Mitternachtshacking

Wenn man mit einem frisch installierten Firefox beispielsweise die Webseite des CCC aufruft, bekommt man diesen lustigen Zertifikatsfehler:

Der Grund ist bekanntlich, daß die Zertifizierungsstelle CACert im Browser nicht als vertrauenswürdige CA enthalten ist.

Einige Browserhersteller liefern deshalb auch CA-Aktualisierungen aus. Microsoft beispielsweise stellt immer wieder mal über Microsoft Update eine Aktualisierung der Zertifizierungsstellen (”Update der Stammzertifizierungsstellen”) bereit. Ich kucke meistens dann auch, wer da alles neu drin steht.

Meines Wissens (ich lasse mich aber gerne eines besseren belehren) verlangt Microsoft, um in die Liste der vertrauenswürdigen Zertifizierungsstellen aufgenommen zu werden, die Erfüllung mehrerer Voraussetzungen:

• Eine Vereinbarung mit Microsoft (Microsoft CA Agreement)
• Mind. 2048 Bit Schlüssellänge, mind. SHA-1 Hashalgorithmus, min. 8 Jahre gültig, höchstens bis 2030
• CRL Distribution Point Extension, d.h. eine CRL muß bereitgestellt werden
• Eine dokumentierte Policy (Certificate Practice Statement, CPS)
• Ein erfolgreich bestandenes Audit, typischerweise nach
  • WebTrust for Certificate Authorities v1.0 or later, durch einen lizensierten WebTrust for CAs Auditor
  • ETSI TS 101 456 v1.2.1 or later
  • ETSI TS 102 042 V1.1.1 or later
  • ISO 21188:2006, “Public key infrastructure for financial services — Practices and policy framework”, ebenfalls durch einen lizenzierten Auditor
• Außerdem habe ich mal gehört, daß Microsoft dann noch so ca. 50.000 USD haben möchte, für den ganzen Aufwand

In den Auditregeln stehen insgesamt ganz schön viele  Anforderungen drin. CACert beispielsweise wird von Microsoft nicht aufgenommen, alleine weil die vermutlich die geforderten Kosten für Audit und RootCA-Zertifikatsverteilung nicht bezahlen können. Bei einigen Antragstellern scheint es Microsoft mit den Regeln auch nicht ganz so genau zu nehmen. Beispielsweise muß man das CPS der Cisco Root CA im Internet suchen. Im Zertifikat ist der Link dahin leider nicht enthalten.

Was mir aber langsam Sorgen macht, sind die vielen Regierungs-CAs die als vertrauenswürdige Zertifizierungsstellen im Internet Explorer (und anderen Browsern mit Verzögerung) auftauchen. Hier beispielsweise die Liste cer CAs die mir beim Durchsehen des aktuellen IEs aufgefallen sind:

• CN = AC RAIZ DNIE, OU = DNIE, O = DIRECCION GENERAL DE LA POLICIA, C = ES
• OU = Application CA G2, O = LGPKI, C = JP (Japanese Local Government)
• OU = ApplicationCA, O = Japanese Government, C = JP
• CN = Common Policy, OU = FBCA, O = U.S. Government, C = us
• CN = ComSign, O = ComSign CA, C = IL
• O = Government Root Certification Authority, C = TW
• CN = GPKIRootCA, OU = GPKI, O = Government of Korea, C = KR
• CN = IGC/A, OU = DCSSI, O = PM/SGDN, L = Paris, S = France, C = FR (Secrétariat Général de la Défense Nationale)
• OU = MPHPT Certification Authority, OU = MPHPT, O = Japanese Government, C = JP
• CN = Root CA, OU = GPKI, O = Government of Korea, C = KR
• CN = Root CA Generalitat Valenciana, OU = PKIGVA, O = Generalitat Valenciana, C = ES
• OU = sigov-ca, O = state-institutions, C = si
• CN = Staat der Nederlanden Root CA, O = Staat der Nederlanden, C = NL
• CN = VRK Gov. Root CA, OU = Varmennepalvelut, OU = Certification Authority Services, O = Vaestorekisterikeskus CA, S = Finland, C = FI

Bei Firefox ist das nicht anders. Mozilla (Kathleen Wilson) selbst sagt dazu:

“Mozilla has included many root certificates that are operated either by actual government agencies or by organizations that are government sponsored. We do not have a policy against accepting government sponsored CAs into our program.”

Bei der Aufnahme bzw. dem späteren Rauswurf von CNNIC, einer (möglicherweise staatlich kontrollierten) chinesischen Zertifizierungsstelle gab es bei Mozilla riesige Diskussionen. Die spanische Polizei kann aber inzwischen genauso Man-in-the-Middle Angriffe mit gültigen Zertifikaten auf beliebige SSL-Verbindungen durchführen. Und ich bin sicher, die eine oder andere scheinbar harmlose Organisation im Browser die nicht auf meiner Liste steht, wird von irgendeinem Geheimdienst kontrolliert.

Im Ergebnis habe ich folglich im Browser inzwischen fast 300 RootCA-Zertifikate von rund 100 Zertifizierungsstellen. Welche davon staatlich kontrolliert sind, welche davon tatsächlich vertrauenswürdig sind und welche böse, ist für mich nicht mehr überschaubar. Die Regeln Microsoft, Mozilla und Co. helfen wie oben gesehen leider nicht weiter. Ich denke, ich werde demnächst meine eigene Liste “Mitternachtshacking traut diesen CAs” veröffentlichen und alle anderen aus meinem Browser rauswerfen. Tatsächlich stammen alle SSL-Zertifikate der von mir genutzten verschlüsselten Verbindungen aus den letzten drei Monaten von lediglich 8 Zertifizierungsstellen, sagt Certificate Patrol. Die anderen 92 können folglich raus.

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.

Hach ja, SSL ist ein lustiger Dienst. Da braucht man so Zertifikate (X.509v3 ist recht beliebt) nur um dann feststellen zu können, die Webseite www.commerzbank.de gehört wirklich der Commerzbank in Frankfurt.

Wobei, wieso wirklich? Im Fall der Commerzbank bestätigt mir das die TC Trustcenter GmbH in Hamburg, seit neuestem eine Tochter der PGP Corp. Mein Mozilla Firefox (3.0.x) zeigt mir das in blauer Farbe vor der URL. Die Frage ist jetzt natürlich, ob ich TC Trustcenter glaube. Also quasi ob ich denen vertraue, daß sie die Prüfung korrekt durchgeführt haben und mich nicht belügen. Ich persönlich halte TC Trustcenter für recht seriös seit sie mal ein Zertifikat von mir nicht signieren wollten, das zugegeben geringfügig phisy aussah.

Wenn ich bei Verisign schaue, dem vermutlich weltweit wichtigsten Zertifikatsanbieter, bekomme ich sogar einen grünen Balken in meinem Firefox. Grün! Viel besser als blau! Weil Verisign hat sogar ein “Extended Validation”-Zertifikat. Übrigens von Verisign selbst ausgestellt. Die bescheinigen sich also selbst, daß sie Verisign sind. Das Extended Validation Zertifikat ist meiner Ansicht nach ja Beutelschneiderei par Excellenz. Da verlangt Verisign doppelt so viel Geld für das Zertifikat nur um den Antragsteller “genauer” zu prüfen als für weniger Geld. Als ob eine vertrauenswürdige Zertifizierungsstelle nicht sowieso genau prüfen sollte. Aber gut, von Verisign kann man vermutlich nichts anderes erwarten. Die haben auch schon mal ohne Prüfung Zertifikate auf den Namen Microsoft ausgestellt. (Die sind übrigens immernoch im Internet Explorer als “Fraudulent” zu finden). Außerdem war Verisign bis Oktober 2008 Haupteigentümer von Jamba. Das ist die Firma, die kleine Kinder mit Klingeltonabos über den Tisch zieht. Ob ich die wirklich vertrauenswürdig finde … ich bin mir da gar nicht so sicher. Verisign wäre jedenfalls der letzte Anbieter bei dem ich ein Zertifikat kaufen würde.

Der Chaos Computer Club greift übrigens auf die Dienste von CACert zurück. Die kennt mein Firefox nicht, und der Internet Explorer erst recht nicht. Obwohl ich die für recht vertrauenswürdig halte. Beim IE ist das aber klar. Ich habe mir sagen lassen, daß Microsoft rund 50.000 USD will, damit eine Zertifizierungsstelle in den IE aufgenommen wird. Und da CACert die Zertifikate kostenlos anbietet, vertragen sich die beiden Geschäftsmodelle recht schlecht. Vertrauen hin oder her.

Über die lustigeren Zertifizierungsstellen will ich gar nicht lästern, auch wenn mir ein Zertifikat einer deutschen Onlinebank ausgestellt z.B. vom “Autoridad Certificadora del Colegio Nacional de Correduria Publica Mexicana” etwas … naja, spanisch … vorkommen würde. Obwohl die laut Internet Explorer sicher sehr vertrauenswürdig sind. Leider ist deren Zertifikat Mitte 2009 abgelaufen. Aber es gibt ja auch noch die “Saunalahden Server CA” aus … na? … genau, Finnland. Wo soll so ein Saunala(h)den auch sonst herkommen

Warum ich das alles schreibe? Weil es bei SSL-Zertifikaten eben einfach nur um das Vertrauen zum Aussteller geht. Ist die Zertifizierungsstelle (CA) vertrauenswürdig? Stellt sie nur Zertifikate aus wenn die Identität korrekt verifiziert worden ist? Oder kann jeder dahergerollte Schäuble zu so einer CA gehen und ein falsches Zertifikat bekommen um einen staatlichen Man-in-the-Middle Angriff durchzuführen? Dann will ich so eine CA gar nicht im Browser haben.

