Local File Inclusion (LFI) is a flaw that allows an attacker to disclose or execute files that are already present in the server of the application. By achieving this an attacker can potentially perform Path Traversal, Information Disclosure as well as Remote Code Execution vulnerabilities. In this blog, I wish to explain how this vulnerability can be exploited by malicious parties and also lay down the best mitigation steps to be followed.
Web pages sometimes receive user input as a file or directory name and whenever this user input is improperly sanitized, it can lead to various security vulnerabilities, one of which is the file path traversal (such as dot-dot slash). Through path traversal, an attacker can get arbitrary content to read/write on the file system using crafted requests. Enabling him/her to read sensitive information such as web.config. Any file upload or download functionality should therefore be properly validated.
Let us first understand how this vulnerability can be exploited. Below are the steps I followed when I unearthed this vulnerability in a client application.
Fetching sensitive information from server through LFI vulnerability
A look at the response upon upload or download of files from the server revealed that the file path was specified on the response which means an attacker can potentially download any files from the server by specifying the path in a request.
We found this in one of our client applications and observed that File download parameters are vulnerable to local file inclusion vulnerability.
I uploaded a JPEG file in our GRC based client application.
Snapshot 1: Downloading the recently uploaded file.
Upon trying to download the file, I was able to view the exact path of the file which is present in the server upon intercepting the request in the response.
Snapshot 2: The server will check if the file is present or not before downloading the file.
Next, I tampered with the download request and changed the file path to web.config instead of JPEG image path.
Snapshot 3: Upon tampering the file name to C:******Web.config in the strFile parameter in the request we’re able to confirm the presence of web.config file in the server.
By tampering the filename in the strFile parameter in the request, I was able to fetch the configuration details in the response.
Snapshot 4: Content of the web.config file are fetched through file download request.
We were able to download the web.config file from the file server by tampering with the strFile parameter in the request.
Snapshot 5: The evidence shows that the file gets downloaded successfully on the web page.
The impact of this vulnerability depends on the permissions granted by the web server. Based on these factors, attackers can leverage the vulnerability as mentioned below.
- Remotely executed commands may combine with other attack vectors such as File upload/Download or Injection attacks.
- Attacker can potentially gather sensitive information via /etc/passwd file.
Successful LFI attacks could result in exposure of sensitive information stored on the server. The best way to mitigate against the same could be to :
- Save the file paths in a database and assign an ID to each of them. By doing so, users only see the ID and are not able to view or change the path.
- Use a whitelist of filenames and ignore every other filename and path.
- Instead of including files on the web server, store their content in databases where possible.
- Instruct the server to automatically send download headers and not execute files in a specific directory such as /download/. That way you can point the user directly to the file on the server without having to write additional code for the download. An example link could look like:https://example.com/downloads/brochure.pdf
- Limit APIs to allow inclusion only from select app directories. So that any potential attack cannot perform a directory traversal attack.