Alex' blog (Artikel mit Tag phishing)

Wie man es nicht machen sollte - revisited

nospam@example.com (Alex) — Wed, 16 Jan 2008 16:33:00 +0100

Nach mehr als einem Monat Zeit funktioniert dies hier noch immer. Dabei bräuchte es nicht einmal fünf Minuten, um es in Ordnung zu bringen.
Und ja, es wurde dem Mobilfunk-Provider gemeldet (mit Rückantwort).

Was kommt nach JavaScript & Flash ? UPnP !

nospam@example.com (Alex) — Tue, 15 Jan 2008 14:42:00 +0100

Seit heute ist es auch beim Verlag Heise zu lesen: Ungewollte Fernkonfiguration für Heim-Router.

Das UPnP schon immer gefährlich war, ist nichts neues. Eigentlich wird UPnP hauptsächlich für das Setzen von Port-Forwardings im Router, initiert durch Anwendungen im LAN, benutzt. Daher war Universal PnP auch schon immer so gefährlich, da sich bereits im LAN befindliche Malware ebenfalls UPnP bedienen kann, um Port-Forwardings im Router einzurichten. Somit wäre es dann möglich auf Dienste, die sonst vom WAN aus nicht erreichbar wären, problemlos zugreifen zu können.

Doch nun kommt das Ganze etwas ~~anders~~ schlimmer: Während man früher noch CSRF/XSRF-Attacken in Verbindung mit einem bereits in den Router eingeloggten Benutzer brauchte, um z.B. den vom Provider zugeteilten DNS-Server zu verändern, um (z.B.) gepflegter Phishing betreiben zu können, ist dies jetzt nicht mehr notwendig, da UPnP über keinerlei Authentifizierungsmassnahmen verfügt und leider zu wesentlich mehr fähig ist als nur Port-Forwardings setzen zu können, was ich leider auch erst lernen musste. Wikipedia ist hier leider nicht vollständig.

Bislang konnte sich Malware im LAN ebenfalls dieser "erweiterten" Features von UPnP bedienen, aber dank der Arbeit von pdp und ap braucht es jetzt quasi nicht mehr als einen Webbrowser und eine entsprechend präparierte Webseite für einen solchen Angriff von außen.

Daher macht man es mir am besten nach. UPnP komplett deaktivieren - und nicht nur im Router, sondern auch am besten in allen anderen UPnP-fähigen Geräte, sofern weitere vorhanden sind. (Unser Router hat direkt an seinem ersten Arbeitstag UPnP deaktiviert bekommen.)

Weil die beiden bereits genug ausführliche Artikel zu dem Thema geschrieben haben, verweise ich hier auf die entsprechenden Seiten:

Cross Domain Basic Auth Phishing Tactics 3.0

nospam@example.com (Alex) — Thu, 03 Jan 2008 15:25:00 +0100

Heute häuft es sich ja richtig mit den Einträgen zur Unsicherheit von Webbrowsern ...

Das nächste, was ich entdeckt habe, ist, dass Firefox-Benutzer, die die Extension "FasterFox" installiert haben, um sich mittels Prefetching von statischen Webseiten einen Geschwindigkeitsvorteil zu sichern, leichter bei XSA-Angriffen über das Ohr gehauen werden können, als Firefox-Benutzer, die auf "FasterFox" verzichten.

Um in beispielsweise einem Forum jemanden mittels Phishing über das Ohr zu hauen, verwendet man sonst üblicherweise HTML oder BBCode, um ein (nicht existentes) Bild in den eigenen Beitrag einzubinden. Das Verzeichnis, wo das (nicht existente) Bild liegt, wird zudem mit HTTP-Auth abgesichert.

Falls nun in einem Forum zur Absicherung HTML-Quellcode bzw. BBCode zur Einbettung von Grafiken deaktiviert wurde, ist dieser Angriff nicht möglich. Wer jedoch die Extension "FasterFox" installiert hat, der kann hier dennoch Opfer eines Phishing-Angriffs werden.

