mTAN-Betrugsfälle: Erst der Anfang

Betrugsfälle bei mTAN häufen sich inzwischen genauso, wie sich die Medienberichte darüber häufen. Dass das mTAN-Verfahren nichts taugt, war seit Jahren klar und ich habe bereits Anfang 2011 darüber berichtet.

Die aktuelle Betrugswelle setzt scheinbar auf gezielte Angriffe, bei denen der Mobilfunkanbieter des Opfers getäuscht wird, und schließlich den Betrügern eine Zweit-SIM-Karte mit der Nummer des Opfers überlässt. Im Gegensatz zu den Phishing-Angriffen, die versuchen mit möglichst wenig Aufwand möglichst viele Opfer zu erwischen, geht es hier also um gezielte und relativ aufwändige Angriffe.

Somit ist es nur eine Frage der Zeit, bis auch Angriffe über das Mobilfunknetz stattfinden. Die Sicherheit von GSM (klassischen Mobilfunknetzen) ist inzwischen vorne und hinten zerlegt worden. Mitlesen von SMS ist mit einem normalen Computer, 2 TB an Festplatten/SSDs/USB-Sticks, frei erhältlicher Software und einem einfachen DVB-T-Stick, der bei Amazon rund 20 EUR kostet, möglich. Alternativ gibt es auch aktive Attacken, welche die SMS frei Haus an einen beliebigen Ort in der gleichen Location Area liefern und praktischerweise auch gleich verhindern, dass der rechtmäßige Empfänger die SMS bekommt. Auch die Verschlüsselung von UMTS ist inzwischen zumindest stark angeknackst. Alle diese Sachen sind öffentlich bekannt, und zwar seit Jahren. Das Bestellen von Zweit-SIM-Karten hatte ich bereits in meinem Artikel von 2011 als einen möglichen Angriffsweg von vielen genannt. Ich weiß nicht, ob es schon damals praktiziert wurde und öffentlich bekannt war, oder einfach nur so offensichtlich, dass ich von selbst drauf gekommen bin. Ich tippe auf letzteres, denn zunächst waren Handy-Trojaner das Mittel der Wahl, um an mTANs zu kommen.

Bisher war den Betrügern das Abfangen der SMS im Mobilfunknetz scheinbar zu aufwändig, aber das wird sich ändern, sobald die Mobilfunkbetreiber es schaffen, den betrügerischen Zweitsimkarten-Bestellungen einen Riegel vorzuschieben. Von diesem Angriff wird der Kunde dann erst einmal nichts mitbekommen.

Statt das vermurkste mTAN-Verfahren abzuschaffen und z. B. ChipTAN einzusetzen, was bei korrekter Umsetzung nahezu perfekte Sicherheit bieten würde, verteidigen Banken die mTAN, versuchen einzelne Varianten des mTAN-Betrugs mit kleineren Änderungen abzustellen, und schieben zum Teil die Schuld ihren Kunden in die Schuhe, indem sie immer wieder die Sicherheit des Verfahrens betonen und auf die „Sorgfaltspflicht“ des Kunden hinweisen (Virenscanner etc.). In den oben verlinkten Berichten wird immer wieder erwähnt, dass Kunden zum Teil noch nicht wissen, ob sie ihr Geld zurückbekommen, denn das sei eine Einzelfallentscheidung…

Der Bankenverband geht laut Pressestelle davon aus, dass die Angriffe nicht auf die Praxis übertragbar seien und sich deswegen nicht auf das Onlinebanking auswirken. Beispielsweise sei physischer Zugriff auf die SIM nötig (andere Meinung), physische Nähe zum Mitschneiden (5-35 km laut Folie 13/PDF-Seite 14 dieser Präsentation), die Daten müssen offline und damit verzögert entschlüsselt werden (hier wird der Aufwand bei Verwendung von SSDs auf die Größenordnung von 10 Sekunden geschätzt), die TMSI-Übermittlung sei nötig und nur bei manchen Providern unterstützt (d.h. wenn das tatsächlich ein Hindernis ist, dann nur für manche Netze), und eine stille SMS könne nur der Provider schicken (diese und diese Android-App behaupten es auf gerooteten Geräten zu können, aber evtl. filtern die Provider; nicht getestet – andere Methoden wie kurze Anrufe wurden aber genannt).

Zudem sei die mTAN nur ein Faktor von mehreren (d.h. zusätzlich braucht der Angreifer die PIN). Dieses Argument ist allerdings Humbug, denn das mTAN-Verfahren dient ja gerade dazu, das System auch bei bekannter PIN sicher zu halten – sonst könnte man einfach iTAN weiternutzen oder gar ganz auf TANs verzichten.

Meine Meinung nach ist das wieder mal ein klarer Fall von „Kopf so lange in den Sand stecken, bis die Angriffe so oft passieren, dass man das Problem nicht mehr wegreden kann“, wie damals bei den EC-Karten und seitdem zig anderen Verfahren. Es wird sicher nicht einfach sein, diese Angriffe durchzuführen, was Kriminelle eine gewisse Zeit lang davon abhalten wird. Aber früher oder später wird es passieren – und der Kunde kann nichts tun, um das Abfangen der mTAN zu verhindern, er kann lediglich seine PIN schützen wie schon bei iTAN. Wenn jemand fahrlässig handelt, dann sind es die Banken, die ihre mTANs über unsichere Kanäle verschicken, deren Unsicherheit seit Jahren bekannt ist – und trotzdem immer wieder behaupten, das Verfahren sei sicher. Kurz, ich bleib bei ChipTAN bzw. iTAN und stocke meine strategischen Popcornreserven auf.

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

Verified by Visa – Unsicherheit mit System

Früher konnte man mit einer Kreditkarte einfach online zahlen, indem man Kreditkartennummer und Gültigkeitsdatum (und später noch CVV2) eingegeben hat. Das hatte den Nachteil, dass ein Betrüger, der diese Angaben erfahren hat, auch mit der Karte einkaufen konnte. Besonders einfach ist es natürlich, wenn ein Händler selbst der Betrüger ist oder mit Betrügern zusammenarbeitet.

Deswegen haben sich die Kartenherausgeber ein System ausgedacht, was dieses Problem lösen sollte: Der Händler leitet einen auf die Seite der Bank um, dort meldet man sich mit einem Kennwort an, was nur dem Karteninhaber und der Bank bekannt ist, und die Bank bestätigt, dass der Karteninhaber sich angemeldet hat. Visa nennt das „Verified by Visa“, Mastercard nennt es „Mastercard SecureCode“, und allgemein werden diese Verfahren als 3-D-Secure-Verfahren bezeichnet. Da das Passwort im Gegensatz zu den Kreditkartendaten immer nur zwischen Kunde und Bank (verschlüsselt) ausgetauscht wird, ist es für Betrüger deutlich schwerer, an dieses Passwort zu gelangen. Eigentlich genial.

Eigentlich. Wenn der Nutzer auch tatsächlich das Passwort nur auf der Bankseite eingibt. Dafür muss er wissen, wie er die Bankseite erkennt, und auch darauf achten. Idealerweise, indem die Verifikationsseite, auf der der Kunde sein Verified-by-Visa-Passwort eingibt, auf der dem Kunden bekannten Domain seiner Bank betrieben wird. Aus unerklärlichen Gründen passiert genau das leider oft nicht, und ein Kunde kann nicht wissen, ob die Seite wirklich zu seiner Bank gehört oder nicht. Auch dafür gibt es eine Lösung: Mit EV-Zertifikaten wird der Name des Webseitenbetreibers neben der Adresszeile angezeigt (Beispiel). Darauf könnte man die Kunden trainieren, und Kunden mit Ahnung von IT-Sicherheit hätten etwas, worauf sie sich verlassen könnten.

Das setzt aber voraus, dass die Kunden wirklich auf die Bankseite umgeleitet werden, und somit sehen können, auf welcher Seite sie sind. Immer mehr Händler binden die Bankwebsite aber per IFrame in ihre eigene Website ein, statt den Kunden auf die Bankwebsite umzuleiten. Ohne den Quelltext der Seite auseinanderzunehmen, kann der Kunde nicht sehen, ob das Eingabeformular wirklich von seiner Bank stammt, oder einfach das Passwort einem betrügerischen Onlineshop (oder einem Hacker, der einen echten Onlineshop manipuliert hat) ausliefert. Was eigentlich ein untrügliches Zeichen für Phishing ist (Eingabeformular für Bankpasswort auf Nicht-Bank-Website), ist bei Verified-by-Visa/3D-Secure nicht nur völlig normal, sondern sogar die ausdrücklich empfohlene Art, das 3D Secure-Verfahren umzusetzen.

Um dem Kunden die Echtheit der Seite zu bestätigen, gibt es daher eine „persönliche Begrüßung“, die nach der Eingabe der Kreditkartennummer, aber vor der Eingabe des Passworts, angezeigt wird. Dieses auch auf anderen Seiten beliebte Verfahren ist völlig wirkungslose Scheinsicherheit: Eine bösartige Website, die das Passwort abgreifen will, kann per Software die Website der Bank besuchen, die Kreditkartennummer des Kunden dort eingeben, und bekommt daraufhin die persönliche Begrüßung mitgeteilt. Diese kann sie nun dem Kunden anzeigen und sich so als besonders echt ausweisen. Theoretisch könnte das gegen „dumme“ Phishingseiten schützen, die sich diese Mühe nicht machen wollen, praktisch wird dort das Fehlen der Begrüßung aber den meisten Kunden nicht auffallen.

Das Verfahren mit Kreditkartennummer, Gültigkeitsdatum und später CVV2 war auch notorisch unsicher, führte zu Missbrauch, aber es war bequem. Die Kartenherausgeber nahmen das bewusst in Kauf und übernahmen die Schäden, weil die Kreditkarten gerade durch ihre Bequemlichkeit attraktiv waren – den Kunden konnte die Unsicherheit egal sein, da die Kreditkartenherausgeber die Schäden übernahmen. Mit der Einführung von Verified by Visa/3-D Secure könnte sich das ändern. Mit dem Argument, das Verfahren sei sicher und jeder Missbrauch sei auf Fahrlässigkeit des Kunden zurückzuführen, könnten Banken nun versuchen, die Schäden auf Kunden abzuwälzen. Insbesondere das sinnlose Verfahren mit der persönlichen Begrüßung stinkt förmlich danach, dass das System als deutlich sicherer dargestellt werden soll, als es ist.

Deswegen schreibe ich diesen Beitrag: Das Verfahren ist unsicherer Murks, aber der Kunde hat keine andere Wahl, als es zu benutzen, wenn er seine Kreditkarte nutzen will. Solange die Bank dafür haftet, ist das auch völlig OK. Sollte eine Bank aber versuchen, die Folgen ihrer eigenen Fahrlässigkeit auf die Kunden abzuwälzen, ist dies inakzeptabel. Ich hoffe, dieses Posting trägt dazu bei, dass die Unsicherheit von Verified-by-Visa/3-D Secure besser bekannt wird, und es Banken dadurch schwerer wird, die Schäden unrechtmäßig auf ihre Kunden abzuwälzen.

Das Problem ist übrigens nicht neu und es haben schon zig Leute darüber geschrieben – siehe z. B. das Paper von Steven J. Murdoch und Ross Anderson, die regelmäßig vermurkste Bank-Sicherheitssysteme auseinandernehmen. Von Ross Anderson ist auch dieser herrliche offene Brief (Leseempfehlung!) an einen Kartenherausgeber-Verband, der die Publikation unangenehmer Forschungsergebnisse mit rechtlichen Drohungen verhindern wollte. Anderson findet in seinem vor Sarkasmus triefenden Meisterwerk  sehr deutliche Worte für das Abwälzen von Schäden durch unsichere Systeme auf die Kunden, indem behauptet wird, die Systeme seien sicher.

 

Es gibt noch einen weiteren, viel banaleren Grund, warum ich Verified by Visa hasse: Es ist lästig. Da man in Deutschland Kreditkarten online meist ca. einmal im Jahr braucht, kann ich mir das Passwort nie merken (speichern/aufschreiben darf man es natürlich auch nicht, und die sinnlosen Beschränkungen auf 8-10 Zeichen, die die Comdirect einem aufzwingt, tun ihr übriges). So besteht eine Kreditkartenzahlung für mich immer daraus, dass ich mich bei meiner Bank einloggen und dort mittls PIN+iTAN ein neues Kennwort setzen muss. Sehr komfortabel. Insbesondere, wenn die Bank wie gerade eben Wartungsarbeiten hat, und ich meine Kreditkarte deswegen nicht nutzen kann, oder wenn man dringend unterwegs ein Zugticket per Kreditkarte online bezahlen muss, aber die TAN-Liste zu Hause liegt. Die Kreditkarte ist so vom bequemsten Online-Zahlungsverfahren zum Umständlichsten geworden, ohne auch nur ansatzweise vergleichbare Sicherheit zu bieten. Herzlichen Glückwunsch.

Besuch bei der Bundesdruckerei

Bernd Schlömer und ich sind Anfang November einer Einladung der Bundesdruckerei gefolgt und haben sie in Berlin besucht. Dabei ging es vor allem um den elektronischen Personalausweis (weswegen ich dabei war). Hier möchte ich euch kurz von dem Besuch berichten und auch an einigen Stellen meine Meinung dazugeben.

Wir bekamen eine kurze Vorstellung der Bundesdruckerei, eine Führung durch die ePerso-Produktion (ein paar Infos zum Aufbau des Ausweises siehe hier, hier und hier Edit: und hier) und haben anschließend sachlich über unsere Kritik am eID-Verfahren diskutiert.

Die Bundesdruckerei ist eine GmbH in Staatsbesitz, also ein gewinnorientiertes Unternehmen. Sie handelt somit nach wirtschaftlichen Kriterien; Behörden sind entsprechend Kunden der Firma. Die Bundesdruckerei bedient auch ausländische Kunden. Die Bundesdruckerei-Gruppe umfasst neben der eigentlichen Bundesdruckerei GmbH noch weitere Firmen, unter anderem auch die Zertifizierungsstelle D-Trust.

Die Bundesdruckerei sieht in eID eine große und für die Zukunft auch extrem wichtige Chance. Die sichere Authentifizierung im Internet ist ein wichtiges Problem, welches der ePerso löst. Die Sicherheitsprobleme, die sich im Umfeld der eID-Anwendung (hauptsächlich AusweisApp) finden, seien lösbar und daher kein Argument gegen die eID-Lösung. (Ich bin da eher der Meinung, dass die Sicherheitsprobleme mit der Zeit mehr werden, da mit der Zeit attraktive, aber unsichere Nutzungsweisen eingeführt werden. Beispielsweise ist geplant, den ePerso auch an Automaten einzusetzen, was weitere erhebliche und prinzipbedingte Gefahren birgt.)

Die Bundesdruckerei ist ein wenig enttäuscht darüber, dass wir als moderne Technikpartei den ePerso so vehement ablehnen, und dass die Diskussion teilweise unsachlich geführt wird.

eID biete große Vorteile für Bürger und Unternehmen. Beispielsweise könnte man mit eID Konten online eröffnen, ohne zwecks Postident zur Post rennen zu müssen. Das sehe ich übrigens genauso – bin aber der Meinung, dass sich das mit normalen Signaturkarten gut machen lässt.

Wir haben daher auch darüber gesprochen, warum auf eine neue Technik (das eID-Verfahren) statt auf das gewöhnliche, alte Signaturverfahren gesetzt wurde. Diese Vorgaben kamen vom BSI bzw. BMI. Die Bundesdruckerei war zwar beratend tätig, die Kernentscheidungen wurden aber von BSI/BMI getroffen. Die von mir geäußerte Vermutung, dass auch wirtschaftliche Interessen (der Wunsch nach einem neuen, international exportierbaren Standard) bei den Designentscheidungen eine Rolle gespielt haben könnten, wurde entschieden verneint – das BSI würde sowas nicht mit berücksichtigen. Es kann natürlich auch sein, dass das BSI einfach eine eigene Technologie haben wollte.

Die eID-Technologie hat gegenüber von gewöhnlichen Signaturkarten einige Vorteile. Beispielsweise weist sich nicht nur der Ausweisinhaber gegenüber einer Website (dem Diensteanbieter) aus, sondern es findet eine beidseitige Authentifizierung statt. Nur Diensteanbieter, die zertifiziert sind, auf geeigneten Datenschutz geprüft wurden, die Daten auch wirklich benötigen, vertrauenswürdig sind etc. bekommen ein Berechtigungszertifikat, was zum Auslesen des elektronischen Personalausweises nötig ist. Gleichzeitig dürfen sie nur die Daten auslesen, die sie benötigen, und der Nutzer kann Daten einzeln freigeben. Das wäre mit gewöhnlichen Signaturkarten nur eingeschränkt möglich.

Weiterhin gibt es die Möglichkeit, z. B. anonym das Alter zu beweisen oder sich mit einem karten- und seitenspezifischen Pseudonym zu identifizieren. Das ist in der Tat eine Funktion, die mit Signaturkarten gar nicht geht. Die Pseudonyme gehen allerdings verloren, wenn man einen neuen Ausweis bekommt, was die Nutzbarkeit einschränkt. (Das ist eine -meiner Meinung nach korrekt getroffene- Designentscheidung.)

Ich konnte bei dem Gespräch auch einige Fragen zum Thema klären.

Die Personalausweise enthalten bei der Ausgabe keine Signaturzertifikate – um die sichere und sinnvolle Signaturfunktion zu nutzen, muss der Bürger sich neben einem teuren Lesegerät also noch ein solches Zertifikat kaufen, was ihn ca. 40 EUR pro Gültigkeitsjahr kostet. Technisch wäre es kein Problem, die Zertifikate von vorne herein aufzuspielen, und die zur Bundesdruckerei-Gruppe gehörende D-Trust GmbH kann solche Zertifikate ausstellen. Die Entscheidung, die Zertifikate nicht mit aufzuspielen, war eine politische Entscheidung, von der die Leute von der Bundesdruckerei auch nicht wirklich begeistert sind. Ein Argument für diese Entscheidung, was mir an anderer Stelle genannt wurde, war, dass das ja ein Eingriff in den freien Markt wäre und deswegen nicht gemacht wurde. Leider hat das zur Folge, dass eine der wirklich guten Funktionen des Ausweises für die Bürger nur mit zusätzlichem Aufwand und Kosten erreichbar ist.

Die Entscheidung, auf drahtlose Technik (NFC/RFID) statt normale kontaktbehaftete Technik zu setzen, hat mehrere Gründe. Einmal die Haltbarkeit, die Tests zufolge deutlich besser sein soll – auch gegenüber mechanischen Belastungen wie „10 Jahre lang in der Hosentasche rumtragen“ und die damit verbundenen Biege-Belastungen. Die Karten sollten also die 10 Jahre durchhalten. Zudem haben moderne Handies zum Teil NFC, aber keine kontaktbehafteten Schnittstellen. Mit einer kontaktbehafteten Karte wären mobile Nutzungen so ausgeschlossen, deswegen wurde NFC als Technologie der Zukunft gewählt. Weiterhin soll der ePerso kompatibel mit den elektronischen Reisepässen sein, die kontaktlos gelesen werden.

Es ist davon auszugehen, dass die Lesereichweite von wenigen Zentimetern sich nicht deutlich ausweiten lässt. Für „dumme“ Karten existieren zwar Experimente, die mit großen Antennen eine Ausweitung auf rund 25 cm hinbekommen. Der ePerso-Chip ist aber deutlich komplexer und hat damit einen höheren Stromverbrauch. Daher sei es unwahrscheinlich, dass man aus 10 cm eine benutzbare Verbindung hinbekommt, die auch stabil bleibt, wenn das eID-Verfahren anläuft und die Kryptoprozessoren anfangen Strom zu ziehen. Die MARS-Studie des BSI, auf die ich hingewiesen wurde, ist leider noch nicht abgeschlossen, dürfte dazu aber weitere Erkenntnisse bringen.

Zum Thema RFID-Fingerprinting hatte die Bundesdruckerei leider auch keine weiterführenden Informationen.

Für die pseudonyme Identifikationsfunktion haben zahlreiche Personalausweise den gleichen privaten Schlüssel („Generationenschlüssel“). Dieser Schlüssel ist in jedem Ausweischip gespeichert und verlässt den Chip nicht. Würde es jemand schaffen, den Schlüssel auszulesen (z. B. über Seitenkanalangriffe oder Öffnen des Chips mittels FIB), wäre das ein ziemliches Sicherheitsproblem. Die Chips sind natürlich gegen solche Angriffe gesichert – aber eine Garantie dafür, dass das 10 Jahre lang hält, trauen sich auch die Hersteller der Chips nicht abzugeben. (Die Chips stellt die Bundesdruckerei nicht selbst her, sondern kauft sie von externen Herstellern ein.) Die genauen Folgen, die ein solcher Angriff hätte, sind noch nicht ganz klar. Es gibt eine Möglichkeit, auf einen zweiten, chipindividuellen Schlüssel zurückzugreifen. Das zerstört die Anonymität bzw. starke Pseudonymität, löst aber das Sicherheitsproblem. Weiterhin sollen die unveränderlichen Daten abweichend von dem was in der TR 3127 des BSI  steht (S. 14 oben) mittels eIDSecurityInfo gemäß BSI-TR 3110 A.1.1.6 signiert sein. Das dürfte viele Angriffe verhindern, selbst wenn die Schlüssel leaken. (Möglicherweise sind diese Signaturen auch erst dann abrufbar, wenn die chipindividuellen Schlüssel freigeschaltet werden.)

Das Nachladen von Zertifikaten für die Qualifizierte Elektronische Signatur erfordert derzeit einen Medienbruch (Aktivierungscode per Post). Das ist gut, könnte sich aber noch ändern. Eine starke Sitzungsbindung an den Ausweis soll beim Nachladen vorhanden sein (das ist gut).

FAZIT
Ich bin immer noch kein Freund von ePerso und eID. Die eID-Funktion kann meiner Meinung nach nicht das Sicherheitsniveau bieten, auf welches viele vertrauen. Die millionenfach verteilten Basisleser sind unsicher, und die neuen Anwendungsszenarien sorgen für weitere Gefahren. Durch diesen Widerspruch zwischen angenommenem und tatsächlichem Sicherheitsniveau ergeben sich Gefahren für den Bürger – wenn er einem Angriff auf eID zum Opfer fällt, steht er einer erdrückenden Beweislast des „sicheren“ Systems gegenüber, die er wiederlegen muss (und nicht kann).

Eine elektronische Identifikationsfunktion im Internet halte ich für sinnvoll – zumindest solange man davon ausgehen kann, dass Bundestag und BVerfG die diversen Unionspolitiker unter Kontrolle halten können, die dann wieder ihre Idee mit dem Realnamenzwang im Internet aufwärmen. Die zusätzlichen Funktionen von eID sind aber meiner Meinung nach nicht nützlich genug, um die Inkompatibilität und Sicherheitsprobleme in Kauf zu nehmen. Die wechselseitige Authentifizierung mittels Berechtigungszertifikat des Diensteanbieters wird eher eine bürokratische und teure Hürde sein, als ein nützliches Feature.

Den Verdacht, dass es sich beim ePerso (auch) um eine Wirtschaftsförderungsmaßnahme handelt und dieser Aspekt oft zu stark in den Vordergrund gerückt ist, werde ich trotz der gegenteiligen Beteuerungen leider auch nicht ganz los.

Elektronisch auslesbare Ausweisdokumente (Perso und Pass) laden außerdem zu zusätzlicher automatisierter Datensammlung und mehr (z. B. auch automatisierten) Kontrollen ein.

Daher bin ich weiterhin der Meinung: Den neuen Perso in Zukunft ohne Chip ausgeben, und davon getrennte, ggf. staatlich geförderte und vorzugsweise kontaktbehaftete Signaturkarten ausgeben, die auf bewährten internationalen Standards basieren. Die QES-Infrastruktur ist bereits teilweise vorhanden, und da sie auf bewährte Standards setzt, ist die Technik auch für Betreiber leicht einzurichten. Entsprechende signaturfähige Lesegeräte (Sicherheitsklasse 3) für kontaktbehaftete Signaturkarten sind für knapp 36 EUR inkl. Versand zu bekommen, die vergleichbaren Komfortleser beim ePerso kosten ab rund 100 EUR aufwärts. (Einen Standardleser mit Display, mit dem man nicht mittels ePerso signieren, aber eID halbwegs sicher nutzen kann, bekommt man schon ab rund 55 EUR. Mit einer normalen Signaturkarte kann dieser Leser übrigens signieren!)

Android: Löschfunktion löscht nicht richtig

(For english version, see the post on the Hatforce site)

Für einen Hatforce-Test musste ich ein gebrauchtes Android-Handy zurücksetzen, um die privaten Daten zu löschen, bevor ich mit dem Test loslege. Dafür hat Android eine eingebaute Löschfunktion: „Factory Data Reset“ oder auf deutsch „Auf Werkszustand zurücksetzen“. Zahlreiche Webseiten empfehlen, diese zu nutzen, bevor man das Gerät verkauft – wie ich feststellen musste, löscht diese aber nicht immer zuverlässig.

Vorher dem Löschen wollte ich natürlich meine Daten sichern, und zwar auf meinem PC und nicht bei Google. Das geht mit Titanium Backup relativ einfach (führt aber zu Gefahren!), dafür braucht man allerdings root-Rechte auf dem Gerät. Um die auf dem offiziellen Weg zu bekommen, muss man den Bootloader entsperren – und dabei werden die Daten gelöscht. Mittels des zergRush-Exploits geht das aber auch ohne Datenverlust. Im Anschluss hat man vollen Zugriff auf das Gerät.

Nachdem ich meine Daten gesichert und das Gerät mit der oben genannten Funktion gelöscht hatte, habe ich die Gelegenheit genutzt und getestet, ob die Löschfunktion sauber funktioniert. Mit

cat /dev/block/platform/s3c-sdhci.0/by-name/userdata | strings

habe ich die Rohdaten des Speichers ausgelesen und mir lesbare Zeichenketten anzeigen lassen – und siehe da, jede Menge persönlicher Daten! Mittels netcat lässt sich die Rohversion des Speichers auf den PC übertragen und dort in Ruhe mit photorec und ähnlichen Tools bearbeiten, um noch mehr (wie z. B. Fotos) zu Tage zu fördern.

Zumindest auf dem Samsung/Google Nexus S mit Android 2.3.6 taugt die eingebaute Löschfunktion also nichts. Mit geringem Aufwand und öffentlich verfügbaren Tools können große Teil der Daten, wie Fotos und evtl. auch Passwörter, wiederhergestellt werden. Auch das Löschen über das versteckte Recovery-Menü hat nichts gebracht. Beim Unlocken des Bootloaders hingegen wurde der Speicher genullt, sodass nichts mehr wiederherstellbar war. Ab Android 3.0 scheint das Problem laut Sourcecode behoben zu sein, getestet habe ich es aber mangels Testgerät nicht. (95% der Geräte laufen aber derzeit auf älteren Versionen.) Ob/welche anderen Geräte betroffen sind oder ob die Hersteller Anpassungen gemacht haben, um das Problem zu beheben, weiß ich natürlich nicht.

Da man das Gerät auch nach einem Wipe rooten und die Daten wiederherstellen kann, betrifft das auch Geräte, die in gesperrtem Zustand verloren werden. Zunächst kommt der Finder/Dieb nicht an die Daten heran (weil er das Gerät nicht entsperren kann, und damit weder den USB-Speicher noch das für das Rooten nötige USB-Debugging einschalten kann). Wenn er es aber über den Recovery-Modus löscht, wird die Sperre ebenfalls entfernt, und er kann die Daten wiederherstellen. Ob das Gerät vorher gerootet war, spielt dementsprechend keine Rolle.

Wenn ich ein Android-Gerät verkaufen müsste, würde ich es vermutlich wipen, die Partitionen (inkl. Datenpartition) über eine Rootshell mit Datenmüll vollschreiben, und es wieder wipen. Wie das System darauf reagiert, wenn man die Blockdevices direkt überschriebt (was eigentlich besser wäre), habe ich lieber nicht ausprobiert.

(Auf Englisch ist es etwas ausführlicher im Hatforce-Blogeintrag erklärt.)

Android: Apps können nicht nur Fotos lesen (TitaniumBackup-User aufgepasst!)

Vor einigen Tagen wurde in der Presse berichtet, dass Android-Apps ohne besondere Berechtigungen auf die Fotos des Nutzers zugreifen können. Da ich mich gewundert habe, warum es nur die Fotos betreffen soll, hab ich mal genauer nachgeschaut. Apps können nicht nur „Fotos“ lesen. Apps können, ohne dafür irgendwelche Berechtigungen anfordern zu müssen, den Inhalt des USB-Speichers (/sdcard/) lesen – nur für das Schreiben wird eine Berechtigung gefordert. Das ist laut Android Security Team übrigens kein Bug, soondern ein gut dokumentiertes Feature. Glücklicherweise ist trotzdem geplant, dafür eine Permission einzuführen.

Das bedeutet übrigens, dass derzeit jedes werbefinanzierte Spiel (welches wegen der Werbung immer Internet-Permissions hat), genug Rechte hat, um den gesamten Inhalt des USB-Speichers über das Internet zu verschicken. Das wird insbesondere dann ein großes Problem, wenn man dort z. B. mittels TitaniumBackup auch Backups der App-Daten (die normalerweise vor Zugriff geschützt sind) ablegt.

Nochmal: Wenn man Titanium Backup nutzt, legt man seine App-Daten in einen Ordner, der von jeder App gelesen werden kann!

Ich hab in meinem Handy keine externe SD-Karte, deswegen kann ich nicht prüfen, ob es schwieriger ist, auf dort (/sdcard/external_sd) gespeicherte Daten zuzugreifen, ich glaube aber, dass es damit genauso aussieht.

Ein „chmod 770 /mnt/sdcard/“ funktioniert auf meinem (gerooteten) Galaxy Nexus übrigens nicht. Vermutlich müsste man den Speicher dafür irgendwie mit rootmode=770 remounten. Wenn das überhaupt klappt, dürfte mit Nebenwirkungen zu rechnen sein – Experimentieren auf eigene Gefahr!

In den nächsten Tagen wird es hier noch 1-2 weitere Postings zur Android-Sicherheit geben – während eines Sicherheitstests für Hatforce sind mir nämlich noch andere Dinge aufgefallen.

Massenüberwachung des Internets dürfte ein Fakt sein

Eine Firma hat laut Golem ein Storage-System gebaut, was 10.000.000 Terabyte (!) speichern kann. Wir reden hier nebenbei von ca. 5 Mio. Festplatten nach Angaben der Firma. Der wirklich interessante Teil sind aber folgende Aussagen:

Angesichts des steigenden Internettraffics geht Cleversafe davon aus, dass es 2015 Unternehmen geben wird, die Datenmengen von 80 Exabyte pro Monat analysieren müssen.

sowie der Schlusssatz

Zu den Investoren von Cleversafe gehört unter anderem auch die CIA-Tochter In-Q-Tel.

Im Prinzip steht da unverblümt, dass es „Unternehmen“ gibt, die Internettraffic in großen Massen analysieren. Cisco prognostiziert, dass Ende 2015 der Internettraffic pro Monat *trommelwirbel* 80 Exabyte betragen wird. Es deutet also vieles darauf hin, dass die CIA sämtlichen Traffic global überwacht oder überwachen will, und sich nicht mal sonderlich bemüht, das geheimzuhalten.

Das massiv geschnüffelt wird, ist seit ECHELON eigentlich öffentlich und unbestritten bekannt, auch wenn man es immer wieder gerne verdrängt. Dieses Ausmaß könnte aber vielleicht doch überraschen.

Gleichzeitig gibt es eine Firma namens D-Wave Systems, die behauptet, einen 128-Qbit-Quantencomputer kommerziell anzubieten. Die Behauptung ist natürlich kontrovers und kann durchaus sein, dass es sich dabei um einen Fake handelt. Wären aber derartige Quantencomputer tatsächlich auf dem zivilen Markt erhältlich, wäre meiner Meinung nach davon auszugehen, dass Geheimdienste bereits jetzt leistungsfähige Quantencomputer mit genug Qbits haben, um gängige Schlüssellängen bei RSA und Diffie-Hellman zu brechen. Damit dürften alle gängigen Verbindungen, die asymmetrische Kryptographie nutzen, inklusive solcher, die eigentlich Perfect Forward Secrecy haben, gebrochen sein, auch rückwirkend bezogen auf den in der Vergangenheit gesammelten Traffic.

Als Sahnehäubchen könnte man jetzt noch die Fortschritte bei der Spracherkennungstechnologie nennen, die bereits im zivilen Bereich Transkripte von Anrufbeantworternachrichten erstellt. Das kann man natürlich auch wunderbar verwenden, um Transkripte von abgehörten Gesprächen zu erstellen und sie so maschinenlesbar zu machen.

Schöne neue Welt, nicht?

Schlechte Nachrichten für Bürgerrechte

Leider bin ich nicht direkt dazu gekommen, diese Zusammenfassung zu schreiben, aber vielleicht ist es ja auch besser, diese „tollen“ Beschlüsse unserer Regierung mal gesammelt zu sehen, nachdem man sie schon vergessen wollte. Um den folgenden Mist zu beschließen, haben die Parlamente übrigens nur zwei Tage (27. und 28.10.) gebraucht.

Fangen wir an mit dem Beschluss, dass das Erststudium nicht als Werbungskosten absetzbar ist. Über den Sinn dieser Änderung kann man sich streiten, aber der wirkliche Hammer kommt zum Schluss: Um die armen Besserverdiener unter den Studierenden nicht zu überlasten, können z. B. teure Privatunis jetzt besser abgesetzt werden. Unsere Regierung kann wohl nichts beschließen, ohne der FDP-Klientel noch ein paar Geschenke mit einzupacken.

Weiter gehts mit dem „Schuldenschnitt“ für Griechenland. Statt einem wirklichen Schuldenschnitt (ein Teil der Schulden verfällt) sollen die (wertlosen) Griechenland-Anleihen zu 50% des Nennwerts (also deutlich über dem tatsächlichen Wert) in europäische oder von der EU garantierte Anleihen umgetauscht werden. Statt einem Schuldenschnitt gibt es also auch hier Geschenke, diesmal vor allem für die Banken.

Dafür wollte unsere Regierung auch mal was dem Volk schenken, zum Beispiel kostenlose Warteschleifen und ein Ende des Abofallenbetrugs im Internet. In der entsprechenden Reform des Telekommunikationsgesetzes hat sie leider „vergessen“, Breitband-Internet zum Universaldienst zu machen (womit die Anbieter wie bei Trinkwasser und Telefon verpflichtet wären, es überall bereit zu stellen). Auch die Netzneutralität, die eigentlich in die Reform rein sollte, ist wohl nicht so ganz verankert worden. Dafür wurde in dem netten Paket mal eben die Vorratsdatenspeicherung versteckt – und zwar in letzter Sekunde und dann schnell beschlossen, damit das Parlament ja nicht merkt, worüber es gerade abstimmt.Zwar ist die neue Vorratsdatenspeicherung nicht verpflichtend, aber dafür dürfen die Provider jetzt freiwillig speichern. Angesichts dessen, dass viele das schon bisher (illegal!) getan haben, dürfte sich ein großer Datenberg ansammeln, aus dem sich die Ermittlungsbehörden bedienen können. Somit hat die Regierung zwar mal wieder „Für unsere Bürger“ auf das Paket draufgeschrieben, mit dem Inhalt spielen werden aber vor allem die Ermittlungsbehörden. Einige populäre Verbesserungen beim Verbraucherschutz (die durchaus dringend nötig waren!) hat die Regierung aber doch reingepackt – vermutlich, um es dem Bundesrat schwerer zu machen, das Gesamtpaket abzulehnen. Der Bundesrat ist nämlich fest in der Hand der Opposition, und dort muss das Gesetz noch durch. Hier ist die Hoffnung also noch nicht ganz verloren – auch wenn man davon ausgehen kann, dass die Verräterpartei ihrem Namen wieder gerecht wird, obwohl sie im Bundestag dagegen gestimmt hat.

Aber wo wir bei Überwachungsgeschenken sind: Die Linke hat beantragt, jemandem etwas wegzunehmen. Nämlich der Polizei das Recht, den Bundestrojaner zu nutzen, nachdem diese gezeigt hat, wie „verantwortungsvoll“ sie damit umgehen kann (zur Erinnerung). Dass der Antrag gegen die Stimmen von Union und FDP keine Chance hat, war klar. Dennoch konnte die SPD (als Oppositionspartei!) sich nicht nehmen lassen, gegen den Antrag und somit für den Bundestrojaner zu stimmen. Würde jeder Missbrauch eines Überwachungsrechts dazu führen, dass es eingeschränkt oder zurückgenommen wird, würden die Ermittlungsbehörden vielleicht lernen, damit verantwortungsvoller umzugehen. Schade, dass diese Chance, hier den Anfang zu machen, verpasst wurde.

Stattdessen hat die Bundesregierung lieber mal die Anti-Terror-Gesetze verlängert – und nebenbei noch ein wenig verschärft, indem sie z. B. Geheimdiensten die „Selbstbedienung“ an den Flugreisedaten erlaubt haben. Auch hier hat die SPD sich wieder einmal als Verräterpartei betätigt und trotz Oppositionsrolle gegen Bürgerrechte und für die Verlängerung gestimmt. Ach, und wo wir schon bei „Anti-Terror“ sind, hier noch ein alter, aber guter Artikel von heise/c’t zur Anti-Terror-Datenbank, wo man sieht, was da so alles gespeichert wird. Die Lobby, die dafür sorgt, dass solche „Sicherheits“gesetze produziert werden, hat übrigens Jörg Tauss für Gulli aufgedeckt.

Das Europäische Parlament hat sich natürlich nicht lumpen lassen und gleichzeitig ein Abkommen beschlossen, nach dem Australien die Flugreisedaten erhält und fünfeinhalb Jahre speichern darf. Mit 463 zu 96 Stimmen übrigens, falls noch irgendwelche Hoffnungen bestanden, das EU-Parlament würde sich für Datenschutz und Bürgerrechte einsetzen. Die übermittelten Daten enthalten unter anderem Kreditkarten- und Telefonnummern, IP-Adressen und besondere Essenswünsche (aus denen vermutlich auf die Religion geschlossen werden soll, die nicht explizit übermittelt wird). Auch ein nettes Geschenkpaket, oder?

Das einzig halbwegs Erfreuliche waren die Nachrichten über den ePerso ein paar Tage später. Schade um die verschwendeten Steuergelder, aber gut für die Bürgerrechte – wie erwartet folgte der ePerso dem Schicksal der meisten IT-Großprojekte von Bundesregierungen und wurde ein grandioser Fehlschlag: Sicherheitslücken ohne Ende, kaum Angebote, kaum Nutzer bei bestehenden Angeboten, nicht einmal die Hälfte der Ausweise mit aktiver eID-Funktion – aber leider auch schon wieder Ideen, wie man den Perso z. B. mit einer DNA-Datenbank „verbessern“ könnte.

Oft übersehene Lügen zum Bundestrojaner

In der derzeitigen Debatte zum Bundestrojaner werden ein paar Dinge oft von der Presse übersehen und von den Verantwortlichen falsch dargestellt. Die zwei Wichtigsten nehme ich hier mal auseinander (Liste wird ggf. noch ergänzt):

Behauptung:
„Beim Einsatz der Trojaner wurden alle rechtlichen Vorgaben eingehalten“

GELOGEN In Bayern hat einer der Trojaner Screenshots angefertigt. Das war nach rechtskräftigem Beschluss des Landgerichts rechtswidrig. Illegal, verboten, gegen die gesetzlichen Vorgaben verstoßend. Unbestreitbar, ohne wenn und aber. Die (leider von der Presse oft übernommene) Behauptung, die rechtlichen Vorgaben seien eingehalten worden, ist also eine dreiste Lüge. Konkret hatte das Bayrische Innenministerium behauptet:

Nach der Entscheidung des Bundesverfassungsgerichts zur Online-Durchsuchung 2008 ist eine Quellen-TKÜ zulässig, wenn sich die Überwachung ausschließlich auf Daten aus einem laufenden Telekommunikationsvorgang beschränkt und dies durch technische Vorkehrungen und rechtliche Vorgaben sichergestellt wird. Nichts anderes ist in Bayern bisher praktiziert worden.

Auf Unwissenheit wird man sich hier angesichts der Bekanntheit des Urteils kaum berufen können.

Behauptung:
„Trojaner werden nur zur Verfolgung schwerer Straftaten wie Terrorismus verwendet“

GELOGEN In den bekannten Fällen handelt es sich einmal um Drogenhandel, einmal um möglicherweise nach Betäubungsmittelgesetz illegale Ausfuhr von zugelassenen Medikamenten und einmal um Diebstahl, siehe Fefe.

Noch Ärgerlicher ist allerdings, dass die Gelegenheit genutzt wird, Forderungen nach mehr (!) Überwachungsbefugnissen zu stellen. Die GDP (Gewerkschaft der Polizei, nicht zu verwechseln mit der DPolG oder dem BDK) fordert einen „sauberen rechtlichen Rahmen“, will also ein Gesetz, was die Überwachung erlaubt.

Wenn jemand gegen ein Gesetz verstößt, dann ist die richtige Reaktion darauf in der Regel, ihn in den Knast zu stecken, und nicht, den Gesetzesbruch zu legalisieren! Wenn Vertrauen und bestehende Privilegien missbraucht werden, dann gehören diese Privilegien entzogen, nicht ausgeweitet.

Meiner Meinung nach müssten:

• Sämtliche Verantwortlichen (und nicht nur ein paar Bauernopfer) zur Rechenschaft gezogen werden. Das beinhaltet insbesondere eine Entlassung und Strafverfahren, und wir reden hier sicher von Dutzenden von Verantwortlichen.
• Die Überwachungsbefugnisse der Behörden massiv zusammengestrichen werden. Nicht nur muss die Verwendung von Spionagesoftware unmissverständlich untersagt werden, auch die sonstigen Befugnisse dürfen nicht unangetastet bleiben. Der Richtervorbehalt muss gestärkt werden, eine ausführliche Begründung sollte Pflicht werden. Wenn Richter pro Fall erstmal 1-2 Seiten individuelle, nicht aus Textbausteinen bestehende Begründung selbst abfassen müssten, wäre schon viel gegen ausufernde Überwachung ohne richtige Prüfung getan. Wenn der Richter überlastet ist, bleiben die Anträge halt so lange liegen, bis die Behörden gelernt haben, die Maßnahmen nur in Fällen anzuwenden, wo sie wirklich nötig sind.
• Sämtliche Überwachungsmaßnahmen nachträglich geprüft und bei Verstößen sofort empfindliche Strafen verhängt werden.

Wird natürlich nicht passieren, solange die CDU an der Regierung ist. Vermutlich wird es vielmehr ein Alibi-Gesetz geben, was 1-2 Überwachungsbefugnisse reduziert und dafür an anderer Stelle zahlreiche andere ausweitet, und vielleicht müssen 1-2 Leute mit großzügigen Pensionen gehen, natürlich ohne Strafverfolgung befürchten zu müssen.

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.

Argumente gegen (Anti-)Terrorgesetze

Auf einer Mailingliste innerhalb der Piratenpartei wurde vor kurzem über allgemeine Argumente gegen neue bürgerrechtsfeindliche (Anti-)Terrorgesetze diskutiert. Meinen Beitrag möchte ich auch hier etwas breiter publizieren:

Verhältnismäßigkeit

Auch wenn dies zweifelslos die Zahl der Verkehrstoten reduzieren würde, käme niemand auf die Idee, deutschlandweit eine Geschwindigkeitsbegrenzung auf 30 km/h einzuführen – denn das wäre völlig überzogen, die Schäden, die daraus resultieren würden, stehen in keinem Verhältnis.

Bei Anti-Terror-Maßnahmen, deren Wirkung im Vergleich zum Tempolimit überdies zweifelhaft ist, wird diese Abwägung leider gerne übersehen. Selbst wenn diese Maßnahmen tatsächlich Terroranschläge verhindern könnten, stehen die damit verbundenen Schäden, die an unserer Freiheit, an unseren Grundwerten entstehen, in keinem Verhältnis dazu.

Leider sind Einschränkungen der Bürgerrechte nicht so direkt spürbar, wie ein Tempolimit – doch wenn wir nach und nach unsere Bürgerrechte aufgeben, zerstören wir unsere freiheitliche Gesellschaft. Wir würden genau das tun, was die Terroristen möchten, aber mit ihren Bombenanschlägen ohne unsere ‚Hilfe‘ nie erreichen würden.

Zum Vergleich sollte man sich vor Augen führen, dass wir trotz 50.000 Toten im deutschen Straßenverkehr von 2001 bis 2010 nicht in blinden Aktionismus verfallen. Genau wie wir uns im Straßenverkehr auf sinnvolle und zurückhaltende Sicherheitsmaßnahmen beschränken, müssen wir dies auch bei der Bekämpfung von Terrorismus tun.

Genausowenig, wie wir auch auf diese riesige Anzahl Verkehrstoter mit einem Verbot des Straßenverkehrs oder einer bundesweiten Tempo-30-Zone reagieren, dürfen wir auf die bloße Gefahr von Terroranschlägen mit überzogenen Maßnahmen wie der Überwachung aller Bürger reagieren.

Terroristen können bloß töten. Nur überreagierende Politiker können unsere Gesellschaft zerstören. Von ihnen geht die wirkliche Gefahr aus – und gegen diese Gefahr wenden wir uns.

(Siehe auch dieser Beitrag von „Nano“)

Ursachen

Wir könnten auch aufhören, uns in jeden internationalen Konflikt einzumischen. Damit dürfte die Terrorgefahr deutlich stärker sinken, als durch die Einführung irgendwelcher Terrorgesetze. Ganz verschwinden wird sie jedoch nie – genauso, wie man selbst mit den strengsten Gesetzen nie alle Anschläge verhindern können wird.

Selbstverständlich ist es wünschenswert, die Freiheit von Menschen in anderen Ländern zu schützen und zu fördern. Wir dürfen aber nicht zulassen, dass die Folgen dieser Einsätze unsere eigene Freiheit gefährden. Solange die einzige Antwort, die wir auf eine leicht gesteigerte, abstrakte Terrorgefahr kennen, ein drastischer Abbau unserer Bürgerrechte ist, können wir uns solche Einsätze einfach nicht leisten.

Wirkungen und Nebenwirkungen

„Herr Nachbar, was machen Sie da in ihrem Garten?“
„Ich streue Pulver gegen Elefanten.“
„Aber hier gibt es doch gar keine Elefanten!“
„Na dann sehen Sie mal, wie das Pulver wirkt!“

Genauso wie der Nachbar sein Elefantenpulver streuen Innenminister gerne (Anti-)Terrorgesetze, deren Wirkung recht zweifelhaft ist. Wenn es dann gar keine Terroranschläge gibt, wird das als Zeichen gewertet, dass die Gesetze wirken, und man ganz dringend noch mehr davon braucht. Über Nebenwirkungen, wie den Abbau unserer Freiheitsrechte, macht man sich hierbei keine Gedanken.

Die wenigen versuchten Terroranschläge, die es in Deutschland gab, hatten meist von vorne herein wenig Aussicht auf Erfolg – und wurden meist nicht mit Hilfe der neuen Befugnisse aus den Terrorgesetzen aufgedeckt, sondern durch andere Mittel.

Die Mittel aus den Terrorgesetzen hingegen werden immer wieder eingesetzt, um unschuldige Bürger auszuspähen – wie man am zum Beispiel Handydatenskandal in Dresden sehen konnte.

Der Begriff „Antiterrorgesetze“ wurde in den Medien ab und zu als „Terrorgesetze“ abgekürzt. Eines Tages fiel jemandem auf, dass diese Bezeichnung eigentlich viel passender ist, weil erst diese Gesetze die eigentliche Wirkung des Terrors entfalten und sie durch die Einschränkungen der Bürgerrechte die Bevölkerung terrorisieren. Daher steht auch bei mir das „Anti“ in Klammern (und manchmal gar nicht) da.

Probleme bei BitCoin – gesellschaftstheoretisch und technisch

Das komplett dezentrale auf kryptographie basierende Zahlungssystem BitCoin hat es in letzter Zeit zu einiger Berühmtheit gebracht. Das Konzept werde ich hier nicht nochmal erklären, das ist z. B. in der Wikipedia nachzulesen.

Die für diese Betrachtung relevanten Haupteigenschaften von Bitcoin sind:

• Das System ist dezentral und völlig unkontrollierbar
• Zahlungen sind nicht umkehrbar
• Neues Geld wird (beschränkt) ständig erstellt und anteilig nach beteiligter Rechenleistung an die aktiven Teilnehmer verteilt

Die Unkontrollierbarkeit wird als Vorteil gesehen – kein Staat kann willkürlich Konten oder Guthaben einfrieren, auch kann kein Staat einfach so Geld drucken. Bitcoins verhalten sich in einigen Aspekten wie Bargeld – insbesondere sind sie weg, wenn sie mal gestohlen werden.

Gesellschaftstheoretisch

Die Unkontrollierbarkeit kann gesellschaftstheoretisch aber auch als Problem gesehen werden: Anonymität und Unkontrollierbarkeit für Kommunikation und Meinungsäußerung finde ich generell gut, auch wenn sie missbraucht werden kann, einfach weil der Nutzen überwiegt und die Gefahren nicht soo groß sind. Bei der Aufklärung von Straftaten sehe ich „follow the money“ statt Kommunikationsüberwachung als guten Ansatz an. Man kann sich natürlich auf den Standpunkt stellen, dass der Staat möglichst wenig Macht haben soll, und es daher gut ist, wenn seine Macht beschränkt wird. Hier wird aber eine sehr wichtige Aufgabe des Staates übersehen: Er soll eine demokratische Kontrolle von Macht sicherstellen und wo nötig „schwache“ vor „starken“ schützen. Verurteilt ein Gericht jemanden, einem anderen z. B. eine Entschädigung für etwas zu zahlen, kann dieser es entweder tun, oder der Gerichtsvollzieher kommt und pfändet. Das – und damit die Durchsetzung des Rechts! – würde deutlich schwieriger, wenn Geld nicht mehr auf Bankkonten sondern auf verschlüsselten und redundanten USB-Sticks liegen würde.

Nimmt man dem Staat jede Macht, hat man zunächst eine Anarchie, letztlich herrschen diejenigen, die Ressourcen kontrollieren oder die Macht haben, andere Menschen unter Druck zu setzen. Mit anderen Worten: Warlords, die in der Lage sind, sich genug Söldner zu mieten und/oder genug Waffen haben. Irgendwo habe ich ein „interessantes“ Szenario gelesen – was, wenn jemand eine Plattform anbietet, wo man per Bitcoin Kopfgelder auf Personen ausschreiben kann? Oder Belohnungen für terroristische Anschläge? Das geht mit „normalem“ Geld nur sehr eingeschränkt, wäre mit Bitcoin aber anonym umsetzbar. Auch wenn reiche Menschen auch in westlichen Demokratien deutlich mehr Macht haben, bietet ein demokratischer Staat eine gewisse Kontrolle. Gibt man diese auf, hat man eine reine Plutokratie – das will man eigentlich nicht.

Die Einführung von Bitcoin als Zahlungsmittel würde den Staat nicht abschaffen, aber seine Position schwächen. Das hat auch Vorteile, man kann es befürworten, und eine abschließende Meinung dazu habe ich nicht – aber es hat eben auch Nachteile, die oft vergessen werden, und die ich daher hier nennen wollte.

Technisch

Die weiteren Probleme sind technischer Art. Das Gesamtkonzept sieht solide aus und da bisher noch keiner einen Fehler darin gefunden hat, dürfte es auch relativ solide sein. Das Geld, was einem gehört, ist über private Schlüssel gesichert – wer diese Schlüssel hat, kann es ausgeben. IT-Kriminalität wird dadurch ein ganz neues Tor geöffnet: Bisher mussten Kriminelle eine Online-Überweisung manipulieren, um ein Bankkonto leerzuräumen. Bei Bitcoin reicht ein simpler Trojaner auf dem Rechner des Opfers. Experten haben gewisse Chancen, ihre Maschinen sicher zu halten – 95% der Computernutzer dürften aber mit IT-Sicherheit hoffnungslos überfordert sein und viele handeln sich regelmäßig Schadsoftware ein. Ergänzung: Dieser Fall, wo genau das mit Bitcoins im Wert von 500.000 USD passiert sein soll, war Anlass für diesen Artikel. Ich gehe davon aus, dass der (Ex-)Besitzer in Sachen Computersicherheit noch auf jeden Fall zu den Top 10% zählt, auch wenn er sehr sehr viel falsch gemacht hat. Update: Heise über Bitcoin-Trojaner.

