2013-12-13

restriction to code execution. Need to think about other impacts

← Older revision

Revision as of 18:36, 13 December 2013

(One intermediate revision by one user not shown)

Line 3:

Line 3:

 

Author(s):  

 

Author(s):  

 

*[[User:Soroush Dalili|Soroush Dalili]]

 

*[[User:Soroush Dalili|Soroush Dalili]]

 

+

*[[User:Dirk Wetter|Dirk Wetter]]

 

*[[User:OWASP|OWASP]]

 

*[[User:OWASP|OWASP]]

 

 

Line 13:

Line 14:

 

Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.  

 

Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.  

 

 



The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system, forwarding attacks to backend systems, and simple defacement. It depends on what the application does with the uploaded file
, including
where it is stored.  

+

The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system
or database
, forwarding attacks to backend systems, and simple defacement. It depends on what the application does with the uploaded file
and especially
where it is stored.  

 

 

 

There are really two different classes of problems here. The first is with the file metadata, like the path and filename. These are generally provided by the transport, such as HTTP multipart encoding. This data may trick the application into overwriting a critical file or storing the file in a bad location. You must validate the metadata extremely carefully before using it.  

 

There are really two different classes of problems here. The first is with the file metadata, like the path and filename. These are generally provided by the transport, such as HTTP multipart encoding. This data may trick the application into overwriting a critical file or storing the file in a bad location. You must validate the metadata extremely carefully before using it.  

 

 



The other class of problem is with the file content. The range of problems here depends entirely on what the file is used for. See the examples below for some ideas about how files might be misused. To protect against this type of attack, you should analyze everything your application does with files and think carefully about what processing and interpreters are involved.  

+

The other class of problem is with the file
size or
content. The range of problems here depends entirely on what the file is used for. See the examples below for some ideas about how files might be misused. To protect against this type of attack, you should analyze everything your application does with files and think carefully about what processing and interpreters are involved.  

 

 

 

 

 

== Risk Factors  ==

 

== Risk Factors  ==

 

 



*The impact of this vulnerability is high
but
the likelihood is
low
.
So,
the severity of this type of vulnerability is
Medium.

+

*The impact of this vulnerability is high
, supposed code can be executed in
the
server context or on the client. The
likelihood
of a detection for the attacker
is
high
.
The prevalence is common. As a result
the severity of this type of vulnerability is
High
.  



*The website can be defaced
.  

+

*The web server can be compromised by uploading and executing a web-shell which can: run
commands
, browse system files, browse local resources, attack other servers, and exploit the local vulnerabilities, and so on. This
may also result in a defacement
.



*The web server can be compromised by uploading and executing a web-shell which can: run
a command
, browse
the
system files, browse
the
local resources, attack
to
other servers, and exploit the local vulnerabilities, and so on.  

+



*
This
vulnerability can make the website vulnerable to some other types of attacks such as [[Cross-site Scripting (XSS)|XSS]]
.  

+

 

*An attacker might be able to put a phishing page into the website.  

 

*An attacker might be able to put a phishing page into the website.  

 

+

*An attacker might be able to put a stored XSS into the website/

 

+

<!--

 

*Local file inclusion vulnerabilities can be exploited by uploading a malicious file into the server.  

 

*Local file inclusion vulnerabilities can be exploited by uploading a malicious file into the server.  

 

+

-->

 

+

*This vulnerability can make the website vulnerable to some other types of attacks such as [[Cross-site Scripting (XSS)|XSS]].

 

+

* Pictures may trigger vulnerabilities in broken picture libraries on a client (libtiff, IE had problems in the past) if picture is published 1:1

 

+

* Script code or other code may be embedded in the uploaded file which gets executed if picture is published 1:1

 

*Local vulnerabilities of real-time monitoring tools such as an antivirus can be exploited by uploading a harmful file.  

 

*Local vulnerabilities of real-time monitoring tools such as an antivirus can be exploited by uploading a harmful file.  



*A malicious file can be uploaded on the server in order to have a chance to be executed by administrator or webmaster later
.

+

*A malicious file
(Unix shell script, windows virus, reverse shell)
can be uploaded on the server in order to have a chance to be executed by administrator or webmaster later
-- on the server or on a client of the admin or webmaster



