mTAN-Betrugsfälle: Erst der Anfang

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

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

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

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

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

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

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

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

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

Briefgeheimnis, Pressegeheimnis, PGP

Die Presse hat das Recht, Informantenbeziehungen zu verheimlichen (auch wenn das in der Praxis mit der Vorratsdatenspeicherung ab 2008 abgeschafft ist). Briefe unterliegen dem Briefgeheimnis.

Beides auf einmal wurde vom BKA verletzt, als die Post an bestimmte berliner Zeitungsverlage durchsucht wurde. Aber es war ja halb so schlimm – oder?

Es wurden nur zwei Schreiben geöffnet, so das BKA, und das waren auch beides tatsächlich Bekennerschreiben. Seltsam gute Trefferquote, oder? Es wurde nämlich nicht wie behauptet nur dem äußeren Aussehen nach bewertet, ob es sich um ein entsprechendes Schreiben handelt, sondern das BKA hätte die „Briefe […] gegen das Licht gehalten, um zu sehen, ob ein fünfzackiger Stern – das Symbol der Militanten Gruppe – erkennbar ist„. Um es mit anderen Worten auszudrücken, die Briefe wurden ganz einfach durchleuchet. Somit wurde das Briefgeheimnis nicht nur in zwei Fällen verletzt, sondern bei allen untersuchten Briefen (also vermutlich allen, die an die entsprechenden Zeitungen gingen), obwohl diese nicht geöffnet wurden (warum auch, wenn man sie auch anders lesen kann).

Noch nicht schlimm genug? Dann wurden die Briefe „kopiert und ausgetauscht„. Dass dabei eventuell Informationen verloren gehen können – wie z. B. versteckte (steganographische) Nachrichten – mag in diesem Fall weniger wichtig gewesen sein. Die Frage ist eher: Sollte die Zeitung merken, dass der Brief ausgetauscht wurde? Wenn nicht, wäre es erstens schon ein Unding an sich und zweitens kommt früher oder später sicher jemand auf die fixe Idee, Briefe an unerwünschte Personen nicht nur abzufangen, sondern durch Versionen mit verändertem Inhalt zu ersetzen. So kann man dann ganz einfach zwei Menschen gegen einander aufhetzen. Man kann sich also nicht nur nicht mehr darauf verlassen, dass Briefe ungelesen ankommen, sondern auch nicht mal darauf, dass ein Brief, der ankommt, nicht von irgendwelchen Behörden manipuliert wurde.

Immer noch nicht genug gekotzt? Sicherheitshalber wurden die Telefone der Redaktion auch gleich abgehört.

Das problematische am Austauschen von Nachrichten: Erstmal ein einfaches Beispiel: Ein Informant will die Presse über einen Skandal aufklären und hat bereits Informationen  zugeschickt, ist sich aber noch nicht ganz sicher. Nun findet er den abschließenden Beweis und schickt ihn der Presse. Wenn das mitgelesen wird, ist es für den Informanten äußerst unangenehm, aber die Informationen kommen an die Öffentlichkeit. Wenn der Informant oder seine Post verschwinden, werden weitere Nachforschungen angestellt. Wenn aber ein gefälschter Brief ankommt, in dem der Informant zu behaupten scheint, sich geirrt zu haben, wird (bei ausreichend geschickter Story) das Ganze vergessen. (Und der Informant bekommt die Meldung, dass die Story leider nicht interessant genug war und sie nicht veröffentlicht wird).

Beim Entwurf von Sicherheitssystemen, bei denen zwei Personen über eine unsichere Leitung kommunizieren, geht man von verschiedenen Unsicherheitsarten aus: Ein Angreifer, der die Leitung nur lesen kann, ist vergleichsweise harmlos. Ein einfaches Public-Key-Verfahren unterbindet solche Angriffe. Wenn der Angreifer zusätzlich noch nach Lust und Laune (z. B. alle verschlüsselten) Datenübertragungen unterdrücken kann, ist das zwar ärgerlich, aber man hat dann die Wahl, Daten unverschlüsselt zu übertragen oder es sein zu lassen, aber es besteht keine Gefahr, Daten ohne es zu wissen offenzulegen. Wenn aber der Angreifer sogar Daten unbemerkt austauschen kann, kann er auch die Schlüssel beim Public-Key-Verfahren austauschen – ohne dass es jemand merkt. Die Kommunikationspartner denken, die Kommunikation sei verschlüsselt – in Wirklichkeit liest aber jemand mit und kann den Inhalt beliebig manipulieren. Das Austauschen von Post geht also durchaus auch aus technischer Sicht weit über das mitlesen hinaus. Wenn das BKA also anfängt, auch Kommunikation im Internet nicht nur abzuhören, sondern auch bei Bedarf auszutauschen, wird auch verschlüsselte Kommunikation nicht mehr besonders sicher sein. Zum Glück ist es kaum möglich, solche Angriffe vollautomatisch durchzuführen – denn wenn im Inhalt der Nachricht noch eine Kopie des richtigen Schlüssels liegt, muss diese auch ersetzt werden, da der Unterschied zum verwendeten Schlüssel sonst auffallen würde. Und das kann nur manuell geschehen. (Ein Computer wird „Schau mal nach, ob 5136234-5123134 die letzten 2 Byte meines Schlüssels sind“ nicht automatisch finden können.) Außerdem hat PGP noch mit den „Web of Trust“ eine Gegenmaßnahme. Bei diversen verschlüsselten Telefon- und Chatprotokollen und unaufmerksamen Nutzern sind derartige Angriffe durchaus denkbar.

Onlinedurchsuchung vs. Abhören

Der alte Artikel an dieser Stelle war falsch, ich habe ihn daher gründlich überarbeitet.

Angeblich soll der NRW-„Landestrojaner“ „nur“ VoIP-Gespräche abhören und nicht Festplatten ausspähen. Wenn das stimmen würde (was es aber wohl nicht tut), wäre eine solche Maßnahme ziemlich genau damit zu vergleichen, dass einige Beamte konspirativ in die Wohnung einbrechen und eine Wanze ins Telefon installieren. Eine laschere Handhabung wäre also auf jeden Fall falsch. Sofern eine solche Wanzenaktion verboten ist, muss über die Onlinewanze gar nicht diskutiert werden.

Laut Lawblog soll ein Trojaner aber eben nicht auf das Abhören beschränkt sein:

Das Verfassungsschutzgesetz NRW liest sich etwas anders, und zwar eindeutig. In § 5 Ziff. 11 heißt es:

… heimliches Beobachten und sonstiges Aufklären des Internets, wie insbesondere die verdeckte Teilnahme an seinen Kommunikationseinrichtungen bzw. die Suche nach ihnen, sowie der heimliche Zugriff auf informationstechnische Systeme auch mit Einsatz technischer Mittel.

Selbst wenn eine normale Wanze erlaubt wäre, und der Trojaner nur abhören würde: Es muss beachtet werden, dass allein dadurch, das Behörden Trojaner nutzen dürfen, ein Dammbruch entstehen würde – kein normaler Mensch wird einen großen Unterschied zwischen „abhören“ und „ausspähen“ machen, und dann lässt sich ein neues, viel weiter reichendes Gesetz recht leicht umsetzen („Abhören ist ja vollkommen ok, steht so im Gesetz, das hier ist nur eine kleine Änderung, wir brauchen das, keine Ahnung warum das nicht direkt dabei war, ist wohl vergessen worden. Wer das ablehnt, will die Terroristen schützen und ist selbst einer“) – daher müssen vermutlich noch strengere Maßstäbe angelegt werden.

Zu hoffen wäre dann gewesen, dass das Bundesverfassungsgericht auch einen eingeschränkten „Abhörtrojaner“ nicht erlaubt – denn jetzt ist als „Bundestrojaner“ die „bloße“ Abhörmaßnahme durch die Medien getrieben worden, und wenn das erlaubt wird, dann können die CDU/CSU-Politiker machen was sie wollen.

Gulli scheint recht gut darüber zu berichten.

Siehe auch: andere Vergleiche „Altmodische Maßnahme – moderne Maßnahme“