BitCoin basiert auf einem P2P-Netzwerk. Sollte es jemand schaffen, eine Sicherheitslücke, welche Code Execution (d.h. das Einschleusen von Malware) erlaubt, im Bitcoin-Client zu finden, kann er einen Wurm schreiben, der sich über das Bitcoin-Netz selbst verbreitet und so innerhalb kürzester Zeit alle zu dem Zeitpunkt aktiven Bitcoin-Teilnehmer gleichzeitig hacken und ihre Konten leerräumen. Aber auch wenn die Software selbst sicher sein sollte, kann ein Angreifer über das P2P-Netz herausfinden, wer alles an Bitcoin teilnimmt, inklusive deren IP-Adressen. Sollten die Systeme andere, von außen erreichbare Schwachstellen haben, kann er diese nutzen, um in die Systeme einzubrechen und die privaten Schlüssel zu stehlen – mit denen er dann die Bitcoins an sich überweisen kann.

Ein weiteres Problem ist, dass der Besitz von Bitcoins durch den (alleinigen) Besitz des privaten Schlüssels gekennzeichnet ist. Das Verfahren gilt als sicher, d.h. es ist nicht möglich diese Schlüssel zu knacken – noch. Was aber, wenn in 20 Jahren Quantencomputer existieren oder das Verfahren auf andere Art und Weise geknackt wird? Man kann Bitcoin mit ein paar Schwierigkeiten auf ein neues Verfahren migrieren, aber das muss passieren bevor das alte Verfahren angegriffen wird. Wird das Verschlüsselungsverfahren was in Bitcoin eingesetzt wird geknackt, hat der Angreifer, dem das gelungen ist, die Möglichkeit, Geld aus beliebigen Bitcoin-Konten zu überweisen, und es gibt keine Möglichkeit, Angreifer und legitimen Besitzer mehr zu unterscheiden (wie auch in anderen Fällen, wo der Angreifer den private key gestohlen hat).

Durch das Investieren von Rechenzeit („Mining“) kann man Bitcoins generieren, allerdings ist das ein Zufallsprozess – ein normaler Mensch mit einer einzelnen normalen Grafikkarte (Grafikprozessoren können die nötigen Operationen schneller ausführen als CPUs, mit CPUs rechnen ist nahezu sinnlos) dürfte sehr lange rechnen, bis er Bitcoins sieht. Daher gibt es sogenannte Mining-Pools, bei denen mehrere Menschen zugleich minen und im Erfolgsfall der Gewinn dann auf die Beteiligten aufgeteilt wird. Diese Mining-Pools konzentrieren große Mengen an Rechenleistung. Das ist insofern ein Problem, als dass die Sicherheit des Netzes darauf basiert, dass die Mehrheit der beteiligten Rechenleistung von ehrlichen Teilnehmern kontrolliert wird. Die Pools kontrollieren jeweils über ihre Teilnehmer sehr viel Rechenleistung, und die einzelnen Teilnehmer können nicht (direkt) prüfen, ob der Pool „ehrlich“ arbeitet. Falls einer der großen Pools die Mehrheit der Rechenleistung kontrolliert, könnte er diese missbrauchen. Soweit ich sehe ermöglicht das jedoch „nur“ das doppelte ausgeben von Bitcoins, und es dürfte laut dem Konzept von Bitcoin lohnenswerter sein, die Leistung wie vorgesehen für die Unterstützung des Netzes zu nutzen statt sie zu missbrauchen. Dieses Problem dürfte also nicht allzu groß sein. Sollte allerdings eine Lücke in den Mining-Clients gefunden werden, könnte einer der Pool-Betreiber (oder jemand, der ihn hackt!) die Kontrolle über zahlreiche beteiligte Rechner übernehmen und deren Bitcoin-Börsen plündern.

Da es Geld für Rechenleistung gibt, wird es sicherlich früher oder später Schadsoftware geben, die fremde (übernommene) Rechner benutzt, um Bitcoins zu erzeugen (falls es das nicht schon längst gibt). Wenn Firmen mit großen Rechenzentren wie Amazon, Google oder Facebook sich entscheiden würden, bei Bitcoin einzusteigen, könnten sie wohl allein mit unbenutzten Servern in kürzester Zeit (bevor der Algorithmus die Erzeugung bremst) riesige Mengen an Bitcoins erzeugen (oder das Netzwerk zerstören, wovon sie aber nichts hätten). Diese Möglichkeit könnte gerade in einem Krisenfall die Stabilität der Währung massiv gefährden.

In den Zeiten, wo das Bitcoin-Netz noch klein war, konnten einzelne Personen große Mengen an Bitcoins erzeugen – dadurch haben einige „early adopter“ unglaublich große Geldmengen, und könnten dadurch vermutlich den Kurs massiv beeinflussen. Außerdem ist Bitcoin Ziel von zahlreichen Spekulanten. Der aktuelle Wert der Bitcoins, meist definiert über den Umtauschkurs in USD bei MtGox, kann sich also sehr schnell ändern und ist soweit ich weiß vor einiger Zeit innerhalb eines Tages von 30 USD auf 15 USD gefallen.

Auch die vielgerühmte Anonymität bei Bitcoin ist keineswegs so toll, wie viele glauben – im Gegenteil: Bedingt durch die Dezentralität des Netzes sind alle Transaktionen komplett öffentlich, mit Sender, Betrag und Empfänger. Sender und Empfänger sind jedoch keine Personen, sondern Bitcoin-Konten, und es wird empfohlen, für jede Transaktion ein neues Konto anzulegen. Selbst wenn jemand dieser Empfehlung folgt – wenn ich jemandem Geld schicke, sehe ich, was er damit weiter macht und kann der Spur weiter folgen. Er kann das Geld natürlich an ein weiteres Konto überweisen, und ich weiß nicht, ob es noch ihm oder jemandem anderen gehört. Aber angenommen ich führe meine Überweisung an einen mir bekannten Empfänger X auf Konto 1 durch, und sehe, dass innerhalb von Minuten mein ganzes überwiesenes Geld auf Konto 2 geht, dort drei Tage liegen bleibt, dann ein bestimmter Betrag auf Konto 3 geht und von dort auf ein Sammelkonto 4, was wie bekannt ist einem Pornohändler gehört: Dann kann ich davon ausgehen, dass in einem Versuch, das Geld zu anonymisieren, der Empfänger X sein Geld auf ein zweites Konto (Konto 2) von sich verschoben hat, und sich später davon bei besagtem Pornohändler Pornos zu kaufen, indem er das Geld an die für ihn erstellte Bezahladresse des Händlers (Konto 3) überweist – bevor der Händler es auf sein bekanntes Hauptkonto (Konto 4) zieht. Anhand des Betrages und der Preisliste des Händlers kann ich vielleicht ja sogar sehen, was genau der Kunde gekauft hat. Anonymisierungsdienste (bzw. Geldwäschedienste) sind möglich und existieren, man kann also mit etwas Aufwand Bitcoin anonym nutzen. Bitcoin als „anonym“ zu bezeichnen ist jedoch schlicht falsch. Um die Anonymität muss man sich selbst kümmern, und dafür dürften 95% der Nutzer zu unerfahren sein, viele wissen nicht einmal, dass es eigentlich nötig ist, geschweige denn, wie es geht.

Zusammenfassung

Bitcoin ist also sowohl extrem anfällig für IT-Kriminalität und kann vor allem schlagartig zusammenbrechen, plötzlicher und heftiger als die „schlechten, instabilen, altmodischen“ Währungen und Geldsysteme. Die Halbwertszeit dürfte sogar darunter liegen. Als Zahlungssystem könnte Bitcoin, sobald sich der Wert etwas stabilisiert hat, sogar taugen, als alternatives Weltwährungssystem eher nicht. Bei einem Zusammenbruch westlicher Währungen könnte es natürlich sein, dass Menschen anfangen, es als Ersatz zu nutzen, weil man außer Naturalien nichts anderes hat (und darauf dürften auch einige der Bitcoin-Spekulanten spekulieren). Eine langfristige Lösung ist das aber nicht.

An dieser Stelle möchte ich anmerken, dass ich Bitcoin unter theoretischen Gesichtspunkten extrem gut finde: Technisch ist es eine bemerkenswerte Leistung – in einem dezentralen Netzwerk ohne zentrale vertrauenswürdige Stelle ein System mit solchen Sicherheitseigenschaften und darauf basierend ein Zahlungssystem aufzubauen, was das doppelte Ausgeben von Geld verhindert, kontrollierte Inflation beinhaltet, einen gewissen Grad an Anonymität bietet und zumindest vom Konzept her sicher ist, ist schlicht und einfach eine reife Leistung. Das Konzept ist solide und hat sogar praktische Anwendungen. Nur der darin gesetzte Hype ist übertrieben und man sollte sich davor hüten, die Probleme auszublenden und ein solches System als die ultimative Lösung für die Geldsystemproblematik anzusehen.

Einschätzung des SCHUFA-Hacks

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).

Zensus: Fragebogennummer im Adressfeld

Gerade hat mich jemand kontaktiert, der per Post einen Fragebogen zur Wohnungszählung bekommen hatte. Auf dem Antwortumschlag, in dem man das Teil zurückschicken soll, ist ein (kleiner) rechteckiger DataMatrix-2D-Barcode. Dieser kennzeichnet scheinbar nur, dass es sich um eine Werbeantwort handelt, enthält jedoch keine weiteren Daten (z. B. irgendwas, womit man Absender oder Empfänger identifizieren könnte) – er entspricht exakt dem Beispielbarcode, den die Post auf ihrer Website zu ResponsePlus in einem Beispiel zeigt. (Offiziell muss der Befragte das Porto zahlen, weil viele es aber nicht tun werden und die Zensusämter gerne den Brief trotzdem haben wollen ohne Strafporto zu zahlen, ist das Teil als Antwort gekennzeichnet – d.h. das Porto zahlt bei unfrankierten Briefen der Empfänger. Mehr dazu auch im lawblog von Udo Vetter)

Auf dem Fragebogen, der per Post verschickt wurde, steht im durch das Fenster im Umschlag sichtbare Adressfeld ein weiterer DataMatrix-Barcode, der als Freimachung dient. In dieser Freimachung kann eine Art Referenznummer/Kommentar untergebracht werden – bekannt wurde das, weil einige Banken es für eine gute Idee hielten, dort (also von außen lesbar!) die Kontonummer unterzubringen. Nachdem ich den DataMatrix-Code zugeschickt bekommen und mit bcTester dekodiert hatte, schickte ich den Inhalt des Barcodes an die Person, der der Fragebogen gehörte – und diese bestätigte mir, dass darin die Fragebogennumer kodiert ist.

Die Fragebogennummer kann somit von außen eingesehen werden, ohne den Umschlag zu öffnen. Jetzt stellt sich natürlich die Frage, ob das ein Problem darstellt, und darauf weiß ich keine Antwort. Falls jedoch die Anonymisierung der Daten über die Fragebogennummer durchgeführt wird, könnte es ein Problem sein – wenn die Daten anonymisiert werden, indem sie getrennt vom Namen unter der Fragebogennummer abgelegt werden, wäre die Zuordnung Fragebogennummer-Adresse nicht ganz unproblematisch. Solange die aber nur auf dem Umschlag steht, wäre das jetzt nicht so das Problem. Es ist aber möglich, dass die Informationen, die im Barcode stehen, auch noch bei der Post landen und dort ggf. zusammen mit der Adresse gespeichert werden. (Ob das der Fall ist, weiß ich nicht!)

Wenn also 1. die Anonymisierung über die Fragebogennummern erfolgt und 2. die Post die Informationen aus dem Barcode inkl. der dazugehörigen Adresse speichert, dann existiert eine Datenbank außerhalb der Kontrolle der Statistikämter, die eine Deanonymisierung der Zensusdaten ermöglichen würde.

Das ist also ein großes „wenn“ – es ist nicht klar, ob die Nummer in den Barcodes überhaupt ein Problem ist. Trotzdem wollte ich es hier erwähnen, vielleicht sieht jemand damit noch weitere Probleme oder findet es aus irgendeinem anderen Grund interessant. Für sich allein genommen dürfte die Fragebogennummer relativ uninteressant sein, in den Hinweisen zum Fragebogen steht:

Die Fragebogennummer enthält eine frei vergebene Ziffernfolge und ermöglicht es, den Fragebogen der betreffenden Person zuzuordnen. Darüber hinaus enthält sie eine Prüfziffer. Sie enthält aber keinerlei Informationen zu der betreffenden Person.

Warum die Nummer auf diese Art, von außen sichtbar, eingebaut ist? Einerseits kann man so unzustellbare Briefe maschinell einfacher zuordnen, ohne sie öffnen zu müssen um an den innenliegenden Barcode auf dem Fragebogen zu kommen. Andererseits kann es auch einfach sein, dass bei der Erstellung der Barcodes eine Referenznummer angegeben werden kann/soll/muss und dafür eben die Fragebogennummer genommen wurde.

Zu beachten ist: Die Fragebögen werden AFAIK nicht zentral für ganz Deutschland verschickt, d.h. es kann regionale Unterschiede geben. Bei dem Fragebogen, um den es hier geht, handelt es sich um den Bogen zur Gebäude- und Wohnungszählung, nicht um die Haushaltebefragung.

Die Barcodes kann man übrigens mit passender Software mit jedem ordentlichen Smartphone dekodieren. Wenn die Druckqualität so schlecht ist, dass eine Erkennungssoftware versagt (viele Programme scheinen generell nicht richtig zu funktionieren) kann es helfen, den Barcode vorher etwas unscharf zu rechnen (Gaussfilter). Vielen Dank an die Person, die die Barcodes zur Verfügung gestellt hat und die Idee mit dem Deanonymisierungsproblem hatte!

Volkszählung: Online-Übermittlung unsicher

Aus aktuellem Anlass (die Fragebögen sollen bald raus und jemand der einen bekommen soll hat mich kontaktiert) habe ich mir den Zensus-Kram nochmal angeschaut und mir ist eine Sache aufgefallen: Laut dem Musterfragebogen zur Haushaltsbefragung: werden die Leute, die den Fragebogen online ausfüllen wollen, auf „www.zensus2011.de“ geleitet – sollen die Seite also per unverschlüsseltem HTTP aufrufen. Das ist unsicher, und ob danach sofort eine Umleitung auf HTTPS erfolgt, ist im Fall eines aktiven Angriffs irrelevant, da die erste Anfrage über HTTP rausgeht und somit vom Angreifer manipuliert werden kann, bevor der Server überhaupt was mitbekommt und den Nutzer umleiten kann.

Um diese Art von Angriff zu demonstrieren, gibt es eine fertige Software namens „sslstrip“ von Moxie Marlinspike. Schaltet man diese in die Leitung, so fängt sie https-redirects automatisch ab, sodass der Nutzer weiter http nutzt und die Daten im Klartext über die Leitung gehen. Ich weiß nicht wie weit die Software entwickelt ist, d.h. ob sie auch in diesem Fall ohne Anpassungen funktioniert, aber in dem Moment wo die erste Anfrage unverschlüsselt rausgeht, ist der Angriff machbar.

Um Missverständnisse zu vermeiden – das bedeutet NICHT

• dass die Server gehackt wären
• dass Daten schon offen/geklaut/geleakt wären
• dass jeder mit dem Tool einfach so sämtliche Zensusdaten abgreifen kann
• dass Daten im Normalfall (d.h. ohne Angriff) unverschlüsselt verschickt würden
• dass ein rein passiver Angreifer die Daten abgreifen könnte

Ein aktiver Angreifer kann aber die Daten abfangen. Es zeigt vor allem, dass Sicherheit offenbar nicht wirklich ernstgenommen wird – die Lösung wäre einfach gewesen ein https:// auf den Zensusbogen zu schreiben und darauf hinzuweisen, dass diese Adresse exakt einzugeben ist. Nachträglich könnte man das vermutlich am Besten mit einem zusätzlichen Infoblatt noch retten, was man zusammen mit den Fragebögen austeilen könnte.

Was bedeutet „aktiver Angreifer“? Wie auch die AusweisApp-Geschichte setzt dies voraus, dass der Angreifer den Datenverkehr nicht nur abhören, sondern auch manipulieren kann. Das ist nicht trivial, aber machbar und schon vorgekommen. In der IT- und Netzwerksicherheit geht man – nicht ohne Grund – eigentlich immer von einem sogenannten Dolev-Yao-Angreifer aus, der genau diese Möglichkeiten hat. Die Zertifikate, ein ziemlich komplexer Baustein bei SSL, sind auch nicht ohne Grund da. Die verschiedenen Methoden wie sowas passieren kann müsste ich mal ausführlicher bloggen, einige wären:

• DNS-Server der Domain manipulieren (wie z. B. beim Sicherheitsdienstleister Secunia passiert)
• DNS-Server/Cache des Providers manipulieren/vergiften
• DNS-Cache des Routers manipulieren/vergiften
• Falsches kostenloses WLAN
• Angreifer im gleichen Netzwerk (WG, Firma, Schule, verseuchter PC im Haushalt), dann ARP spoofing/poisoning (oder Kontrolle über Proxy/Router)

Diese Angriffe betreffen den Nutzer auch, wenn sein Computer an sich sicher ist! Um sich zu schützen, muss man vor dem Login prüfen, dass a) HTTPS verwendet wird und b) man immer noch auf der richtigen Seite ist.

Die Zensus-Seite für das Online-Ausfüllen ist noch nicht online – ob da noch weitere peinliche Lücken auftauchen weiß ich nicht, ich hoffe nur, dass Finder sie melden oder veröffentlichen statt sie zu missbrauchen.

Eine andere unschöne Geschichte ist noch, dass beim Zensus die ausgefüllten Fragebögen wahlweise bei den Interviewern gelagert werden (siehe auch: NPD ruft Mitglieder auf, Volkszähler zu werden) oder per Post eingeschickt werden können – aber nicht immer an die statistischen Landesämter, sondern teilweise an private Firmen an die der Kram outgesourced wurde.

Zur generellen Kritik am Zensus sei noch gesagt, dass der Zensus keineswegs anonym ist und die Daten jahrelang personenbeziehbar abgelegt sein dürfen. („Hilfsmerkmale“ sind die personenbezogenen Daten)

Abgefragt (und ggf. bei den Interviewern zuhause gelagert!) werden unter anderem:

• Name, Adresse
• Geburtsdatum
• Telefonnummer
• alle Staatsangehörigkeiten
• Religionsgesellschaft (Pflichtfrage!)
• Glaubensrichtung (freiwillig – bei Islam möchte man es gerne genau wissen: sunnitisch, schiitisch oder alevitisch?)
• Zugewandert? Falls ja, wann und woher?
• Das gleiche nochmal für die Eltern!
• Exakter Beruf(z. B. „Blumenverkäuferin“, nicht „Verkäuferin“)
• Stichworte zur Tätigkeit (z. B. „Beratung, Verkauf, Verpacken von Pflanzen“)

Im Bezug auf die Datenschutzversprechen könnte auch mein Artikel über die herumliegenden Daten die gar nicht da sein sollten beim Statistischen Bundesamt interessant sein.

An dieser Stelle sei noch verwiesen auf:

• Die „Volkszählungsfibel“ des AK Zensus (Zensuskritiker) mit einem guten Überblick über den Zensus und die Kritik daran
• Die FAQ auf der offiziellen Seite

UPDATE:
Um die Angriffe zu verdeutlichen, hier ein paar Diagramme (können per Klick vergrößert werden).
Schwarze Linien zeigen unverschlüsselte Verbindungen an, blaue Linien sind HTTPS-Verbindungen (d.h. verschlüsselt und die Identität des Servers wird geprüft).

Zunächst einmal der normale Ablauf ohne Angriff:

Der Nutzer gibt die Adresse auf dem Papierfragebogen ein, sein Browser geht (unverschlüsselt) zum Server und bekommt einen HTTPS-Link auf den Online-Fragebogen. Der Nutzer klickt drauf, sein Browser holt über eine gesicherte Verbindung den Fragebogen ab, der Nutzer loggt sich ein und füllt ihn aus.

Nun ein Angriff:

Der Angreifer leitet sämtliche Verbindungen des Nutzers auf sich um.
Der Nutzer gibt die Adresse auf dem Papierfragebogen ein, sein Browser geht (unverschlüsselt) zum (falschen!) Server und bekommt eine Antwort mit einem HTTPS-Link auf einen falschen Fragebogen auf einer Domain die dem Angreifer gehört (und für die er daher ein Zertifikat hat). Beispielsweise http://www.zensus2011-befragung.de ist noch frei (die echte Seite heißt zensus2011-befragungen.de, was der normale Nutzer aber nicht wissen kann). Eventuelle Sicherheitshinweise auf der Seite mit dem Link sind natürlich auch auf den falschen Namen angepasst. Der Rest läuft wie beim normalen Zensus, nur dass der Nutzer den Fragebogen des Angreifers ausfüllt. Der kann entweder eine Kopie des echten Fragebogens sein, oder gleich noch zusätzliche Fragen enthalten.

Mit sslstrip kann man einen anderen Angriff automatisiert machen:

Das sieht erstmal komplizierter aus, ist es aber nicht, weil es weitgehend automatisch passiert. Der Nutzer bekommt hier einen http-Link auf die echte Domain, die ungesicherten Anfragen fängt der Angreifer wieder ab, leitet sie (per https, weil der echte Server keine unverschlüsselten Anfragen will) an den Server weiter und liefert die Antwort wieder an den Zensus-Teilnehmer. Dabei liest er natürlich mit, wenn der Teilnehmer den Fragebogen ausfüllt.

Statt einem HTTP-Link (der das Opfer eventuell wegen der fehlenden Verschlüsselung stören könnte) kann der Angreifer auch einen HTTPS-Link auf eine andere, eigene Domain (wie bei Angriff 1) liefern, und die an ihn gestellten Anfragen von sslstrip weiterreichen lassen.

Wenn auf dem Fragebogen die Adresse mit https stehen würde, würde es so aussehen:

Bereits die erste Anfrage geht über HTTPS, es gibt keine unverschlüsselten Anfragen! Würde der Angreifer hier angreifen wollen, würde es so aussehen:

Der Browser merkt beim Aufbau der gesicherten Verbindung, dass er nicht mit dem richtigen Server spricht, und bricht mit einer sehr deutlichen Warnmeldung an den User ab.

Die Diagramme sind übrigens mit mscgen erstellt.

Atomkraft? Sicher! [Foto/Wallpaper]

Dieses Werk von Jan Schejbal steht unter einer Creative Commons Namensnennung-NichtKommerziell-KeineBearbeitung 3.0 Deutschland Lizenz.

• Position der Piratenpartei zur Atomenergie

Wallpaper:

• 640×480
• 720×480
• 768×576
• 800×480
• 800×600
• 854×480
• 1024×768
• 1152×768
• 1280×720
• 1280×768
• 1280×800
• 1280×854
• 1280×960
• 1280×1024
• 1366×768
• 1440×900
• 1440×960
• 1400×1050
• 1600×1200
• 1680×1050
• 1920×1080
• 1920×1200
• 2048×1080
• 2048×1536
• 2560×1600
• 2560×2048

Sicheres Onlinebanking? Kostet extra!

Die Postbank schaltet das iTAN-Verfahren zugunsten „sichererer“ Verfahren ab. Das iTAN-Verfahren, also die Eingabe eines Einwegkennworts von einer gedruckten Liste, ist bei einem verseuchten Computer über einen Trojaner angreifbar, der die Überweisungsdaten verändert. Der Schritt ist also erstmal logisch, nachvollziehbar und scheint sinnvoll zu sein.

Als Ersatz werden zwei alternative Verfahren angeboten: Die mTAN, bei der eine TAN auf das Handy geschickt wird, und die chipTAN (auch smartTAN genannt), bei der die TAN von einem speziellen Gerät in Verbindung mit der Bankkarte erzeugt wird. Bei beiden Verfahren werden die Trasaktionsdetails (Betrag, Empfängerkonto, …) auf einem separaten Gerät (Handy bzw. TAN-Generator) angezeigt. Dadurch kann ein Trojaner nicht mehr die Überweisung unbemerkt ändern. Vor diesem Problem schützen beide neuen Verfahren. Alle drei Verfahren, also iTAN, mTAN und chipTAN, stellen zusammen mit der PIN des Nutzers eine Zwei-Faktor-Authentifizierung dar: der Nutzer muss geheimes Wissen (die PIN) beweisen, und den Besitz eines physikalischen Gegenstands (TAN-Liste, Handy, TAN-Generator+Karte).

Im Folgenden wird davon ausgegangen, dass es einem Angreifer irgendwie gelungen ist, an die PIN zu kommen – was ohne einen Trojaner auf dem Rechner schwierig ist und in dem Fall die Gefahr relativiert, mit einem Trojaner jedoch trivial ist. Aufgrund der Zwei-Faktor-Authentifizierung sollte der Angreifer alleine mit der PIN (ohne den Besitz des entsprechenden Gegenstandes) nichts anfangen könnten.

Solange kein Trojaner auf dem Rechner ist und die TAN-Liste geheim bleibt, ist das iTAN-Verfahren sicher. Beim mTAN-Verfahren hingegen sieht es bereits anders aus: Hier muss nicht der PC, sondern das Handy sicher sein. Mit steigender Verbreitung von Smartphones und eher mangelhafter Sicherheit derselbigen wird das immer schwieriger. Während es für gewöhnliche Nutzer schwieriger ist, den Computer statt das Handy sauberzuhalten, kann das bei „Powerusern“ genau umgekehrt aussehen. Gelangt ein Angreifer in den Besitz der PIN und kann gleichzeitig das Handy mit Malware verseuchen, kann er das Konto plündern. (Update: Kunden einer spanische Bank sollen auf diese Weise angegriffen worden sein, das ist also keineswegs graue Theorie. Danke an wopot für den Hinweis! Update 2: Jetzt warnt auch das BSI vor dieser Art von Angriff. Update 3: Und jetzt gibts schon gezielte Angriffe auf deutsche User, ausgehend von einem verseuchten Rechner. QED.)

Eine weitere Gefahr bei der mTAN entsteht durch das Mobilfunknetz: Die mTANs werden per SMS verschickt. Diese sind bei der Übertragung nur sehr schlecht geschützt, und es existieren Angriffe, die SMS-Nachrichten an eine bestimmte Nummer bereits im Handynetz umleiten können. Beispiele für Angriffsmöglichkeiten wären: Die Nummer des Opfers portieren lassen, Klonen der SIM-Karte/des Handies, Abhören der SMS-Übertragung irgendwo zwischen Bank und Handy, das Bestellen einer neuen SIM-Karte, und und und. Darüber hinaus ist das meist immer mitgenommene Handy einer höheren Diebstahlsgefahr ausgesetzt als die TAN-Liste, die sicher zu Hause verwahrt wird.

Die mTAN ist im Szenario „PIN dem Angreifer bekannt, Rechner sauber“ somit weniger sicher als die iTAN.

Auch im Szenario „Computer verseucht“ beitet die mTAN keinen vollständigen Schutz: Heutige Smartphones werden oft mit dem Rechner verbunden, und ein Virus, der vom Computer auf das Smartphone überspringt um die mTANs zu stehlen ist technisch möglich und höchstwahrscheinlich nur eine Frage der Zeit. (In diesem Fall versagt jedoch das bisherige iTAN-Verfahren ebenfalls.)

Das andere Verfahren, die chipTAN, ist nahezu ideal: Ein separates Gerät, welches ausschließlich für die TAN-Erzeugung genutzt wird, zeigt die Überweisungsdaten an und generiert anhand der Bankkarte eine nur für diese Überweisung gültige TAN. Auch hier gibt es zwar Angriffe, diese nutzen jedoch ähnlich wie mein letzter ePerso-Angriff Fehler des Nutzers aus. Mit einer eindeutigen Bedienungsanleitung können diese weitgehend vermieden werden. Dieses Verfahren ist selbst dann sicher, wenn alles außer dem chipTAN-Generator virenverseucht ist, da die Prüfung der Überweisungsdaten auf dem Display des Generators stattfindet. Da dieses Gerät eine abgeschlossene Einheit mit minimalem Funktionsumfang (und somit kaum Angriffsfläche) darstellt, dürfte es vor Viren sicher sein.

Das Problem: Die iTAN wird bei der Postbank abgeschafft, Kunden haben also nur noch die Wahl zwischen mTAN und chipTAN. Nur die mTAN kann allerdings ohne weitere Kosten für den Nutzer genutzt werden. Das weitaus bessere chipTAN-Verfahren erfordert, dass der Nutzer 12-15 Euro für ein passendes Lesegerät ausgibt. Das wird die Akzeptanz dieses Verfahrens nicht gerade fördern. Das mTAN-Verfahren ist aber in bestimmten Fällen weniger sicher als die bisherigen iTANs. Durch das von den Banken behauptete hohe Sicherheitsniveau könnte das im Missbrauchsfall für den Kunden ein ziemliches Problem vor Gericht werden.

Gleichzeitig machen die Preise für die TAN-Generatoren übrigens deutlich, was für eine Gelddruckmaschine die ePerso-Kartenleser mit Verkaufspreisen im dreistelligen Bereich sind bzw. welche Preisklasse die ordentlichen Lesegeräte haben dürften, wenn man sie statt der unsicheren Basisleser in großen Mengen herstellen lässt.

Zusammenfassung:
– Die iTAN ist gegen verseuchte Computer anfällig. Dies ist derzeit das größte Problem beim Onlinebanking.
– Die Abschaffung der iTAN wird insgesamt betrachtet die Sicherheit erhöhen
– Die mTAN kann das Problem lindern, aber nicht lösen.
– Die mTAN bietet in bestimmten Szenarien einen geringeren Schutz als die iTAN
– Die chipTAN hat ein sehr hohes Sicherheitsniveau, kostet aber den Nutzer Geld
– Einige Nutzer werden durch diese Änderung ein niedrigeres Sicherheitsniveau als bisher haben. Sicheres Onlinebanking kostet extra.
– Die Nutzung des chipTAN-Verfahrens kann ich nur empfehlen.

Meiner Meinung nach sollten die Banken die chipTAN als Standardverfahren verwenden und genauso wie sie den Kunden ec-Karten zur Verfügung stellen, kostenlose TAN-Generatoren anbieten.

Durch die Nutzung eines separaten Geräts für die Erzeugung der TANs dürfte das chipTAN-Verfahren übrigens deutlich sicherer sein als die eID-Anwendung des ePersos – obwohl die Hardware einen Bruchteil kostet. Mit einem ähnlichen Ansatz (sichere Eingabegeräte mit Display und Tastatur im Besitz des Nutzers) ließen sich auch EC-Kartenzahlungen deutlich sicherer gestalten – da gibt es nämlich auch schon Sicherheitslücken.

Auch bei digitalen Signaturen sollte ein sicheres Signiergerät den zu signierenden Inhalt in einem simplen Fomat (z. B. Plaintext oder Bitmap) nochmal auf einem eigenen Display anzeigen und nur genau das signieren, was angezeigt wurde. Aber bis sich so etwas etabliert, dürften Jahrzehnte vergehen.