This document summarizes a case study of a remote code execution vulnerability in a publicly available web application called BogusVenture. Due to flaws in the application's file upload functionality, an attacker could craft an HTTP request to upload a malicious file like a DLL that would execute code on the server. The vulnerability was possible due to a lack of authentication on internal pages, bypassable file type validation via direct requests, and a bug in filename canonicalization that allowed traversing to other parts of the file system. The case study aims to demonstrate how these flaws could be exploited to achieve remote code execution without any user credentials.

1. Malicious file upload attacks: A Case Study
Oktawian Powązka
Recently, I had a chance to analyze a trial version of some publically available Web application
portal (for the sake of this publication let's call it BogusVenture) and came up with very
interesting observations.
To my astonishment, due to some serious security flaws, this particular software suffers from an
arbitrary file upload vulnerability that can be leveraged to gain remote code execution on the
underlying server.
In this article, learn about a case of Remote Code Execution threat to Web application software
and how to guard against them.
The Download section contains all the required components for a malicious file upload attack
case study presentation.
Introduction
It’s an open secret that remote file upload represents a significant risk to all publically available
Web Servers, nevertheless, in today’s internet world, it is a common practice because it helps to
increase business efficiency.
Among many other places, file uploads are allowed in Web application portals, to give the
opportunity to the end user to efficiently share files with others.
As in life, the more functionality is provided to the user, the greater is the risk due to the
increased entropy of the whole system.
The first step in many attacks is to get some script or executable code to be delivered into some
remote system.
Obviously, the consequences of some unrestricted file upload may vary.
In this particular case study a potential attacker would be able to remotely execute the code
embedded in the Windows library file (DLL).
This vulnerability can be exploited by remote attacker without any user account knowledge as
there is no prior authentication mechanism embedded into some of the portal’s internal websites.
As elementary as it sounds, this is certainly not a first and not the last time when such common
flaw exist in the wild.
In such cases, the first line of defense would be a good Web application firewall able to filter out
the malicious http traffic containing the arbitrary binary data like executable files or scripts.
Nevertheless, it goes without saying that discovery of such security bug should be done during
development and penetration testing phase.

2. For this publication, I have prepared very simple Web application upload website designed to
emulate the exact behavior of this authentic BogusVenture portal run in the real world.
I have replicated this web service using some simple reverse engineering techniques as the whole
application Portal has been written using combination of HTML, JavaScript and Java language.
One very interesting feature of this real upload website is that the user input validation is done by
the two separated layers:
• file type’s validation is done by the JavaScript code,
• canonicalization of filenames is done by the Java servlet code,
As I’ll present further on, none of those two layers is able to stop the malicious file upload by the
skillful attacker.
From the adversary point of view successful uploading of the malicious content is one thing, but
remote execution of such arbitrary binary or script file in such a way that is stays undiscovered is
another.
That is one of the reasons why I’ve picked up the Windows library file as a payload for this
attack vector.
At first, let’s indentify all the security flaws around this BogusVenture portal application code…
The flaw
For starters, let’s define what is meant by Web application software in the context of this
publication.
Most of the time, a Web application is comprised of a collection of scripts, that reside on a Web
server and interact with some sort of databases.
The term ‘script’ is very generic here as it can contain the whole bunch of various programming
languages depending on the type of underlying Application Server.
For the purpose of this case study, I’ve used IBM WebSphere Application Server (WAS) as
Application Server to run my version of BogusVenture upload website.
WAS is also one of the Application Servers supported by this real BogusVenture portal service.
Of course, you can easily deploy this ‘.war’ file into JBoss or Weblogic as the servlet code
imports only some elementary Java classes.
Following is the list of security issues around this original upload website:
• A complete lack of initial authentication when website is accessed using a direct link,
• Upload file type’s validation can be easily breached by sending a direct http POST
request,
• A bug in the part of the code responsible for canonicalization of filenames,
• No file upload logging mechanism making any attack invisible for the Application Server
administrator.
So, let’s indentify each of those above issues one be one.

3. • Lack of authentication
It looks like that design criteria of this BogusVenture portal took for granted that the user always
uses main login page to access all subsequent application resources.
After successful authentication, user is welcomed with a menu of links the user is authorized to
access.
The problem with such approach is that it only works as long as user is not aware of Web portal
structure.
If he ever used the upload website before he would know the direct URL address leading to the
this page…after all it’s shown in the browser address bar.
Of course, if an attacker gets direct access to such trial software version he can study all the
application resources as those are fully available after default installation.
It’s not even required do decompile anything as all those ‘.jsp’ files are stored in clear text.
It looks like a typical example of ‘Security through obscurity’ which is completely unreasonable
in the modern world.
Summing up, some of the portal portal’s internal websites require no authentication itself and
blindly provides the requested content.
• Improper use of file type’s validation
Again, design criteria of this Portal took for granted that users always use Web browser to access
any of the application resources.
After attacker learns this upload website URL he can easily construct a crafted http POST
request using some scripting techniques and bypass this validation layer.
The problem is that file type’s validation is done by the JavaScript code called directly from
‘Upload’ button action embedded within HTML document.
Well, this technique works perfectly as long as the user uses the ‘Upload’ button for files upload
process as presented in the ‘Figure 1’.
Figure 1: The real upload website emulated by BogusVenture application.
But if attacker sends a direct http request using this upload URL address with all the required
parameters and the filename embedded in the http header, a Java Servlet code will be called first
and will predate any HTML and JavaScript execution.
This looks like a typical oversight during Web page design phase.
‘Listing 1’ depicts the case.

4. Listing 1: The authentic FileUpload.jsp structure.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<%@ page import="java.util.*" %>
<%@ page import="com.bogusVenture.WebHelper.FileSystemManager" %>
<%
if(request.getParameter("parameters") !=null)
{
FileSystemManager fileManager = new FileSystemManager();
if (request.getMethod() == "POST"){
fileManager.saveFile(request);
}
}%>
<HTML>
--- HTML/JavaScript content ---
</HTML>
Lucky for the attacker, due to this Portal design architecture, the Java servlet code does not
perform any additional checks on the type of the file being uploaded.
It barely checks filename structure.
Of course, using just internet browser, it’s also possible to input the whole URL address
manually (‘http://localhost:8080/bogusVenture/FileUpload.jsp?parameters=true’) but in such
case there is no chance to encode filename field into http header.
There is one more thing as far as this file type’s validation goes.
This BogusVenture portal application has left those file types as configurable option with the
‘.exe’ as the exclusive default extension.
Such assumption is pretty naive as for example ‘.dll’ library can do even more harm if delivered
to the right place.
• Error in Canonicalization of filenames
The consequence of this bug is critical as it allows to traverse from the default application
destination folder to some another location on the remote file system.
Basically, the Java servlet code does not properly neutralize slash/backslash sequences of the
filename part from the Content-Disposition field of the http header.
One of the most common is the ‘../’ sequence, which in most operating systems is interpreted as
the parent directory of the current location.
This is referred to as relative path traversal.
This particular servlet code removes all the characters before the last instance of ‘/’ or ‘’
depending which comes first but it does not check both simultaneously.
‘Listing 2’ presents the case of http request containing filename prefixed by a combination of
slash and backslash sequence (‘../../../../../../’)
That's the key to this attack vector.

5. So, when the servlet code does its buggy filename ‘sanitization’ and tries to save the file into its
destination folder, Windows resolves all those remaining ‘../’ sequences and traverse into the
‘C:’ (root directory) and subsequently into whatever is specified afterwards.
Lucky for the attacker, Windows accepts unlimited amount of those ‘../’ sequences…so, it
doesn’t matter how deep the application destination folder has been setup.
In BogusVenture example the application destination folder is ‘c:Program
FilesbogusVentureDocuments’.
The real portal application left this destination folder location as configurable option.
Listing 2: An example of specially crafted http request which includes a
combination of slash and backslash sequences within its Content-
Disposition field
POST http://localhost:8080/bogusVenture/FileUpload.jsp?parameters=true HTTP/1.1
Content-Type: multipart/form-data; boundary=145a950bd26
User-Agent: Java/1.7.0_25
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 49324
--145a950bd26
Content-Disposition: form-data; name="userfile"; filename="../../../../../../Windows/sfc_
Content-Type: application/octet-stream
MZ��������������������@���������������������������������
���� �!� L�!This program cannot be run in DOS mode.
….
• Lack of file upload logging
So, let’s say that attacker was able to upload some malicious file somewhere into the file system
application outside of the application destination folder.
Now, the problem is that this whole operation goes undiscovered.
This servlet code doesn’t contain any logging mechanism of all those operation done on Server
file system.
It certainly has its debugging mode switch, which does log some of such operations into
application server log file (using log4j as logging framework) but nobody uses debugging mode
on a real production environment.
This complete lack of file upload logging functionality only confirms the thesis that designers
took for granted that all users always behave ethically.

6. Remote Code Execution vs Windows protection mechanisms
From the attacker point of view successful uploading of some malicious content into some
remote Server is just first step within the whole attack scenario.
Before we even delve deeper into the Windows code execution details I should point out that
there is one basic concept which can easily counteract any arbitrary file upload scenario
(malicious or not).
This technology is called User Account Control (UAC) and if configured properly it can prevent
most of those attacks.
Once again, lucky for the potential attacker, many Windows Server Administrators setup some
particular Application Server to be run under LocalSystem account which by default, is much
more powerful that any member of the Administrators group.
The LocalSystem account would be especially useful when considering saving some file content
under ‘C:Windows’.
If UAC is enabled and attacked Application Server is run under the account with administrative
privileges the amount of potential places for malicious code/script upload relatively shrinks.
Because in such case ‘C:Windows’ and ‘C:Program Files’ are out of option the only viable
solution would be ‘C:’ (root directory).
The only problem is to somehow get the uploaded code executed by some relevant process.
Of course, apart from UAC, there are also some other problems to consider like Windows
installation done to some other folder than the default ‘C:Windows’ or a separated drives for
operating system and application location.
For our case study let’s assume that attacker was indeed lucky and came across the System
where all those listed conditions are fulfilled.
I’d say it’s 50/50 chance for such scenario.
Now our attacker needs to choose destination folder and file type for its malicious payload.
The only requirement is to find the target file, which would be automatically executed by the
operating system.
Attacker could select something below ‘C:Program Files’ directory or even target the
Application Server itself but is quite possible that the name of such sub-directory on remote
machine is entirely different than initially expected.
So, ‘C:Windows’ or one of its subfolders seems to be the most likely a choice as a malware
upload destination.
The next decision to make is to either overwrite some existing executable or provide a new one.
Let’s consider which option gives more probability of success.
In previous version of Windows (before Vista/2008), overwriting existing executable was an
easy task as Windows File Protection (WFP) mechanism could be trivially defeated by
overwriting the targeted executable (or dll) within ‘dllcache’ folder first and later uploading the
second copy into final location.
The only requirement was to send http request twice. (Basically, WFP detects any attempt made
by other programs to replace or move a protected system files by checking their digital signature.

7. If signature doesn’t match WFP restores the original version from its ‘dllcache’ folder.)
However, this attack scenario is not trivial anymore when taking into consideration any of the
newer Windows versions due to Windows Resource Protection model.
This new mechanism (an enhanced version of good, old WFP) sets access control lists (ACLs)
on most operating system files (roughly couple of thousands of them) so they are not writable by
any member of the Administrators group or even LocalSystem account.
The only account, which can overwrite one of those protected files, is TrustedInstaller account.
Unfortunately, none of the existing Web Application Servers runs using TrustedInstaller
privileges.
‘Listing 3’ presents the example.
Listing 3: The default ACL for Windows Command Processor (cmd.exe)
protected by Windows Resource Protection.
icacls c:WindowsSystem32cmd.exe
NT SERVICETrustedInstaller:(F)
BUILTINAdministrators:(RX)
NT AUTHORITYSYSTEM:(RX)
BUILTINUsers:(RX)
Upon reflection, those distinct Windows protection mechanisms has let me into conclusion that
the best way for malicious payload is to upload a non-existing binary file.
For this construct, I’ve picked up the Windows library format (DLL) due to the following
reasons:
• There is a chance (although extremely slim) that some potential application firewall rules
will ignore the ‘.dll’ extension when analyzing http header.
(As I’ve presented before, BogusVenture portal code has only filtered out the ‘.exe’
extension by default).
• By design, Windows libraries are not visible on the process list using Task Manager thus
much harder to be disclosed by most Server Administrators.
• Windows offers the so-called ‘hooking mechanism’, which allows to monitor the
message traffic passing between different Operating System components.
There is one condition: hooking/monitoring procedure must be implemented within a
DLL.
If that condition is met, the operating system injects such DLL automatically into all
processes that meet the requirements for particular hook filter.
(I’ve presented this concept extensively in another publication: ISAM ESSO under the
hood)
There is only one problem as far as Windows library format is concerned: Bitness (‘exe’ would
has advantage over ‘dll’ in such case).
If attacker is planning to load some library into specific executable he needs to predict if the
target Operating System is 64 or 32bit based.
Unfortunately, it’s not possible to load 32bit DLL into 64bit process address space (and vice
versa).
One thing is certain, the further in time such attack will be conducted the bigger the chance to hit
64bit Server.

8. Proof of concept: an Exploit payload part
The remaining question is which Windows process should be selected as a host for malicious
DLL payload.
After quick research I’ve picked up Windows Explorer (‘explorer.exe’) as a target.
Windows Explorer, also referred as Windows shell, is located in the ‘C:Windows’ directory.
It’s mainly responsible for presenting all the user interface items such as the Windows Taskbar
and Desktop.
‘explorer.exe’ is started by ‘Userinit’ every time when someone login either locally or by
Remote Desktop connection.
(As has been the case with other impediments around this attack, there is a possibility (although
very remote) that some particular Server Administrator has used other program for User desktop
interface, for example bblean).
One of the features of Windows Explorer is that every time when some other application is
started from its desktop, Explorer calls System File Checker (implemented in ‘sfc.dll’ and
‘sfc_os.dll’) to perform some simple file verification procedure.
From the adversary point of view the important part is that it loads those two libraries only for a
fraction of a second.
So far, this mechanism works in most newer Windows versions (at least in case of Windows 7 /
2008 / 2012).
By default, ‘sfc_os.dll’ is located in ‘C:WindowsSystem32’ but due to the way how dynamic
libraries are loaded on Windows the first directory to be searched is always (with few exceptions
defined under ‘KnownDLLs’ registry entry) the directory containing the executable file used to
create the calling process.
In Windows Explorer case it would be ‘C:Windows’.
This mechanism allows for private DLL files associated with a process to be found without
adding the process's installation directory into the System PATH variable.
Although this mechanism seems to be pretty useful it’s also a double-edged sword because the
attacker can place his own malicious version of the DLL file into the calling process directory,
thereby blocking the genuine one.
This is exactly what we are going to do in our case study simulation.
‘Figure 2’ presents the whole DLL loading sequence upon Windows calculator (‘calc.exe’)
initialization process.

9. Figure 2: Malicious version of ‘sfc_os.dll’ called by Windows Explorer.
‘Figure 2’ might look slightly misleading…let me depict the whole loading sequence step by
step (please don’t pay attention to those recurring calls...it’s just a way how operating system
load dynamic libraries):
1. Explorer calls ‘sfc.dll’ as part of System File Checker procedure for Windows calculator.
2. ‘sfc.dll’ functionality is dependent on some interfaces located in ‘sfc_os.dll’,
3. As I’ve pointed out before, because ‘sfc.dll’ is loaded into memory space of Windows
Explorer it would search for ‘sfc_os.dll’ starting from Explorer process directory
(‘C:Windows’).
4. I’ve designed ‘sfc_os.dll’ in such a way that after simple initialization procedure it will
forward all API function calls to the genuine version of ‘sfc_os.dll’ library located in
‘C:WindowsSystem32’
5. Calculator is being started using prefetch cache to improve application startup
performance.
That particular design allows for malware to execute itself every time when some genuine
application is started from Windows desktop.
For administrator, it would be very difficult to detect the existence of this malicious version of
‘sfc_os.dll’ as it would not be visible in tools like Task Manager and moreover it’s loaded into
Explorer memory for a very, very short time.
A malicious payload (code and data) could relocate itself from the memory region allocated for
DLL to some other memory region in the Explorer virtual address space and allows to unload the
host library.
Through all this time, that payload would be running just as another Windows Explorer thread
under the same privileges as its parent. There are many possibilities in that area.
The thing is that even on relatively secure Windows Server, administrators use some basic and
trusted operating system tools (Notepad, Microsoft Management Console etc. etc.) for its
administrative work.
That way, malware can load and unload itself for endless amount of time.
My version of ‘sfc_os.dll’ (it’s 64bit version) is trivial and benign; it barely plays the simple
sound (‘Windows Exclamation.wav’) during DLL initialization procedure (DllMain entry point).
It also uses a simple technique to forward all those API calls sent from the caller (most of the
time it’s ‘sfc.dll’) to the intended recipient: genuine version of ‘sfc_os.dll’.

10. Proof of concept: an Exploit sender part
Now, it’s a time for the sender… first of all, the attacker needs to somehow deliver this
malicious library into destination folder located somewhere on the remote server .
To recall, ‘Listing 2’ presents http request, which needs to be constructed for Exploit delivery.
Although, such functionality can be written in many scripting languages, I’ve decided to use
good, old Java for this simple task.
‘Listing 3’ presents an excerpt from the Java class designed to construct a simple http request
with the crafted filename field and its file payload.
File payload contains ‘sfc_os.dll’ library encoded using Base64 encoding scheme.
Listing 3: Excerpt from the Exploit payload sender code
...
((HttpURLConnection) connection).setRequestMethod("POST");
connection.setRequestProperty("Content-Type", "multipart/form-data; boundary=" + boundary);
BufferedOutputStream writer = new BufferedOutputStream(connection.getOutputStream();
writer.write(("--" + boundary + CRLF).getBytes());
writer.write(("Content-Disposition: form-data; name="userfile"; filename="../../../../../../Wi
writer.write(("Content-Type: application/octet-stream" + CRLF + CRLF).getBytes());
writer.write(Base64.decode("TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
)
writer.write(CRLF.getBytes());
writer.write(("--" + boundary + "--" + CRLF).getBytes());
...
The compiled class can be accessed from the Download area (SendExploit.jar).
It’s fully compatible with Sun and IBM JVM.
Due to this overall task simplicity the rest of the Sender code does not even deserve to be
discussed.
Apart from the http request cooking, there are couple lines of code designed to bypass SSL/TLS
certificate check to get the content of BogusVenture application through HTTPS protocol.
In other words, to ‘relax’ the Java security manager through disabling Server certificate
verification.
The ‘SendExploit‘ class needs to be invoked in the following way:
• java -cp SendExploit.jar SendExploit
http://hostname:port/bogusVenture/FileUpload.jsp?parameters=true
Where
‘hostname’ is the machine name or IP address of the Application Server,
‘port‘ is the address of the port on which the Application Server is listening for requests.
‘bogusVenture’ is the name of this example Web application which needs to be deployed
using the ‘.war’ file from the Download area.

11. A short summary about User Input Validation
The most crucial oversight done by those real BogusVenture application developers is improper
input validation.
The general rule would be to assume that all user input is malicious.
Validation strategy should use a whitelist of acceptable input characters that strictly conform to
some predefined construct.
Designers should not rely exclusively on malformed user input using only a blacklist…there is
always a chance to overlook some characters.
Especially those nasty filenames can hide elements like ‘../’ or ‘~’ allowing to get outside the
destination folder on the remote end.
A separated issue is proper file type’s validation.
Still, there are some Web applications (although minority), which use blacklist of file type
extensions to prevent malicious content filtering.
Again, this technique is just disaster waiting to happen.
Conclusions
As has been presented, BogusVenture application shows some serious security flaws.
Typically, such flaws should be discovered during penetration testing phase.
BogusVenture application is an perfect example where penetration testing has been completely
neglected.
Nevertheless, it’s also true, that HTTP protocol can employ a myriad of encoding and
encapsulation techniques.
There is no way to predict all those possible ways how such protocol can be exploited… there's
just too much entropy in this modern, internet world.
Download area
1. ‘SendExploit‘ container:
SendExploit.jar

12. 2. ‘bogusVenture’ Web application. (archive ‘.war’ file):
bogusVenture.war
Resources
• Malware Scanner extension for IBM Security AppScan
• rfc2616 - Hypertext Transfer Protocol specification
• Windows Resource Protection
• ISAM ESSO under the hood
• Process Monitor...an advanced monitoring tool for
Windows