What is Local File Inclusion (LFI) and Log Poisoning ?
So, there’s this thing called LFI (Local File Inclusion) vulnerability that hackers can exploit to access and run files on a server. Basically, if the server doesn’t check user input properly, the hacker can mess with file paths and directories and get into stuff they shouldn’t. This can lead to all kinds of bad stuff, like stealing data, taking control of the system, and running code from far away. Not good.
Log Poisoning is a sneaky attack where hackers inject bad stuff into log files. It’s like hiding a secret message in plain sight! By doing this, they can sneak past security measures and do all kinds of bad stuff, like running secret code, stealing data, and getting access to important info.
The Story
A bug hunter called Medusa, has discovered a vulnerability in a web application that utilizes PHP as its backend language. The vulnerability founded with unique exploit technique called Log Poisoning, It has been discovered by a security researcher that could result in RCE by leveraging LFI vulnerability.
The report discusses a web application that uses PHP as its backend language. Although the whole process can be performed using Burp, the author will use cUrl to send and receive responses and manipulate requests. The server is Nginx and the backend programming language is PHP.
Local File Inclusion (LFI) is a very common web application vulnerability, and it allows attackers to read sensitive files on the server. In some cases, even execute remote commands. This happens when input is not validated properly, or code is written poorly.
In this case, the web application contains a cookie named PHPSESSID, and its value is encoded in base64. After decoding the base64 value of the cookie, a serialized string is found.
The string contains some complex arrays with elements of more than one data type, so PHP uses a function called searealize() to convert them into a formatted string. The decoded cookie data points to an index.html path. By modifying the path to something else, any file present on the server that leads to LFI can be included.
The modified path is encoded to base64 and sent to the application. The command used is “O:9:”PageModel”:1:{s:4:”file”;s:22:”../../../../etc/passwd”;}”. The passwd file confirms LFI vulnerability in this application.
Log Poisoning is a technique that allows the attacker to tamper with the log file contents. The log file contains all the activities that have been performed while communicating with the web server. The activities such as files that were accessed, status codes, user-agent, location, IP, etc. Log poisoning is only effective when the application is already vulnerable to LFI.
In this case, the PHP code includes file index.html from the include statement without proper input validation. So the inclusion of a malformed file would be evaluated. If the contents of a file available on the vulnerable web application can be controlled, PHP code can be inserted and loaded over the LFI vulnerability to execute the attacker’s code.
The contents that can be controlled are the logs that are sent to the server. In this case, the server is Nginx, so the default path for logs is /var/log/nginx/access.log, which may differ according to different servers. The following string is used to encode and send the logs to the server: “O:9:”PageModel”:1:{s:4:”file”;s:25:”/var/log/nginx/access.log“;}.”
Remote Code Execution (RCE) vulnerability allows an attacker to execute commands remotely on the victim system. The User-Agent header is logged, and it is possible to change its value to a malicious PHP code and send it to the server.
The PHP function system() accepts a command as a parameter and displays its result as output. After the request is sent, the PHP code is logged into the system and executed once the access.log file is visited. The following command is used to perform this action: “curl -i -v {URL} -A “<?php system(‘ls /’); ?>”“.
It is essential to note that this vulnerability can be prevented by input validation and proper code writing. The use of Burp or cUrl to manipulate and send requests can help identify vulnerabilities that may have gone undetected otherwise because the vulnerability of LFI (Local File Inclusion) and Log Poisoning can be a significant threat to the security of a web application.
How to Prevent LFI Vulnerability?
Preventing Local File Inclusion (LFI) and log poisoning vulnerabilities is crucial for securing your web application. To achieve this, consider taking the following steps:
- Sanitize user input: It’s essential to sanitize all user input to prevent malicious code injection that can be used to exploit LFI vulnerabilities. Use secure coding practices, such as input validation and output encoding, to prevent log poisoning.
- Implement access controls: Restrict access to sensitive files and directories on the server by using file permissions, firewalls, and network security protocols. This can help prevent unauthorized access and data breaches.
- Use a web application firewall (WAF): A WAF can detect and prevent LFI and log poisoning attacks by analyzing incoming traffic and filtering out malicious requests.
- Monitor log files: Regularly check log files for suspicious activity, such as unusual file access or user behavior. Take appropriate action if any suspicious activity is detected, such as blocking IP addresses or suspending user accounts.
- Keep software up-to-date: Ensure that all software and applications are regularly updated with the latest security patches and updates to prevent vulnerabilities from being exploited.
By following these steps, you can effectively prevent LFI and log poisoning vulnerabilities and ensure that your application remains secure. Remember to regularly review and update your security measures to stay ahead of evolving threats.
Overall, preventing LFI and log poisoning vulnerabilities is essential for maintaining the security and integrity of your web application. By implementing these steps and staying vigilant, you can protect your application from malicious attacks and safeguard your users’ data.
Link to read full write up: here
Save the PDF here
