Autor: Yannik Meinhardt

In dem verlinkten Paper wird ein interessanter Seitenkanal in Wi-Fi-Netzwerken aufgedeckt. Es geht um die beobachtbare Rahmengröße von TCP-Paketen, die von Angreifern ausgenutzt werden kann, um TCP-Hijacking-Angriffe durchzuführen. Trotz der Implementierung verschiedener Sicherheitsmechanismen wie WEP und WPA2/WPA3, um Wi-Fi-Netzwerke zu schützen, zeigt die Studie, dass ein Angreifer ausreichend Informationen aus dem Seitenkanal extrahieren kann, um die TCP-Verbindung eines Opfers übernehmen zu können.

Die Angriffsmethode basiert auf zwei wichtigen Erkenntnissen: Erstens variieren die unterschiedlichen Typen von Antwortpaketen wie ACK und RST, die von TCP-Empfängern generiert werden, in ihrer Größe. Zweitens haben die verschlüsselten Rahmen, die diese Antwortpakete enthalten, konsistente und nach Typ unterscheidbare Größen. Durch Beobachtung der Größe der verschlüsselten Rahmen kann der Angreifer den Status bzw. die korrekte Sequenznummer der TCP-Verbindung des Opfers erkennen und in der Folge die Verbindung entweder terminieren oder arbiträre Daten einspeisen.

Die Wirksamkeit dieses Seitenkanal-Angriffs wird durch zwei Fallstudien bestätigt: Ein SSH-DoS und die Manipulation von Web-Traffic. Zudem werden umfangreiche Messungen durchgeführt, um die Auswirkungen des Angriffs auf reale Wi-Fi-Netzwerke zu bewerten. Dabei werden 30 beliebte drahtlose Router von neun bekannten Herstellern getestet. Keiner dieser Router kann Opfer vor dem Angriff schützen. Außerdem werden der Angriff in realen Wi-Fi-Netzwerken implementiert und die TCP-Verbindungen der Opfer in 69 der 80 evaluierten Wi-Fi-Netzwerke erfolgreich übernommen (86 %).

Die Schwachstelle wurde verantwortungsbewusst der Wi-Fi Alliance gemeldet, ebenso wurden mehrere Maßnahmen vorgeschlagen, um das Problem auf Protokoll-Ebene anzugehen. Als Anwender muss man mit dieser Möglichkeit umgehen, indem man den Zugang zu seinen WiFi-Netzwerken über bspw. starke Passwörter oder MAC-Filtering reguliert.

Zum Paper in voller Länge: https://arxiv.org/abs/2402.12716

Zu dieser Frage herrscht Uneinigkeit in unserer Branche. Das BSI benennt als Anforderung, dass bei TLS-Verbindungen eine RSA-Schlüssellänge von mindestens 3.000 Bits verwendet werden sollte. Die US-Standardisierungsbehörde NIST gibt an, dass RSA-Schlüssellängen mit 2.048 Bit noch bis 2030 als ausreichend sicher gelten.

Wichtig in dieser Diskussion ist, den Anwendungsfall von RSA im TLS-Verfahren zu berücksichtigen. Es wird verwendet, um die Authentizität des Servers gegenüber dem Client zu bestätigen – und im Fall von mTLS auch die des Clients gegenüber dem Server. Obwohl mittels RSA keine Inhalte verschlüsselt werden und ein mögliches Brechen eines RSA-Schlüssels in der Zukunft keine Auswirkungen auf bereits aufgezeichneten verschlüsselten Verkehr hätte (die Anwendung von Perfect-Forward-Secrecy vorausgesetzt), muss die Sicherheit des Signaturverfahrens für die Verwendungsdauer des Schlüssels gewährleistet sein: üblicherweise ein Jahr bei öffentlichen Client/Server-Zertifikaten, ca. 3-5 Jahre bei internen Client/Server-Zertifikaten oder ca. 20-30 Jahre bei CA-Zertifikaten.

Ein Wechsel zu einem Zertifikat mit einem längeren Schlüssel hat nicht nur formale, sondern auch praktische Auswirkungen auf die Leistung des Servers, da mit der Schlüssellänge auch die benötigte Rechenzeit für die Signaturerstellung steigt. Webserver, die viele Verbindungsaufbauten gleichzeitig bedienen, müssen bei einem längeren Schlüssel bei jedem Verbindungsaufbau die aufwendigeren Signaturen erstellen und ggf. Signaturprüfungen durchführen, was zu einer höheren Belastung führen kann. Damit steigt auch das Risiko für DDoS-Attacken bei längeren Schlüsseln.

Dieser Diskurs wirkt auf uns jedoch wenig zielführend. Die Schlüssellänge bei RSA ist ein reiner Wettlauf gegen die Zeit, da klassische Computer immer leistungsstärker werden. Und spätestens mit dem Erscheinen eines kryptografisch relevanten Quantencomputers hat sich das Thema RSA erledigt, da für diesen das Ermitteln des geheimen Schlüssels auf Basis des öffentlichen Schlüssels kein schweres Problem mehr darstellt. Auch wenn elliptische Kurven (ECC) noch zur klassischen asymmetrischen Kryptografie zählen, sollten diese anstelle des RSA-Verfahrens eingesetzt werden, da sie mit geringeren Schlüssellängen auskommen und eine bessere Gesamtperformance bieten. Oder besser, man geht den Weg, den auch die Messenger-App Signal eingeschlagen hat, mit einer Komposition aus ECC und einem PQC-Kandidaten, um gegen kryptografisch relevante Quantencomputer gewappnet zu sein.

