The way that Yahoo! was hacked, SQL Injection attack, is the same method as many other hacks in the news recently: SQL Injection. SQL Injection attacks are common for the following reasons:
     •    The prevalence of SQL Injection vulnerabilities
     •    Databases are attractive targets because they typically contain critical application information
     •    The approach (i.e., the hack) is not new and is well documented on dozens of forums

While Tech Crunch reported that many users were employing ridiculously weak passwords such as “12345” and “password”, having a strong password, as I wrote about recently in Fighting back against Anonymous, LulzSec and the global cyber insurgency, is worthless if the site servers or applications are not configured or patched appropriately.

So, what is a SQL Injection attack?

The point of an SQL Injection attack is to compromise a database, which is an organized collection of data and supporting data structures. The data can include user names, passwords, text, etc.

Structured Query Language  is the programming language used to manage data in a database; more appropriately, a relational database management systems (RDBMS). The types of management systems that employ Structured Query Language include Microsoft SQL Database, Oracle, MySQL, PostgreSQL, and others.

A simple example to get basic table name information would be the following:

Select * from table_name :

This statement uses a wildcard (*) to return the contents of the table. The hack could also include inserting information into the database, like a new user for the purposes of doing bad things.

insert into users(username,userid) values("HackerBob","hb123");

The point of the hack is not just to get information from the target site. Depending on the intention of the malicious hooligans attacking you, it can include to bypass logins, to access data as in the Yahoo! case, to modify the content of a website as when hackers replace the website with a new front page, or simply shutting down the server. Often it is a combination of the above.

Step one of the attack is to scan sited to see if a vulnerability exists. Believe it or not, a hackers best friend is Google. Employing Google Dork, a hacker is able to search for vulnerabilities using Google tricks. After a site is identified a hacker will attempt to gain a foothold and search for files containing usernames and directories that are known to contain sensitive data.

The attack is opportunistic and does not take a lot of research or a large team to pull off. Infact, you can go to Google directly and enter one of the following commands as illustrated in a Ethical Hacking Tutorial online:

     •    inurl:index.php?id=
     •    inurl:gallery.php?id=
     •    inurl:article.php?id=
     •    inurl:pageid=

From the listing of sites that Google returns, you will then need to checked each site for vulnerabilities.

www.TargetSite.com + inurl:index.php?id=

In fact the first site that comes back when you run inurl:article.php?id= in a Google browser is also the topic of discussion on a hacker site HackeForums.net. The discussion starts:

“http://www.targetsite.org/article.php?id=129. SQL The website is listed as having only one column, so I run into problems when I try to...” The forum allows for collaboration between hackers. Yikes!

I found an email for the targeted site and contacted them regarding the vulnerability. Hopefully, they will forward the email to someone who can take appropriate action.

The good news here is that these attacks are very simple to prevent or avoid. The Open Web Application Security Project has a SQL Injection Prevention Cheat Sheet, which outlined primary and additional defenses.

The primary defenses that are used to fight include,
     •    Prepared Statements (Parameterized Queries) - Parameterized queries force developers to define all the SQL code, then pass in each parameter to the query, which allows the database to distinguish between code and data, regardless of what input is supplied.
     •    Stored Procedures - a stored procedure is defined and stored in the database itself, and then called from the application rather than something that a user is allowed to enter.
     •    Escaping all User Supplied Input - Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.

Additional Defenses include
     •    Least Privilege – or minimizing the privileges assigned to every database account, so that users have enough permission to do their job, but no more.
     •    White List Input Validation - Input validation is used to detect unauthorized input before it is processed by the application, thereby preventing the attack

Have you experienced an SQL Injection hack at your organization? How did your organization combat the attack? Let me know.