Mitternachtshacking

So langsam wird das ja mein Lieblingsthema hier im Blog: IT-Sicherheit und Vertrauen. Wem vertrauen wir und warum? Läßt sich das überhaupt rational begründen? Manches kommt mir schon seltsam vor. Trust Center beispielsweise führen im Namen schon die Bezeichnung “Trust”. Gerade so, als wäre es zwingend notwendig darauf hinzuweisen, daß man diesen Centern doch bitte auch vertrauen soll. Ein normaler, vernünftiger Mensch würde das nämlich nicht tun.

Der aktuelle Anlaß um mal wieder über Trust Center zu polemisieren ist die Art und Weise, wie manche Zertifizierungsstellen die Identität eines Antragsstellers überprüfen. Dazu muß man wissen, daß sich in der Praxis vier (genauer 4,5) Klassen der Identitätsprüfung herausgebildet haben:

• Class 0: keine Ãœberprüfung des Antragsstellers. Hier wird ein Zertifikat ausgestellt, ohne den Antragsteller überhaupt zu prüfen. In der Praxis wird das nur für Testzertifikate gemacht, die sich nicht gegen eine bekannte CA verifizieren lassen.
• Class 1: Ãœberprüfung der E-Mail Adresse. Das ist praktisch für E-Mail-Zertifikate. Man schickt einen Antrag an die Zertifizierungsstelle und die schickt das Zertifikat an die angegebene E-Mail Adresse zurück. Wenn man das empfangen kann ist es offensichtlich korrekt. Eine weitere Ãœberprüfung ist nicht notwendig. Das ist sehr günstig und effizient aber halt nur eingeschränkt sicher.
• Class 2: Ãœberprüfung der Organisation anhand von irgendwelchen Unterlagen. Hier wird geprüft, ob es z.B. die Organisation des Antragstellers tatsächlich gibt, ob die Domain eines Webservers tatsächlich dem Antragsteller gehört, usw. Allerdings nur auf Basis öffentlich zugänglicher Dokumente. Beispielsweise kann ich für mitternachtshacking.de ein Zertifikat beantragen mit dem Namen der in DeNIC als Eigentümer der Domain registriert ist aber nicht auf einen anderen Namen.
• Class 3: Ãœberprüfung der Organisation mit Kontaktaufnahme. Hier wird in der Regel die Organisation geprüft und zum Antragsteller direkt Kontakt aufgenommen. Die meisten deutschen Zertifizierungsstellen machen das beispielsweise durch PostIdent. Bei den amerikanischen Beutelschneidern weiß ich das gar nicht. Meistens gibt es da ein Fallback auf Class 2.
• Die letzte halbe Klasse ist dann das “Extended Verification” von Verisign. Ich denke das kommt auch dadurch, daß es in den USA kein PostIdent oder vergleichbar gibt und für Class 3 dann eigentlich nur eine etwas erweiterte Class 2 Prüfung stattfindet. Mit dem “Extended Verification” wird dann halt ein wenig mehr geprüft. Wenn überhaupt.

Soweit ist das ja ok. Allerdings setzt bereits eine Class 2 Verification einen gewissen Aufwand voraus. Unter Umständen kann man das nicht komplett automatisieren sondern muß manuell prüfen, ob die ganzen Daten übereinstimmen. TC Trustcenter hat sich bei mir da mal verdient gemacht (das ist jetzt ausnahmsweise nicht ironisch), weil sie es abgelehnt haben ein Zertifikat auszustellen in dem die Daten nicht 100% mit den Unterlagen übereingestimmt haben. (Ursache war, daß wir am umziehen waren und ich das Zertifikat schon mal auf die neue Anschrift ausgestellt haben wollte).

Der eine oder andere Zertifizierungsstellenbetreiber ist deshalb auf folgenden Trick gekommen, den Aufwand zu minimieren:

Man definiert ein paar sogenannter “System-E-Mail-Adressen”, die per Definition (par ordre de mufti) in jedem Mailsystem vorhanden sein müssen und die dann vertrauenswürdig sind, weil die nur vom Betreiber des Mailsystems und damit vom Eigentümer der Domain genutzt werden können.

Das ist eine mutige Annahme. Darunter befinden sich nämlich auch so Adressen wie:

• administrator@domain.org
• admin@domain.org
• info@domain.org
• hostmaster@domain.org
• root@domain.org
• ssladmin@domain.org
• sysadmin@domain.org
• webmaster@domain.org
• info@domain.org
• postmaster@domain.org

und teilweise noch abwegigere wie

• ssladministrator@domain.org
• it@domain.org
• dnsadmin@domain.org

In irgendwelchen nie gelesenen RFCs sind tatsächlich alle diese E-Mail Adressen für besondere Zwecke mal reserviert worden. Die meisten Mailsysteme und praktisch alle Administratoren wissen aber nichts davon. Und wenn dann ein normaler Anwender eine dieser Mailadressen hat, kann er damit beispielsweise SSL-Zertifikate für die Domain beantragen obwohl er dafür gar nicht berechtigt sein sollte.

Aufgeflogen ist das ganze jetzt mal wieder, weil Kurt Seifried beim Freemail-Anbieter Portugalmail die nicht gesperrteE-Mail Adresse ssladministrator@portugalmail.pt registriert hat und damit erfolgreich ein SSL-Zertifikat für die Domain portugalmail.pt bei RapidSSL bekommen hat. Übrigens mal wieder eine 100%ige Tochter von Verisign. Dokumentiert ist das in einem Bugreport bei Mozilla der fordert, RapidSSL aus den vertrauenswürdigen Zertifizierungsstellen zu entfernen sowie in einem Artikel im Linux Magazine.

Passieren wird aber mal wieder nichts, weil sich die Mozilla Foundation nicht mit dem mächtigen Konzern Verisign anlegen will. Und RapidSSL hat ja auch verkünden lassen, Zertifikate nur noch bei einigen wenigen Mailadressen einfach so rauszuschicken. Klingt ganz toll, löst nämlich das darunterliegende Problem nicht: Erschreckend vielen Zertifizierungsstellen ist es offensichtlich einfach viel zu teuer die eigentlich geforderte korrekte Überprüfung des Antragstellers auch durchzuführen. Statt dessen wird da gemauschelt und geschummelt was das Zeug hält. Eigentlich gehört das ganze Sicherheitskonzept von SSL entsorgt und neu entworfen.

Und darum heißen diese Firmen ja auch Trust Center, sonst würde denen schließlich niemand vertrauen.

Ich lach mich schlapp. Die Beutelschneider von Verisign haben ein neues Geschäftsmodell gefunden. Musste ja kommen, weil Jamba (die mit den Klingeltonabos für kleine Kinder) im Oktober 2008 an Rupert Murdoch verkauft wurde.

Zur Wiederholung, das Geschäftsmodell von Verisign basiert neben der überteuerten Domainverwaltung von .com und .net vor allem darauf, überteuerte Zertifikate für SSL-Server zu verkaufen. Am besten gleich die mit Extended Verification, was bei mir den Eindruck erweckt als würde Verisign bei den anderen SSL-Zertifikaten gar nicht richtig prüfen. (Naja, tun sie ab und zu auch nicht wie die fehlerhaft auf den Namen Microsoft ausgestellten Zertifikate zeigen.) Aber gut, man braucht ja nicht unbedingt ein Zertifikat von Verisign. Es gibt auch günstige seriöse Anbieter.

