SQL server attacks are one of the most painful attacks organizations can suffer. An organization's database is one of its softest spots, with a wide surface area susceptible to attacks. This results in it being an attractive target of attackers. Neglecting your organization's SQL server security is equivalent to having a bomb ticking in your organization's IT infrastructure.
Adopting comprehensive security measures and following SQL security best practices are crucial for data security in organizations using Microsoft SQL Server databases.
In June 2023 there was an increase in unsecured MSSQL servers falling victim to the Mallox Ransomware attack. The ransomware group behind the attack, known as Mallox, targets unsecured MS-SQL servers to infiltrate victims' systems and distribute the ransomware.
There are different ways to protect your SQL server from firewalls to ensure secure configurations. This article will present two of the most popular attacks and database breaching methods: SQL injection and SQL Obfuscation.
https://calcomsoftware.com/how-to-protect-microsoft-server/
SQL injection:
SQL Injection is a code injection technique used to attack applications. It can be used in a range of ways to cause serious problems. Attackers can use tools, scripts, and even browsers to insert SQL statements into application fields. The statements are then executed by the database engine. Such attacks are usually used to:
- Spoof identity
- Tamper with existing data
- Steal data
- Destroy data
- Change database permissions
- Execute commands on the operating system.
The data behind an application is usually mission-critical, which is why SQL Injection attacks are considered very severe.
SQL Injection can be classified into three major categories - In-band SQLi, Inferential SQLi, and Out-of-band SQLi.
In-band SQLi (Classic SQLi)
In-band SQL Injection is the most common and easy-to-exploit of SQL Injection attacks. in this kind of attack, the attacker can use the same communication channel to both launch the attack and gather the results.
Inferential SQLi (Blind SQLi)
Inferential SQL Injection may take longer for an attacker to exploit; however, it is just as dangerous as any other form of SQL Injection. In an inferential SQLi attack, no data is actually transferred via the web application. The attacker would see the results like in the in-band attack (which is why such attacks are commonly referred to as "blind SQL Injection attacks"). Instead, the attacker is able to change the database structure by sending payloads, observing the web application's response and the resulting behavior of the database server.
Out-of-band SQLi
Out-of-band SQL Injection attack depends on enabled features on the database server, thereby it is not very common. the attacker will choose this type of attack when he is unable to use the same channel to both launch the attack and gather the results. Out-of-band SQLi techniques would rely on the database server's ability to make DNS or HTTP requests to deliver data to an attacker.
SQL Obfuscation:
Obfuscation is one of the main tools for bypassing pattern-based security mechanisms such as web application firewalls (WAF). By tricking the firewall into thinking our attacks are legitimate traffic, we can successfully initiate, for example, an SQL injection attack without being detected by the WAF.
SQL obfuscation techniques are deployed to conceal malicious activities within SQL databases, making it challenging for security mechanisms to identify and thwart potential threats.
There are several methods that can be used to obfuscate our injections:
Fuzzers:
fuzzing is the process of finding hackable bugs by randomly feeding different permutations of data into a target program until one of those permutations reveals a vulnerability. It is important for firewall developers to be fully aware of all the database specifications and oddities. While some of them are documented, others can only be found through fuzzing. One example of peculiarities discovered through the use of fuzzers are the permitted whitespace characters for each type of database. Each different RDBMS allows a variety of different whitespace characters instead of the usual 0x20. By switching the standard whitespace with other allowed whitespace characters, the attacker can make his injection unrecognizable to certain firewalls allowing him to effectively bypass them.
Actively monitor failed logins and unusual database access patterns, as these might indicate attempts at SQL obfuscation through fuzzers. Implementing strong passwords and managing user accounts diligently further bolster the server database's defenses.
https://calcomsoftware.com/hardening-iis-server-guide/
Encodings:
Encodings are another tool to use when bypassing WAFs. The web application may see the data in one way, while the proxy, firewall or database might interpret the data differently. It is because of these discrepancies between layers that encodings may work to bypass the WAF.
URL encode- URL Encoding is used to transform "special" characters, so they can be sent over HTTP. Characters get transformed into their hexadecimal equivalent, prefixed by a percent sign.
Double URL encode- Applying URL encode two times on the characters.
Unicode encode- Unicode is an industry-standard for representing over 110,000 symbols and characters for a wide range of languages. This encoding generally works against IIS servers or applications built in ASP or .NET.
UTF-8 encode- UTF-8 is a form of encoding each one of the code points in the Unicode character set. The number of blocks required to represent a character varies from 1 to 4.
Nibble encode- a nibble corresponds to a single hexadecimal digit. Since every character from ASCII range 0-255 can be represented in 1 byte, we can URL encode the 4 most significant bits, the 4 least significant bits or both of them.
Invalid Percent encode- this method is specific to .NET/IIS applications. The percent sign is added in between nonvalid hex characters so that the IIS will strip them and make the data valid. Any firewall that is unaware of this IIS behavior, won't change the percent sign. This will allow mangling the SQL syntax, making it undetectable to the firewall.
Invalid Hex encode- this method isn't exactly an encoding method. It is a way of affecting how applications convert hexadecimal to decimal. This method creates invalid hex that has the same decimal value as valid hex.
It's crucial for those in sysadmin roles to understand encoding methodologies and be proficient in writing SQL queries that are secure and resilient to obfuscation attacks, thereby safeguarding the SQL database.
SQL Security Best Practices for SysAdmins
Your SQL doesn’t have to be the breaking point of your network. Basic SQL security best practices starts with hardening it by configuring it in the most secure fashion. Not so complex when you have a small infrastructure, but extremely difficult in organizations with tangled IT infrastructure.
Here are four of the most fundamental and critical SQL security best practices:
Least Privilege Principle: Grant users and applications the minimum necessary permissions to perform their tasks. Avoid giving excessive privileges to prevent unauthorized access or unintended data modifications.
Parameterized Queries: Use parameterized queries or prepared statements to prevent SQL injection attacks. This practice ensures that user input is treated as data and not executable code, making it more difficult for attackers to manipulate SQL statements.
Regular Updates and Patching: Keep your database management system (DBMS) and related software up to date with the latest security patches. Vulnerabilities in outdated software can be exploited by attackers, so patch management is crucial.
Data Encryption: Implement encryption to protect data both at rest and in transit. Use technologies like SSL/TLS for securing data in transit and mechanisms like Transparent Data Encryption (TDE) for protecting data at rest.
Changing the server’s configurations might result in production outages. In order to avoid it, dependencies in the system must be understood. But even after testing the outcomes of every change, mistakes might happen that will lead to damaging application function. CalCom Hardening Suite (CHS) solves this problem for you. With CHS you can implement your desired policy directly on your production. CHS will learn your system’s dependencies and will do the impact analysis for you. After implementing the policy, CHS will ensure you avoid configuration drifts by informing you about any unauthorized change in the server.
