Hello friends, today I will show you the steps of detecting a vulnerability that I encountered in Web Application Security Tests in my project named Saka Local File Inclusion (Null Byte)and exploiting this vulnerability.
What’s Local File Inclusion
You can find detailed information about the LFI vulnerability in the article below.
Running the Application
Docker
docker pull erdemstar/saka:local-file-inclusion-null-byte
docker run --rm -d -p 80:8080 erdemstar/saka:local-file-inclusion-null-byteVisual Studio 2022 IDE
git clone https://github.com/Erdemstar/Saka
cd Saka/local-file-inclusion-null-byte
- mouse local-file-inclusion-null-byte
- devenv local-file-inclusion-null-byte (CMD)Reconnaissance
When we first open the application, a page like the one below welcomes us. By pressing the Attack button on the page, we are directed to the part we will test.
The page encountered when redirected to the Attack page is as follows.
The HTTP GET request sent for the Attack page is as follows. When the details of the incoming response are checked, the application receives the ‘filename’ information via the GET request. When redirected to the Attack page via the menu, the “filename” information is “sample” by default.
The response shows the content of the received file and the path information on the OS. Finally, the application creates a list to show the user other files it has.
Below, a request has been sent to obtain the content of the file named “Sample 2” via the “a” tag.
The result obtained is as follows.
It has been observed that in the first and second requests, only the file name is included in the “filename” information provided by the user in the Querystring, and no extension information is provided.
When the response contents obtained are checked, the application performs the file reading operation by adding the “.txt” extension to the filename information it receives from outside.
Client -> filename=sample | Server -> filename=sample.txt
Client -> filename=erdemstar | Server -> filename=erdemstar.txtMental Notes
- The application expects the QueryString information named “filename” from the user for the “/Home/Attack” page to display the file contents it has. By default, this value is “filename=sample”
- The application adds the “.txt” extension to the end of the file name it receives from the user.
- The application displays the file name it receives from the user as the file path via the OS and includes the relevant file content in the response.
- The physical path of the files shown on the UI via OS is “wwwroot/files/”.
Exploitation
After obtaining sufficient information on the application, the LFI vulnerability will be checked to ensure that the application can read files other than expected.
Before starting the work, since the target application was developed with Dotnet and runs on Docker, the Code Structure and Folders will be similar to the one below.
Here, no LFI payload is used as a reference since the target application and technology are known.
After obtaining sufficient information about the application and the technology used, the aim is to read the “web.config” and “appsettings.json” files. It has been observed that when these file names are given directly as “Filename”, a “Not Found” error is given.
Considering that these files are not in the current path, the relevant files were searched in the upper directories using the “../” pattern, which marks the upper directory in Linux and Windows.
The result for “web.config” is as follows.
The result for “appsettings.json” is as follows.
In order to read the “web.config” and “appsettings.json” files, the “../” pattern is added to the requests and a valid OS Path is created. When the obtained responses are checked, the application receives the “file is not exists” error because the “.txt” extension is added to the “filename” information provided by the user.
In the first stage, the expression “../” was added to read files in different directories. In order to get rid of the “.txt” extension added to the end of the filename parameter by the application, the requests were recreated by adding the Null Byte character “%00” to the end of the filename part of the requests.
The result for “web.config” is as follows.
The result for “appsettings.json” is as follows.
When the obtained results were checked, it was observed that the requests made using the Null Byte character “.txt” extension added by the application were invalid, and it was determined that a valid path within the OS was given to the “filename” field and the file content was read successfully.
After the vulnerability was detected, the main purpose was to read sensitive data on the application, so the “/etc/passwd” “/etc/shadow” files below were read successfully.
The result obtained for “/etc/passwd” is as follows.
The result obtained for “/etc/shadow” is as follows.
Since the target application runs with root privileges in the container, the content of the shadow file was easily read. In some scenarios, reading a file that any user can read, such as /etc/hosts, instead of /etc/shadow, may be useful when detecting the LFI vulnerability.
Thank you for reading my article, I hope it was useful for you. Below I leave the links of my other concepts that may be useful to you.
Click here to see my other articles about web vulnerabilities. Link
