Was nun folgt mag für die meisten eher sehr theoretisch klingen und man braucht vielleicht auch etwas Phantasie, um sich mögliche Einsatzzwecke für diesen Bug einfallen zu lassen, aber es gibt ihn und er zeigt exemplarisch, um wie viele Ecken man denken muss, wenn es um Sicherheit und Privatsphäre im Netz geht.
Entdecker Pascal Landau beschreibt das von ihm entdeckte Problem in einer Kurzfassung so:
Durch die Implementierung eines veralteten Protokollstandards der Content Security Policy in Google Chrome können die öffentlichen Profildaten von Facebook Nutzern ohne deren zutun ermittelt werden. Der Angriff ist speziell für vorab definierte, zu überwachende Personengruppen geeignet.
Ein paar Erläuterungen: Content Security Policy (CSP) sollen verhindern, dass Schadcode in eine Website eingebunden wird. Eine Website legt also vorab fest, von welchen Adressen Ressourcen nachgeladen werden dürfen und von welchen nicht und der Browser hält sich daran. Versucht nun ein Skript auf einer so geschützten Website – zum Beispiel ein von einem Angreifer eingeschleustes JavaScript – Ressourcen von einer Website nachzuladen, die nicht erlaubt ist, dann bekommt das Skript eine Fehlermeldung. Ist praktisch, erhöht die Sicherheit etwas und ist an sich total super, wenn Pascal eben nicht einen Weg gefunden hätte, dieses Verfahren in Chrome zu nutzen, um Besucher einer Website zu deanonymisieren. Man muss aber einschränken, dass das nur gelingt, wenn man zuvor eine Gruppe von Facebook-Nutzern definiert hat und der Besucher aus eben dieser Gruppe stammt. Wer es selbst probieren möchte: Den Proof of Concept gibt es dazu auch.
Wie arbeitet das Skript nun? Vereinfacht gesagt – eine ausführliche Beschreibung gibt es natürlich auch – nutzt das Skript die Tatsache, dass Facebook die Adresse Facebook.com/me immer auf das Profil des gerade eingeloggten Nutzers weiterleitet oder auf die Login-Seite. Wenn ein Angreifer nun eine bestimmte Zahl an vorausgewählten Profilen hat, für die er sich interessiert, dann kann das Skript die CSP jeweils anpassen, so dass ein Zugriff per JavaScript – im Browser und mit der Identität des Nutzers – auf die Login-Seite von Facebook verboten, auf das gesuchte Profil aber erlaubt wird. Kommt beim Versuch auf Facebook.com/me zuzugreifen dann ein Fehler vom Browser, so ist klar, dass User und Vergleichsprofil nicht zusammen gehören, kommt kein Fehler, dann ist der Nutzer identifiziert.
Jetzt höre ich schon die Einwände: „Ja Moment mal, das funktioniert ja nur dann, wenn der Nutzer bei Facebook angemeldet ist und auch nur, wenn der zufällig in der Gruppe der User ist, die ich vorher für den Abgleich ausgewählt hatte. Das ist doch sehr theoretisch…“ Stimmt natürlich, aber zum einen gibt es recht simple Methoden, die Zahl der notwendigen Anfragen deutlich zu verringern, so reichen für den Vergleich mit 100.000 Profilen 21 Anfragen an Facebook. Pascal hat das ausführlich erklärt. Natürlich reicht das immer noch nicht, um jeden Zugriff auf eine Website mit 1 Milliarde Facebook-Profilen abzugleichen, da alleine das nötige Skript gigantisch groß würde – die ganzen Namen der Vergleichsprofile müssen ja in das JavaScript gesteckt und zum Nutzer übertragen werden. Und dann ist da noch die Einschränkung, dass diese Methode nur in Chrome funktioniert. Stimmt alles, aber es ist trotzdem durchaus interessant und relevant.
Es handelt sich bei einem Angriff dieser Art nicht um ein Tool zur Massenüberwachung, aber zum Beispiel eine gute Möglichkeit für gezielte Beobachtung von Personen. Geheimdienste haben ja schon einige Male andere Websites gekapert. Es wäre also durchaus denkbar, dass sie bei der Gelegenheit so ein Skript – und vielleicht weitere für andere Browser – in so eine Website einbauen, um zu prüfen, ob bestimmte vorher festgelegte Verdächtige diese besuchen. Und wann. Und wie lange. Und welche Seiten des Angebots sie aufrufen. Gut möglich, dass diese Methode bereits im Werkzeugkasten der NSA schlummert oder auch eingesetzt wurde.
Im Gegensatz zu Xing – bei denen der Angriff auch möglich war – sehen Google und Facebook das Problem als nicht so gravierend an und haben erstmal nichts geändert, diese Attacke zu unterbinden. Isoliert für diesen Fall kann man das durchaus so sehen, der Aufwand ist nicht gerade klein und man kann nur Nutzer enttarnen, die zu einem vorab festgelegten Pool gehören. Aber interessant ist diese Methode alleine schon wegen der vielen Ecken, um die es gedacht ist. Ein prima Beispiel dafür, wie die immer komplexeren Zusammenhänge und Wechselwirkungen zwischen Systemen es unmöglich machen, bei der Entwicklung eines neuen Stücks Software wirklich jede Lücke zu bedenken, die im Zusammenspiel mit anderen Werkzeugen oder Websites auftreten könnte. Und auf der anderen Seite finde ich die Kreativität und Phantasie, mit der manche Menschen solche Lücken dann aufspüren einfach beneidenswert. Ganz unabhängig davon, wie groß oder lein so eine Lücke ist oder wie sie der Entdecker am Ende nutzt, das ist dann wieder eine andere Frage.
Übrigens: Das wäre mal wieder ein guter Grund, sich bei Facebook und anderen Diensten auszuloggen, wenn man sie gerade nicht aktiv nutzt. Wenn es halt nicht so verdammt komfortabel wäre, einfach immer eingeloggt zu bleiben… Aber die neue CSP-Version soll diese mögliche Lücke ja verhindern, bis jetzt ist die aber in Chrome noch nicht implementiert.
