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.

Atomkraft? Sicher! [Foto/Wallpaper]

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

• Position der Piratenpartei zur Atomenergie

Wallpaper:

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

Sicheres Onlinebanking? Kostet extra!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ePerso: PIN-Diebstahl ohne Malware

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

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

v

v

v

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

v

v

v

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

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

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

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

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

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

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

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

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

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

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

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

Sicherheitslücke bei PayPal eine Woche lang offen

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

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

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

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

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

 

Technische Details der Lücke

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

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

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

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

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

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

    0K                                                       100%   15.56 MB/s

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

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

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

Asse – Mathematik der Lügen

In „Wahrscheinlichkeitsrechnung des Terrors“ hatte ich vor Jahren mathematisch erklärt, warum vermeintlich sichere Verfahren zum Erkennen von Terroristen (oder sonstigen Tätern) dazu führen würden, dass ziemlich viele Unschuldige eingelocht würden. Die Grundidee dabei ist: Wenn man mit einem Verfahren, was sich nur selten irrt, sehr sehr viele Menschen testet, wird es in einigen Fällen danebenliegen. Gibt es nun nur wenige Terroristen in der Gesamtmenge, meldet das Verfahren eventuell mehr Unschuldige als es Terroristen erkennt.

Mit der Asse (dem löchrigen einsturzgefährdeten Atommülllager) gibt es nun ein anderes mathematisches Problem. Da ich hier ZDF-Quellen habe, muss ich recht großzügig zitieren, weil das ZDF die Originalquellen depublizieren wird. Um die Asse wurde eine deutlich erhöhte Krebsrate beobachtet. Laut diesem ZDF-Beitrag schließt die Regierung einen Zusammenhang aber aus:

Die Anzahl der Krebsfälle rund um das marode Atomlager Asse liegen über dem Durchschnitt – einen Zusammenhang hat die Bundesregierung nun einem Bericht zufolge ausgeschlossen. Sie erklärte demnach die Erkrankungsrate mit „statistischen Zufällen“.

Ob es einen Zusammenhang besteht zwischen „erhöhter Krebsrate“ und „Da ist ein Berg in der Nähe den sie mit (krebserzeugendem) Atommüll vollgemacht haben, indem sie Fässer aus ein paar Meter Höhe mit einem Radlader abgekippt haben. Danach ist da Salzlake durchgeflossen bis sie radioaktiv verseucht im Grundwasser gelandet ausgetreten ist“. – das kann man mathematisch nicht beweisen. Um zu beurteilen, ob es „statistische Zufälle“ sind, gibt es aber ein Verfahren. Das nennt sich Hypothesentest und klingt böser als es ist. Wir können damit keine Sachen beweisen, aber wir können damit Sachen wiederlegen. Beispielsweise die Behauptung, das Auftreten sei reiner Zufall und die Wahrscheinlichkeit, Krebs zu bekommen, sei nicht erhöht. Diese Behauptung nennt sich „Nullhypothese“. Die Gegenhypothese ist „ist doch kein Zufall, die Wahrscheinlichkeit ist erhöht“. (Wohlgemerkt: Die Ursache für die Erhöhung können wir nicht feststellen!)

Zunächst einmal zu den Parametern. Im Videobeitrag wird gesagt: „Die Fälle von Blutkrebs [haben sich] verdoppelt. Es sind 18 Neuerkrankungen an Leukämie bei 10000 Einwohnern.“ (Blutkrebs = Leukämie) Damit haben wir alle Werte die wir für die Berechnung brauchen: 18 Betroffene, 10000 Einwohner, normale Fallzahl wäre 9, d.h. eine Wahrscheinlichkeit von 9/10000. Welcher Zeitraum betrachtet wird wissen wir nicht, aber aufgrund der „verdoppelt“-Aussage können wir uns sicher sein, dass die Wahrscheinlichkeit sich auf den gleichen Zeitraum bezieht wie die Anzahl der Betroffenen.

Wir brauchen also eine Binomialverteilungstabelle. Das ist mit OpenOffice Calc (oder Excel) schnell erledigt, in Spalten B und C wird jeweils eingetragen:

=BINOMVERT(A3;10000;9/10000;FALSCH)
bzw.
=BINOMVERT(A3;10000;9/10000;WAHR)

(In Spalte A sind fortlaufende Zahlen von 0 bis 100 – weiter brauchen wir die Tabelle nicht, da die Wahrscheinlichkeiten im Bereich über 100 verschwindend gering sind)

Diese Tabelle gibt an, wie wahrschenlich es ist, dass genau eine bestimmte Anzahl Krebsfälle auftritt, wenn die Wahrscheinlichkeit tatsächlich 9/10000 ist. (Spalte B gibt diese Wahrscheinlichkeit an, Spalte C die aufsummierte Wahrscheinlichkeit, also die Wahrscheinlichkeit für „bis zu x Fälle“.)

Nun entscheiden wir uns, wie genau wir es haben möchten. Ich wähle einen maximalen Fehler von 1% (hätte meine Aussage also gerne mit 99%-iger Sicherheit). Wäre ja schlimm, wenn wir unsere Politiker zu Unrecht der Lüge bezichtigen würden. Nun sind alle Vorbereitungen getroffen und wir können unseren einfachen einseitigen Hypothesentest durchführen: Wir schauen in Spalte C (der summierten Wahrscheinlichkeit) und suchen den ersten Wert >= 99%. Dann lesen wir ab: links steht zu diesem Wert 17. Das bedeutet: Wenn die Krebsrate in der Asse-Umgebung nicht erhöht wäre, würden mit mindestens 99% Wahrscheinlichkeit höchstens 17 Leukämiefälle auftreten.

Die Behauptung, die Krebsrate sei nicht erhöht und die Häufigkeit vor Ort sei reiner Zufall, ist somit widerlegt. (Es ist damit allerdings nicht bewiesen, dass das auch tatsächlich etwas damit zu tun hat, dass direkt daneben ein Berg steht, den sie mit (krebserzeugendem) Atommüll vollgemacht haben, indem sie Fässer aus ein paar Meter Höhe mit einem Radlader… ich glaub ich wiederhole mich.)

Nun kommen wir aber zur Wahrscheinlichkeitsrechnung des Terrors zurück: Würde man einen Test mit einer Zuverlässigkeit von 99% auf tausend Orte anwenden, würde man selbst wenn alles normal wäre 1%, also 10 Orte, als Betroffen ansehen. Darüber versucht die Regierung sich auch rauszureden. Ich habe aber nicht den Eindruck, dass hier 1000 Orte untersucht wurden, und einer betroffen war, sondern es wurde die Umgebung eines Bergs (den sie mit (krebserzeugendem) Atommüll …) untersucht.

Um einen Zusammenhang mathematisch auszuschließen, müsste man den Test übrigens umgekehrt machen: Die Nullhypothese (das was zu widerlegen ist) wäre also „die Krebsrate ist erhöht“ und das würde man dann versuchen zu widerlegen. Wenn die Anzahl der Fälle über dem Mittelwert liegt, wird das allerdings nicht gelingen.

Was wären also mögliche Ursachen? Die Regierung stellt die Behauptung auf:

Um den beobachteten Anstieg mit Strahlung erklären zu können, müsste nach den vorliegenden wissenschaftlichen Kenntnissen über die Entstehung entsprechender Krebserkrankungen die Dosis etwa 10.000 mal höher sein als beobachtet.

Wenn man fies und unsachlich wäre, könnte man diese Steilvorlage jetzt nutzen und Spekulationen über die Strahlendosis anstellen. Die kann man schließlich auch (absichtlich) falsch/an „passenden “ Orten messen. Das halte ich jedoch für unnötig: Radioaktivität die man von außen abbekommt ist eine Sache. Nicht gerade gesund, aber nicht allzu gefährlich, wenn man es mit einem anderen Problem vergleicht: In den Körper aufgenommene radioaktive Stoffe. Da kann die Strahlendosis in der Umgebung noch so gering und unter allen gefährlichen Werten sein, wenn man strahlende Partikel im Körper hat, hat man ein Problem. Alphastrahlung kann, wenn sie von außen kommt, keinen Schaden anrichten, da sie in den oberen (toten) Hautschichten abgefangen wird. Gelangt allerdings ein Alphastrahler in den Körper, können seine Strahlen verheerende Schäden anrichten (ungefähr 20x so viel wie Gammastrahlen!). Angesichts der Lecks ist das leider zumindest kein unrealistisches Szenario.

