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.
Step 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)
Through the output, we can conclude that
Target Machine IP: 172.16.178.179
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
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.
nikto -h 172.16.178.179
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 Sep6 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
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?
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-dev
gcc -o OpenFuck 764.c -lcrypto
it is (small L)crypto
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.
This 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.