Name | Cap | |
Difficulty | Easy | |
Release Date | 2021-06-06 | |
Retired Date | <don’t know> | |
IP Address | 10.10.10.245 | |
OS | Linux | |
Points | 20 |
The WalkThrough is protected with the root user’s password hash for as long as the box is active. For any doubt on what to insert here check my How to Unlock WalkThroughs.
foothold
Because this was an Easy box, I ended up not even running nmap
on it. Most of the boxes have a website and that was actually where I started. Opening the box’s IP showed some kind of security dashboard with alerts.
I decided to look around to get a sense of what data was “real” (more like dynamic content), and what was static. The displayed data is actually static but on the side menu there’s 3 submenus with dynamic data.
Security Snapshots
let’s you download apcap
file (network capture)IP Config
just displays the result of theifconfig
commandNetwork Status
displays the result of thess
/netstat
command
Now, the first one has the interesting bit. When you clink the link, you’re actually redirected to http://<BOX-IP>/data/1
which shows a packet capture with 0 captured packets:
It occurred to me that maybe there’s more even if there’s no selection box or anything to choose from. So, I just changed that 1
with a 0
, and voilá, a valid packet capture with actual packets in it:
What’s next you ask? Just fire up Wireshark and let’s see what’s inside.
The first packets in the file are just requests to the HTTP server, but the ones that come next are what actually matter. There’s a recorded “conversation” of an access to the FTP server that’s running on the box, where the credentials where caught. FTP isn’t a secure protocol by itself (it doesn’t use SSL/TLS to encrypt the communications), because of that, we now have our first set of credentials 😉 and our foothold.
user flag
Getting the user flag is easy because we got the user’s credentials from the packet capture; we just login with the user nathan
and password Buck3tH4TF0RM3!
.
nathan@cap:~$ id
uid=1001(nathan) gid=1001(nathan) groups=1001(nathan)
nathan@cap:~$ cat user.txt
1c4919f2d30c8b1bd397133aa8e19574
root flag
For the root
flag, I tried to see what we could execute with the sudo
command:
nathan@cap:~$ sudo -l
[sudo] password for nathan:
Sorry, user nathan may not run sudo on cap.
Hummm, not normal. So, if this wasn’t the way, I downloaded LinPEAS
and let it run on the box to see what it could found. [Download]
While LinPEAS
was running I did some quick checks for credentials on the website directory (/var/www/html
) and checked for some other out of the ordinary things (that LinPEAS
could also get), but didn’t spot anything out of the ordinary. After it finished, I started looking for red text on the output (⚠️ always check the red stuff!). One line looked out of the ordinary:
Files with capabilities (limited to 50):
/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip
/usr/bin/ping = cap_net_raw+ep
/usr/bin/traceroute6.iputils = cap_net_raw+ep
/usr/bin/mtr-packet = cap_net_raw+ep
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper = cap_net_bind_service,cap_net_admin+ep
Well, most of that stuff is normal, but python having cap_setuid
isn’t for sure! cap_setuid
is a Linux Capability that allows a process to change the owner of itself while it’s running using the setuid syscall. This works even in a user process that requests a change to root
.
With this information at hand, I just needed a quick python on-liner:
nathan@cap:~$ python3 -c "import os; os.setuid(0); os.system('bash')"
root@cap:~# id
uid=0(root) gid=1001(nathan) groups=1001(nathan)
root@cap:~# cat /root/root.txt
f2cba0bdc4fec03791d60d200d2bbd82
And we have our root
flag. 🥳
root password hash
$6$8vQCitG5q4/cAsI0$Ey/2luHcqUjzLfwBWtArUls9.IlVMjqudyWNOUFUGDgbs9T0RqxH6PYGu/ya6yG0MNfeklSnBLlOskd98Mqdm0