CVE-2025-56380 — Zeitbasierte Blind-SQL-Injection in Frappe / ERPNext (frappe.client.get_value)

📌 Zusammenfassung Eine zeitbasierte Blind-SQL-Injection-Schwachstelle wurde im API-Endpunkt frappe.client.get_value in Frappe Framework v15.72.4 entdeckt (und ist auch in der Codebasis von ERPNext v15.67.0 vorhanden). Ein authentifizierter Benutzer mit Zugriff auf die Reporting-/Client-API kann über den Parameter fieldname SQL injizieren. Durch das Einfügen von Zeitverzögerungsfunktionen (z. B. sleep(15)) in den Parameter fieldname kann ein Angreifer die Injektion über messbare Antwortverzögerungen bestätigen — was Denial of Service, Informationsoffenlegung (über Blind-Techniken) und Datenmanipulation ermöglicht.

🛠 Technische Details

• Schwachstellentyp: SQL-Injection (zeitbasiert blind) (CWE‑89)

• Betroffene Produkte: Frappe Framework / ERPNext

• Betroffene Versionen (gemeldet):

  • Frappe — 15.72.4
  • ERPNext — 15.67.0 (gleiche Codebasis betroffen)

• Betroffene Komponente: API-Methode frappe.client.get_value (frappe/client.py)

• Verwundbarer Endpunkt:

  root@kitploit:~

  /api/method/frappe.client.get_value
  

  Beispiel einer verwundbaren Abfrage:

  root@kitploit:~

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

• Verwundbarer Parameter: fieldname (nicht ordnungsgemäß bereinigt / in SQL verkettet)

• Angriffsart: Remote (erfordert Authentifizierung und Zugriff auf die Reporting-API)

• Schweregrad: Hoch (zeitbasierte Blind-SQLi ermöglicht Datenextraktion, DoS und Manipulation)

• Geschätzter CVSS v3.1-Score: 8.0 (Hoch) — Schätzung basierend auf einer Remote-SQL-Injection mit erforderlicher Authentifizierung, die Datenoffenlegung und DoS ermöglicht; die maßgebliche Bewertung sollte von den zuweisenden Stellen vorgenommen werden.

• Status: Nicht behoben (wie gemeldet)

