This should be a pretty straightforward box, the details provided note that this will involve brute forcing, hash cracking, service enumeration, and Linux Enumeration. Let’s get started with some recon!

Recon

Like usual, let’s hit the target with an nmap scan. My initial scan is as follows:

nmap -sV 10.10.188.205

This takes a little while, so after making some coffee we come back to the following output:

Starting Nmap 7.93 ( https://nmap.org ) at 2023-01-13 21:49 EST
Nmap scan report for 10.10.188.205
Host is up (0.21s latency).
Not shown: 995 closed tcp ports (conn-refused)
PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http        Apache httpd 2.4.18 ((Ubuntu))
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
8009/tcp open  ajp13?
Service Info: Host: BASIC2; 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 193.76 seconds

Excellent! We have quite a few services to dive into. Since we already have the browser open, we can take a quick look at the web server. Navigating to the web page we’re greeted with an “Undergoing Maintenance” sign, not much else here. Inspecting the source shows a comment left in the page:

<!-- Check our dev note section if you need to know what to work on. -->

Not sure what that means since /dev and /dev-note returns a 404, but we’ll come back to that later. Much better tools available than us random guessing.

Inspecting the Web Server

Checking the robots.txt also returns a 404 which is unfortunate as that can usually be a quick win in these CTFs. Oh well, still plenty to try!

At this point, it’s time to do a quick enumeration of the web servers routes, so we can use dirbuster for that. Let’s do a basic run with the IP address we have and using the directory-list-1.0.txt wordlist with all the defaults selected.

Boom! A couple directories popped up, including /development which matches that comment from earlier! Time to take a look.

This shows us a file directory with two text files, dev.txt and j.txt. Neither of these seem like they should be freely available, so we should take a quick peek at both:

# dev.txt

2018-04-23: I've been messing with that struts stuff, and it's pretty cool! I think it might be neat
to host that on this server too. Haven't made any real web apps yet, but I have tried that example
you get to show off how it works (and it's the REST version of the example!). Oh, and right now I'm 
using version 2.5.12, because other versions were giving me trouble. -K

2018-04-22: SMB has been configured. -K

2018-04-21: I got Apache set up. Will put in our content later. -J

# j.txt

For J:

I've been auditing the contents of /etc/shadow to make sure we don't have any weak credentials,
and I was able to crack your hash really easily. You know our password policy, so please follow
it? Change that password ASAP.

-K

Alright, so from this we can see that there is talk about an Apache server, SMB, and something about struts with version 2.5.12 – definitely info that we shouldn’t know. Additionally we know that user “J” has a really weak password, so if we can find the username we should be able to brute force it.

SMB Enumeration

The hint for the username question mentions SMB, so we can try to enumerate the usernames using metasploit. Load msfconsole and use auxiliary/scanner/smb/smb_enumusers, set your RHOSTS to the target IP, and run the scan.

Unfortunately this doesn’t give us anything useful. Looking around a bit, a tool called enum4linux might work a bit better as it’s more generalized and checks quite a few aspects of both Windows and Linux systems. By using Samba tools it can pull quite a bit of info from a system, so we can give it a try:

enum4linux -a 10.10.188.205

Boom! We see some generic built in users but we also return “Jan” and “Kay” which lines up with the text documents we found earlier. Since the one text file indicated Jan has a weak password, let’s brute force it with hydra.

SSH Attack

It’s time to go after Jan’s ssh access. We can do this quickly with hydra to brute force the login, running with the standard rockyou password file since this is an easy CTF and it should be contained there. SSH is running on port 22 so no special config needed there, so we can fire off the tool with:

hydra -l jan -P /usr/share/wordlists/rockyou.txt ssh://10.10.188.205

With that, we find that “armando” is the password and can ssh into the server with that information.

Privilege Escalation

Now that we have user access it’s time to see how this can be escalated to root. There are a number of ways to do this, so I like to go through a couple easy wins using GTFOBins with sudo access or SUID binaries.

The initial check of sudo -l shows that jan cannot run sudo on this machine. Oh well, that’s too bad.

Next, time to check for SUID with the following command:

find / -type f -perm -04000 -ls 2>/dev/null

This is a bit more lucrative. We see that vim has it’s SUID set, and GTFOBins has an exploit for this. The following script should give us root access:

vim -c ':py import os; os.execl("/bin/sh", "sh", "-pc", "reset; exec sh -p")

Whoops! This gives an error – python3 is installed on this machine so make a quick update to :py3 and try again:

vim -c ':py3 import os; os.execl("/bin/sh", "sh", "-pc", "reset; exec sh -p")

The shell changes, and we have root! Changing to kay’s directory we can cat out the password file in there and finish the machine.

All done!