Magic
Reconnaissance: NMAP
┌──(kali💀kali)-[~]
└─$ sudo nmap -sC -sV -O 10.10.10.185
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 06:d4:89:bf:51:f7:fc:0c:f9:08:5e:97:63:64:8d:ca (RSA)
| 256 11:a6:92:98:ce:35:40:c7:29:09:4f:6c:2d:74:aa:66 (ECDSA)
|_ 256 71:05:99:1f:a8:1b:14:d6:03:85:53:f8:78:8e:cb:88 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-title: Magic Portfolio
|_http-server-header: Apache/2.4.29 (Ubuntu)
Aggressive OS guesses: Linux 4.15 - 5.8 (96%), Linux 5.3 - 5.4 (95%), Linux 2.6.32 (95%), Linux 5.0 - 5.5 (95%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (95%), ASUS RT-N56U WAP (Linux 3.4) (93%), Linux 3.16 (93%), Linux 5.0 (93%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 42.89 secondsWe have two ports open.
Port 22: running OpenSSH 7.6p1
Port 80: running Apache httpd 2.4.29
Enumeration: 22/tcp open ssh
OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
The OpenSSH version that is running on port 22 is not associated with any critical vulnerabilities, so it’s unlikely that we gain initial access through this port, unless we find credentials.
Enumeration: 80/tcp open http
Apache httpd 2.4.29 ((Ubuntu))
http://10.10.10.185/# http://10.10.10.185/login.php
view-source view-source:http://10.10.10.185/#
Viewing the page source doesn’t give us any useful information. Next, view Autorecon’s gobuster scan.
OPTION 1:
/upload.php Right off the bat, I see something that could potentially be very concerning. The upload.php & logout.php pages are internal pages (require authentication) that lead to a 302 redirect when a user attempts to access them. However, the interesting part is the response size. The upload.php response size is much larger than what a normal 302 redirect response would be. So if I had to guess, the PHP script is not properly terminated after user redirection, which could give us unrestricted access to any internal page in the application.
10.10.10.185/upload.php 10.10.10.185/logout.php
We can confirm this using Burp proxy. Visit the upload.php script and intercept the traffic in Burp. As can be seen in the below image, before the request is redirected to the login page, we are served with the upload page.
Now all we have to do is change the HTTP Status Code from “302 Found” to “200 OK” and we get access to the upload page. To have Burp automatically do that for you, visit the Proxy > Options tab. In the Match and Replace section, set the following options. Proxy > Options tab. In the Match and Replace section, set the following options.
Type: Responce header
Match: 302 Found
Replace: 200 Ok
Regex matck checked
OPTION 2:
SQLi Login Bypass: http://10.10.10.185/login.php
Clicking Login leads to /login.php, with a simple login form:
I tried a few basic logins like admin/admin and magic/magic without luck. I tried a basic SQLi login bypass of username ' or 1=1-- -, and it logged me in.
This works because the site must be doing something like:
So my input makes that:
That must satisfy the site’s logic, as it allows me in.
Shell as www-data
To check the filters on upload, I like to find the POST request where the legitimate image file was uploaded in Burp and send it to repeater. After making sure it successfully submits, I’ll start changing things to see where it break. There are three checks that a site typically employs with this kind of upload:
file extension block/allow lists;
mimetype or Magic bytes for the file must match that of the allowed type(s);
Content-Type header on the image must be image.
Some testing shows that there are at least two filters applied on upload: filename must end with .jpg, .jpeg, or .png and mimetype passes for images.
The second filter can be bypassed by putting PHP code into the middle of a valid image.
I’ll create a copy of my image and name it avatar-mod.png. Then I’ll open it with vim and add a simple PHP webshell to the middle of the file:
Upload PHP Webshell: On successful login, the browser is redirected to /upload.php:
Username : theseus | Password : iamkingtheseus.
Priv: www-data –> theseus
Looking at the home directories, there’s one user, theseus, and as www-data I can see user.txt but not read it:
Enumerating as www-data didn’t turn out anything obvious, so I went into the web configurations to see what I could find. The site is hosted out of /var/www/Magic:
db.php5 does have creds for the database:
Database Dump: Unfortunately, mysql, the binary I would typically use to connect to the local port and interrogate the DB, isn’t on the box. This is a case where having a full PTY shell on the box paid off, because when I typed mys[tab][tab][tab], it gave a list of things that were on the box:
It would have been not that hard to upload Chisel and create a tunnel from my host to the MySQL port (3306) listening on localhost on Magic, but mysqldump jumped out as an alternative. Once I figured out the syntax, it worked like a charm:
This tool dumps out SQL such that all the commands are here to rebuild this database. There’s one INSERT statement for the login table:
SU:
These creds do work to login without SQLi on the webpage, but they also work for su to theseus:
Priv: theseus –> root
Enumeration: Now we need to escalate our privileges to root. I downloaded the LinEnum script and ran it. It looks like the SUID bit is set for the sysinfo program, which means that the program runs with the privileges of the owner of the file. We can see that it runs the fdisk & lshw programs without specifying the full path. Therefore, we could abuse that to our advantage and have it instead run a malicious fdisk program that we control.
Any enumeration script will highlight SUID binaries, or I can find files owned by root with SUID set using find:
/bin/sysinfo is new to me, so I’ll check it out. It’s also interesting that only members of the users group can execute it, and theseus is the only member of that group:
ltrace:
Running sysinfo with ltrace prints out the calls made outside the binary. There’s a ton of output, but looking through it, there’s a line that jumps out at me:
popen is another way to open a process on Linux. The binary is making a call to fdisk, which is fine, except that it is doing so without specifying the full path. This leave the binary vulnerable to path hijacking.
OPTION1: I’ll create a reverse shell script in /dev/shm:
Give it execute rights:
OPTION2: In the tmp folder (which we have write access to), create an fdisk file and add a python reverse shell to it.
Now I’ll update my current path to include /dev/shm:
This way when we run the sysinfo program, it’ll look for the fdisk program in the tmp directory and execute our reverse shell. Setup a netcat listener to receive the reverse shell:
Then run the sysinfo command:
Upgrade the shell and get the root.txt flag
Last updated