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

Der Telekom entkommen – günstig Telefonieren ohne Sparvorwahlen

Viele Nutzer sind an die Telekom gebunden, weil bei anderen Anbietern kein Call-by-Call („Sparvorwahlen“) möglich ist, und mit dem normalen Tarif des jeweiligen Anbieters ins Ausland oder aufs Handys zu telefonieren meist schweineteuer ist. Da die Telekom der Netzneutralität endgültig den Krieg erklärt hat, möchte ich gerne dabei helfen, der Telekom den Rücken zu kehren.

Daher stelle ich hier die Lösung vor, die mir geholfen hat, von der Telekom loszukommen: Internettelefonie. Das klingt nach einer unpraktikablen Nerdlösung mit Headset und Computer, in Wirklichkeit ist es aber ziemlich einfach und bis auf die Einrichtung auch Anfängertauglich. Als zufriedener Kunde von 1&1 habe ich eine Fritz!Box, an welche auch die Telefone angeschlossen sind. Darin kann man problemlos weitere SIP-Provider (Internettelefonieanbieter) und Wahlregeln definieren. Wenn man einen günstigen SIP-Provider gefunden und einmal eingerichtet hat, kann man die Fritz!Box so einstellen, dass Anrufe ins Ausland oder aufs Handy automatisch über diesen Anbieter laufen. Sobald das einmal gemacht wurde, kann man idiotensicher und einfach günstig telefonieren – ganz normal am Telefon die Nummer wählen, die Fritz!Box erledigt den Rest, ohne dass man überhaupt etwas mitbekommt. Das lästige Raussuchen und Vorwählen aktueller Sparvorwahlen entfällt.

Die Preise hängen vom gewählten Anbieter ab. Ich nutze einen der zahlreichen Ableger von Dellmont und bin dort zufrieden – welcher davon am Besten ist, hängt davon ab, wohin man am meisten telefoniert, technisch dürften die meisten davon gleich sein. Die Preise sind mit günstigen Call-by-Call-Anbietern vergleichbar, teilweise niedriger. Die meisten der Ableger bieten für jede Guthabenaufladung einige Monate kostenlose Anrufe in viele ausländische Festnetze (Beschränkt auf wenige Stunden/Woche). Vorsicht, bei einigen kommen Verbindungsentgelte dazu. Bei allen muss man zu den angezeigten Preisen etwa 25-30% für Steuern und Transaktionsgebühren dazurechnen. Guthaben kaufen kann man vorab (Prepaid) mit Paypal, Kreditkarte, Überweisung oder einer der vielen anderen Zahlungsarten. Bei Kreditkartenzahlung kann man eine automatische Aufladung bei Verbrauch des Guthabens einstellen. Einen groben Vergleich (der viele Sachen unberücksichtigt lässt, aber einen Anfang bietet) gibts hier.

Aktuell scheint Freevoipdeal.com die besten Kondition zu haben – unter 1 Cent pro Minute ins dt. Handynetz (nicht kostendeckend, also nicht enttäuscht sein falls der Preis irgendwann erhöht wird), knapp 1.5 Cent zu den „Gratis“-Zielen wenn das Freikontingent (120 Tage mit nicht näher definierter „Fair Use“-Regelung) verbraucht ist. Die Preise können sich jederzeit ändern, aber bisher sind sogar die dt. Handypreise seit min. 2 Monaten stabil und mehr als das aufgeladene Guthaben riskiert man nicht. Über die Qualität oder Zuverlässigkeit kann ich mich bisher nicht im Geringsten beschweren, die ausgehende Rufnummernanzeige (der bestehenden Festnetznummer) funktioniert (wenn eingerichtet), Rufnummernunterdrückung allerdings nicht. Nachtrag: Die erste Aufladung von ca. 12,70 EUR (inkl. Steuern/Gebühren) hat über 6 Monate lang gereicht, obwohl sämtliche Auslands- und Handygespräche darüber liefen. Die Handypreise sind weiter so günstig. Freevoipdeal: Absolut empfehlenswert.

Die Einrichtung in der Fritzbox erfolgt (zumindest wenn die Profiansicht aktiv ist) unter Telefonie -> Eigene Rufnummern, als „Internetrufnummer“ gibt man einfach einen Platzhalter wie „0000001“ ein. Nach der Einrichtung nochmal Bearbeiten und beim Rufnummernformat die „00“, „49“, und die Ortskennzahl ankreuzen, nicht aber die Null zwischen der „49“ und der Ortskennzahl. Anschließend unter „Wahlregeln“ neue Wahlregeln für „Ausland“ und „Mobilfunk“ anlegen, testen und schauen, ob die Anrufe mit einigen Minuten Verzögerung in der Übersicht im Kundenkonto des jeweiligen Anbieters auftauchen. Mit vielen anderen Routern/SIP-Adaptern dürfte das auch gehen, aber ich nutze eben die Fritz!Box und kenne das daher nur damit. Eingehende Gespräche und Festnetzgespräche gehen weiter über den normalen VoIP-Anschluss des Internetanbieters.

Damit steht einem Wechsel von der Telekom weg selbst dann nichts mehr im Wege, wenn man nicht-technikaffine Familienmitglieder hat, die oft ins Ausland telefonieren. Alternative Anbieter gibt es genug.

Bevor jetzt jeder, der beim Providerwechsel schlechte Erfahrungen gemacht hat oder macht, in den Kommentaren aufschlägt: Bei allen Anbietern, ohne Ausnahme, kann dabei was schiefgehen, und es passiert auch regelmäßig, überall. In der Mehrzahl der Fälle läuft es aber relativ unproblematisch ab. Immer dran denken, das „Sicherheitspaket“ zu kündigen, was einem die meisten Provider „kostenlos“ (Sternchen: in den ersten drei Monaten) dazubuchen. Zu jedem Anbieter gibt es unzählige Horrorstories, und noch viel mehr zufriedene Kunden.

Ich persönlich bin seit Jahren bei 1&1 und mit denen zufrieden. Die Hauptvorteile sehe ich darin, dass es vernünftige Hardware gibt (AVM Fritz!Box, darf man auch nach Vertragsende behalten), die Preise vernünftig sind und bis zu 4 SIM-Karten mit Festnetzflat dabei sind (gratis bis auf die Einrichtungsgebühr). Außerdem gibt es einen UMTS-Stick bis zur erfolgreichen Schaltung, sodass man auch bei Problemen ins Internet kommt. Eine Drosselung gibts nur, wenn man ausdrücklich den einen gedrosselten Tarif bestellt („Surf & Phone Flat Special“). Natives IPv6 gibt es leider nicht. Die VDSL-Verträge (DSL 50.000) laufen anscheinend im Hintergrund über die Telekom – von der Drosselung ist man da zwar nicht betroffen, aber das schlechte Peering macht sich gelegentlich bei einem kleinen Teil der Youtube-Videos bemerkbar (sonst eigentlich nicht). Ist bei der Telekom aber natürlich auch nicht besser. Eine Übersicht über die 1&1-DSL-Tarife gibt es hier*.

Von den DSL-Anbietern möchte ich hier noch EasyBell erwähnen. Mit diesen habe ich selbst keine Erfahrung und kenne auch keine Kunden von denen, sie scheinen aber viel Wert auf Service und Fairness zu legen und schneiden unter anderem beim DSL-Vergleich von WieIstMeineIP.de am Besten von allen bundesweiten Anbietern ab. EasyBell bietet auch halbwegs günstiges SIP ins Ausland an – wer statt Dellmont und deren etwas seltsamer Tarifstruktur lieber eine deutsche Firma haben will, für den könnte das interessant sein.

Für Internet mit extrem hohen Geschwindigkeiten und ohne Drosselung wird mir regelmäßig Unitymedia genannt, wo viele Leute anscheinend zufrieden sind. Dort gibt es auch natives IPv6 – leider aber für viele Kunden kein direktes IPv4, nur NAT (selbst bei Bekannten gesehen). Wem das nichts sagt, dem kann es vermutlich egal sein. Die Fritz!Boxen sind Mietgeräte, bei denen Updates nur vom Provider eingespielt werden können (was zu Verzögerungen führen kann), und generell könnten die Kabel-Fritzboxen weniger ausgereift sein. Manche Kunden bekommen man auch D-Link-Schrott statt Fritz!Boxen, das kann man in den Filialen möglicherweise besser als online beeinflussen. Edit: Die Kabel-Fritzboxen (zumindest das Basismodell) sind der letzte Murks mit unbrauchbarem WLAN, welches sehr kreative Probleme hervorruft. Für die Qualität des Services von Unitymedia fallen mir auch keine jugendfreien Worte ein. Unitymedia – bloß nicht!

*) Offenlegung: Der 1&1-Link ist ein Partnerprogramm-Link, d.h. ich erhalte Provisionen für darüber erfolgte Bestellungen. Ich empfehle 1&1 nicht wegen der Provision – solche Provisionsprogramme bieten die meisten Internetanbieter an – sondern weil ich zufriedener Kunde bin. Weil ich das öfter tue, habe ich mich für das Partnerprogramm angemeldet. Für die anderen Links wie Freevoipdeal, Easybell und Unitymedia bekomme ich nix.

Alle Angaben nach bestem Wissen und Gewissen, aber ohne Gewähr. Stand Mai 2013.

Bestandsdatenauskunft – neues Überwachungsgesetz und Demos dagegen

Die Bundesregierung hat sich mal wieder ein neues Überwachungsgesetz ausgedacht: Die Bestandsdatenauskunft. Nachdem das BVerfG (mal wieder) ausufernde und schwammig formulierte Überwachungsbefugnisse kassiert hatte, musste „natürlich“ gleich ein neues Gesetz her, um die kassierten Befugnisse wieder einzuführen und noch weiter auszuweiten.

Worum geht es dabei? Eine Kurzzusammenfassung gibt es bei bestandsdatenauskunft.de, wo auch noch weitere Probleme aufgezeigt werden. Etwas ausführlicher:

