TLStorm 2.0: 5 kritische Schwachstellen in Netzwerk-Switches (Aruba und Avaya)

Sicherheit (Pexels, allgemeine Nutzung)[English]Netzwerkswitches von Aruba und Avaya sind durch 5 Schwachstellen für RCE-Angriffe anfällig. Sicherheitsforscher des auf vernetzte Geräte spezialisierten Unternehmens Armis, die die Schwachstellen entdeckten, nennen diese "TLStorm 2.0" – weil es bereits den Fall TLStorm gab (ich hatte diesen Artikel TLStorm: 3 kritische 0-day-Schwachstellen gefährden Smart-UPS von APC zu der ursprünglichen Entdeckung der Schwachstelle TLStorm bei intelligenten UPS-Einheiten hier im Blog veröffentlicht).


Anzeige

Bei TLStorm 2.0 handelt es sich um Sicherheitslücken in der Implementierung von TLS-Kommunikation in mehreren Modellen von Netzwerk-Switches. Sie beruhen auf einem ähnlichen Designfehler wie die TLStorm-Schwachstellen (die im März 2022 von Armis entdeckt wurden, siehe TLStorm: 3 kritische 0-day-Schwachstellen gefährden Smart-UPS von APC). Die neuen Schwachstellen erweitern die Reichweite der von TLStorm Geräte auf Millionen weiterer Netzwerkinfrastrukturgeräte in Unternehmen.

Die Hauptursache für diese Schwachstellen war ein Missbrauch von NanoSSL, einer beliebten TLS-Bibliothek von Mocana. Mithilfe der Armis Device Knowledgebase – einer Datenbank mit mehr als zwei Milliarden Assets – identifizierten die Sicherheitsforscher von Armis Dutzende von Geräten, die die NanoSSL-Bibliothek von Mocana verwenden. Die Ergebnisse umfassen nicht nur die Smart-UPS-Geräte von APC, sondern auch zwei beliebte Netzwerk-Switch-Anbieter (Aruba und Avaya), die von einem ähnlichen Implementierungsfehler der Bibliothek betroffen sind. Während sich USV-Geräte und Netzwerk-Switches in ihrer Funktion und dem Grad des Vertrauens innerhalb des Netzwerks unterscheiden, können die zugrunde liegenden TLS-Implementierungsprobleme verheerende Folgen haben.

TLStorm 2.0-Studie

Die neue, von Armis erstellte TLStorm 2.0-Studie deckt Schwachstellen auf, die es einem Angreifer ermöglichen könnten, die vollständige Kontrolle über Netzwerk-Switches zu übernehmen, die in Flughäfen, Krankenhäusern, Hotels und anderen Organisationen weltweit eingesetzt werden. Die betroffenen Hersteller sind Aruba (von HPE übernommen) und Avaya Networking (von Extreme Networks übernommen).

Die Sicherheitsforscher fanden bei beiden Herstellern Switches, die anfällig für Remote Code Execution (RCE)-Schwachstellen sind, die über das Netzwerk ausgenutzt werden können, was zu Folgendem führt:

  • Aufbrechen der Netzwerksegmentierung, so dass durch Änderung des Switch-Verhaltens ein Übergreifen auf weitere Geräte möglich ist
  • Datenexfiltration von Unternehmensnetzwerkverkehr oder sensiblen Informationen aus dem internen Netzwerk in das Internet
  • Ausbruch aus dem „Captive Portal"

Diese Erkenntnisse verdeutlichen, dass durch TLStorm 2.0  die Netzinfrastruktur selbst gefährdet ist und von Angreifern ausgenutzt werden kann. Dies wiederum bedeutet, dass eine Netzsegmentierung allein als Sicherheitsmaßnahme nicht mehr ausreicht. Barak Hadad, Head of Research bei Armis sagt dazu:

