Last week I was interviewed for a job at a company which I am a big fan of. I got to know the competition were hard and that the company had sky-high standards. Somewhat at the end of the interview the interviewer asked me “Which method do you use for penetration testing?” Me being a bit nervous replied back “As of now I am defining our own method to fit the company I work for” The interviewer just said “OK” Then I instantly felt like I should have elaborated my answer further.
This brings me on track for today’s topic. I’m going to elaborate my answer over a couple of blog posts. First of we will be looking at a general method. In the next blog post we will be looking at the method which I have defined for my company.
So – why a method?
In general we use methodologies to manage processes. It can be regarded as a step by step list of what you should do to cover what you would define as a good job.
A method consists of several segments – think of it as sub projects with a defined goal and output that is to be used as input for the next segment. These segments also serves as identifiers to where you are at in the complete process. If your boss asks you “what’s the status of the project?” You can then reply “We are in the reconnaissance stage”. The boss would then know what would follow.
By following a method we can assure that all necessary steps that builds up to the report is carried out. In a perfect world – all known vulnerabilities has been applying and none has been left out.
A rouge penetration tester working without a method may hit his target with all kinds of vulnerabilities. Just like firing an automatic gun into the bushes in hopes of hitting something. He may hit gold. But he also may end up unlucky hitting nothing. Following a method does not imply that we will find everything – but the chances for hitting gold is much bigger.
Example method 1
With all the chat about what a method is let us look into an often used one. As far as I know it has not got a name (like Scrum, Kanban etc) – if it has please update me. I’ve taken the liberty to add some segments of my own into this to make things clearer.
Step 1: Customer agreement and project scope
Before testers can start a penetration test they must have a customer. The customer must state what output they expect from the tests. Testers ends up writing a report based on the competence level of the customer. Then the project scope shall be defined. This is done to make sure that testers do not test too much or too little. It would be silly to test everything – where does the limits go? For a website should external integrations be tested or are they to be tested on their own in a later project?Establishing boundaries is good.
A written permission for conducting the tests shall always be obtained. This is most often handled by the contract. But the customer may not own the server environment. A written permission from all involved parties shall also be obtained. Fragmentation is a bitch. Also, a written permission will let you work on the right side of the law. Hacking is a massive gray area.
Oops almost forgot. An agreement on the time frame is crucial. The testers need a fixed time frame to conduct the test. This will affect what is going to be tested, though. If the customer want it done in five days, then we must reorganize our test strategy to fit the time frame. Or else the test can go on and on in all eternity.
Step 2: Reconnaissance
A famous geezer once said that knowledge is power. And that is what this segment is all about. Reconnaissance is about digging up information about the target from publicly available resources. Resources includes search engines, domain registrars, banner grabbing, e-mail lists and basically whatever you imagine. Often, fixed lists of resources to use exists – if the testers should forget to check vital resources.
Step 3: Vulnerability Assessment
Armed with information from the reconnaissance segment testers will try to find out if the target is vulnerable. There are mainly three ways to do this in my opinion – automatic scans, manual work and a hybrid.
Automatic scans can be performed by tools designed for this kind of work. For now we’ll focus on testing web pages. Testers can use tools such as Acunetix Web Vulnerability Scanner or BurpSuite for this (many others exists on the market). These tools will scan through the website applying various known vulnerabilities and spitting out a report of what they find in the other end.
Manual work is when the testers applies known techniques to the website. SQL injection, CSRF, SQL injection, looking at the redirects etc. Automatic scanning tools are just hackers in a box – but they lack AI to understand what they have found properly. Better put in some humans into this mix.
Hybrid work is not the the best term – but here goes. Hybrid work is when humans applies exploits to a site in a targeted attack. Say you got an exploit for Apache which remotely crash it – a human will be executing the exploit and evaluating the result. Some may say that hybrid work is better placed in the Exploitation segment and some say it belongs in the Vulnerability Assessment segment.
Step 4: Exploitation
Notice that in the previous segment that testers worked to find out if the target was vulnerable. Now the time has come to exploit the vulnerabilities – aiming for establishing access to a system or a resource by bypassing security restrictions. Or, better stated, getting in.
Step 5: Root Cause Analysis
In this segment testers try to uncover the why’s. Why were these vulnerabilities there in the first place? By now testers are moving away from the target and looks at what lead to the vulnerabilities found.
Things they may touch upon
- Are the developers adequately educated?
- Is the software release process faulty?
- Is the management rushing it?
- Etc, etc.
This segment is very difficult since the customer may not want to expose the internal workings of their company – so testers include in their report various focus areas that lead to the vulnerabilities.
Step 6: Risk Assessment
We are almost at the end here now – so just hang on. Now the project is to be summarized. Findings are rated on how severe they are based on a predefined determination matrix. There are many formats on how to classify severities. At work we use a traffic light with 4 lamps. Green means that the finding is harmless but annoying. Yellow means unsafe practice but is not really that dangerous. Dark orange means almost the same but that the CIA triad is heavily breached. Red lamp means “Holy shit, send out the Batman signal!” This means hackers already has access to the system – or access is obtainable with a little effort. Listing the vulnerabilities without also mentioning how to mitigate is a big failure. Though – I have seen reports stating you suffer from this and that with no further explanation on how to mitigate. That leaves me with a fouls taste in my mouth.
Step 7: Reporting
It is time to present the evaluation of the target to the customer. Findings are put together to form a report in a an easy to read format.
Step 8: Follow up
The customer got the report. Great! A sad fact is – many customers just want the report to show off to their own customers so they can say “look, we take security seriously!”
To remedy this the testers may do a follow-up . Say – two months after the test has been conducted the testers phones the customer and asks how they are doing remedying the vulnerabilities. If the customer responds negatively the same procedure can be redone two months after. If still the customer has not done anything with the situation we’re not obliged to bug them further. It’s their call.
However -a customer may re-issue a test in order to validate things got fixed.
This was an example on how a penetration could be done. It may differ from your chosen method. That is fine. It seems like a common thing that companies extend a base method with their own preferred way to work. Anyhow – this was my effort to shed some light into a fascinating topic.
Next time I will cover how I defined a method that suited the nature of the company I work for.