Wenn der Angreifer in dem Forum Links direkt eingeben kann (z.B. über BBCode) oder reiner Text auf gültige URLs automatisch geparst wird, der bekommt diese Links dank besagter Extension im Voraus geladen. Die Folge davon ist, dass sich nur beim Besuch einer solchen Webseite mit einem Link auf einen Bereich, geschützt durch HTTP-Auth, im Firefox der übliche HTTP-Auth Dialog erscheint und um Eingabe der Logindaten bittet.

Wer dies mit installierter "FasterFox"-Extension ausprobieren möchte, der klickt bitte einmal hier: http://ha.ckers.org/blog/20070608/cross-domain-basic-auth-phishing-tactics/
(Dies funktioniert ebenfalls nur für kurze Zeit, da ich bald die .htaccess-Datei von testing.bitsploit.de wieder entfernen werde.)

Update: RSnake fand es auch eine Erwähnung wert.

Wie man es nicht machen sollte

nospam@example.com (Alex) — Wed, 12 Dec 2007 23:19:00 +0100

Gegeben sei folgende Situation: eine Webseite eines großen, deutschen Mobilfunk-Providers benutzt Frames. Um den HTML-Code für das Frameset zu schreiben wird JavaScript benutzt. Ohne aktiviertes JavaScript tut sich gar nichts. Nicht einmal ein Hinweis wird ausgegeben, dass der Benutzer doch bitte JavaScript aktivieren sollte.
An sich schon mal aus mehreren Gründen keine gute Idee.

Gegeben sei auch besagtes JavaScript, welches ich auf die wesentlichen Bestandteile reduziert habe (der JS-Code war auch ziemlich grauenhaft):

document.write("<frameset rows='100,*'>");
document.write("<frame src='header.php' name='top'>");

var path = location.search.substring(1, location.search.length);

if (path.length == 0)
{
path = "index.php";
}

document.write("<frame src='" + path + "' name='bottom'>");
document.write("</frameset>");

Hier liegt ein klassisches XSS-Problem vor: auf einfache Art und Weise lässt sich der untere Frame komplett austauschen.

Advisory zur HTTP-Auth Phishing-Lücke von Opera

nospam@example.com (Alex) — Wed, 25 Jul 2007 04:24:00 +0200

Das Advisory gibt es hier.

Update: Ich habe vergessen zu erwähnen, dass Opera knapp sechs Wochen bis zum Fix gebraucht hat. Schneller als Microsoft, denn die haben sich bislang noch nicht einmal auf die Schwachstelle gemeldet.

Opera 9.22 behebt HTTP-Auth Phishing Problem

nospam@example.com (Alex) — Thu, 19 Jul 2007 12:51:24 +0200

Die neuste Version von Opera, 9.22, fixt laut Changelog auch meine veröffentlichte Phishing-Lücke mit HTTP-Auth.

Zitat:

"Improved the display of long domain names in authentication dialogs. Long domain names will now scroll instead of using ellipsis."

(Microsoft hat sich bislang zum Problem mit der IDN-Darstellung im HTTP Auth Login-Dialog im IE7 nicht wieder gemeldet.)

Update: Nun steht auch ein Advisory zur Lücke bereit: http://www.opera.com/support/search/view/864.

Phishing E-Mails von Idealo

nospam@example.com (Alex) — Fri, 29 Jun 2007 14:25:14 +0200

Wie doof muss man eigentlich sein, um auf solche E-Mails hereinzufallen ?

Ich habe eine Phishing E-Mail weitergeleitet bekommen (und etwas unkenntlich gemacht) und zeige daran einmal die Fehler auf (abgesehen von vielleicht falsch dargestellten Zeichen (Kodierung) oder schlechter Sprache (Rechtschreibung / Grammatik)).

Liste (rot markierte Stellen von oben nach unten):

