How a SysAdmin becomes a Pentester PART 2

5 minute read

Billy

This post is PART 2, PART 1 is HERE

So in PART 1 we covered the first 2 points below with the third being covered in this post

  * a brief synopsis of how I got here from where I was
  * What a SysAdmin (in my opinion) needs to do in order to be competitive as a pentester.
  * An inside look at an actual pentesting scenario

An example of why the first two points are important (An inside look at an actual pentesting scenario):

So our client goes through a particular 3rd party for one of their applications, and during the penetration test, one of our seniors discovered that an API endpoint was vulnerable to SQLi due to unparameterised query sent via JSON.   They reported the vulnerability and provided the reproduction steps (again, both for proof and so the devs can test their fix) as well as what, in his opinion should be done to mitigate the SQLi, and this most certainly included the use of parameterised queries.  

Now in this situation a RETEST is required, to test the specific vulnerability found and make sure the vector is patched up, and also test that whichever fix has been deployed does not open any other attack vectors.  

And so a few weeks later I was told I would be the one to retest. I looked through the original job, made sure I could access the endpoint, reached out to the Project Manager to ensure that on the day of testing everything would be ready for me to go, and I would not have to chase anything up.   I started the test by immediately following the documented reproduction steps, as is obvious, if these are reproducible to the same effect then obviously nothing has been done.  

The steps did NOT work, in fact, all I observed in burp was that EVERY response was a 500 Internal Server Error… Hmmm.   So the server is no longer providing any verbosity in it’s response, but it IS telling me that the server came back with an error.   So I decided to see if I could get something other than a 500/prove code execution. The only real way to do this in this scenario is by trying to make the server timeout by injecting either SLEEP or WAITFOR or, well, you get the idea.  

Lo and behold, the below caused the server to timeout with a 504 gateway Timeout:

{
  json_val_1 : "foo"
  json_val_1 : "bar"
  json_val_1 : "foo"
  json_val_1 : "bar' waitfor delay'0:0:10'--"

}

zzzzzzz....  

Now, why is receiving 2 different responses a big deal?   Because it means that to a certain degree I am now in control.   My previous deep dive into sqli led me to the conclusion that I am now dealing with something called Blind SQL Injection.   It is pertinent to note at this point that all the devs has seemingly done at this stage is break the reproductions steps so that the security testing is a pass and their product can be released

Weaponising Server Responses

Now, the cool part:   Because whoever was responsible for patching this vulnerability up did not do so efficiently/correctly as per OWASP - I was now able to come up with proof of concept exploit, in which truth in a query is infered via the fact I control whether or not the server responds with a 504.   This may seem confusing, but consider the following: If we send the same payload in JSON as before, but with some added code, we can either prevent or cause the server from timing out with something called BOOLEAN logic, which very basically means: TRUE vsFALSE, or, 1 vs 0. We can say, “if 1=0”, or if FALSE, do nothing.   And adversely we can also say “if 1=1”, or if TRUE, wait for 10 seconds thus causing the server to timeout.

FALSE, NO TIMEOUT (because the first condition is not met, the second part of the query is not sent)  

{
  json_val_1 : "foo"
  json_val_1 : "bar"
  json_val_1 : "foo"
  json_val_1 : "bar' if 1=0 waitfor delay'0:0:10'--"

}

TRUE, TIMEOUT (because the first condition is met, the second part of the query is sent)  

{
  json_val_1 : "foo"
  json_val_1 : "bar"
  json_val_1 : "foo"
  json_val_1 : "bar' if 1=1 waitfor delay'0:0:10'--"

}

Now, this may seem arbitrary, but what if instead of saying if 1=1, we say, what if the first character of ADMINISTRATOR's password begins with A?   What we have now is the foundation for beginning a bruteforce attack, we can write a Python script that will assess the response from the server - if it is a 504? guess what - we have the first character of ADMIN’s password, then we send AA, then AB and so on, until we have a complete string.   This is a very contrived example however this is the exact logic I used to SHOW impact to the business.  

Retest no.3

So, after all this, and after pretty much the same vuln being found on the first retest you would think the devs in question would pull their socks up and fix the issue correctly, wouldn’t you?

No such luck.  

Long story short I was able to prove that all they had done was mitigate my particular attack through string matching/regex - which is a big no-no.   Unfortunately I was unable to re-exploit in my allocated time (pentesting is allllll about what you can achieve in the time you have). This however put me in a bit of a predicament, as I was unable to re-exploit the endpoint, but was not confident it had been fully patched.   This is where experience dealing with Project Managers/stakeholders/the non-technical side of the business can be utilised - I was able to communicate the situation in a manner that was non-abrasive yet concise, I essentially suggested that the business ask to actually see the code and steps taken to prevent the vuln, and if parameterisation was not being used, that it should not be deemed fit for release.

The last part of my blog regarding the SQLI and testing/retesting was a bit long winded I know, but I hope that the scenario in it’s entirety shows both how valuable the soft skills gained form working on System’s can be, as well as the need to understand what you are doing along with a grasp on programming logic.

If you have made it this far - you have reached the end of this post, thank you for getting the whole way through - and I hope that it has helped illuminate your path to becoming a pentester.

See you guys soon for another post - in the meantime I will continue to level up so I can dorn this fancy +5 mace I found :)))))

war3z