Archiv

Posts Tagged ‘unsicher’

Sicherheitslücke bei PayPal eine Woche lang offen

2010-12-27 6 Kommentare

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.

Werbeanzeigen

Über die (Un-)Sicherheit von SSL und HTTPS

2009-01-18 9 Kommentare

Normalerweise denkt man, eine Seite mit https:// in der Adresse sei sicher, die Daten seien verschlüsselt und man kommuniziere definitiv mit dem richtigen Gesprächspartner. Das zugrunde liegende Protokoll nennt man SSL bzw. TLS (ich werde hier nur noch von SSL reden, TLS ist der Name der neusten Version), wenn also in SSL ein Fehler gefunden wird, ist davon auch HTTPS betroffen.  Das Protokoll an sich ist größtenteils sicher. Die Angriffe beziehen sich auf meist die dahinterliegenden Strukturen, die teilweise unsicher sind. Ich rede dennoch etwas unkorrekt von Angriffen auf HTTPS bzw. SSL, weil die Angriffe auf die Strukturen im Hintergrund natürlich in der Praxis per HTTPS/SSP gesicherte Verbindungen unsicher machen. Hier möchte ich einen sowohl für Anfänger als auch für Fortgeschrittene interessanten Überblick geben, was von der Sicherheit zu halten ist, was noch sicher ist  und was unsicher. Ich gehe im Folgenden von Firefox aus, wer noch den Internet Explorer nutzt, ist selber schuld und tut mir leid.

Ich habe auch allgemeine Tipps für Anfänger eingebaut. Je nach Kentnissstand werden einige Abschnitte unverständlich kompliziert und einige andere langweilig sein. Auch Profis können interessante Probleme finden, aber die Seite richtet sich eher an Nutzer, denen SSL ein Begriff ist.

Der Artikel ist doch sehr lang geworden. Daher erstmal nur, was hier behandelt wird:

  • Einleitung
  • Funktionsweise von SSL und HTTPS (sehr grob)
  • (Nicht) mögliche Angriffe
  • Aufbau von Adressen
  • Sicherheitsmerkmale im Browser
  • EV-Zertifikate
  • HTTPS ist kein Gütesiegel
  • Die einzelnen Angriffe
    • 1. Debian OpenSSL weak keys
    • 2. Comodo stellt ungeprüft Zertifikate aus
    • 3. StartSSL stellt schlechte geprüft Zertifikate aus
    • 4. MD5-Kollisionsangriffe
    • 5. OpenSSL-Lücke
    • 6. „optimierte“ Umleitung, wenn zunächst http benutzt wird (sslstrip, IDN-Spoofing)
    • 7. Nullbytes im Hostname des Zertifikats
  • Fazit

Vorab: Sicherheitstipps für Einsteiger in Kürze

  • System sicher halten – In dem Moment, wo der Rechner von einem Angreifer z. B. mit einem Trojaner bearbeitet wurde, kann man die ganzen Sicherheitsmaßnahmen vergessen. Nur wenn der Rechner und die Software vertrauenswürdig sind, kann man sich auf die Ausgaben verlassen. Dafür sollte man:
    • Sichere Software verwenden – Software, die oft Sicherheitslücken hat, meiden. Je stärker die Software fremdem Inhalt ausgesetzt ist, desto sicherer muss sie sein. Ein unsicheres (Offline-)Spiel ist kaum ein Problem. Ein unsicherer Browser umso mehr.  Internet Explorer meiden, z. B. Firefox nutzen.
    • Software aktuell halten – Software hat immer Sicherheitslücken. Mit Updates werden bekannte Lücken geschlossen. Spielt man ein Update nicht ein, obwohl es eine bekannte Lücke gibt, wird diese meist bald ausgenutzt. Auch hier gilt: Vor allem Betriebssystem und Browser sowie die Browser-Plugins (Acrobat Reader, Flash, diverse Mediaplayer) müssen immer topaktuell sein.
    • Virenscanner und Firewalls sind ein zusätzliches Sicherheitsnetz. Updates sind viel wichtiger.
    • Nicht vertrauenswürdige Software nicht starten. Dazu zählen gerne auf dubiosen Seiten angebotene falsche Updates sowie illegale Kopierschutz-Knackprogramme.
  • Wichtige Seiten direkt aufrufen – am Besten per Lesezeichen. Wer seine Bankseite immer per Google sucht, hat ein Problem, wenn ein Phisher es mal nach oben schafft.
  • Beim Aufrufen direkt https:// benutzen – sonst kann ein Angreifer problemlos umleiten, siehe unten.
  • Warnungen beachten – wenn der Browser sagt, dass irgendwas mit der Bankseite nicht in Ordnung ist, dürfte es stimmen, auch wenn bei irgendwelchen Hobbyseiten die Warnung oft „grundlos“ kommt.
  • Für Seiten die man nicht direkt aufruft muss man leider https kennen, um sicher zu sein. Das ist für Anfänger nicht einfach.


Weiterlesen …