Wie man es nicht machen sollte - revisited

16 01 2008 16:33
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 !

15 01 2008 14:42
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

03 01 2008 15:25
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

12 12 2007 23:19
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

25 07 2007 04:24
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

19 07 2007 12:51
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

29 06 2007 14:25
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. ;-)