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

save
Share and earn Cybytes
Facebook Twitter LinkedIn Email

Kate Haworth|

January 05, 2017

Part 1 – The Directory Traversal Attack

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:

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.

Bookmark our Blog page for the next installment from my colleague – Path Traversal Attack Solutions.

Share this post and earn Cybytes
Facebook Twitter LinkedIn Email
Follow
174 Followers
About WhiteHat Security
WhiteHat Security is the leading provider of website risk management solutions. Sentinel, WhiteHat's flagship product, is the most accurate, complete and cost-effective website vulnerability management solution available. It delivers the flexibility, simplicity and manageability that organizations need to take control of website security and prevent Web attacks. WhiteHat Sentinel is built on a Software-as-a-Service (SaaS) platform designed from the ground up to scale massively, support the largest enterprises and offer the most compelling business efficiencies, lowering your overall cost of ownership.
Promoted Content
Application Security Testing as a Foundation for Secure DevOps
Organizations realize that addressing the risk of attacks on their Website applications is critical. Given the growing number of Website applications that businesses now must manage in a highly competitive environment, organizations are quickly trying to evaluate how to deploy software faster to meet or exceed company goals. It is imperative for Information Security teams to realize that aligning to a rapidly changing business is now part of their requirement to be competitive and successful in today’s digital world.

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Support Cybrary

Donate Here to Get This Month's Donor Badge

 

We recommend always using caution when following any link

Are you sure you want to continue?

Continue
Cancel