“How the hell did you circumvent that security?” asked the systems architect in the Slack channel we had open for communication during the penetration test.
He was referring to how I could possibly have just committed a (benign) file called PENTEST.txt to their private code repository on Github during the penetration test of their financial services app. There was a time when the actions I had taken (discussed later) were bordering on magic, when penetration testing was some kind of dark art that was looked upon by some with a mix of fear and respect. Modern penetration testing is quite different I believe. There is much less secrecy, much more clarity over methodology and techniques, there are literally millions of blog posts that explain how to approach penetration testing and giving great detail on performing complex attack techniques. It is a professional service.
There are organisations that create and manage standards on how to approach a penetration test. There are professional certifications that individuals can obtain to demonstrate a certain level of knowledge and experience. Yes, absolutely, those l33t, no-one-saw-it-coming hacks still go on and there is the top 1% like in any specialist field but on the whole, penetration testing has grown up considerably in the last ten years or so and it is rare to discover an entry point into an application or system that is truly original.
Brace yourself, the market is shifting
For this reason, we have also seen the inevitable commoditisation of penetration testing. As the mystery of penetration testing reduces and companies understand more about the types of attacks, why they matter and how to protect against them, it is inevitable that some penetration testing companies will find it harder to differentiate their service and resort to competing on price. There is at least one large company in the UK penetration testing market from whom you can now buy a “penetration test” for a fixed price complete with online shopping cart checkout.
Going all Kübler-Ross
Discovering this made me undergo pretty much a full Kübler-Ross Change Curve. I was initially shocked, I couldn’t believe what I was seeing. I wasn’t shocked at the price (though it's certainly at the bottom end of the market), that’s all relative, but at the fact that an activity such as a penetration test could be reduced to a fixed price - and inherently therefore - a fixed effort endeavour, without discussing what’s being tested.
At the price stated and at current market rates I’d say there's a maximum of three days' effort involved for that company to deliver a test like that. It’s certainly possible to perform a decent test in three days but that is highly dependent on both the target's size and complexity and the level of assurance required. It is impossible to provide a fixed price up front for a network or an application you’ve never seen without compromising on something. You’re almost certainly going to get a reduced scope and lower level of assurance whichever way you come at it.
After a short period of frustration and grumbling, I arrived at acceptance (I should point out this entire process took a matter of minutes). Inevitable commoditisation. The buying community is changing. The diversity of 4ARMED's own client-base is constantly changing as we receive enquiries from organisations that would never traditionally have looked for security assurance. There are lots of reasons for this but contractual obligations seems to be a key driver.
The era of disruptive small, technology companies is well and truly upon us and for all of the well known business-to-consumer brands the average member of the public is aware of there are thousands of business-to-business platforms too, all vying to revolutionise company procedures. Many are punching well above their weight in terms of their company size versus the blue chip clients they are now supporting. With the right product it doesn’t matter how many people you have, if you can scale you can play too.
Going are the days of the accounting system on the company server in the office, when expenses were entered into a spreadsheet, emailed to Finance with approval from your manager for them to rekey it or, if they're lucky import it, into that system for payroll processing. Now for many the accounting system is cloud-hosted and staff have an app on their personal mobile phone that lets them photograph their receipts and enter their expenses on the go.
This is just one simple example of how backend business processes are evolving but organisations still need to know their data is protected. So they often ask the provider to perform a penetration test and the provider looks around, gets some quotes and commissions a test. How that organisation approaches the procurement process for the penetration test is entirely dependent on their own risk appetite, security maturity, experience of buying penetration testing services and how specific the requirement from their customer is.
This is why I completely understand and accept the emergence of this method of purchase. It is filling a customer need whether I agree with it or not.
But is it a penetration test?
If you're thinking of buying one of these tests it's vital you understand what you are getting and what you are not getting. The company selling them is very clear about this when you dig a little deeper. It's a "Level 1" test (their definition, not ours, we have a different one). Not to put too fine a point on it, you're paying for an automated scan with a few manual checks. The only really skilled part of the process is interpreting the results and writing a report that (presumably) is actionable and useful.
That's not a penetration test.
If you've never had a penetration test before the report is likely to contain a reasonable amount of low hanging fruit and things you'll want to resolve. It will add some value for sure but it's also highly likely you wouldn't want to show this to a current or potential client.
Beautiful unique snowflake
What is also missing is the understanding and context of your network or application. It is a beautiful and unique snowflake, especially if it's a web application. Scanning will find vulnerabilities and quickly. We use them at 4ARMED as part of our methodology, absolutely. Penetration testing is a time limited service no matter how long you've scoped a test for, so the quicker you find things the better for everyone but scanners lack understanding of the application and for some apps just flat out don't support the technologies used.
Besides, finding vulnerabilities is only one part of a penetration test, exploiting them is the key difference between this and a vulnerability scan or security review. Consider the issue mentioned at the start of this article. The ability to commit code to our client's GitHub repository could have been used in all manner of nefarious ways. Code committed to their repo was automatically compiled and pushed as part of their Continuous Integration process. Providing any code I committed passed the build stage I had virtually free reign to add code to their app.
This could have been used to dump arbitrary data from their data store, attack their users or siphon financial data from the transactions passing through the system.
Behold! The magic!
Yet this level of compromise could not have been detected by a scanner. The attack involved chaining together a few different issues. The application presented a JSON API which was part of our testing. We could almost stop here as most scanners don't understand JSON. However, it was utilising a Java framework that relied on the value specified in the client's Content-type HTTP header. I tried changing this to application/xml and converted the JSON to equivalent XML and found I could perform API functions exactly the same. With XML in play I found the API was vulnerable to XML External Entity attacks which allowed me to read arbitrary files from the web server.
Up to this point a scanner might have detected this vulnerability however, the next part there is simply no way to automate. It needs a human. I browsed around the filesystem of the web server until I came across an SSH private key file. It was not protected by a pass phrase so I copied the encoded text out of the XML output and on my local testing machine I created the same private key. Further browsing in the application document root yielded the GitHub repository information and, you guessed it, I used the SSH private key to access the repository.
There are a number of recommendations that needed making around this issue. The XXE itself obviously needed resolving but there were improvements around the deployment process, protection of SSH keys and the privilege the keys had in the GitHub repository also (it didn't need write access). Note that many of these items would traditionally fall under the remit of a build review rather than an application penetration test.
The specifics of this issue was not the purpose of this article though. I wanted to highlight the value a specialist, third party penetration test can add to your organisation. A properly scoped test delivered by skilled and experienced staff can not only tick off your external compliance or contractual requirements but add a massive uplift to your real world security too.
Preparation is key
If you are looking for a penetration test, rather than buy a Level 1 anything I'd recommend you read our developing series on how to prepare your networks, systems and applications. We'll show you some relatively straightforward steps you can take to remove the low hanging fruit, instantly improve your security posture and drive more value out of a penetration test by allowing the testing team more time to focus on human-only issues.
If you're worried about what a proper penetration test might uncover and the amount of work it might present for you, remember two things.
- We're on your side, working with you, not marking your homework.
- If there are issues, they are already there. Better that we find them than someone with different intentions.