3M Jupiter PAPR alternative battery / USB power supply

 

The 3M Jupiter is a battery-powered PAPR (powered air purifying respirator) device that provides filtered air to a helmet/hood, providing protection against particulates and (depending on the filter) other pollutants.

Since original batteries can be expensive, hard to obtain, and require a proprietary (also expensive and hard to obtain) charger, I investigated the possibility of alternative power supplies. Luckily, the interface between the battery and the device is a standardized barrel connector.

ALL OF THE BELOW INFORMATION IS TO MY BEST KNOWLEDGE, AND COMES WITHOUT ANY GUARANTEES. USE AT YOUR OWN RISK. YOU WILL LOSE LOW BATTERY WARNING PROTECTION, AND YOUR AIR SUPPLY WILL FAIL WITHOUT WARNING IF A USB BATTERY PACK TURNS OFF OR IS ACCIDENTALLY UNPLUGGED.

From my measurements, it appears to be a 5.5×2.5 mm barrel jack (i.e. the plug diameter is 5.5 mm, the inner pin diameter is 2.5 mm) with standard polarity: Positive center pin, negative barrel/sleeve. The jack is on the battery, the plug is fixed inside the blower unit. A corresponding plug will fit the original battery, and a 5.6 mm x 2.5 mm jack (Reichelt HK 25) fits the connector inside the blower unit.

The original 8 hour battery is rated at 4.8 volts, measured at 5.2 volts when fully charged. This means the device can be powered with 5 V. The 8h battery is rated ~36 Wh, implying a power consumption of ~4.5 W (less than 1 A), though power draw could be significantly higher during power-up or under heavy load due to aging or obstructed filters. (Note: Single-use, non-rechargeable primary lithium metal batteries with higher voltage ratings exist according to pictures; e.g. the 6 V BAT-22 lithium-metal battery and the 9 V BAT-21. Some data sheets mention a 7.8 V Intrinsically Safe battery but I’ve also seen pictures of 4.8 V IS batteries.)

By cutting the Micro USB end off a high-quality (low resistance) USB-A to Micro-USB cable, and soldering it to the above-mentioned barrel jack, a makeshift adapter can be created that allows powering the PAPR from a USB battery pack or wired power supply. A jack with strain relief should be used and the cable side of the jack should be filled with hot glue after soldering to provide strain relief, mechanical stability, and protection against short circuits. Remember to slide on the cover before soldering!

Inserting the adapter’s plug/socket into the battery well of the blower unit is best done with needle nose pliers, heavy duty tweezers, or a similar tool. Care must be taken to protect the cable against pulling, especially diagonally, as this could damage the connection on the blower unit. An adapter with the shape of an original battery could possibly be 3D-printed. The battery is 95.9 mm wide, 24 mm thick, with the narrower top part 75.5 mm wide and rounded at the top (the rounding doesn’t seem required).

This way, the PAPR can be powered from a USB power supply (untested) or a regular power bank (tested), as long as the power bank provides enough current to devices that do not perform any negotiation (you will likely have to manually turn on the power bank, even if that isn’t necessary with other devices). Since many power banks can be charged while in use, this effectively provides a way to power the PAPR from mains power with battery backup. Note the warning above: When the power bank discharges and is no longer able to supply the necessary current, it will likely cut out abruptly and without any warning. Do not use such a setup in environments where this could be a problem, or where you would not immediately notice the absence of the blower noise!

Finished USB-to-barrel-plug cable

Other notes:

• Extended use of PAPRs may cause dry eyes.
• Unlike other respirators, tight fit is not required due to the slight overpressure created in the helmet, and the system is highly effective: e.g. no trace of cigarette smoke can be detected even directly next to a smoker with the standard A2P filter.
• The A2P filter is A2P3, i.e. it provides the highest level of particle filtration.
• Air leaving the helmet is not effectively filtered.
• The Versaflo M-106 helmet is surprisingly comfortable. Glasses can be worn. The visor/face shield in the this helmet has a EN166B medium energy impact protection rating, comparable to a good pair of protective googles (verify the marking on your visor to make sure yours is the same, as different visor models exist).
• The air next to a busy road smells noticeably fresh when wearing this, making one realize how bad pollution in cities is and that cars with internal combustion engines should probably be banned sooner rather than later.

Atomkraft: Schwebstofffilter in der Probeentnahmeleitung

Beim Lesen des 2002er-Jahresberichts des Bundesamts für Strahlenschutz ist mir auf Seite 55 etwas seltsames aufgefallen: Beiläufig wurde erwähnt, dass in einer Probeentnahmeleitung eines AKWs ein Schwebstofffilter des Betreibers gefunden wurde, welcher die Messergebnisse verfälschte.

Vor kurzem habe ich mich endlich dazu entschlossen, das BfS mal zu fragen, was es damit auf sich hatte, und habe eine ausführliche und lesenswerte Antwort erhalten. Kurz, es gibt eine Erklärung, die nichts mit böser Absicht des Betreibers zu tun hat, und das Messsystem ist redundant ausgelegt. Auch darüber hinaus enthält die Antwort zahlreiche Details, die zeigen, dass im Hintergrund doch sorgfältiger gearbeitet wird, als man nach der Lektüre des Jahresberichts-Artikels befürchten könnte.

