Alex' blog (Artikel mit Tag webbrowser)

Interprotocol Communication/Exploitation - Ein Webbrowser-Vergleich

nospam@example.com (Alex) — Sat, 16 Aug 2008 18:23:17 +0200

Vor ca. 2,5 Wochen hatte ich schon einmal etwas zu Interprotocol Communication/Exploitation geschrieben.

In der Zwischenzeit habe ich einige Webbrowser miteinander verglichen und bin zu folgendem Ergebnis gekommen, welches in der nächsten Zeit sicherlich noch etwas weiter ausgebaut wird.

Interprotocol Communication/Exploitation

nospam@example.com (Alex) — Thu, 31 Jul 2008 19:40:00 +0200

Es ist hinlänglich bekannt, dass Mozilla Port-Blocking für bestimmte Ports vornimmt, damit Interprotocol Communication/Exploitation verhindert wird.

So kann z.B. der beliebte Webbrowser Firefox auf die Ports 20, 21, 22, 23, 25, 110, 111, 113, und viele weitere nicht mittels HTTP zugreifen.

Die vollständige Liste der gesperrten Ports befindet sich hier: http://www.mozilla.org/projects/netlib/PortBanning.html

Heute wollte ich sehen, ob Microsofts Internet Explorer 7 (genauer: 7.0.5730.11) auch über gesperrte Ports verfügt und habe das kurzer Hand schnell getestet: ja, er verfügt über einige wenige Port-Blockaden. Diese lauten wie folgt (ohne Anspruch auf Vollständigkeit):

Doch wie gestalten sich solche Blockaden in anderen Webbrowsern ? Falls jemand Lust und Zeit hat, kann er oder sie gerne hergehen und dies einmal überprüfen. Über eine Rückmeldung würde ich mich freuen, da ich dann selber weniger Arbeit habe und die Ergebnisse gerne in einer Tabelle festhalten würde.

Fritz!BoxDial Wählhilfe und Firefox 3

nospam@example.com (Alex) — Mon, 07 Jul 2008 13:55:00 +0200

Oben: FF2 Unten: FF3

Für die Firefox-Versionen 1.5 und 2.0 gibt es für Besitzer der Fritz!Box eine nette Extension namens Fritz!BoxDial, die Ähnlichkeiten zur Extension von Skype aufweist. Wenn man eine Telefonnummer auf einer Webseite markiert, kann man im Kontextmenü einen Anruf über die Fritz!Box veranlassen und auf dem normalen Telefon telefonieren. Man muss also die Nummer nicht erst abtippen.

Leider funktioniert die Extension mit Firefox 3 nicht mehr.
Eine kurze Analyse hat gezeigt, dass der neue Zwang zur Angabe eines Charsets im Header für einen XMLHttpRequest (XHR) für Probleme seitens der Fritz!Box sorgt. Diese kann mit dem charset=... nichts anfangen und verweigert ihren Dienst.

Selbst wenn man explizit keine charset-Angabe in der Methode requestHeader() macht, so wie es die Extension auch tut, setzt Firefox 3 nun standardmässig das Charset rein (auf UTF-8).

Hat irgendjemand eine Idee, wie man Firefox 3 von diesem Zwang befreien kann ?

Firefox 3 ist fertig

nospam@example.com (Alex) — Wed, 18 Jun 2008 16:05:00 +0200

Firefox 3 ist nun fertig und daher habe ich das u.a. zum Anlass genommen, um meinen RC 2 auf die finale Version upzudaten.

Da ich heute früh endlich Windows Vista auf dem Acer Aspire 7520G entfernt habe und nun Windows XP (für knapp 67 EUR) auf dem Laptop seine Arbeit anstandslos verrichtet, habe ich mich gleich an die Installation von Firefox 3 gemacht. Gut, dass auf dem schnelleren Laptop der langsame Firefox nicht so sehr auffällt. Evtl. ist das vor ein paar Tagen beschriebene Problem gar nicht existent ...

Daher habe ich zweimal beim Download Day mitgemacht und spaßeshalber habe ich mir auch ein "Zertifikat" dafür ausgestellt.

Wer beim Download Day und dem damit verbundenen Eintrag ins Guinness Buch der Rekorde mitmachen will, der hat nach MESZ noch bis heute 19:00 Uhr Zeit dazu.

Nachdem bei mir aber vieles nicht mehr anständig funktioniert, seitdem ich den Firefox 3 mit einer der verfügbaren Beta-Versionen installiert habe, muss ich wohl oder übel ein neues Profil erstellen und sämtliche Werte, die ich von Hand angepasst habe, erneut anpassen. ~~Das wird wieder viel Arbeit ...~~

Update: Oder auch kaum Arbeit, wenn man die Datei prefs.js zur Hilfe nimmt.

Feed-Reader für Windows Mobile 6

nospam@example.com (Alex) — Sun, 27 Apr 2008 04:37:00 +0200

Momentan bin ich noch etwas auf der Suche nach brauchbarer und sinnvoller Software für meinen neuen PocketPC, den T-Mobile MDA Vario III.

Da ich bislang noch keinen freien Feed-Reader finden konnte und der Feed-Reader im Opera Mini mir etwas suspekt und langsam erscheint, habe ich jetzt meinen eigenen erstellt. Er ist allerdings auch noch nicht ganz fertig, läuft aber schon recht problemlos.

Jetzt suche ich nur noch einen Webbrowser oder ein passendes Add-On für den IE, Opera Mini, Opera Mobile oder auch MiniMo, welches den Quelltext einer Webseite anzeigen kann.

Außerdem wäre ein besseres und freies E-Mail Programm nicht schlecht, da man mit dem integrierten keine E-Mails von seinem T-Online-Account verschicken kann, wenn dies verschlüsselt geschehen soll.

Einen freien Jabber-Client suche ich ebenfalls, da MGTalk nicht funktioniert.
Ein Programm für einen Countdown und für eine Stoppuhr suche ich ebenfalls noch. Das solche Standard-Anwendungen fehlen, ist schon etwas seltsam. Sind sie doch fast bei jedem Handy dabei.

Wahrscheinlich muss ich für einiges wieder selber in die Trickkiste greifen. Für Vorschläge, Empfehlungen oder Anregungen bin ich allerdings jederzeit offen.

HTTP Auth Probleme mit Mozilla Firefox 3 Beta 5

nospam@example.com (Alex) — Mon, 21 Apr 2008 10:59:00 +0200

Seitdem ich etwas an der neusten Firefox-Version aus der Zweier-Reihe verzweifelt bin, habe ich den Schritt zur neusten Beta-Version der Dreier-Reihe gewagt. Leider hat es an meinem Problem nicht wirklich etwas verbessert (Änderung an Dateityp => Aktion).

Dafür hat mir die neue Version gleich ein neues Problem beschert: wenn man ein Bookmark zu einer Webseite anlegt, die vor dem eigentlichen Abruf erst mittels HTTP Auth Logindaten bearbeitet werden muss, und diese in der Form:

https://benutzername:passwort@example.com/pfad

eingibt, so funktioniert dies in der neusten Beta leider nicht mehr automatisch. Jetzt muss man sie wieder händisch eingeben. (Vielleicht betrifft dies neuerdings auch nur SSL-verschlüsselte Verbindungen. Unverschlüsselte habe ich nicht getestet.)
Hoffentlich bleibt diese Einschränkung nur bis zur Final. Es war doch recht bequem.
(Ja, auch unsicher, solange man keine anderen Vorkehrungen trifft.)

Leider ist dies bei HTTP/HTTPS auch nicht über ein RFC standardisiert, sondern nur bei FTP. Trotzdem machen es alle Webbrowser, die mir so einfallen, dennoch richtig.

Firefox 3.0 und CAcert-Probleme

nospam@example.com (Alex) — Sat, 22 Mar 2008 22:10:00 +0100

Ich habe mir vor einigen Tagen die neuste Vorab-Version von Firefox 3.0 angeschaut. Die Neuerung "ausführliche Zertifikatsfehlermeldungen" ist immer noch enthalten.

Das gibt, wie ich hier schon einmal erwähnt hatte, auf jeden Fall Probleme für Betreiber von Webseiten mittels CAcert-Zertifikat (oder einem self-signed Zertifikat).

Da der Nutzer nicht mehr zur Interaktion gezwungen wird, wie eins mit dem Dialogfeld, dessen Voreinstellung das temporäre Erlauben der Webseite gewesen wäre, werden sicherlich viele Nutzer die Webseite verlassen, bevor sie sie richtig aufgesucht haben.

Da CAcert als CA auch im Firefox 3.0 noch nicht dabei sein wird (abgesehen von einigen Linux-Distributionen, die CAcert als CA gleich dazupacken), werden meiner Ansicht nach viele Nutzer aus Sicht des Betreibers einer Webseite ausgesperrt werden. Andererseits ist es eine ausführliche Warnung natürlich besser für die Sicherheit.

Wenn ein Nutzer nun das Zertifikat akzeptieren will (egal ob temporär oder permanent), so durchläuft er folgende Screenshot-Abfolge:

Schritt 1:

Schritt 2:

Schritt 3:

Schritt 4:

Anzahl nötiger Klicks bei permanenter Annahme des Zertifikats: 4
Anzahl nötiger Klicks bei temporärer Annahme des Zertifikats: 5

Zudem hat sich die Voreinstellung für die Annahme des Zertifikats unbekannter CAs geändert: die neue Voreinstellung ist "permanent". Nicht mehr "temporär".

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:

Neuer XSS-Angriffsvektor

nospam@example.com (Alex) — Sat, 05 Jan 2008 19:49:22 +0100

Nicht wirklich neu, aber er fehlt noch in RSnakes XSS Cheat Sheet:

<img src=. onerror=alert('XSS')>

Getestet in Firefox 2.0.0.11, Opera 9.25, Internet Explorer 7 und Safari 3.04 Beta (Windows).

Allerdings gibt es noch einige andere Varianten, die wie folgt funktionieren:

0<img src=\ onerror=alert(0)>FF2: 0 / IE7: 1 / O: 1 / S: 1 1<img src="/" onerror=alert(1)>FF2: 0 / IE7: 1 / O: 1 / S: 1 2<img src="." onerror=alert(2)>FF2: 1 / IE7: 1 / O: 1 / S: 1 3<img src="" onerror=alert(3)>FF2: 1 / IE7: 1 / O: 0 / S: 0 4<img src=. onerror=alert(4)>FF2: 1 / IE7: 1 / O: 1 / S: 1 5<img src=/ onerror=alert(5)>FF2: 0 / IE7: 1 / O: 1 / S: 1 6<img src= onerror=alert(6)>FF2: 0 / IE7: 0 / O: 0 / S: 0 7<img src onerror=alert(7)>FF2: 1 / IE7: 0 / O: 0 / S: 0 8<img onerror=alert(8)>FF2: 0 / IE7: 0 / O: 0 / S: 0 9<img src="\" onerror=alert(9)>FF2: 0 / IE7: 1 / O: 1 / S: 1(0 = funktioniert nicht; 1 = funktioniert)

XSA-Artikel in Hakin9

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

Ich hatte für die Ausgabe 10/2007 des Magazins Hakin9 einen Artikel über Cross-Site Authentication (XSA) Angriffe verfasst. Da ich heute mal wieder etwas mit HTTP-Auth zu tun hatte und ich damals über den Angriff mittels eines Perl-Moduls (für Apache) geschrieben habe, möchte ich hier nun noch eine Ergänzung vornehmen:

Wer statt Perl lieber PHP benutzen möchte, der kann sich der zwei Variablen $_SERVER['PHP_AUTH_USER'] und $_SERVER['PHP_AUTH_PW'] bedienen. Auf diese Art und Weise braucht man weder mod_perl noch das vorgestellte Perl-Modul selbst. So muss nach der beschriebenen XAMPP-Installation das Perl-Installationspaket nicht mehr installiert werden.

Spoofing-Schwachstelle im Webbrowser Firefox

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

Aviv Raff hat eine neue Spoofing-Schwachstelle in der HTTP-Auth Authentifizierung im Webbrowser Firefox gefunden.

Details zur Lücke hat er bislang nicht veröffentlicht. Nur einen Screenshot der Authentifizierungs-Dialogbox.

Hiermit veröffentliche ich ebenfalls nur einen Screenshot einer (weiteren !?) Spoofing-Schwachstelle, die aber ausschließlich durch den Benutzer zustande kommt.
Ob es letztendlich der gleiche Fund ist, wird sich nach einer detailierteren Beschreibung Raffs zeigen.

Leider macht einem der deutsche Satzbau in Firefox einen Strich durch die Rechnung. Wer nun einen geschickten deutschen Satz zusammenbekommt oder nur auf die englischsprachige Firefox-Version setzt, hat keine weiteren Probleme. So ist der Satzbau noch fehlerhaft - spaßeshalber habe ich Raffs Realm 1:1 übernommen. Eigentlich ist das von der Schwierigkeit her eine "0815-Lücke", die sowohl bei Basic- als auch Digest-Authentifizierung funktioniert.

Wer es selber einmal ausprobieren will: http://testing.bitsploit.de
(Nur für kurze Zeit verfügbar.)

DNS Rebinding and more packet tricks

nospam@example.com (Alex) — Fri, 28 Dec 2007 00:26:00 +0100

Genialer Vortrag von Dan Kaminsky auf dem 24C3.
Lustiger Mensch mit absolut krassen Ideen (TCP over JSON / IP over Spam / etc.). Respekt !

(Er wäre auch ein prima Entertainer.)

Firefox-Extension: InFormEnter

nospam@example.com (Alex) — Tue, 11 Dec 2007 23:36:00 +0100

Eben bin ich über die Firefox-Extension "InFormEnter" gestolpert, welche eigentlich die Aufgabe hat vordefinierte Zeichenketten per Mausklick in jedes Formularfeld einfügen zu können. Dazu befindet sich neben jedem Feld ein Symbol über dieses dann die gewünschte Zeichenkette eingefügt werden kann. So lässt sich bequem die eigene Adresse oder Telefonnummer mittels Mausklick einfügen.

Jedoch kann man dieses Tool auch etwas zweckentfremden und Injection-Zeichenketten (SQL, JavaScript, etc.) abspeichern. So fällt das lästige Copy & Paste aus den eigenen Cheatsheets weg.

Meinen Blog-Eintrag "Hacken von Web-Applikationen mit Firefox-Extensions" habe ich dazu passend aktualisiert.

Wie Webseiten PCs (auch anders) kompromitieren (könnten)

nospam@example.com (Alex) — Sat, 08 Dec 2007 17:49:00 +0100

Der neuste Bericht über Botnetze bei Spiegel Online erweckt bei mir den Eindruck, dass Webseiten Computer nur mittels des Webbrowsers infizieren können. Dies stimmt natürlich nicht.

Ok, schädliche E-Mails können sie dem Surfer zwar so wirklich nicht schicken mangels Kenntnis über dessen E-Mail-Adresse. Aber man braucht dafür auch gar keine weiteren ungepatchten Programme auf Clientseite ins Spiel zu bringen (Flash Player, MUA, etc.).

Das Zauberwort heißt "User-Agent".

Der User-Agent verrät der Webseite eine Menge Informationen über das eigene Betriebssystem und zum Teil auch über die ein oder andere installierte Software.

Über die so gewonnenen Informationen kann die Webseite halbwegs gezielt vorhandene Exploits an die IP-Adresse des Client schicken - gewisse Voraussetzungen müssen dafür natürlich auf Clientseite (nicht) erfüllt sein: Firewall, NAT, Port-Forwarding, etc.

Anhand des User-Agents des Webbrowsers lässt sich verwendete Sprache feststellen sowie das verwendete Betriebssystem. Im Falle von Windows zum Teil "relativ" detailiert mit Service Pack-Angabe.

Mit dem Hintergrundwissen von verwendetem Betriebssystem und dessen Version, evtl. installierten Service Pack und verwendeter Sprache lässt sich natürlich schon recht gut der passende Exploit auswählen. So braucht der Angreifer, der hinter einer schädlichen Webseite steckt, nicht alle möglichen Exploits auf die Ports des Opfers loslassen.

Manchmal kann der User-Agent noch geschwätziger sein und noch ein paar weitere Informationen ausliefern, wie z.B. hier:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

Hier kann man sehen, dass das .NET Framework installiert wurde und vor allem in welchen Versionen.

Das Abschalten des User-Agents hilft hier weiter. Zumindest kann man die Zeichenfolge etwas mehr den eigenen Bedürfnissen anpassen, da sich einige "gute" Webseiten auch auf den User-Agent des Webbrowsers verlassen.
Für die Benutzer des Internet Explorer sei auf diese Webseite von Microsoft verwiesen, da sie es etwas aufwändiger haben als z.B. die Benutzer von Firefox.

Man könnte natürlich noch schreiben, dass ein vorgeschaltener Web-Proxy oder ein Anonymisierungsnetzwerk die eigene IP-Adresse verbergen kann, aber es gibt genug Möglichkeiten (z.B. mit Java bzw. mit LiveConnect via JavaScript), um dennoch den Exploit an die richtige WAN-IP-Adresse zu schicken.