Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

TRC Tech Talk: Directory Traversal Attack and Defense – Part 1

DZone's Guide to

TRC Tech Talk: Directory Traversal Attack and Defense – Part 1

A look at a traversal attack encountered on a consultant customer's website, and how the attack works.

· Security Zone
Free Resource

Discover an in-depth knowledge about the different kinds of iOS hacking tools and techniques with the free iOS Hacking Guide from Security Innovation.

I work in the penetration testing team of the Threat Research Center, working with customers who use dynamic scanning of their website as part of their application security solution. Application security is a key part of the greater network security ecosystem, taking care of hacks made directly against the user-facing interface. My job is to find vulnerable features within applications, and let the customer’s DevOps know where they need to fix their code.

What follows is a directory traversal hack I found “In the Wild” as they say, on a customer’s actual website I was working on. Our customer was a large enterprise client involved in Information Management, but this could be present on many web applications that allow a user to upload and download files.

In Open Web Application Security Project (OWASP) terms, a directory traversal attack falls under the category A4 of the top 10: Insecure Direct Object References. A directory traversal attack aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations, or by using absolute file paths, a hacker may be able to access arbitrary files and directories stored on a file system — including application source code or configuration and critical system files. This type of attack is variously known as “dot-dot-slash”, “path traversal”, “directory traversal”, “directory climbing” and “backtracking.” It should be noted that access to files is limited by system operational access control (such as in the case of ‘locked’ or ‘in-use’ files on the Microsoft Windows operating system).

In most cases I see issues where unintended content can be accessed via download functionality by using dot-dot-slash sequences, but in this case, I was able to *upload* files to an unintended location.

Here’s a simplified example ([redacted] names in places to protect the innocent):

Files are supposed to go into the specific Activity’s document subfolder, but I was able to put them in the main Projects folder. Each dot-dot-slash in the filename is interpreted as an instruction to go up one level in the file path. Simplified illustration:

Picture1

This next section includes the actual requests I saw while testing (with some more redacting). You can see where the filename with dod-dot-slash characters is included in the POST body request to upload a new file.

Ok, so POST request to:

site.com/filepath/filepath/task/uploadFileAndDetails.do

content-type: multipart/form-data

The filename is submitted in the following places in the POST data:

Content-Disposition: form-data; name=”fileName” /../../WHS Testfile Plaintext

—————————–478258899660247721576781152

Content-Disposition: form-data; name=”file”; filename=”/../../WHS Testfile Plaintext”

Content-Type: application/octet-stream

The response was positive but uninformative:

{“status”:0,”message”:”Success”,”result”:null}

The request sent to change a filename shows us a bit more about where the file is being stored, in the “FileDestinationPath” parameter:

{“activitySid”:5504,”taskSid”:0,”fileDetailsVOs”:[{“fileName”:”/../../Testfile 
  Plaintext”,”file”:null,”fileLookupSid”:950,”fileTypeName”:”Other (optional)”,”fileDescription”:” 
    “,”taskNumbers”:””,”oldTaskSeqNumbers”:””,”fileUploadedDate”:”Apr 27 2016 22:28:10″,”fileModifiedDate”:”Feb 23 2015 
      18:05:50″,”operation”:”U”,”fileDestinationPath”:”/apps/[redacted]_data/[redacted]Files/UploadedFiles/04/5504″,”hasFileUploaded”:”Y”,”hasToBeDeleted”:”Y”,”oldFileName”:”/../../Testfile Plaintext”}]}

And finally the request to download the file, with the file path shown in the URL parameter “FileLocView” describing where the application should retrieve my desired file from.

The full request to retrieve/re-download the file:

https:// site.com/filepath/filepath/viewFileOpen.do?fileLocView=/

apps/[redacted]_data/[redacted]Files/UploadedFiles/02/5502/ZIPOUTPUT// ../../WHS Testfile

Plaintext

A file uploaded with the filename “/../../../whstestfile” can be accessed by going to either (the default location provided by the application) “…UploadedFiles/02/5502/ZIPOUTPUT//../../../whstestfile” OR “…UploadedFiles/whstestfile”.

By removing the notation, I can see that my file is stored (in this case) way up in “Uploaded Files” in the Projects folder.

To check that all activities were uploading to the same UploadedFiles folder, I went to a different Activity and uploaded a new file, but used the same filename. In this instance, the new illegal file overwrote the first illegal file, which I verified by downloading the file and checking if the contents were the original text or the new text.

Finally, I changed the download request completely, and was able to access the Hosts file (/../../../../etc/hosts). This means I was allowed to get into directories that I should not be able to access from the web. For obvious reasons I did *not* attempt to overwrite the localhost file on the production server, but this combination of vulnerabilities has some very serious negative potential – this is a bad combination of path traversal vulnerabilities.

Learn about the importance of a strong culture of cybersecurity, and examine key activities for building – or improving – that culture within your organization.

Topics:
security ,directory

Published at DZone with permission of Kate Haworth, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}