Die Sicherheitsforschung bei Armis wird von einem einfachen Ziel angetrieben: Aufkommende Sicherheitsbedrohungen zu identifizieren, um unseren Kunden einen kontinuierlichen Schutz in Echtzeit zu bieten. Die TLStorm-Schwachstellen sind ein Paradebeispiel für Bedrohungen von Assets, die bisher für die meisten Sicherheitslösungen nicht sichtbar waren, und zeigen, dass eine Netzwerksegmentierung nicht mehr ausreicht und eine proaktive Netzwerküberwachung unerlässlich ist. Die Sicherheitsforscher von Armis werden weiterhin Assets in allen Umgebungen untersuchen, um sicherzustellen, dass unsere Wissensdatenbank mit mehr als zwei Milliarden Assets allen unseren Partnern und Kunden die neuesten Bedrohungsabwehrmaßnahmen zur Verfügung stellt.

Captive Portals

Ein Captive Portal ist die Webseite, die neu verbundenen Benutzern eines Wi-Fi- oder kabelgebundenen Netzwerks angezeigt wird, bevor ihnen ein umfassenderer Zugriff auf Netzwerkressourcen gewährt wird. Captive Portals werden üblicherweise verwendet, um eine Anmeldeseite zu präsentieren, die eine Authentifizierung, Zahlung oder andere gültige Anmeldeinformationen erfordert, denen sowohl der Host als auch der Benutzer zustimmen. Captive Portals ermöglichen den Zugang zu einer breiten Palette von mobilen und "Pedestrian"-Breitbanddiensten, einschließlich Kabel- und kommerziell bereitgestelltem Wi-Fi und Heim-Hotspots sowie kabelgebundenen Netzwerken in Unternehmen oder Privathaushalten, z. B. in Apartmentkomplexen, Hotelzimmern 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 erlangen, ohne dass eine Authentifizierung erforderlich ist. Sobald der Angreifer die Kontrolle über den Switch erlangt hat, kann er das Captive Portal vollständig deaktivieren und lateral in das Unternehmensnetzwerk eindringen.

Schwachstellendetails und betroffene Gerätetypen

Aruba

In Aruba Netzwerkswitches gibt es die Schwachstelle CVE-2022-23677 (CVSS Score 9,0) in der NanoSSL-Bibliothek, die einen NanoSSL-Missbrauch bei verschiedenen Interfaces (RCE) ermöglicht. Die oben erwähnte NanoSSL-Bibliothek wird in der Firmware von Aruba-Switches für mehrere Zwecke verwendet. Es gibt zwei Hauptanwendungsfälle, bei denen die mit der NanoSSL-Bibliothek hergestellte TLS-Verbindung nicht sicher ist und zu RCE führen kann:


Anzeige

  • Captive Portal – Ein Benutzer des Captive Portals kann vor der Authentifizierung die Kontrolle über den Switch übernehmen.
  • RADIUS-Authentifizierungs-Client – Eine Schwachstelle in der RADIUS-Verbindungsprüfung könnte es einem Angreifer ermöglichen, die RADIUS-Verbindung über einen Man-in-the-Middle-Angriff abzufangen und ohne Benutzerinteraktion einen RCE über den Switch zu erlangen.

Weiterhin gibt es CVE-2022-23676 (CVSS Score 9,1) in der Radius-Implementierung in Form von RADIUS Client Memory Corruption-Schwachstellen. RADIUS ist ein Client/Server-Protokoll zur Authentifizierung, Autorisierung und Abrechnung (AAA), das die zentrale Authentifizierung von Benutzern ermöglicht, die versuchen, auf einen Netzdienst zuzugreifen. Der RADIUS-Server antwortet auf Zugriffsanfragen von Netzwerkdiensten, die als Clients fungieren. Der RADIUS-Server prüft die Informationen in der Zugriffsanfrage und antwortet mit der Genehmigung des Zugriffsversuchs, einer Ablehnung oder einer Aufforderung zur Einholung weiterer Informationen.

In der RADIUS-Client-Implementierung des Switches gibt es zwei Schwachstellen in Bezug auf Speicherkorruption; sie führen zu Heap-Überläufen von Daten, die von Angreifern kontrolliert werden. Dies kann es einem böswilligen RADIUS-Server oder einem Angreifer mit Zugriff auf das gemeinsame RADIUS-Geheimnis ermöglichen, aus der Ferne Code auf dem Switch auszuführen.

