I'll keep the second payload at 48-126 (0-9, A-Z, a-z). Hopefully the table is 10 characters or less in length. I'm not trying to be sneaky, and blind SQL injection is inherently not sneaky, so I'm just going to guess the length and set the first payload to 1 through 10. How about the SQL syntax, " ' if (ascii(lower(substring((select top 1 name from sysobjects where xtype=char(85) and name like ' %user%'), 1,1)))= 100) waitfor delay '00:00:30'- ?" This looks for a table that has the word "user" anywhere within. Payload 1 value 3 = payload 2 value 111 which is " o"ĭbo, a good proof of concept but we could have guessed it.Payload 1 value 2 = payload 2 value 98 which is " b".Payload 1 value 1 = payload 2 value 100 which is " d".Sorting the results by length will put all of the 0-length, timed out, "true," responses in line. Running this attack should yield the three ASCII codes for the SQL "USER" variable. Since we're asking for a username, I doubt there are any special characters (32-47) in it so we'll just be lazy and use 48-126.
BURP SUITE SQL INJECTION CODE
In our SQL syntax above, you'll notice that we're using the " lower()" function to reduce the number of ASCII code values to guess but our number range will include them anyway so we're not saving any time there. The first payload needs to be numeric and range from 1 to 3 since we know that's the number of the character positions whose ASCII codes we want to guess.įor the next payload, we look up our ASCII codes and ponder a bit. One is the position of the character and the second is the ASCII decimal code of the character in that position. This time the SQL syntax will be " ' if (ascii(lower(substring((user), 1,1))) =100) waitfor delay '00:00:30'- " and there are actually two changing payloads (highlighted in bold). Just open another Intruder tab and we'll change the attack quite a bit. When the correct payload number is guessed, the application will pause for 30 seconds, expiring our 29-second Burp timeout value.Īt this point a good thing to know is what those 3 characters are that comprise the "USER" variable's length. Now we should get the length of the "USER" variable in the SQL server when this Intruder attack is started. One more thing to do is to set the Intruder threads to 1, otherwise when one thread delays the SQL database, the others will be delayed as well and false positives will abound. The SQL question is "How long is the USER variable?" Using a numeric payload, we'll guess 1 through 30, a wide margin indeed. Now that the payload position is marked, we need to define the payload. " It's also necessary to now mark our payload position in Intruder. This time the SQL syntax, " 'if (len(user)= 1) waitfor delay '00:00:30'. Ok, now we'll send our delay injection request over to the Intruder tool. Let's set the HTTP timeout length from 60 seconds to 29 seconds in Burp's timeout options. That's all just great but we want to do better than just pause the database during our login query. The vulnerable web application will pass this SQL command directly to the login query causing a 30-second pause. We can send this request to the Repeater tool and inject the SQL syntax, " ' waitfor delay '0:0:30'- " (omit the double quotes). The first thing we do is identify the vulnerable request: I'll demonstrate some techniques below and use HacmeBank as a target even though errors are completely visible in this purposefully vulnerable app and blind techniques are not necessary. Sometimes this just isn't in the cards for a variety of reasons and you just want to show proof of concept that you can pull back sensitive data through the web server. These tools can do more than just extract database data. SQLMap is a good one but there are a lot and your success will vary. Many of these are installed and ready to run on the BackTrack 4 R2. There are plenty of SQL Injection tools out there that will work with blind or error-based vulnerabilities. with SQL injection in general still being used to great success in the wild. That is fine because blind SQL injection is still relatively easy to exploit. To take a rough guess, I'd estimate this to be the case at least 8 out of 10 times. These days, the SQL injection flaws that I am finding are largely of the "blind" type. It's very easy to use a variety of methods to cause errors to display database names, table names, column names, and even row values. SQL injection used to be a lot easier a few years ago when it was less known, web application security was less mature, and errors were often exposed.
0 kommentar(er)