*The web server might be used as a
warez
server
by a bad guy
in order to
be
host of
malwares
, illegal software,
steganographic objects
, and
so on
.

+

*The web server might be used as a server in order to host of
malware
, illegal software,
porn
, and
other objects
.

 

 

 

== Examples  ==

 

== Examples  ==

Line 62:

Line 67:

 

*In case of using IIS6 (or prior versions), it might be possible to bypass this protection by adding a semi-colon after the forbidden extension and before the permitted extension (example: “file.asp;.jpg”).

 

*In case of using IIS6 (or prior versions), it might be possible to bypass this protection by adding a semi-colon after the forbidden extension and before the permitted extension (example: “file.asp;.jpg”).

 

*In case of using IIS6 (or prior versions), it might be possible to bypass this protection by putting an executive file such as ASP with another extension in a folder which ends with an executive extension such as “.asp” (example: “folder.asp\file.txt”). Besides, it is possible to create a directory just by using a file uploader and ADS (Alternate Data Stream). In this method, filename should end with “::$Index_Allocation” or “:$I30:$Index_Allocation” to create a directory instead of a file (example:  “newfolder.asp::$Index_Allocation” creates “newfolder.asp” as a new directory).

 

*In case of using IIS6 (or prior versions), it might be possible to bypass this protection by putting an executive file such as ASP with another extension in a folder which ends with an executive extension such as “.asp” (example: “folder.asp\file.txt”). Besides, it is possible to create a directory just by using a file uploader and ADS (Alternate Data Stream). In this method, filename should end with “::$Index_Allocation” or “:$I30:$Index_Allocation” to create a directory instead of a file (example:  “newfolder.asp::$Index_Allocation” creates “newfolder.asp” as a new directory).



*This protection can be completely bypassed by using the
most famous
control
character which is
Null
character
(0x00) after the forbidden extension and before the permitted one. In this method, during the saving process all the strings after the Null character will be discarded. Putting a Null character in the filename can be simply done by using a local proxy or by using a script (example: “file.asp%00.jpg”). Besides, it would be perfect if the Null character is inserted directly by using the Hex view option of a local proxy such as Burpsuite or Webscarab in the right place (without using %).  

+

*This protection can be completely bypassed by using the
e.g.
control
characters like
Null (0x00) after the forbidden extension and before the permitted one. In this method, during the saving process all the strings after the Null character will be discarded. Putting a Null character in the filename can be simply done by using a local proxy or by using a script (example: “file.asp%00.jpg”). Besides, it would be perfect if the Null character is inserted directly by using the Hex view option of a local proxy such as Burpsuite or Webscarab in the right place (without using %).  

 

*It is also possible to create a file with a forbidden extension by using NTFS alternate data stream (ADS). In this case, a “:” sign will be inserted after the forbidden extension and before the permitted one. As a result, an empty file with the forbidden extension will be created on the server (example: “file.asp:.jpg”). Attacker can try to edit this file later to execute his/her malicious codes. However, an empty file is not always good for an attacker. So, there is an invented method by the author of this paper in which an attacker can upload a non-empty shell file by using the ADS. In this method, a forbidden file can be uploaded by using this pattern: “file.asp::$data.”.

 

*It is also possible to create a file with a forbidden extension by using NTFS alternate data stream (ADS). In this case, a “:” sign will be inserted after the forbidden extension and before the permitted one. As a result, an empty file with the forbidden extension will be created on the server (example: “file.asp:.jpg”). Attacker can try to edit this file later to execute his/her malicious codes. However, an empty file is not always good for an attacker. So, there is an invented method by the author of this paper in which an attacker can upload a non-empty shell file by using the ADS. In this method, a forbidden file can be uploaded by using this pattern: “file.asp::$data.”.

 

*In Windows Servers, it is possible to replace the files by using their short-name (8.3). (example: “web.config” can be replaced by uploading “web~1.con”)

 

*In Windows Servers, it is possible to replace the files by using their short-name (8.3). (example: “web.config” can be replaced by uploading “web~1.con”)

Show more