Oouch HTB writeup

Oouch is one of the hard (close to Insane) boxes that will give you a lot of fun but also tons of frustration with a big dose of new technologies and web techniques. Prepare to study, investigate and get fun.

Enum

Port scans

As with every box, first is to execute some Nmap to discover open ports and execute basic script against those.

After initial enumeration I've found out -T5 with Nmap missed a port, so built a script to enumerate ports with netcat. Here are the results with a new port (5000) discovered

Web fuzzing

The main website at port 8000 didn't have any valid response, just server error. So executed a fuzzer to discover vhosts on the server.

Discovered a vhost called authorization, then fuzzed it to discover other internal paths and files a unauthenticated and then with an authenticated cookie.

FTP

Nmap gave as an FTP port opened with anonymous enabled, on the FTP there was only a file called project.txt with the following contents.

This gave us an idea of what the server is running and what could be the vhosts names

  • authorization.oouch.htb

  • consumer.oouch.htb

Abusing Oauth for foothold

Once tried some user creation, login, authorizations, etc. I understood the behaviour and the technology behind all of this, in this case was Oauth2. This box gave me the opportunity to study this technology with some blogs and an Udemy course.

One of the blogs I've found was this, were the author explains how could possibly get other's account in an miscofigured Oauth implementation: https://dhavalkapil.com/blogs/Attacking-the-OAuth-Protocol/

qtc user on consumer

The whole process to steal a user session was:

On the /Documents path there was this juicy information.

Now we have to steal the cookie of qtc user on authorization.

qtc on authorization via SSRF

Next step is to create a client app at http://authorization.oouch.htb:8000/oauth/applications/register with the login found on the documents.

  • Use authorization_code as client type

  • Redirect url should be pointing to your netcat listener (http://1.2.3.4:4443)

Craft an auth request with the client_id, client_secret and redirect_url created in the client.

Then send the auth request on the contact form again and wait ~30 seconds with your netcat listening on the correct port

Once qtc clicks the link, will attempt to authorize in our client and get redirected to us, here we can steal his cookie on authorization.

Now we can login as qtc on authorization with that cookie, change it on the browser or add it as header Cookie: sessionid=<COOKIE> in curl or python.

At this point we create a new client app as with type client_credentials.

Then we get a token on the new client to get a new valid token.

Once we have a token and a cookie on authorization, get can get ssh information about qtc user, as Chris mentioned in the /documentation, copy the ssh_key into a file.

The ssh key have \n as strings instead of parsed as real jump lines, so lets' replace it to fix the ssh private key syntax.

Set proper permissions to the key and connect to the box with qtc user.

Local enumeration

First thing we see once we connect is .note.txt inside qtc's $HOME directory.

This file contents are really important as is the base information we need to do all the privesc process.

We noticed docker is running and there are some neighbours in the net aka containers running with those IPs.

Try to connect through ssh to them, one of them will work

Getting www-data

Inside the container, after full enumeration we end up focusing on /code directory

Abusing uwsgi

Here we can see all the consumer app code. For now, we focus on uwsgi configuration, which have open permissions on the unix socket under /tmp

After some google fu research, found this python exploit to take advance of the wsgi socket.

https://github.com/wofeiwo/webcgi-exploits/blob/master/python/uwsgi_exp.py

The exploit needs to be fixed for python3 compatibility, change sz function as follows:

This container does not have netcat, wget or curl installed. You could use ftp or as I did, encode the exploit as base64 in your host and decode inside the box.

This will give us a shell as www-data on the container.

Root

During previous enumeration on /code and some code review, we saw what .note.txt said about dbus.

Abusing DBUS

This is a excerpt of the vulnerable implementation found at /code/oouch/.

Found a similar exploit for a different application abusing dbus and got the proper syntax to exploit ours app. https://www.exploit-db.com/exploits/46186

At this point, open another netcat listener and send a message to dbus with a reverse shell payload pointing to your listener.

Now we got root on oouch.htb box.

This box was specially fun and frustrating, made me learn Oauth and investigate about dbus and uwsgi. Also good practice for csrf and ssrf techniques. Hope you enjoyed the whole process.

Last updated

Was this helpful?