The recent BillQuick attack was an important reminder of the dangers of SQL injection. Malicious hackers discovered a SQL injection flaw in BillQuick software used by over 400,00 organizations and used it to deploy ransomware across customer networks. Below are lessons learned from Gilad David Maayan and provides measures to protect your organization from SQL injection.
So, what Is SQL Injection? SQL injection (SQLi) techniques are one of the primary focuses of database security initiatives. They enable attackers to gain unauthorized access to databases by injecting a string of malicious code into the database query. It can manipulate the SQL code to provide access to protected digital resources, like sensitive data, or execute malicious SQL statements.
SQL injection is a critical threat included in the OWASP Top 10 list of web application security risks. These attacks gain access to intellectual property, administrative credentials, and customer data.[1]
Threat actors using this technique can target any application using SQL databases, such as MySQL and SQL Server. SQL injection attacks powered by automated tools can cause significant damage.
The BillQuick Attack? The BillQuick attack was reported by security researchers at Huntress. According to Huntress, threat actors exploited the CVE-2021-42258 vulnerability to gain unauthorized access to a US engineering company. It allowed these actors to deploy ransomware across the network.
BillQuick is a project management software by BQE Software. It includes project management, billing, time-tracking, and accounting features—deployed on-premise or in the cloud. BillQuick Web Suite 2020 constructs SQL database queries. It is vulnerable because it allows spawning a command shell via the application’s login screen through an SQL injection. Hackers can use the command shell to execute unauthorized commands through the underlying Windows operating system. When this occurs, ransomware can run with Windows system administration privileges.
This issue was addressed in version 22.0.9.1 of BillQuick, released on 7 October 2021. However, eight other undisclosed security issues identified as part of the investigation have not yet been patched.
BillQuick Vulnerability Analysis - Below is a summary of how the Huntress ThreatOps team discovered the BillQuick vulnerability:
- The canary trap - The team was managing an engineering company’s environment. Their ransomware canary files were tripped, and the team began investigating the incident.
- The Defender alert - The team discovered Microsoft Defender antivirus alerts that indicated malicious activity as the MSSQLSERVER$ service account. It led them to suspect a web application was being exploited for initial access.
- The suspicious activity - Investigation into the suspected server revealed it hosted BillQuick Web Suite 2020. Additionally, the connection logs revealed that a foreign IP was repeatedly sending POST requests to the webserver logon endpoint leading to the initial compromise.
The investigative team suspected that a threat actor was attempting to exploit BillQuick, and began reverse-engineering the web application to trace the actor’s steps. The investigators downloaded a free copy of BillQuick from the official site, installed it locally, and started investigating. They ran a static analysis of the server-side code and identified concatenated SQL queries. This function allows users to control a query sent to the MSSQL database. In this case, it allowed blind SQL injection through the application’s main login form.
The team then recreated the victim’s environment and validated that simple security tools, such as sqlmap, could easily obtain sensitive data from the BillQuick server without any authentication. These versions of BillQuick use the system administrator (sa) MSSQL user for database authentication. As a result, SQL injection also enables actors to use xp_cmdshell to execute code on the underlying operating system remotely.
SQL Injection Prevention. The BillQuick attack is just one example showing how SQL injection can lead to disastrous consequences. Here are techniques you can use to prevent SQL injection attacks in your organization.
Using Parameterized Queries. When writing database queries, developers should use prepared statements with variable binding; also known as parameterized queries. These are easier to write and understand than dynamic queries. The developer must define the entire SQL code for a parameterized query before passing each parameter to the query. The database can then distinguish between the data and code in any user-supplied input.
Prepared statements prevent attackers from changing the query intent by inserting SQL commands. In rare situations, this coding approach may impact performance, so it might be preferable to use data validation or escaping for user-supplied input in these cases.
Using Stored Procedures. Stored procedures are an alternative to parameterized queries, although they require safe implementation. While not always secure from SQL injection, they can use standard programming constructs with a similar effect to parameterized queries. The developer must build automatically parameterized SQL statements, defining and storing the SQL code for stored procedures in the database. The application calls the stored procedures from the database.
Applying the Principle of Least Privilege. Organizations should secure their applications by ensuring that every user, entity, or process can only access the resources it requires. The principle of least privilege involves applying the appropriate access levels to each employee and system component, restricting access to protected resources. This approach makes it harder for attackers to implement SQL injection. Applications rarely need to modify the database structure at runtime, so it makes sense to restrict permissions during runtime and provide increased permissions temporarily during release windows. In SQL databases, the production accounts should execute DML statements but not DDL statements. For complex databases, designs, permissions should be more granular, with most processes restricted to read-only access. A least-privilege access management strategy ensures that attackers cannot implement adverse changes when infiltrating the network.
Implementing Input Validation Allow Lists. Some parts of an SQL query, including table or column names, are not legal locations for binding variables. For these situations, the best strategy is redesigning the query or validating inputs. For example, the values for table or column names should come from code, not user parameters. However, user parameter values may be useful for targeting various table and column names. In such situations, it is important to map the parameter values to the legal column or table names to prevent the introduction of unvalidated into the query. This allow-listing approach is a quick fix, but a full redesign or rewrite is preferable where possible.
- Using parameterized queries – most modern databases provide a parameterized queries mechanism which completely prevents SQL injection vulnerabilities.
- Using stored procedures – stored procedures are another way to separate queries from execution logic, and if implemented correctly, can also prevent SQL injection.
- Applying the principle of least privilege – ensuring an application and database have only the minimal required privileges on the host machine, to minimize the impact of a breach.
- Implementing input validation allow lists – this is a last line of defense, ensuring that software code sanitizes user inputs to ensure they match allowed patterns.
Red Sky Alliance is a Cyber Threat Analysis and Intelligence Service organization. For questions, comments or assistance, please contact the office directly at 1-844-492-7225, or feedback@wapacklabs. com
Weekly Cyber Intelligence Briefings:
- Reporting: https://www. redskyalliance. org/
- Website: https://www. wapacklabs. com/
- LinkedIn: https://www. linkedin. com/company/64265941
Weekly Cyber Intelligence Briefings:
REDSHORTS - Weekly Cyber Intelligence Briefings
https://attendee.gotowebinar.com/register/5504229295967742989
Article: TR-22-152-001_SQLinjection.pdf
[1] https://americansecuritytoday.com/sql-injection-the-billquick-attack-best-practices-to-protect-your-org/
Comments