Local File Inclusion and Path Traversal Attacks
Find Exploit Impact
Finding LFI
LFI (Local File Inclusion) and Path Traversal are technically two different issues. LFI has the ability to execute files, which could be shell code or another local file that exists on the system. On the other hand, Directory Traversal can only access files; it can’t execute them. This type of issue is generally considered Sensitive Information Disclosure. For simplicity, I'll refer to both issues as LFI.
When analyzing a site for LFI vulnerabilities, I focus on a few key things:
Images and Files:
Right-click on an image and select 'Copy image location'.
Paste the URL into a new tab (e.g.,
www.example.com/assets/images/home/404-img.svg).Try tampering with the image location (e.g.,
/assets/images/home/../../../../../../etc/passwd).
Research has shown that certain parameters are more likely to be associated with LFI vulnerabilities.
- Using a tool like HUNT can help streamline the testing process, as it has built-in detection for common LFI parameters.
-
The idea behind this project is that certain common parameters often indicate that the server is drawing from a local file. It’s worth manually testing any parameter that matches these patterns. Of course, the list is not exhaustive, so it’s important to use your own judgment to discover additional patterns. Pay close attention to JavaScript files as well—sometimes, you may not identify a vulnerable endpoint through passive browsing, but a code review could reveal the vulnerable path. Example LFI writeup
Examples
"file=",
"document=",
"folder=",
"root=",
"path=",
"pg=",
"style=",
"pdf=",
"template=",
"php_path=",
"doc=",
"page="
Screenshot or export Mechanisms:
The thought over here is that the mechanism which is taking a screenshot of the page or exporting the page may be taking a file reference as an argument to the service.
Secondary Context - Middleware Routing Path Traversal:
I first read about this topic in Sam Curry's post about hacking Starbucks. The idea is really neat and makes a lot of sense once you get your head around the basic understanding of how middleware and routing work in the modern web context. To try and summarize in just a few sentences:
When I send a request to /api/v1/user/1 The middleware (proxy) server extracts the route, which for example could be /api/v1/user and identifies that route with api.internalcompany.com:3031/api/v1/user. Now one way to take advantage of this is by traversing the secondary context (api.internalcomany.com:3031) and trying to access the web root and identify other methods and endpoints accessible to our user.
Our request might look as follows:
GET /api/v1/users/1/../../../<FUZZ>
Host: example.com
Our requests get sent by the proxy to the internal API which reads the requests as
GET /
Host:api.internalcompany.com
Notice This is a direct call to the web root. From here we are hoping to for several things. Sam puts it best so I'll quote
Data is being served across extra layers Introduces translation issues like HTTP request smuggling CRLF injection in weird places
Developers do not expect users to be able to control parameters/paths Functionality you would normally see in a development environment is accessible (?debug=1, /server-status)
Information disclosure Internal HTTP headers, access token
SSRF and XSS via manipulating response content Finding an open redirect in 2nd context = server issuing/potentially rendering arbitrary request
Try to detect routing
/bff/proxy/orchestra/get-user/..%2f
/bff/proxy/orchestra/get-user/..;/
/bff/proxy/orchestra/get-user/../
/bff/proxy/orchestra/get-user/..%00/
/bff/proxy/orchestra/get-user/..%0d/
/bff/proxy/orchestra/get-user/..%5c
/bff/proxy/orchestra/get-user/..\
/bff/proxy/orchestra/get-user/..%ff/
/bff/proxy/orchestra/get-user/%2e%2e%2f
/bff/proxy/orchestra/get-user/.%2e/
/bff/proxy/orchestra/get-user/%3f (?)
/bff/proxy/orchestra/get-user/%26 (&)
/bff/proxy/orchestra/get-user/%23 (#)
The Challenge
The Discovery of LFI
The discovery of an LFI vulnerability depends on several factors:
OS Dependent: Is the target system running Windows or Linux?
File Location: Simply inserting
/etc/passwdwon’t be helpful if the location requires something like../../../../../../../../etc/passwd.Filters in Place: You’ll need patience and persistence to bypass any filters that may be in place.
The payloads you use will be OS-dependent. There are many wordlists available that provide paths for both Windows and Linux. Additionally, Burp extensions like Agartha or psychoPATH can be helpful. Proper use of these tools should ideally lead you to either the correct path to the webroot (e.g., /var/www/html/) or other accessible system files (e.g., log files or files containing sensitive data).
TL;DR Don’t jump to /etc/passwd
Avoid Jumping to /etc/passwd
When you suspect a path traversal vulnerability, it can be tempting to jump straight to exploiting /etc/passwd. However, attempting this immediately could trigger alerts, be blocked by intrusion detection systems, or fail due to path normalization that you may not fully understand yet. This could lead you to mistakenly believe the vulnerability doesn’t exist, even though it's simply being stopped by security filters or additional validation measures.
Taking Incremental Steps
A more effective approach is to start with something simpler, like test/../test/1234, if you have access to /test/1234. While this might not confirm a full traversal issue, if it isn’t blocked, you’ll learn that path components like ../ aren’t completely restricted. From there, you can try progressively more complex paths, such as another_directory/../test/1234. Each successful attempt provides valuable insight into how the application handles file paths, helping you determine if a more significant exploit might eventually succeed.
Finding Public Research Tips
I often will browse Twitter for people's discoveries. LFI bypass has led me to some very nice bypasses.
Bypass (NGINX)
//////////////////../../../../../../../../etc/passwd
../../../../../etc/notexists/../passwd
Other Bypasses
→ ...//....//....//etc/passwd
→ %252f..%252f..%252fetc/passwd
→ ../../../etc/passwd%00.png
Recently I went through @Hussein98D slides from his talk at BSides and I wanted to highlight a few of his tips
Of course, these are only a couple of examples and the list is truly endless.
Impact
Path traversal can be highly effective in a Local File Inclusion (LFI) scenario, especially when you have the opportunity to upload a file to the server and create a web shell for greater impact. In this scenario, there are two main options:
Upload a Shell to the Webroot: This will make the shell directly accessible from the website or browser.
Log Poisoning: There are many different approaches to log poisoning. The key is to accurately fingerprint the server technology being used. For example, there's no point in uploading a PHP shell if the server isn't running PHP.
Additionally, you can use LFI to read sensitive data from default directories on the server.
/proc/sched_debug
/proc/mounts
/proc/net/arp
/proc/net/route
/proc/net/tcp
/proc/net/udp
/proc/net/fib_trie
/proc/version
/proc/self/environ
/root/.ssh/id_rsa
/root/.ssh/id_rsa_pub
/root/.ssh/authorized_keys
