LdN 211 - Geheimdienste sollen Trojaner bekommen - Technischer Hintergrund

Moin,

in der aktuellen (LdN211) Folge haben Philip und Ulf zum Schluss über die Geheimdienste und aktuelle Trojaner geredet.

Gibt es dazu mehr Quellen die das ganze von einer mehr technischen Seite analysieren/betrachten? Mich würde insb. der Part interessieren, wie der Traffic über die ISB an die Geheimdienste umgeleitet werden sollen. Ich konnte hierzu leider keine eigenen Quellen finden.

VG

In dem Gesetzentwurf steht zur Technik überhaupt nichts. Das ist auch Absicht, weil Gesetze normalerweise möglichst Technik-neutral formuliert werden, damit man sie nicht anpassen muss, wenn es technische Fortschritte gibt.

Näherungsweise kann man sich das so vorstellen, dass der gesamte Traffic für bestimmte Kunden über einen Proxy des Geheimdienstes geleitet wird. So gut wie alle Daten werden einfach durchgeleitet, aber sobald im Datenstrom eine ausführbaren Datei auftaucht, wird die mit einem Trojaner verseucht und erst dann weitergeleitet.

1 Like

Ich war für die Berichterstattung etwas verwundert. Ihr (Ulf) habt das Thema TLS eigentlich vorbildlich erklärt. Allerdings ist die Schlussfolgerung meiner Meinung nach falsch:
Beispiel Firefox- oder Windows-Update: natürlich bauen diese Programme nur eine Verbindung zum Update-Service auf, wenn der Server sich mit einem für seine Domain gültigen Zertifikat „ausweisen“ kann. Vermutlich wird es sogar noch Fingerprint Prüfungen der Intermediate Zertifikate geben. Zum Schluss sind sicher auch Windows-Updates beispielsweise zusätzlich signiert.
Würde der Geheimdienst also die Verbindung (wie richtig erklärt mit eigenem Zertifikat) aufbrechen, würde der Download gar nicht gestartet. Alles andere wäre selbst verständlich eine massive Sicherheitslücke.

Anders sieht es vielleicht beim normalen Aufruf von Webseiten aus. Hier bekommt der User eine Warnung angezeigt, die er je nach Browser einfach (oben eben recht aufwendig, bei z.B. Safari mit TouchID) ignorieren muss. Gerade hier werden die Browser auch immer strikter, sodass der „normale“ User tendenziell eher die Seite nicht aufruft.
Aber hier besteht natürlich eine Gefahr bzw. Möglichkeit für Geheimdienste.
Verschlimmert wird das Ganze natürlich dadurch, dass viele gerade im Unternehmensumfeld darauf „trainiert“ werden diese Hinweise auf (internen) Seiten einfach zu ignorieren.

Wir haben uns natürlich ein plastisches Beispiel gesucht. Es mag sein, dass FF sinnvolle Sicherheitsmaßnahmen ergreift, beispielsweise Certificate Pinning. Aber meine eigenen Versuche mit dem Charles Proxy

weisen darauf hin, dass jedenfalls die allermeisten Apps kein ordentliches Pinning einsetzen und jedes Cert schlucken, das vom System als gültig akzeptiert wird.

Wenn man das selbst testen will „hackt“ man natürlich sein Gerät mit einem Root-Cert. Aber man kann wohl getrost davon ausgehen, dass ein Geheimdienst auch Zugriff auf eine normale Root-CA hat, deren Certs vom OS by default akzeptiert werden. Wenn nicht die Telekom mitspielt, dann findet sich garantiert ein befreundeter Dienst, der das gerne übernimmt.

2 Like

Um an dieser Stelle nochmal nachzubohren:
Das heißt, @vieuxrenard du gehst davon aus, dass Geheimdienste auch heute schon die Möglichkeit haben, gefälschte Zertifikate durch Root-CAs signieren zu lassen?
Das gab es zwar schon, zum Beispiel 2011, als die damalige niederländische CA DigiNotar ein gefälschtes Wildcard-Zertifikat für google.com ausgestellt hatte und dieses für MITM-Attacken im Iran verwendet wurden. Auch andere Fälle sind bekannt, bei denen CAs schlicht selbst gehackt wurden, um falsche Zertifikate zu signieren.

