HackTheBox Oouch Writeup –

Hello, welcome back :), Here is the writeup of HackTheBox Oouch machine ( The Oouch Linux box by qtc released on Feb 29th, 2020 with the difficulty level “Hard“.


The machine is all about Enumeration, XSS vulnerability and gaining foothold by stealing web application tokens and APIs etc. An Oauth2 authentication protocol exploitation is major foothold for this machine, exploit the Oauth2 and stole Admin session cookie.

HackTheBox Oouch Writeup –

Let us start.


As always, I update my hosts file with machine IP as oouch.htb and proceed for intense NMAP scan.

As per the NAMP scan, FTP port 21 is open with anonymous access allowed, SSH at port 22, TCP ports 5000 and 8000 are open.

The FTP is hosting a text file “project.txt“, I download the file to my local machine and it seems like the text file contains the name of the servers.

Web Services

The port 8000 throws bad request (400) error, while the port 5000 opened up a login page. The page has an option to register and login. I registered myself and logged in successfully to a web application “Oouch”. However, there is nothing much interesting.

User Profile Page after registration

What caught my attention was CSRF Token in login page, but decided to look at it later and move forward. A WFUZZ fuzzing on http://oouch.htb:5000/FUZZ showed a new directory “oauth”.

Upon visiting the newly discovered page, I found “OAuth Endpoint” of the application. Two links were found:

  • http://consumer.oouch.htb:5000/oauth/connect
  • http://consumer.oouch.htb:5000/oauth/login

The projects.txt file downloaded from shows there are two services running, I need to find the hosts. As you know NAMP comes with an option to discover hosts. I’m going to run it in next step.

Searching For Virtual Hosts (vHosts)

I modified the command to add the file I downloaded from FTP as my arguments.

I found two new virtual hosts. I added them to my hosts file.

Upon visiting the website on http://authorization.oouch.htb:8000/ I found a new web app “Oouch – The Simple and Secure Authorization Server” which is some kind of authorization server based on authorization server based on the Oauth2 protocol. From the description it looks like the Server being used as SSO for the web applications.

After enumerating and finding different services, I understood that, as per the file project.txt found in FTP, the services on http://consumer.oouch.htb:5000/ is based on the Flask and the service http://authorization.oouch.htb:8000/ is running on Django framework.

I tried to log in using the credentials I created early, but didn’t work. There is another sign-up option, so I proceed to register myself as OouchNS1 and logged-in to test.

After logging in with new credentials, I noticed two options (endpoints as they were called by the author). The /OAuth/authorize) throws Error: invalid_request error while the token shows a blank page.

I try to open applications: http://authorization.oouch.htb:8000/oauth/applications but it requires credential.

The other directories I found was http://authorization.oouch.htb:8000/oauth/token/, which I previously tested it.


The webpage seemed dead-end as I couldn’t enumerate more, so I decided to find hidden directories of the application using WFUZZ.


While the WFUZZ fuzzing is continued in the background I started to look in to the directories found already.


While I was enumerating http://oouch.htb:5000/login I found the http://consumer.oouch.htb:5000/oauth/connect was calling.

And this where I’m now:

The below is the sequence when a user authorized to log in using OAuth2 token. I capture the process using burp to see what’s going in the background.



As I started to reading about Exploiting and Bypassing OAuth2 authentication, I found few report in HackerOne that shows the way to steal OAuth Tokens.

Going further, I noticed a couple of users mentioned that a form in user profile can be used as XSS. The only form I found was http://consumer.oouch.htb:5000/contact.

Whatever you send you get the below message;

I tried to do some nasty XSS, and I was Immediately blocked for Hacking Attempt, the WFA is blocking anything it detected not normal request. However, it has been noticed by one of team member that WFA filter is “Capitalized letter”

After spending hours on Google and articles related to OAuth2, I come across with this article: . As mentioned by the author; I’m going to perform Cross-Site Request Forgery (CSRF) attack on the application and see if I’ll be able to exploit it and gain access to Admin account. .

As I understand its is possible to steal OAuth token, I started to look for reports from HackerOne and Google. I found following few articles I could use as references.

Admin Account Takeover Using Stolen OAuth2 Authorization Token

Token: /oauth/connect/token?code=yJQVFf95neXeBlLpgL7VYDRlFiQKnu

STEP 1 – I open the page http://consumer.oouch.htb:5000/oauth/connect and fire up the Burp Suite and prepared my intercept.