Die E-Mail kommt von einer russischen Universität (zumindest sieht es so aus - ich kann kein russisch).
Solche E-Mails werden maschinell und automatisiert zugestellt. Microsoft Outlook Express 6.x als MUA macht hier keinen Sinn. Die X-Mailer Zeile kann man natürlich auch noch fälschen, wenn man will.
Der anklickbare Link aus dem HTML-Abschnitt der E-Mail soll einen von der Beschriftung her glauben machen, dass man auf Idealo weitergeleitet wird. In Wirklichkeit aber verweist das Ziel des Links nach Geocities.

Abgesehen von diesen technischen Details, sollte dem Kenner auffallen, dass Idealo nur Preisvergleiche macht und keinen eigenen Shop hat.

Was allerdings raffiniert gemacht ist, ist die Tatsache, dass diese Multipart-E-Mail einen Plaintext- sowie einen HTML-Bereich aufweist. Je nach Einstellung des MUAs wird also etwas anderes angezeigt. Für den Fall, dass nur reiner Text als Ansicht im MUA gewählt ist, wird dem Benutzer kein falscher Link angezeigt. Das verhindert allzu schnelles Auffliegen. Der Benutzer wird vor einer seltsamen E-Mail stehen gelassen. Wenn der MUA E-Mails in der HTML-Ansicht allerdings anzeigt, dann kann man nur in der Statuszeile erkennen, wohin der Link tatsächlich führt.

Ich würde den Aufruf der der Webseite bei Geocities auf jedem Fall unterlassen, außer man weiß genau, was man tut !

Lustig finde ich an dieser Phishing E-Mail die Tatsache der unterschiedlichen Preise für die beiden Kameras (siehe blaue Markierungen).
Für den Preis aus dem Plaintext-Bereich würde ich auch zwei Kameras nehmen und sie weiterverkaufen.

Cross Domain Basic Auth Phishing Tactics reloaded

nospam@example.com (Alex) — Tue, 12 Jun 2007 00:42:20 +0200

Wie ich hier u.a. schrieb, zeigt der IE 7 den Domainnamen im HTTP-Auth Login-Dialog nicht korrekt an, sofern es sich um einen IDN handelt. Darauf hereinfallen kann man eigentlich nicht, da in der Statuszeile, welche standardmässig einblendet ist, der nach Nameprep und Punycode richtig konvertierte Domainname angezeigt wird.

IDN

Mit Skriptsprachen lässt sich die Statusleiste beim IE 7 zwar nicht mehr ausblenden, aber der Inhalt lässt sich weiterhin umschreiben, was z.B. beim Firefox standardmässig ebenfalls nicht erlaubt ist. Während der besagte Login-Dialog allerdings angezeigt wird, wird eventueller über window.defaultStatus o.ä. gesetzter Text ignoriert.

Es hat sich aber gezeigt, dass sich diese Anzeige in der Statusleiste aber komplett unterdrücken lässt. Allerdings funktioniert dieser, sagen wir einmal, Trick nur dann, wenn der Popup-Blocker deaktiviert ist. Dieser ist aber ebenso standardmässig aktiviert.

Daher nun folgende Frage bevor ich diesen Trick veröffentlichen werde: Kann mir jemand vielleicht verraten, wie man den Popup-Blocker im IE 7 umgehen kann ? Vielleicht hat dies ja jemand schon geschafft.

HTTP-Auth Bugs in Apples Safari 3 Beta (Windows)

nospam@example.com (Alex) — Tue, 12 Jun 2007 00:17:00 +0200

Vorhin habe ich beim Verlag Heise gelesen, dass Apple seinen Browser Safari auch für Windows in der Version 3 herausbringen will. Da die öffentliche Beta-Version seit heute bereits verfügbar ist, dachte ich mir, dass ich dort mal den HTTP-Auth Login-Dialog überprüfen könnte.

Wie gesagt, es ist eine Beta-Version, worin natürlich Fehler enthalten sein werden, so dass man dies nicht als besonders negativ bewerten kann, aber Bug ist Bug. Vielleicht wird er bei Nichterwähnung sonst glatt noch übersehen ...
(Ich würde das eher nicht Beta sondern Alpha nennen, weil massive Rendering-Fehler unter Windows XP an jeder Stelle auftauchen. Vielleicht also etwas zu früh für den Beta-Status ...)

Mit der Konfigurationsdatei .htaccess lässt sich die Notwendigkeit eines Logins für bestimmte Bereiche auf einem Webserver einstellen. Diese Bereiche kann man mit Namen (Authname) versehen. Die Anzeige dieses Namens beherrscht die Beta-Version bislang überhaupt nicht und gibt stattdessen erneut den Domainnamen aus.

Schwerer Fehler

Wenn man den Domainnamen zu lang wählt, dann gibt Safari diesen überhaupt nicht mehr an und lässt ihn auch als Bereichsname weg (siehe von Bug eins darüber). Die restliche Formulierung im Dialog verrät auch nicht unbedingt, dass hier eigentlich noch weitere Informationen stehen sollten ...

IDN-Domains zeigt Safari richtig an - im Gegensatz zum IE 7.

Korrekte IDNs

Ich habe bislang für meine Tests immer Basic Auth, statt Digest Auth verwendet. Bei Basic Auth wird das Passwort im Klartext übertragen, bei Digest Auth verschlüsselt. Digest Auth unterstützt aber nicht jeder Browser, daher ist es mehr als ratsam Basic Auth ausschließlich über eine SSL/TLS-Verbindung zu nutzen.

Browser halten sich in Bezug auf Basic bzw. Digest Auth mit Informationen gegenüber dem Benutzer recht zurück. Der IE 7 zeigt jedoch alle Informationen an: Man sieht ob der Login-Dialog Basic oder Digest Auth unterstützt und ob die Verbindung verschlüsselt ist oder nicht. (Falls Basic Auth über eine SSL/TLS-Verbindung verwendet wird, dann kommt allerdings gar kein Hinweis in dieser Richtung mehr. Im Fall von Digest Auth wird auch keinerlei Information darüber anzeigt.)

IE 7

Safari informiert darüber zwar nicht über die Art des HTTP-Auth Login-Dialogs, aber er zeigt an, ob die Verbindung per SSL geschützt ist oder nicht. Angeblich ist so eine Anzeige auch für den Browser Opera geplant. Was Safari aber dabei nicht wirklich richtig macht, ist, dass bei Digest Auth ohne SSL/TLS es dennoch heißt, dass das Passwort im Klartext gesendet wird.

Was mich etwas stört, ist, dass der Safari standardmässig keine eingeblendete Statuszeile hat. Dies hat der Opera zwar auch nicht, aber wenigstens zeigt dieser die URL an, wenn man mit dem Mauszeiger über einen Link fährt ... Gegen die oben genannten Bugs hilft aber auch das Einblenden der Statuszeile nicht.

Informativ

Cross Domain Basic Auth Phishing Tactics

nospam@example.com (Alex) — Fri, 08 Jun 2007 19:31:00 +0200

Der Screenshot zeigt den IDN-Bug im HTTP-Auth Dialog des IE 7.

Viel mehr gibt es dazu nicht zu sagen, außer dass an dieser Stelle auch Eric Johanson zu danken sei, weil ich seine IDN-Domain für meine Tests benutzen durfte.

Beitrag über HTTP-Auth Phishing mit Opera.

HTTP-Auth Phishing mit Opera

nospam@example.com (Alex) — Tue, 05 Jun 2007 17:38:00 +0200

In den letzten Tagen habe ich mich aus speziellem Grund ein wenig mit HTTP-Auth beschäftigt und bin zufälligerweise auf zwei unschöne Dinge gestoßen, die für einen unvorsichtigen Benutzer zu einem Phishing-Problem werden könnten.

Da ich den Hersteller des Browsers, den das zweite Problem betrifft, noch nicht informiert habe, erwähne ich heute nur eins der beiden unschönen Dinge: HTTP-Auth Phishing mit Opera.

Wenn der Domainname (z.B. durch den Einsatz von Subdomains) ausreichend lang gewählt wurde, dann schneidet Opera den Domainnamen in der Anzeige des HTTP-Auth Login-Dialogs ab. Wenn man die Länge (34 Zeichen) passend wählt, so folgen der gefakten TLD nur noch drei Punkte. Sprich: ...

Eigentlich sollte man stutzig werden, wenn man ... am Ende einer TLD sieht, da dies nicht gültig ist und im normalen Schriftverkehr andeutet, dass es hier noch weitergeht. Dies kann aber unter Umständen von einem Benutzer übersehen werden, was sich selbst die Mitarbeiter bei Opera Software ASA eingestehen.

Da Opera (zumindest in Version 9.21) standardmässig keine Statusleiste anzeigt und diese aber selbst nach manueller Einblendung nicht mit Informationen zur Domain füllt, kann man nicht auf einen Blick an mehr Informationen gelangen.
Es hilft also nur, die Authentifizierung dann abzubrechen und den Link, der einen zum mit htaccess abgesicherten Bereich eines Webservers geschickt hat, nun selbst erst zu überprüfen und danach gegebenenfalls fortzusetzen.

Lustig wird dies dann, wenn man diesen Phishzug mit XSA kombiniert. Wenn Opera ein Bild aus dem abgesicherten Bereich laden soll, so erfolgt dies natürlich ohne das Zutun des Benutzers - ganz im Gegensatz also zum Anklicken des Links, welcher zum abgesicherten Bereich führt, aus der vorhergehenden Situation.

Eine Abhilfe von Herstellerseite her ist bis jetzt noch nicht zu sehen, da sie selber keine Lösung (ja, das fand ich auch etwas seltsam ...) dafür haben und meine Vorschläge nicht gut fanden. Vielleicht fällt mir aber auch noch eine tolle Lösung ein, die die Entwickler von Opera auch prima finden.

Schlechte Ideen von F-Secure

nospam@example.com (Alex) — Wed, 09 May 2007 12:58:00 +0200

Mikko Hyppönen von F-Secure spricht sich für die Einführung einer neuen TLD für Banken (.bank) aus, um damit Phishing zu erschweren.
Das ist sicherlich nur ein Witz ...

Ich spreche mich hingegen für die Einführung von kurzen URLs aus, so dass man bei sensitiven Webseiten immer die komplette URL im Blick hat und so ganz bequem die Möglichkeit hat die URL zu überprüfen.
Welcher Otto-Normalbenutzer schaut sich eine URL, die nicht komplett auf einmal erfassbar in der Navigationsleiste steht, sonst ganz an ? Hier helfen dann entweder nur kurze URLs oder hohe Monitor-Auflösungen, wovon man letztere nicht voraussetzen darf.

Insecurity 2.0

nospam@example.com (Alex) — Fri, 13 Apr 2007 19:42:00 +0200

Mit Einzug von Web 2.0 und der damit verbundenen Rückeroberung des Internets von Benutzerseite aus, wurden zeitgleich auch neue Gefahren geschaffen, die für den Benutzer wesentlich schwieriger als zuvor abzuwenden sind.

Die Absicherung des heimischen Netzwerks oder Computer lässt sich im Normalfall noch recht leicht bewerkstelligen, so dass man nicht auf Grund eines Buffer-Overflows in irgendeinem Netzwerkdienst Spammern gleich Tür und Tor zu seinem Rechner öffnet. Stichwort: Botnetz.

Wovor sich Otto-Normalanwender allerdings weniger gut schützen kann, sind Angriffe auf Web-Applikationen, die in den letzten Jahre einen wahren Ansturm erlebt haben, weil er fast nichts dagegen unternehmen kann, außer sich entsprechendes Wissen anzueignen und stets alles und jedem zu misstrauen.

Oft basiert ein für den Nutzer gefährlicher Angriff auf JavaScript (XSS und zum Teil auch XFS). XSA, und CSRF bauen, aber nicht zwingend auf JavaScript (oder auch VBScript in der Windows-Welt) angewiesen sind. Durch den Missbrauch von JavaScript werden allerdings auch Cookies wieder gefährlich, da sie Nutzerdaten enthalten, welche möglichst nicht in die Hände eines Angreifers fallen sollten. Neuerdings lässt sich mit JavaScript Port-Scanning von LANs über das Internet bewerkstelligen. Dazu später noch mehr.

Mit JavaScript lässt sich allerdings auch der Browser-Verlauf, sprich: History, stehlen. Ein weiterer Angriff auf die Privatsphäre.

Wer den Internet Explorer von Microsoft benutzt, der ist auch weiterhin der Gefahr von bösartigen ActiveX-Controls ausgesetzt, sofern die Benutzung dieser Controls eingestellt oder wenigstens weitgehend eingeschränkt wird (nur Windows Update erlauben o.ä.). Leider lässt sich diese Gefahrenquelle auch in Alternative-Browser integrieren (z.B. Mozilla Firefox). Davon sollte man aber natürlich Abstand nehmen.

Als Ausweg bleibt nur die Deaktivierung von JavaScript. Jedoch geht einem nicht dabei nicht nur viel Komfort verloren, sondern manchmal lässt sich so die Webseite der Wahl gar nicht mehr anständig lesen bzw. generell etwas mit ihr anfangen.

Hier hilft die (seitenweise) Abschaltung von JavaScript. Man lässt auf diese Art nur noch Webseiten zu, denen man vertraut. Dies schützt natürlich nur bedingt vor XSS-Angriffen u.ä. Vor reinen Angriffen auf die Privatsphäre reicht auch die Abschaltung von JavaScript nicht aus, da sich z.B. mit CSS (Cascading Stylesheets) ebenfalls die History des Browsers auslesen lässt. Hier muss man zwar sehr viel Aufwand betreiben, da man keine Liste direkt aus dem Browser auslesen kann, sondern mit einer eigenen Liste von URLs auf die Suche nach Übereinstimmungen gehen muss, aber es potenziell machbar.
Auch basieren die meisten dieser genannten Angriffe nicht auf Fehlern in Browsern. Fehler in Browsern kommen noch dazu, wie man im Fall des Passwort-Diebstahls im Firefox sehen konnte.

SQL-Injections (prinzipiell jede Art von Datenbank als Backend hinter einem Web-Dienst) sind zwar in erster Linie ein Problem für den Server-Betreiber, aber da in Datenbanken fast immer auch irgendwie Benutzerdaten gespeichert werden, wird dies auch zum einem Problem für die eigene Privatsphäre.

Auch kann der eigene Browser mit JavaScript missbraucht werden, um für den Angreifer die Arbeit (andere Webseiten auf Schwachstellen untersuchen) zu erledigen, wie man bei Jikto sehen kann.

Auch AJAX-Frameworks, deren fester Bestandteil JavaScript ist, und heutzutage recht oft und gerne eingesetzt werden (als Beispiel hier Google), sind nicht sonderlich sicher entworfen, was MySpace anhand eines AJAX-Wurms sehen musste.

Da die komplette Deaktivierung von JavaScript keine wirkliche Hilfe ist, da man zu oft darauf wirklich angewiesen ist und die Einschränkung von JavaScript für ausgewählte Webseiten "nur" die Angriffsfläche verkleinert, bleibt dem Nutzer fast ausschließlich nur das, was er bisher gelernt hat oder was er noch lernen kann.

Angriffe, die auf präparierte URLs aufbauen, die dann letztendlich andere Inhalt gelayert (dank XSS) über die aufgerufene Webseite legen oder direkt ein anderes Ziel laden, lassen sich nur mit dem eigenen Verstand abwehren.

