Sink is an Insane rated machine on HackThebox by MrR3boot which features a misconfiguration in a proxy that leads to HTTP-request-smuggling and access to a gitea application. In the gitea application we will dig through git logs to find a ssh key allowing us to log in as marcus. Next we will interact with AWS to retrieve a password for david. Finally we will use AWS again to query through keys and decrypt an encrypted archive which contains a yaml file with the root users password.
User
Nmap
We start our enumeration with a nmap scan on all ports, followed by a script and version detection scan on the open ones.
All ports
1 |
|
Script and version
1 |
|
HTTP-request-smuggling
Going over to port 3000 we see a gitea hosting default page.
Clicking on Explore=>Users we can identify possible usernames for the application and note them down for later.
On port 5000 there is gunicorn application, which let’s us register a user.
After signing up and logging in it looks like a blog and note keeping application.
Looking at a request submitting a comment to the blogpost we see a haproxy installation which might be vulnerable to CVE-2019-18277. The setup in the blogpost describing this vulnerability looks very similar to the setup at hand.
For it to work we have to obfuscate the Transfer-Encoding header with a vertical tab. This way the frontend proxy does not recognize it and forwards the request as a whole. The backend server however parses the header and sees two requests instead of one. Since the Content-Length in the next request is not reached a request by another user might get concatenated to our request. First we need to create the vertical tab in burp. We use python to do this and base64 encode it.
1 |
|
In Burp we then can decode it again in front of the chuncked value. Next we add an empty chunk which signifies the end of the request for the backend. Now we add another request to ours, also posting to comment using our cookie with a Content-Length longer as the message specified. This enables the next users request to get concatenated to ours.
Refreshing the page after about a minute(if we are too quick our own request gets concatenated), we see the start of another users http request in a comment field. The request doesn’t display any useful information yet sadly though because our Content-Length of 100 in the second request was too small.
We send another request increasing the Content-Length of the smuggled request to 300 this time.
Refreshing the page again after some time we were able to capture the full session cookie this time.
Replacing our cookie and refreshing, we are now logged in as the administrator user of the page.
Notes
Logged in as the admin we can now read his notes which reveals 3 username password pairs with a website and a short note.
| NR | Note | URL | Username | Password |
|---|---|---|---|---|
| 1 | Chef Login | http://chef.sink.htb |
chefadm | /6'fEGC&zEx{4]zz |
| 2 | Dev Node | http://code.sink.htb |
root | FaH@3L>Z3})zzfQ3 |
| 3 | Nagios | https://nagios.sink.htb |
nagios_adm | g8<H6GK\{*L.fB3C |
Root already appeared as the usernames on gitea and trying this set of credentials we can log into gitea.
Key_Management
Going over to repositories, from the four being present Key_Management sounds the most interesting.
To have a better look at it we download it locally.
1 |
|
Looking at the git history we see some interesting commits made by marcus.
1 |
|
Checking out the difference between the head and commit b01a6b7ed372d154ed0bc43a342a5e1203d07b1e which states to add EC2 Key Management Structure, we find a private ssh key.
1 |
|
With this key we can now log in as the user marcus, after setting the correct permissions on it and grab the user flag
1 |
|
Root
Marcus => David
Listing all the ports listening on localhost we identify AWS on port 4566.
1 |
|
Checking the health of the AWS service we see 3 services running.
1 |
|
To interact with the endpoint we have to first configure the AWS cli.
1 |
|
The secretsmanager looks interesting and we are able to list all the secrets contained in it.
1 |
|
Retrieving all the secrets from the secretsmanager, we get 3 usernames and 3 passwords.
1 |
|
Since David is the only other user and he is also mentioned in the secrets, we use his password to switch to his account.
David => Root
In David’s home directory there is an encrypted file servers.enc in the Projects folder.
Looking for a fitting key to open the lock we configure AWS-CLI again for David and enumerate AWS KMS.
1 |
|
We can list all the keys within KMS and also look at the encryption algorithms possible with a key.
1 |
|
1 |
|
There 11 keys with multiple possible algorithms per key. So it is best for us to not manually try each combination. In a first step we extract all the key ids from the endpoint like this.
1 |
|
The second step is to get all the possible possible encryption algorithms, which we can do in the first command and then manually add them to a file.
1 |
|
1 |
|
With all preperations done we can now try all keys with the possible decryptions methods on the servers.enc
1 |
|
All of them but one error out but the succeeding one gives us a base64 encoded object.
1 |
|
The base64 blob turns out to be a gzip compressed file with a tar archive inside. Decompressing and opening it gives us a new password.
1 |
|
Using this password we can now switch to the root user on sink.
1 |
|