Re: Phishing mit ECHTER Bank-Seite? - Schwedische Bank geht wegen Phishing off…
Obwohl ich es bislang noch nirgendwo In-The-Wild gesehen habe, ist es
mit IE/OE sehr wohl möglich, mit Hilfe der originalen Webseite zu
phishen. Mit einer Kombination von Exploits für nachwievor
ungepatchte Lücken kann man folgendes bewerkstelligen:
1. In der Mail ist ein Link auf https://securelogin.citibank.com, in
der Statusleiste erscheint diese URL ebenfalls, aber beim Klick
landet mal auf http://www.evil.com/citiphish.htm. Ohne JavaScript.
2. Diese Webseite öffnet ein neues Fenster für
http://www.evil.com/citiphish2.htm und schließt sich selbst. Dieses
Fenster hat keine Adressleiste. Seit XPSP2 sollte nun in der
Titelleiste des neuen Fenster die originale URL, dann eine
Bindestrich und dann der Titel der neuen Webseite stehen - dank einer
weiteren kleinen Lücke erscheint jedoch
https://securelogin.citibank.com als URL.
3. Diese Webseite erzeugt einen neuen DIV-Layer ganz oben, der die
Adressleiste emuliert. Die zeigt daher brav
https://securelogin.citibank.com an und ist sogar durch Klickerei
bedienbar.
4. Diese Webseite besteht auf einem JavaScript im Header und einem
Frame, der die originale https://securelogin.citibank.com einbindet.
Dadurch erscheint in der Statusleiste das SSL-Lock, und bei
Rechtsklick, Eigenschaften erscheint ebenfalls
https://securelogin.citibank.com als URL.
5. Gibt nun einer seine Logindaten ein, so fängt das Script sämtliche
Tastenanschläge ab - obwohl die Cross-Domain-Policy das ja strikt
verbieten sollte. Diese werden dann an den Server gesendet. Phishing
gelungen.
Ach, warum mach ich’s mir denn so schwer?
2a. Man öffne ein neues Fenster auf
http://www.evil.com/citiphish2.htm. Dieses schnappt sich die Referenz
auf das öffnende Fenster, sucht sich eine bislang noch nicht
gesperrtes Objekt heraus (Microsoft sperrt nur exploitete Objekte,
und zwar immer wieder, anstatt das Problem selbst zu beheben - weil
sie dann den gesamten IE größtenteils umschreiben müssten), wie z.B.
das frame-Objekt, und speichern es in einer neuen Variable. Ebenfalls
per dieser Referenz redirecten wir das originale Fenster nach
https://securelogin.citibank.com, und, was Wunder, können mit der
gespeicherten Referenz diese Webseite nun beliebig manipulieren.
Trotz Cross-Domain-Policy.
Ach, warum mach ich’s mir denn so schwer?
2b. Man exploite eine der viele Boundary Errors in shdocw.dll bei
diversen CSS-Combos, um beliebigen Code auszuführen. Das daraufhin
installierte Trojanische Pferd erledigt den Rest.
Ne, auch noch zu kompliziert.
2c.
MZblah_ein_echtes_binary, abszuspeichern als evil.gif, wobei der
Webserver als Content-Type video/x-ms-wmv liefert.
Ne, auch das ist noch zu schwer.
2d. Der User hat doch sein Logindaten in ‘ner Textdatei abgelegt und
benutzt die Zwischenablage. Klar, man könnte auch die Textdatei
suchen und auslesen, aber dann müsste man wenigsten grob den Namen
kennen. Indes, die Zwischenablage kriegen wir ja direkt: Eine
unsichtbare Textarea, ein focus() draufgesetzt und per
document.execCommand(”paste”) haben wir den Inhalt.
Nein, ich werde keine 0day-Exploits an Phisher verkaufen.
Nein, ein Großteil davon ist eigentlich schon seit Jahren bekannt und
von Microsoft totgeschwiegen wurden.
Nein, secure@microsoft.com interessierte sich schon vor Monaten nicht
dafür.
Nein, beim IE7 wird nix davon besser, zumindest laut der Beta.