Meldung auf heise online: https://www.heise.de/news/Microsoft-RSA-Schluessellaengen-von-2048-Bit-reichen-fuer-TLS-Zertifikate-9657480.html

Wissenschaftliches Paper zum Vergleich von RSA und ECC: https://www.researchgate.net/publication/322558426_RSA_and_ECC_A_comparative_analysis

Blogpost von Signal zu deren PQC-Strategie: https://signal.org/blog/pqxdh/

Bereits im Februar-Digest hatten wir über den Angriff Midnight Blizzards und die damit einhergehenden Verfehlungen Microsofts berichtet. In der Zwischenzeit hat sich die Lage noch weiter verschärft, nachdem bekannt wurde, dass ein im Angriff gestohlener Schlüssel dazu berechtigte, in vielen Cloud-Diensten Microsofts Zugangstoken für Benutzerkonten anlegen zu können. Dieser Master-Key ist zwar nun gesperrt – es bestand zeitweise jedoch die Möglichkeit des Anlegens von Hintertür-Accounts in Cloud- und teilweise auch OnPrem-Applikationen des Anbieters.

Ein Review Board der US-amerikanischen Cybersecurity and Infrastructure Security Agency (CISA), dem Pendant des deutschen BSI, hat den Vorfall nun noch einmal genauer unter die Lupe genommen und Microsofts Fehler in Form eines Berichtes aufbereitet.

Der Bericht wirft Microsoft vielfaches Versagen bei der Cybersicherheit vor und betont, dass der Technologieriese den Angriff nicht selbst entdeckt hat, sondern erst durch einen Kunden darauf aufmerksam gemacht wurde. Der Bericht untergräbt weiter das Vertrauen in Microsofts Sicherheitskultur durch das Aufdecken falscher Behauptungen bezüglich der Ursachenfindung des Vorfalls und fordert das Unternehmen auf, eine kulturelle Veränderung hin zu mehr Sicherheit, Verantwortlichkeit und Transparenz voranzutreiben.

Unser Digest vom Februar: https://www.hisolutions.com/detail/digest-februar-2024

Bericht der CISA: https://www.cisa.gov/resources-tools/resources/cyber-safety-review-board-releases-report-microsoft-online-exchange-incident-summer-2023

Gestartet als Wurm, der über USB-Sticks verteilt wurde, ist Raspberry-Robin heute Teil eines komplexen Malware-Ökosystems. Dabei führt die Schadsoftware häufig die initiale Infizierung der Endpunkte eines Opfers durch, damit anschließend weitere Malware zwecks Lateral Movement (Infektion weiterer Systeme im Netz) und Rechteausweitung nachgeladen werden kann. Bekannte kriminelle Gruppierungen sind dafür bekannt, die Malware zu verwenden, um unter anderem auch die bereits thematisierte Ransomware von LockBit auszurollen.

Um wirksam zu bleiben und Erkennungsmechanismen zu umgehen, verändert sich die Malware kontinuierlich. Die Verwendung neuartiger Verbreitungsmethoden, wie dem Versenden von RAR-Dateien über Discord, und die kontinuierliche Weiterentwicklung von Bypass-Techniken stellen eine zusätzliche Herausforderung für den Schutz dar. Häufig sind es sogenannte 1-Day-Exploits, die sich Raspberry-Robin zunutze macht. Das bedeutet, dass Entwickler in kürzester Zeit auf neu entdeckte Sicherheitslücken reagieren, ihre Malware anpassen oder enge Beziehungen zu Exploit-Verkäufern pflegen, um die aktualisierte Malware zu verbreiten, noch bevor Opfer ihre Systeme aktualisieren können. Jüngst hat sich dies in zwei neuen 1-Days manifestiert, dessen weitere Erläuterung wir am Ende verlinkt haben.

Für uns hat das zur Folge, dass wir mit einer sich ständig verändernden Bedrohungslandschaft Schritt halten müssen. Neben präventiven Sicherheitsmaßnahmen, wie dem schnellen Einspielen von Patches, bleibt es wichtig, über reaktive Maßnahmen, etwa ein ausgeklügeltes Konzept für XDR (Extended Detection & Response) oder MDR (Managed Detection & Response) zu verfügen.

Einen Deep Dive zu den zuletzt verwendeten Schwachstellen durch Raspberry-Robin finden Sie hier:
https://research.checkpoint.com/2024/raspberry-robin-keeps-riding-the-wave-of-endless-1-days/

HiSolutions hat auch 2024 die große Zahl durchgeführter Penetrations- und Schwachstellentests vom Vorjahr nach Schweregrad und Kategorien analysiert.

Hieraus können interessante Trends und Entwicklungen für die Sicherheitslage in Ihrem Unternehmen oder Ihrer Organisation abgeleitet werden.

Die gute Nachricht: Unternehmen, die sich proaktiv mit IT-Sicherheit beschäftigen, schaffen es immer besser, kritische Schwachstellen in externen Systemen zu erkennen und zeitnah zu beheben.

Zum Schwachstellenreport 2024: https://www.hisolutions.com/detail/schwachstellenreport-2024