Die Mozilla Foundation hat sich genau diese Diskussion nämlich jetzt eingefangen, nachdem die staatlich kontrollierte chinesische Domainregistry CNNIC mit ihrer Zertifizierungsstelle in den Firefox-Browser aufgenommen wurde. Dabei wurden die Anforderungen der Mozilla Foundation strikt erfüllt. CNNIC hat eine Zertifikatspolicy (CSP) die formal allen Anforderungen genügt. Meine Freunde von Ernst & Young haben geprüft, daß diese Policy formal ok ist. Webtrust hat gekuckt, daß Ernst & Young formal korrekt geprüft hat. Und die Mozilla Foundation verläßt sich darauf, daß die Anforderungen von Webtrust formal korrekt sind. Formal eben. Nur das mit dem Vetrauen, das ist halt schwierig.

Aber wenn mich jemand fragt … das Sicherheitsmodell von SSL ist sowieso für’n Arsch.

(via Fefe)

Nachtrag:

Die Mozilla Foundation hat die CNNIC-SSL-Zertifikate wieder aus der Standardinstallation entfernt.

Die Check Point Zertifizierungen gehen mir langsam auf die Nerven … alle paar Jahre wieder den ganzen Krampf.  Hab deshalb heute noch schnell zum Jahresende was gemacht. Was bin ich jetzt alles:

• CCSA NGX
• CCSE NGX
• CCSE PLUS NGX
• CCMSE NGX

und was fehlt mir noch alles:

• CCMSE NGX PLUS VSX
• CPCS Connectra
• CPCS Integrity
• CPCS IPS-1

Den VSX mach ich zum Jahresende noch schnell aber der Rest hat Zeit bis nächstes Jahr.

Ich stell mir grad vor, die das auf einer Visitenkarte aussehen würde. Die Amis drucken da doch jeden Blödsinn drauf. Ich schreibe dagegen bei mir weder Dipl.-Inf. noch CISSP drauf, das ist mir echt zu doof

Kollege Matthias hat sich zur CISSP-Prüfung angemeldet. Das kann ich natürlich nicht auf mir sitzen lassen und habe mich auch gleich mal dort gemeldet. Am 1. Juli ist Prüfung.

Die Anmeldeseite ist lustig. Eine der Fragen: Sind Sie jemals im Zusammenhang mit Hacking aufgefallen?” Na klar, davon lebe ich. Wir machen Penetrationstests und öffentliche Hackingshows und wenn wir da nicht auffallen, dann machen wir was falsch.

Ich hoffe, die nehmen mich trotzdem … ich hab vorsichtshalber dazugeschrieben, daß ich Certified Ethical Hacker bin. Man weiß ja nie, was die Amis so denken. Obwohl, die CISA-Prüfung würde mich auch noch interessieren.

Zertifizierungen gibt es wie Sand am Meer und der Deutsche Michel schwört auf jedes Stück Papier, das er sich an die Wand hängen kann. Besonders beliebt sind Herstellerzertifizierungen. Egal ob MCSE, Check Point CCSA/CCSE, Cisco CCNA/CCIE oder irgendeine andere Urkunde … so kann man zeigen, was man angeblich alles kann. An zweiter Stelle stehen dann die Zertifizierungen eines mehr oder weniger unabhängigen Instituts (klingt besser als Marketingklitsche, ist aber meist das gleiche). Da gibt es dann den Certified Ethical Hacker (CEH) von EC-Council, den OSSTMM Professional Security Expert (OPSE) von ISECOM und für die Leute mit mehr Geld (und meist noch weniger Wissen) so tolle Sachen wie CISSP, CISA und CISM.

Aber am besten sind die, für die es auch einen schönen Braindump gibt, den man auswendig lernen kann. Das hat den positiven Effekt, daß man das Zertifikat bekommt, ohne auch nur im geringsten was zu wissen oder verstanden zu haben.

Ich habe schon mit Kollegen gearbeitet die theoretisch alles hätten wissen müssen. Zumindest wenn man der langen Liste von Titeln auf der Visitenkarte hätte glauben wollen. Die Praxis sah leider genau umgekehrt aus. Die Kollegen bei denen auf der Visitenkarten nur der Namen und vielleicht noch “System Engineer” stand, das waren meistens die, die am meisten drauf hatten. Und je größer das Unternehmen um so krasser die Erfahrung.

Ich vermute, das Problem hängt mit den Personalabteilungen der großen Unternehmen zusammen. Der Abteilungsleiter aus der Technik kann höchstens auf Basis der Papierunterlagen eine Vorauswahl treffen und hat da wenig andere Anhaltspunkte als die Zertifikate. Der Personalverantwortliche wiederum nimmt halt den, der im Gespräch am besten abschneidet. Und das sind öfter die Blender und seltener die Techniker. Aber gut, so haben kleinere Firmen mit einer klugen Mitarbeiterauswahl eine reelle Chance im Markt. Die großen Unternehmen kaufen für viel Geld die Blender weg und die richtig guten bekommt man manchmal für ‘nen Appel und ein Ei.

Zumindest ist es bei uns im Unternehmen so. Wir sind nur ein paar Leute, aber jeder von uns kann leicht 3 oder 4 Pappnasen der großen Riesen in die Tasche stecken. Und wenn die nicht mehr weiter wissen, dann kommen sie ja doch immer wieder auf uns zu und fragen nach Unterstützung.

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!