Ermittlungsbehörden und Geheimdienste werden ermächtigt, auf sogenannte „Bestandsdaten“ zuzugreifen. Was das ist, ist zwar schwammig formuliert, aber sicherheitshalber wird sehr deutlich erwähnt, dass dazu auch Passwörter zählen, und die Abfrage auch anhand von IP-Adressen möglich sein soll. Ein Richtervorbehalt ist nur beim Zugriff auf Passwörter vorgesehen. Die anderen Abfragen, insbesondere also die Identifizierung von Internetnutzern anhand der IP-Adresse, sollen bei größeren Providern sogar über eine automatisierte Schnittstelle ablaufen. Hierfür reicht es, wenn die abfragende Stelle der Meinung ist, „für die Erfüllung der gesetzlichen Aufgaben“ diese Daten zu benötigen, und eine Rechtsgrundlage dafür vorweisen kann.

Die Rechtsgrundlage wird gleich mitgeschaffen, indem z. B. das BKA-Gesetz geändert wird (Art. 3 des Entwurfs). Danach darf das BKA Daten erheben, wenn es sie für seine Aufgaben gem. § 2 Abs. 2 Nr. 1 BKAG braucht. Dort steht „genau“, welche Daten das BKA braucht: „alle hierfür [gemeint: für Verfolgung und Prävention bestimmter Straftaten] erforderlichen Informationen“ – auf gut Deutsch: Alle Daten, auf die es gerade Lust hat und sie für „erforderlich“ hält.

Das ist nur ein Beispiel, es werden auch noch die Befugnisse anderer Behörden auf ähnliche Art und Weise ausgeweitet. Auf Grundrechte wurde nicht im Geringsten Rücksicht genommen. Die Verhältnismäßigkeit wird nirgendwo geprüft, in den meisten Fällen ist nicht einmal ein Richtervorbehalt gefordert (nicht dass der viel bringen würde).

Mit den Passwörtern z. B. für Facebook, Google- und E-Mail-Accounts können die Behörden dann weitere Überwachungsmaßnahmen durchführen, z. B. über Facebook den Freundeskreis ausforschen, E-Mails mitlesen, eine Onlinedurchsuchung bei Online-Speicherdiensten machen,  über den Play-Store Schadsoftware auf Android-Geräte installieren, mit der PUK die auf einer SIM-Karte hinterlegten Kontakte und SMSen lesen, mit dem Google-Accountpasswort die Bildschirmsperre eines Android-Handies aufheben. Ob sie das dürfen, dürfte die Behörden nicht interessieren. (Siehe z. B. illegaler Einsatz des Bayerntrojaners). Die strengeren rechtlichen Anforderungen für Überwachungsmaßnahmen wie die TKÜ werden somit komplett unterlaufen.

Durch die Massenabfrage von IP-Adressen können Massen-Überwachungsaktionen durchgeführt werden. Die rechtswidrige, aber trotzdem regelmäßig durchgeführte Überwachung und Zurückverfolgung von Internetnutzern, die Behördenseiten besuchen, wird damit viel einfacher und dürfte massenhaft eingesetzt werden. Bei solchen Aktionen gilt für viele Behörden sowieso das Motto „Legal, illegal, scheißegal“ – die Überwachung in NRW fand auch statt, nachdem das ausdrücklich für rechtswidrig erklärt worden war. Dank automatischer Schnittstelle wird massenhafter Missbrauch ala Dresdner Handydatenskandal viel leichter und unauffälliger.

Wer es selbst nachlesen will: Das Gesetz wurde nach anfänglicher Kritik geändert, sodass jetzt ein Originalentwurf und ein Änderungstext existiert, falls ich eine zusammengefasste Version finde, werde ich den Link hier nachtragen. (Edit: hier findet sich eine von Freiwilligen erstellte Version – Danke!)

Es handelt sich um ein Zustimmungsgesetz (das erkennt man übrigens an der Formulierung „Der Bundestag hat mit Zustimmung des Bundesrates…“ im Gesetzesentwurf). Ohne die Zustimmung im Bundesrat kann die Bundesregierung das Gesetz also nicht beschließen, und dort hat sie keine Mehrheit. Leider hat die SPD bereits versprochen, das Gesetz und damit diesen eklatanten Grundrechteabbau zu unterstützen, und verkauft das als „wichtigen Kompromiss„, weil sie es geschafft haben, einige kleine Verbesserungen einzubringen. Das ändert aber nichts daran, dass die Bestandsdatenauskunft inakzeptabel ist, und die SPD diesen Grundrechteabbau ohne Not und freiwillig mitträgt. Vielleicht überlegen sich einige Landes-SPDs ja noch, ob sie da mitmachen wollen, wenn sie merken, dass die Öffentlichkeit zuschaut.

Deswegen finden bundesweit friedliche Demos in über 25 Städten statt. Los geht es bereits dieses Wochenende (bundesweiter Aktionstag ist der 14.4., einige Städte fangen schon früher an), die zweite Runde gibt es am 27.4. (auch hier machen einige Städte die Demos schon früher). Die genauen Orte finden sich z. B. im Protestwiki. In Frankfurt am Main fängt die Demo am 14.4. um 13:00 Uhr am Römer an. (Nazis sind bei den Demos übrigens ausdrücklich nicht willkommen.)

Kommt nicht nur zu den Demos, sondern weist auch andere Leute auf die Bestandsdatenauskunft und die Demos hin, und fordert sie auf, ebenfalls Leute mitzubringen und auf die BDA hinzuweisen! Aktuell ist das Thema selbst unter politisch aktiven Informatikern viel zu wenig bekannt, da die Medien bisher kaum darüber berichtet haben.

Bestandsdatenauskunft ist Scheiße – und nun?

Es gibt einige Leute, die der Meinung sind, wir müssten Alternativen zur BDA aufzeigen, um sie kritisieren zu dürfen, und die Ermittlungsbehörden würden solche Befugnisse brauchen, um uns vor Kriminalität zu schützen. Das ist im Fall der Bestandsdatenauskunft reiner Unsinn. Die Bestandsdatenauskunft in der jetztigen Form missachtet sämtliche rechtsstaatlichen Grundsätze, pfeift auf Verhältnismäßigkeit, und erlaubt nahezu beliebigen Behörden, nahezu beliebige Bestandsdaten inkl. Passwörtern abzugreifen – außer bei den Passwörtern sogar ohne jegliche richterliche Kontrolle!

Als Piraten und Bürgerrechtsaktivisten ist es nicht unsere Aufgabe oder Pflicht, Vorschläge für „bessere“ Überwachungsgesetze zu schreiben, und ich bin maßlos enttäuscht von jedem, der ohne das Problem wirklich verstanden zu haben, die darin enthaltenen Überwachungsbefugnisse kleinredet und das Gesetz verharmlost (ja, tarzun, das gilt insbesondere für Leute die im Piratenvorstand sitzen) und so die Salamitaktik des stetigen Grundrechteabbaus unterstützt.

Wir brauchen aktuell keine weiteren Erweiterung der Rechte der Ermittlungsbehörden, sondern erstmal ein Freiheitspaket, was die katastrophalen Änderungen der letzten 20 Jahre rückgängig macht. Weiterhin brauchen wir Ermittlungsbehörden, die Befugnisse und Möglichkeiten nicht missbrauchen, und bei denen Missbrauch ernsthaft geahndet wird. Wenn wir Ermittlungsbehörden haben, die sich zuverlässig an geltendes Recht halten, dann und erst dann können wir darüber nachdenken, ihnen die und nur die Befugnisse zu geben, die sie zur Erfüllung ihrer Aufgaben zwingend benötigen, unter Einhaltung aller machbaren Vorsichtsmaßnahmen. Eine automatische Identifizierung von Internetnutzern ist unnötig, und es gibt keine Rechtfertigung dafür, irgendeine derartige Maßnahme ohne wirksamen Richtervorbehalt einzuführen.

Die BDA wäre auch dann abzulehnen, wenn Passwörter nur bei Verdacht auf bestimmte Straftaten abgefragt werden dürften, denn wer verdächtig ist, ist noch nicht schuldig. Ein Verdacht hebt das Grundrecht auf Privatsphäre nicht auf. Natürlich wäre es für die Behörden hilfreich, wenn sie alles dürften. Das darf in einem Rechtsstaat aber nicht das Kriterium sein.

Selbst wenn eine Erweiterung der Befugnisse der Behörden für sinnvoll erachten würde, kann die Diskussion darüber nicht auf Basis eines völlig überzogenen, verfassungswidrigen Gesetzes geschehen. Denn das ist die übliche Taktik „das zehnfache des Sinnvollen fordern, um am Ende das doppelte zu bekommen“. Das kann man sich etwa so vorstellen:

Regierung: „Hey, ich werde dir zehn Backsteine in den Arsch schieben“
Bürger: „WTF? NEIN! WAS FÄLLT DIR EIN!“
Regierung: „Ok, du hast gewonnen. Zwei sind ein fairer Kompromiss!“
Bürger: „Hm, immer noch scheiße, aber naja…“ *bück*

Deswegen kann es über die Bestandsdatenauskunft keinerlei Debatte geben, außer die Forderung nach kompletter Ablehnung. Wir müssen auch keinen „Gegenvorschlag“ für weitere Überwachungsgesetze machen. Unser Gegenvorschlag lautet: Die Grundrechte achten und bewahren!

Wenn wir nicht für unsere Grundrechte kämpfen, wenn wir dieses Gesetz ohne massiven Widerstand durchgehen lassen, dann war das nur der Anfang – dann folgen noch dreistere Gesetze, bis „Privatsphäre“ nur noch in Geschichtsbüchern zu finden ist.

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

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.

Beschäftigug für lästige Bürger

Die Online-Petitionsplattform des Bundestages klang nach einer tollen Idee für mehr Bürgerbeteiligung. Nach einer Weile wurde sie aber bekannt und beliebt, und es kamen die ersten Mega-Petitionen – und mit ihnen die Abstürze, wenn zu viele Bürger mitzeichnen wollten. Eine neue Software wurde beschafft, womit man sich umständlich registrieren musste, um mitzeichnen zu können. Als sich auch davon nicht genug Bürger abschrecken ließen, brach das System wieder zusammen. Dennoch kamen immer wieder große Petitionen zustande – und wurden, egal wie viele mitzeichneten, vom Bundestag kaum beachtet.

Um dafür zu sorgen, dass das Portal nicht durch Massen von Unfug unbenutzbar wird, gibt es dort eigentlich Richtlinien. Diese besagen unter anderem:

Voraussetzung für eine öffentliche Petition ist, dass die Bitte oder Beschwerde inhaltlich ein Anliegen von allgemeinem Interesse zum Gegenstand hat und das Anliegen und dessen Darstellung für eine sachliche öffentliche Diskussion geeignet sind. […] Eine öffentliche Petition einschließlich ihrer Begründung wird nicht zugelassen, wenn sie […] offensichtlich unsachlich ist oder der Verfasser offensichtlich von falschen Voraussetzungen ausgeht […]

Trotzdem kamen immer mehr Petitionen durch, wo das „allgemeine Interesse“ sehr fragwürdig war. Ärgerlicher als das waren allerdings die völlig unsinnigen Petitionen, die bereits existierende Dinge forderten – also nach den Richtlinien hätten ausgeschlossen werden müssen. Auch diese häuften sich. Wenn mehrere Petitionen zum gleichen Thema eintrafen, wurde ein Text ausgewählt (was ja auch sinnvoll ist) und nur dieser als öffentliche Petition behandelt. Da die Texte jedoch oft auffallend schlecht waren, drängte sich der Verdacht auf, dass hier absichtlich eine der schlechtesten Petitionen als „Muster“ gewählt wurde, um die Zustimmung und Beteiligung zu senken.

Viel schlimmer aber ist, dass gleichzeitig gut ausgearbeitete Petitionen zu tatsächlich relevanten Themen nicht als öffentliche Petition behandelt wurden – wodurch das Sammeln von Unterschriften massiv erschwert wurde. Im Fall der „108e-Petition“ gegen Abgeordnetenbestechung habe ich davon erfahren: Diese wurde (auch auf Nachfrage)ohne nähere Begründung abgelehnt. Wie viele sinnvolle Petitionen so unter den Teppich gekehrt worden sind, weiß man nicht.

Man könnte jetzt schon Absicht unterstellen, aber dazu gibt es einen schönen Grundsatz: „Never attribute to malice that which is adequately explained by stupidity.“ (Gehe nicht von Vorsatz aus, wenn etwas durch Dummheit ausreichend erklärt werden kann). Gerade zu den Zeiten, wo das Portal sehr aktiv war, wäre die schlechte Sortierung der Petitionen durch Überlastung erklärbar. Auch schlichte Inkompetenz wäre eine denkbare Erklärung. Eine Absicht kann man also nicht direkt unterstellen. Oder?

Dieser Zustand hält jetzt schon seit Jahren an. Wenn die Arbeit des Petitionsausschusses ernst genommen würde, wäre es für den Bundestag ein leichtes, eine ausreichende Menge an kompetentem Personal dafür einzustellen. Da das nicht geschehen ist, ist klar, dass echte Bürgerbeteiligung nicht gewünscht ist. Entweder es werden bewusst gute Petitionen unterdrückt, oder es wird bewusst nichts getan, damit der Petitionsausschuss seine Arbeit ordentlich macht/machen kann. So oder so ist klar, dass diese Plattform nur dazu dient und dienen soll, Bürger ihre Wünsche irgendwo äußern zu lassen, wo man sie bequem ignorieren kann, und die Zeit von engagierten Bürgern zu verschwenden.

Das Fass zum Überlaufen brachte eine Petition, die die Wiedereinführung einer Regelung im Personalausweisgesetz forderte: Wer einen Pass besitzt, soll keinen zusätzlichen Perso brauchen. Dummerweise steht das immer noch genau so im Gesetz (§ 1 Abs. 2) und wäre dort auch einfach zu finden gewesen. Die Petition ist inzwischen nicht mehr verfügbar, nachdem es im Forum massiv Kritik hagelte. (Mein Beitrag, der auch die Arbeitsweise des Ausschusses kritisierte, wurde auch verschwunden).

Deswegen ist der Petitionsfeed aus meinem Newsreader geflogen, und von mir gibts auch keine Werbung oder Mitzeichnung für Petitionen, die über dieses Portal laufen, solange es sich nicht um eine der „großen“, hauptsächlich außerhalb des Portals ablaufenden Petitionen handelt – egal wie sinnvoll der Text aussehen mag. Ohne massiven Öffentlichkeitsdruck sind die Petitionen sowieso sinnlos – außer als Zeitbinder für politisch engagierte Bürger.

Wenn ihr das genauso seht, und es irgendwo erklären wollt – dafür ist dieser Text da, ein Link sagt mehr als tausend Worte und ist schneller gesetzt als eine langwierige Erklärung…

Firefox 6 benutzbar machen

Ich bin lange auf dem 3.6.x-er-Zweig von Firefox geblieben (der zum Glück weiterhin gepflegt wird), weil ich Angst hatte, dass mir das Update wieder mal alle Extensions zerschießt und es keine einfache Möglichkeit gibt, das vorher zu prüfen. Außerdem hat die 4er-Reihe (also 4, 5, 6, …) auch ein „Feature“ durch das alle Texte unscharf gerendert werden und einige andere nette Sachen.

Nun hab ich endlich mal die paar Stunden investiert, eine Kopie meines Profils in einen portablem Firefox 6 gepflanzt und geschaut, ob man das Teil brauchbar bekommt. Hier die Schritt-für-Schritt-Anleitung für Leute, die das gleiche Problem haben:

Menüleiste wiederherstellen
„Firefox“-Knopf -> auf „Einstellungen“ zeigen -> „Menüleiste“

Schrift lesbar machen
Linuxnutzer sind so eine augenfolternd-verwaschene Schrift wohl gewöhnt, die man bei Firefox ab Version 4 gratis dazubekommt, ich aber nicht (einer der Gründe, warum ich noch Windows hab). Viele stellen in about:config die Grafikbeschleunigung ganz aus (gfx.direct2d.disabled), um die Schrift wieder ordentlich hinzubekommen, aber es reicht, die Einstellung „gfx.font_rendering.cleartype_params.rendering_mode“ auf 2 zu setzen. Mit den anderen „gfx.*“-Einstellungen spiel ich irgendwann später mal rum, vielleicht bekommt man damit ja sogar die Webfonts (downloadbare Schriften) so hingebogen, dass einem die Augen beim Lesen nicht mehr wehtun.

Statusleiste wiederherstellen
Irgendwer hielt es für eine geniale Idee, die Statusleiste zwecks Platzersparnis auszublenden bzw. durch eine Add-on-Leiste zu ersetzen, und Link-URLs auf Einblendungen (mal links, mal rechts) am unteren Bildschrimrand zu präsentieren. Um dieses „Feature“ loszuwerden, braucht man das Addon Status-4-Evar. Das muss auch noch sinnvoll konfiguriert werden, weil die Defaultwerte z. T. idiotisch sind: Die Verzögerungen für die Linkdarstellung habe ich auf 0 gesetzt, und im erweiterten Editor für den Ladeindikator im Adresszeilen-Hintergrund (Fill-Mode) hab ich „rgba(128, 128, 128, 0.075)“ eingetragen, damit auch farbige Adresszeilen (SSL-Indikator, aus Firefox 2 mit einem User-CSS gerettet) ordentlich aussehen.

Mouse Gestures Redox wieder lauffähig machen
Die Mausgestenerweiterung „Mouse Gestures Redox“ ist für mich eine der wichtigsten Extensions und wird nicht mehr (bzw. nicht mehr so wirklich) gewartet. Zum Glück gibt es eine Nightly/Beta-Version, die mit Firefox 6 läuft.

Verlorene Addons retten
Die Addons, die durch das Upgrade inkompatibel geworden sind und für die es keine Updates gibt (bei mir nur Google Toolbar und SSL Blacklist) kann man versuchen zu retten, indem man den Add-on compatibility reporter installiert. Ob sie dann wirklich funktionieren, ist natürlich nicht garantiert, zumindest die Grundfunktionen scheinen bei mir aber zu laufen.

Menühöhe korrigieren (Update)
Nach Erstellung dieses Beitrags ist mir noch ein Ärgenis aufgefallen: Die Menüeinträge (Kontextmenü etc.) sind durch zusätzliche Zwischenräume plötzlich etwas höher. Die minimalen Unterschide summieren sind und so passen plötzlich deutlich weniger Einträge auf den Bildschirm, wie man auch am folgenden Screenshot sehen kann (gleichzeitig sieht man den Unterschied zwischen korrigiertem Schriftrendering links und dem Original rechts). Obwohl das rechte Menü einen Menüpunkt und eine Trennlinie weniger hat, ist es fast genauso lang wie das linke:

Wie ich jetzt merke, ist das wahrscheinlich der zweite Punkt, weswegen Linux-GUIs mir subjektiv massiv missfallen. Auch hierfür gibt es beim Firefox jedoch eine Lösung: In die userChrome.css (im Ordner „chrome“ im Profilordner, ggf. erst erstellen) wird der folgende Code eingetragen (angepasst nach diesem Post):

/* unfuck firefox7 menu item height */
.menu-accel, .menu-iconic-accel, .menu-text, .menu-iconic-text {
  margin-top: 0px !important;
  margin-bottom: 0px !important;
  padding-top: 0px !important;
  padding-bottom: 0px !important;
}

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.

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

Wie Sofortüberweisung.de funktioniert

Scheinbar wissen viele nicht, wie der Dienst „Sofortüberweisung.de“ funktioniert – denn ich glaube kaum, dass so viele ihn sonst nutzen würden. Der Dienst verspricht, wie der Name schon sagt, sofortige Überweisungen, was beim Online-Shopping dem Händler die (vermeintliche – siehe unten) Garantie gibt, dass die Ware direkt bezahlt ist, und dem Kunden so unter Umständen zu einer kürzeren Lieferzeit verhilft. Im Gegensatz zum Lastschriftverfahren ist eine Überweisung auch nicht (zumindest nicht so leicht und nur innerhalb kurzer Zeit) zurückrufbar.