• Entdeckt von: Mohammed Aloli (GitHub: https://github.com/MoAlali)

• Entdeckungsdatum: Im Bericht nicht angegeben

• CVE-ID: CVE-2025-56380

🚀 Proof of Concept (PoC) — Zeitbasierte Blind-SQLi

Nur in autorisierten / Laborumgebungen testen. NICHT gegen Systeme ausführen, die dir nicht gehören oder für die du keine ausdrückliche Testgenehmigung hast.

PoC-Anfrage (Beispiel):

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

Schritte zur Bestätigung

1. Melde dich bei der Ziel-Frappe/ERPNext-Instanz mit einem Benutzer an, der Zugriff auf die Reporting-/get_value-API hat.
2. Sende die obige GET-Anfrage (oder eine entsprechende URL-kodierte Nutzlast).
3. Beobachte die Antwortzeit; wenn die Antwort um ~15 Sekunden verzögert ist, deutet dies auf eine erfolgreiche zeitbasierte Injektion hin.
4. Wiederhole dieselbe Anfrage, um die Reproduzierbarkeit zu bestätigen.
5. Entferne die injizierte Nutzlast +%2F+sleep(15)+& und beobachte, dass die Antwort sofort zurückkommt — was bestätigt, dass die Injektion die Zeitverzögerung verursacht.

Hinweise: Ersetze sleep(15) je nach Datenbank-Engine durch andere Zeitfunktionen oder Zeitwerte, die zum Backend-DBMS passen (z. B. pg_sleep(n) für PostgreSQL). Der PoC demonstriert Blind-Injection über Timing; komplexere Nutzlasten könnten verwendet werden, um Daten Bit für Bit zu extrahieren.

🧪 Angriffsvektoren & Auswirkungen

• Angriffsvektor: Ein authentifizierter Benutzer erstellt GET-Anfragen an /api/method/frappe.client.get_value mit einem bösartigen Parameter fieldname, der SQL-Nutzlasten (Zeitverzögerungsfunktionen) enthält.

• Auswirkungen:

  • Denial of Service: Erzwungene Verzögerungen in der Serverantwort (Ressourcenerschöpfung bei Missbrauch).
  • Informationsoffenlegung: Blinde Extraktion von Daten über zeitbasierte Techniken (bitweise/zeitbedingte Abfragen).
  • Datenmanipulation: Potenzielle Möglichkeit, den Datenbankzustand zu verändern, falls andere SQL-Injection-Vektoren verfügbar sind.
  • Sonstiges: Eskalation der Auswirkungen je nach den Datenbankberechtigungen des Anwendungsbenutzers.

🔐 Empfehlungen zur Abschwächung

1. Parametrisierte Abfragen / Prepared Statements: Stelle sicher, dass fieldname und sämtliche benutzergelieferten Eingaben niemals direkt in SQL verkettet werden. Verwende parametrisierte Abfragen oder ORM-APIs, die Parameter ordnungsgemäß binden.
2. Strikte Eingabevalidierung / Whitelisting: Validiere Parameter, die Feldnamen oder Bezeichner sein sollen, gegen eine strikte Allowlist bekannter gültiger Feldnamen oder verwende serverseitiges Mapping, anstatt rohe Feldbezeichner von Clients zu akzeptieren.
3. Bezeichner sicher escapen: Wenn Bezeichner dynamisch verwendet werden müssen, nutze sichere DB-spezifische Funktionen zum Quoten/Escapen von Bezeichnern — und beschränke die zulässigen Werte trotzdem.
4. Datenbankkonto mit geringsten Rechten: Betreibe die Anwendung mit einem Datenbankbenutzer, der nur die notwendigen Berechtigungen besitzt (wo möglich schreibgeschützt für Reporting-Endpunkte).
5. Rate-Limiting & Monitoring: Wende Rate-Limits an und erkenne anomale Anfragemuster oder wiederholte Zeitverzögerungstests; alarmiere bei verdächtigem Datenverkehr.
6. Audit & Protokollierung: Protokolliere Anfragen an sensible API-Endpunkte und überwache auf verdächtige Nutzlasten (z. B. sleep, pg_sleep, benchmark, /, ;).
7. Patch & Release: Die Entwickler von Frappe/ERPNext sollten frappe.client.get_value und den Codepfad, der fieldname/Filter verarbeitet, überprüfen, unsichere Verkettung durch sichere APIs ersetzen und einen Sicherheitspatch veröffentlichen. Betreiber sollten Updates umgehend einspielen.

🔗 Referenzen

• Entdecker / Melder: Mohammed Aloli — GitHub: https://github.com/MoAlali — X: https://x.com/alaliksa_ — LinkedIn: https://www.linkedin.com/in/mohammedaloli/
• Codebasen von Frappe / ERPNext (Überprüfung und Patch): https://github.com/frappe/frappe , https://github.com/frappe/erpnext
• Allgemeine SQLi-Anleitung: OWASP SQL-Injection-Cheat-Sheet — https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

🙏 Danksagungen

Entdeckt von Mohammed Aloli

📢 Haftungsausschluss

Diese Informationen werden ausschließlich zu Verteidigungs- und Abhilfezwecken bereitgestellt. Versuche nicht, diese Schwachstelle gegen Systeme auszunutzen, die dir nicht gehören oder für die du keine ausdrückliche Genehmigung zum Testen hast. Betreiber sollten dem Patchen Priorität einräumen, sichere Codierungsmaßnahmen anwenden und den oben genannten Empfehlungen zur Abschwächung folgen.