datenritter blog

Am 10. Oktober konnte man im SC Magazine lesen, dass WPA angeblich nicht mehr sicher sei. Eine russische Firma würde die enorme Rechenleistung von nVidia-Grafikkarten-Prozessoren nutzen, um das Knacken von Passwörtern um 10.000% zu beschleunigen.

Es handelt sich übrigens um die Firma Elcomsoft, spezialisiert auf "Passwort-Rettung".

Das hat wiederum eine andere Firma, GSS, dazu veranlasst, WiFi generell für unsicher zu erklären und VPNs anzupreisen. Kristian Köhntopp fragte sich indes, wie denn die VPNs mit den gleichen Verfahren wie bei WPA sicherer sein sollen.

Bei Slashdot hat man am 12. Oktober richtig gerechnet: Eine Beschleunigung um 10.000% bedeutet ungefähr* Faktor 100. Nicht mehr. Und das bei einer Brute-Force-Attacke. Die ist bei schwachen Passwörtern schon immer erfolgversprechend gewesen, sonst eher nicht.

Das ganze ist also nichts, was man durch mehr konventionelle Rechenleistung, z.B. einen kleinen Cluster nicht auch erreichen könnte. Bruce Schneier schreibt dazu dann auch gewohnt deutlich:

Yes, weak passwords are weak -- we already know that. And strong WPA passwords are still strong. This seems like yet another blatant attempt to grab some press attention with a half-baked cryptanalytic result.

Thema durch.


(* Da bin ich pingelig: Beschleunigung um 10.000%, also um die 100fache Leistung, bedeutet auf das 101fache. Beschleunigung auf 10.000% wäre hingegen auf das 100fache. Ich gehe davon aus, dass auch im Englischen so unterschieden wird.)

Das Problem mit den ePässen ist offenbar, dass die Terminals selbstsignierte Daten akzeptieren. (Siehe auch: heise-Meldung.) Das lässt sich leicht ändern, in dem man Signaturen zwingend verlangt.

Doch der Beitrag über den schon erwähnten Hack des elektronischen Personalausweises, erklärt sehr prägnant, warum die Zertifikatsautoritäten einer Publik-Key-Infrastruktur (PKI) selbst ein ernsthaftes Problem sein können. Die Kritik lässt sich auf andere Einsatzfelder der PKI anwenden, zum Beispiel bei SSL-geschützten Webseiten:

Using a Certification Authority (CA) could solve the attack but at the same time
introduces a new set of attack vectors:

1. The CA becomes a single point of failure. It becomes the juicy/high-value target for the attacker.
Single point of failures are not good. Attractive targets are not good.

Das ist die wichtigste Erkenntnis: Die Zertifikatsautorität (CA) ist der "single point of failure" und ein hochwertiges Ziel für einen Angreifer.

Any person with access to the CA key can undetectably fake passports. Direct attacks, virus,
misplacing the key by accident (the UK government is good at this!) or bribery are just a few
ways of getting the CA key.

Ich übersetze mal sinngemäß: Wer auch immer Zugang zum Schlüssel einer CA hat kann unbemerkt Ausweise fälschen. Durch direkte Angriffe, Viren, irrtümliche Preisgabe des Schlüssels oder Bestechung könnte man an den Schlüssel gelangen. Dass gelegentlich USB-Sticks, Festplatten, ja sogar Kameras mit geheimen Daten in Umlauf gelangen, dürfte bekannt sein.

Nun folgen ein Punkt, der zu Diskussionen führt und nicht oberflächlich betrachtet werden darf:

2. The single CA would need to be trusted by all governments. This is not practical as this
means that passports would no longer be a national matter.

Dass es keine multinationale CA geben kann, ist offensichtlich, doch:

3. Multiple CA's would not work either. Any country could use its own CA to create a valid
passport of any other country. (...)

Diese Behauptung ist die am häufigsten kritisierte und gilt vermutlich nur für schlecht aufgesetzte ePass-Terminals. Selbst wenn alle Terminals derart nachlässig sind, wird man dies bald ändern. Doch gilt sie uneingeschränkt für SSL-Zertifikate, z.b. für Webseiten, denn ein Browser kann nicht wissen, welche CAs für meine Bank zuständig sein sollen und welche nicht.

Und für den ePass gilt:

This option also multiplies the number of 'juicy' targets. It makes it also more likely for a CA key to leak.
Revocation lists for certificates only work when a leak/loss is detected. In most cases it will not be detected.

Denn es kommt bei einer Fälschung vielleicht nicht unbedingt darauf an, aus welchem Land der falsche Pass stammt.

Sicher ist:
• Die Pässe sind beschreibbar. Man kann also die Daten einer anderen (z.B. ähnlich aussehenden) Person auf den eigenen Chip schreiben — inklusive der gültigen Signatur.
• Angriffe auf CAs sind außergewöhnlich lohnend.
• Viele CAs sind viele Angriffsmöglichkeiten. Zu viele.
• Rückruflisten helfen nur, wenn die Fälschung überhaupt bemerkt wird. Das ist sehr unwahrscheinlich.

Ich empfehle als Notbehelf für den ePass die Mikrowelle. Sie verhindert wenigstens, dass ein Dritter die eigenen Daten ausliest und verwendet. Für Webseiten gibt es auch weiterhin keine einfache Lösung, außer der händischen Prüfung des Fingerprints.

Die Hacker-Gruppe THC (The Hacker's Choice) zeigt wie man biometrische Reisepässe mit RFID-Chip, die ePässe, klonen und verändern kann.

Auch Deutschland hat ePässe eingeführt.

ePassport emulator:

This emulator applet allows you to create a backup of your own passport chip(s).

Damit sind die Dinger aus sicherheitstechnischer Sicht praktisch wertlos geworden. Möglicherweise sind sie sogar ein größeres Risiko als die alten Pässe.

Das es GPS-Simulatoren geben muss, die plausible aber beliebige GPS-Signale erzeugen, ist logisch, denn ein GPS-Simulator wird für die Entwicklung von GPS-Empfängern und GPS-basierten Geräten dringend benötigt. Ohne ihn gäbe es nur eine Art, ein Gerät, dass zum Beispiel einen Sturz von einer Autobahnbrücke verhindern soll, zu testen: Durch waghalsiges Ausprobieren. Auch Flugbenzin und Raketentreibstoff dürften durch das Kästchen tonnenweise eingespart werden. Doch die Möglichkeit zur Simulation macht das System, das mehr oder weniger ohne Berücksichtigung von Sicherheitsaspekten entwickelt wurde, verwundbar... "wie man Drohnen vom Himmel holt - oder die ... »

Wie schon erwähnt bietet der Hack des Blood&Honour-Netzwerks durch die "Datenantifa" Stoff für Diskussionen.

Chris von FIXMBR erklärt direkt mal, warum ihm das ganze Bauchschmerzen bereitet:

Hat irgendwer an die Kollateralschäden gedacht? An den kleinen Jungen vom Dorf, der irgendwann einmal auf dem Schulhof die URL bekommen hat, sich registriert, die Seite aber schnell wieder verlassen hat. (...) Und wenn man zufällig den gleichen Namen hat, den gleichen Nick nutzt, wie ein Mitglied dort - Pech gehabt. Die sogenannten Linken feiern einen großen Schlag gegen die Rechtsextremisten - Kollateralschäden inbegriffen. (...) Und morgen demonstrieren wir dann wieder gegen die Vorratsdatenspeicherung, die Datenweitergabe an die USA, gegen den Datenmissbrauch, gegen alles - so, als wenn nichts gewesen wäre. ;-)

In der Tat war "Selbstjustiz" auch eines der ersten Stichworte, die mir in den Sinn kamen, und dass der Zweck nicht die Mittel heiligt. Chris hat recht: Auch wenn man einem üblen Burschen auf die Schliche kommen will, muss man selbst dabei sauber bleiben und die eigenen Werte leben. Die Hackerethik des CCC bietet da ein paar nette Ansatzpunkte.

Gestern noch schrieb ich über den Lausebengel, der die Webseite der fränkischen Stadt Ansbach gelöscht hatte. Die Empörung über den jugendlichen Datenvandalen dürfte zumindest vor Ort groß sein.

Heute nun kassieren die politisch motivierten Hacktivisten der "Datenantifa" Sympathiepunkte für einen digitalen Einbruch, bei dem nichts gelöscht, wohl aber einiges "gestohlen" wurde.

Laut einer AFP-Meldung haben Mitglieder der "Datenantifa" Rechner des Neonazi-Netzwerks "Blood & Honour" gehackt und dabei "mehr als 30.000 Datensätze" kopiert. (Wie wohl so ein "Datensatz" aussehen mag?)

AFP schreibt:

Unter den Datensätzen waren demnach auch rund 500 aus Deutschland. Seit September 2000 ist "Blood and Honour" (B&H) hierzulande als verfassungsfeindliche Gruppierung verboten.

Und NDR Info berichtet, dass durch die geklauten Daten wahrscheinlich auch die rege Nutzung des Netzwerkes in Deutschland belegt sei. Verbindungen der NPD zu B&H werden erwartet. Den Verfassungsschutz, dem die Daten jetzt übergeben werden sollen, dürfte das alles sehr interessieren.

Viele sind der Meinung, dass dieser nicht selbst im staatlichen Auftrag Computersysteme angreifen sollte, der Streit ist bekannt. Die "Datenantifa" zeigt wie verlockend der Gedanke ist, kriminelle Organisationen durch digitalen Einbruch zu enttarnen. Doch strenggenommen ist auch dieser nach deutschem Recht illegal, ob er nun Neonazis trifft oder nicht. Folgerichtig müsste man die Aktivisten der "Datenantifa" als Cracker bezeichnen und nach § 202a StGB und § 202c StGB (dem heftig kritisierten Hackerparagraphen) strafrechtlich verfolgen. Heiligt der Zweck die Mittel?

Die meisten dürften an dieser Tat nichts auszusetzen haben. Andere werden sagen, dass ihnen jede noch so obskure Organisation, egal welchen politischen Spektrums, lieber ist als verbeamtete Cracker in staatlichem Auftrag. Wieder andere werden sagen, dass man Hacktivismus nicht mit Scriptkiddies vergleichen kann.

So oder so: Viel Stoff für Diskussionen.

Fefe erwähnt einen Beitrag in der WAZ, laut dem ein Jugendlicher Cracker die Webseite der fränkischen Stadt Ansbach manipuliert hat. Die WAZ schreibt:

Ein Fachmann hatte daraufhin festgestellt, dass die Seiten größtenteils vom Server gelöscht worden waren.

Für diese lapidare Feststellung braucht es offenbar auch 2008 noch einen "Fachmann". Hätte dieser Fachmann der Stadt Ansbach mal ein Backup empfohlen, dann wäre das ganze nicht so grenzenlos peinlich für die Stadt.

Felix hat vollkommen recht mit seiner Kritik daran, dass der Lausebengel laut WAZ für die Neugestaltung der Webseite aufkommen soll. Denn hier geht es nicht um die Begleichung eines durch eine Missetat entstandenen Schadens, sondern darum, dass die Stadt Ansbach grob fahrlässig die Sicherung ihrer Daten vernachlässigt hat. Damit hat sie den größten Teil des Schadens nämlich selbst verursacht.

Man vergleiche das ganze zur Verdeutlichung mit einem maroden Staudamm, der durch den Steinwurf eines Kindes zusammenbricht und ein Dorf wegspült. Dann das Kind als schwerkriminell hinzustellen, weil ja schließlich Menschen gestorben seien, wäre schon arg mittelalterlich.

Kurz: Man muss zwischen Verursacher und Auslöser unterscheiden. Ich hoffe mal, die Juristen bekommen das hin.

Die Angriffsmöglichkeit durch alte Zertifikate hat sich bestätigt. Laut einem Artikel bei heise Security bestehen zudem die Möglichkeit, dass die Systeme, die mit schwachen Schlüsseln ausgestattet waren, bereits früher angegriffen bzw. belauscht wurden.

Es ist schon übel, dass der heise-Newsticker vorgestern nur am Rande in WWW, der "Wochenschau von Hal Faber" über die bestehende Angriffsmöglichkeit durch das OpenSSL-Debakel berichtete:

Es gibt Leute, die viel davon verstehen und die erklären können, wie selbst unsere Selbsteintreibungs-Software ELSTER davon betroffen ist, dass Revocation Lists für Zertifikate nicht funktionieren: Skalierender Schlüsselrückruf ist ein ungelöstes Problem.

Die von mir hervorgehobene Formulierung suggeriert, dass das schon das Ende der Gefahrenstange sei. Das ist nicht der Fall, es kann auch Online-Banking-Webseiten oder andere sensible Bereiche treffen. Nach einem Hinweis antwortete mir Jürgen Kuri, er werde die Leute bei heise Security noch einmal darauf hinweisen.

Heute erschien dann die Meldung "Tausende deutsche Server laden zum Einbruch ein". Dort wird berichtet, dass viele ihre SSH-Schlüssel noch nicht ausgetauscht haben, Provider ihre Kunden nicht benachrichtigen:

Kurze Stichproben von heise Security enthüllten Erschreckendes: In den Netzen von Root-Server-Providern verwendeten von 1938 erreichbaren SSH-Servern 114 bekanntermaßen schwache Schlüssel – das sind immerhin rund fünf Prozent.

Das ist schlimm, aber wartet, es kommt schlimmer.

Man hat sich bei heise Security auch die Mühe gemacht, einen interessanten Artikel über die verschiedenen Gefahren zu schreiben — leider steht zu befürchten, dass den schon aufgrund der Länge kaum jemand liest. Das ist schade, denn auf Seite drei steht der erschreckende Sachverhalt, vor dem ich warnte, in einem Absatz zusammengefasst:

Insbesondere für Phishing und Pharming sind Originalzertifikate eines Webservers zusammen mit den passenden privaten Schlüsseln Gold wert. Gelänge es einem Phisher, seine Opfer beispielsweise mittels des sogenannten Pharmings seine Opfern per DNS-Spoofing oder untergeschobene Hosts-Einträge auf seine eigene Seite umzudirigieren, so könnte der Anwender den Angriff nicht mehr erkennen. Sein Browser würde anzeigen, dass das Sicherheitszertifikat des Servers zur eingegebenen URI passt und dass es von einer vertrauenswürdigen CA ausgestellt wurde.

Und tatsächlich: Alexander Klink berichtet auf der Mailingliste full disclosure, er habe eine Bank ausgemacht, deren altes Zertifikat schwach war. Das Zertifikat ist noch etwa 3 Jahre gültig - so lange sind Man-In-The-Middle-Attacken auf diese Bank möglich.

Als wäre das nicht genug, erklärt der Artikel auch noch, dass aufgezeichnete verschlüsselte Verbindungen nun nachträglich entschlüsselt werden könnten. Es ist durchaus davon auszugehen, dass immer dann, wenn sensible Daten abgegriffen werden sollten, auch verschlüsselte Verbindungen auf Vorrat aufgezeichnet wurden, gerade im Bereich Industriespionage dürfte das üblich sein.

Doch der wahre Schrecken lauert auf Seite fünf:

Wer immer sich in den vergangenen 20 Monaten die Mühe gemacht hat, eine Datenbank mit (...) öffentlichen Schlüsseln zu pflegen, konnte vermutlich ungefähr ab Oktober 2006 die erstaunliche Beobachtung machen, dass in dieser Datenbank Kollisionen auftreten, wo eigentlich keine passieren dürften. Aufgrund des Geburtstagsparadoxons genügen schon 500 schwache Schlüssel gleicher Länge, um unter ihnen mit rund 95-prozentiger Wahrscheinlichkeit ein Duplikat zu finden. Vom Entdecken eines solchen Duplikats ist es nur noch ein kleiner Schritt, um über den ungefähren Zeitpunkt und den Kontext der betroffenen Schlüssel auf das Debian-Betriebssystem zurückzuschließen und die in dem Zeitraum vorgenommenen Änderungen am Quellcode der kryptographisch relevanten Programmpakete zu untersuchen.

