Most of my focus these days is on User Agents, we are going to do a browser insecurity panel at SANS Boston 2016, but somehow one of my Google Alerts triggered a recent OWASP SQL presentation on a series of methods to improve the scanning speed of Blind SQL Injection attacks.
"Blind SQL (Structured Query Language) injection is a type of SQL Injection (SQLi), attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection." OWASP Veracode has a nice graphic on SQL Injection that they allow you to place on your website.
Programmer Interview gives an example: "We said that loading the URL “http://www.mybigspace.com?id=1008 AND 1=1″ might result in mybigspace.com running the SQL above – the reason we said might is because of the fact that it depends on whether the server would allow the extra characters after the 1008 to be injected into the SQL."
NOTE 1: the string AND 1=1 is VERY common and tools such as IDS/IPS/DLP/Web Firewalls should report these attempts to the SIEM. Should be OR 1=1. Reason is select * from user where username = 'x' and 1=1 does not change the logic. However, select * from where username = 'x' or 1=1 now returns all rows. If you want to learn more, you may want to reference OWASP SQLi prevention cheatsheet (https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet).
NOTE 2: Mitre makes some additional comments however filtering union/select/insert as they recommend could have significant unintended consequences. That said, recommending strong input validation is always true with any interaction with software. If the database developers properly escape inputs, there should not be a problem with a user having the username of "'; drop database allthethings --" " Perhaps the webcomic XKCD explains it best :)
Other classic common examples including the use of sleep(), can be found here. There is a, (slightly boring), Youtube demonstration of Blind Injection available here.
This is not a new technique, one of the early talks on the subject was at Blackhat in 2004 where Cameron Hotchkies discussed automating the process. His process to search for integers was as shown:
"Select a range (usually starting with 0)"
• Increase value exponentially by a factor of two until upper limit is discovered
• Partition halfway between upper limit and previous value
• Continue to halve sections until one value remains"
Once there is an established technique such as the one above by Hotchkies, or the one below by Makan, tools to automate exploitation are developed. The open source sqlmap continues to mature as a tool aiding with identification of SQL injection vulnerabilities. Recognizing how rampant SQLi continues to be, most web application scanners have SQLi scanning modules. The idea of automating these tests eventually led to the creation of Burp Suite, There is an excellent GIAC Gold paper on the tool here. Another popular tool, the OWASP Zed Attack Proxy also includes SQL injection modules.
It is generally agreed that Blind SQL injection is slow. This leads to the observation by Keith Makan at a recent, March 23, 2016 talk that is hosted on YouTube: https://www.youtube.com/watch?v=7WA9Muvt4Sg
Essentially, the idea is to automate the "Is it bigger than a breadbox". His slides are available here: https://drive.google.com/file/d/0B0tB... As we seek to optimize our databases we also make them more predictable.
Summary, (or, if I am a manager why do I care?). This has been a long standing source of vulnerabilities and introduces risk to most web based applications. Risk with a simple and well known countermeasure, always validate user inputs. Some articles you may want to review for further information:
"14 Years of SQL Injection and still the most dangerous vulnerability" (https://www.netsparker.com/blog/web-security/sql-injection-vulnerability-history/)
"The History of SQL Injection, the Hack That Will Never Go Away" (https://motherboard.vice.com/read/the-history-of-sql-injection-the-hack-that-will-never-go-away)More and more data is stored in databases that can be queried from the Internet. These queries have been around forever and are getting better and faster. The good news is they are somewhat predictable and are VERY noisy. In addition to validating input, if we are monitoring our databases for more than just performance, the odds are quite high we can detect Blind SQL injection in the early phases of an attempted attack. If we are not monitoring our databases, the odds of a successful attack just increased, again.
