Pentest or Penetration testing is a type of mission during which we “attack” the infrastructure/application we agreed upon with our client. The goal of the attack is to improve the security of their system. To do so we provide remediation to every vulnerability we found. A Pentest mission is short in time: we have around one week to test and write the report. As the mission is short it’s important to have clear rituals and a methodology to help us. During a Pentest we can find three major rituals. The first one is the kick-off
Kick-offs are usually on Monday morning at the start of the week. During this meeting, we are going to validate:
Every day we are doing a Daily with our PO. During this time we sum up our findings of the previous day and detail our daily goals.
This meeting can assure that we are still aligned with the PO and as the Pentest is to help the client it’s still a moment of exchange to explain our way of thinking to the client. It can provide interesting leads, it’s important to remember that our goal is to help the client which here is the PO. The meeting is not just one-way communication.
The last important ritual is the Restitution, it concludes the week. It happens quite a lot on Thursday in order to fix some details in the report on Friday.
This meeting gives us time to detail our findings and exchange them with our clients. It’s important to know beforehand who will be here in order to adapt the technical details in it.
Now that you know a little more about the week organization we can detail the process of the Pentest.
First of all, it’s important to know that in order to help us we are not starting from a white page with every Pentest. We have a list of the main vulnerabilities to check based on the OWASP top 10, our previously done Pentest, and the technologies used by the client. This helps us to quickly start a pentest and understand the service we are attacking.
The first step is to discover the system you are in. Depending on the type of pentest, you might already know the attack’s surface. The goal of this part is to identify the main component of the system you want to attack. For example, what type of server is running? which ports are open on the server? What technologies are used at the front of the application?
With this, you can establish a quick schema of the infra you are facing. With this schema, you can list a quick overview of the potential point of attack possible. In order to detail, your findings and your process to the PO this schema will be really useful.
Now that you know what to do it’s time to practice!
This part is where you actually are testing vulnerabilities. Depending on your target server, Kubernetes cluster, network, or website you have a huge list of tests to do. What you need to keep in mind is the stakes of the client.
For example, not so long ago I was working on an API where blob content privacy was the key for our client. After the discovery part, we found a GraphQL backend: our first test was to check if the introspection was enabled. With a simple request, you have access to all the API endpoints available and their usage:
{
"query": "query IntrospectionQuery{__schema{queryType{name}mutationType{name}subscriptionType{name}types{...FullType}directives{name description locations args{...InputValue}}}}fragment FullType on __Type{kind name description fields(includeDeprecated:true){name description args{...InputValue}type{...TypeRef}isDeprecated deprecationReason}inputFields{...InputValue}interfaces{...TypeRef}enumValues(includeDeprecated:true){name description isDeprecated deprecationReason}possibleTypes{...TypeRef}}fragment InputValue on __InputValue{name description type{...TypeRef}defaultValue}fragment TypeRef on __Type{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name}}}}}}}}"
}With this, I start to look for every query regarding blob content. I found several major issues like adding content to other users and removing content from another user.
The two things you need to do during this time are:
To win time and not forget anything it’s important to write everything you found or test.
Taking notes during the pentest is a must, as I detailed before you need to remember everything you found. One miss-configuration might not be critical but it can give you some data that might be needed afterward to exploit another vulnerability.
For each finding, you need to keep a trace of your test, the result, and an example if needed. It will help you to write the report. You can also use it in the following daily to explain the vulnerability to the PO. Why do you need to explain the vulnerability to your client as soon as possible? He might give you more info or some direction in which you can exploit the service with what you found.
As you can see the coverage of technologies is huge when doing a Pentest. It’s important to always train yourself in order to perform. At Padok we have a lot of ways to keep ourselves up to date for example University or Rikai. Here is an article in french detailing how we train ourselves at Padok.