CVE-2025-56380 — Iniezione SQL cieca basata sul tempo in Frappe / ERPNext (frappe.client.get_value)

📌 Riepilogo È stata scoperta una vulnerabilità di iniezione SQL cieca basata sul tempo nell'endpoint API frappe.client.get_value in Frappe Framework v15.72.4 (presente anche nel codebase di ERPNext v15.67.0). Un utente autenticato con accesso all'API di reporting/client può iniettare SQL tramite il parametro fieldname. Inserendo funzioni di ritardo temporale (ad es., sleep(15)) nel parametro fieldname, un attaccante può confermare l'iniezione tramite ritardi misurabili nella risposta — consentendo denial of service, divulgazione di informazioni (tramite tecniche cieche) e manipolazione dei dati.

🛠 Dettagli tecnici

• Tipo di vulnerabilità: SQL Injection (cieca basata sul tempo) (CWE‑89)

• Prodotti interessati: Frappe Framework / ERPNext

• Versioni interessate (segnalate):

  • Frappe — 15.72.4
  • ERPNext — 15.67.0 (stesso codebase interessato)

• Componente interessato: metodo API frappe.client.get_value (frappe/client.py)

• Endpoint vulnerabile:

  root@kitploit:~

  /api/method/frappe.client.get_value
  

  Esempio di query vulnerabile:

  root@kitploit:~

  /api/method/frappe.client.get_value?doctype=Report&fieldname=ref_doctype+%2F+sleep(15)+&filters=Profit+and+Loss+Statement&_=1752174156893
  

• Parametro vulnerabile: fieldname (sanitizzato in modo improprio / concatenato in SQL)

• Tipo di attacco: Remoto (richiede autenticazione e accesso all'API di reporting)

• Gravità: Alta (la SQLi cieca basata sul tempo consente esfiltrazione di dati, DoS e manipolazione)

• Punteggio CVSS v3.1 stimato: 8.0 (Alto) — stima basata su un'iniezione SQL remota che richiede autenticazione e consente divulgazione di dati e DoS; la valutazione ufficiale dovrebbe essere eseguita dagli enti assegnanti (assigners).

• Stato: Non risolto (come da segnalazione)

• Scoperto da: Mohammed Aloli (GitHub: https://github.com/MoAlali)

• Data della scoperta: Non specificata nella segnalazione

• CVE ID: CVE-2025-56380

🚀 Prova di concetto (PoC) — SQLi cieca basata sul tempo

Effettuare test solo in ambienti autorizzati / di laboratorio. NON eseguire contro sistemi di cui non si è proprietari o per i quali non si ha il permesso esplicito di testare.

Richiesta PoC (esempio):

GET /api/method/frappe.client.get_value?doctype=Report&fieldname=ref_doctype+%2F+sleep(15)+&filters=Profit+and+Loss+Statement&_=1752174156893

Passaggi per la conferma

1. Autenticarsi all'istanza Frappe/ERPNext target con un utente che possa accedere all'API di reporting/get_value.
2. Inviare la richiesta GET sopra indicata (o il payload equivalente codificato in URL).
3. Osservare il tempo di risposta; se la risposta viene ritardata di ~15 secondi, ciò indica che l'iniezione basata sul tempo è riuscita.
4. Ripetere la stessa richiesta per confermare la riproducibilità.
5. Rimuovere il payload iniettato +%2F+sleep(15)+& e osservare che la risposta torna immediata — confermando che l'iniezione causa il ritardo temporale.

Note: Sostituire sleep(15) con altre funzioni temporali o valori di tempo adatti al DBMS sottostante (ad es., pg_sleep(n) per PostgreSQL) a seconda del motore di database. Il PoC dimostra l'iniezione cieca tramite timing; payload più complessi potrebbero essere usati per estrarre i dati bit per bit.

🧪 Vettori di attacco e impatto

• Vettore di attacco: Un utente autenticato crea richieste GET a /api/method/frappe.client.get_value con un parametro fieldname malizioso contenente payload SQL (funzioni di ritardo temporale).

• Impatto:

  • Denial of Service: ritardi forzati nella risposta del server (esaurimento delle risorse se abusato).
  • Divulgazione di informazioni: estrazione cieca dei dati tramite tecniche basate sul tempo (query bitwise/condizionate dal tempo).
  • Manipolazione dei dati: potenziale capacità di alterare lo stato del database se sono disponibili altri vettori di SQL injection.
  • Altro: escalation dell'impatto a seconda dei privilegi sul database disponibili per l'utente dell'applicazione.

🔐 Raccomandazioni di mitigazione

1. Query parametrizzate / Prepared Statement: assicurarsi che fieldname e tutti gli input forniti dall'utente non vengano mai concatenati direttamente in SQL. Utilizzare query parametrizzate o API ORM che legano correttamente i parametri.
2. Validazione rigorosa degli input / whitelisting: per i parametri che dovrebbero essere nomi di campi o identificatori, validare rispetto a un allowlist rigoroso di nomi di campo validi noti o utilizzare una mappatura lato server invece di accettare identificatori di campo grezzi dai client.
3. Escape sicuro degli identificatori: se gli identificatori devono essere usati dinamicamente, utilizzare funzioni sicure di quoting/escaping specifiche del database — e comunque limitare i valori consentiti.
4. Account database con privilegi minimi: eseguire l'applicazione con un utente del database che abbia solo i privilegi necessari (sola lettura dove possibile per gli endpoint di reporting).
5. Rate limiting e monitoraggio: applicare limiti di frequenza e rilevare pattern di richieste anomali o test ripetuti di ritardo temporale; generare alert sul traffico sospetto.
6. Audit e logging: registrare le richieste agli endpoint API sensibili e monitorare payload sospetti (ad es., sleep, pg_sleep, benchmark, /, ;).
7. Patch e rilascio: gli sviluppatori di Frappe/ERPNext dovrebbero esaminare frappe.client.get_value e il percorso del codice che gestisce fieldname/filtri, sostituire la concatenazione non sicura con API sicure e rilasciare una patch di sicurezza. Gli operatori dovrebbero applicare gli aggiornamenti tempestivamente.

🔗 Riferimenti

• Scopritore / Segnalatore: Mohammed Aloli — GitHub: https://github.com/MoAlali — X: https://x.com/alaliksa_ — LinkedIn: https://www.linkedin.com/in/mohammedaloli/
• Codebase Frappe / ERPNext (revisione e patch): https://github.com/frappe/frappe , https://github.com/frappe/erpnext
• Guida generale sulla SQLi: OWASP SQL Injection Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

🙏 Riconoscimenti

Scoperto da Mohammed Aloli

📢 Esclusione di responsabilità

Queste informazioni sono fornite esclusivamente a scopo difensivo e di remediation. Non tentare di sfruttare questa vulnerabilità contro sistemi di cui non si è proprietari o per i quali non si ha esplicita autorizzazione al test. Gli operatori dovrebbero dare priorità all'applicazione delle patch, applicare correzioni di codifica sicura e seguire le indicazioni di mitigazione sopra riportate.