SQL injection is the most common penetration technique employed by hackers to steal valuable information from corporate databases. Yet, as widespread as this method of attack is, a seemingly infinite number of ‘sub-methods,’ or variations of SQL Injection attacks can be carried out against the database.
Two common variations of the SQL Injection exist. Both are code injection techniques that exploit security vulnerabilities.
The most common technique is exploiting a lack of user input filtering on web pages or application user interface elements. This technique will often result in the pass through of string literal escape characters that end up embedded in SQL Statements and allow for the execution of malicious SQL code using the privileges of the web application process. One indicator is the presence of an odd number or quotes in a SQL Statement. For example in an Active Server Page a SQL string can be created as follows:
dim sql
sql = “select * from products where pname = ‘” & request(“name”) & “‘”
The application substitutes the pname variable with the value entered into the HTML form by the user. It then runs this SQL statement and displays the returned record set. An attacker will first attempt to detect a SQL injection flaw by trying a single quote and observing the error returned. By inserting a single quote, the following invalid SQL statement is generated and throws an error:
select * from products where pname = ”’
If an error is returned the attacker now realizes there is a SQL injection vulnerability and will attempt to exploit it.
Another common technique used to exploit a SQL injection vulnerability is to insert SET NOEXEC ON into the SQL. This causes the first statements in the SQL to fail and allows the result of the attack statement to be returned to the browser.
Similar to the web-based variant, SQL Injection in the DBMS exploits the passing of SQL commands as a parameter of a function or stored procedure. This will then execute the malicious SQL commands in the context of the component that provides the called function. Often this is done using components with system or admin privileges, resulting in privilege escalation.
One example would be the SYS.DBMS_PRVTAQIP package of a common Database Management System that contains procedures that are susceptible to SQL Injection and allows any user with EXECUTE privileges to execute commands under the elevated privileges of the SYS user.
Typically, when executed through a web front end, these attacks will not necessarily be caught by firewalls since they are using Port 80, and are hidden as part of the regular POST data when submitting a web form. A good database activity monitoring solution (DAM) is able to identify these attacks by looking at the actual SQL code submitted or executed on the database back end.
Every time patches to DBMS systems are released, the race is on. The bad guys will reverse engineer the patch to understand the fixed vulnerability and add it to their arsenal of attacks. DAM vendors will do the same in order to create new signature sets that will indentify these vulnerabilities and attacks.
Similar to how anti-virus solutions work, it is important to continuously update the set of signatures used by an activity monitoring solution. Since it is typically not possible to patch all databases in an enterprise environment all at once, identifying and monitoring the vulnerabilities provides much needed interim security.
[block:block=47]
Another important task is to regularly perform vulnerability assessments, which consists of checking and testing configuration settings and identifying vulnerabilities. Following these guidelines will help to put an organization in a position to remediate against potential vulnerabilities and be aware of any attempted attacks.
Alex Rothacker is the manager of the Team SHATTER research team at Application Security Inc. You can follow him on Twitter at @TeamShatter.