UPDATE: Das Epidemiologische Krebsregister Niedersachsen ist auch der Meinung, dass das kein Zufall ist. (Danke für den Link, Felix!) Welch Überraschung. Wohlgemerkt: damit ist immer noch nicht bewiesen, dass es auch tatsächlich an der Asse liegt – allerdings ist damit geklärt, dass die Behauptung der Bundesregierung („statistische Zufälle“) eine Lüge ist.

Wie man Leute zum Gegner des ePerso macht

Eigentlich habe ich die Idee eines ePerso an sich nicht generell abgelehnt. Man achte auf die Wortwahl: Nicht wirklich befürwortet, aber sowas hat auch einige Vorteile und ich war nicht wirklich überzeugt, dass die Gefahren durch politischen Missbrauch tatsächlich so groß sind, wie einige behauptet haben. (Das hat natürlich nichts mit der technischen Sicherheit zu tun, die konkrete Implementierung halte ich für, … suboptimal.)

Die Argumentation der strikten Gegner online nutzbarer Ausweisdokumente ist folgende: Sobald es eine leichte Möglichkeit gibt, die Identität des Gegenübers im Netz zu prüfen, könnte sich schleichend zur Selbstverständlichkeit entwickeln (oder politisch durchgesetzt werden), im Netz immer den Ausweis vorzuzeigen, was die Anonymität im Netz zerstören würde. Damit wären Privatsphäre und vor allem freie Meinungsäußerung mehr oder weniger tot.

Ich habe diese Gefahr bisher als eher nicht so groß gesehen, zumal der Einsatz des Personalausweises für die Seitenbetreiber teuer und bürokratisch sein soll, und war vorsichtig optimistisch – mit einer vernünftigen Technik, die nicht auf Wirtschaftsförderung sondern auf vernünftiges Funktionieren optimiert ist, hätte so eine sichere Ausweismöglichkeit durchaus auch Vorteile – sichere Logins, Bankkonten online eröffnen, Onlineshops die Ware vielleicht eher mal auf Rechnung/Bankeinzug rausrücken statt auf Vorkasse zu warten, und vieles mehr. Daher auch mein Standpunkt, die Idee eines ePerso an sich nicht generell abzulehnen.

Herr Axel Fischer, natürlich von der CDU, hat es aber geschafft, mich mit einem Schlag zu einem überzeugten Gegner des Konzepts zu machen. Er konnte einfach nicht anders, als genau den befürchteten Missbrauch unverzüglich zu fordern. Danke, Herr Fischer, dass Sie mir die Augen geöffnet haben. Ach, das ist übrigens nicht irgendwer, sondern der Vorsitzende der Enquete-Kommission „Internet und digitale Gesellschaft“, also quasi der Internetexperte der CDU.

Das meiste ist bei Netzpolitik schon gesagt worden. (Update: Dieser Heiseforumskommentar bringts auch auf den Punkt.) Die Möglichkeit, sich anonym und somit sicher vor Repressalien zu äußern, ist eine Voraussetzung für eine freie Meinungsäußerung. Diesen Grundpfeiler der Freiheit abschaffen zu wollen passt in meinen Augen zu totalitären Zensurstaaten – die Forderung kommt für mich der Forderung gleich, hier einen solchen Staat zu errichten. (Mir ist sooo klar was jetzt für ein Kommentar kommt. Er ist langweilig und weder lustig noch interessant noch nötig. Der erste der ihn postet bekommt nen Fisch in seinen Kommentar geklebt.) Jede Meinungsäußerung zuordnen zu können ist nämlich besonders dann wichtig, wenn man unliebsame Äußerungen zügig bestrafen will.

Nur eines finde ich an dieser Forderung wirklich schade: Dass sie nicht rechtzeitig vor meinen ganzen Interviews rauskam.

AusweisApp gehackt (Malware über Autoupdate)

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

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

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

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

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

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

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

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

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

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

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

(SHA1: 22b96851042bfece3c641851eaa6e890a7b28bff)

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

CDU-Beschluss zur Netzpolitik, übersetzt

Netzpolitik weist auf einen CDU-Vorstandsbeschluss hin, welcher (als letzten Punkt) auch die Netzpolitik erwähnt. Mit ein wenig Übung kann man aus solchen Beschlüssen durchaus Absichten herauslesen. Für die weniger erfahrenen, hier eine Übersetzung. Zitate sind gekennzeichnet und stammen aus dem verlinkten Dokument. Hervorhebungen von mir.

Sollte sich jetzt irgendwer von der CDU gekränkt fühlen und/oder der Meinung sein, dass die Übersetzung ungenau ist: Ihr habt die nächsten Jahre Zeit, das unter Beweis zu stellen. Aber bitte insgesamt und nicht in irgendwelchen Details. Viel Glück.

 

Die Übersetzung

 

Es ist unser Ziel, die Möglichkeiten des Internets in allen Lebensbereichen optimal nutzbar zu machen und den Standort Deutschland als moderne Informations- und Kommunikationsgesellschaft weiter zu entwickeln.

 

Wir wollen das Internet kommerzialisieren wo auch immer das möglich ist und die kommerzielle (Aus)nutzung des Internets fördern. Wirtschaftliche Interessen haben Vorrang vor allem anderen.

 

Ein Netz ohne staatliche Mindestregulierung entspricht nicht unserer Vorstellung von politischer Verantwortung.

 

Wir wollen das Internet regulieren.

 

Gleichzeitig sind wir uns bewusst, dass zentrale und rein nationale Regelungen nur bedingt wirksam sind, gerade auch wenn es um Kriminalität im Internet geht. Fragen der Netzpolitik sind daher im europäischen und internationalen Dialog zu beantworten, Netzaktive und Branchenverbände werden wir dabei einbeziehen.

 

Wir wissen, dass wir unseren Überwachungswahn hier nicht durchgesetzt kriegen, weil uns die Bürger zu sehr auf die Finger schauen. Deswegen werden wir den Weg über die EU-Ebene und internationale Abkommen gehen. Lobbyisten werden dabei die Gesetzesentwürfe schreiben, während wir ein paar „Netzaktive“ ihre Meinung sagen lassen (die wir natürlich ignorieren), um die Massen ruhig zu stellen.

 

Dabei wird in der CDU die Abwägung zwischen „Freiheit“ und „Sicherheit“ stets eine wichtige Rolle spielen.

 

Die Freiheit darf die Sicherheit dabei nie einschränken. Wir fordern die totale Kontrolle.

 

So halten wir das Urheberrecht und das geistige Eigentum für schützenswerte Grundlagen von Innovation und Wirtschaftswachstum in unserer Gesellschaft.

 

Das Urheberrecht wird weiter nach Wünschen der Verwerterindustrie verschärft.

 

Auch ist es unserer Ansicht nach Aufgabe des Staates, etwa im Bereich des Daten-, Kinder-, Jugend- und Verbraucherschutzes, verbindliche Rahmenbedingungen für das Netz zu schaffen.

 

Unter dem Vorwand des Daten-, Kinder- und Jugendschutzes werden wir die Überwachung und Zensur des Internets vorantreiben und in Gesetzesform gießen. Mit ein paar wirkungslosen Verbraucherschutzregeln zünden wir eine Nebelkerze um ein – wenn auch irrelevantes – Gegenbeispiel zu haben, wenn man uns daran erinnert, dass wir eigentlich fast immer für die Lobbyisten und gegen die Verbraucher arbeiten. Falls wir am Datenschutz was ändern, werden wir „klare“ und einfache Rahmenbedingungen schaffen – „einfach“ dadurch, dass wir die Einschränkungen bei der Datennutzung reduzieren.

 

Die CDU hat eine Arbeitsgruppe „Netzpolitik“ eingerichtet, die für den Bundesparteitag 2011 programmatische Positionen erarbeiten wird, mit denen wir diese Entwicklung fördern, den Herausforderungen begegnen und die Bürger über die Chancen und Risiken der digitalen Welt informieren können.

 

Wir haben eine ganze Arbeitsgruppe eingerichtet, um so zu tun, als ob wir Ahnung vom Thema haben. Gleichzeitig werden wir uns intensiv bemühen, die Freiheit im Netz weiter einzuschränken und Propaganda über das große böse Internet zu verbreiten.

Stuttgart 21: Gezielte Kopfschüsse mit Wasserwerfern

Zu den Wasserwerfereinsätzen der Polizei in Stuttgart habe ich ein Video gefunden, wo ein Wasserwerfer bei einzeln stehenden Personen aus relativ geringer Entfernung gezielt auf den Kopf zielt, und zwar mit einem ziemlich kräftigen Strahl. Wozu das führen kann, hat man ja leider gesehen. Auf diesem Video bei 2:47 (direkt nach dem kleinen Schnitt) sieht man einen solchen Vorfall – da scheint es übrigens so, als würde gezielt ein Fotograf/Kameraman aufs Korn genommen, was ich besonders abartig finde.

