Thinking outside the box when pentesting GraphQL
The hardest part when pentesting any system is undoubtedly answering the question:
What is meant is "how outside-the-box thinking works?", and "how is a pentester meant to think outside the box?".
Although tackling this question might seem like a near impossible task, but a good approach would be giving an example of a vulnerability that required "out of box" thinking, dissecting the thought process behind it while trying to answer the "why?" that might pop up.
Prophase
Before the actual hacking happens, a couple of questions should be answered, either consciously or in an implied manner.
First, think of what are you doing, and why are you trying to find vulnerabilities. Is it a pentesting task, or security research? if it is a pentesting task then consider looking more for known/already known vulnerabilities, on the other hand, while doing security research is where you try and innovate and try new things.
Next would be considering what would be interesting as a result. What results are important for you? Maybe you care about nothing but a Remote Code Execution, or maybe you care about everything even a reflected XSS.
Once you have all your answers you can start your hacking process.
The Example
The example we are going to use in this article is CVE-2022-31173, it's a vulnerability we found at Escape while doing DOS security research on Juniper GraphQL server.
So to answer some of the questions asked in the prophase, we are doing a combination of pentest and security research, and we were only interested in Denial Of Service attacks.
Basic Ideology
When doing any security research or pentesting it is essential to check prior work done on the same field you are tackling, and in our case one of the DOS attacks we found on GraphQL servers was CVE-2022-21708
To briefly explain how this vulnerability works, sending a recursive fragment as follows to a vulnerable server would cause a stack overflow causing the server to crash:
query {
...X
}
fragment X on Query {
...Y
}
fragment Y on Query {
...X
}
For the Escape Security team, this had some implications that could be made:
- The stack can be filled with fragments call
- The stack is not properly protected since the CVE-2022-21708 was patched using similar techniques to query analysis.
So we asked ourselves, how can we cause a stack overflow again? What can we do?
Note
Having a clear view of what we need to achieve transforms the "Thinking outside the box" problem into one small problem that needs a suitable solution.
In our example, it transformed the problem of wanting to DOS a server into the question: "How do we fill the stack with fragments without a recursion?". Essentially they are the same question but the latter is easier for the brain to process and more likely to be solved.
Our solution
We decided to go back to the basics, we know that a query like this would cause one fragment to be in the stack at one time:
query {
...X
}
fragment X on Query {
__typename
}Another one would cause two fragments to be in the fragment at one time, try to stop reading and figure out where is this going:
query {
...X
}
fragment X on Query {
...Y
}
fragment Y on Query {
__typename
}
If you thought of increasing the number of fragments even more then congrats, you just thought outside the box! what we did is kept increasing the number of fragments until we hit 7500 fragments and it happened, the server crashed!
If you want to catch recursive fragment vulnerabilities and 50+ other GraphQL security issues (DOS, resolver performance, N+1, tenant isolation, complexity, sensitive data leaks…) before it's too late, check out our GraphQL Security Scanner! 🚀
– 1-minute install / free pentest report / no credit card required!
Conclusion
Thinking outside the box is sometimes what differentiates between a good and a great security expert but I am a deep believer that creativity is a muscle that could be trained, I hope through this article I was able to facilitate the creative process of finding the vulnerability.
HACK THE WORLD!
Learn more
đź’ˇ Want to learn more about pentesting & GraphQL testing?
Read our blog articles: