Skip to content

Multiple SQL injections in sql_api/api_workflow.py endpoint ExecuteCheck post method GHSL-2022-102

Moderate
hhyo published GHSA-hvcq-r2r2-34ch Apr 18, 2023

Package

No package listed

Affected versions

1.9.0

Patched versions

1.10.0

Description

Summary

The Archery project contains multiple SQL injection vulnerabilities, that may allow an attacker to query the connected databases.

Product

Archery

Tested Version

v1.9.0

Details

SQL injection exists in the project due to unsafe user input being concatenated with a SQL query, that is passed to methods executing a query in a database. All identified issues exist due to the controller files in folder sql taking user input and not sanitizing it, which later is passed to execution. Since the controller methods are connected to and allows querying all the databases that are connected to Archery, then all databases making queries with concatenated input will be affected. In this way, one vulnerable endpoint allows for exploiting several databases. To exploit most of these SQL injections, knowledge of the exploited instance name that is defined in Archery, is needed.

Issue 2: Multiple SQL injections in sql_api/api_workflow.py endpoint ExecuteCheck post method (GHSL-2022-102)

User input coming from the db_name parameter value and the full_sql parameter value in the api_workflow.py ExecuteCheck post endpoint is passed to the below defined methods in given SQL engine implementations, which concatenate user input unsafely into a SQL query and afterwards pass it to the query method of each database engine for execution.

  • sql/engines/clickhouse.py > execute_check method passes unsafe user input into the sql/engines/clickhouse.py > get_table_engine method, which concatenates input which is passed to execution on the database in the sql/engines/clickhouse.py query method on line 130.
  • sql/engines/goinception.py > execute_check method concatenates input which is passed to execution on the database in the sql/engines/goinception.py query method.
  • sql/engines/oracle.py > execute_check method passes unsafe user input into the object_name_check method, which is passed to execution on the database in the sql/engines/oracle.py [query method] on line 640.

Remediation

Escape the variables accepting user input in sql_api/api_workflow.py ExecuteCheck post endpoint that is db_name and full_sql by using f.ex. MySQLdb.escape(). This solution is easier to implement and will fix the issues in all SQL engines at once. Using this solution, it would fix the both GHSL-2022-102 and GHSL-2022-103 vulnerabilities.

Impact

All of the issues may lead to Information Disclosure.

General remediation advice

To fix each of the issues, the best practice would be to escape the user input (as presented in Remediation section of each of the issues) or use prepared statements when executing SQL queries. Using placeholders in cursor.execute() will automatically escape the passed values. See Django documentation around executing custom SQL directly and Connections and cursors.

Generally, it is best to use prepared statements rather, but for Archery's codebase it would be much easier to fix the issues by escaping user input, which is sufficient protection. Please consider also escaping all other variables which accept input from the user, particularly the ones from GET or POST requests.

For more information on preventing SQL injection see SQL Injection Prevention Cheat Sheet - Primary Defenses

Credit

These issues were discovered and reported by GHSL team member @sylwia-budzynska (Sylwia Budzynska).

Disclosure Policy

This report is subject to our coordinated disclosure policy.

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

CVE ID

CVE-2023-30553

Weaknesses

Credits