Auch dass sich eine Behörde Zeit nimmt, auf eine einfache Bürgeranfrage eine derart detaillierte Stellungnahme zu schreiben, ist selten. Vielen Dank nochmals an das Bundesamt für Strahlenschutz!

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

Android: Löschfunktion löscht nicht richtig

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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…

ePerso kann remote missbraucht werden

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

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

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

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

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

Demo des Angriffs auf YouTube

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

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

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

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

Dieser Angriff setzt also voraus:

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

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

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

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

Folgen

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

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

Totalversagen

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

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

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

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

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

Gegenmaßnahmen

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

Nutzer können:

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

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

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

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

Die Projektverantwortlichen können:

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

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

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

Technische Details

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

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

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

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

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

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

Argumente gegen (Anti-)Terrorgesetze

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

Verhältnismäßigkeit

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

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

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

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

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

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

(Siehe auch dieser Beitrag von „Nano“)

Ursachen

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

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

Wirkungen und Nebenwirkungen

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

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

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

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

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

Bundes-un-freiwilligendienst

Die Regierung ist überrascht – ohne Pflicht findet sich kaum noch jemand, der gerne Zivildienst machen möchte. Das hat sicher nichts damit zu tun, dass in der heutigen Gesellschaft alles schnell-schnell gehen muss, vor allem der Einstieg ins Berufsleben, nachdem man Turbo-Abi und Bologna-Studium in höchstens der vorgesehenen Zeit abgeschlossen zu haben hat.

Seltsam, dass der „Bundesfreiwilligendienst“ nicht genug Freiwillige findet, um Massen von zwangsweise verpflichteten Billigarbeitskräften zu ersetzen, oder? Sicherlich gab es Leute, die sich bewusst für den Zivildienst entschieden haben. Den Großteil dürften aber diejenigen bilden, die nicht durch den Schlamm robben und sich anbrüllen lassen wollen. Wer sich wirklich sozial engagieren möchte, dürfte das an anderer Stelle tun, statt freiwillig umsonst reguläre Arbeitsplätze zu ersetzen. Da hilft auch kein Gerede davon, wie wichtig (formal nachweisbares!) soziales Engagement im Lebenslauf ist.

Ich sehe drei Möglichkeiten, wozu das Ganze führen kann:

Im Idealfall würden die Zivi-Jobs durch reguläre, bezahlte Arbeitsplätze ersetzt. Das würde aber das Gesundheitswesen verteuern und das Geld müsste irgendwo herkommen. Da mal wieder Bundestagswahl ansteht und somit die FDP mal wieder Steuersenkungen braucht, ist das unwahrscheinlich.

Alternativ kann man natürlich das Gesundheits- und Pflegesystem noch weiter den Bach runtergehen lassen, indem die Stellen nicht ersetzt werden. Kranke und Pflegebedürftige bringen ja wirtschaftlich nichts, also kann man dort ja genausogut einfach sparen – so eine Denkweise würde zumindest zur Einstellung der schwarz-gelben Regierung passen. Aber die dritte Option ist viel verlockender:

Der Bundesfreiwilligendienst wird unfreiwillig. Diesmal nicht für Jugendliche, die man dringend über Turbo-Abi und Turbostudium schnellstmöglich zu wertvollen Arbeitskräften verarbeiten will, sondern für diejenigen, die gerade viele Anhänger der Regierungsparteien als wertlosen, asozialen, faulen Abschaum sehen: Arbeitslose. Diese Variante halte ich für sehr wahrscheinlich, denn die Regierung würde damit viele Fliegen mit einer Klappe schlagen.

Die „faulen asozialen Schmarotzer“ bekommen unter allgemeinem Applaus der typischen Klientel von CDU/FDP endlich was zu tun, und können sich nicht in der „sozialen Hängematte ausruhen“. Indem ALG2-Empfänger zur Zwangsarbeit abkommandiert werden, gewinnen die Regierungsparteien unter ihrer Klientel deutlich an Zustimmung.

Wo der Staat ansonsten Geld für Arbeitskräfte ausgeben musste, kann künftig umso mehr gespart werden, während die „Freiwilligen“ diese Arbeiten übernehmen. Besser wird das Gesundheitswesen dadurch nicht (auch wenn man das natürlich gut behaupten kann, um Pluspunkte zu sammeln), aber vielleicht billiger. Die Mehrwertsteuern für Hoteliers sind ja immer noch viel zu hoch, oder?

Gleichzeitig „löst“ man das selbstgeschaffene Problem mit dem Mangel an Freiwilligen. Der Dienst wird weiter Bundesfreiwilligendienst heißen, aber er mehr zu einem Bundes(zwangs)arbeitsdienst verkommt. Verkauft wird das Ganze natürlich als Wiedereingliederungsmaßnahme o.ä., da mangelt es ja nicht an Kreativität. Vielleicht bleibt der Dienst auf dem Papier weiter freiwillig, aber die Teilnahme wird für viele Arbeitslose als Wiedereingliederungsmaßnahme angeordnet, oder als „freiwillige“ Möglichkeit angeboten, um ein niedriges Zusatzeinkommen zu erhalten und das ALG2 auf menschenwürdiges Niveau zu bringen. Alternativ wäre es auch denkbar, dass der Dienst das ALG2 weitgehend ersetzt, oder sich auch ohne direkte Intervention durch die ARGEn als schlecht, aber immerhin etwas bezahlte „Ersatzarbeit“ für Arbeitslose etabliert.

