Nmap Scan:
─$ cat nmapscan
# Nmap 7.92 scan initiated Sat Mar 4 00:55:39 2023 as: nmap -sCV -A -p22,80 -oN nmapscan 192.168.126.171
Nmap scan report for 192.168.126.171
Host is up (0.43s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 74:ba:20:23:89:92:62:02:9f:e7:3d:3b:83:d4:d9:6c (RSA)
| 256 54:8f:79:55:5a:b0:3a:69:5a:d5:72:39:64:fd:07:4e (ECDSA)
|_ 256 7f:5d:10:27:62:ba:75:e9:bc:c8:4f:e2:72:87:d4:e2 (ED25519)
80/tcp open http Apache httpd 2.4.38 ((Debian))
|_http-title: Surfing blog
|_http-server-header: Apache/2.4.38 (Debian)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Mar 4 00:55:51 2023 -- 1 IP address (1 host up) scanned in 12.43 seconds
Checking the web server on port shows this
Nothing really much there except 2 posts talking about surfing
I ran gobuster on it and found this
Going on to /administration shows a login page
Trying default/weak cred doesn't work
So i noticed the request in burp and saw a cookie which caught my attention
Cookie: auth_status=eydzdWNjZXNzJzonZmFsc2UnfQ==; PHPSESSID=ie6k33s7t2ahuop2kuqpcm2hc5
Decoding the cookie with base64 decode shows its value
┌──(mark㉿haxor)-[~/…/B2B/Pg/Practice/Surf]
└─$ echo eydzdWNjZXNzJzonZmFsc2UnfQ== | base64 -d
{'success':'false'}
I'll generate a new cookie and replace it with the request cookie
┌──(mark㉿haxor)-[~/…/B2B/Pg/Practice/Surf]
└─$ echo -n "{'success':'true'}" | base64
eydzdWNjZXNzJzondHJ1ZSd9
After poking around the web page i got this that we had just few access over some functions
We can create a user and exploit the customers list in form of a csv file
Trying to access the shell console gives an error
There's another function called check server status clicking it just shows that the server is running
Hmmmm lets intercept the request in burp and check what happens when we click the check button
Cool we see that its accessing the internal service
url=http://127.0.0.1:8080
Therefore this is a SSRF vulnerability
With SSRF (Server Side Request Forgery) we can access internal service running on the target
But when i try accessing internal resource i don't really get an output
Lets check if it can reach our host
I'll set a listener on port 80 then try to access it
After forwarding the request i get a connection back on my listener
Out of curiosity i fuzzed for internal ports to know if maybe theres another web server running except the one on port 8080
Only 2 web server running on the target
Anyways if you notice what the check said
It refers to phpfusion
Searching google for it shows an exploit
What basically is happening is that its running system on base64_decode(payload)
Where the payload is a base64 encoded value
We can't run this on the remote server since we can't access it directly
So i'll just do it manually and take advantage of the ssrf to run system command
Firstly to confirm if it works i'll generate a base64 encoded value to send icmp request to me which i'll then capture using tcpdump
Then i'll url encode the payload
With this i will send it to the target
Back on tcpdump we get icmp packets flowing
Now i'll repeat the same process but this time we need to get shell 🐚
But note that from the exploit code
# !!spaces are important in order to avoid ==!!
So we need to add space if we get ==
from our generated payload
I used curl as its more efficient rather than us url encoding stuffs smh
Lets stabilize our shell
python3 -c "import pty; pty.spawn('/bin/bash')"
export TERM=xterm
CTRL +Z
stty raw -echo;fg
reset
Only one user on the box
www-data@Surf:/tmp$ ls -l /home
total 4
drwxr-xr-x 2 james james 4096 Nov 9 2021 james
www-data@Surf:/tmp$
Looking around the web app files i got this
But unfortunately i couldn't brute force it
So looking over the other web directory i got another config file
Trying it to switch as user james with password FlyToTheMoon213!
works
Lets get root 🤓
Running sudo -l
shows the user james
can run php /var/backups/database-backup.php
as user root
Checking the perm shows that user www-data owns it
So if we are user www-data we can replace it to something else then run it sweet
I'll exit my shell to land as user www-data then change its content to change the permission of /bin/bash
to a suid
binary
And we're done 👻