Allerdings gibt es genau wegen solcher Fälle mittlerweile eine – aus meiner Sicht – halbwegs wirkungsvolle Maßnahme gegen fälschlicherweise ausgestellte Zertifikate: Certificate Transparency.
Laurie et al. schlugen dafür ein öffentliches, kryptographisch signiertes append-only Log basierend auf einem Merkle-Tree vor, in das jedes neu ausgestellte Zertifikat eingetragen wird. Jedes Zertifikat kann dann darauf hin überprüft werden, ob es im Log vorkommt.

Dadurch sollte es auch Geheimdiensten recht schwer fallen, gültige Zertifikate, zum Beispiel für mozilla.org, zu nutzen.

1 Like

Faktisch haben die Geheimdienste ja schon jetzt legal die Möglichkeit, 20% des deutschen Traffics passiv zu analysieren. Wie wir durch die Selector-Affäre vor einigen Jahren mitbekommen haben, wurden die deutschen Geheimdienste hier ja auch zu Erfüllungsgehilfen für die CIA und NSA und haben effektiv Wirtschaftsspionage betrieben.

Sobald aber aktiv in den Verkehr eingegriffen werden darf, gehen die Möglichkeiten massiv hoch. Downgrade-Attacken können beispielsweise die TLS-Verbindungen von neuen, sicheren Versionen auf ältere, unsichere Versionen runterbrechen. Hat man in Firefox oder Chrome nicht das https-only-Plugin aktiviert, versuchen alle heutigen Browser auch im Zweifel eine unverschlüsselte HTTP-Verbindung (falls nicht explizit verschlüsseltes HTTPS angefordert wird). HSTS - was dem Browser signalisiert, dass nur verschlüsselte HTTPS-Verbindungen gemacht werden sollen - funktioniert erst nach dem ersten Aufruf einer Seite und nicht bei noch nie besuchten Seiten. Zuletzt ist der Browser selbst ja neben Dutzenden weiteren Programmen installiert, wovon die meisten automatische Updater installiert haben, wovon im Zweifel dann mindestens eins unsicher implementiert sind.

Wer mehr über die Schwierigkeiten von sicheren Updates lernen will, kann mal mit dem BDF-Proxy rumspielen[1] oder sich die dort verlinkten Vorträge anschauen - der BDFProxy macht genau das, was die Geheimdienste auch wollen: er baut dynamisch in den Traffic Malware in ausführbare Downloads (wie Softwareupdates) ein.

[1] https://github.com/secretsquirrel/BDFProxy

Danke für die Hintergründe. Das kann man nur hoffen … aber ob die Prüfung wirklich immer zuverlässig ist? Es genügt ja eine schlecht programmierte Routine in einem Autoupdater, und schon kommen die Schlapphüte ins System.

Eben: Snowden hat mit der Prism-Veröffentlichung ja gezeigt, welche Unternehmen beteiligt waren. Wenn man sich dann noch so so schräge Vögel wie Adobe ansieht (von denen fast jeder Windows-Nutzer etwas auf dem Rechner hat), und dass Oracle eine CIA-Ausgründung sein soll (MySQL, VirtualBox …) dann kommen die Backdoors doch hoch-offiziell ins Haus geflogen.

Um sich der Integrität von Paketen bzw. Updates sicher zu sein, muss man sich schon komplette Repositories von Linux-Distributionen lokal spiegeln - und auf unabhängigem Weg die Integrität der Prüfsummen checken.

Will heißen: Man muss sowohl so gefährdet, so geschult und so sensibel sein, wie Edward Snowden sein, um die Integrität seiner IT sicher zu stellen. Widerspricht das nicht dem Urteil des BVerfG, nach dem wir unserer IT grundsätzlich vertrauen können müssen?!

Mir scheint, dass die digitale Souveränität des Bürgers, die als Gedanke hinter dem Urteil des BVerfG von 2008 steht,

  • eine andere digitale Souveränität ist, als die, die Verwaltungen und Behörden gerade für sich entdecken.
  • Die digitale Souveränität der Verwaltungen und Behörden unterscheidet sich dann auch von der, die die Unternehmen für sich beanspruchen.
  • Und Last but not least hat sicher auch der/die GesetzgeberIn eine Idee, was er/sie für sich unter digitaler Souveränität versteht - z.B. wenn er/sie Gesetze über die Integrität der IT erstellt.

Ich glaube, es ist an der Zeit zwischen diesen vier Parteien zu klären, wer denn nun wirklich das Privileg erhalten soll, seiner/ihrer IT wirklich vertrauen zu dürfen - und wer sich damit abzufinden hat, dass seine IT eben von Geheimdiensten kompromittiert und ggf. auch sabotiert werden kann/darf …

My 2 ct