Das ist DESASTRÖS. Denn es ist mehr als wahrscheinlich, dass Kriminelle, Geheimdienste, vielleicht auch andere Organisationen Schlüssel gesammelt und das Problem bereits vor langer Zeit bemerkt und für Einbrüche und Lauschaktionen genutzt haben.

Felix von Leitner schreibt in seinem Blog über eine wirklich gefährliche Angriffsmöglichkeit, die sich aus dem OpenSSL-Debakel ergibt. Alle Verbindungen zu Servern, die ein "schlechtes" SSL-Zertifikat hatten, sind wahrscheinlich immer noch verwundbar. Felix berichtet, dass dies bei einem Server von Akamai der Fall ist, und über Akamai werden Daten für das Steuerprogramm ELSTER übermittelt.

Wie es funktioniert

Die Angreiferin, nennen wir sie Carol, ruft Daten von einer Webseite ab, deren URL mit https beginnt, also über eine SSL-verschlüsselte Verbindung — z.B. beim Online-Banking. Sie erhält dabei das Zertifikat der Webservers, welches sie speichert. Dieses Zertifikat und der geheime Schlüssel dazu sind nun aber mit der kaputten Version von OpenSSL erzeugt worden.

Mit dem Zertifikat und dem enthaltenen öffentlichen Schlüssel alleine kann Carol nichts anfangen, es ist ganz normal, dass man diese übermittelt bekommt. Wichtig ist allerdings, dass das Zertifikat von einer Zertifikatsautorität (CA) signiert wurde, wodurch die Echtheit sozusagen "offiziell" beglaubigt ist.

Der geheime Schlüssel ist außerdem dank des OpenSSL-Fehlers leicht ermittelbar — Carol erzeugt alle möglichen geheimen Schlüssel einfach selbst und prüft, welcher zu dem öffentlichen Schlüssel des Servers passt.

Nun hat Carol also sowohl den geheimen Schlüssel, den eigentlich nur der Server kennen sollte, als auch ein "von offizieller Stelle" signiertes Zertifikat.

Die Zertifikate der "offiziellen Stellen", also der CAs sind in jedem Webrowser vorinstalliert, das heißt jeder Webbrowser erkennt auch das Zertifikat ohne weitere Prüfung oder Abfrage als gültig an, obwohl es unsicher ist:



Natürlich haben die Betreiber die verwundbaren Zertifikate schon ausgetauscht. Aber Carol war schnell, und hat das alte vorher gespeichert, gleich nachdem der OpenSSL-Fehler bekannt wurde. (Zukünftig wird Carol dies automatisieren, ein kleines Programm speichert die Zertifikate während sie im Web surft. Denn vielleicht gibt es nochmal so einen Fehler.)

Zwar überprüft ein Browser das Ablaufdatum, welches unveränderlich im Zertifikat steht und dieses nach einer bestimmten Zeit automatisch ungültig macht, aber das ist schlichtweg noch nicht erreicht.

Dagegen gibt es natürlich auch einen Schutzmechanismus, nämlich zentrale Stellen, die Listen mit vorzeitig für ungültig erklärten Zertifikaten enthalten, sogenannte CRLs (Certificate Revocation Lists). Doch diese Listen muss der Browser auch abrufen.

Tut er aber nicht:



Die Standard-Einstellung des Browsers Firefox ist, keine CRLs abzurufen. Das dürfte bei vielen Programmen so sein, und auch E-Mail-Programme, Homebanking-Programme und Programme zur Übermittlung der Steuererklärung benutzen SSL.

Schaltet man die Prüfung ein, so funktioniert sie möglicherweise nicht, was die Funktion einfach nur lästig macht:



Mit dem privaten Schlüssel und dem signierten Zertifikat kann Carol nun dem Browser irgendeines Users glaubhaft vormachen, ihr eigener (manipulierter) Server sei der Server, dessen Zertifikat sie "übernommen" hat. Sie kann sich also als Mittelsmannfrau in die vermeintlich geschützte Verbindung einklinken, und somit Daten mitlesen, unterdrücken oder gar verändern, also zum Beispiel Schadcode, etwa einen Trojaner, einschleusen.

Man nennt dies eine Man-In-The-Middle-Attacke, kurz MITM. (Oder WITM. Wegen der Gleichberechtigung.)

Der Haken beim PKI-Verfahren

Wie Felix ganz richtig schreibt, ist das ganze Prinzip der PKI, der Echtheitsprüfung durch irgendwelche Zentralstellen, die der User gar nicht kennt, ihnen also auch nicht vertrauen kann, schon allein durch die Zahl der standardmäßig installierten CA-Zertifikate der eigenartigsten CAs höchst zweifelhaft.

Es ist keine Diskriminierung, sondern reine Vernunft, wenn ich sage, dass ich eigentlich nicht möchte, dass die mir völlig unbekannte Stelle "TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş" (Türkei) oder die"NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado" (Ungarn) Zertifikate für gültig erklärt, mit denen mein Browser verschlüsselte, also vermeintlich sichere Verbindungen aufbaut.

Ich muss überhaupt nicht an Geheimdienste denken, ganz normale Kriminelle werden schon ihre Wege finden, die ein oder andere CA für ihre Zwecke zu missbrauchen.

Was tun?

Das einzige, was Server-Betreiber gegen diesen Angriff tun können, ist das alte Zertifikat dadurch unbrauchbar zu machen, dass sie ihre Domain ändern, bis die alten Zertifikate abgelaufen sind. Dumme Sache.

Benutzer müssen bei vielen Webseiten, die keine "offiziell beglaubigten" Zertifikate haben, ohnehin selbst entscheiden, ob sie das Server-Zertifikat

• nur temporär akzeptieren (es könnte gefälscht sein)
• dauerhaft akzeptieren (sie kommunizieren zumindest immer mit dem selben Server und halten es für unwahrscheinlich, dass Carol dahinter steckt) oder
• verifizieren.

Um diese Entscheidung immer selbst zu fällen, können sie alle CAs, denen sie nicht vertrauen — das werden wohl nahezu alle sein — in den Einstellungen ihrer Software deaktivieren.

Wenn es wichtig ist, und sie das Zertifikat verifizieren müssen, — die Fingerprints überprüfen, in dem sie den Betreiber anrufen.

Bei so etwas wichtigem wie dem Online-Banking oder der Steuerrerklärung z.B. sollte man das unbedingt tun!

Banken und Behörden werden sich natürlich wundern, aber es ist deren Schuld, schließlich schicken die den Kunden zwar stapelweise Papier mit PINs, TANs und iTANs, aber die Fingerprints ihrer Banking-Webseiten und Steuerdatenserver fehlen in den Unterlagen.

Diesen Cartoon, und eine Verarbeitung dieses Dilbert-Comics im gleichen Stil findet man zur Zeit fast überall im Netz. Und Lolcats gibt es natürlich auch.

Ein schlimmer Bug hat die Linux-Welt erschüttert. SSH-, OpenVPN- und andere X509-Schlüssel sind vorhersehbar, die Sicherheit dahin. Feiste Windows-User kringeln sich in ihren nassgeschwitzen T-Shirts vor Lachen, blöd grinsende Microsoft-Jünger zeigen mit nackten Wurstfingern auf eigentlich besser ausgestattete Betriebssysteme, spießige Neuinstallierer fühlen sich in ihrer oberflächlichen Halbmeinung dass "Sicherheitslücken ja überall drin sind", bestätigt.

Ich denke, der Spott ist unberechtigt. Ebenso wie das peinlich berührte Schweigen der Geeks und das leise Wimmern der Blogs. "OpenSSL-Debakel zeigt: Linux ... »