Aruba-Geräte, die von TLStorm 2.0 betroffen sind:

  • Aruba 5400R Series
  • Aruba 3810 Series
  • Aruba 2920 Series
  • Aruba 2930F Series
  • Aruba 2930M Series
  • Aruba 2530 Series
  • Aruba 2540 Series

Sicherheitslücken im Avaya Management Interface vor der Authentifizierung

Die Angriffsfläche für alle drei Schwachstellen der Avaya-Switches ist das Web-Management-Portal, und keine der Schwachstellen erfordert eine Art der Authentifizierung, was sie zu einer Zero-Click-Schwachstellengruppe macht.

CVE-2022-29860 (CVSS Score 9,8) – TLS Reassembly Heap Overflow

Dies ist eine ähnliche Sicherheitslücke wie CVE-2022-22805, die Armis in APC Smart-UPS-Geräten gefunden hat. Der Prozess, der POST-Anfragen auf dem Webserver verarbeitet, validiert die NanoSSL-Rückgabewerte nicht ordnungsgemäß, was zu einem „Heap Overflow" führt, der zur Remote Code-Ausführung führen kann.

CVE-2022-29861 (CVSS Score 9,8) – HTTP Header Parsing Stack Overflow

Eine unsachgemäße Begrenzungsprüfung bei der Behandlung von mehrteiligen Formulardaten in Kombination mit einer Zeichenkette, die nicht null-terminiert ist, führt zu einem vom Angreifer kontrollierten „Stack Overflow", der zu einem RCE führen kann.

HTTP POST Request Handling Heap Overflow

Eine Schwachstelle in der Behandlung von HTTP-POST-Anfragen aufgrund fehlender Fehlerprüfungen der Mocana-NanoSSL-Bibliothek führt zu einem „Heap Overflow" mit vom Angreifer kontrollierter Länge, was zu einem RCE führen kann. Diese Schwachstelle hat kein CVE, da sie in einer aufgekündigten Produktlinie von Avaya gefunden wurde. Dies bedeutet, dass kein Patch herausgegeben wird, um diese Schwachstelle zu beheben, obwohl Daten von Armis zeigen, dass diese Geräte immer noch in freier Wildbahn gefunden werden können.

Avaya-Geräte, die von TLStorm 2.0 betroffen sind:

  • ERS3500 Series
  • ERS3600 Series
  • ERS4900 Series
  • ERS5900 Series

Updates und Abhilfemaßnahmen

Aruba und Avaya haben in dieser Angelegenheit mit Armis zusammengearbeitet. Die Kunden wurden benachrichtigt und erhielten Patches, um die meisten der Schwachstellen zu beheben. Nach Armis' Kenntnisstand gibt es keine Hinweise darauf, dass die TLStorm 2.0-Schwachstellen ausgenutzt wurden.

  • Unternehmen, die betroffene Aruba-Geräte einsetzen, sollten die betroffenen Geräte sofort mit Patches aus dem Aruba Support Portal hier patchen.
  • Unternehmen, die betroffene Avaya-Geräte einsetzen, sollten die Sicherheitshinweise sofort im Avaya Support Portal hier überprüfen.

Armis-Experten werden die Ergebnisse der TLStorm-Analyse auf der Black Hat Asia 2022 (10. bis 13. Mai 2022) unter dem Titel Like Lightning From the Cloud: Finding RCEs in an Embedded TLS Library and Toasting a Popular Cloud-connected UPS präsentieren.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Geräte, Sicherheit abgelegt und mit Geräte, Sicherheit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

3 Antworten zu TLStorm 2.0: 5 kritische Schwachstellen in Netzwerk-Switches (Aruba und Avaya)

  1. Stephan sagt:

    Warum macht ein Switch überhaupt TLS? Der sollte einfach Ethernet Frames durchreichen.

    • Stefan A. sagt:

      Weil die Teile bisschen mehr können, als nur „Ethernet Frames durchreichen".
      Stichwort: Layer-3-Switch

      • Stephan sagt:

        Das ist mir schon bekannt. Meine Kritik setzt ja genau da an: Auf Layer 3 sollte man Router betreiben und keine Switches. Diese Vermischung von Ebenen bringt nur Unheil.

        Mal abgesehen davon machen Router aber auch kein TLS.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.