The consumer.oouch.htb:5000/oauth/connect page authorized users

I was redirected to Sign-in page: http://consumer.oouch.htb:5000/login

And here I’m logged in as QTC AKA Administrator. However, there is nothing much admin stuff but the Documents section has some useful information.

There is a credential: develop:supermegasecureklarabubu123!

In my first WFUZZ fuzzing I found a couple of hidden directories /oauth/applications/ and /oauth/applications/register, I used the credentials found in QTC directory Application but it didn’t accept, however the login form in applications/register was successfully logged in.

There is a Registration form with pre-existing Client ID and Client Secret, I filled the rest fields and saved it.

I tried a lot before making a final payload. This payload is going to be run in the http://oouch.htb:5000/contact. I set up my listener with fingers crossed and hoping to get the call back.

My final working payload:

Yessssss……, I got the call back in my listener after waiting for few moments:

I now have the Session ID cookie I was looking for. I went on fired up Burp and load the page http://authorization.oouch.htb:8000/ from browser and intercept the request and replaced Session ID cookie with admin’s Cookie and forward it.

Boom, I’m logged in as QTC.

Obtaining The Access Token

As soon as I’m logged-in as QTC, the next step is to get Access Token from QTC. The Access token is generated from this https://www.oauth.com/oauth2-servers/access-tokens/ URL, however direct access is blocked and I got invalid access error, so I tried with cURL.

Getting API using The Access Token and Obtaining SSH Key:

Intercept the request using Burp and add the access token I obtained in previous step and forward the request.

Here is the SSH key after a couple of forwards.

Getting User.txt

After fixing the SSH key, I add it to my .ssh/id_rsa and open the terminal and ssh the box as qtc. I got logged-in and I obtained the user.txt immediately.

On To The Next One – Privilege Escalation

Upon checking hidden directories and folders inside the QTC directory, I found a hidden text file .note.txt, it says “Implementing an IPS using DBus and iptables == Genius?”

A show process monitoring command showed some interesting things running.

Docker Services:

Internal Docker IPs:

From the .note found in the QTC directory it is confirmed that DBus Server is running. So I decided to find more about it before I proceed.

As per this DBus documentation, the configuration file can be found here: /etc/dbus-1/system.d.

The DBus system configuration did give me much info, however the config file htb.oouch.Block.conf shows the user www-data is the one other than root is running DBus service. So I believe I need to escalate my current user privileges from QTC to www-data.

A user’s comment in HTB forum made some sense. I started to look for more rooting hints in the forum. One of them is SSH as QTC using the container interfaces IP.

I used NAMP binary to see interface IPs and services they are running.

The docker br-cc6c78e0c7d0 is in up state and the IP range assigned :

I successfully logged in as QTC to the docker container aeb4525789d8.

I started to enumerate the directories. I found a folder “code” where I found file config.py and a credential for MySQL database. I don’t know where this applies, so I noted it for future reference.

Further enumeration showed me the service uwsgi running and found other associated details. **Thanks 0xPrashanth for timely nudge.

And the www-data processes used by the service uwsgi.

A quick Googling showed me an exploit for UWSGI which is readily avilable in the GitHub.

As the exploit need to run locally post exploit, I had to move the exploit to QTC directory and then from QTC directory to the docker IP

Uploading File to QTC Directory Using SCP

Moving Exploit to the docker

Exploit In Docker

When everything is in place, my next task is to get shell as www-data using the exploit I just uploaded to docket temp folder. I set up a listener listening port 9999 in my Kali machine and run the following command in docker/temp directory.

Before starting exploit I wanted to see DBus config files to find anything useful to create exploit code and the payload.

I immediately got the reverse shell as www-data in my listener.


From www-data reverse shell, I run the debus-send command.

Thank you for reading, Oouch is one of the hardest machine I’ve ever worked on HTB. I learned a lot and. It took me more days and nights than what I estimated earlier. It was a great journey.


Hey there, I'm Navin, a passionate Info-Sec enthusiast from Bahrain. I started this blog to share my knowledge. I usually write on HackTheBox machines and challenges, cybersecurity-related articles and bug-bounty. If you are an HTB user and like my articles, please respect here: https://www.hackthebox.eu/home/users/profile/68523

View all posts by Navin →
Notify of
Inline Feedbacks
View all comments
Sorry, that action is blocked.
%d bloggers like this: