HackTheBox - Joker
Last updated
Was this helpful?
Last updated
Was this helpful?
Looks like there are just these two ports opened. We know about SSH and there is a http proxy running on port 3128. This proxy is widely used for filtering web requests. You can set it up for your own network if you want.
Squid is a caching and forwarding HTTP web proxy. It has a wide variety of uses, including speeding up a web server by caching repeated requests, caching web, DNS and other computer network lookups for a group of people sharing network resources, and aiding security by filtering traffic.
This is the proxy running on 3128 and we need the access the webserver present behind. I will be using Foxy Proxy to create the proxy.
Now if we try to access the webserver, we will get the following error saying Sorry, you are not currently allowed to request http://10.10.10.21/ from this cache until you have authenticated yourself.
I tried default usernames and passwords but that didn't work. So let's proceed with the UDP port scan that we kept running the background.
This will download the squid.conf file from the target server and stored it in /tmp/squid.conf
Password file located in /etc/squid/ .Let's get that file using the same method.
Now that we have the password, we can surf the webserver with these credentials. Save the username and password in the Foxy Proxy settings. We can also access localhost now.
OK now we have Werkzeug console where we can potentially run system commands or even get a reverse shell.
Since this is not the best debugging environment, Werkzeug provides a WSGI middleware that renders nice tracebacks, optionally with an interactive debug console to execute code in any frame. ... Danger. The debugger allows the execution of arbitrary code which makes it a major security risk.
I tried getting reverse shell but the server didn't respond after that and I had to reset the machine to get it working again. So I eventually checked for iptables config for IPv4.
So by looking at this, I realized that the network will DROP all the outgoing packets. We have udp in scope where we can try to get shell via UDP. I found this trick that is much more easy to understand.
sudoedit will use the nano editor to edit/modify the file given as an argument. We can leverage this by creating a symlink to a file which is neither readable or writable by us. In this machine, we will write our SSH public key to alekos account by exploiting this vulnerability.
And we will write the SSH Public key to that file and save it. Now if you will check, our contents will get successfully added into authorized_keys file.
First method will be to use Normal Tar Wildcard Injection.
A cron job is running every 5 minutes backing up all the files in development directory to backup directory.
Now what this thing will do is pass the --checkpoint-action=exec=sh shell.sh and --checkpoint=1 as an argument to tar command, thus resulting into execution of shell.sh file.
Another way is to use symlink again but this time to link it to root directory. Move the development directory to some other place and create a file having a symlink to root directory.
Now here the tar file will contain everything from the root directory. Isn't that awesome :))
Notice the difference in sizes that means our exploit worked.
The file server doesn't require authentication that means we can just download or upload. I will use module written in python to enumerate the service. We need squid.conf to get all the details about the cache server.
There is local privilege escalation vulnerability in sudoedit. We can check the version of sudoedit using dpkg command. Read more about the vulnerability over .
