SQL Attacks Are A piece of Cake for Hackers and the Risk to Firms is High

SQL attacks are old hat, but that hasn’t stopped them from ripping open systems that companies like Sony and TalkTalk thought were secure.

SQL, or Structured Query Language, is wildly used by programmers in applications and more specifically in the design and management of databases.

The advantage of using SQL is that it lets the user access records or data in batches with just one single command.

Using SQL queries the user also doesn’t have to specify how the data should be retrieved; as in whether it should be done through an index or not.

Unfortunately, as is often the case, these advantages are also vulnerabilities that threat actors can utilise for their own needs…

SQL Attacks: First, Issue Your Command

A vast amount of websites and online applications store information in SQL databases.

When users or developers engage with these databases they use SQL commands to retrieve data or run operating system commands.

A SQL attack tricks the system into given a hacker information because they have issued it with a SQL command. The main issue here is that hackers often don’t need access to the system to attempt a SQL query as it can be done from a login page or via a URL.

Christopher Fielder, cyber security strategist at Fidelis Cybersecurity told Computer Business Review: “SQL Injections are one of the most tried and true attack vectors defenders must be aware of, not only because of their relative simplicity in many cases, but also due to the devastating effects such an attack could have within an enterprise.

“Depending upon the dataset the attacker is attempting to manipulate, a successful SQL injection is capable of anything from exposing integral enterprise information, to allowing attackers further access into an environment, to even modifying or deleting critical company data that could cause serious financial impact.”

How it Works

Essentially an SQL attack lets a hacker inject malicious code into an SQL command that alters its intended function. Sometimes they just simply expand the function so that it requests sensitive data such as passwords or login in credentials.

On a login page to a webpage a SQL attack can be as simple as SELECT * FROM users WHERE name=’tom’ and password=’tom’.

Something like this can bypass security and return all the passwords and login in credentials of a firm’s employees with the name Tom.

Scott Caveza, Research Engineering Manager, Tenable told us: “What many developers often don’t consider is how to accept that user input in a safe manner. In the rush to get an application developed, they may overlook the fact that no input validation is used, or that there may be library support to help sanitise that user input.

“As a researcher, the first thing I look at when interacting with any web application is what input will the application accept.”

SQL Attacks Legacy Systems

Daniel Goldberg, cybersecurity research expert at Guardicore Labs told us that SQL attacks should be a thing of the past, as modern infrastructure and technical solutions have eliminated them from the game.

It is only companies working with old legacy system that are at risk. As he put it: “Systems simply shouldn’t be vulnerable to SQL injection attacks any more. If an organisation is still succumbing to SQL injection attacks in 2019, then its infrastructure is hopelessly outdated and insecure and the business in deep trouble.”

Modern infrastructure and systems should have SQL immunity built in as these systems use native input validation and parameterised queries.

Yet very few firms can say that they don’t have some form of old software or system framework still present in their technology stack.

Rick Holland, CISO at Digital Shadows points out that: “Companies must maintain their legacy applications and rely on third-party apps to conduct business.

“These legacy web applications, SSL VPN appliances, and Word Press plugins are frequently used and abused by SQLi.”

Critical SQL vulnerabilities within web applications provides hackers another vector to attack a database where they can change, delete or remove sensitive data.

Web applications can be open to this type of attack because developers often design them to be accessible across the internet. Logins boxes, enterprise portals or emails are also subject to intense probing by threat actors searching for an SQL vulnerability.

SQL Attacks Defence

The best defence against SQL attacks is to understand your systems and infrastructure inside and out, especially if your firm operates a mixture of modern and legacy systems.

One of the simplest ways to reduce the risk is to stop using dynamic queries, this is often not an option as dynamic queries are sometimes integral to how a SQL database is run. If possible organisations should have security checks in place such as input validation or they could build a whitelist of input commands.

Boris Cipot, senior security engineer at Synopsys told us that: “Using parameterized statements are the best mechanism by which to protect against SQLi. Don’t allow, or avoid to the extent possible, dynamic queries. The principle of least privilege ensures that users cannot gain unauthorized access to sensitive data. Also be sure that patches are applied and software is up to date. This concerns not only the SQL technology itself, but also the software it connects to.”

Firms should make sure that adequate controls are set in place to control what SQL queries can have an effect on. Only the queries that are required for business functions should be allowed work, while all others should be blocked.

As Fidelis notes, “Decoy servers can [also] be generated to help lure attackers into the open and stop them before they are able to execute their intended attacks.”

At the end of the day SQL attacks are old news, but that doesn’t reduce the threat they pose. In fact their simplistic nature and high value return makes them an essential tool in a hacker’s kit and they are often the first thing threat actors learn and toy with.

Organisations need to make sure they are vaccinated against them: just because a disease is not considered a threat any more doesn’t mean a lapse in health checks won’t give it the opportunity to infect once again.