NameCap
DifficultyEasy
Release Date2021-06-06
Retired Date<don’t know>
IP Address10.10.10.245
OSLinux
Points20

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.

website

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 a pcap file (network capture)
  • IP Config just displays the result of the ifconfig command
  • Network Status displays the result of the ss/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:

capture-1

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:

capture-0

What’s next you ask? Just fire up Wireshark and let’s see what’s inside.

wireshark

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.

wireshark-ftp

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