Blind detection of path

traversal-vulnerable file uploads

Discovering vulnerable implementations with zero knowledge about the
remote directory structure
 $ whoami
Julian Horoszkiewicz
• IT Security Consultant at Pentest Ltd
• open source and security enthusiast
• OSCP, eMAPT
• GNU/Linux, web, mobile, SIEM
• recently focused on methodology

Cont@ct: skype/gmail/github: ewilded

Path traversal
• software vulnerability (all kinds of software, not just the web apps)
• operations on files: read/write (upload)/rename (move)
• file name value is controlled by the user (should not be trusted)
• file name value is not properly sanitised, making it possible to control
the path with relative path sequences like ./../../../
• “.” – current directory
• “..” – parent directory
• can be exploited to read/write files from/into locations other than
expected by the developer
Relative paths
“.” leads to C:\Windows\System32
(current directory)

“..” leads to C:\Windows\ (parent

directory)

“../../” leads to C:\ (parent directory of the

parent directory)
Relative paths

redundant “..” sequences are ignored

redundant “/” sequences are ignored as

well
Controlling the path
• let’s assume that the current working directory is
/var/www/html/images/
• target path -> /var/www/html/images/ + USER_PROVIDED
• the underlined value is provided by the user, the target path resolves
as follows:
• normal use, the sole filename: file.jpg -> /var/www/html/images/file.jpg
• parent directory jump sequence: ../file.jpg -
>/var/www/html/images/../file.jpg -> /var/www/html/file.jpg
• parent directory jump sequence combined with a new full path:
../../../../home/bob/private_pictures/file.jpg ->
/var/www/html/images/../../../../home/bob/private_pictures/file.jpg ->
/home/bob/private_pictures/file.jpg
Path traversal – read from file example
Read
http://vuln/app/image_path=media/logo.png
http://vuln/app/image_path=media/../media/logo.png
If both above URLs give the same results, it looks like we have a path traversal, so we can
try to read something else, e.g.:
http://vuln/app/image_path=media/../../../../../home/bob/pictures/private.png
http://vuln/app/image_path=media/../../../../../etc/passwd

Now, we’ll talk about writing to files

Web applications - the upload directory and
the document root
• The upload directory is simply the custom folder dedicated to store
uploaded files, for example /tmp/uploads/
• application-specific
• usually hard-coded
• might be configurable
• up to developers
• The document root is the location where web application files (e.g.
HTML, CSS, JSP) reside, for example /var/www/html/
• platform specific
• controlled by the web server configuration
• decided while deploying
• up to administrators rather than developers
Document roots – just few examples
• /var/www/html (APACHE)
• /var/www/html/www.example.org (APACHE)
• /usr/local/apache2/example (APACHE)
• /usr/local/tomcat/webapps/example (TOMCAT)
• /opt/tomcat5/webapps/example (TOMCAT)
• /var/www/nginx-default (NGINX)
• c:\inetpub\wwwroot\ (IIS, Windows)
• D:/Program Files/Apache Group/Apache2.2 (Apache, Windows)
A vulnerable file upload example
A vulnerable file upload example
What happens when we use it
What happens when we abuse it – example 1
 What happens when we abuse it – example 2

Very easy when we know what the

document root is
Vulnerable upload - malicious goals
• Modify information (e.g. website deface)
• Plant malicious HTML/JavaScript code (embedded XSS)
• Upload an executable file (e.g. JSP) to the document root -> Remote
Code Execution
Malicious goals – mandatory conditions to
upload a working webshell

1. we can write to the document root, either because

• the upload directory is inside of the document root
• the application is vulnerable to path traversal
Sometimes both of these conditions are met, but one is
usually sufficient

2. we can control file contents and extension

Directory structure - possible variants
• A) the upload directory is located inside of the document root (bad
practice), e.g.
• the document root: /var/www/html/example.org/
• the upload directory: /var/www/html/example.org/admin/docs/uploads/

• B) the upload directory is located outside the document root (good

practice), e.g.
• the document root: /var/www/html/example.org/
• the upload directory: /home/example/uploads/
Possible variants - the right payloads
• A) the upload directory is located inside of the document root
• the document root: /var/www/html/example.org/
• the upload directory: /var/www/html/example.org/admin/docs/uploads/
• If we know the upload dir, we do not even need the traversal (the payload is simply
shell.php): http://example.org/admin/docs/upload/shell.php?cmd=whoami
• otherwise: the payload = ../../../shell.php
• the result of concatenation (upload_dir+filename):
/var/www/html/example.org/admin/docs/uploads/../../../shell.php ->
/var/www/html/example.org/shell.php, Remote Code Execution:
http://example.org/shell.php?cmd=id

