Description
The Planets: Venus Date release: 3 Jun 2021
Author: SirFlash
Series: The Planets
URL: https://www.vulnhub.com/entry/the-planets-venus,705/Difficulty: Medium
Venus is a medium box requiring more knowledge than the previous box, “Mercury”, in this series. There are two flags on the box: a user and root flag which include an md5 hash.
This writeup is being created in real-time, so it includes a record of both my successes and failures as I progress through the challenge. This can be helpful for others to learn from my experience and understand the process I followed !
User(WebApp) part
- Nmap scan log:
> sudo nmap -sC -sV -p- -r 192.168.1.37 -vvv
Starting Nmap 7.91 ( https://nmap.org ) at 2021-06-22 18:58 CEST
Reason: 65410 no-responses and 123 admin-prohibiteds
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.5 (protocol 2.0)
| ssh-hostkey:
| 256 b0:3e:1c:68:4a:31:32:77:53:e3:10:89:d6:29:78:50 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBB+dV9A80/dgYSig2NEBJYcoRe6VFus7DqjGWjNYjN4FH4e8scrM8P9zuw8EYJTdIjDVeJbersbscUbJTTH3C+w=
| 256 fd:b4:20:d0:d8:da:02:67:a4:a5:48:f3:46:e2:b9:0f (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEG7ONqJEC7HEEiTZaI+MemunphhJ23BhWM0eLlcL/BJ
8080/tcp open http-proxy syn-ack ttl 63 WSGIServer/0.2 CPython/3.9.5
| fingerprint-strings:
| GetRequest, HTTPOptions:
| HTTP/1.1 200 OK
| Date: Mon, 21 Jun 2021 05:05:21 GMT
| Server: WSGIServer/0.2 CPython/3.9.5
| Content-Type: text/html; charset=utf-8
| X-Frame-Options: DENY
| Content-Length: 626
| X-Content-Type-Options: nosniff
| Referrer-Policy: same-origin
| <html>
| <head>
| <title>Venus Monitoring Login</title>
| <style>
| .aligncenter {
| text-align: center;
| label {
| display:block;
| position:relative;
| </style>
| </head>
| <body>
| <h1> Venus Monitoring Login </h1>
| <h2>Please login: </h2>
| Credentials guest:guest can be used to access the guest account.
| <form action="/" method="post">
| <label for="username">Username:</label>
| <input id="username" type="text" name="username">
| <label for="password">Password:</label>
| <input id="username" type="text" name="password">
| <input type="submit" value="Login">
| </form>
| </body>
|_ </html>
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: WSGIServer/0.2 CPython/3.9.5
|_http-title: Venus Monitoring Login
Nmap done: 1 IP address (1 host up) scanned in 243.85 seconds
- We have only 2 opened ports (22 for ssh) and (a webserver on port 8080)
Server: WSGIServer/0.2 CPython/3.9.5=> this is the webserver name
-
When we browse it, we see this message
Credentials guest:guest can be used to access the guest account. -
We can use the provided credentials to log in to the login form. If the login is successful, we will be presented with a simple HTML page.
- That has nothing interesting, So I had download the image file
venus1.jpgto continue my investigation.
-
I applied various steganography tools, but did not find anything unusual or hidden within the image.
-
“We can go back to the webpage, enable our Burp proxy, and log in again.
- In the first response header response header, we see that a new cookie has been set.
Set-Cookie: auth="Z3Vlc3Q6dGhyZmc="; Path=/
- It looks like the value of the cookie is encoded using base64. We can use a base64 decoder to reveal the contents of the cookie.
- The base64 decoder returned the value
guest:thrfg. The first part, guest, is clear, but the second part after the separator:is not immediately recognizable. It is possible that this value has been encoded using the rot13 algorithm, which can be easily confirmed using tools such as CyberChef. If the assumption is correct, then the decoded value would beguest.
It seems that our guess was correct, as the decoded value indeed matches the expected result.
- Despite attempting various types of cookie manipulation techniques such as SQL injection, command injection, …
I was not able to identify any vulnerabilities or achieve any successful results. It appears that the system is not susceptible to these types of attacks.
- So where is the bug ? I have determined that the bug lies in the fact that the system does not properly check the password value. Even if we remove the password value and the separator :, the system still allows us to log in. This suggests that the password is not being properly validated by the webapp.
-
Additionally, if we send only the base64 encoded username to the server, the auth value in the response will include both the username and password
base64(user:rot13(pass)). -
Great ! We are able now to retrieve the password of any valid user, so its time to fuzz for a valid username.
wfuzz -c -u "http://192.168.1.37:8080/" -d "username=FUZZ&password=elonmusk" -w WordList/raft-large-words.txt --ss "Invalid password."
- we got 3 new valid users:
guest
venus
magellan
- Let’s try to get the password of both
venusandmagellan!
-
The password for
magellanis:venusiangeology1989 -
The password for
venusis:venus -
I tried the credentials on SSH and I was able to login with
magellan.
- The user flag:
Root (Privilege Escalation) Part
- The root flag:
After some enumeration I came to this:
Active Ports:
- We have an unexpected port wich is 9080, let’s dig more …
-
Based on the information provided, it appears that this is a service that is being run by the root user !
-
We can confirm that the service is being run by the root by examining the process list.
- Information about the binary file:
The binary exploitation
This part was done by my dear friend datajerk.
Hope you enjoyed the walkthrough !