Introduction
Hello everyone, during one of the penetration testing assessments, we faced Amano Xparc parking solution web application. While conducting the assessment we discovered multiple vulnerabilities and we submitted it to https://cve.mitre.org/. For your reference the links for the other CVEs blogs:
- SQL injection CVE-2023–23331: https://0xhunter20.medium.com/how-i-found-my-first-blind-sql-injection-cve-2023-23331-aef103a7f73c
Today I will be demonstrating CVE-2023–23330.
Vulnerability Details
- Vulnerable Software: Amano Xoffice parking solutions
- Vulnerability: Local File Inclusion
- Affected Version: 7.1 (7.1.3879)
- Vendor Homepage:https://www.amano.eu/en/
- CVE: CVE-2023–23330
What is Local File Inclusion (LFI)?
“Local file inclusion (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application”
- OWASP
To simplify things, LFI is a vulnerability that abuses a flaw when a server tries to include a file. The idea is to let the include unattended files such as system files or non-published documents.
Why LFI is there? and how to prevent it.
It occurs due to the use of user input without validation.
Preventing LFI could be done by considering the following:
- Avoid passing user-submitted input to the system.
- Whitelist files that can be included.
- Reject un-defined/Whitelisted document.
- Do not permit file paths to be appended directly make them hard-coded.
- Use databases instead of filesystems. Either to store the files in the database or store the file path in the database.
CVE Demo
While exploring the website manually, I noticed a page to download the user manual and guide. I intercepted the request in burp so I can use Burp repeater for easier request manipulation. The image below shows the parameter and user manual file:
So, clearly, the “file” parameter in the GET request is responsible for specifying the file name. interesting…
Let’s try to change the file name to “/etc/passwd” which is a default file in Linux/Unix servers and readable by all users. The image below shows the try to inject “/etc/passwd”:
So, it didn’t work directly, as the error shows in the HTTP response the file “../manuals/etc/passwd” was not found.
No Problem!
Instead of using the absolute path of “/etc/passwd” we will use the relative path. In file systems to get a file there are two main ways “absolute” or “relative”.
Now let’s fuzz the relative path to know what is the depth of the file. We can use Burp intruder, python scripts, or manually in Burp repeater. The image below shows the first try with a depth of 2 manually in the Burp repeater:
Didn’t work, let’s try depth 3
It worked!
We were able to include a file from the system without any validation.
The question now is, how to abuse that?
There are multiple ways to exploit this and gain more. Each case or scenario has its own way to go further. However, I may suggest looking into:
- Config files & Source code: most of the time DB credentials, API tokens …etc. Are stored in clear-text format either in Config files or source code.
- Well-Known files: You may try to access well-known files such as Shadow file, log files, bash history, SSH keys …etc.
For the sake of knowledge, let’s try an example of a source code and SSH key.
Acknowledgment:
I would like to thank the teammates: Fahad Almulhim (0xHunter) and Osama Aldosari. Also, many thanks to the Saudi information and technology company — SITE for their continuous support.
References:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-23330
- https://0xhunter20.medium.com/how-i-found-my-first-blind-sql-injection-cve-2023-23331-aef103a7f73c
- https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion
