TL;DR: In diesem Text geht es um meinen Wechsel des Passwortmanagers, nachdem sich Lastpass als zu unzuverlässig erwiesen hat. Vorangestellt werden ein paar Überlegungen dazu, warum man eigentlich einen Passwortmanager braucht und wie man ihn sicher nutzt. Abschließend geht es um die Frage, wie mit dem Datenverlust bei Lastpass umzugehen ist: Muss ich jetzt alle meine Passworte ändern?

Eine der wesentlichen Regeln der Passwortsicherheit ist die Verwendung von individuellen Logins für jeden Dienst und Zweck. Angesichts immer wiederkehrender Verluste von Logindaten bei erfolgreichen Angriffen auf Webdienste kann man nur so den Schaden auf den jeweiligen Dienst begrenzt halten. Es nutzt nichts ein einzelnes, super sicheres Passwort zu haben, welches man immer verwendet. Denn schon ein erfolgreicher Einbruch bei einem einzigen der Dienste, bei denen man das Passwort verwendet, wird dazu führen, dass die Angreifer danach auch die anderen Dienste mit den so gewonnenen Logindaten erfolgreich angreifen. Diese Art des Angriffs ist so häufig, dass sie einen eigenen Namen bekommen hat: Credential stuffing

Auch 2-Faktor-Authentifizierungen ändern daran erst einmal nicht grundsätzlich etwas, und bis wir überall Passkeys einsetzen und keine Passworte mehr brauchen wird es noch etwas dauern.

Ein Passwortmanager ist unverzichtbar

Zwar kann man so eine Vorgehensweise auch ohne digitale Unterstützung umsetzen, entweder mit einem Notizbuch für die Passworte, oder durch Schemata, bei denen man ein komplexes Grundpasswort nach eigenen Regeln jeweils individualisiert, aber die Verwendung eines Passwortmanagers macht diese Vorgehensweise erst in einer Weise handhabbar, die den digitalen Lebenswandel und Arbeitsalltag nicht so sehr erschwert, dass es nicht mehr praktikabel ist.

Auch bieten die gängigen Passwortmanager einige Vorteile im Vergleich zu manuellen Lösungen:

• Generierung von Passworten: Es gibt üblicherweise Funktionen, um sich lange und zufällige Passworte mit vielen Zeichenvariationen mit einem Klick zu erzeugen. Zufällig generierte Passworte bieten den höchsten Schutz gegen Passwortrateversuche, selbst wenn Angreifer dabei sehr viel Zeit und sehr viel Rechenleistung zur Verfügung steht
• Umgang mit sehr langen Passworten: Der Passwortmanager nimmt einem eventuell noch vorhandene Hemmungen sehr lange Passworte zu verwenden. Also Passworte mit Längen jenseits von 30 Zeichen, die man bei einer manuellen Handhabung wohl eher scheut
• Schutz vor homographischen Angriffen: Wenn der Passwortmanager verwendet wird zum automatischen Ausfüllen von Logins in Webseiten kann man auf diese Art von Angriffen – bei denen sehr ähnliche oder gar völlig identisch aussehende Webadressen verwendet werden – nicht hereinfallen. Bzw. muss dann als Nutzer*in selbst aktiv die Logindaten eingeben und könnte sich bei der Gelegenheit wundern, warum der Passwortmanager das nicht tut

Aber es gibt natürlich auch Nachteile, gerade wenn es um die ganz besonders bequemen Passwortmanager mit einer Synchronisierung über die Cloud geht. Da heute nahezu jede*r mindestens 2 Geräte haben wird, auf denen man sich irgendwo einloggen will, muss man in der Lage sein die Inhalte des Passwortmanagers – nennen wir ihn den ‚Tresor‘ – sicher zwischen diesen Geräte zu transportieren.

Das kann man selbst machen, aber das ist mit einem gewissen Aufwand verbunden und braucht eine hohe Sorgfalt, damit keine Fehler beim Umgang mit diesen kritischen Daten passieren. Es gibt aber inzwischen eine Reihe von Anbietern, die die Passwortmanagerinhalte über die Cloud synchronisieren und dabei vor allem dies versprechen:

Zero Knowledge Architekturen

Mit dem ‚Null Wissen‘ ist dabei gemeint, dass der Anbieter des Passwortmanagers zwar die Inhalte in der Cloud speichert und so zwischen den Geräten synchronisieren kann, aber nicht in der Lage ist die Inhalte selbst zu sehen bzw. zu entschlüsseln. Das ist durch eine entsprechende Programmierung der Passwortmanagersoftware möglich, da die Entschlüsselung letztlich nur auf den Geräten der Nutzer*innen – also lokal und nicht in der Cloud – stattfinden muss.

Auf diese Weise lassen sich zwei Probleme lösen:

1. Wie viel Vertrauen brauche ich in meinen Passwortmanageranbieter? Je weniger der Anbieter von meinen Daten sehen kann, desto weniger Vertrauen muss ich zu ihm haben. Ganz ohne Vertrauen geht es natürlich nicht: Da meist die Passwortmanagersoftware vom gleichen Anbieter kommt wie die Cloudsoftware, die die Daten synchronisiert, muss ich darauf vertrauen, dass die Software nicht doch mein Passwort direkt in die Cloud schickt. Oder die Inhalte meines Passworttresors im Klartext
2. Was passiert, wenn meine ganzer Passwortschatz abhanden kommt? Da der Passwortmanager, wenn er richtig genutzt wird, der Schlüssel zum gesamten digitalen Leben ist, kann er in den falschen Händen maximalen Schaden anrichten. Dabei kann er sowohl vom eigenen Gerät entwendet werden, wie auch aus der Infrastruktur des Anbieters. Erfolgreiche Angriffe auf Clouddienste sind keine Seltenheit, dabei trifft es alle Ebenen: Vom grundlegenden Cloudserviceanbieter (Beispiel Rackspace) über die Softwareentwicklungsinfrastruktur (Beispiel Circle CI) bis hin zum IT Sicherheitsdienstleister selbst (Beispiel Okta). Im Idealfall könnte ich meinen verschlüsselten Passworttresor auch frei ins Internet stellen und niemand könnte mit einem vernünftigen Ressourceneinsatz meine Passworte daraus extrahieren, so dass ich mir selbst im Fall eines erfolgreichen Angriffs auf meinen Dienstleister keine (großen) Sorgen machen muss

‚Das letzte Passwort, das Sie jemals brauchen werden‘

Der Schutz des Passworttresors und seiner wichtigen Inhalte hängt nun von einer einzige Sache ab: Dem Passwort, welches man für den Passwortmanager verwendet. Dieses Passwort wird verwendet um den Tresor zu verschlüsseln und dann auch wieder zu ‚öffnen‘. Wer es besitzt hat damit die komplette Kontrolle über alle im Tresor gespeicherten Logindaten.

Im Idealfall ist es dann das ‚letzte‘ Passwort, welches man in dem Sinne braucht, dass man es sich merken und manuell eintragen muss. Produkte wie Lastpass oder 1Password verdanken dieser Idee ihre Namen. Oft wird dieses Passwort als das Masterpasswort bezeichnet

Da man dieses Passwort häufig benötigt um den Tresor zu entsperren ist es praktisch es sich merken zu können und so kann man ausgerechnet beim wichtigsten Passwort von allen kaum auf ein langes, zufällig generiertes Passwort setzen. Sondern muss sich für eine Vorgehensweise entscheiden um ein Passwort zu finden, welches auch in dem Fall, dass der damit verschlüsselte Tresor Angreifern in die Hände fällt, für eine ‚vernünftige‘ Zeit vermutlich nicht knackbar ist.

Die Ratschläge wechseln dabei mit der Zeit, die Vorgehensweise oben im Comic scheint heute immer noch aktuell, nur sind 4 Worte wohl nicht mehr genug. Hier ein paar Links dazu:

• Tipps vom BSI – Wobei die Aussage, dass ein ‚gutes Passwort‘ mehr als 8 Zeichen haben sollte, für ein Masterpasswort viel zu schwach ist. Hier sollte man schon etwas jenseits von 15 Zeichen haben, besser noch mehr
• Bitwardens Passwortstärkeprüfung: Diese Seite gibt einem ein Feedback dazu, wie sicher ein Passwort vermutlich ist. Hier kann man ein Gefühl dafür bekommen, wie Länge und verwendete Zeichenarten die Komplexität beeinflussen, und die steht wiederum im direkten Verhältnis zum Aufwand, den potentielle Angreifer zum Erraten betreiben müssen
• Password Haystack von GRC: Diese etwas nerdige Seite von Steve Gibson (vom Security Now Podcast) kann einem ebenfalls ein Gefühl dafür geben, wie komplex ein Passwort ist und wie sich die Länge und weitere Zeichenklassen (Groß- und Kleinschreibung, Zahlen, …) auf die Anzahl der Passwortkombinationen auswirken, die ein Angreifer durchtesten müsste. Das ist kein völlig korrektes Maß für die sogenannte Entropie eines Passworts und die Zeiten, die dort prognostiziert werden um ein Passwort zu brechen, sind nicht mehr realistisch angesichts heute verfügbarer Hardware. Trotzdem vermittelt es einem ein Bild davon, wie sich Komplexität erzeugen lässt. So ist ein Passwort, in dem man irgendwo zehn ‚.‘ oder ähnliches eingefügt hat und welches dadurch auf eine enorme Länge kommt durchaus für Angreifer, die davon nichts ahnen, sehr schwer zu erraten
• Have i been pwnd: Hier kann man prüfen, ob ein Passwort schon einmal in gehackten Konten vorkam. So ein Passwort sollte man in keinem Fall mehr verwenden

Generelle Hinweise:

• Das Masterpasswort sollte keins sein, welches man vorher schon irgendwo verwendet hat. Und man sollte es dann auch für keinen anderen Zweck verwenden
• Es gibt keinen Grund das Passwort regelmäßig zu ändern, es sei denn man möchte es noch länger / komplexer machen
• Das Masterpasswort sollte man sich ggf. aufschreiben und an einem sicheren Ort verwahren. Gerade ein kompliziertes Passwort vergisst man nach einem langen Urlaub auch schon mal
• Man sollte das Masterpasswort nur auf Geräten eintragen, die vertrauenswürdig sind. Vertrauenswürdig ist zum Beispiel sicher nicht ein Internetcafé am Urlaubsort, aber ggf. auch keine Geräte von Bekannten oder Freunden. Es ist für Besitzer*innen fremder Geräte einfach zu leicht eine Tastatureingabe mitzuschneiden und so an das Passwort zu kommen

Das Versagen von Lastpass

Ich habe mich vor Jahren für Lastpass als meinen cloud-basierten Passwortmanager entschieden und eine der kostenpflichtigen Optionen gewählt. Auf dieses Produkt bin ich denke ich durch den Security Now Podcast aufmerksam geworden, der ursprüngliche Entwickler von Lastpass hat sein Produkt damals für Steve Gibson geöffnet und dieser hat einen Review des Konzepts gemacht, welches zu dieser Zeit State of the art war. In den folgenden Jahren wurde Lastpass aufgekauft und der ursprüngliche Entwickler hat das Unternehmen schon lange verlassen. Aber aus Nutzersicht war und ist es ein Produkt, welches seine Aufgabe im Webbrowser und auf Android und iOS problemlos erledigt.

Auf Grund der Zero Knowledge Architektur war dann auch die Meldung von Lastpass Anfang Dezember 2022 (inzwischen aktualisiert) über einen Sicherheitsvorfall, bei dem die verschlüsselten Passworttresore gestohlen wurden, zunächst ärgerlich, aber noch nicht sehr besorgniserregend:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data. 

Quelle Lastpass Blog

Natürlich ist der Verlust der Informationen dazu, welche Webseiten ich nutze, schon ein durchaus heftiges Datenschutzproblem und eine ideale Grundlage für Phishingangriffe. Trotzdem war der Stand zunächst der, dass durch die Art und Weise, wie aus dem Masterpasswort die Verschlüsselung generiert wird, die wirklich wichtigen Daten geschützt sind. Der Blogeintrag bestärkt diesen Eindruck noch:

To further increase the security of your master password, LastPass utilizes a stronger-than-typical implementation of 100,100 iterations of the Password-Based Key Derivation Function (PBKDF2), a password-strengthening algorithm that makes it difficult to guess your master password. You can check the current number of PBKDF2 iterations for your LastPass account here. 

Quelle Lastpass Blog

Nun kommen aber die Erkenntnisse ins Spiel, die im Verlauf dieser Security Now Episoden stückweise ans Tageslicht kamen:

• Shownotes Security Now 904 – Leaving Lastpass
• Shownotes Security Now 905 – 1

Das sind für mich insbesondere diese Punkte:

1. PBKDF2 Iterationen: 5000! Der Schutz meiner von Lastpass gestohlenen Daten hängt nur daran, dass Angreifer mein Masterpasswort nicht knacken. Mein Passwort ist deutlich länger als die von Lastpass zu diesem Zeitpunkt empfohlenen 12 Zeichen. Aber Lastpass selbst kann die Sicherheit sehr einfach durch die Anzahl der Iterationen erhöhen, die beim PBKDF2 Verfahren verwendet werden. Und hier ist es eine schlichte Lüge, dass hier mehr als 100.000 Iterationen verwendet werden. Bei mir waren nur 5.000 eingestellt, da ich ein langjähriger Nutzer bin und offenbar noch die Einstellung habe, die bei meiner ersten Nutzung von Lastpass aktuell war. In der 905er Episode behandelt Steve Fälle, bei denen es gar nur 1 Iteration war! Wieso hat Lastpass uns bisher treue Altnutzer nicht automatisch umgestellt? Als ich das manuell gemacht habe musste ich mich einmal neu einloggen und ein paar Sekunden warten, dann war das erledigt. Das hätte Lastpass in den letzten Jahren einfach mal automatisch tun können
2. ECB verschlüsselte Passworte: In alten Versionen von Lastpass wurden Passworte nach dem ECB Verfahren verschlüsselt. Auch wenn das eine sichere Verschüsselung ist hat sie den Nachteil, dass die gleiche Eingabe immer das gleiche Ergebnis erzeugt. Es ist also in den verschlüsselten Daten einfach erkennbar, wenn jemand ein Passwort mehrfach verwendet hat. Später hat Lastpass auf das CBC Verfahren umgestellt, welches dieses Problem nicht hat. Es aber auch hier versäumt die Altdaten komplett umzustellen. In dem Lastpass Extrakt, den man sich nach dem in Folge 904 vorgestellten Verfahren herausziehen kann, finde ich zahlreiche ECB-kodierte Passworte
3. Kein Zwang zu guten Masterpassworten: Das Problem betrifft mich nicht, aber offenbar hat Lastpass nie seine eigene Vorgabe durchgesetzt mindestens 12 Zeichen lange Passworte zu verwenden. Sie haben ihre Nutzer*innen damit in unverantwortlicher Weise sich selbst überlassen
4. Herunterspielen der Menge an unverschlüsselten Daten: Es scheint, also enthalte der gestohlene Datensatz eine Menge an unverschlüsselten Informationen, die Lastpass für den Betrieb seiner Services nicht benötigt. Diese Daten sind nun direkt für die Angreifer auswertbar und helfen ihnen mindestens bei der Priorisierung welche Passworte sie ggf. zuerst angreifen sollen
5. Mangelhafte Kommunikation: Insgesamt macht es den Eindruck, dass es Lastpass eher darum geht den Vorfall herunterzuspielen und eventuelle Datenverluste den Kunden in die Schuhe zu schieben. Auch wenn sie es in der Hand gehabt hätten hier viel für die Sicherheit zu tun

Letztlich hat mich die Menge der Probleme und der unprofessionelle Umgang damit dazu veranlasst ähnlich wie Steve Gibson nun Abschied von Lastpass zu nehmen.

Bitwarden als neue Lösung

Trotz der Erfahrung, dass meine Passwortmanagerdaten einmal in der Cloud abhanden gekommen sind, bleibe ich beim Grundprinzip eines cloud-basierten Passwortmanagers. Alles andere ist einfach zu umständlich. Zum Glück gibt es einige Alternativen, die in Episode 904 auch kurz diskutiert werden. Von den da genannten Kandidaten Dashlane, 1Passwort und Bitwarden habe ich mich für letzteren entschieden.

Ein Grund ist, dass es sich hier um eine Open Source Lösung handelt, die aber zugleich ein Serviceangebot hat, welches man kaufen kann. So hat man zwar die Option eines selbstverantwortlichen Betriebs, aber wenn man das nicht kann oder möchte nutzt man den Service in der Cloud.

Kann man sicher sein, dass Bitwarden keine ähnlichen Probleme hat oder bekommt wie Lastpass? Letztlich nicht wirklich, allein das es sich hier um Open Source handelt ist keine Garantie dafür, dass komplexe Algorithmen korrekt implementiert sind, keine sonstigen Fehler in der Software sind und das der Betrieb der Cloudplattform kompetent erfolgt. Aber zumindest könnte man in einem vergleichbaren Fall einfach nachsehen wie die Software funktioniert, und müsste nicht herumraten, wie es bei Lastpass nun der Fall ist.

Die Migration an sich hat bei mir gut funktioniert, man nutzt entsprechend der Anleitung den Export von Lastpass und holt diese Daten dann nach Bitwarden.

Nach dem ersten Eindruck ist die Oberfläche etwas weniger gefällig, als die von Lastpass, aber nicht in einem für mich abschreckenden Maß. Etwas Feintuning kann man dann noch machen und die Anzahl der Iterationen für die Schlüsselableitung (KDF) erhöhen. Sie liegt per Voreinstellung bei 100.000, also auf dem Level, welches Lasspass bei neuen Nutzer*innen setzt. Aber man kann sie hochsetzen, und heutige Smartphones verkraften auch deutlich höhere Werte:

Zur Erinnerung: Die Anzahl der Iterationen erhöht direkt den Aufwand, den Angreifer in einem Szenario wie dem Datendiebstahl bei Lastpass erbringen müssen und hier hat man neben der Komplexität des Masterpassworts noch eine weitere Stellschraube. Der Wert von mehr als einer Million scheint auf meinem Geräten keine Schwierigkeiten zu bereiten, auch auf dem alten iPad Mini als wohl leistungsschwächsten Gerät dauert das Öffnen des Tresors nur eine Sekunde.

Ich habe meinen Lastpass Account noch nicht gekündigt und werde noch ein paar Wochen beobachten, wie sich Bitwarden schlägt, aber Passwortänderungen werden nun nur noch über den neuen Passwortmanager gemacht.

Umgang mit den bisher bei Lastpass gespeicherten Passworten

Ich muss davon ausgehen, dass mein kompletter Passworttresor heute in den Händen von Kriminellen ist. Zusammen mit den Tresoren von Millionen von anderen Lastpass Nutzer*innen. Trotz der oben benannten kritischen Punkte bei der Verschlüsselung gehe ich nicht davon aus, dass meine Daten schon geknackt wurden. Aus diesen Gründen:

1. Ich stelle vermutlich kein speziell interessantes Ziel dar, welches besondere Aufmerksamkeit und umfangreiche Investitionen an Rechenzeit rechtfertigt
2. Bei einer opportunistischen Vorgehensweise der Angreifer – leichte Ziele vor schweren Zielen angehen – sind die Nutzer*innen, die eine noch kleinere Anzahl von PKDF-Iterationen hatten (vielleicht nur eine einzige!) wohl eher ‚dran‘ als ich. Allerdings gibt es keine vollständige Information darüber, in welchem Maße die schwachen Iterationszahlen vorhanden sind, wann ich nach dieser Logik als ‚dran‘ wäre
3. Mein Masterpasswort war nicht schwach und erfüllte die oben von mir selbst aufgestellten Massgaben
4. Ich habe bisher keine ungewöhnlichen Aktivitäten bei meinen diversen Konten bemerkt

Trotzdem…es wäre absurd zu glauben, dass nicht irgendwann die Daten meines Tresors zugänglich werden, sei es in ein paar Wochen, Monaten oder Jahren, die Logindaten müssen also geändert werden. Allerdings habe ich hunderte von Logins in meinem Tresor, es ist daher eine Priorisierung notwendig. Das ist meine Reihenfolge:

Priorität 1: Zentrale Mail- und Betriebssystemkonten

An wichtigsten sind die Google Konten. Nicht nur enthalten sie selbst jede Menge wichtige Daten, sie sind auch bei vielen Services als Adressen eingetragen für Passwortresets. Wer diese Konten kapert, der kann sich dann auch ohne gestohlenen Passworttresor den Zugriff auf viele Konten sichern.

In gewisser Weise gilt das auch für die Konten bei Microsoft und Apple, die den Zugriff auf die Betriebssysteme dieser Anbieter ermöglichen und ebenfalls zentrale Angriffspunkte sind.

Priorität 2: Finanzen und große Einkaufsplattformen

Danach kommen direkt die Konten bei Banken und Onlinefinanzdienstleistern. Ein Zugriff darauf kann unmittelbaren finanziellen Schaden erzeugen, auch wenn hier heute immer ein weiterer Faktor wie eine dynamische TAN benötigt wird. Auch Plattformen wie Amazon gehören für mich dazu, da hier ebenfalls das Potential zu wesentlichen finanziellen Schäden besteht.

Priorität 3: Eigene Webseiten und Social Media

Eine Übernahme meiner digitalen Identität im Netz würde über Jahre aufgebaute Repräsentationen zerstören und hat das Potential auch andere zu schädigen, falls Angreifer versuchen sollten sich auf diese Weise Vertrauen zu erschleichen.

Priorität 4: Der große Rest

Danach bleiben immer noch eine Menge von Konten, für die eine Lösung gefunden werden muss. Bei vielen wird sich eher die Frage stellen ob man sie nicht komplett aufgibt, statt das Passwort zu ändern. Denn jeder Service, der Daten von einem verwaltet, ist letztlich ein potentielles Angriffsziel, über das Daten abfließen können.

Beschäftigt man sich regelmäßig mit IT Sicherheitsthemen – etwa in dem man jede Woche den Security Now Podcast hört – gibt es immer wieder Momente in denen man völlig davon überzeugt ist, dass das Internet nur von Kaugummi und Klebeband zusammengehalten wird. Aber oft sind es auch Themen, die tief in die unheimlich komplex gewordenen Infrastukturen und Technologien führen, mit denen wir täglich hantieren. Das sind zwei Beispiele aus den letzten Wochen, die ich besonders spannend fand:

Trojan Source – UTF-8 und Tricks mit dem bidi Encoding 🔀

Aus Security Now 843: Zwei britische Forscher haben ein spannendes Paper mit dem Titel ‚Trojan Source: Invisible Vulnerabilities‚ veröffentlicht, welches im Endeffekt diese Kernaussage hat:

Bei der Prüfung eines Programmcodes kann man nicht mehr davon ausgehen, dass der Code, den man vor sich auf dem Bildschirm sieht, der gleiche Code ist, der später vom Compiler ‚gesehen‘ und in ein Programm übersetzt wird

So wie das Trojanische Pferd auch nicht das war, was es zu sein schien…Wenn man darüber einen Moment nachdenkt zieht es einem nach und nach das Fundament unter dem Füßen weg, auf dem die Überprüfung von Softwarequalität und -sicherheit von jeher stand:

Ein Mensch schaut sich in einem Editor den Quellcode, den ein anderer Mensch – oder inzwischen auch eine Maschine – geschrieben hat, versucht ihn zu verstehen und vergleicht ihn mit der Funktion, die der Code laut Pflichtenheft oder Eigenbeschreibung oder Stack Overflow Kommentar haben soll.

Im Paper werden nun unterschiedliche Verfahren beschrieben, wie man in Quellcode, der als Unicode gespeichert ist, subtile Täuschungen einschmuggeln kann. Und dabei kommt die Komplexität moderner Zeichensatzcodierungen, die den Anspruch haben letztlich jedes relevante Schriftsystem der Welt – und möglicherweise auch extraterrestrische – korrekt darstellen zu können, uns die Quere:

Neben vergleichsweise simplen Ticks wie dem Einfügen von breitenlosen und damit unsichtbaren Leerzeichen (Zero Width Space ZWSP), die Stringvergleiche scheitern lassen können, oder der Verwendung von Homoglyphen, die etwa zur Einführung alternativer Methodenaufrufe genutzt werden können, sind es die Nutzungen der Bidirectional Commands und davon gibt es einen ganzen Block:

Die lassen sich sogar verschachteln und ähnlich wie bei einem Stack in der Programmierung gibt es POP Anweisungen um Verschachtelungen wieder zu beenden und damit eine Schachtelungsebene nach oben zu gehen:

Gerade mit dem Isolates, die komplette Gruppen von Zeichen als gemeinsames Element behandeln, und Kombinationen von BiDi Anweisungen lassen sich leicht Fälle konstruieren, bei denen etwas, dass im Quellcodeeditor so aussieht:

...
/* Wenn Sicherheitsprüfung bestanden, dann return; */
if (check == true) 
     return;
else 
     throw new Exception("Keine Berechtigung!");

für den Compiler hingegen so erscheint:

...
/* Wenn Sicherheitsprüfung bestanden, dann */ return;
if (check == true) 
     return;
else 
     throw new Exception("Keine Berechtigung!");

Hier wird also aus dem scheinbaren Kommentar am Ende eine Programmanweisung, die die Logik komplett aushebelt. Das solche subtilen Änderungen manchmal weitreichende Probleme verursachen, dafür ist der goto fail;-Bug ein gutes Beispiel, den Apple vor Jahren in seinem Betriebssystem hatte. Hier sah der fehlerhafte Abschnitt so aus:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
	goto fail;
	goto fail;

Richtig wäre aber diese Variante gewesen:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
	goto fail;
goto fail;

Die dritte Zeile durfte also nicht eingerückt sein. Manchmal reicht schon ein TAB um den Unterschied zu machen und in diesem Fall gab es Vermutungen, dass vielleicht jemand dafür bezahlt worden sein könnte diesen subtilen Fehler an einer entscheidenden Stelle einzubauen. Das Risiko der Entdeckung wäre gering gewesen und man hätte sich leicht damit herausreden können, dass es sich um einen Tippfehler gehandelt hat. Mit Hilfe der BiDi-Trickserei wäre dieser Fehler nicht einmal bei einem sehr sorgfältigen Code Review sichtbar gewesen.

Da die Forscher bereits reale Beispiele für die Anwendung dieser Technik gefunden haben ist das keine rein theoretische Bedrohung. Da sich solcher Code sogar per Copy-and-Paste übernehmen lässt sind beliebte Vorgehensweisen in der modernen Softwareentwicklung ebenfalls gefährdet. Also noch mehr gefährdet, als sie es immer schon waren 🙈

Was kann man tun?

Grundsätzlich wird man wohl abwarten müssen bis die Werkzeuge wie Editoren, Compilier und vielleicht auch Linter sich dieses Problems annehmen. Bis dahin gibt es vielleicht diese Faustformeln:

