Lazy

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 4000 10.129.64.184                 
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-19 14:11 +08
Nmap scan report for 10.129.64.184
Host is up (0.0075s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Did a detailed scan too:

$ nmap -p 80 -sC -sV --min-rate 4000 10.129.64.184 
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-19 14:11 +08
Nmap scan report for 10.129.64.184
Host is up (0.011s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
|_http-title: CompanyDev
|_http-server-header: Apache/2.4.7 (Ubuntu)

Since only port 80 is open, we can proxy the traffic through Burpsuite.

Web Enumeration -> Padding Oracle

The website shows a really basic company website:

I created a user and logged in to view the same thing:

In Burp, there appears to be a custom cookie being sent to the website called auth:

Although the website was written in PHP, this cookie was not the default PHP session cookie that was used. I tried to change a few parameters for it and found that the application returned a unique error:

This is an obvious hint that we have to somehow use the paddling oracle attack for this. This attack basically gives us a computationally feasible way to brute force the plaintext byte by byte using the error. Here's a pretty good video from college that I used:

We can attempt to decrypt this cookie using padbuster.

There seem to be 2 errors, 1 of which returns a length of 1133 and the rest are likely errors. I continued with test 2 since it had a higher frequency.

After a bit, padbuster returns the plaintext like this:

So the cookie decrypts to give us user=test123, and using padbuster again, we can encrypt it to something like user=admin. This would give us another cookie to work with:

When we access the website with this cookie, it tells us we are logged in as the administrator:

It also gives us a private SSH key to ssh in as the mitsos user as indicated by the URL:

Privilege Escalation

Backup SUID -> PATH Hijack

We don't have the user's password, so we cannot check sudo privileges. The user's directory has an SUID binary:

When used, it prints out the /etc/shadow contents:

The hashes in this are normally not crackable, and I don't think the creator would be so kind to give us the root hash directly. The file was an ELF binary:

I used ltrace to see the functions used:

This binary did not use the full path for the cat command, thus allowing us to create our own malicious binary within any directory to execute commands as root.

To exploit this, execute the following commands:

Rooted!

PreviousJupiterNextLightweight

Last updated