Das mag zwar alles nach einer guten Idee klingen. Die immer stärkere Einführung von Billigarbeit über 1-EUR-Jobs, Aufstocker, Arbeitsbeschaffungsmaßnahmen und ähnliche Geschichten hat aber eher zu mehr Lohndumping und größerer Armut denn zu besseren Lebensbedingungen geführt. Für Menschen, die z. B. aus gesundheitlichen Gründen nicht mehr arbeiten können, dürfte das eine weitere Verschlechterung der Situation darstellen. Darunter fallen auch die, die durch die immer stärkere Beschleunigung (Turbo-Abi, Turbo-Studium) oder ihre Arbeit psychisch krank gemacht wurden (z. B. Burnout). Zudem dürften die Betroffenen kaum mit angemessenen Arbeitsbedingungen rechnen – schließlich hätten die un-freiwilligen Arbeiter keine Wahl und auch keine Mittel, sich gegen unmenschliche Behandlung zu wehren.

Der freiwillige Bundesfreiwilligendienst dürfte keine Chance haben. Das unausweichliche Scheitern, vielleicht von vorne herein einkalkuliert, wird hingegen eine willkommene Gelegenheit darstellen, Zwangsarbeit zu schaffen und den Sozialstaat weiter auszuhöhlen.

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!

Zensus: Fragebogennummer im Adressfeld

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

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

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

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

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

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

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

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

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

Plagiatsdoktor-Count: Neun

Langsam wirds zu viel für mein Linkblog, deswegen habe ich die Sammlung hierher verschoben. Das wären schon vier fünf neun Doktortitel, die wegen Plagiaten weg (aberkannt, zurückgegeben, …) oder in Gefahr sind:

• Karl-Theodor zu Guttenberg (CSU) – weg
• Silvana Koch-Mehrin (FDP) – Verfahren läuft
• Matthias Pröfrock (CDU) – Verfahren läuft
• Veronica Saß (Tochter von Edmund Stoiber (CSU)) – weg
• Jorgo Chatzimarkakis (FDP) – Plagiatsverdacht

Mehr Infos gibts übrigens beim VroniPlag Wiki.

UPDATE:Die ganzen Fälle inkl. der vier Neuen habe ich mal im Piratenwiki in eine schicke Liste eingepflegt. Man könnte fast sagen, dass die Parteien- und Fachbereichstendenz sich bestätigt.

Der Fall von Matthias Pröfrock war mir neu, als ich die Liste erstellt hab. Kurz darauf gabs schon den Fall von Jorgo Chatzimarkakis – und der ärgert mich besonders ob der Dreistigkeit, mit der das Plagiieren verteidigt wird: Auf seiner Website weist er darauf hin, dass er verschiedene „Zitierweisen“ benutzt habe, unter anderem „Zitate im Fließtext, nicht eingerückt und ohne Anführungszeichen, ausgewiesen durch Fußnote“. Um sicherzugehen, dass ich ihm kein Unrecht tue, habe ich mir die „Zitate“ mal angeschaut, die Arbeit ist online verfügbar, die Plagiateliste auch. Und da werden ganze Seiten en bloc „zitiert“, mit einer Fußnote am Ende (Beispiel: Seite 55-56, Fußnote 115), ohne dass zu erkennen wäre wo das „Zitat“ anfängt (böse Zungen würden sagen: Dort, wo das Ende des vorherigen durch die Fußnote erkennbar ist). Besonders schön ist, dass eines der „Zitate“ wiederum einen (gekennzeichnet) zitierten Satz enthält, und die Fußnote dann passend bei diesem steht (Seite 54, Fußnote 113).

Interessant vielleicht auch die beteiligten Unis und Fachbereiche:

• Guttenberg: Bayreuth, Rechts- und Wirtschaftswissenschaften
• Koch-Mehrin: Heidelberg, Philosophie
• Pröfrock: Tübingen, Juristische Fakultät
• Saß: Konstanz, Rechtswissenschaft
• Chatzimarkakis: Bonn, Philosophische Fakultät

Ob der große Anteil der Jura-Fachbereiche (+ Rest Philosophie) damit zusammenhängt, dass Politiker oft Jura studieren, oder damit, dass im Jura- und Philo-Bereich überdurchschnittlich viele Studenten unterwegs sind die es mit ehrlicher Arbeit nicht so haben, weiß ich nicht.
Für eine statistisch fundierte Aussage reicht es ja (noch) nicht aus. Vielleicht ja beides und ggf. ist ja das eine auch die Ursache für das andere ;-)

Für die auffällige Häufung bestimmter Parteien könnte man das mit dem überduchschnittlichen Anteil natürlich auch…

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.