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.
