secnigma posted: " Prelude Atom is an intermediate box from Hack The Box, developed by MrR3boot. This is my second windows machine writeup in this blog and this machine was actually pretty hard for me due to the initial foothold's finickiness and my overall naivety on r"
Atom is an intermediate box from Hack The Box, developed by MrR3boot. This is my second windows machine writeup in this blog and this machine was actually pretty hard for me due to the initial foothold's finickiness and my overall naivety on redis servers.
If you look back after rooting the machine, most of the steps will feel more or less straightforward. Maybe that's the reason that the machine was debuted as an easy machine. But later, the machine's difficult was changed to medium, after several users pointed out the difficulty in getting the initial foothold.
Let's begin the exploitation.
Exploitation
As usual I started the exploitation with Nmap scan.
nmap -sCV -v -oN tcp 10.10.10.237
And I got the scan result as follows.
# Nmap 7.91 scan initiated Wed Jun 2 18:15:53 2021 as: /usr/bin/nmap -sCV -v -oA nmap/tcp 10.10.10.237 Nmap scan report for 10.10.10.237 Host is up (0.26s latency). Not shown: 996 filtered ports PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.46 ((Win64) OpenSSL/1.1.1j PHP/7.3.27) | http-methods: | Supported Methods: HEAD GET POST OPTIONS TRACE |_ Potentially risky methods: TRACE |_http-server-header: Apache/2.4.46 (Win64) OpenSSL/1.1.1j PHP/7.3.27 |_http-title: Heed Solutions 135/tcp open msrpc Microsoft Windows RPC 443/tcp open ssl/http Apache httpd 2.4.46 ((Win64) OpenSSL/1.1.1j PHP/7.3.27) | http-methods: | Supported Methods: HEAD GET POST OPTIONS TRACE |_ Potentially risky methods: TRACE |_http-server-header: Apache/2.4.46 (Win64) OpenSSL/1.1.1j PHP/7.3.27 |_http-title: Heed Solutions | ssl-cert: Subject: commonName=localhost | Issuer: commonName=localhost | Public Key type: rsa | Public Key bits: 1024 | Signature Algorithm: sha1WithRSAEncryption | Not valid before: 2009-11-10T23:48:47 | Not valid after: 2019-11-08T23:48:47 | MD5: a0a4 4cc9 9e84 b26f 9e63 9f9e d229 dee0 |_SHA-1: b023 8c54 7a90 5bfa 119c 4e8b acca eacf 3649 1ff6 |_ssl-date: TLS randomness does not represent time | tls-alpn: |_ http/1.1 445/tcp open microsoft-ds Windows 10 Pro 19042 microsoft-ds (workgroup: WORKGROUP) Service Info: Host: ATOM; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: |_clock-skew: mean: 2h23m36s, deviation: 4h02m30s, median: 3m35s | smb-os-discovery: | OS: Windows 10 Pro 19042 (Windows 10 Pro 6.3) | OS CPE: cpe:/o:microsoft:windows_10::- | Computer name: ATOM | NetBIOS computer name: ATOM\x00 | Workgroup: WORKGROUP\x00 |_ System time: 2021-06-02T05:49:58-07: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: 2021-06-02T12:50:02 |_ start_date: N/A
There were quite some ports open.
So, as usual I started my enumeration with the website. I navigated to http://10.10.10.237/ and found the following webpage.
It was a static HTML page and there was a download link for the advertised note taking software.
After extracting and installing the software on my Windows machine, I got the following application.
This was an Electron application. Electron applications are JavaScript based desktop applications, which uses a web browser rendering engine as a backend.
Once installed, we can see the javascript source code of the application at the Installed directory. In my case, it was at C:\Users\User\AppData\Local\Programs\heedv1.
Since, we don't have much information or scope to exploit the electron vulnerability as of now, I decided to expand my enumeration to other services.
Finding the exposed SMB share
I decided to move my focus to SMB.
smbclient -L 10.10.10.237
There was an exposed SMB share named Software_Updates.
So, I quickly checked the permissions with smbmap.
smbmap -H 10.10.10.237 -u 'guest' -p ''
And guest users have Read/Write access on Software_Updates.
So, I connected to the share using smbclient.
smbclient \\\\10.10.10.237\\Software_Updates
The share had three folders named client1, client2 and client3 which were empty. There was also a PDF file named UAT_Testing_Procedures.
I downloaded the file using the following command and opened it.
get UAT_Testing_Procedures.pdf
It was the manual for testing the Heed software. It mentioned that the files placed in the client folders are used for updating.
Now, the exploitation vector is getting clearer.
We have to exploit the Electron application by placing the malicious update files in the exposed SMB share and we'll get a code execution.
Exploiting Electron-Updater
I went back to my Windows VM, searched for electron vulnerabilities and I came across an article that mentioned a vulnerability in electron-updater module. If we start the the Heed application, we can see that it checks for auto updates and fails.
Upon further research, I found that the update server URL is defined in the C:\Users\User\AppData\Local\Programs\heedv1\resources\app-update.yml file.
Contents of app-update.yml
So I edited the C:\Windows\system32\drivers\etc\hosts file and added an entry for updates.atom.htb that points towards my Kali box, started the python http.server and restarted the Heed application.
And got a hit!
The application is requesting for latest.yml file from my kali box. This means that we can probably exploit this situation using the vulnerability in the electron-update module I mentioned earlier.
The vulnerable version is electron-updater v2.23.3. So, I checked the C:\Users\User\AppData\Local\Programs\heedv1\resources\app.asar file for the electron-updater version and found the version to be same.
There's actually two vulnerabilities in the electron-updater module. One is Signature Validation Bypass that allows us to execute any applications by providing a malicious latest.yml file and the other one is a code injection vulnerabilitywhen specifying the update file name in latest.yml.
So, I decided to start the testing with the Signature Bypass vulnerability.
To exploit the signature bypass vulnerability, we need to craft a malicious file with a single quote in the file name and specify the filename in the latest.yml, which might looks like the following.
Malicious yml file definition as mentioned in the article
The single quote in the filename will skip the Signature Validation of the electron-update module and with this, an attacker can effectively execute arbitrary executables.
So, I generated a reverse shell file using msfvenom and renamed it to "v'ulnerable-app-setup-1.2.3.exe".
We have to also update the sha512 in the latest.yml with the output of the following command.
After this, I thought my latest.yml file was ready.
So, I decided to test it by hosting the latest.yml and v'ulnerable-app-setup-1.2.3.exe files in my Kali box and open the Heed application in my Windows VM.
I got a hit on the latest.yml file, but the reverse shell exe wasn't hit; which indicated that my latest.yml file might not be in the right format.
So, I tried tinkering with the latest.yml file and tried different paramters in the file and finally from this github page, I finally I got an idea for a valid latest.yml parameters, which is given below.
And I got a hit on my Kali machine from my test Windows VM.
Also the error message in the Heed app have changed a little. It showed Update Available and showed Download in progress, but after that the app exited abruptly.
Nevertheless, this is a good sign. So, I decided to upload the file to the SMB share of atom.
I created the reverse meterpreter shell using the following msfvenom command.
Now, I need to upload both the latest.yml and v'ulnerable-app-setup-1.2.3.exe files to the exposed SMB share's client1 , client2 and client3 directories.
Since it was a boring and repetitive task, I decided to automate it with a quick bash script that connects to the exposed SMB share and upload the latest.yml and v'ulnerable-app-setup-1.2.3.exe to the client1 , client2 and client3 directories.
#!/bin/bash # Pass the filename as an argument # Eg: ./smb "v'ulnerable-app-setup-1.2.3.exe" smbclient \\\\10.10.10.237\\Software_Updates -N<< SMBCLIENTCOMMANDS cd client1 put $1 put latest.yml cd ..\client2 put $1 put latest.yml cd ..\client3 put $1 put latest.yml exit SMBCLIENTCOMMANDS
After saving this as smb.py, I used ./smb.py "v'ulnerable-app-setup-1.2.3.exe"to upload both latest.yml and the v'ulnerable-app-setup-1.2.3.exefiles to the said directories.
And I got a shell back on my multi/handler as user jason !
Now, you guys might've been thinking about why've I uploaded the reverse shell binary to the target, instead of hosting the reverse shell binary in my server. Gaining shell via that method is also possible, by changing the PATH parameter to an http URL pointing towards our machine. Some users got shell back that way, but for some reason, that method didn't work for me.
Privilege Escalation
Privilege escalation was actually pretty easy and straight forward than the initial foothold. However, my inexperience when dealing with redis servers made the process a little longer.
Side Note: I actually found a plain text password kidvscatelectron@123 of user jason from credential manager. But I couldn't use that to login via Evil-Winrm.
I personally believe that this is a bad way of designing an online CTF box since, there are tons users exploiting the machine and tons of resets are happening to the machine at the same time. In this case, if the ability to save the progress of an exploitation attempt is absent in a CTF box, then it is a pretty bad CTF box design. Also, it dramatically increases the exploitation attempts by a whole lot (at least for the initial period of box release) and that might make the machine unstable and frustrating to exploit.
Back to the exploitation...
Upon gaining the initial shell on the target as jason, we can see that there are two folders in the target's Downloads folder.
node_module is directory for the static http server running at port 80.
The PortableKanban directory looked interesting. Kanban is a workflow management method and Portable Kanban is a software to aid that. It is basically a virtual notice board containing current projects.
Source Wikipedia
I looked up exploits for Portable Kanban vulnerabilities and found an exploit that can be used to decrypt the encrypted portable kanban credentials. To do that, it required a .pk3 file in the directory and I found a PortableKanban.pk3.lock file inside the directory. It contained an encrypted password for the redis server.
Now, there are two ways to extract the redis password from here. The easy way is to look at the configuration file of the redis server and get plain text credentials from it.
The relatively harder way is to decrypt the encrypted password from the PortableKanban.pk3.lock file and decrypt it using the exploit I mentioned earlier.
So, I modified the exploit and made the following version to decrypt the password.
#!/usr/bin/python3 import base64 from des import * #python3 -m pip install des import sys # Encrypted Password to decrypt pk_hash= "Odh7N3L9aVQ8/srdZgG2hIR0SSJoJKGi" hash1 = base64.b64decode(pk_hash.encode('utf-8')) key = DesKey(b"7ly6UznJ") x=key.decrypt(hash1,initial=b"XuVUm5fR",padding=True).decode('utf-8') print(x)
And decrypted the password kidvscat_vs_kidvscat.
I then used the password to login to redis.
redis-cli -h 10.10.10.237 -p 6379 -a "kidvscat_yes_kidvscat"
Then I decided to dump the whole redis database.
I firstly found the current redis directory using config get dir command.
Then I used the bgsave command to dump the database toa file named dump.rdb.
I then opened the file with Notepad++ and found the encrypted Administrator password.
I decrypted the password using the script I made earlier and found the password of Administrator.
What's up with the kidvskat references?
The password was kidvscat_admin_@123.
I then used WinRM to login as Administrator!
Woot
Postlude
And that was Atom!
This was actually one of the hardest machines I've ever encountered in terms of getting the initial foothold, just because of the yml file debugging.
But nevertheless, it was a new lesson in a new technology and in the end, I'm happy.
Kudos to MrR3boot for creating such a challenging box!
Also, Thanks to HTB user SimonBai for helping me overcome the road blocks I've encountered during solving this machine.
WordPress.com
No comments:
Post a Comment