Verisign hat jetzt aber entdeckt, daß es ja gaaaanz viele Webseiten gibt, die gar kein SSL haben. Und den gaaaanz vielen Webseiten ohne SSL kann man gar kein SSL-Zertifikat verkaufen. Was verkauft man denen dann? Genau, ein Webseiten-Siegel. Sowas wie es der TÃœV (die anderen Beutelschneider) auch im Angebot hat. Bei Verisign heißt das “VeriSign Trusted” (nur 299 USD, umgerechnet 220 Euro) und beinhaltet laut Heise die Identitätsprüfung des Seitenbetreibers. Ein SSL-Zertifikat ist nicht enthalten, das ist nämlich dann “VeriSign Secured” und kostet natürlich mehr. Nebenbei ist noch ein Malware-Scanner für die Webseite enthalten. Ich persönlich halte das ja für Quatsch, aber es gibt sicher genug Webseitenbetreiber die drauf reinfallen. Und vielleicht gibt’s das Siegel irgendwann sogar im VeriSign-Sparabo.

Nachtrag:

Ganz sachlich: ein normales VeriSign-SSL-Zertifikat kostet umgerechnet 440 Euro (599 USD) für ein Jahr, ein VeriSign-SSL-Zertifikat mit Extended Validation kostet umgerechnet 1250 Euro (1699 USD) für einen Server außerhalb der USA/Kanada. Ein vergleichbares SSL-Zertifikat z.B. von TC Trustcenter kostet 159 Euro (aktuelle Promo 143 Euro) zzgl. MwSt., von der Deutschen Telekom kostet es 150 Euro zzgl. MwSt. Aber da VeriSign keine Zwangslage ausnutzt darf man nicht von Wucher sprechen.

ICANN diskutiert mal wieder, der alte Laberverein. Das sind die mutmaßlich korrupten Bürokraten, die den Vertrag für die com-Registry mit einem Blankovertrag bzgl. Preiserhöhungen an Verisign vergeben haben, weshalb die com-Domänen demnächst doppelt so teuer werden wie de-Domänen.

Diesmal geht es um Regionaldomains, also sowas wie “.cat” (gibt es schon), “.eu” (gibt es auch), “.asia” (gibt es auch schon, aber ist noch nicht aktiv), “.berlin” (braucht das wer?), “.africa“, “.lat“, usw. usf.

Ich verstehe jetzt (mal so aus bayrischer Sicht gesprochen) die Diskussion nicht ganz. Bayern Tourismus residiert doch unter der Domain www.bayern.by, scheint also ok zu sein. Gut, es gibt da irgendwie eine kleine Verwechslung: Laut Wikipedia gehört die Länderdomain “.by” nicht Bayern sondern Weißrussland. Da scheint es sich um einen Fehler zu handeln. Weißrussland soll meinetwegen “.wr” (white russia, wäre noch frei) oder “.br” (belarus, Brasilien kann ja auf “.bl” wechseln) verwenden.

Darum sollte sich ICANN mal kümmern! Ist doch nicht zumutbar, daß wir Bayern unsere Domains auf kyrillisch registrieren müssen.

(via Heise, die irgendwas von komische GeoTLDs erzählen. Brauche ich ein Pferd, wenn ich auch einen Metzger habe?)

Muahahaha, oder wie Fefe schreiben würde: Das merken die NIE !!!1!!

JdM von 23sr hat’s doch bemerkt, nämlich, daß man dem Verisign Trusted Shop Siegel falsche Daten unterjubeln kann. Dann sieht es so aus, als hätte man einen Verisign-zertifizierten Shop und in Wirklichkeit stimmt das gar nicht. Dazu stellt er die Frage: “Wieviele der Siegel klickst DU vor einer Bestellung an? Prüfst DU einen Shop wirklich?”

Meine Antwort: KEINE. Das macht auch gar keinen Sinn.

Ich rege mich sonst nur wieder über solche Shops auf:

www.watchbizz.de