Damit man besser sieht was passiert, habe ich hier mal die relevanten Frames extrahiert und ein langsam abgespieltes animiertes GIF daraus gemacht. Man sieht eindeutig, wie der Strahl genau den Kopf trifft, und man sieht auch die Wucht, mit welcher der Strahl auftrifft. Die ersten Bilder sind vom Einschlag des Strahls, die letzten zwei (in etwas größeren Abständen) zeigen die Situation direkt danach. Im letzten Bild (etwa eine Sekunde nach dem Einschlag des Strahls) sieht man dann, dass vor dem Fotografen mehrere Meter frei waren und der Strahl deutlich über die Plane hinwegging, die ein paar Leute in der Nähe des Wasserwerfers gespannt hatten. „Versehentlich zu hoch geschossen“ dürfte (auch angesichts des Volltreffers) also keine Ausrede sein. Links, rechts und hinter dem Fotografen waren übrigens auch Köpfe – anders als mit Absicht ist das meiner Meinung nach kaum zu erklären.

Stuttgart 21: Entgegenkommen, Baustopp oder Verarsche?

Derzeit wird desöfteren betont, dass in naher Zukunft wegen Stuttgart 21 weder Bäume gefällt werden noch der Südflügel abgerissen wird. Das wird dann als Entgegenkommen verkauft, oder gar als der von den Gegnern des Projekts geforderte Baustopp.

Der SWR schreibt dazu:

Mappus (CDU) bekräftigte, dass es bis zur Landtagswahl am 27. März 2011 keine weiteren Abrissarbeiten mehr gebe. „Da ist in den nächsten Monaten nichts notwendig, was in irgendeiner Weise provozieren könnte.“ Außerdem fügte er hinzu, dass bis 2011 auch kein Baum im Schlossgarten mehr gefällt werde. […] Der Südflügel sei für den Baufortschritt nicht notwendig. „Wir werden ihn so bestehen lassen. Und ich glaube, das ist ein Signal“, sagte die Ministerin

Ich lese da keineswegs ein Entgegenkommen oder einen Baustopp. Ich lese da: „Die Bauarbeiten werden wie geplant fortgesetzt. Die Bäume, die gefällt werden müssen, haben wir in der (vermutlich illegalen) Hau-Ruck-Aktion schon gefällt, und alles was wir in nächster Zeit abreißen müssen ist schon abgerissen, den Rest machen wir nach der Wahl, wenn die anderen Tatsachen geschaffen sind, das hat ja eh Zeit.“ Tolles „Entgegenkommen“. Die Medien und die Bevölkerung so zu verarschen ist aber sowohl typisch für das ganze Projekt, als auch geschickt – denn leider werden wohl zumindest einige drauf reinfallen.

Genauso toll ist übrigens, wie ständig davon gesprochen wird, dass „die ersten“ Bäume schon gefällt wurden. Nach der obigen Aussage scheint es so zu sein, als ob alle relevanten Bäume in dem Teilstück gefällt wurden. Und zwar höchstwahrscheinlich rechtswidrig gegen den enstprechenden Beschluss des Eisenbahnbundesamtes. Das problematische daran: Würde noch mindestens ein Baum dort stehen und der Beschluss umgesetzt – wie man leicht vermuten könnte wenn die Medien von den ersten gefällten Bäumen sprechen – würde sich das Bauvorhaben verzögern. Ist aber erstmal abgeholzt, bleibt nur noch die langwierige Diskussion über mögliche (Geld-)Strafen – der Bau kann weitergehen. Ich wette, die Geldstrafe bzw. eventuelle Kosten für Ersatznaturschutzmaßnahmen werden nur einen Bruchteil dessen betragen, was eine Bauverzögerung gekostet hätte, sodass sich das rechtswidrige Verhalten für die Bahn unterm Strich richtig fett lohnt. Vor allem wenn man bedenkt, dass ein Monat Verzögerung plus Winter plus (evtl. sogar vorgezogene) Landtagswahlen ein Aus für das Projekt ergeben können, bevor die Bahn ausreichend viele Fakten schaffen kann. Meiner Meinung nach müsste sichergestellt werden, dass Geldstrafen in solchen Fällen den Gewinn durch das rechtswidrige Verhalten deutlich übersteigen, oder die verantwortlichen Personen Haftstrafen bekommen.

