Welcome back to the biweekly Methodology Walkthrough. Today, we’ll explore exactly how a logic flaw can allow an attacker to access unauthorized files.
Objective
Retrieve the contents of the /etc/passwd file.
What is Path Traversal?
File traversal, also known as directory traversal, is a type of vulnerability that allows an attacker to access restricted directories and execute commands outside of the web server's root directory. Attackers can gain access to files and directories stored outside of the intended application surface, potentially exposing sensitive information such as configuration files, passwords, and other critical data. This vulnerability typically occurs due to insufficient sanitation of user input, allowing the insertion of characters or sequences to traverse up the directory tree and access unauthorized areas.
Methodology
The Recon
Our first step, as with any application, is to figure out where our attack vector will be.
It looks like the application has very simple functionality: a shop with product pages that have no functionality.
There is also no functionality to authenticate to the application.
Next, let’s take a look at the SiteMap.
There is nothing immediately apparent that could contain a path traversal. Although there is the retrieval of a prodcut, it is just an API call to retrieve a product, not a specific file.
The /images folder also does not look like it has any functionality.
Next, let’s take a look at the HTTP History under the Proxy tab.
It looks like we may have found our entry point!
We can see that there is a filename parameter that is being used to retrieve the image used in the product pages.
Let’s send this over to the Repeater for som testing.
Testing
Since we’ll be attempting a file traversal here, we should first try out the classic double-dot technique: ../
This is a technique we see often through Command-Line interfaces or while programming to traverse file directories.
Let’s give it a shot:
We can see that a couple of variations of this yield a 400 response.
Let’s test it again with the name of our file to make sure we aren’t missing anything.
Still nothing…
Let’s take a step back and remember the name of our lab. We can assume that non-recursive stripping is happening.
This means that the application is likely looking four our double-dot sequence and stripping it away.
But, since it is not looking recursively, that means it will not be checking again after removing the sequence.
This is exactly what we need to try.
Exploitation
Let’s piece together our attack: ….//etc/passwd
Since the double-dot sequence is getting removed, that means it will leave us with: ../etc/passwd
Perfect.
Let’s give it a shot.
Still nothing!!
But, believe it or not, this is actually expected.
We need to test out more sequences of ….// before our current payload since it’s unlikely our target file is just one folder up from our current location.
We need to keep stepping backward until we find it…
Three traversals looks like it was the correct amount we needed - lab solved!
What We’ve Learned
We’ve learned the importance of sanitizing user input in our web applications. Any time an applciation inherently trusts anything that a user can modify, we are setting ourself up for danger. We’ve also seen the importance of outside the box thinking here. “Non-recursive” was a clue staring us right in the face, and it took us a bit to realize that.
Want to give the lab a try yourself? You can check it out on PortSwigger’s website here.
Securely Yours,
The Cybersec Cafe
Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.
Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.
. . .
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!