Getting the most from your cyber security assessment.
When requiring a Penetration Test, many businesses will shop around for the cheapest offering.
Shopping around for the cheapest deal isn’t necessarily the best route to take, particularly when it comes to cyber security, just like the old adage “buy cheap, pay twice”.
By spending more on a comprehensive Penetration Test, you can ensure that skilled professionals with extensive knowledge and experience are conducting the assessment.
Cybersecurity is a complex field that requires expertise, sophisticated tools, and comprehensive analysis. Higher investment can allow for higher quality services to be delivered by a set of professionals who are knowledgeable in their dedicated field.
Penetration Test vs Vulnerability Scan
Recently we undertook an engagement for a customer that clearly demonstrates the difference, between the different service levels available to organisations. Too often customers pay for a penetration test and receive a vulnerability assessment, this is often because they have purchased a service based on price.
It is really hard to differentiate service offerings in this space – you can either join the race to the bottom on pricing or you can differentiate on quality, which is what we try to do.
An automated scan and findings can be run in a matter of minutes, but what does this actually tell you about your organisation's security posture? Do you know what the impact of these vulnerabilities are? What does this mean if your system or network was compromised?
Understanding the value of a Penetration Test
A Penetration Test we conducted recently was on an educational platform with three levels of user – pupil, teacher, and administrator.
During our testing we discovered a relatively common vulnerability known as Cross Site Scripting or XSS. From the OWASP page on XSS:
“Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.”
We have seen multiple reports given to customers from previous tests with generic XSS findings, nearly always accompanied by the typical XSS evidence showing an alert dialog popping:
More often than not, in the reports we have seen, the finding is verified and evidenced, and the tester moves on to the next finding.
All too often we have seen these issues pulled out as not being too severe due to other mitigations that would prevent something like session hijacking where the target victims’ cookies could not be stolen due to correct cookie security configurations.
Having spoken to the client in depth prior to starting the test, it was clear that one of their primary concerns was ensuring the academic integrity of the platform, meaning that pupils should not be able to interfere with the application in any way.
So, for this client we have a serious vulnerability – but how do we translate that into client specific findings that will allow them to easily present the issue to other business areas and obtain budget and buy in to be able to remediate the issue?
We deep dived into the issue to demonstrate an attack path that spoke directly to the client’s concerns by chaining multiple issues together to achieve a complete platform takeover from the lowest possible user role.
It took a few hours to get it to work, having to bypass some input length limitations, bypass the basic XSS defences the client had, create a fully functional payload to re-write the HTML of the page and mimic the POST to the CreateUser endpoint complete with correctly formatted JSON but that extra effort gave the client exactly what they needed to address the issue.
Conclusion
The result meant the client could present the findings directly to stakeholders, without the issue being lost in technical details or wordy hypotheticals. A solid, reproducible, well evidenced vulnerability was proven to exist.
That’s the service we provide here at Cybaverse, not just sending a report based on an automated tooling’s findings, but listening to our clients and ensuring that the report is tailored to their requirements. The output we provide should be actively useful to the client rather than just a list of findings from a tool and recommended remedial actions.
And that is what occurred to me during testing.
I am sure that the majority of tests performed against this platform would have simply highlighted all of the same vulnerabilities that we discovered (we don’t have any secret sauce for testing, just effort and skill), but would have failed to contextualise them for the client.
We are security partners for our clients, not just a one-time deal, thank you for your order, here is your report and invoice. That means we take the time to understand the technical requirements for testing such as scope and the business requirements. Without understanding the latter, we cannot produce output that is relevant and targeted for the client.
And that is the Cybaverse difference.