Note: the payload in this scenario does not even require the document root!
Possible variants - the right payloads
• B) the upload directory is located outside the document root
• the document root: /var/www/html/example.org/
• the upload directory: /home/example/uploads/
• the payload: ../../../var/www/html/example.org/shell.php
• the result of concatenation (upload_dir+filename):
/home/example/uploads/../../../var/www/html/shell.php ->
/var/www/html/example.org/shell.php, Remote Code Execution:
http://example.org/shell.php?cmd=id
Black-box/grey-box method – a lot of
guesswork (what this is all about)
• Zero/little knowledge about the target (just a remote end-user
perspective)
• No source code available/config files available
• No information about the directory structure (upload dir?!,
document root?!)
• Sometimes this information is available/attainable (e.g. by taking
advantage of verbose error messages)... but usually it is not, what
then?!
• This is why we call such scenario “Blind”
Blackbox/greybox – hit the document root
• The document root is platform-specific
• It *might* contain the common name of the application,e.g.
/var/www/html/commonname
• Using known platform-specific document roots and possible common
names, we can generate a list of potential document root paths
• https://github.com/ewilded/get_docroots
• Inspired by sqlmap’s –os-shell feature
• We blindly try to upload a completely valid
file to all potentially valid document roots
The algorithm
1. Generate a full list of potentially valid document roots
2. Using a web browser with an intercept proxy (Burp Suite), upload a
single, legitimate file that is surely accepted by the application
(type, size, contents, name) – NO malicious contents/extensions
3. Transfer the upload request to Intruder, embedding the list of paths
in the file name holder
4. Create a second holder inside of the sent file contents, with
incrementing natural numbers (to mark the first payload)
5. Start the attack
6. Check if the file has been created by requesting it
Generating the list – basic config
Generating the list – basic config
Generating the list – evasive versions of the
payloads
Example:
./....//....//....//....//....//....//....//....///usr/local/localhost/apache/www/apache22/localhost/htdocs/test.png

Aimed at circumvention of poorly written (non-recursive) sanitisation

functions, e.g. REMOVE ALL ../:
• ./....//....//....//....//....//....//....//....///usr/local/localhost/apache/www/apache22/localhost/htdocs/
test.png ->
• ./....//....//....//....//....//....//....//....///usr/local/localhost/apache/www/apache22/localhost/htdocs/
test.png ->
• ./../../../../../../../..//usr/local/localhost/apache/www/apache22/localhost/htdocs/test.png
The Intruder attack
Change the attack
type to Pitchfork

Use two holders:

1)The file name

2)Some safe place in

the content (exif
tags are safe
choice for
pictures)
The Intruder attack
The first payload
set (the file
name) -> the list
we have just
generated

Do not URL-encode these characters

The Intruder attack
The second payload set (the
file content holder) ->
ascending natural numbers

Again, do not URL-encode these

characters (even if they are not there
)
The Intruder attack – attack!
Verifying the result
Identifying the golden payload
And the winner is….

./../../../../../../../..//var/lib/to
mcat7/webapps/uploadbare/

The logical next step is to take this payload

and try to upload a shell (and bypass other
possible file upload restrictions – which is a
whole different subject )
An interesting diversion
A) the upload directory is located inside of the document root
the document root: /var/www/html/example.org/
the upload directory: /var/www/html/example.org/admin/docs/uploads/
If we know the upload dir, we do not even need the traversal (the payload is simply shell.php):
http://example.org/admin/docs/upload/shell.php?cmd=whoami

If the application is NOT vulnerable to path traversal, but the upload dir is inside of the
document root (but we still do not know what the upload directory is):
• make sure we did all the content discovery (passive and active directory
enumeration)
• check all discovered directories from the site map for existence of the uploaded file
An interesting diversion
An interesting diversion
Extract a unique list of
existing directories
An interesting diversion
An interesting diversion
Covered vulnerable scenarios summary
• Upload dir outside of the document root
• Path traversal required
• Document root full path required
• Upload dir inside of the document root, but unknown/not directly
accessible
• Path traversal required
• Document root full path NOT required
• Upload dir inside of the document root and known/enumerable +
directly accessible
• Path traversal NOT required
• Document root full path NOT required
Other things worth mentioning
• Sometimes the document root might not be writable, but one of its
subdirectories might be – this would require to generate a way longer
payloads list, using the directories from the site map
• The document root is not the only one target worth writing to:
• System binary files
• System scripts, user scripts
• Crontabs
• Autostart locations
• Blind exploitation (no way to confirm the path traversal in the first place)
• Targets are world-writable/server is running as root
• Using get_docroots.pl for other purposes (like reading files )
Possible improvements
• More document root paths?
• Support for windows!
• Improved evasive techniques?
• More automation (a Burp plugin?)
• Removable file scenario detection
• Race condition scenario detection
• How common is the upload-path-traversal today?
Thanks for attention!