• Die URL an sich ist schon genial: http://www.watchbizz.de/ssl/shop/index.htm. Schön, daß SSL wenigstens in der URL vorkommt, wenn auch sonst von SSL nichts zu finden ist.
• Auch Klasse ist die Shopsoftware. Mit der Maus über einen [Bestellen]-Button fahren zeigt, was aufgerufen wird: ArtNr=902527&Bez=OmegaSportuhrenHardcover&Preis=69,00&Anz=1, eine URL in der der Artikel und Preis enthalten sind. Manipulation trivial möglich, und wenn vielleicht gerade Weihnachtsgeschäft und viel los ist und man die Bezeichnung um “Promotion” ergänzt, fällt ein günstigerer Preis gar nicht wirklich auf.

www.handy-discount-shop.de

• Der Shop hat ein schönes “Trusted Shops“-Logo, wenn auch nicht von Verisign. Gut, der nette Verisign-Trick funktioniert bei dem Logo nicht, sind leider nicht alle so doof.
• Die Freunde haben jedoch ein ähnliches Problem mit der Preisübergabe in der URL: bestellen_o2_genion_duo.php?handy=Nokia N95 und Motorola F3&preis=39. Aber vermutlich sagt das Logo eh nur, daß der Shop ein bissi ehrlicher als die anderen im Internet ist. Und das mit den Preisen … ist doch egal, oder?

Ach ja .. Verisign. Das sind übrigens die, die in die .com-Zone Wildcard-DNS eingeführt hatten und Jamba gehört denen auch. Da brauch ich auf das Siegel gar nicht klicken, da weiß ich vorher schon, daß ich da lieber nicht einkaufen will.

Beim Aufsetzen eines neuen DNS-Servers die Tage habe ich nebenbei bei Securityfocus nach bekannten Sicherheitslücken und Konfigurationsempfehlungen geschaut. Dabei bin ich über einen ganz anschaulichen Kommentar von Thomas Ptacek gestoßen, warum DNSSEC nicht zu gebrauchen ist.

Ich habe die DNSSEC-Diskussion dann ein wenig zurückverfolgt und bin auf folgende interessante Phising-Anleitung von D. J. Bernstein gestoßen:

1. Der Angreifer beschafft sich zwei IP-Adressen, z.B. 1.2.3.4 und 9.8.7.6. Er besorgt sich außerdem einen sprechenden Domainnamen, z.B. secure-banking.com.
2. Der Angreifer richtet einen DNS-Record für hugebank.secure-banking.com ein, der auf 1.2.3.4 verweist. Er beantragt bei Verisign ein Zertifikat im Namen von “HugeBank Secure Banking”. Er setzt einen SSL HTTP Server auf 1.2.3.4 auf, der genauso aussieht wie der von hugebank.com.
3. Der Angreifer richtet einen HTTP-Server auf 9.8.7.6 ein, der auf Anfragen nach hugebank.com antwortet und auf hugebank.secure-banking.com weiterleitet.
4. Hier kommt die Modifikation: Statt DNS-Anfragen zu fälschen wie im Original, schicken wir Phishing-Mails aus, mit dem Hinweis, sich mit hugebank.secure-banking.com zu verbinden. Alternativ können wir auch DNS-Anfragen an hugebank.com verfälschen, so daß auf die Adresse 9.8.7.6 verwiesen wird.
5. Das Opfer verbindet sich mit hugebank.secure-banking.com. Die Seite sieht aus, wie von Hugebank gewohnt. Der Browser zeigt eine sichere, verschlüsselte Verbindung zu hugebank.secure-banking.com an.
6. Ok, nun bin ich paranoid und prüfe das Zertifikat. Aber das Zertifikat ist gültig, von Verisign ausgestellt und sagt mir,daß hugebank.secure-banking.com tatsächlich “Hugebank Secure Banking” gehört.

Sieht alles korrekt aus und ist gar nicht mal so abwegig. Die Raiffeisenbank verweist zum Beispiel für ihr Internetbanking auf die Seite finanzportal.fiducia.de …

Eigentlich also nichts neues. Nur, die Anleitung ist von 1999!