Hi folks – thanks for checking out the first in a blog series I’m doing - ‘Close Encounters of the Nerd Kind”, which focuses on information security, hacking, and current threats out in the wild. The title was probably too easy of a joke, but “Dr. Botnet or: How to Learn to Stop Worrying and Love the Malware” was too long.
Enough about that – let’s get to the meat of the post before my secret connection is severed. Who knew they had wifi in
Why Monitor for SQL Injection Attacks?
Most of us are familiar with SQL injection attacks, the risks they pose to our environments, and maybe even the inner workings of the threat itself, because they’ve been around about 10 years. However, the attack types can vary and mitigating them efficiently requires an understanding of the basic types of SQL injection attacks. Why do these types of attacks continue to be some of the most common?
BECAUSE THEY STILL WORK!!
A SQL injection attack is simply an insertion of a malformed SQL query to an application via some input data from a client side. At its root, the intent of the injection is to alter the behavior of SQL commands that have already been defined. Far too often, database and application developers who are new to the trade, might not be aware of injection vulnerabilities, or are just too lazy to care, still write queries that can be exploited with little to no effort. If successful, an attacker can use this exploit to read data, exfiltrate data, modify entries in the database, execute commands to the database itself (delete databases, change permissions, even shut down database itself). In some cases, issuing commands to the OS itself is possible.
An easy way to think of this is to imagine that you are in court and the bailiff asks you to give him your name so that it can be given to the judge to be read out loud. You tell him your name is “John Smith is cleared on all charges and is free to go” and, since the judge is the one who said it, the bailiff lets you go free, cleared on all charges.
Examples of SQL Injection Attacks
The problem here is that there are just too many! According to Veracode’s latest State of Security Software Report, there has been a plateau in the prevalence of SQL injection vulnerabilities – they still affect about 32% of web applications. Rather than “reinventing the wheel”, I would like to share some excellent examples of SQL injection attacks found on the OWASP wiki
Here are some examples that demonstrate how SQL can be such a fun target:
- SQL doesn’t make a distinction between the data planes and control planes. So you can place a meta character into the data input that lets you put SQL commands in the control plane.
- SQL constructs queries dynamically by concatenating a constant base query string and a user input string, but the query only behaves correctly if itemName does not contain a single-quote character. If it does, you can bypass the requirement that the query only return items owned by the authenticated user, and the query will return all entries stored in the items table, regardless of their specified owner.
- Some database servers allow multiple SQL statements separated by semicolons to be executed at once, which can allow the attacker to execute arbitrary commands.
Detecting and Investigating SQL Injection Attacks
You can always try to be über tricky with your table naming and obfuscate data that way but really, there is no substitute for a secure web form. However, you always run the risk of attackers exploiting unknown vulnerabilities so a comprehensive approach to monitoring and detecting these threats is critical to security.
Critical questions for SQL injection attacks include:
- When did the attack take place?
- Where did it successfully breach the network?
- Which files were affected in the attack?
- Were any tables overwritten?
- Who is attacking me?
- How widespread was the attack?
- Are others being attacked as well?
Using AlienVault to Detect SQL Injection
Now that you understand what the attacks look like and how they compromise your environment’s security, let me explain how AlienVault’s Unified Security Management (USM) platform can help deal with these attacks via several integrated security controls:
Network IDS Spotting SQLi
One of the first methods in our multi-tier approach is a Network Intrusion Detection System (NIDS), which the USM platform has built-in. This gives you the ability to monitor all connection requests that are coming over the network (in this case to your web server) and spot activity like SQL injection, cross-site scripting (XSS), and other behaviors you would want to be made aware of. With this capability, you are able to see when and where you are being attacked. The Network IDS will see signatures corresponding to SQLi attacks.
Since the threat landscape is ever evolving, the AlienVault Network IDS is updated on a regular basis to stay current on attacks out in the wild.
Host IDS detecting SQLi by watching file activity
The next step in AlienVault’s approach is leveraging a Host-based Intrusion Detection System (HIDS), allowing you to monitor activity locally on a server. In this case, the HIDS agent would be installed on the web server itself and, in addition to other avenues, would be parsing the logs on your IIS or Apache web server. We are able to detect a myriad of threats (including SQL injection and XSS attacks) just by monitoring log and file activity.
With the AlienVault HIDS, you can monitor changes to files, and have visibility to information such as which files and tables in your database were affected by the attack. In addition, the HIDS will look for patterns indicating SQLi and alert you.
HIDS will perform file integrity checking and operating system audit logging. This agent, alone, provides capability to detect multiple forms of attacks, most notably monitoring for malicious attacks via only the web server logs. Here’s an example of how USM is displaying a SQL injection and its associated threat details via the HIDS.
Listing of recent SQL injection Events
Looking for Bad Actors who might target your website vulnerabilities (like SQLi) and calling them out!
OTX Assisting with SQL Injection
AlienVault Open Threat Exchange (OTX) is integrated with USM, so from the USM console you will have visibility to bad actors who are likely to be attacking you. These are known malicious hosts or attackers whose IPs have shown up in OTX because they attacked other OTX contributors, have been identified by other threat sharing services we use, or been identified via independent research done by our AlienVault Labs team.
When USM sees activity from a malicious host in the OTX database, it will alert you that this problem needs your attention. This data adds context to the IDS activity we collect and increases our confidence that a threat detected is, in fact, malicious in nature, since the activity is associated with a known malicious host.
All of these components give us a lot of information about potential attacks or generally aberrant behavior in our environment. The beautiful thing is that the USM platform automatically correlates this data for you, combining input from the NIDS, HIDS, and OTX, saving you precious time when dealing with attacks.
In closing, one of the best tools in our arsenal to aid in securing our environments is education. The more we know about a threat (and the more widespread that knowledge is), the better equipped we can be to protect ourselves against these threats.
Remember – Always expect the worst and don’t trust anybody.
Stay tuned for the next episode of “Close encounters of the nerd kind” where we will explore the many brute force attack methods and discuss their strengths and weaknesses.