Use scripts to test SQL injection attacks with Guardium

IBM Security Guardium protects structured and unstructured data in databases, big data environments, and file systems against threats, ensuring compliance. Guardium collects monitored data, which passes through a policy filter and is stored as activity, exceptions, policy violations, and more. This data is then available via Guardium tools, such as reports and dashboards, and can generate alerts. While this data is useful for compliance purposes, to provide real security, it needs to filter out the noise and focus on actual threats.

To achieve this, Guardium employs machine learning (ML) and analytics capabilities. The following features are part of Guardium Analytics:

• Active Threat Analytics (ATA): The Active Threat Analytics dashboard shows potential security breach cases based on outlier mining processes and identified attack symptoms. In this dashboard, you can view, investigate, and take actions on individual cases.

• Risk Spotter (RS): A first-of-its-kind technology that changes the security paradigm to an Artificial Intelligence Data Protection Policy. It uses a holistic algorithm to dynamically assess risk factors and a smart algorithm to identify potential risks across your entire system.

• Realtime Trust Evaluator (RTTE): Evaluates the application connections monitored by Guardium. Connections are classified as untrusted,evaluated, or trusted, with trust scores (values from 0 to 100) assigned to each classified connection. Connections that are not classified as trusted or untrusted are classified as evaluated.

To demonstrate these capabilities in a PoC environment or with a customer, we have developed data generation scripts. By running these scripts, one can generate malicious activities with the database, which can be captured by Guardium Data Protection and populate these analytics dashboards.

Part 1 of this article describes the scripts for SQL Injection attacks.

Prerequisites

• Guardium Data Protection 12.x version with STAP connection from a MySQL 8.x database
• Python 3.9.2

SQL Injection attack data scripts

The developed SQL Injection attack scripts cover the following attacks.

Cross site scripting (XSS)

Cross site scripting occurs when an attacker uses a web application to send malicious code, generally in the form of a browser script, to obtain data.

Example:

insert into testTable(text, id) values ('<IMG SRC=javascript:alert("XSS")>', 3);

In the above statement, a script is inserted into a production database. When any query related to this table is executed, this script is rendered, and an alert statement present in the query returns some critical data in the browser.

Tautology

These attacks make database transactions always return some data.

Example:

select * from testTable where text='xxx' or 15=15;

The preceding select statement will always be executed because the WHERE condition has an OR condition 15=15, which is always true.

Side channel attack

The attacker exploits loopholes in the code or system to observe, identify, and leak data.

Example:

select * from testTable where text='sleep(12)#';

Here, the attacker makes the system sleep between transactions so that they can observe, infer, or confirm their attack scenarios.

Denial of service

The attacker tries to occupy the system with their transaction, causing delays or rejections for other users/transactions.

Example:

insert into testTable(text) values('benchmark(123456)');

Here, the benchmark function will repeatedly perform the expression, thereby occupying the database resource, overloading it, or making it unavailable for other users.

OS commands

The attacker tries to perform OS-specific commands using SQL statements.

Example:

select * from testTable where text='cat /etc/passwd';

In this SQL statement, the attacker is displaying the user information file in the output.

Assessment from Guardium

The following image shows the SQL Injection attacks captured by Guardium after enabling Active Threat Analytics.

Drill-down details of an attack scenario showing more information, particularly from a DB and DB user perspective.

The Risk Spotter identifies this user (in our example, NEWUSER) as a Risky User.

The drill-down details reveal the activities that led to the classification of the user as risky. Examining closely, you can see that the user performed a high volume of activity, which was promptly detected by both Risk Spotter and Active Threat Analytics.

Summary

By executing these scripts and enabling Risk Spotter, Active Threat Analytics, and security policies in Guardium, SQL injection attacks are identified and reported, allowing for timely mitigation.

Next steps

The scripts are available in the GitHub folder. The scripts can be extended to include additional test scenarios or used as-is.

For detailed documentation about Guardium Analytics, see IBM Security Guardium Data Protection.