• Gerade in den Quellcode eingebrachte Texte wie Kommentare und Strings sind Einstiegspunkte für diese Art von Angriff
• Die Auswirkung der bidi-Tricksereien enden beim nächsten Zeilenumbruch. Eine einheitliche Quellcodeformatierung, die z. B. eingebettete Kommentare nicht in der gleichen Zeile stehen lässt wie Code, kann ein paar Varianten vermutlich aushebeln
• Bei der Nutzung von fremden Programmcodes muss man noch stärker als bisher schon auf deren Qualität achten. Was immer schon notwendig, und immer schon schwierig war

HTTP Request Smuggeling 🧱⛏️

Aus Security Now 846: Auch dieses Problem wird durch Komplexität verursacht, aber auf einer ganz anderen Ebene: Hier geht es darum, dass zwei oder mehr hintereinander geschaltete Webserver, die am Bedienen eines Webrequests beteiligt sind, das dabei verwendete HTTP Protokoll nicht einheitlich interpretieren.

Und im Endeffekt unterschiedliche Vorstellungen davon haben, welche Webrequests sie eigentlich gerade verarbeiten.

Dieses Problem ist kein ganz neues Problem, aber heute noch relevanter, da es inzwischen gängige Praxis ist, dass mehr als ein Server am Ausliefern einer Seite beteiligt ist:

• Proxy Server werden vor den eigentlichen Applikationsserver geschaltet, um die Last zu verringern
• Webserver wie Apache oder nginx liegen vor den Applikationsservern um TLS zu terminieren oder Loginfunktionen – z. B. Shibboleth – zu übernehmen
• Loadbalancer sind Netzwerkkomponenten, die die Zugriffe auf nachgelagerte Server verteilen, um Lasten gleichmäßig verarbeitbar zu machen
• Dienste wie Cloudflare bieten ihren Kunden durch vorschaltete Systeme Schutz vor Denial of Service Angriffen, die eigentlichen Server sind nicht mehr direkt erreichbar
• Und alle denkbaren Kombinationen davon….

Für die effiziente Kommunikation zwischen diesen Servern werden verschiedene Webrequests gerne hintereinander gehängt, damit sie sich schnell über die gleiche Verbindung übertragen lassen.

Aber wie schafft man es dem einen Server etwas anderes vorzugaukeln, als dem später drankommenden Server? In dem man die zwei Optionen, die der HTTP Standard als Mittel bietet um die Länge eines Request zu definieren – und damit bei hintereinander gehängten Requests zu definieren, wo der eine aufhört und der andere beginnt – so trickreich nutzt, dass die beteiligten Server zu unterschiedlichen Ansichten darüber gelangen, wo die Grenze zwischen zwei Requests liegt. Auch wenn es laut dem Standard eigentlich klar wäre, wie vorzugehen ist:

“According to the HTTP/1.1 standards, if both Content-Length and Transfer-Encoding headers are passed, Transfer-Encoding takes precedence.”

Quelle auf Medium

Auf diese Weise kann es bei anfälligen Serverkombinationen – und laut diesem Paper sind das viele – gelingen einen Zugriff auf einen Backend Server abzusetzen, der eigentlich von den davor geschalteten Servern gefiltert werden sollte. Das kann insbesondere dann relevant sein, wenn die vorgeschalteten Server das Login- und Rechtemanagement übernehmen.

Auch hier ist es nicht leicht etwas zu tun. Wie immer muss man natürlich seine Server aktuell halten, so gibt es z. B. für Tomcat inzwischen einen Patch für CVE-2021-33037, der auch mit HTTP Request Smuggeling zu tun hat. Aber auf das Verhalten vieler Komponenten, wie z. B. Loadbalancer, hat man wenig bis keinen Zugriff.

Eine Lösung ist es vielleicht die kritischen Entscheidungen einer Applikation – also die Rechte- und Zugriffskontrolle – möglichst weit nach hinten zu verlagern, bis in die Applikationsserver. Das nimmt einem Optimierungsmöglichkeiten, aber dafür ist der Server, der am Ende die Requests verarbeitet, auch derjenige, der entscheidet welche Requests zulässig sind.