Introduction
A “penetration test” was requested by “HackTheBox” for their soon-to-be-deployed “Postman” service. The goal of this test is to verify that security is up to par with their expectations before being released to production. The test will be done in black box format, without access to any code or prior knowledge of the system.Scope and Duration
The scope of this test is limited to the “Postman” server located at 10.10.10.160. The duration for the test is one week starting from the 18th of November 2019. The client has requested we avoid using any "DoS" exploits to avoid unnecessary crashes. If root level access is obtained, the testing can be stopped immediately and the test results reported to the client for remediation.Technical Summary
Initial port scanning revealed several exposed services, such as HTTP, SSH, Redis, and Webmin.Initial Port Scan Results
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Discovered open port 6379/tcp on 10.10.10.160
Discovered open port 80/tcp on 10.10.10.160
Discovered open port 10000/udp on 10.10.10.160
Discovered open port 10000/tcp on 10.10.10.160
Discovered open port 22/tcp on 10.10.10.160
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Port Scan Results With Banners
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
|_banner: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
6379/tcp open redis Redis key-value store 4.0.9
10000/tcp open http MiniServ 1.910 (Webmin httpd)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Particularly interesting is the Redis service, which is an in-memory database application. Internet research reveals a known security flaw detailed by the developer here: http://antirez.com/news/96. While attempting to reproduce this we discovered that command line access to redis was easily obtained and commands can be executed.
We continue to follow the developers instructions and create a text file containing our public SSH key with newline padding. Once that is created we need to:
1. Change the dbfilename to authorized_keys
2. Change the config directory to .ssh
3. Insert the contents of our text file into a “set” within the database
1) "Redis Sets are an unordered collection of unique strings. Unique means sets does not allow repetition of data in a key."
5. Save
6. Test to see if we can SSH in
We can see that this attack was successful, and we now have a shell on the system as the redis user. This user only has limited access:
While searching the system for files containing sensitive information, we discovered a file called “id_rsa.bak” in the /opt/ directory. The owner is shown as the “Matt” user and the contents reveal it is a private key.
Internet research reveals an article ( https://medium.com/@canarerobertjohn/basic-pentesting-2-325cafc19fcc ) with instructions for cracking a private key such as this to reveal the passphrase. The steps are as follows:
1. Convert the key to a format supported by JohnTheRipper
1) "John the Ripper is a fast password cracker, currently available for many flavors of Unix, macOS, Windows, DOS, BeOS, and OpenVMS"
3. Run JohnTheRipper on the converted key using a wordlist
Sorry for the small text... |
Within seconds we have revealed the passphrase, and using this information we want to see if it's possible to escalate our privileges to the Matt user.
The privilege escalation was successful, we are now logged in as Matt and have more access, but not to everything.
Additional testing reveals that the credentials for “Matt” also work for the webmin panel:
Earlier banner information revealed Webmin as being version 1.910, and searching for exploits reveals one:
Now we load up MetaSploit with this exploit and configure all of the options:
After running the exploit we have successfully obtained root level access to the system.
Remediation Recommendation
This server was able to be fully compromised due to a series of weaknesses that were easily exploited. We recommend:1. Closing ports to services that do not need to be publicly exposed
2. Removing banner information that can reveal software versions
3. Training your users not to leave sensitive information on the server in a directory readable to all users
4. Enforcing stronger password requirements
5. Patching all software to the latest version
No comments:
Post a Comment