Vulnhub’s FoxHole 1 CTF Walkthrough

FoxHole 1 is a vulnerable VM from purpl3f0x. The box is labeled as somewhere between easy and intermediate.

Having been through the box, I would say that this is on the easier side. While there are some really fun techniques that you need to use to get control of the box, you will likely have it completed in under an hour.

I used it on VirtualBox and I’m not sure how well it works on VMWare. I went with the easiest privilege escalation method on the box, but I’m sure there are other ways to get root. Okay! Let’s start with enumeration.

Enumeration

A quick Nmap scan shows that there are only two ports open. There aren’t any known vulnerabilities for the SSH service so I moved onto the web server on port 80.

user@kali:~$ nmap -sV -Pn -A 192.168.1.228
Starting Nmap 7.80 ( https://nmap.org ) at 2020–09–22 16:57 EDT
Nmap scan report for FoxHole.attlocal.net (192.168.1.228)
Host is up (0.00082s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Photosen — Colorlib Website Template
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.61 seconds
user@kali:~$

The landing page of the site showed a Colorlib template for an online portfolio.

A quick dirb scan revealed that there were a few directories.

user@kali:~$ dirb http://192.168.1.228

— — — — — — — — -
DIRB v2.22
By The Dark Raver
— — — — — — — — -

START_TIME: Tue Sep 22 16:58:29 2020
URL_BASE: http://192.168.1.228/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

— — — — — — — — -

GENERATED WORDS: 4612

— — Scanning URL: http://192.168.1.228/ — —
==> DIRECTORY: http://192.168.1.228/css/
==> DIRECTORY: http://192.168.1.228/fonts/
==> DIRECTORY: http://192.168.1.228/images/
+ http://192.168.1.228/index.html (CODE:200|SIZE:9135)
==> DIRECTORY: http://192.168.1.228/js/
+ http://192.168.1.228/phpmyadmin (CODE:200|SIZE:98)
+ http://192.168.1.228/robots.txt (CODE:200|SIZE:13)
+ http://192.168.1.228/server-status (CODE:403|SIZE:278)

— — Entering directory: http://192.168.1.228/css/ — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)

— — Entering directory: http://192.168.1.228/fonts/ — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)

— — Entering directory: http://192.168.1.228/images/ — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)

— — Entering directory: http://192.168.1.228/js/ — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)

— — — — — — — — -
END_TIME: Tue Sep 22 16:58:38 2020
DOWNLOADED: 4612 — FOUND: 4

Naturally, I gravitated to the phpmyadmin directory since there is a such a widely known vulnerability for it. Turns out, that directory was just an image file of the phpmyadmin GUI.

Cute, huh?

Next, I thought I would try the robots.txt directory.

There’s a secret directory. I navigated there for another trick.

But a check of the source code revealed a slight clue.

So, there was a hint somewhere, I just had not found it. With nothing left to go on, I decided to do a Nikto scan. A lot of times, Nikto will pick up on something that dirb misses. Turns out, there was one directory that we missed.

user@kali:~$ nikto -h 192.168.1.228
- Nikto v2.1.6
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
+ Target IP: 192.168.1.228
+ Target Hostname: 192.168.1.228
+ Target Port: 80
+ Start Time: 2020–09–22 17:12:02 (GMT-4)
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
+ Server: Apache/2.4.41 (Ubuntu)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use ‘-C all’ to force check all possible dirs)
+ Server may leak inodes via ETags, header found with file /, inode: 23af, size: 5aee8ce5af43c, mtime: gzip
+ Allowed HTTP Methods: HEAD, GET, POST, OPTIONS
+ OSVDB-3092: /admin.html: This might be interesting…
+ OSVDB-3268: /css/: Directory indexing found.
+ OSVDB-3092: /css/: This might be interesting…
+ OSVDB-3092: /readme.txt: This might be interesting…
+ OSVDB-3268: /images/: Directory indexing found.
+ 9535 requests: 0 error(s) and 10 item(s) reported on remote host
+ End Time: 2020–09–22 17:12:29 (GMT-4) (27 seconds)
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
+ 1 host(s) tested

*********************************************************************
Portions of the server’s headers (Apache/2.4.41) are not in
the Nikto 2.1.6 database or are newer than the known string. Would you like
to submit this information (*no server specific data*) to CIRT.net
for a Nikto update (or you may email to sullo@cirt.net) (y/n)? n

The admin.hmtl directory is another trick.

But looking at the source code gave me the clue I needed. At the bottom, it points back to a different directory I looked at, but didn’t see much in.

That one purple fox picture. I headed back to the /images directory.

The clue of take a deeper look obviously pointed to stenography. I was sure that the file was the purpl3f0x.png file, but I couldn’t get anything to pull up. I tried binwalk, foremost and a few others on the file, but nothing came of it.

I downloaded all of the files that had the word fox in them and found something in the foxy1.jpeg file. No password was required. I just hit “enter.”

user@kali:~/Downloads$ steghide extract -sf foxy1.jpeg
Enter passphrase:
wrote extracted data to “msg.txt”.

When I concatenated msg.txt I was given some output.

user@kali:~/Downloads$ cat msg.txt
WTB1M3NjYXAzZFRoM0YweEgwbGUhClVzZXJuYW1lIGlzIGZveCA7Mw==

Right off the bat, I could tell it was base64. I decoded it for the first clue.

user@kali:~/Downloads$ cat msg.txt | base64 — decode
Y0u3scap3dTh3F0xH0le!
Username is fox

I SSH’d into the box and found something interesting in the user’s home folder.

I tried to run the GiveMeRootPlz program and I was met with some strange output.

The clue leads me to believe that there is a buffer overflow attack on this specific program. In fact, when I do a permissions check I can see that there is an SUID sticky bit on the program.

Also, while the program sits idle in the “Do you want the root password?” prompt, it is running as root. I did a ps aux | grep GiveMeRootPlz command while it sat idle.

I also ran a strings on the program and found a string named overflow.

I decided to leave the program idle and run another Nmap scan. A scan on the TCP ports didn’t yield anything. I also scanned the UDP ports, but I didn’t find anything there either. So maybe, this is a “foxhole.”

Another thing that caught my eye was one of the groups that fox was in.

fox@FoxHole:~$ id
uid=1000(fox) gid=1000(fox) groups=1000(fox),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),120(lpadmin),131(lxd),132(sambashare)
fox@FoxHole:~$

As you can see here, fox is not only part of the lxd group (which has an extremely well known privilege escalation method), this user is also part of the sudo group.

I did a sudo -l on the target and was asked for fox’s password. I used the same password from SSH.

fox@FoxHole:~$ sudo -l
[sudo] password for fox:
Matching Defaults entries for fox on FoxHole:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User fox may run the following commands on FoxHole:
(ALL : ALL) ALL

As you can see from the output, fox can run all commands through sudo. A simple sudo su - gave me root.

I navigated to the root folder and grabbed the flag.txt. file.

This was a great CTF. There were a few “foxholes” but overall it wasn’t too bad. This was great because it gave me a chance to really problem solve throughout the entire process. I really enjoyed it so thanks to purpl3f0x!

Until next time, you can follow me on here or on Twitter @assume_breach