Phishing-Filter helfen bei präparierten URLs u.U. nur gerade so weit, dass sie bei bereits identifizierten Schad-URLs warnen. Gerade durch die Internationalisierung von Domainnamen (IDN) sind viele für das Auge gleich aussehende Zeichen hinzugekommen, die sich aber technisch unterscheiden. So wurde schon vor einiger Zeit Daten gephisht, da die Domain vermeintlich richtig aussah, aber dennoch nicht die echte war.

Wie schiebt man einem Benutzer nun solche gefälschten URLs unter ?
Per E-Mail oder Messenger. Das man keine (ungewünschten) Anhänge (fremder) Herkunft öffnet, gar entpackt (mit Passwort) und ausführt, sollte heutzutage bei dem ein oder anderen Benutzer vielleicht doch angekommen sein. URLs in Phishing-Mails evtl. auch, sofern diese noch unbehelligt durch den Phishing-Filter kommen. Beim Einsatz von Messenger sieht das leider noch anders aus. Hier sollte es noch gut möglich sein, irgendwem irgendwelche gefälschten URLs unter zuschieben.
Vor dem (ungewollten) Release von Jikto konnte diese Gefahr durch manipulierte URLs bzgl. XSS o.ä. Angriffen noch als gering angesehen werden, da die Gefahr durch eine gezielt manipulierte Webseite einen Bug im Browser auszunutzen und sich so aller Wahrscheinlichkeit nach administrative Rechte zu sichern, als wesentlich schwerwiegender einzustufen war. Schließlich konnte man sich als Phisher nicht sicher sein, dass derjenige über die Sprache versteht, in der er aufgefordert wird irgendeine Postbank-Webseite in Russland anzusurfen. Nachdem nun irgendwer aber nur aus welchem Grund auch immer den Link klicken muss, um Mittäter einer Attacke zu sein, braucht man keinen hohen Aufwand mehr auf die Ausnutzung von Schwachstellen in Browsern wert legen. JavaScript reicht völlig aus.

Leider sind wir damit noch nicht in der Zukunft angekommen, sondern befinden uns genau da, was heute machbar ist. Die Zukunft wird wahrscheinlich zeigen, dass noch mehr Lücken in AJAX-Frameworks großer Portale gefunden werden und somit Phishern und Spammern viele brauchbare Daten in die Hände spielen werden, ohne dafür groß Zeit zu verbrauchen und Geld ausgeben zu müssen. (Stichwort: StudiVZ)

Auch werden wir in Zukunft vermehrt Varianten von Jikto sehen und weitere Web 2.0-Würmer. Um nun noch einmal auf das Portscanning mittels JavaScript zurückkommen, es werden sicherlich viele Router ,vor allem im heimischen Umfeld, vor JavaScript-basierten Attacken nicht mehr sicher sein, sofern sich jemand einmal hinsetzt und die bisher vorhandenen JavaScript-Portscanner so umschreibt, dass sie sich durch Router-GUIs wühlen können und vorhandene Datensätze zurückschicken. Letztendlich stellt sich dabei nur die Frage, was man damit wirklich "sinnvolles" anfangen könnte.
Eine Methode, die auf jeden Fall funktionieren wird, ist die Methode einen Router unbenutzbar zu machen indem man ein neues Passwort automatisiert vergibt und vorher die Netzwerkeinstellungen verstellt. Die meisten Modelle haben allerdings einen Reset-Knopf, der in solchen Fällen wieder für Abhilfe sorgt. Das Flashen von absichtlich fehlerhafter Router-Firmware sollte auf Grund der Vielzahl unterschiedlicher Geräte sehr unpraktikabel sein. Schließlich wird nicht (immer) jeder Haufen Bits stillschweigend als gültige Firmware akzeptiert, so dass das Gerät sich dann ins digitale Nirvana verabschiedet.
Interessanter ist es da also eher wieder, wenn man SPIs in solchen Geräten deaktiviert oder Port-Forwardings bzw. -Triggers setzt oder UPnP im Router aktiviert (für Viren, Würmer und anderes Getier, welches sich evtl. mal neuer Möglichkeiten bedient).

