Wie man es nicht machen sollte - revisited
16 01 2008 16:33Und ja, es wurde dem Mobilfunk-Provider gemeldet (mit Rückantwort).
Kategorien : .hacking
Trackbacks : Keine Trackbacks »
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:
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.)
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.
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.
"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.
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):
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. ![]()