Offensive Security passionaries believe that hackers should always “Try Harder!”. Generally, I respect this position. But what hackers usually forget is that efforts in different stages of the Penetration Testing Cycle are different. Particularly, while doing information gathering, an attacker should try as hard as he can to understand the system – and, as a result, to find vulnerabilities. However, while doing exploitation, an attacker should concentrate his efforts to feel comfortable with the vulnerabilities he uses. And these two processes are quite different.
While doing active information gathering, an hacker looks for vulnerability and tries to find some restrictions somewhere. You go to the most limited access you can go, go to the weirdest configuration. You try to be “a birdie in the cage”, and you try to increase your sizes while looking for a smaller cage. This happens all the time.
Then, when you are a big birdie in a tiny cage, you note all the parameters of this cage. You feel each cage as it’s your home, as your fresh bloody pieces of flash aggregate the zink of your beloved cage roads. And you like that.
After checking a lot of different cages, some hacker decides to move to the exploitation phase. In terms of birds, he goes to the cage, closes the lock, and tries to maximize his control in this situation. And it’s time to relax. Try harder to feel comfortable. Time to accept the context and to temporarily stop looking for cages. Take a deep breath and prepare environments for testing: create virtual machines, download a comfortable IDE, increase the font size in your terminal. Clean the desktop, and allocate some time in your calendar for the smooth research. By the way – just in case that the vulnerability doesn’t exist, an attacker must be sure that the problem is not at his side.
Now the example and the promised quality-of-life stuff. This example shows how the active information gathering through fuzzing can evolve to exploitation in the right way. For simplicity, we talk about an SQL injection and SQLMap, but the tool and the vulnerability certainly might be different.
Let’s find an SQL injection.
On the screenshot, we see that the SQL injection probably occurs. For better control, an attacker might enforce SQLMap to send its request through some proxy. That provides us with bigger freedom. The tool “proxychains” works fine for it; otherwise, we could use sqlmap –proxy flag, or modify SQLMap program itself. The proxychains config:
strict_chain http 127.0.0.1 8080
Works fine, so we clean the SQLMap logs and run the application again. We turn intercept off, go to HTTP history, and send the latest request to Repeater. Now we have much more freedom and control.
In case we need even more control, we could use “Copy as Python-Requests” burp extension.
We could use Wireshark to thoroughly inspect what this script does. We note, that, generally, an SQL injection does not require a deep level of understanding of networking.
The whole exercise requires less than 5 minutes, however, leads to the next results:
- We now can see exact SQLMap behavior.
- We can inspect the requests, we can send them to the Burp Repeater.
- We can fully control the requests with Python, and we can create Proof-of-Concept easily.
And this way of getting control is stable.