Ich bin jedenfalls gespannt was noch von anderen kommt und woran ich selber in naher Zukunft mitarbeiten werde. Für den Otto-Normalanwender wird es auf jeden Fall schlimmer werden.

PC WELT: Tipps gegen Phishing

nospam@example.com (Alex) — Sat, 10 Feb 2007 17:46:42 +0100

Die PC-Fachzeitschrift PC WELT hat vor einiger Zeit einen Artikel zu sicherem Online-Banking verfasst in Form von Tipps. Darin enthalten sind auch Tipps gegen Phishing beim Banking. Der Artikel wurde jetzt aktualisiert, enthält aber immer noch große Mankos.

Folgender Tipp ist zwar generell schon ein echter Tipp, aber so beschrieben enthält er einen großen Fehler:

"Kontrollieren Sie, ob die geladene Website verschlüsselt ist. Das erkennen Sie zum einen am „https“ in der Adressleiste und zum anderen am Schloss-Symbol unten im Browser-Fenster. Ein Klick darauf liefert Informationen zum Echtheits-Zertifikat der Site."

Soweit zwar richtig, aber eben nicht ausreichend weit genug beschrieben. Es ist schließlich möglich, dass eine gefakte Webseite ebenfalls ein Zertifikat ausgestellt bekommen hat. Sicherlich richtig ist, dass nicht jede CA ein Zertifikat für seltsame Domainnamen ausstellt, die ersichtlich auf Phishing ausgelegt sind. Jedoch passieren auch da einmal Fehler. Vielleicht klickt bei self-signed Zertifikaten der Benutzer auch einfach die Meldung des Browser darüber genervt weg.

Letztendlich könnte man hier allerdings wieder sagen, dass dieser Tipp soweit okay geht, da die aufgezeigten Ausnahmen schon sehr selten wären.

Was jedoch nicht sehr selten ist, ist XSS - auch nicht bei Banking-Portalen. Somit wäre es bei einigen Portalen ein leichtes, eine beliebige lautende Domain, auf die bereits ein Zertifkat ausgestellt wurde, in das Portal zu integrieren, was somit ein intaktes Schloss-Symbol im Browser zur Folge hätte, da Portal-Seite wie Phishing-Seite verschlüsselt übertragen werden. (Für teilweise authentifizierte Webseiten zeigt der Browser ein gebrochenes Schloss-Symbol an, was widerum beim Browser Firefox und der Auswahl eines Nicht-Standard-Themes teilweise recht schwer zu erkennen sein kann und somit sicherlich bei Otto-Normal-Banker nicht zu einem "Aha"-Erlebnis führt.)

Wer nun nach der empfohlenen Vorgehensweise dieses Tipps dann vorgeht und sich nur das Zertifikat anzeigen lässt, der bekommt von der Phishing-Site nichts mit. Das Zertifikat erscheint deswegen trotzdem korrekt und der kryptografische Fingerabdruck (Hash) dessen lässt sich deswegen genauso erfolgreich überprüfen.

Erst wenn sich jemand durch die anderen Seiteninformationen wühlt (die haben nichts mit dem Zertifikat zu tun), der kann feststellen, dass noch eine andere Site eingebunden wurde. Somit sollte dies zumindest irgendwie ergänzend zu diesem Tipp noch erwähnt werden, da es einfach unvollständig ist und weiterhin das vielseitig zititerte Gerücht "wenn das Schloss-Symbol da ist, ist alles in Ordnung" untermauert.

Eigentlich hätte ich einen passenden Screenshot zu einer solchen bislang wohl noch unbekannten Lücke bei einer Bank parat, aber da ich diese erst noch darüber informieren muss bzw. sollte, gibt es an dieser Stelle weder weitere Hinweise dazu, noch besagten Screenshot zu sehen.