Netzwerkbedrohung
TLS-Implementierungsfehler öffnen Aruba- und Avaya-Netzwerk-Switches für RCE-Angriffe
Foto: Den Rise - shutterstock.com
Nach den Angaben der Forscher der Sicherheitsfirma Armis sind mehrere Serien von Netzwerk-Switches von Aruba Networks, das zu Hewlett Packard Enterprise gehört, und Avaya, einer Tochter von Extreme Networks, anfällig für RCE-Angriffe (Remote Code Execution). Die Schwachstellen sind auf Fehler zurückzuführen, die die Hersteller bei der Implementierung der eingebetteten TLS-Bibliothek gemacht haben. Insgesamt konnten die Sicherheitsexperten fünf Sicherheitslücken aufdecken, die unter dem Namen TLStorm 2.0 zusammengefasst werden.
Die Gefahr: Die Switches werden zur Isolierung öffentlicher Netzwerksegmente in Flughäfen, Krankenhäusern, Hotels und anderen Organisationen verwendet - oft ohne Authentifizierung. Über die Sicherheitslücke könnten Angreifer die vollständige Kontrolle solcher Netzwerke übernehmen.
"In den letzten Monaten haben wir eine zunehmende Anzahl von Schwachstellen in gängigen Bibliotheken festgestellt, wobei Log4Shell und Spring4Shell zu den auffälligsten zählen", so die Armis-Forscher in ihrem Bericht. "Es ist zwar klar, dass fast jede Software auf externe Bibliotheken angewiesen ist, aber diese Bibliotheken bringen neue Risiken für die Host-Software mit sich. Im Fall von Mocana NanoSSL gibt das Handbuch klar die richtige Bereinigung im Falle eines Verbindungsfehlers an, doch wir haben bereits gesehen, dass mehrere Anbieter die Fehler nicht richtig behandelt haben, was zu Speicherbeschädigungen oder zu Verwirrung über den aktuellen Zustand führte."
Was sind NanoSSL und TLStorm?
Zunächst entdeckten die Armis-Forscher kritische Schwachstellen, genannt TLStorm, in APC SmartUPS-Geräten, die darauf zurückzuführen sind, dass der Hersteller einige der Implementierungsempfehlungen der NanoSSL-Entwickler nicht befolgt hat. NanoSSL ist eine Closed-Source-TLS-Bibliothek für eingebettete Geräte. Sie wurde von Mocana entwickelt, einem IoT-Sicherheitsunternehmen, das kürzlich von DigiCert übernommen wurde.
Implementierungsfehler kommen bei kryptografischen Bibliotheken im Allgemeinen häufig vor. Bei den APC SmartUPS-Schwachstellen steckten die Fehler im Code, der die Herstellerlogik und die NanoSSL-Bibliothek miteinander verband. Bei der Untersuchung der TLStorm-Schwachstellen identifizierte das Forscherteam Dutzende von Geräten, die die NanoSSL-Bibliothek verwenden, darunter auch Netzwerk-Switches von Aruba und Avaya. Diese Geräte offenbarten die gleichen Probleme bei der Implementierung der Bibliothek mit ähnlich schwerwiegenden Auswirkungen..
Umgehung der Netzwerksegmentierung und unverschlüsselter Portale
Netzwerk-Switches werden häufig verwendet, um aus Sicherheitsgründen VLAN-Segmente (Virtual Local Area Network) voneinander zu isolieren. So ist es beispielsweise üblich, dass Unternehmen Gastnetzwerke, entweder Wi-Fi oder kabelgebunden, vom größeren Unternehmensnetzwerk trennen. Zudem werden kritische Geräte oder Server innerhalb eines eigenen, eingeschränkteren Netzwerksegments isoliert, auf das vom allgemeinen Unternehmensnetzwerk nicht ohne zusätzliche Authentifizierung zugegriffen werden kann.
Eine gängige Methode zur Authentifizierung des Netzwerkzugangs sind so genannte Captive Portals. Dabei handelt es sich im Wesentlichen um Webseiten, die neu hinzukommenden Benutzern angezeigt werden und auf denen sie aufgefordert werden, sich zu authentifizieren oder bestimmte Bedingungen zu akzeptieren, bevor sie Zugriff auf das Internet oder andere Netzwerkressourcen erhalten. Captive Portals sind bei Gastnetzwerken sehr verbreitet, von Flughäfen, Krankenhäusern und Hotels bis hin zu Cafés, Wohnhäusern und Geschäftszentren.
"Unter Ausnutzung der TLStorm 2.0-Schwachstellen kann ein Angreifer das Captive Portal missbrauchen und Remote-Code-Ausführung über den Switch erreichen, ohne dass eine Authentifizierung erforderlich ist", warnen die Armis-Forscher. "Sobald der Angreifer die Kontrolle über den Switch hat, kann er das Captive Portal vollständig deaktivieren und sich ungehindert mit dem Unternehmensnetzwerk verbinden."
Sobald die Angreifer die Kontrolle über den Switch haben, können sie auch die Netzwerksegmentierung umgehen und von einem VLAN in ein anderes springen. Dies ermöglicht laterale Bewegungen im gesamten Netzwerk und in Netzwerksegmenten, die eigentlich vom Internet isoliert sein sollten.
Die NanoSSL-Implementierungsfehler in Aruba-Switches können durch TLS-Verbindungen ausgenutzt werden, die sowohl mit der Captive-Portal-Funktion als auch mit dem RADIUS-Protokoll arbeiten. RADIUS ist ein Client-Server-Netzwerkauthentifizierungs- und -autorisierungsprotokoll, das für die zentrale Verwaltung von Benutzern verwendet wird, die auf Netzwerkdienste zugreifen. Netzwerk-Switches enthalten einen RADIUS-Client, der sich mit dem zentralen RADIUS-Server verbindet, um den Zugriff auf verschiedene Ressourcen anzufordern.
"Eine Schwachstelle in der RADIUS-Verbindungsbehandlung könnte es einem Angreifer ermöglichen, die RADIUS-Verbindung über einen Man-in-the-Middle-Angriff abzufangen, um ohne Benutzerinteraktion RCE über den Switch zu erlangen", so die Armis-Forscher.
Unabhängig davon kann ein Benutzer des Captive Portals vor der Authentifizierung die Kontrolle über einen anfälligen Switch übernehmen. Da beide Probleme auf eine unsachgemäße TLS-Verbindung über NanoSSL in Aruba-Switches zurückzuführen sind, werden sie zusammen als CVE-2022-23677 (9.0 CVSS Severity Score) erfasst. Die Forscher identifizierten außerdem zwei Speicherkorruptionsprobleme im RADIUS-Client von Aruba-Switches, die über Heap-Überläufe zur Ausführung von Malware-Code führen können, womit Angreifer die Steuerung übernehmen könnten. Diese werden separat als CVE-2022-23676 (9.1 CVSS-Score) verfolgt.
Die von diesen Schwachstellen betroffenen Aruba-Switch-Modelle sind:
· Aruba 5400R Series,
· 3810 Series,
· 2920 Series,
· 2930F Series,
· 2930M Series,
· 2530 Series und
· 2540 Series.
Die in den Avaya-Switches gefundenen Schwachstellen können über das Web-Management-Portal ausgenutzt werden.Keine der Schwachstellen erfordert eine Authentifizierung. Bei einer Schwachstelle (CVE-2022-29860) mit dem Schweregrad 9.8 handelt es sich um einen Heap-Überlauf, der aus der TLS-Wiederzusammensetzung resultiert. Dies wird durch eine unsachgemäße Validierung der NanoSSL-Rückgabewerte bei der Verarbeitung von POST-Anfragen an den Webserver verursacht.
Eine separate Schwachstelle im HTTP-Header-Parsing von Avaya-Switches bei der Verarbeitung von mehrteiligen Formulardaten in Kombination mit einer Zeichenkette, die nicht null-terminiert ist, kann ebenfalls einen von einem Angreifer kontrollierten Stapelüberlauf verursachen und zur Remote-Code-Ausführung führen. Diese Schwachstelle wird separat als CVE-2022-29861 (CVSS-Score 9,8) verfolgt.
Eine dritte RCE-Schwachstelle, die keine CVE-ID erhalten hat, wurde ebenfalls in einer nicht mehr hergestellten Avaya-Produktlinie gefunden und wird durch fehlende Fehlerprüfungen im Zusammenhang mit der NanoSSL-Bibliothek verursacht. Da die betroffenen Produkte nicht mehr gewartet werden, ist es unwahrscheinlich, dass diese Schwachstelle einen Patch erhält, aber die Daten von Armis zeigen, dass die betroffenen Geräte immer noch eingesetzt werden.
Bei den von TLStorm 2.0 betroffenen Avaya-Geräten handelt es sich um die
· ERS3500-Serie,
· ERS3600-Serie,
· ERS4900-Serie und
· ERS5900-Serie.
Entschärfung von TLStorm 2.0
Laut Armis gibt es bis dato noch keine Anzeichen dafür, dass die Schwachstellen von TLStorm 2.0 ausgenutzt wurden. Sowohl Aruba (HPE) als auch Avaya (Extreme Networks) haben ihre Kunden kontaktiert und Patches für die meisten Schwachstellen herausgegeben. Diese sind über die jeweiligen Kundensupport-Portale verfügbar.
Darüber hinaus empfiehlt Armis,Netzwerküberwachungslösungen zu implementieren, die Angriffsversuche für diese und andere Schwachstellen erkennen können, sowie die Angriffsfläche von Geräten zu begrenzen, beispielsweise durch das Blockieren des Zugriffs auf ihre Verwaltungsportale von Gastnetzwerken aus oder durch eine Beschränkung auf dedizierte Verwaltungsports.(jm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.