Lacerating through SQL Injections

The Dangers of Structured Query Language Insertions

SQL injections (SQLi) are prevalent web application vulnerabilities that leverage manipulated user inputs to compromise the underlying databases. By exploiting weaknesses in application code, attackers can inject malicious SQL statements, enabling unauthorized data access, manipulation, or even deletion.

SQL injection isn’t a monolithic attack. It’s a versatile weapon wielded by malicious actors, taking on various forms depending on the attacker’s goals and the application’s vulnerabilities. Understanding these different types of SQLi is crucial for effectively defending against them. Although they aren’t relatively new, they can be extremely dangerous, ranking among the top five most malicious attacks.

There is a diverse landscape of SQLi techniques which include different types and variations to perform this attack. These include:

• Error-based injections: Imagine a conversation where the other person’s angry outbursts reveal hidden information. Error-based SQLi works similarly. By injecting crafted code, attackers trigger database errors that expose details about the database structure and potentially sensitive data.
• Union-based injections: This technique leverages the UNION operator, a database tool for combining results from multiple queries. By manipulating user input, attackers can craft an SQL statement that merges their desired data with legitimate queries, essentially creating a backdoor for unauthorized data retrieval.
• Blind techniques: Not all SQLi attacks provide a clear view of the stolen information. In blind techniques, attackers rely on indirect methods to determine the success or failure of their injection. This might involve manipulating application behaviour, analyzing response times, or even leveraging timing delays for confirmation. Blind techniques require more patience and effort but can be effective when other avenues are blocked.

These are just a few of the many techniques in SQL injections. These SQLi techniques are used most often and prove to be most dangerous when dealing with hacking clients or users.

A simple SQL Injection

An SQL injection attack can be used to obtain admin privileges to wing the attacker to quickly access sensitive data. However, this type of attack relies on the website conditions and how user ID and other admin-related content is stored. Despite its simplicity, this type of attack can lead to more complex security breaches.

Generally, most operating systems and secure websites, use hashes to store passwords, to prevent attacks like SQL injections. In this case, websites store passwords beside their usernames like an Excel sheet, and write code to make sure that both username AND password are right, then only will the user be able to enter the site. The code may look like this:

SELECT * FROM users WHERE username ='admin' AND password='password123'

In the code shown above, the site only lets us in, if both the username and password match the ones given in the code. (Generally, there will be a huge list from which the code scans through to identify if the password and username match).

A small loophole is when through the username and password bar, we can access and add on to this code. For example, in this case, we can either comment out the rest of the code after the username mentioned or we can add a bit of code to overrun the existing code like so:

SELECT * FROM users WHERE username ='admin' OR '1'='1' AND password='password123'

In the username bar, it would look like:

username: admin’ OR ‘1’=’1

OR

SELECT * FROM users WHERE username ='admin' --AND password='password123'

In this case, the entire code after the username is ignored. The username would be typed as:

username: admin’ — —

From this basic example, we can understand that SQL injections are insertions of a SQL query via the input data from the client to the application. When a SQL injection exploit is successful, it can read sensitive data from the database, alter database data (Insert/Update/Delete), perform database administration tasks (like stopping the DBMS), retrieve the contents of a specific file that is located on the DBMS file system, and occasionally even send commands to the operating system. One kind of injection attack is SQL injection when preset SQL instructions are executed differently by injecting SQL commands into data-plane input.

Threat Modeling

• SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.
• SQL Injection is very common with PHP and ASP applications due to the prevalence of older functional interfaces. Due to the nature of programmatic interfaces available, J2EE and ASP.NET applications are less likely to have easily exploited SQL injections.
• The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser extent, defence in depth countermeasures, such as low privilege connections to the database server and so on. In general, consider SQL Injection a high impact severity.

(Threat modelling referenced from https://owasp.org/www-community/attacks/SQL_Injection)

The main consequences of unintended data entering a program from an untrusted source and data being used to dynamically construct an SQL query are:

• Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL Injection vulnerabilities.
• Authentication: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.
• Authorization: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL Injection vulnerability.
• Integrity: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with an SQL Injection attack.

Because of this, they become very common with database-driven websites; this is also shown in the simple SQL injection example.

Another example (taken from OWASP)

The following C# code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently authenticated user.

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
                + userName + "' AND itemname = '"
                + ItemName.Text + "'";
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
...

The query that this code intends to execute follows:

SELECT * FROM items
WHERE owner =
AND itemname = ;

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single quote character. If an attacker with the user name Wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:

SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';

The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

SELECT * FROM items;

This simplification of the query allows the attacker to bypass the requirement that the query only returns items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.

There are several ways to use SQL injections effectively and use them in different circumstances to obtain the best possible result.

SQL Injection Bypassing WAF

While Web Application Firewalls (WAFs) are commonly deployed to protect against such attacks, SQL injection can still bypass them under certain circumstances.

Firstly, phishers can use encoded payloads and can obfuscate SQL injection payloads to evade pattern-based detection mechanisms employed by WAFs. By encoding special characters or using alternative encodings like Unicode, attackers can make their malicious SQL queries appear benign to the WAF.

Another method to pass WAF is splitting the malicious payload into multiple smaller requests. This fragmentation can bypass WAFs that are configured to inspect complete requests for malicious patterns, as each request may appear innocuous.

Other ways of doing so include:

1. Bypassing Signature-Based Detection: To identify and stop SQL injection attempts, WAFs frequently rely on preconfigured signatures. Attackers can, however, create specially designed payloads to get around these signatures. Attackers can evade signature-based detection by employing strategies like whitespace, comments, and different SQL syntax.
2. Time-Based Attacks: Instead of directly extracting data from the database, attackers can launch time-based attacks where the application’s response time reveals information about the underlying database. This can bypass WAFs that focus solely on pattern matching without considering the runtime behaviour of the application.
3. Blind Injection: In blind SQL injection, attackers don’t receive direct feedback from the application about the success or failure of their queries. Instead, they infer information indirectly by analyzing variations in the application’s behaviour. Techniques like Boolean-based and time-based blind SQL injection can evade WAFs that are not equipped to detect such subtle attacks.
4. WAF Misconfiguration: Attackers may be able to take advantage of holes left by insufficient rule sets or improperly implemented WAF rules. In the event that the WAF is not set up to scrutinise certain parameters or is not proficient in sanitising user input, attackers may take advantage of these mistakes to carry out SQL injection attacks.
5. Zero-Day Vulnerabilities: SQL injection attempts that take use of recently found vulnerabilities in web applications may go undetected by WAFs. These zero-day vulnerabilities provide an avenue for attackers to get beyond WAF protection until updates or security patches are released.

Blind SQL Injection

Blind SQL Injection is a type of attack that questions the database with two possible answers/solutions. This attack is often used when the web application is configured to show generic error messages but has not mitigated the code that is vulnerable to SQL injection.

To create the database structure and retrieve all of the data within the database, blind SQL injections are frequently utilised. Brute force methods are used for this, which means it takes a lot of queries. However, attackers may be able to automate this with SQL Injection tools.

There are several other types, methods and other ways to use SQL injections to access login IDs, passwords, and other crucial information. A few others include code injections, double encoding, etc.

Thumbnail

source: https://www.avast.com/c-sql-injection