Wie aber schafft es der Dienst, Überweisungen durchzuführen? Ganz einfach – man gibt ihm seine Onlinebanking-Zugangsdaten. Nein, man loggt sich nicht bei seiner eigenen Bank ein und überweist, man gibt diesem Dienst seine Zugangsdaten für den Onlinebankingzugang. Damit loggt er sich dann bei der Bank ein und führt die Transaktionen durch. Mit Benutzername/Kontonummer und PIN hat der Dienst schonmal weitreichenden Lesezugriff aufs Konto – und wurde vor kurzem dabei erwischt, wie er diesen missbraucht, um die Umsätze der letzten 30 Tage, den Dispokredit, Vorhandensein und Kontostände anderer Konten bei der gleichen Bank und/oder vorgemerkte und ausgeführte Auslandsüberweisungen abzufragen. Das soll nur der Absicherung der Überweisung dienen, was aber nichts daran ändert, dass Sofortüberweisung.de die entsprechenden Informationen abfragt. Mit der eingegebenen TAN wird dann die Überweisung durchgeführt. Technisch läuft die Kommunikation mit der Bank über das HBCI-Protokoll, worüber auch Onlinebanking-Software wie Hibiscus, WISO etc. mit der Bank kommuniziert.

Rein technisch gesehen ist das ganze Verfahren exakt das gleiche, was die ganzen Phishingseiten machen – es werden Zugangsdaten des Nutzers abgefragt und dann verwendet, um eine Transaktion durchzuführen. Bei iTAN wird die Transaktion eben der Bank gegenüber eingeleitet, die Bank sagt, welche iTAN sie möchte, und dann wird diese iTAN abgefragt. Der Nutzer muss darauf vertrauen, dass Sofortüberweisung.de mit der TAN keinen Missbrauch anstellt. Das soll durch ein TÜV-Zertifikat bestätigt werden – es gab allerdings schon zahlreiche Fälle (hier ein anderer TÜV-Verein), wo TÜV-geprüfte Webseiten völliger Murks waren. Diese Zertifikate sind also meiner Meinung nach nicht die Bytes wert, die die PDF-Dateien belegen.

Wenn ein Händler also nur eine Zahlung über Sofortüberweisung anbietet, oder bei anderen Zahlungsmethoden miese Konditionen bietet, kaufe ich eben woanders. Sofortüberweisung ist genauso (un)sicher wie Vorkasse per Überweisung, bietet aus Kundensicht in dem Punkt also keinen Vorteil. Wenn ein Händler Lastschrift anbietet, bevorzuge ich das – kaum Arbeit, sollte es große Probleme mit dem Händler geben (was mir bisher nie passiert ist) kann die Lastschrift zurückgebucht werden und die Missbrauchsgefahr ist nahe Null. Klar kann unberechtigt abgebucht werden, dann wird es eben zurückgebucht – dazu ist die eigene Bank grundsätzlich verpflichtet, egal ob sie sich das Geld vom Händler zurückholen kann oder nicht!

Bei mTAN und chipTAN dürfte das Verfahren ähnlich laufen – die Überweisung wird eingeleitet, bei der chipTAN leitet Sofortüberweisung.de die Challenge weiter, der Nutzer gibt die TAN vom Handy/Generator an Sofortüberweisung. Hier ist wenigstens sichergestellt, dass keine falsche Überweisung aufgegeben werden kann – die PIN kann allerdings immer noch benutzt werden, um – wie im oben genannten Fall geschehen – das Konto auszuspähen!

Diese Funktionsweise hängt Sofortüberweisung natürlich nicht an die große Glocke (natürlich steht das alles irgendwo – aber irgendwo wo es keiner liest), und setzt darauf, dass Nutzer sich schon nicht so recht informieren oder es ihnen egal ist. Die Weitergabe von Logindaten an fremde Webseiten verstößt in der Regel gegen Banken-AGB. Diesen Punkt hat das Kartellamt übrigens in einer grandiosen Fehlentscheidung bemängelt, denn viele Banken bieten einen ähnlichen Dienst selbst unter dem Namen GiroPay an. Dieser hat höhere Transaktionsgebühren, wird jedoch von den Banken selbst betrieben und unterscheidet sich in einem „klitzekleinen“ Detail: Der Kunde loggt sich bei seiner eigenen Bank in sein Onlinebanking ein, und die Bank bestätigt dann die Überweisung. Die Logindaten gehen also nicht an eine dritte Partei, in deren Hände sie nicht gehören.

Die Banken hätten also einerseits ein wirtschaftliches Interesse, Sofortüberweisung zu behindern, riskieren dabei allerdings juristische Probleme – weswegen z. B. die Postbank den Laden auch nicht technisch aussperrt. Wäre ich zuständiger für die Online-Sicherheit einer Bank und hätte das unabhängig von den wirtschaftlichen/rechtlichen Sachen zu entscheiden, würde ich die IPs von Sofortüberweisung regelmäßig in die Firewalls stopfen, und die bis zur Erkennung als IP von Sofortüberweisung eingereichten, aber noch nicht durchgeführten Überweisungsaufträge stornieren (mit Benachrichtigung des Kunden, aber ohne Benachrichtigung von Sofortüberweisung) – der Laden müsste dann zusehen, wie er sein Geld vom Kunden bekommt, vor allem, nachdem dieser einen bösen Brief von seiner Bank erhalten hat. Es wäre natürlich auch denkbar, dem Kunden einfach den Onlinezugang wegen Missbrauch zu sperren. Ehrlich gesagt überrascht es mich massiv, dass das nicht durch irgendwelche automatischen Systeme, denen das hohe Transaktionsvolumen auffällt, geschehen ist. Die vereinzelten Posts in Foren, wo behauptet wird, dass Leuten wegen der Nutzung von Sofortüberweisung.de (d.h. unberechtigter Weitergabe von Zugangsdaten) die Onlinebankingzugänge oder gar Konten gekündigt werden, sind bisher (leider, muss man sagen) vermutlich eher Falschmeldungen, das kann sich aber natürlich noch ändern. In Foren als Möglichkeit erwähnt und durchaus denkbar ist es, dass die Banken protokollieren, wer derart gegen AGB verstößt, und im Falle eines Schadens (z. B. durch Phishing) das Verhalten des Kunden als Argument benutzen, um den Schaden nicht auszugleichen. Sofortüberweisung.de „empfiehlt“ den Shopbetreibern, um Abmahnungen durch Verbraucherzentralen zu vermeiden, zu Erklärungen von Sofortüberweisung einen Text hinzuzufügen, in dem zwischen viel wiederholendem Geschwurbel steht:

Vorsorglich weisen wir dennoch darauf hin, dass es in Deutschland Banken und Sparkassen gibt, die davon ausgehen, dass die Nutzung von sofortüberweisung.de wegen der Verwendung von PIN und TAN außerhalb der eigenen Online-Banking-Systeme bei etwaigen Missbrauchsfällen zu einer Haftungsverlagerung führen kann. Dies kann bedeuten, dass im Missbrauchsfall die Bank sich weigert, den Schaden für den Endkunden zu übernehmen und der Endverbraucher den Schaden zu tragen hat.

Für Händler hat das Verfahren neben der Abmahngefahr außerdem noch das Problem, dass die Überweisung keineswegs so garantiert ist wie angedeutet wird – Sofortüberweisung bestätigt nur, dass die Überweisung abgeschickt wurde. Wenn der Kunde die Überweisung direkt danach bei der Bank widerruft, oder die Bank sich einfach entscheidet, die Überweisungen zu stornieren, dürfte der Händler seinem Geld wohl hinterherlaufen.

Giropay hat übrigens auch ein Problem, ist nämlich bei unvorsichtigen Nutzern besonders anfällig gegen Phishing. Der Nutzer wird von einer Drittwebsite (Onlineshop) auf sein Onlinebanking umgeleitet und soll sich dort einloggen. Der Onlineshop könnte den Nutzer nun auf eine Phishingseite umleiten. Wenn der Nutzer weiß, wie Giropay zu funktionieren hat (d.h. Login erfolgt auf der eigenen Bankwebsite) und er (z. B. über das SSL-Zertifikat) prüft, dass er sich auf der richtigen Website befindet, würde er so etwas natürlich erkennen. Ich weiß das, weiß wie ich das prüfen kann, und tue es auch konsequent – ich bezweifle jedoch, dass das auf Otto Normalnutzer auch zutrifft. Das ließe sich mit ein wenig Aufklärung aber wahrscheinlich korrigieren, denn die Nutzer sind inzwischen für Sicherheitsthemen gerade beim Onlinebanking sensibilisiert. Das gleiche Problem (mit der gleichen Lösung) gibt es übrigens auch beim Verified-by-Visa-Programm für Kreditkarten (bei Online-Kreditkartenzahlungen muss man sich bei Visa einloggen, somit sind Zahlungen nur mit den Infos die der Händler klauen kann nicht mehr mögich) sowie beim Authentifizierungsverfahren OpenID – und natürlich bei Sofortüberweisung, wo ein „Phishing-Angriff“ sogar mehr oder weniger Teil des Verfahrens ist.

Und nein, ich bekomme für diesen Artikel weder Geld noch habe ich irgendwas mit Giropay oder sonstigen Online-Zahlungssystemen zu tun. Es regt mich „nur“ tierisch auf, wenn das Verletzen grundlegener Sicherheitskonzepte zum Geschäftsmodell gemacht wird. Wenn man sich die Kommentare im Heiseforum zur Entscheidung des Kartellamts anschaut, bin ich offensichtlich nicht der einzige.

Zusammenfassung:

Probleme für Kunden

• Kontoumsätze wurden und werden abgefragt
• Missbrauch möglich
• Keine Rückbuchung bei Problemen mit Händler (wie bei normaler Vorkasse auch)
• AGB-Verstoß gegen Bank-AGB
  • Bank könnte Haftung bei Missbrauch (auch in unabhängigen Fällen!) verweigern
  • Onlinebanking-Sperrung denkbar

Probleme für Händler

• Verlust von Kunden die wissen wie das Verfahren funktioniert und es daher nicht nutzen wollen oder es gar als unseriös ansehen
• Abmahngefahr durch Verbraucherzentralen
• Zahlungen sind keineswegs garantiert!

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.

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.

ePerso: PIN-Diebstahl ohne Malware

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

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

v

v

v

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

v

v

v

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

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

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

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

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

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

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

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

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

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

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

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

Sicherheitslücke bei PayPal eine Woche lang offen

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

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

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

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

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

 

Technische Details der Lücke

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

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

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

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

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

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

    0K                                                       100%   15.56 MB/s

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

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

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