Caption

Recon

nmap_scan.log|h-50%_styled

HTTP (8080)

GitBucket

Writeup-1.png

Default Creds

Nothing to see as unauthenticated user. Search for defaults:

Writeup-2.png

Creds: root:root

Login is successful

Writeup-3.png

Leaked Creds

User credentials in commit of frontend application:http://caption.htb:8080/root/Caption-Portal/commit/0e3bafe458d0b821d28dde7d6f43721f479abe4aarrow-up-right

Writeup-5.png

Creds: margo:vFr&cS2#0!

Logservice

There's also Logservice application.

Writeup-4.png

http://caption.htb:8080/root/Logservice/blob/main/server.goarrow-up-right

H2 Database

Abusing H2 Database ALIASarrow-up-rightRemote Code Execution in Three Acts: Chaining Exposed Actuators and H2 Database Aliases in Spring Boot 2arrow-up-right

Writeup-7.png
Writeup-8.png

SSH

User.txt

Frontend App Backend Source

Creds: admin:cFgjE@0%l0

Still doesn't work because HAProxy is restricting any request being made to server.

HTTP (80)

Writeup.png

We are able to authenticate as margo

Writeup-6.png

Also admin from source, but we can't do anything. /logs and /download is blocked by HAProxy.

Do port forwarding to bypass the proxy.

Logservice Exploit

/logs is now accessible, but /download fails. The previous application (Logservice) is probably running as privileged user.

log_service.thrift:

Thrift has a guide: https://thrift.apache.org/tutorial/py.htmlarrow-up-right

We can use generated code by thrift to work with the service and inject malicious payload.

Root

Root.txt

Hashes

Past Root

varnish > default.vcl

ruth > bot.py

ruth > varnish_logs.sh

Intended Route

I think on release date everything went wrong and nobody got the intended route 😄

As I kept digging the source code I realized that real chain of attack was

  1. GitBucket

  2. Source Code

  3. Guessy work

  4. XSS via header

  5. Cache poison

  6. admin

  7. HAProxy bypass

  8. LFI

  9. Fuzzing

  10. Service on 9090

On GitBucket we can login with default credentials (root:root) and browse source of 2 applications. For now we only need Caption-Portalarrow-up-right. Now the trickiest part is figuring out how to perform anything at all.

If you look in the source you can view something like this:

Now comes the guessy work, considering we don't know how this value is populated there's only plug and play situation...

From the GitBucket we have credentials for margo user and we can fuzz for headers which effect how url works.

So because we can control the contents of script we can also inject and gain XSS, but first let's test it.

Writeup-9.png

If you notice age header increased, this is because Varnish is a caching HTTP reverse proxy service and whatever we send is cached and later used. If I make request to XXX and then you make same request you will get cached page from server and not a new one.

Writeup-10.png

Anyway, check your server listener and what do you know! someone is visiting the website frequently so maybe we can steal their cookies too?

XCGFULLBAN can be used to clear cache, or wait 120sec

Now that we are logged in as other user (presumably higher then margo) we can browse around. If we go to /logs we get denied because of HAProxy

http://caption.htb:8080/root/Caption-Portal/blob/main/config/haproxy/haproxy.cfgarrow-up-right

Basically any request to /logs or /download is blocked! BUT the path is only filtering case, so what prevents us from injecting a forward slash at the front? (or similar payload)

Writeup-11.png

Absolutely nothing.

Great, we can view log files like:view-source:http://caption.htb//download?url=http://127.0.0.1:3923/ssh_logsarrow-up-right

But why is request made to internal webapp?

Searching for this service we end up on GitHub and exploit:

Writeup-12.png

copyparty 1.8.2 - Directory Traversalarrow-up-right

LFI like: http://caption.htb//download?url=http://127.0.0.1:3923/.cpr/../../../../../etc/passwdarrow-up-right will not work because we need to urlencode, but it will not work, because we need to urlencode again for the second request.

view-source:http://caption.htb//download?url=http://127.0.0.1:3923/.cpr/%252F%252E%252E%252F%252E%252E%252F%252E%252E%252F%252E%252E%252F%252E%252E%252Fetc%252Fpasswdarrow-up-right

Writeup-13.png

There's 3 valid users: root, margo and ruth

Automate the file grabbing:

Since we don't know what we are looking for and /proc/self/* doesn't work, fuzz.

I first focused on SSH keys. Had to resort to sockets because // was not accepted in the url by requests

We gained margo ssh key and can login as her. (SSH key is from Arena VPN, so it may not work on public IP)

From this point on the path to root is the same, exploit the service on port 9090 (thrift) and that's it, I guess.


Could be useful: https://github.com/kacperszurek/exploits/blob/master/GitBucket/gitbucket-unauthenticated-rce.mdarrow-up-right

Intended Route 2 (HAProxy bypass)

After some time machine got patched, root:root was removed and HAProxy was also fixed...

Writeup-14.png

HAProxy is vulnerable to H2 Smuggling Requestarrow-up-right

Upgrade Header Smugglingarrow-up-righth2csmugglerarrow-up-right

Writeup-15.png

Now that we can bypass the proxy the steps are relatively the same:

Get private key:

This step can be automated, but at this point we know this file exists...

Last updated