Im Rahmen der Unterstützung eines Kunden sind wir 2021 auf CVE-2022-33757, eine Schwachstelle in den Schwachstellenscannern Nessus bzw. Nessus Manager aufmerksam geworden. Durch eine Schwachstelle waren Scan-Attachments ungeschützt und konnten bei Kenntnis des Links ohne Authentifizierung abgerufen werden. Ebenso konnten Nutzer, die selbst keinen Zugriff auf die Scan-Attachments hatten, durch eine Manipulation des Links zum Anhang auf die Dateien zugreifen.
Was sind eigentlich Nessus und Nessus Manager
Nessus ist ein Infrastruktur-Schwachstellen-Scanner und eines der Hauptprodukte der Firma Tenable. Ursprünglich als Open-Source-Produkt gestartet, wird Nessus seit Version 3 unter einer kommerziellen Lizenz veröffentlicht.
Der Nessus Manager ist eine Spezialvariante von Nessus, die ebenfalls Nessus-Agenten verwalten kann. Nessus-Agenten könnten auf Servern oder Clients installiert werden und das System auf Schwachstellen untersuchen.
Es fing an mit einem… Öhm?
Wir waren dabei, Probleme bei einem Nessus-Scan zu untersuchen. Ein Mittel hierzu ist, das Nessus während des Scans zusätzliche Protokolldaten erfasst und diese als Debugging-Log in den Scan-Ergebnissen als Anhänge aufführt.
Beim Teilen eines Links einer solchen Log-Datei fiel uns auf, dass der Zugriff auf die Datei möglich war, selbst wenn man nicht in Nessus eingeloggt war. Allein mit Kenntnis des richtigen Links war es also möglich, auf Log-Dateien des Scans zuzugreifen, sofern man die Nessus-Instanz im Browser erreichen konnte.
Wir haben dann die offensichtliche Schwachstelle genauer untersucht. Nach Aunserer Analyse haben wir die Schwachstelle über eine Responsible Disclosure an Tenable gemeldet. 7 Monate nach unserer Meldung wurde die Schwachstelle von Tenable behoben.
Proof of Concept
Getestet mit Nessus 10.0.x und 10.1.x
- Einen Nessus-Scan erstellen und „Enable plugin debugging“ in den erweiterten Scan-Einstellungen aktivieren
- Den Scan starten und die Ergebnisse nach dem Abschluss aufrufen
- Die Ergebnisse für den „Debugging Log Report“ (Plugin 84239) für einen beliebigen Host öffnen
- Eine der angehängten Log-Dateien mit einem Klick öffnen
- Die Datei öffnet sich in einem neuen Browser-Tab bzw. -Fenster
- Den Link zum Anhang aus der Adresszeile des Anhangs kopieren
- Aus Nessus ausloggen bzw. einen anderen Browser öffnen
- Den Link in die Adresszeile einfügen
- Der Anhang wird angezeigt
Details
Die Struktur eines Anhang-Links war zum Zeitpunkt des Reports wie folgt:
/scans/$ScanId/attachments/$AttachmentKey?key=$HashValue_$UserId_0Die User-ID ist dabei die ID des Users, der die Berechtigung hat, die Scan-Ergebnisse anzusehen. Allerdings ist der Zugriff auf die Anhänge eingeschränkt. Nur der Nessus-Administrator-Account, der den Scan erstellt hat, darf die Debugging-Logs aufrufen, selbst anderen Administratoren blieb der Zugriff verwehrt. Beim Nessus Manager war die Situation etwas komplexer, da hier ein abgestufteres Rollenkonzept Anwendung findet.
Nun ist es leicht, die User-ID zu erraten. Der bei der Installation erstellte Admin-Account hat immer die User-ID 2 und dürfte in vielen Installationen nie gelöscht werden. User-IDs werden mit jedem neuen User inkrementiert, daher ist es recht einfach, die User-ID zu erraten. Außerdem ist es möglich, die User-ID von anderen Nutzern über das Web-Interface bzw. die API zu ermitteln.
Nehmen wir an, es gibt zwei User im System:
| UserID | Username | Zugriffsrechte |
|---|---|---|
| 2 | admin | Systemadministrator (Standardaccount) |
| 3 | evil | Systemadministrator oder weniger |
Der Benutzer admin hat einen neuen Scan erzeugt und „Plugin Debugging“ aktiviert. Ein funktionierender Link für den Nutzer könnte also sein:
https://10.0.0.1:8834/scans/1/attachments/3?key=cd8e43757ffc27fb993dcc7ec8a9ff9c_2_0.| Wert | Beschreeibung |
|---|---|
| 3 | ID des Attachments |
| ?key=cd8e43757ffc27fb993dcc7ec8a9ff9c | Hash des Attachments |
| _2 | User-ID des Users admin mit vorgestelltem Unterstrich |
| _0 | Suffix ohne erkennbare Funktion |
Wenn unser user „evil“ sich die gleiche Datei ansehen will, sieht sein Link so aus:
https://10.0.0.1:8834/scans/1/attachments/3?key=cd8e43757ffc27fb993dcc7ec8a9ff9c_3_0Es fällt sofort auf, dass sich die Urls nur an einer Stelle unterscheiden: der User-ID.
Wenn nun aber der User „evil“ seine eigene User-ID „3“ durch die „2“ des admin-Users austauscht, wird die Datei angezeigt.
Das allein stellt schon eine „Broken Access Control“ dar. Allerdings geht die Schwachstelle noch darüber hinaus: sobald man den Link zur Datei mit der User-ID des Admin-Users kannte, war dies schon ausreichend. Man musste nur in der Lage sein, die Nessus-Instanz über den Browser zu erreichen. Die User-ID des Admin-Users überging jegliche Authentifizierung. Wenn z.B. ein Link per Mail geteilt wurde, wäre es möglich, dass jeder Mitarbeiter die Datei hätte abrufen können, sofern die Nessus-Instanz nicht durch Firewalls weiter abgeschottet war. Noch kritischer war es bei einer Nessus-Instanz, die über eine öffentliche IP-Adresse frei im Internet erreichbar war, hier war die Datei bei Kenntnis des Links frei zugänglich.
Wo Tenable nicht ganz richtig liegt
Leider ist die Beschreibung der Schwachstelle in dem Tenable Security Advisory tns-2022-11 nicht ganz korrekt. Tenable spricht davon, dass sich ein authentifizierter Angreifer Zugriff auf Debugging-Log-Attachments erlangen kann, auf die er keinen Zugriff hat.
Dies ist allerdings in zwei Punkten nicht ganz korrekt:
- Die Schwachstelle betraf alle Scan-Attachments, nicht nur Debug-Logs
- Die Kenntnis eines korrekten Links war ausreichend, es erfolgte keine Prüfung, ob der Zugreifende autorisiert ist. Ein Link, der beispielsweise per Mail weiterleitet worden war, ermöglichte es jedem, der die Nessus-Instanz erreichen konnte, das Attachment abzurufen
Fazit
Von außen entsteht der Eindruck, dass Tenable hier ein Feature integriert hat, welches nicht ausreichend getestet wurde. Möglicherweise waren Scan-Attachments ursprünglich nur ein „Hack“, um an Scan-Logs zu kommen, der später in das Hauptprodukt integriert wurde, ohne dass der Code noch einmal genau überprüft wurde. Außerdem scheint Tenable zumindest 2021 die Sicherheit der eigenen Produkte nicht genügend mittels automatisierter Tests (z.B. Unit- und Integrationstests) überprüft zu haben.
Ein grober Schnitzer war, dass mit dem Parameter der User-ID die Authentifizierung für diese Attachments umgangen werden konnten. Es zeigt auch, dass es leicht ist, einen Fehler bei der Programmierung zu machen, nicht umsonst ist „Broken Access Control“ die häufigste Schwachstelle der aktuellen Version der OWASP Top 10.
Timeline
| Datum | Berschreibung |
|---|---|
| 04.12.2021 | Meldung der Schwachstelle an den Hersteller Tenable per E-Mail, dort Weiterleitung auf das Portal HackerOne |
| 05.12.2021 | Triage der Schwachstelle durch HackerOne und Übergabe an das Tenable-Team |
| 07.01.2022 | Schwachstelle wird durch Tenable akzeptiert und ein Fix für die Nessus-Version 10.2 angekündigt |
| 26.05.2022 | Veröffentlichung von Nessus 10.2. und dem Tenable Security Advisory tns-2022-11 |
| 29.06.2022 | Tenable veröffentlicht die Details zu CVE-2022-33757 |