Wie das BSI unsere Daten „schützt“. Ein Rant über die Schwachstelle im GSTOOL.

TL;DR: Das BSI gibt ein Tool heraus, welches sensible Daten über die IT-Sicherheit von deutschen Firmen vor ausländischen Industriespionen schützen soll. Die Verschlüsselung ist derartiger Murks, dass sie als Spielzeug für Hacker verwendet wird. Sie lässt sich innerhalb von Sekunden bis Minuten knacken. Das BSI reagiert auf Sicherheitsforschung mit juristischen Drohungen – was dazu geführt hat, dass das BSI erst Jahre nach der ersten Entdeckung des Problems davon erfahren hat. Ein Sicherheitsupdate ließ über eineinhalb Jahre auf sich warten, und die Sicherheitswarnungen haben nicht alle Kunden erreicht. Es entsteht leicht der Eindruck, dass das BSI vor allem daran interessiert war, dass die peinlichen Fehler nicht allzu öffentlich werden.

Eigentlich wollte ich ja nur wissen, ob Chiasmus sicher ist. Die sagenumwobene, geheimgehaltene, nicht veröffentlichte¹⁾ Chiffre, die das BSI damals, in den dunklen Zeiten der Kryptographie, entwickelt hat. Es war damals eine durchaus nachvollziehbare Entscheidung, eine eigene Chiffre zu entwickeln. Der damalige weltweite Standard, DES, war auf Wunsch der NSA vermurkst und unsicher, AES noch nicht standardisiert – womöglich waren zu Beginn der Entwicklung Rijndael (das heutige AES) und Twofish noch gar nicht publiziert.²⁾

Die Chiffre ist in einem gleichnamigen Programm eingebaut, was man aber nur bekommt, wenn man ein öffentliches Interesse nachweisen kann. Das BSI hat auch ein Hilfsmittel für den IT-Grundschutz, das sogenannte GSTOOL, herausgegeben. Das GSTOOL (in der betroffenen Version) wurde nicht vom BSI programmiert, sondern von Steria-Mummert. Mit dem GSTOOL werden sensible Informationen über die Sicherheit von IT-Netzen verwaltet – insbesondere bei Firmen, die besonders schutzbedürftig sind, sowie bei Behörden. Deswegen bietet das GSTOOL auch eine Verschlüsselungsfunktion, welche ebenfalls auf der Chiasmus-Chiffre basiert. Diese Verschlüsselungsfunktion soll die Daten vor Kriminellen und vor ausländischen Geheimdiensten schützen. Daten, die zum Beispiel für Industriespione ein gefundenes Fressen wären.

Die Entdeckung

Vor knapp zwei Jahren. Wir sitzen zu dritt vor einem Computerbildschirm. Facepalmend. Auf dem Bildschirm ein Debugger, der die Schlüsselerzeugungsfunktion von GSTOOL zeigt. Verschlüsselungsschlüssel müssen zufällig und nicht vorhersagbar sein, denn sonst kann ein Angreifer sie erraten und dadurch die Nachricht entschlüsseln. Deswegen erzeugt man sie mit speziellen, sicheren (Pseudo-)Zufallsgeneratoren. Wenn man kompetent ist. Wenn nicht, googelt man „c++ zufallszahlen“, klickt das erste Ergebnis an und verwendet was man da sieht. Dummerweise sieht man da vermutlich etwas wie das hier – das Standardverfahren zum Erzeugen von Zufallszahlen. Und dummerweise sind die Zufallszahlen, die so erzeugt werden, vielleicht gut genug für die Würfel in einer digitalen Version von Mensch-Ärgere-Dich-Nicht, aber nicht für kryptographische Schlüssel. Das weiß eigentlich jeder, der auch nur ansatzweise Ahnung von Kryptographie hat. Die Entwickler des GSTOOL wussten es offensichtlich nicht. Und das BSI hat es in all den Jahren offensichtlich nicht für nötig gehalten, die Verschlüsselungsfunktion zu überprüfen, denn dann wäre zumindest eines der Probleme aufgefallen. Denn die Schlüsselerzeugung war zwar das schlimmste, aber nicht das einzige Problem. (Die Details gibts im Advisory)

Einige Zeit und einige hundert Zeilen Code später haben wir eine Software, welche mit dem GSTOOL Chiasmus-verschlüsselte Dateien entschlüsseln kann – ohne Schlüssel, in der Regel innerhalb von Sekunden. In einer Mail an das BSI bitten wir um eine verschlüsselte Testdatei – und senden sie postwendend zurück. Entschlüsselt.

Bitte keine Ergebnisse

In einigen Tagen gelangweiltem Stochern haben wir die Verschlüsselung komplett zerlegt. Totalschaden. Weniger als 2^32 effektive Schlüssellänge – das ist ein Wert, bei dem man aufhört, den Angriff zu optimieren, weil es eh schon schnell genug geht. Und das war keine besonders anspruchsvolle Aufgabe, sondern eigentlich nur Fleißarbeit. Wir haben die Software fertig analysiert, dem BSI und Steria-Mummert Ratschläge zur Behebung des Problems gegeben, und schließlich auch ein Paper mit den Analyseergebnissen geschickt, in welchem auch die Chiffre selbst beschrieben war.

Als Antwort auf das Paper erhielten wir unmissverständliche und sehr deutliche juristische Drohungen, dass das Reverse Engineering einen Urheberrechtsverstoß darstelle und von den Juristen des BSI „sehr strikt verfolgt“ würde. Daher wurden wir „dringend gebeten“ das Paper nicht zu veröffentlichen. Um dem BSI Zeit zur Fehlerbehebung zu geben und unnötige Konfrontationen zu vermeiden, haben wir eine zeitnah geplante Veröffentlichung verschoben (was im Nachhinein gesehen angesichts der langen Dauer bis zum Patch IMHO ein Fehler war). Erst als deutlich wurde, dass wir uns nicht einschüchtern lassen und das Paper definitiv irgendwann veröffentlichen werden, wurden die Drohungen telefonisch entschärft.

„Lösung“

Am 25.11.2011, über eine Woche nachdem das BSI vom Problem erfahren hat, wurde eine öffentliche Sicherheitswarnung herausgegeben; ein Sicherheitsupdate sollte in Kürze folgen. Aus „in Kürze“ wurden eineinhalb Jahre. Eineinhalb Jahre, in der eine hochkritische Sicherheitslücke in einer Verschlüsselungssoftware offen blieb. Die Sicherheitswarnung ist inzwischen auf keiner offiziellen Seite mehr aufzufinden, und hat nicht alle Kunden erreicht – in einem persönlichen Gespräch Ende 2012 war ein Nutzer über die Information überrascht und hat gesagt, dass die GSTOOL-Verschlüsselung immer noch regelmäßig benutzt werde. Das Sicherheitsupdate wurde ebenfalls kaum angekündigt, auch wir erfuhren davon nur durch Zufall, als wir auf der BSI-Website nachgeschaut haben.

Klar ist so eine dämliche Sicherheitslücke peinlich. Aber ich werde den Verdacht nicht los, dass das BSI mehr darauf bedacht war, negative Öffentlichkeit zu vermeiden, als für Sicherheit zu sorgen. Das führt dann eben dazu, dass es auch Nutzer nicht mitbekommen und so der wertlosen Verschlüsselung weiter vertrauen.

Das „Sicherheitsupdate“ bestand am Ende übrigens daraus, die Verschlüsselungs-Schaltfläche zu deaktivieren. Ohne einen Hinweis im Programm, warum das der Fall ist. Nur wer in die Update-Notizen schaut oder eine Sicherheitswarnung des BSI erhalten hat, erfährt, dass die Verschlüsselung geknackt ist.

Spielzeug

Das offensichtliche Problem, dass die GSTOOL-Verschlüsselung den unsicheren Modus ECB benutzt, war bereits Christian Gresser vom Blog „Mitternachtshacking“ aufgefallen. Und zwar 2008. Durch Zufall erfuhren wir später, dass wir auch nicht die ersten waren, die die defekte Schlüsselerzeugung gefunden haben. 2009 fragte Felix Schuster beim BSI an, ob sie daran interessiert wären, wenn er das Tool analysiert, und bekam rechtliche Drohungen als Antwort.  Er fand trotzdem die gleichen Ergebnisse wie wir, teilte sie dem BSI aber aus offensichtlichen Gründen nicht mit.

Später verwendete er ein GSTOOL-Chiffrat als Aufgabe in einem CTF-Contest – einem Wettbewerb, wo Sicherheitsexperten/Hacker in einem simulierten Netzwerk versuchen, ihre Systeme zu schützen und in die der Mitspieler einzudringen, und nebenbei noch kleine Aufgaben lösen. Die „hochsichere“ Verschlüsselung dieses von offizieller Stelle herausgegebenen Tools war also so schlecht und leicht knackbar, dass sie als Spielzeug für Hacker, eine kleine Aufgabe für zwischendurch, verwendet wurde. Immerhin gab es für die „Borg-Bureaucrats“ stolze vierhundert Punkte. Die Aufgabe wurde erfolgreich gelöst und der glückliche Gewinner hat dem BSI wohl Bescheid gesagt – vermutlich in einem relativ engen zeitlichen Zusammenhang zu unserer Meldung. (Details dazu wissen wir leider nicht)

Das würde auch erklären, warum das BSI im Advisory unsere Namen nicht nennen wollte, wie es eigentlich üblich ist, wenn man einer Organisation schon kostenlos Sicherheitslücken meldet. Wer weiß, wie viele andere das Problem schon vorher entdeckt hatten. Felix hat über die Probleme vor Kurzem einen Vortrag gehalten und die Folien online gestellt. Diese enthalten auch eine Beschreibung des Algorithmus, falls sich jemand an einer Kryptoanalyse versuchen will.

We are not alone

Das Erschreckende an dieser ganzen Sache: Wenn wir auf die Idee gekommen sind, uns GSTOOL anzuschauen, und vor uns schon mehrere andere, dann haben ausländische Geheimdienste das sicher auch gemacht. Und die Probleme sind bei einer Analyse nicht zu übersehen. Normalerweise muss sich die NSA die Mühe machen, die Zufallsgeneratoren und andere Komponenten von Kryptosystemen mittels Hintertüren zu sabotieren, hier gabs ein von Haus aus kaputtes System gratis. Und um diese Lücke zu finden, braucht es keine NSA-Experten. Das hat der chinesische Geheimdienst und jeder andere Wirtschaftsspion sicher auch hinbekommen. Kein schöner Gedanke für deutsche Unternehmen, die sich auf die Sicherheit dieser von einer für die IT-Sicherheit zuständigen Behörde herausgegebenen Software verlassen haben.

Und statt zeitnah auf eine solche Lücke zu reagieren (oder von vorne herein dafür zu sorgen, dass so etwas gar nicht erst veröffentlicht wird), bedroht das BSI lieber Sicherheitsforscher, um zu verhindern, dass solche Probleme öffentlich werden. Ohne die Drohungen hätte das BSI wohl bereits 2009 von den Problemen erfahren.

Damit hat das BSI den letzten Funken Glaubwürdigkeit in der IT-Sicherheit verloren. Schade eigentlich, denn die Chiasmus-Chiffre an sich (die vom BSI selbst entwickelt wurde) sieht sicher aus, das BSI hat also durchaus kompetente Leute (oder hatte sie zumindest damals). Für die Sicherheitsprobleme sorgen erst die Implementierungsfehler von Steria-Mummert im GSTOOL (weswegen „Chiasmus für Windows“ auch nicht von der Lücke betroffen sein sollte).

Es war eine gute Idee, dass ich damals bei der AusweisApp direkt veröffentlicht habe, statt erst das BSI zu kontaktieren. Angesichts der Erfahrungen in diesem Fall werde ich jedenfalls in Zukunft nur noch „full disclosure“ fahren (d.h. gefundene Probleme sofort öffentlich machen), wenn ich irgendwelche Lücken in „offizieller“ Software finde. Alles andere sorgt nur für unnötig Stress, Verzögerungen und unter-den-Teppich-kehren.

Auch Kontakt mit dem BSI gehabt? Kunde/Nutzer von GSTOOL und Hinweise vom BSI bekommen (oder eben nicht)? Ich freue mich über Rückmeldungen über die Kommentarfunktion oder per E-Mail!

Fußnoten:

1) Eine Chiffre nicht zu veröffentlichen ist unüblich und gilt als verpönt – eine gute Chiffre ist auch dann sicher, wenn der Angreifer sie kennt, solange er den Schlüssel nicht hat. Vor den wirklich „Bösen“ kann man die Chiffre nicht langfristig geheimhalten, aber wenn die Chiffre nicht öffentlich ist, bleiben Schwächen oft lange für die Nutzer der Chiffre verborgen.

2) AES und Twofish wurden 1998 publiziert. Die erste Referenz zu Chiasmus, die wir finden konnten, erwähnt Chiasmus für Windows in Version 1.3 und ist aus dem Dezember 2001.

Advisory: Unsichere Verschlüsselung bei GSTOOL

=== Betroffene Produkte ===
Betroffen ist die Verschlüsselungsfunktion des GSTOOL in den Versionen 3.0 bis 4.7 (einschließlich) sowie die mit diesen Versionen erstellten Schlüssel und damit verschlüsselte Dateien. Die Version 4.8 (auch bekannt als GSTOOL 4.5, 4.6 oder 4.7 Service Pack 3) ist nicht betroffen, da in dieser Version die Verschlüsselungsfunktion entfernt wurde. Nicht betroffen ist die Kernfunktion des GSTOOL, das erstellen von Sicherheitskonzepten. Nur Anwender, die die Verschlüsselungsfunktion nutzen, sind betroffen.

Das GSTOOL unterstützt Anwender bei Erstellung, Verwaltung und Fortschreibung von Sicherheitskonzepten entsprechend dem IT-Grundschutz und wird vor allem von öffentlichen Stellen und Dienstleistern eingesetzt. Die Verschlüsselungsfunktion ist lediglich eine Zusatzfunktion, wird durch die entdeckten Sicherheitslücken aber weitgehend unwirksam: Angreifer können mit alten GSTOOL-Versionen verschlüsselte Dateien innerhalb weniger Minuten mit einem gewöhnlichen Computer ohne Kenntnis des Schlüssels entschlüsseln. Ursache ist die unsachgemäße Schlüsselerzeugung durch falsche Verwendung eines Zufallszahlengenerators. Diese Versionen 3.0-4.7 des GSTOOLs wurden von Steria Mummert Consulting im Auftrag und Namen des BSI entwickelt. <http://de.wikipedia.org/wiki/GSTOOL>

Nicht betroffen ist die Sicherheit der Blockchiffre „CHIASMUS“ an sich, da es sich um Implementierungsfehler in GSTOOL handelt. Das Produkt „CHIASMUS für Windows“ verwendet eine unabhängige Implementierung und wir vermuten, dass es nicht von dieser Schwachstelle betroffen ist

=== Problembeschreibung ===
Die kryptographischen Schlüssel werden mit einem ungeeigneten Verfahren erzeugt, wodurch die Stärke der Schlüssel auf maximal 31 Bit (in der Praxis meist deutlich weniger) beschränkt wird. Dadurch können die Schlüssel innerhalb von Minuten, meist aber in wenigen Sekunden, mittels eines angepassten Brute-Force-Angriffs bestimmt werden. Die mit den betroffenen Versionen von GSTOOL verschlüsselten Dateien können somit mit minimalem Aufwand auch ohne Kenntnis des Schlüssels entschlüsselt werden.

Weitere Probleme sind die Verwendung der Betriebsart ECB für die Blockchiffre sowie das Fehlen von Integritäts- und Plausibilitätsprüfungen für Dateien und Schlüssel.

=== Gegenmaßnamen ===
Die Verschlüsselungsfunktion enthält mehre Fehler, so dass das Problem nicht einfach zu beheben ist. Das BSI hat sich dafür entschlossen, die Funktion ganz aus GSTOOL zu entfernen. Wir halten das für eine sehr gute Entscheidung. Anwender sollten davon ausgehen, dass ihre Chiffrate kompromittiert sind, und sie so weit möglich dort löschen, wo Dritte potentiell Zugang zu den Chiffraten haben (Cloud-Anbieter, Dropbox, unverschlüsselte Laptop-Festplatten, Tablet und Smartphones).

Als Alternative bleibt für öffentliche Stellen der Einsatz von „CHIASMUS für Windows“. Die Software ist allerdings nicht öffentlich zugänglich und der Quellcode wurde nicht veröffentlicht, so dass wir die Sicherheit dieser Software nicht beurteilen können. Die Dateiformate sind ebenfalls nicht kompatibel.

Als beste Lösung sehen wir den Einsatz von Festplattenverschlüsselungssoftware (FDE) für Computer, auf denen mit GSTOOL gearbeitet wird, sowie den Einsatz von GnuPG/Gpg4win für das sichere Verschicken von GSTOOL-Datenbanken. Die Software ist kostenlos nutzbar, der Quelltext ist öffentlich einsehbar, und die Entwicklung wurde vom BSI gefördert. Das BSI selbst empfiehlt dieses Tool explizit: https://www.bsi.bund.de/DE/Themen/ProdukteTools/Gpg4win/gpg4win_node.html

=== Beteiligte ===
Jan Schejbal
Erik Tews
Julian Wälde

=== Ähnliche Forschung ===
Christian Gresser berichtete in seinem Blog „Mitternachtshacking“ bereits 2008 über die Verwendung der Betriebsart ECB: http://www.mitternachtshacking.de/blog/727-snake-oil-alarm-chiasmus-im-gstool

Wie uns nachträglich bekannt wurde, hat Felix Schuster (Ruhr-Uni­ver­si­tät Bo­chum) bereits im Jahr 2009 dieses Problem unabhängig von unserer Forschung entdeckt. Da das BSI nach einer anfängliche Kontaktaufnahme eine Analyse des GSTOOL durch ihn vehement ablehnte, wurde die Arbeit nicht veröffentlicht und das BSI nicht über die Ergebnisse informiert. Eine Präsentation seiner Ergebnisse kann seit Kurzem unter http://prezi.com/bzyvzzdsxtkm/ubicrypt-chm/ abgerufen werden.

GSTOOL-Chiasmus-Chiffrate wurden laut Felix Schuster beim Hack.lu CTF 2011 als eine der Aufgaben verwendet und von einem Teilnehmer erfolgreich geknackt, welcher vermutlich das BSI kontaktiert hat. Details sind uns leider nicht bekannt.

Sofern andere Forscher sich ebenfalls mit dem Thema beschäftigt und/oder das BSI kontaktiert haben, würden wir uns über eine Kontaktaufnahme freuen – Kontaktdaten siehe <http://www.janschejbal.de/impressum.shtml>.

=== Patch ===
Das BSI hat in einem Advisory am 25.11.2011 dazu geraten, die Verschlüsselungsfunktion nicht zu verwenden, alternative Verschlüsselungslösungen einzusetzen und evtl. öffentlich verfügbare verschlüsselte Dateien zurückzuziehen. Das Advisory ist inzwischen nur noch auf Drittseiten auffindbar, z. B. <http://goo.gl/lVoHL>, die Empfehlungen sind jedoch korrekt.

In der Version 4.8 (auch bekannt als „Servicepack 3 für GSTOOL 4.5“) wurde die Verschlüsselungsfunktion deaktiviert. <http://goo.gl/3Sjb5>

=== Timeline ===
Alle Ereignisse in chronologischer Reihenfolge (nicht der Reihenfolge in der sie uns bekannt wurden):

2008-09-24 Blog-Posting von Chrisitan Gresser, Hinweis darauf dass die Verschlüsselung von GSTOOL nicht vollständig sicher ist.
2009 Erste Arbeiten von Felix Schuster, Anfrage beim BSI ob eien Sicherheitsanalyse von GSTOOL erwünscht ist, Anfrage wurde abgelehnt.
2011-09-19 hack.lu CTF
2011 Erste Arbeiten von uns, Analyse. Dabei wurden die Schwachstellen der Implementierung entdeckt.
2011-11-14 Kontaktaufnahme mit dem BSI, Demonstration der Lücke
später exakte Fehlerbeschreibung (telefonisch)
2011-11-25 Advisory des Herstellers, Ankündigung Servicepack

Weitere Kommunikation und Ratschläge zur Fehlerbehebung

2011-12-06 Hinweis von Seiten des BSI, dass sie Reverse Engineering bei GSTOOL ihrer Meinung nach nicht erlaubt ist und Bitte, von der Veröffentlichung von Analyseergebnissen der Chiffre abzusehen.

2011-2013 Mehrfache Statusnachfragen unsererseits

2013-06-06 (ca.) Erscheinen des Servicepacks, keine Benachrichtigung.
2013-07-22 UbiCrypt Summerschool in Bochum mit Vortrag von Felix Schuster
2013-09-11 Veröffentlichung dieses Advisories

ePerso kann remote missbraucht werden

In meinem letzten Artikel zum ePerso (PIN-Diebstahl ohne Malware) stellte ich eine Möglichkeit vor, wie ein Angreifer an die PIN des ePerso gelangen kann, indem er eine falsche AusweisApp vortäuscht.

Wie ich erwartet hatte gab es daran viel Kritik: Einerseits sei das ja kein richtiger Angriff, weil „nur“ der Nutzer getäuscht wird, andererseits hätte der Angreifer ja „nur“ die PIN, mit der er nichts anfangen könne, weil er ja keinen Zugriff auf den Personalausweis selbst hätte.

Ersteres spielt für das Ergebnis keine Rolle: Der Angriff funktioniert gegen durchschnittliche Nutzer sehr gut, und der Angreifer hat am Ende die PIN. Damit wären wir beim zweiten Einwand: Die Authentifikation mit dem Ausweis ist eine sogenannte Zwei-Faktor-Authentifikation – man benötigt PIN und Ausweis. Mit der PIN alleine kann der Angreifer somit tatsächlich noch nicht direkt einen Angriff durchführen – aber er hat einen der beiden Faktoren überwunden. Das wird interessant, sobald ein Angriff den anderen Faktor überwindet. Alleine wäre auch dieser neue Angriff „wertlos“, verbunden mit der gestohlenen PIN ermöglicht er jedoch den Missbrauch des Ausweises.

Genau einen solchen zweiten Angriff habe ich nun gefunden. (Nachtrag: Wurde von Heise verifiziert.) Dadurch kann der Angreifer, wenn die im Folgenden erklärten Bedingungen zutreffen, sich mit dem Personalausweis des Opfers ausweisen. (Ich denke, jetzt sieht man auch, warum der PIN-Angriff sehr wohl ein Problem war!)

Weil das Missverständnis öfter aufkam: Der PIN-Diebstahl-Angriff ist kein simpler Phishing-Angriff. Bei einem Phishing-Angriff wird das Opfer auf die Seite des Angreifers gelockt, aber im Glauben gelassen, dass es z. B. die Seite seiner Bank besucht – denn nur dort dürfen die Bank-Zugangsdaten eingegeben werden. Auf den falschen Link reinzufallen ist ein vermeidbarer Fehler des Opfers. Hier jedoch kennt das Opfer die Identität der Seite. Ein legitimer Ausweisevorgang beginnt mit dem Besuch einer fremden Seite, wo dann die AusweisApp aufpoppt – genau wie beim Angriff. Dieser Angriff ist also deutlich schwerer erkennbar als Phishing – vor allem, weil Banken etc. dem Nutzer erklären, wie er sich schützen soll (Bank-Website manuell aufrufen), während auf die wenigen Warnzeichen für eine falsche AusweisApp nirgendwo hingewiesen wird.

Demo des Angriffs auf YouTube

Die von der ComputerBild als Beilage verteilten Starterkits bestehen aus einem Reiner SCT-Basislesegerät sowie einer LoginCard, mit der man sich Online einloggen können soll. Dazu muss eine Software (Browserplugin) von ReinerSCT installiert werden, die Websites Zugriff auf das Lesegerät gibt.

Über dieses sogenannte OWOK-Plugin kann eine Website (nach Bestätigung, siehe unten) frei mit der Karte kommunizieren. Die OWOK-Software habe ich als erstes untersucht, weil der Nutzer bei den Computerbild-Starterkits zur Installation aufgefordert wird, sie also bei vielen Ausweisinhabern vorhanden sein dürfte. Die Software nutzt dafür anscheinend das von den Sparkassen entwickelte SIZCHIP-Plugin – d.h. das gleiche Problem dürfte mit vielen anderen Plugins, z. B. mit dem Geldkarten-Plugin, bestehen.

Pro Website wird der Benutzer einmal gefragt, ob er diesen Zugriff zulassen soll. Diese Frage sollte eigentlich vor dem Angriff schützen, da der Nutzer ja darauf aufmerksam gemacht wird und zustimmen muss. Dabei gibt es jedoch mehrere Probleme:

1. Der Nutzer erwartet beim oben erwähnten PIN-Diebstahl-Angriff, dass der ePerso benutzt wird. Die Frage nach dem Zugriff auf dem Chipkartenleser dürfte den meisten Nutzern daher logisch vorkommen und meist bejaht werden. Nutzer mit gutem Hintergrundwissen über die Technik könnten an dieser Stelle aufmerksam werden – diese zählen jedoch zu einer kleinen Minderheit.
2. Sobald der Nutzer einmal die Entscheidung getroffen hat, scheint diese dauerhaft gespeichert zu werden. Indem der Angreifer das Plugin unter einem Vorwand einige Zeit vor dem Angriff das erste mal aktiviert, kann er verhindern, dass der Nutzer beim eigentlichen Angriff misstrauisch wird.
3. Die Anfrage besteht aus einem Dialogfenster, was an einer vorhersehbaren Position (Bildschirmmitte) auftaucht, sobald das Plugin geladen wird. Das kann sich der Angreifer zunutze machen, indem er den Nutzer animiert, wiederholt schnell auf die „richtige“ Stelle zu klicken (z. B. durch ein Spiel), und dann erst das Dialogfenster auslöst. Viele sicherheitskritische Dialogfenster in Browsern aktivieren die Schaltflächen inzwischen erst nach einer kurzen Verzögerung, um solche Angriffe zu verhindern.
4. Einige im Plugin vordefinierte Seiten können ohne diese Sicherheitsabfrage zugreifen. Gelingt es, in einer dieser Seiten z. B. eine XSS-Lücke zu finden, kann man die Sicherheitsabfrage umgehen, indem man den Angriff im Kontext der Seite durchführt. Eine solche Lücke habe ich gefunden – die Sicherheitsabfrage kann also umgangen werden.

Dieser Angriff setzt also voraus:

• Das Opfer hat z. B. das von der ComputerBild verteilte Starterset nach Anleitung installiert
• Das Opfer fällt auf den PIN-Diebstahl-Angriff mit einer falschen AusweisApp herein
• Das Opfer bestätigt dabei (oder irgendwann vorher!) die Sicherheitsabfrage „Darf von (Seitenname) auf Chipkartenleser zugegriffen werden?“ oder der Angreifer umgeht die Sicherheitsabfrage über eine XSS-Lücke (siehe oben)
• Der Ausweis liegt auf dem Lesegerät (folgt bereits aus dem Hereinfallen auf den PIN-Diebstahl-Angriff)

Sobald diese Voraussetzungen erfüllt sind, hat der Angreifer über das Plugin Zugriff auf den Kartenleser und den darauf liegenden Ausweis, und befindet sich im Besitz der PIN. Damit gilt:

• Der Angreifer kann mit der Identität des Ausweisinhabers Aktionen durchführen, und diese mit dem fremden Ausweis bestätigen.
• Der Angreifer kann sich auch in Benutzerkonten des Ausweisinhabers, die Login via Ausweis zulassen, einloggen, und dort z. B. Daten ausspähen oder weitere Aktionen durchführen.

Der Angreifer braucht also insbesondere weder Malware auf dem Rechner des Nutzers, noch muss er man-in-the-middle-Attacken fahren. Er muss lediglich Besucher auf seine Seite locken und dort mit der falschen AusweisApp täuschen!

Folgen

Der Angreifer kann den Ausweis und somit die bestätigte Identität des Opfers missbrauchen. Das Opfer bekommt dies nicht mit, da ihm z. B. eine erfolgreiche Altersverifikation vorgetäuscht wird. Da die Identitätsbestätigung über den Ausweis einen sehr starken Anscheinsbeweis liefert, wird das Opfer nur sehr schwer belegen können, dass eine Aktion von einem Angreifer und nicht vom Opfer selbst durchgeführt wurde.

Dabei wäre beispielsweise ein Szenario denkbar, bei dem ein Onlineshop Lieferung auf Rechnung anbietet, wenn der Käufer sich per Ausweis identifiziert – soweit ich weiß eines der öfter genannten Beispiele für eine mögliche Anwendung des ePersos. Würde ein Angreifer mit der Identität des Opfers eine Bestellung tätigen, würde der Händler sein Geld beim Opfer einfordern – und hätte vor Gericht dank der Ausweisprüfung gute Chancen, dies auch durchzusetzen. Auch wäre denkbar, dass der Angreifer ein Konto im Namen des Kunden eröffnet und für Betrügereien missbraucht – mit der Folge, dass das Opfer für diese Taten verantwortlich gemacht wird.

Totalversagen

Zum Glück gibt es eh kaum Dienste, die wirklich mit dem ePerso genutzt werden können. SCHUFA und die Flensburg-Punkteauskunft schicken die Zugangsdaten bzw. Infos separat per Post, sodass der Ausweis hauptsächlich als Formularausfüllhilfe dient, und ansonsten kann man damit Onlinepetitionen unterschreiben und kommt vielleicht bei ein paar Versicherungen ins Kundenmenü. Kurz: Unabhängig von den Sicherheitsproblemen hat das Projekt versagt.

Wie in diesem Beitrag erklärt, bin ich der Meinung, dass der ePerso vor allem als Instrument zur Zerstörung der Freiheit und Anonymität im Netz taugt und früher oder später auch dafür verwendet werden wird. Entsprechende Forderungen hat der Bundesinnenminister Friedrich erst gestern wieder gebracht. Wie das aussehen wird, sobald die Mehrheit der Bevölkerung einen ePerso besitzt, ist also absehbar. Wenn Kritik nicht mehr Anonym geäußert werden darf, leidet die Meinungsfreiheit massiv, da viele sich aus Angst vor möglichen Folgen nicht trauen, ihre Meinung zu sagen.

Davon abgesehen ist der ePerso eine sinnlose Wirtschaftsförderungsmaßnahme auf Steuerzahlerkosten. Neben den subventionierten Starterkits sieht man das am Besten daran, dass die Bürger ihre Signaturzertifikate von privaten Unternehmen kaufen müssen (für rund 20 Euro pro Jahr), statt sie zusammen mit dem Personalausweis direkt zu erhalten.

Die Entwicklung und Einführung des Ausweises sollen „nur“ rund 50 Millionen gekostet haben. Gegenüber dem alten Ausweis müssen die Bürger für den ePerso rund 20 Euro mehr zahlen. Bei 6,5 Millionen neuen Ausweisen pro Jahr kommen auf die Bürger jährliche Mehrkosten von 130 Millionen zu. Es ist also nie zu spät, das Projekt noch einzustampfen!

Apropos Signatur: Die geht mit dem Ausweis immer noch nicht, weil die entsprechende Version der AusweisApp auf sich warten lässt. Genauso übrigens, wie eine auf MacOS lauffähige Version.

Gegenmaßnahmen

Folgende Dinge können getan werden, um den Angriff zu erschweren bzw. zu verhindern:

Nutzer können:

• Den neuen Ausweis nicht im Internet nutzen, niemals an Lesegeräte halten und ggf. in einer abschirmenden Hülle transportieren
• Wenn sie den Ausweis im Netz nutzen wollen, ausschließlich Lesegeräte der höheren Sicherheitsstufen (eigenes PIN-Pad) einsetzen und die PIN ausschließlich auf dem Lesegerät eingeben. Weiterhin muss das eigene System sicher und virenfrei gehalten werden!
• Ihren alten Ausweis solange es geht behalten
• Plugins, die Chipkartenzugriffe erlauben, deinstallieren.

Reiner SCT (bzw. die für den Kern des Plugins verantwortliche Firma) kann:

• Die Sicherheitsabfrage vor jedem Zugriff auf das Lesegerät stellen (sollte nur bei Loginvorgängen nötig sein) und sie deutlicher formulieren
• Die APIs des Plugins einschränken, sodass Websites nur noch vordefinierte Funktionen der Karten auslösen können

Das hilft aber nur, wenn alle Hersteller vergleichbarer Plugins das auch tun.

Die Projektverantwortlichen können:

• Die unsicheren Basislesegeräte endlich abschaffen (nicht mehr für die Nutzung mit dem ePerso zulassen). Das ist die einzige Möglichkeit, die das Problem wirklich löst. Allerdings sind die besseren Geräte teuer und somit nicht gerade gut für die Akzeptanz.
• Das Projekt begraben und nicht noch mehr Geld verschwenden
• Die AusweisApp so umbauen, dass sie exklusiven Zugriff auf den Leser nimmt und ihn so für andere Anwendungen sperrt. Das würde Angriffe erschweren oder verhindern, allerdings nur, solange die AusweisApp auch läuft.

Aufgrund der Reaktion des BMI auf meinen ersten Angriff (falsche Behauptung, ich hätte den Angriff länger gekannt und absichtlich zurückgehalten) musste ich leider mit Versuchen rechnen, diese Angriffsmöglichkeit zu vertuschen. Daher habe ich mich entschieden, die Hersteller vor der Veröffentlichung nicht zu benachrichtigen (außer im Fall der XSS-Lücke). Am Besten vor dem Angriff schützen kann sich immer noch der Nutzer allein (durch Deinstallation der Browserplugins), sodass möglichst schnelle öffentliche Aufklärung über diese Gefahr meiner Meinung nach sinnvoll ist.

Die Schuld an dieser Lücke sehe ich übrigens weniger bei den Pluginentwicklern, auch wenn es keine gute Idee und ziemlich unnötig ist, Websites uneingeschränkten Low-Level-Zugriff auf Chipkarten zu geben. Das Hauptproblem ist die bescheuerte Idee, für eine derart sicherheitsrelevante Anwendung unsichere Lesegeräte (Basisleser/Klasse-1-Leser) nicht nur zu verwenden, sondern auch noch aus Steuergeldern zu fördern.

Technische Details

Das OWOK/SIZCHIP-Plugin erlaubt es der Website, per JavaScript einen Kanal zur Chipkarte zu öffnen und darüber beliebige Befehle (APDUs) zu schicken (und die Antworten zu lesen). Ein Angreifer würde diese Befehle von einem Server abholen, auf welchem eine AusweisApp (oder eine äquvivalente Software) läuft. Statt an ein echtes Lesegerät würden die APDUs, die die AusweisApp an die Karte schicken will, über AJAX zum JavaScript im Browser des Opfers geschickt. Dort würden sie über das Plugin an den Ausweis gesendet, und die Antwort würde auf dem umgekehrten Weg wieder zur AusweisApp kommen.

Ich habe hierzu zwei Proof-of-concepts erstellt. Für beide muss ein Lesegerät, das OWOK-Plugin sowie eine kompatible Karte (nicht unbedingt ein Ausweis) vorhanden sein.

Einer (attackwebsite) basiert auf der falschen AusweisApp (die bereits im „FSK18-Bereich“ der Piratenpartei zu sehen war). Er demonstriert, wie ein kompletter Angriff ablaufen würde. An den Ausweis (bzw. die Karte) wird hier nur der Befehl zum Auswählen der ePass-Anwendung geschickt, sodass man die unterschiedlichen Antworten von Ausweisen im Vergleich zu anderen Karten sehen kann.

Der zweite PoC (shellserver) implementiert das Abholen der Befehle über AJAX. Es kann entweder zum einfachen Testen ein fest im Server eingetragener Befehl an das Opfer geschickt werden, oder aber die Karte auf dem Lesegerät des Opfers wird an eine modifizierte cyberflex-shell angeschlossen, von wo dann beliebige Anfragen gestellt werden können.

Die PoCs kann man hier herunterladen, den ersten davon gibt es auch live unter https://fsk21.piratenpartei.de.

Den XSS-Angriff habe ich an Heise mit Bitte um Verifikation und anschließende Weiterleitung an den Seitenbetreiber gemeldet. Die Redaktion konnte ihn nachvollziehen.

ePerso: PIN-Diebstahl ohne Malware

Der CCC hatte im September 2010 einen Angriff gegen den ePerso präsentiert: Ein Trojaner auf dem PC des Nutzers kann die PIN abfangen, wenn der Nutzer sie über die Tastatur eingibt. Das ist für jeden, der sich ein wenig auskennt, keine Überraschung – aber durchaus ein großes Problem für den realen Einsatz des Personalausweises.

Ich habe nun einen Angriff entwickelt, der in der Lage ist, die PIN des Nutzers zu stehlen, ohne Malware auf dem Rechner des Nutzers zu installieren. Wer sich das mal anschauen möchte, kann ja die Altersverifizierung für den (fiktiven) FSK18-Bereich der Piratenpartei-Website durchführen. (Die PIN wird bei der Demo natürlich nicht an den Server gesendet.) Wer den Angriff testen will, sollte das jetzt erstmal tun und nicht weiterlesen.

v

v

v

Man kann den Angriff auch ohne Ausweis, Lesegerät und AusweisApp testen: Einfach eine sechsstellige PIN ausdenken und so tun als sei die AusweisApp installiert, das Lesegerät angeschlossen und der Ausweis aufgelegt.

v

v

v

Der Angriff funktioniert ganz einfach: Mit JavaScript, HTML und Screenshots (also Bildern) wird eine AusweisApp im Browser simuliert. Der Nutzer denkt, er würde die echte AusweisApp sehen, und gibt seine PIN ein. In diesem Fall wird nach der PIN-Eingabe eine Auflösung angezeigt, bei einem echten Angriff bekäme der Nutzer eine Fehlermeldung zu sehen, damit er keinen Verdacht schöpft, und seine PIN würde an den Server geschickt. Die Fehlermeldung wäre auch nichts besonderes – bei den meisten Seiten funktioniert die Ausweisfunktion eh nicht. (Und auch sonst funktioniert an dem ganzen Projekt ziemlich wenig: Die Änderungs-Terminals spinnen, Sonderzeichen machen Probleme, und so weiter.

Bei dieser Simulation ist es nicht möglich, die PIN über die eingebaute Bildschirmtastatur einzugeben, die entsprechende Schaltfläche fehlt. Das hat allerdings nichts damit zu tun, dass das prinzipiell nicht möglich wäre, sondern dass ich faul bin und keine Lust hatte, noch ein Dialogfeld detailgetreu nachzubauen. Sollte also jemand als „wirksame“ Gegenmaßnahme vorschlagen wollen, die Bildschrimtastatur zu nutzen, kann ich das gerne noch nachreichen. Die Bildschirmtastatur schützt lediglich vor sehr einfachen Keyloggern, und vermittelt ansonsten nur ein falsches Gefühl der Sicherheit. Wer Ausweise missbrauchen will, wird sich beim Trojanerschreiben die Mühe machen, auch Eingaben über die Bildschirmtastatur zu erkennen – das ist keine Kunst, sondern Fleißarbeit.

Dieser Angriff nutzt keine Sicherheitslücke im Ausweis oder der AusweisApp aus, sondern die Tatsache, dass Nutzer nicht in der Lage sind, echt aussehende von echten Fenstern zu unterscheiden. Das könnte zwar zu der Behauptung führen, dass dieser Angriff -in der Theorie- gar kein richtiger Angriff sei – das Ergebnis ändert das aber nicht: Der Angreifer hat am Ende die PIN des Nutzers.

Diese Funktionsweise macht es umso schwieriger, den Angriff zu verhindern: Die letzte Sicherheitslücke in der AusweisApp, die ich gefunden hatte, ließ sich mit ein paar Zeilen Code und einem Update lösen. Dieses Problem hingegen lässt sich nur lösen, indem man den Nutzern beibringt, worauf sie zu achten haben – und sie dazu erzieht, auch tatsächlich daran zu denken, jedes mal auf diese Merkmale zu achten. Das ist allerdings sehr schwierig.

Bei unvorsichtigen Nutzern könnte dieser Angriff selbst dann funktionieren, wenn der Nutzer ein Lesegerät der höheren Sicherheitsstufe hat, bei denen man die PIN normalerweise über das Lesegerät eingibt. Eigentlich sollte es dem Nutzer auffallen, wenn er die PIN plötzlich am Rechner eingeben soll – aber wie viele Nutzer, die von den Sicherheitskonzepten keine Ahnung haben, werden die PIN trotzdem über die Computertastatur eingeben, wenn der Computer sie dazu auffordert und die Eingabe über das Lesegerät nicht akzeptiert?

Um sich gegen diesen Angriff zu schützen, muss man lernen, falsche von echten Fenstern zu unterscheiden. Im Browser wird die Website in einem bestimmten Bereich angezeigt. Lässt sich ein Fenster aus diesem Bereich heraus verschieben, dann handelt es sich zumindest um ein richtiges Fenster. Allerdings können Webseiten auch Popup-Fenster öffnen, die sich dann frei verschieben lassen. Bei allen gängigen Browsern kann die Website dabei zwar viele Teile des Browserfensters ausblenden, aber die Adressleiste (bzw. bei Opera eine dünne Leiste mit der Website-Adresse) bleibt immer stehen, eben um zu verhindern, dass ein Popup für ein echtes Fenster gehalten wird. Der „Verschiebetest“ zusammen mit einem kritischen Blick auf das Fenster ist also ein guter allgemeiner Anhaltspunkt.

Darüber hinaus hat die AusweisApp (bei angeschlossenem Lesegerät) ein Chip-Symbol in der Taskleiste neben der Uhr, welches bei aufgelegter Karte grün wird. Ist die AusweisApp aktiv, wechselt es die Farbe zu Blau. Das ist ein weiteres Sicherheitsmerkmal, auf das man achten sollte. Da ich nicht ausschließen möchte, dass es möglich ist, die AusweisApp zu aktivieren und dann irgendwie zu überlagern, würde ich den Verschiebetest zusätzlich empfehlen. Seltsam aussehende Schrift im AusweisApp-Fenster ist übrigens kein Hinweis auf eine Fälschung: Die Schriften sehen auch in der echten AusweisApp seltsam aus.

Man kann falsche Fenster also durchaus unterscheiden – aber die Hinweise, wie man es macht und dass man es machen solte, fehlen in den Hochglanzbroschüren zum Ausweis. Von sich aus kommen selbst Fachleute selten auf die Idee, diese Prüfungen zu machen, solange nicht irgendetwas Verdacht erregt. Eine gute Fälschung tut das aber nicht.

Ist der Angreifer im Besitz der PIN, reicht dies allein zwar noch nicht, um die Identität des Ausweisinhabers zu missbrauchen – die PIN existiert aber nicht ohne Grund und sollte nicht nur zum Spaß geheimgehalten werden. Ein Beispiel für einen Angriff, für den eine gestohlene PIN nützlich wäre, wurde auf dem 27C3 präsentiert.

Warum ich den Ausweis auch unabhängig von der Lücke ablehne, steht in diesem Beitrag. Auf weitere grundsätzliche Probleme wie die Beweislastumkehr, die für Ausweisnutzer ein ziemlicher Nachteil ist, werde ich in weiteren Beiträgen eingehen wenn/falls ich dafür Zeit finde. Ich kann nur davon abraten sich so einen Ausweis zu holen, bzw. wenn man schon einen hat, ihn zu nutzen. Auch wenn Alufolie immer an Verschwörungstheoretiker mit Aluhüten erinnert – ein paar Lagen davon, um den Ausweis gewickelt und an den Seiten umgefaltet, verhindern das Auslesen sowohl beim Ausweis als auch bei anderen RFID-Karten zuverlässig.

Noch ein kleiner Hinweis für die Presse: Ich bin immer noch kein CCC-Mitglied, obwohl ich letztes Mal nach den Falschmeldungen eingeladen wurde ;-)

Fragen die öffentlich beantwortet werden sollen/können, bitte über die Kommentarfunktion. Sonstige (An)fragen bitte über Jabber (XMPP, Google Talk) an janschejbal at jabber.ccc.de (das ist keine Mailadresse!) oder Mail an janhomepage [at] gmx punkt net. Telefon ist ungünstig, ggf. bitte Festnetznummer per Mail schicken.

Bundestag kann SSL abhören

Der Bundestag kann SSL-gesicherte Verbindungen abhören. SSL ist vielen vielleicht nur als „https“ bekannt und sichert neben Onlinebanking auch z. B. Verbindungen zu E-Mail-Servern und ziemlich viele andere Sachen. (Kurzzusammenfassung für Leute die sich mit SSL auskennen: Der Bundestag hat ne CA. Der Artikel erklärt halbwegs laienfreundlich genau das, die Grundidee hinter SSL und warum SSL kaputt ist.)

SSL funktioniert so: Eine vertrauenswürdige Stelle stellt dem Server einen Ausweis aus, den er vorzeigt, und darüber wird die Verbindung verschlüsselt. Das nennt sich Zertifikat und die technischen Details habe ich schonmal erklärt, hier will ich es einfach halten. Ein Angreifer kann sich in die Verbindung nicht einklinken, weil er keinen passendes Zertifikat hat (nur der Besitzer oder jemand der das Original kopiert hat kann ein Zertifikat zeigen, weil beim Zeigen ein Teil geheim bleibt. Klingt komisch, ist aber Mathematik.)

In jedem Browser ist eine Liste der aus Sicht des Browsers vertrauenswürdigen Stellen enthalten. Das sind ungefähr 50 Stück und zwar auch solche, die man vielleicht nicht ganz so vertrauenswürdig findet, wie z. B. die chinesische Internetbehörde.

Die Sicherheit von SSL beruht darauf, dass ein Angreifer kein Zertifikat bekommt für die Seite, deren Datenverkehr er abhören will. Wenn jemand den Datenverkehr zur Postbank abhören will, muss er also jemanden finden, der ihm ein Zertifikat ausstellt, was bestätigt dass ihm Postbank.de gehört. Das kann aber jede der vertrauenswürdigen Zertifizierungsstellen.

Es wird noch „besser“: Die Zertifizierungsstellen können jedermann zu einer Zertifizierungsstelle machen. Derjenige hat dann die gleichen Möglichkeiten wie die im Browser eingetragenen Zertifizierunsstellen. Neben den 50 Stellen können also noch viele viele weitere ein falsches Zertifikat ausstellen – und mit einem solchen kann man eine eigentlich gesicherte Verbindung abhören. (Das funktioniert so, dass der Angreifer die Verbindung über sich umleitet und behauptet, er sei die Postbank – über das Zertifikat prüft der Browser ob das stimmt.)

Zertifizierungsstellen kürzt man übrigens mit CA ab.

SSL ist also unsicher, wenn

• Eine einzige dieser CAs einen Fehler macht und ein Zertifikat ausstellt ohne zu merken, dass der Angreifer nicht die Postbank ist
• Eine CA dem Angreifer bewusst oder z. B. über einen erpressten Mitarbeiter ein falsches Zertifikat ausstellt (man denke an Geheimdienste oder Industriespionage, viele CAs werden von Regierungen/regierungsnahen Organisationen und noch mehr von Firmen die eigentlich was ganz anderes machen betrieben)
• Der Angreifer eine eigene CA hat/ist/kauft
• eine Sicherheitslücke im Protokoll oder im benutzten Browser/Server auftaucht
• oder irgendwas was ich vergessen hab passiert

Fehler sind schon oft passiert. Ein paar Forscher haben mal das Internet nach SSL-Zertifikaten abgegrast und das zusammen mit ein paar anderen Sicherheitsproblemen auf der DefCon präsentiert. Sie sind auf über 500 Organisationen gekommen die direkt oder indirekt eine CA haben.

Weiterhin haben sie gemerkt, dass CAs ca. 500 noch gültige Zertifikate, die praktisch „geknackt“ sind (durch eine Sicherheitslücke bei Debian) nicht für ungültig erklärt haben, und gültige Zertifikate für private IPs. Das ist in etwa so wie ein Ausweis der bestätigt dass Büro Nummer 37 einer bestimmten Person gehört – ohne zu sagen, von welchem Haus in welcher Stadt man redet. Das scheint übrigens dann das Ausnutzen eine anderen Sicherheitslücke zu erlauben (vereinfacht: man sagt dem Nutzer, dass er die Postbank im gleichen Flur in Büro 37 suchen soll, geht in dieses fremde Büro und zeigt dann wenn der Nutzer kommt den Ausweis vor. Deswegen darf es so einen Ausweis eigentlich nicht geben).

Ach ja, und um zu prüfen, ob jemandem eine Domain gehört, wird eine Mail verschickt. Über oft unverschlüsseltes SMTP. Nachdem über bisher ungesichertes DNS nachgeschaut wurde, wohin die Mail gehen soll. Wenn also jemand es schafft, eine dieser Verbindungen zu manipulieren, bekommt er falsche Zertifikate.

Trotzdem sollte man SSL benutzen. Ohne SSL kann ein Angreifer einfach so mithören, was passiert. Mit SSL muss er selbst bei groben Sicherheitsproblemen (z. B. Zertifikate gar nicht prüfen) auch Kommunikation manipulieren statt einfach nur mitzuhören (geht recht leicht, ist aber eine Hürde). Selbst wenn eine CA falsche Zertifikate ausstellt, muss der Angreifer diese finden und sie muss auch ihm so ein Zertifikat geben. Wenn z. B. die Telekom dem BND ein Zertifikat geben würde (was ich jetzt nicht unterstellen möchte), würde sie es immer noch nicht mit einem gewöhnlichen Kriminellen tun. Auch hier wird also eine Hürde geschaffen.

Schützen kann man sich nur bedingt. Die Firefox-Extension CertPatrol zeigt an, wenn sich ein Zertifikat ändert, und auf Wunsch auch bei neuen Zertifikaten, wer es ausgestellt hat. Dabei machen sowohl die Extension als auch Firefox (beim Klick auf das blaue „gesicherte Verbindung“-Feld in der Adressleiste) einen groben Fehler, den ich hier allerdings noch nicht erklären werde. Erinnert mich in nem Monat dran wenn ich nicht dran denke. (Update: In CertPatrol inzwischen behoben – es wird/wurde nur die CA angezeigt, die das Zertifikat ausgestellt hat. Ein Angreifer, der eine falsche CA hat, kann aber erst eine andere falsche CA mit beliebigem Namen erstellen, und damit dann das Cert ausstellen.) Mit dieser Extension habe ich auch gemerkt, dass der E-Petitionsserver des Bundestags plötzlich ein von der mir bis dahin unbekannten Bundestags-CA ausgestelltes Zertifikat hat. Damit könnte der Bundestag theoretisch falsche Zertifikate ausstellen und so SSL-Verbindungen abhören.

Beim Ausstellen falscher Zertifikate geht die CA aber ein gewisses Risiko ein – normale Nutzer merken das nicht, aber wenn es mal einer mit z. B. CertPatrol merkt und das Zertifikat abspeichert, kann die CA sich nicht völlig herausreden, das Zertifikat verrät unabstreitbar wer es ausgestellt hat. Sie muss es auf einen Fehler schieben und hoffen dass nichts passiert. Wenn sich solche Fehler häufen, düfte die CA aus den Vertrauenslisten in den Browsern rausfliegen und andere CAs dürften sich hüten, diese Organisation wieder in den CA-Status zu heben. Um Zertifikate direkt abspeichern zu können, wenn sie auftauchen (und so das Risiko zu vermeiden, dass beim Abruf mit einem anderen Tool wieder das „saubere“ Zertifikat drin ist), kann man die Extension Cert Viewer Plus nutzen.

Die Bundestags-CA wurde vom DFN (Deutsches Forschungsnetz) bestätigt, welches wiederum seine CA von der Telekom bestätigt bekommen hat. Hier die Zertifikate:

Certification path for "epetitionen.bundestag.de"
Inhaber: C=DE,ST=Berlin,L=Berlin,O=Deutscher Bundestag,OU=PetA,CN=epetitionen.bundestag.de
Aussteller: C=DE,O=Deutscher Bundestag,OU=Deutscher Bundestag,CN=Deutscher Bundestag CA - G01,E=pki-ca@bundestag.de
Validität: from 2010-09-27 13:09:06 UTC to 2015-09-26 13:09:06 UTC
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIEEMAVAjANBgkqhkiG9w0BAQUFADCBlDELMAkGA1UEBhMC
REUxHDAaBgNVBAoTE0RldXRzY2hlciBCdW5kZXN0YWcxHDAaBgNVBAsTE0RldXRz
Y2hlciBCdW5kZXN0YWcxJTAjBgNVBAMTHERldXRzY2hlciBCdW5kZXN0YWcgQ0Eg
LSBHMDExIjAgBgkqhkiG9w0BCQEWE3BraS1jYUBidW5kZXN0YWcuZGUwHhcNMTAw
OTI3MTMwOTA2WhcNMTUwOTI2MTMwOTA2WjB/MQswCQYDVQQGEwJERTEPMA0GA1UE
CBMGQmVybGluMQ8wDQYDVQQHEwZCZXJsaW4xHDAaBgNVBAoTE0RldXRzY2hlciBC
dW5kZXN0YWcxDTALBgNVBAsTBFBldEExITAfBgNVBAMTGGVwZXRpdGlvbmVuLmJ1
bmRlc3RhZy5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANxlR8dG
FjtzBE05l7RKRgQwy6DSzLE8qeoPuycX4VrYvgRdX0NyeoZ3h9MqT0DJHvXAWS+d
BHkNrnhRHFf4cxZsIbSjnrSr311QUmwityCoinESNqXAdY/i466/TEE+GcUOS4t2
Mfmba8Zi3qKGspgcGec14xuyNc8ENlKvTjKBC+mJrjlh/Gpb3VW/rNh65V8EXvbW
vlXbyDbZ/5n57TZqM2bblPWRnh/Zual54Y/khqlPdWuNxHMSr+OtvgXW/aJGWOzh
uusPIzxp1uYgd7PMCvP5aHf1w5mMy3Em1c6w8PiH7Fq1yDa1CbpFpq+SHQ0NF2lu
lQecru1cdFefpsUCAwEAAaOCAcwwggHIMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXg
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAdBgNVHQ4EFgQUJUpy4/No
XDOu0LAY+DNj7g+E51QwHwYDVR0jBBgwFoAUd42VgQQK41VYmdALyblb5SJ+LjYw
gZkGA1UdHwSBkTCBjjBFoEOgQYY/aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZXV0
c2NoZXItYnVuZGVzdGFnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMEWgQ6BBhj9odHRw
Oi8vY2RwMi5wY2EuZGZuLmRlL2RldXRzY2hlci1idW5kZXN0YWctY2EvcHViL2Ny
bC9jYWNybC5jcmwwgbIGCCsGAQUFBwEBBIGlMIGiME8GCCsGAQUFBzAChkNodHRw
Oi8vY2RwMS5wY2EuZGZuLmRlL2RldXRzY2hlci1idW5kZXN0YWctY2EvcHViL2Nh
Y2VydC9jYWNlcnQuY3J0ME8GCCsGAQUFBzAChkNodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL2RldXRzY2hlci1idW5kZXN0YWctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0
MA0GCSqGSIb3DQEBBQUAA4IBAQB4XvDdQcukMgEEvgLklMuAjrU7GT4SgyiHZCkY
hcEqqOHA0WiP6i1H66MTui00TDVv9QRpjnMgy9jD0QXynWgHG0F07ZrpO+8YBQvL
NsuslkYr9SXMnOOw3AfwDTUbo+sLKWaRiBiVeP6WOrbtCddrbmMvWexf/1M8dx/E
ynIEIyhRgXD/1YyFLzi85I8UP4eCKa38HPxIgI5An5baOjA4rgOH/LyAKV+9659T
/vjTZZ4R2t/ratiLZEoZ1byUqdit3msDQoq5YXKF5DVgMGF+jL6V+wXg8Vu10ajg
KO6AxrzMS+WBgY4PXuwLMY3iO8GL8s0IlAtMu9Ew0svPAH2V
-----END CERTIFICATE-----
Inhaber: C=DE,O=Deutscher Bundestag,OU=Deutscher Bundestag,CN=Deutscher Bundestag CA - G01,E=pki-ca@bundestag.de
Aussteller: C=DE,O=DFN-Verein,OU=DFN-PKI,CN=DFN-Verein PCA Global - G01
Validität: from 2008-12-17 14:39:27 UTC to 2019-06-30 00:00:00 UTC
-----BEGIN CERTIFICATE-----
MIIFJDCCBAygAwIBAgIEDWiMrzANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJE
RTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UE
AxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA4MTIxNzE0MzkyN1oX
DTE5MDYzMDAwMDAwMFowgZQxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2No
ZXIgQnVuZGVzdGFnMRwwGgYDVQQLExNEZXV0c2NoZXIgQnVuZGVzdGFnMSUwIwYD
VQQDExxEZXV0c2NoZXIgQnVuZGVzdGFnIENBIC0gRzAxMSIwIAYJKoZIhvcNAQkB
FhNwa2ktY2FAYnVuZGVzdGFnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAyV2H0tJjqK2L25XRrdkSyAmCm5AO71u+xAme6ppAunax/aW11Bhn2cet
N3nj0govnSVnOCre2inqvm49d/MVj0zyhhw7v5AG2Ab5WK/4TryLofCHJEEn+1oy
CWnNqBQIjFLawUbhfjOOspPxLujDTdaYDn7Z00nY85c7cRESdW3BbeL0a2OrSJyJ
yW93nR/+of9tsyTLsy9LiKZvRaGnXtYUDy/Sq3MSpgiWjsq95VFBT0lMBE1J+xv7
4ZrXikfZs+o3cfVxFQluLPwmxSqrd4BmH6rTxUb9iFLWwEFWJIYLlV8Z6GG9kxOd
KG9Q+T3QxUqi0Mw7/5hrl8Zs0wXbDQIDAQABo4IBtTCCAbEwEgYDVR0TAQH/BAgw
BgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFHeNlYEECuNVWJnQC8m5W+Ui
fi42MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB4GA1UdEQQXMBWB
E3BraS1jYUBidW5kZXN0YWcuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8v
Y2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3Js
MD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1
Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7
aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0
L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv
Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB
BQUAA4IBAQCTl0KbJX0XEEVgNkLeS/dmgJzwcSC6z8aFvhQPzbE08Q/qhWItV4iU
YYZ9nkfuoKzoz1V1CoqEFhE7QRKr0OLMHVs+yJnWXfWEuQ11ph6KMEAvK8b/9J0O
Hz83WRO7pqZp1VWZGZ0Prj3CWkqxUEmFiPcCC3N1pRcVvufimpchB3SA2NeUKE4C
G2fo3XT3q99ltN53wAPGXhqzSVXO8zYIW+bglion3IdeYna/Hzx94RpXNKl5q4pK
e0lSRUtj0k0yWS/YDptFsVPhr5wLm+uVXz/G43/7I5TYEZ56Yz6LqUhrY59XkSeG
6trUzc7DpXEZWvoqFQy/0jonReRX15x9
-----END CERTIFICATE-----
Inhaber: C=DE,O=DFN-Verein,OU=DFN-PKI,CN=DFN-Verein PCA Global - G01
Aussteller: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Validität: from 2006-12-19 10:29:00 UTC to 2019-06-30 23:59:00 UTC
-----BEGIN CERTIFICATE-----
MIIEITCCAwmgAwIBAgICAMcwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUx
HDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNl
YyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD
QSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UEBhMC
REUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNV
BAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0
j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFssoNTl7LZBF0O2gAHp8v0oO
GwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90D8EJovZr
zr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8z
s9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTb
yRM0mnF1xWzqpwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBwBgNV
HR8EaTBnMGWgY6Bhhl9odHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2
aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVy
PURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYD
VR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEGMBIG
A1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfcqRjs
ga9aifC9KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+EREe5r
eJEzfjtfJid1U2WOM2Puz3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUpQPY/
czJYDQlrptqFbMA/u41mZFYkTq4NPzI1AVvpjILZcllPsYaF8XSFVuXD+Fzzje5H
s1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6LArZYtfahLDdXAGerI2iN
Y6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3LxMr+Mzklj
qAD38hw=
-----END CERTIFICATE-----
Inhaber: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Aussteller: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Validität: from 1999-07-09 12:11:00 UTC to 2019-07-09 23:59:00 UTC
-----BEGIN CERTIFICATE-----
MIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEc
MBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj
IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENB
IDIwHhcNOTkwNzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJE
RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxl
U2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290
IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrC6M14IspFLEU
ha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7TuKhC
QN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1Mjwr
rFDa1sPeg5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1S
NNs671x1Udrb8zH57nGYMsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0moc
QqvF1afPaA+W5OFhmHZhyJF81j4A4pFQh+GdCuatl9Idxjp9y7zaAzTVjlsB9WoH
txa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT1xfgiXotF2wKsyudMzAP
BgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOC
AQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756Abrsp
tJh6sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpa
IzpXl/V6ME+un2pMSyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl
6iFhkOQxIY40sfcvNUqFENrnijchvllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+
xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9WgbRGOiWrqnNVmh5XAFmw4jV5mU
Cm26OWMohpLzGITY+9HPBVZkVw==
-----END CERTIFICATE-----

Einzelne CAs im Browser rauswerfen bringt wenig, weil gerade die kleinen/neuen CAs oft (nicht öffentlich sichtbare!) Bestätigungen von anderen CAs haben. Wenn man eine CA rauswirft, die viele Zertifikate ausstellt, kann man deren Zertifikate nicht mehr von gefälschten unterscheiden. Da man nicht jedes Zertifikat manuell prüfen kann – ganz schlecht. Am Sinnvollsten dürfte CertPatrol sein und für kritische Sachen eben auf die Warnungen achten und beim ersten Mal das Zertifikat genau prüfen. Interessanterweise hat Microsoft dieses Problem scheinbar erkannt – bei WLAN-Verbindungen wo die Anmeldung über Zertifikate gesichert wird muss man ausdrücklich auswählen, welchen CAs man für diesen Zweck traut, und nur die werden akzeptiert. So kann eine Firma sicherstellen, dass ihre Rechner für die Anmeldung in ihrem WLAN nur ihrer eigenen CA und nicht der des Konkurrenten trauen. Und in der Fehlermeldung wird unterschieden zwischen „Zertifikat einer unbekannten CA“ und „Zertifikat einer bekannten aber nicht angekreuzten CA“ sodass man sich zumindest halbwegs sicher verbinden kann, wenn man die richtige CA nicht weiß.

Für Serverbetreiber gilt: Es spielt keine Rolle, wie sicher die CA ist, die man wählt – wichtig ist nur, welche CA in den Browsern akzeptiert wird. Selbst erstellte (nicht von einer CA bestätigte) Zertifikate sind eine relativ schlechte Lösung – eine CA bietet zusätzlich die Möglichkeit, halbwegs sicher zu sein, selbst wenn man das Zertifikat nicht selbst prüfen konnte. Kostenlose Zertifikate für Webserver gibts bei StartSSL, was bis auf Opera von allen Browsern akzeptiert wird. Das oft vorgeschlagene CAcert ist in den meisten Browsern standardmäßig nicht enthalten und daher IMHO nur zweite Wahl – bietet dafür aber auch andere Zertifikatstypen an.

Fefe hat das Thema auch schon kommentiert und ein weiteres Horrorgeschichtenkabinett findet sich in den „A mighty fortress is our PKI“-Mails von Peter Gutmann: Teil 1, Teil 2, Teil 3