Testing Your Defences Against SQL Injection

Websites that serve content in response to user input are generally database-driven. By entering search terms, logging in, clicking options and filters and other user interface methods, the user is interacting with the underlying database, the server.

Structured Query Language (SQL) is the standard method of accessing data in most databases. SQL queries are generated by the website, passed to the database and executed to retrieve or modify the information that it holds.

However, if user input is not appropriately validated, it may be possible for an attacker to ‘inject’ raw SQL statements as part of a malicious input, and for these to be executed by the database.

So-called SQL injection (SQLi) attacks can be used to delete, modify or retrieve information from the database, and even execute commands on the underlying operating system. The most common SQLi attacks result in an attacker gaining access to and ‘dumping’ large amounts of data in the database that they should not have been able to access.

Timeline of recent SQLi attacks

SQL injection attacks were first discovered in 1998, with one of the first live attacks taking place in 2002 on the fashion retailer Guess. 

Common platforms and common vulnerabilities

Building a web application and backend from scratch is a significant undertaking; hence developers typically use web application frameworks and readily available code, often open-source. The resulting website may contain SQLi vulnerabilities owing to flaws in the platform. These vulnerabilities will exist in all websites currently being supported by that version, and patch status, of the platform. Examples of such platforms include:

Application and integration ‘middleware’ such as IBM Websphere – both the David Jones and Kmart ecommerce systems (see timeline above) were built on IBM Websphere; a vulnerability of the Websphere platform was identified and this was used to attack sites built on the same technology.

Content Management Systems (CMS) – these allow non-technical users to add and edit website content with ease, change and optimise site layout on various devices and automatically improve search engine rankings. CMS run a database with a variety of user interface elements on top. WordPress and Drupal are the top two CMSs in use on the web and account for nearly half of all dynamic content websites. Although updates are available for both platforms on a regular basis, sites are frequently left unpatched by administrators and large numbers of websites can be simultaneously vulnerable to exploits, including SQL injection.

3rd party add-ins that enhance CMS functionality can sometimes introduce vulnerabilities of their own, and may not be patched as frequently as the core CMS. Of the 31 SQLi vulnerabilities discovered in WordPress since 2003, 18 relate to WordPress plug-ins.

Attacker Motivation

There are a number of goals that the attacker may wish to achieve via an SQLi attack, including:

1) Long-term access to the network. This may involve compromise of the underlying operating system running the database and lateral movement across the network to open other routes for further or maintained access;
2) Sale of access to database/network on criminal black market;
3) Covert exfiltration of data from the database tables,
4) An overt ‘dump’ of database data for sale on criminal black market. Credential theft is the most prevalent SQL injection attack (23.2% of all traffic) leading to data loss;
5) To boost the attacker’s reputation on criminal forums by openly sharing access with other members;
6) Reputational damage to the targeted organisation;
7) Use of website for exploit kits or malware delivery.

Anatomy of an SQL injection attack

Automated probing and reconnaissance: Before an end-to-end SQL injection attack can be carried out, the attacker needs to probe the target website, or search for vulnerabilities, and perform reconnaissance on the database. 

Exploitation: Based on the results returned by initial enumeration, the attacker may focus their subsequent efforts on particular tables in the database, or on means of exposing these data.

Exfiltration of data – covertness and cracking: Once a vulnerability has been exploited and unauthorised access gained to the underlying database, most cyber-criminal activity will concentrate on exfiltration of data that can be sold on the criminal black market.

Tips & tricks hackers use

Exfiltration of a large amount of data may trigger alarms. Some programs offer ways around this, including the use of DNS queries to hide retrieved data: normally, DNS requests are not monitored as they constitute ‘noise’ in network traffic and the large volume of DNS traffic can effectively mask the malicious activity.

Where passwords have been stored in an encrypted format, some programs provide a number of standard algorithms for cracking weaker encryption standards, and also provide methods to avoid triggering intrusion detection/prevention systems or web application firewalls.

How to prevent SQLi on your network

SQL injection can be attempted by any threat actor on any website they have access to. The use of tools such as SQLmap coupled with web crawlers to automate vulnerability detection provides a low barrier of entry to would-be attackers. Typically, attackers using SQLi are cyber criminals looking for personal data to sell, or amateur hackers looking for fun or to boost their reputation among their community.

SQLi is a well-understood class of vulnerabilities, and extensive guidance on avoidance measures exist, including those provided by OWASP, however the most important steps BAE Systems recommends you can take to avoid an SQLi on your network include:

1) The most important single element of this guidance is input validation. When designing and coding database-driven websites, any user input should be carefully validated to prevent SQL injection via malicious input. 

2) Penetration Testing is an essential step to reducing the likelihood of SQLi. Penetration Testers and attackers will use similar – or identical – tools to aid in the identification of SQLi vulnerabilities. If the penetration test is performed before the website goes live, and performed thoroughly, the chances of an attacker finding an SQLi vulnerability are significantly reduced.

3) Other steps that can be taken to reduce the likelihood or impact of SQLi attacks include use of appropriate permissions, frequent patching and monitoring of web activity by a Security Operations Centre (SOC).