MagicGardens

Recon

nmap_scan.log

Add host

HTTP (80)

Seems to be hosting normal app

Writeup.png

We can register so might as well, Creds: test02:test02@magicgardens.htb:test02

We seem to be dealing with Python application

Writeup-1.png

We are given a weird sessionid token, it consists of 3 parts: django_session:something:something_else

Note: How to decode Django sessionarrow-up-right

App is just like any regular store. What's odd is that we can buy and it says Success, we didn't setup any payment process or anything...

Payment

If we take a look at our profile we can find Subscription. Quick hover over banks gives us domains

Writeup-2.png

Looks like we are unable to upgrade. Looking into the request bank variable is domain, meaning we could slip in our own server

Writeup-3.png

Premium

After some playing around with API it seemed like request should have had Content-Type of x-www-form-urlencoded, but it kept failing. Switching to get_json made the app respond in correct way. Also in the API request we see it returns status key which should indicate if our request was successful or not, modify the value and send it back.

Writeup-4.png

Note: New user created test03

After we buy a product and after some time we get a message in inbox

Writeup-5.png

Decode QR, https://qrcode-decoder.com:

Writeup-6.png

Try XSS via QR code:

Writeup-7.png

Change cookie and login as Morty.

Writeup-8.png

Since Morty is admin we can access the Django admin panel on /admin

Writeup-9.png

Get password

Writeup-10.png

SSH (21)

Using creds from Django we can SSH into the box.

Creds: morty:jonasbrothers

Get connections

Get processes

First docker containers caught my eye and it seems like port 5000 is exposed.

Looks like RustScan missed this port. 5000 - Pentesting Docker Registryarrow-up-right

Morty doesn't seem to have access on docker

Harvest

There's another user on system alex and he has interesting program running

Writeup-11.png

I wasn't able to find the program, so it must be closed source.

server mode fails due to raw socket fail because it should be ran with admin privileges. If client if forcefully disconnected the log file is not created.Writeup-12.png

I think we are interested into the handle_raw_packets function

Writeup-13.png

The log packet copies over the presumably log name, opens it and writes buffer to it.

Since the program doesn't have Canary enabled, it smells like Buffer Overflow. Specifically if we can write to files somehow.

Start processes:

openbsd/src/sys/sys/socket.harrow-up-right

Writeup-14.png

Almost all socket calls are IPv4/TCP, but I wasn't able to get it to log into the file.

Testing IPv4/TCP returns [x] Handshake error

Testing IPv4/UDP returns nothing

Testing IPv6/TCP returns ConnectionRefusedError: [Errno 111] Connection refused

Testing IPv6/UDP returns [!] Suspicious activity. Packages have been logged.

So to introduce the buffer overflow we should send IPv6/UDP packet.

Buffer Overflow

After some manual testing with Starting Server, Starting Client, Attaching strace, Filtering For openat with fuzzer:

The output file is overwritten with our content and offset is 65372

Privilege Escalation (alex)

Create ssh key:

User.txt

SMTP (25)

The SMTP port is filtered on outside, but since we are inside we can take a look

Attachment is a zip file

Crack the password:

Note: If you're passing john's hash to hashcat remove the filename. e.g.: auth.zip/htpasswd:

Unzip and see contents

Crack the hash again

Note: For some reason my Windows Hashcat instance cannot crack bcrypt, so that's why john is used.

Creds: AlexMiles:diamonds

Docker (5000)

The cracked password doesn't work on SSH. Other common service we saw with ss was docker, we could try enumerating the service.

Hacktricks, 5000 - Pentesting Docker Registryarrow-up-right

The app is frontend app which was exploited, since alex has access there should be more we can do with it.

This build didn't have the complete application, after going through few hashes b0c11cc482abe59dbeea1133c92720f7a3feca9c837d75fd76936b1c6243938c had full source.

The Django app is well written and doesn't seem to have any bugs except previous exploit. Since the session token was a little odd on server I looked into server settings

Python pickle module is prone to deserialization attack, with SECRET_KEY we can forge tokens and get RCE on container.

Note: The exploit script needs to be placed in Django project so it has access to apps.

Edit your cookie on website and catch a shell

Get capabilities of container:

Docker Breakout

Hacktricks, Docker Breakout / Privilege Escalationarrow-up-rightHacktricks, Linux Capabilitiesarrow-up-right

Not sure why, but getcap wasn't giving any output. After going through the list I noticed we have CAP_SYS_MODULE so I followed the guide to use kmod and it worked.

I named reverse shell r.c for short and changed output name to r.o

Writeup-15.png

Note: Make sure to change spaces to tabs as specified in guide! Copy/Paste will use spaces from web.

Root.txt


Writeup referenced:https://cn-sec.com/archives/2768793.htmlarrow-up-right

Root exploit 2:https://writeup.raunak-neupane.com.np/hackthebox-seasons/season-5-anomalies/magicgardensarrow-up-righthttps://darkwing.moe/2024/05/21/MagicGardens-HackTheBox/arrow-up-right

Last updated