Headline
CVE-2023-30605: Multiple SQL injections in sql/instance.py param_edit method GHSL-2022-104
Archery is an open source SQL audit platform. The Archery project contains multiple SQL injection vulnerabilities, that may allow an attacker to query the connected databases. User input coming from the variable_name
and variable_value
parameter value in the sql/instance.py
param_edit
endpoint is passed to a set of 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. The affected methods are: set_variable
in sql/engines/goinception.py
which concatenates input which is passed to execution on the database in the sql/engines/goinception.py
, get_variables
in sql/engines/goinception.py
which concatenates input which is passed to execution on the database in the sql/engines/goinception.py
, set_variable
in sql/engines/mysql.py
which concatenates input which is passed to execution on the database in the sql/engines/mysql.py
query
, and get_variables
in sql/engines/mysql.py
which concatenates input which is passed to execution on the database in the sql/engines/mysql.py
query
. Each of these issues may be mitigated by escaping user input or by using prepared statements when executing SQL queries. This advisory is also indexed as GHSL-2022-104
.
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 4: Multiple SQL injections in sql/instance.py param_edit method (GHSL-2022-104)
User input coming from the variable_name and variable_value parameter value in the sql/instance.py param_edit 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/goinception.py > set_variable method concatenates input which is passed to execution on the database in the sql/engines/goinception.py query method on line 153.
- sql/engines/goinception.py > get_variables method concatenates input which is passed to execution on the database in the sql/engines/goinception.py query method on line 153.
- sql/engines/mysql.py > set_variable method concatenates input which is passed to execution on the database in the sql/engines/mysql.py query method on line 341.
- sql/engines/mysql.py > get_variables method concatenates input which is passed to execution on the database in the sql/engines/mysql.py query method on line 341.
Remediation
Escape the variables accepting user input in sql/instance.py param_edit method, that is variable_name and variable_value by using f.ex. MySQLdb.escape().
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.