GHSA-2fr7-cc4f-wh98 OpenSTAManager: SQL Injection via Aggiornamenti Module
DescriptionThe Aggiornamenti (Updates) module in OpenSTAManager <= 2.10.1 contains a database conflict resolution feature (`op=risolvi-conflitti-database`) that accepts a JSON array of SQL statements via POST and executes them directly against the database without any validation, allowlist, or sanitization.An authenticated attacker with access to the Aggiornamenti module can execute arbitrary SQL statements including `CREATE`, `DROP`, `ALTER`, `INSERT`, `UPDATE`, `DELETE`, `SELECT INTO OUTFILE`, and any other SQL command supported by the MySQL server. Foreign key checks are explicitly disabled before execution (`SET FOREIGN_KEY_CHECKS=0`), further reducing database integrity protections.Affected Code**File:** `modules/aggiornamenti/actions.php`, lines 40-82Key Issues**No query validation:** The SQL statements from user input are executed directly via `$dbo->query()` without any validation or filtering.**No allowlist:** There is no restriction on which SQL commands are permitted (e.g., only `ALTER TABLE` or `CREATE INDEX`).**Foreign key checks disabled:** `SET FOREIGN_KEY_CHECKS=0` is executed before the user queries, allowing data integrity violations.**Error message leakage:** Exception messages containing database structure details are returned in the JSON response (line 79).**No authorization check:** The action only requires module-level access, with no additional authorization for this destructive operation.Root Cause AnalysisData FlowAttacker sends POST request to `/editor.php?id_module=<Aggiornamenti_ID>` with `op=risolvi-conflitti-database` and `queries=["<arbitrary SQL>"]``editor.php` includes `actions.php` (root), which checks module permission (`$structure->permission == 'rw'`) at line 472Root `actions.php` includes the module's `actions.php` at line 489`modules/aggiornamenti/actions.php` reads the `queries` POST parameter (line 41)JSON-decodes it into an array of strings (line 50)Iterates over each string and executes it as a SQL query via `$dbo->query()` (line 76)Why This Is ExploitableThe feature is intended for resolving database schema conflicts during updatesHowever, there is no restriction on what SQL can be executedAny authenticated user with `rw` permission on the Aggiornamenti module can exploit thisThe default admin account always has access to this moduleProof of ConceptPrerequisitesA valid user account with access to the Aggiornamenti moduleStep 1: AuthenticateSave the `PHPSESSID` cookie.Step 2: Detect Aggiornamenti Module IDNavigate to the application dashboard and inspect the sidebar links. The Aggiornamenti module URL contains `id_module=<ID>`. Default value in a standard installation: `6`.Step 3: Execute Arbitrary SQL**Request (captured in Burp Suite):**The URL-decoded `queries` parameter is:Three arbitrary SQL statements are sent: `DROP TABLE`, `CREATE TABLE`, and `INSERT INTO` — demonstrating full control over the database.**Response (captured in Burp Suite):**The server responds with HTTP 200 and the following JSON response confirming successful execution of all 3 queries:Step 4: Verify ExecutionThe table `poc_vuln04_verify` was created in the database with the inserted data, confirming that arbitrary SQL was executed. The server confirms: `"Tutte le query sono state eseguite con successo (3 query)."`Observed Results| Action | Result |
|---|---|
| `DROP TABLE IF EXISTS` | Table dropped successfully |
| `CREATE TABLE` | Table created successfully |
| `INSERT INTO` | Data inserted |
| `SELECT VERSION()` (via INSERT...SELECT) | MySQL version extracted: `8.3.0` |
| Server confirmation | `"success":true` with query count |
| Execution with admin user | Success |
| Execution with non-admin user (Tecnici group with module access) | Success |ExploitImpact**Confidentiality:** Complete database exfiltration — credentials, PII, financial data, configuration secrets.**Integrity:** Full control over all database tables — insert, update, delete any record. An attacker can create new admin accounts, modify financial records, or plant backdoors.**Availability:** An attacker can `DROP` critical tables, corrupt data, or execute resource-intensive queries to cause denial of service.**Potential Remote Code Execution:** Depending on MySQL server configuration, an attacker may be able to use `SELECT ... INTO OUTFILE` to write arbitrary files to the server filesystem, or use MySQL UDF (User Defined Functions) to execute operating system commands.Proposed RemediationOption A: Remove Direct Query Execution (Recommended)Replace the arbitrary SQL execution with a predefined set of safe operations. The conflict resolution feature should only execute queries that were generated by the application itself, not user-supplied SQL:Option B: Server-Side Query GenerationInstead of accepting raw SQL from the client, have the client send operation descriptors and generate the SQL on the server:Option C: Restrict Access (Minimum Mitigation)At minimum, restrict this operation to admin-only users:**Note:** This alone is insufficient because even admin accounts can be compromised, and the feature still allows arbitrary SQL execution.Additional Recommendations**Remove `SET FOREIGN_KEY_CHECKS=0`**: Foreign key checks should never be disabled based on user-initiated actions.**Sanitize error output**: Exception messages at line 79 leak database structure information. Replace with generic error messages.**Add CSRF protection**: Ensure the endpoint validates a CSRF token to prevent cross-site request forgery attacks.**Audit logging**: Log the actual SQL queries being executed (already partially implemented) but also log the requesting user's IP address and session.CreditsOmar Ramirez
CVSS v3.1 score: 8.8