Sollte ich mich in irgendeinem Punkt irren, hinterlasst bitte einen Kommentar. Ich bin nicht vor Ort und kann daneben liegen. Wäre in diesem Fall schön, wenn es so wäre. Ansonsten ist nämlich das, was hier als „Geste des guten Willen“ verkauft wird, eine astreine Verarsche.

Bundestag kann SSL abhören

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

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

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

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

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

Zertifizierungsstellen kürzt man übrigens mit CA ab.

SSL ist also unsicher, wenn

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

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

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

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

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

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

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

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

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

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

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

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

Schießsport erlauben, aber Spiele verbieten?

Über Fefe bin ich darauf aufmerksam geworden, dass Wolfgang Bosbach (CDU) nach dem Amoklauf in Lörrach darauf hingewiesen hat, dass man wegen eines solchen Vorfalls nicht gleich das Sportschießen verbieten könne. Da stimme ich ihm übrigens zu. Interessant wird das erst, wenn man sich vor Augen führt, dass er ein Verfechter von Computerspielverboten ist.

Diesen Widerspruch kann ich irgendwie nicht verstehen – denn wegen einzelner solcher Vorfälle etwas verbieten zu wollen, was allerhöchstens sehr indirekt damit zu tun hat, scheint mir recht unlogisch. Eigentlich wollte ich Herrn Bosbach daher über Abgeordnetenwatch fragen, aber darüber will er nicht gefragt werden:

Da ich seit vielen, vielen Jahren völlig problemlos per Brief, per Fax oder per E-Mail erreichbar bin, darf ich Sie sehr herzlich darum bitten, etwaige Fragen an mich auch unmittelbar zu adressieren, ein Umweg über Abgeordnetenwatch.de ist wirklich nicht notwendig. Sodann werde ich Ihnen gern antworten. Selbstverständlich können Sie meine Antwort auch gern veröffentlichen.

Das ist natürlich schade, denn so kann man seine Antworten auf die Fragen anderer Leute nicht lesen, aber natürlich sein gutes Recht.

Daher habe ich folgenden Text eben direkt per Mail an ihn geschickt, und werde die Antwort dann hier veröffentlichen, sobald sie eintrifft (Links waren in der Mail als Fußnoten):

Sehr geehrter Herr Bosbach,
im Rahmen der Diskussion um eine Verschärfung des Waffenrechts, welche durch die Amoktat in Lörrach entfacht wurde, haben Sie laut Zeit gesagt:
„Wegen einer solchen Tat kann man nicht Millionen von Sportlern die Ausübung ihres Sports verbieten.“

In diesem Punkt stimme ich Ihnen völlig zu. Umso mehr überrascht war ich jedoch, als ich darauf hingewiesen wurde, dass Sie sich nach dem Amoklauf in Emsdetten in einem SPIEGEL-Interview vom 23.11.2006 dafür ausgesprochen haben, gewalthaltige Computerspiele zu verbieten.

Hat sich Ihre Meinung diesbezüglich seitdem geändert?

Falls nein, warum halten Sie es für richtig, Millionen von Spielern die Ausübung ihres Freizeitvergnügens zu verbieten, obwohl Sie dies bei Sportschützen (völlig zu Recht) ablehnen?

Computerspiele eignen sich (im Gegensatz zum Sportschießen) keineswegs dazu, den Umgang mit einer Waffe zu erlernen, und sie geben dem Spieler auch keine Möglichkeit, an echte Waffen zu gelangen. Selbst wenn die Spiele – was umstritten ist – bei manchen Personen bereits vorhandene Neigungen zur Gewalt verstärken würden, scheint mir dies eine deutlich geringere Gefahr zu sein als die, die Sie beim Sportschießen bereit sind, in Kauf zu nehmen. Ein Verbot aus rein subjektiven moralischen Gesichtspunkten wäre meiner Meinung nach einer freiheitlichen Gesellschaft unwürdig und schwer nachvollziehbar – bei Sportarten wie Boxen werden ja auch keine Verbote gefordert.

Mit freundlichen Grüßen
Jan Schejbal

P.S.: Ich finde es schade, dass Sie keine Fragen über Abgeordnetenwatch entgegennehmen möchten. Das Portal erlaubt es anderen Besuchern schließlich, auch fremde Fragen und die Antworten darauf an einem Ort einzusehen und leicht zu finden.

Auf die Antwort bin ich jedenfalls gespannt.