Alex' blog (Artikel mit Tag plugins)

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 ?

XSS-Schwachstelle in Serendpity-Plugin Freetag

nospam@example.com (Alex) — Thu, 07 Feb 2008 20:30:00 +0100

Ich habe vor ein paar Tagen eine Cross Site Scripting (XSS) Schwachstelle in einem sehr beliebten Plugin für die Weblog-Software "Serendipity" namens "Freetag" gefunden.

Das Advisory zur Schwachstelle gibt es hier.

Um es kurz zu machen: es gibt bereits ein Update, welches dringendst eingespielt werden sollte, sofern man das Freetag-Plugin integriert hat !
(Der aktuelle XSS-Vektor ist auf IE 6, IE 7 und Netscape Navigator 8.1 (im IE-Rendering Mode) ausgelegt.)
Ein Eintrag von Garvin Hicking befindet sich dazu hier.

Im Gegensatz zu meinen sonst rein deutschsprachigen Beiträgen hier im Blog, ist das Advisory selbstverständlich in englischer Sprache gehalten ! Es ist momentan aber noch nicht online, da es eigentlich erst für morgen geplant war.

Update: Advisory ist nun online. / Advisory is now online.
Mit einem entsprechenden Google Dork lassen sich leicht unzählige verwundbare Webseiten finden. Dieser Google Dork wird zur Sicherheit allerdings nicht veröffentlicht werden.

Update 2: CVE-Candidate: CVE-2008-0751.

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.

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.

CVE Extension für Firefox 2 und Internet Explorer 7

nospam@example.com (Alex) — Fri, 19 Oct 2007 01:00:00 +0200

Eben habe ich festgestellt, dass ich gar keine Such-Engine für CVEs im Browser integriert habe. Auf die Schnelle habe ich bei Google auch noch keine Engine im OpenSearch-Standard gefunden, so dass ich mal wieder meine eigene Extension für Firefox 2 und IE 7 geschrieben habe.

Zur Installation einfach HIER klicken.

Update: Das führende "CVE-" ist optional und muss somit zur Suche nicht zwingend angegeben werden.

QuickReferrer Extension für Firefox 2.x

nospam@example.com (Alex) — Mon, 13 Aug 2007 00:19:00 +0200

Ich habe eine kleine Extension für den Firefox 2.x von Mozilla zusammengebastelt, welche das schnelle Ein- und Ausschalten der Übertragung des Referrers per Mausklick erlaubt.

Der Referrer (korrektes Englisch) bzw. Referer (falsches Englisch, aber stark verbreitet auf Grund eines Schreibfehlers im RFC 2068) kann über einen (momentan noch sehr hässlichen) Button, der frei in der Navigationsleiste platzierbar ist, nach Belieben ein- und ausgeschalten werden. So braucht man nicht immer umständlich mittels "about:config" den Referrer verändern.

Die Projektseite mit dem Download und einigen Erklärungen befindet sich hier: http://quickreferrer.projects.bitsploit.de

Updates to come ...

Extensions für Mozilla Thunderbird 2.0.0.5 fit machen

nospam@example.com (Alex) — Sat, 21 Jul 2007 15:23:00 +0200

Nachdem mein Beitrag "Extensions für Mozilla Thunderbird 2.0.0.0 fit machen" so reißenden Anklang gefunden hat - nicht nur über Kommentare, sondern vermehrt als Anfrage per E-Mail - hier nun ein Kommentar zu der am gefragtesten Extension überhaupt: "Auto Copy".

"Auto Copy" funktioniert hier bis einschließlich Mozilla Thunderbird-Version 2.0.0.5 ohne Probleme.
Diese Extension anzupassen ist besonders leicht, da man dazu eigentlich fast nichts machen muss. Man muss nur die XPI-Datei speichern, mit irgendeinem Programm, welches das ZIP-Format beherrscht, entpacken und dann die Datei install.rdf in einen Editor freier Wahl laden. Dort sucht man den Eintrag für Thunderbird (weit unten) und ändert die maximale Versionsnummer von 1.6a o.ä. auf z.B. 2.0.0.5. (Platzhalter mit * funktioniert bei mir irgendwie nicht). Abspeichern und schön wieder zusammenpacken. Nun installieren und "Auto Copy" funktioniert wieder wie früher. Wer die besagte Extension bereits installiert hat, der muss nur noch die install.rdf modifizieren.

Das es so viele Anfragen geben wird, hätte ich auch nicht gedacht. Jetzt wäre es eigentlich zeitsparender für mich und alle Fragenden gewesen, wenn ich die Lizenz damals doch schon durchgelesen und dann gegebenenfalls die modifizierte Version direkt zum Download angeboten hätte ... vielleicht sollte ich mir jetzt doch einmal die Mühe machen und die Lizenz lesen, so dass vielleicht in Zukunft die von mir modifizierten Versionen hier angeboten werden können.

reCAPTCHA Plugin für Serendipity

nospam@example.com (Alex) — Sat, 02 Jun 2007 10:32:00 +0200

Ich habe die Idee von reCAPTCHA nur kurz überflogen, aber dass was ich mitbekommen habe, hört sich brauchbar an. Ob es vielleicht doch noch einen sicherheitstechnischen Haken hat, mag ich im Moment noch nicht zu sagen, da, wie bereits erwähnt, ich es mir noch nicht genau angeschaut habe.

Was das Überfliegen allerdings erbracht hat, ist folgendes: reCAPTCHA setzt auf Bilder von fehlerhaft erkannten Texten durch OCR-Software. Die Algorithmen, die OCR-Software an den Tag legt um Texte richtig zu erkennen, sind sicherlich nicht schlechter als die Algorithmen von Spammern, die Captchas zu erkennen versuchen.

Es wird also davon ausgegangen, dass solche Bilder automatisierten Spam draußen halten. Die für OCR-Software unguten Scans soll es zentral auf einem Server geben, die dann durch ein Plugin in Serendipity angefordert werden, um dem Benutzer danach zur richtigen Eingabe vorgelegt werden. Natürlich ist das Verfahren nicht nur auf das Weblog-System Serendipity beschränkt.

Ich persönlich finde, dass einige Beispielscans schon hart an die Grenze des menschlich lesbaren gehen. Also bei dem ein oder anderen Wort habe ich schon meine Schwierigkeiten gehabt. Daher werde ich es wahrscheinlich in meinem Blog nicht einsetzen. Schließlich will ich mögliche Kommentatoren auch nicht ausschließen, nur weil er oder sie vielleicht nach mehrmaliger Fehleingabe keine Lust mehr hat.
(All dies abgesehen von einer sicherheitstechnischen Evaluierung.)

Vulnerable Adobe Acrobat plugin detection for UXSS

nospam@example.com (Alex) — Fri, 01 Jun 2007 22:03:40 +0200

Ich habe mich heute ein wenig mit Ronald van den Heetkamp, wahrscheinlich besser bekannt als jungsonn, über UXSS (Universal XSS) unterhalten.

Die Frage war, ob sich schon jemand mit der Detektion von anfälligen Adobe Acrobat Reader Installationen beschäftigt hat. Es schien nicht so.

Daher ist ein JavaScript herausgekommen, welches zuerst auf einen installiertes Adobe Acrobat Plugin prüft und wenn vorhanden, dann die Version ermittelt, um letztendlich sagen zu können, ob man ein Problem hat oder nicht.

Weil Ronald wesentlich schneller als ich darüber gebloggt hat, siehe auch sein Blog-Eintrag hier (inkl. Skript).

Wenn man ein Problem hat, dann ist man anfällig für XSS-Angriffe, die sich des Vorhandenseins eines beliebigen PDF-Dokuments bedienen, um ausgeführt werden zu können. Bei den (definitiv) verwundbaren Versionen 6.x und 7.x (außer 7.9) muss JavaScript im Acrobat aktiviert sein, was allerdings die Standardeinstellung ist, um einem UXSS-Angriff erliegen zu können.

Das Skript prüft momentan noch nicht auf Versionen kleiner 6.x, weil dort erst noch geklärt werden muss, ob UXSS-Angriffe funktionieren. Angeblich ist seit Version 3.x von ungefähr 1996 JavaScript in PDF-Dokumenten möglich. Version 7.9 ist laut Christ1an bereits auch nicht mehr verwundbar. Version 8.x bekannterweise auch nicht.

Diese Erkennungs- und warnroutine kann zum Beispiel in die Projekte "Black Dragon" (von Ronald van den Heetkamp) und in Robert Hansens (besser bekannt als RSnake) "Master Recon-Tool" (kurz: "Mr. T"). integriert werden.

Update: Auf einer alten CD habe ich noch einen Adobe Acrobat Reader 5 gefunden und auch gleich mal installiert, um testen zu können, ob die Version überhaupt für UXSS anfällig ist und ob man dementsprechend davor warnen müsste und somit das Skript abgeändert werden sollte.
Aus einem mir bislang unerfindlichen Grund mag der Acrobat 5.01.x aber nicht starten. Sei es drum. Aber das Plugin im Firefox funktioniert - also zumindest ist es korrekt installiert - und der daraus ausgelesene String passt vom Schema her zu den Versionen 6.x - 7.x. Nachdem ich dann ein wenig im Internet gesucht habe, ist mir ein Kommentar in Jeremiah Grossmans Blog aufgefallen, der aussagt, dass der IE 6.0 mit SP2 und Acrobat 5.x anfällig für UXSS ist. Wenn man ausgeht, dass dieser Kommentar von einer anonymen Person (ich kann also nicht nachfragen) stimmt, dann sollte man das JavaScript zwecks Benutzerwarnung nun minimal abändern. (Wegen Trivialität gibt es hier dazu keinen Quellcode.)
Fraglich sind also weiterhin Versionen vor 5.x.

Cookies, Flash-Cookies, Super-Cookies, DOM Storage und XSS

nospam@example.com (Alex) — Fri, 11 May 2007 04:39:02 +0200

In Zeiten von XSS sieht man häufiger Beispiele, die Cookies an Angreifer verschicken. Das XSS weitaus mächtiger ist braucht wohl kaum erwähnt werden.

Dies klappt deshalb, weil Skript-Code (z.B. JavaScript) auf Cookies im eigenen Seitenkontext beliebig zugreifen darf. In der Spezifikation für Cookies gibt es noch einige Attribute, die man ihnen bei der Erstellung auf den Weg geben kann wie "secure" und die (sinnvolle) Erweiterung von Microsoft namens "HttpOnly".

Das Attribut "HttpOnly" bedeutet, dass Cookies nicht mehr länger über clientseitigen Skript-Code angetastet werden kann. Sonst bleibt alles beim Alten. (Der Vollständigkeit halber will ich das Attribut "secure" hier nicht unterschlagen: Es bedeutet, dass der Cookie nur über SSL- / TLS-gesicherte Verbindungen vom Browser verschickt werden darf.)

Gesetzt müssen die Attribute von der jeweiligen Web-Applikation werden und der Browser hat sich danach zu richten, sofern er damit umzugehen weiß.

Z.B. ist der Mozilla Firefox 2.x bislang nicht in der Lage HttpOnly-Cookies richtig zu behandeln. Die ersten Alpha-Versionen der Version 3.0 beherrschen dies aber endlich. Microsoft hat seit dem SP1 für den Internet Explorer 6.0 HttpOnly-Cookie-Behandlung in seinen Browser integriert.
Stefan Esser hat für den Firefox 2.x eine Extension namens httpOnly herausgebracht, die den Skript-Zugriff von Seiten des Browsers her unterbinden soll. (Tests von meiner Seite her stehen noch aus.)

Momentan beschäftige ich mich mit der Frage, wie man an solche Cookies dennoch herankommt.
ActiveX, JScript und Flash habe ich mir bislang nicht angeschaut, wobei ich auch vermute, dass zumindest JScript keinen Zugriff auf HttpOnly-Cookies bekommen sollte. Java-Applets dürfen von ihren Sicherheitsrichtlinien her nicht auf Cookies zugreifen, so dass man einer für XSS anfälligen Web-Applikation kein Java-Applet unterschieben zu braucht.
Über ein spezielles Package von Netscape (netscape.javascript.*) kann man aber von Java aus auf JavaScript-Objekte zugreifen. Im Moment bin ich dabei ein Java-Applet zu schreiben, welches über diese Art und Weise versucht die zuvor abgespeicherten Cookies auszulesen und auf dem Server abzulegen. Inwieweit diese alten Netscape-Klassen in neuen Browsern (außer Netscape und vielleicht Mozilla) noch funktionieren, wird sich zeigen. Unklar ist bislang auch noch, ob sich so der (angebliche) Schutz der Cookies aushebeln lässt, da sich letztendlich eigentlich doch nur wieder JavaScript an den Cookies vergreift.

Als Ergänzung zu dieser Sache ein Überblick über die verschiedenen Cookie-Varianten (siehe Titel).

Es gibt verschiedene Varianten zur Speicherung von Cookies und noch viel mehr Namen für sie.

Flash-Cookies werden, wie es der Name schon sagt, von Flash benutzt und liegen nicht im Benutzerprofil des verwendeten Webbrowsers. Auch werden sie nicht gelöscht, wenn man den Browser dazu auffordert. Genaueres dazu hier. Flash-Cookies werden auch gerne als Super-Cookies bezeichnet.

DOM Storage ist mehr oder weniger das, was ein üblicher Cookie ist. Der Unterschied besteht darin, dass der Cookie-Inhalt nun wesentlich größer ausfallen darf und das die Domain nicht mehr exakt mit der Ur-Domain übereinstimmen muss. Eine kurze Zusammenfassung befindet sich hier und wesentlich detailierter erklärt hier.
Dies war jetzt Mozilla bezogen, aber auch Microsoft hat nachgezogen. DOM Storage wird auch gerne als Super-Cookie bezeichnet.

E-Mailen mit der D-box 2

nospam@example.com (Alex) — Fri, 27 Apr 2007 01:43:50 +0200

Eigentlich wollte ich einmal meine E-Mails mit der D-box 2 abholen bzw. dank einer Menge IMAP-Konten diese mir anzeigen lassen, was aber das E-Mail-Plugin an seine Grenzen bringt.

Neuzeitigen Standards scheint das Plugin nicht zu beherrschen. Ich habe ausschließlich Konten, die ich per SSL bzw. TLS abrufe. Verschlüsselten Verbindungsaufbau unterstützt das Plugin wohl aber nicht. Abgesehen davon lässt sich nicht einstellen, ob man POP-before-SMTP braucht oder nicht. Nur die Eingabe von Zugangsdaten für SMTP ist möglich, wenn diese anders lauten sollten als die für den POP3- bzw. IMAP-Zugang.

Bislang sieht es so aus als würde man die Konfiguration aller Accounts über das OSD zwar per Code schützen können, aber diese Schutzmaßnahme funktioniert nicht. Die Sperrung eines Accounts vor der Einsicht durch Nichtberechtigte funktioniert allerdings. Da man aber in die Konfiguration kommt, ist dieser Schutz hinfällig.

Gibt es versteckte Optionen für die Konfigurationsdatei, welche einfach nicht im Tuxbox-Wiki stehen oder ist das Plugin wirklich soweit ab vom aktuellen Stand der Technik ?

OpenSearch-Plugin für Bitsploit.de

nospam@example.com (Alex) — Fri, 24 Nov 2006 03:33:57 +0100

Ich habe eben ein OpenSearch-Plugin für die Browser Firefox 2.0 von Mozilla und Internet Explorer 7.0 von Microsoft für die integrierte Suche im Serendipity-Weblog fertiggestellt. Zudem sollte zumindest im Firefox das Icon der Web-Suche hellblau aufleuchten, wenn man mein Blog besucht. Wer den IE 7.0 benutzt, der bekommt einen orangenen Hinweis zu sehen. Im Pulldown-Menü taucht der neue Eintrag zur Installation bei beiden Browsern ebenfalls auf. Die Installation des Plugins ist so auch ohne JavaScript mit dem Pulldown-Menü der Web-Suche möglich.

Wer für meine Domain genug Vertrauen aufbringt und JavaScript erlaubt hat, der kann auch hier klicken um die Installation zu starten. (Natürlich bietet aktiviertes JavaScript auch sonst etwas mehr Komfort auf meinen Seiten.)

Dieses Such-Plugin kann auch gern jeder andere Serendipity-Benutzer einsetzen, sofern er oder sie dazu gewillt ist. Der Code dafür ist wie folgt ...

Der Code der XML-Datei, hier opensearch.xml, für ein OpenSearch-Plugin (Version 1.1) lautet für Serendipity-Benutzer wie folgt:

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
xmlns:moz="http://www.mozilla.org/2006/browser/search/">
<ShortName>Kurzer Name wie z.B. Google</ShortName>
<Description>Beschreibung</Description>
<InputEncoding>So wie benötigt, z.B. UTF-8</InputEncoding>
<Image width="16" height="16">http://deinedomain.tld/opensearch_icon.ico</Image>

<Url type="text/html" method="GET" template="http://deinedomain.tld/index.php?serendipity[action]=search&amp;serendipity[searchTerm]={searchTerms}" />

</OpenSearchDescription>

Für die direkte Einbindung in das Pulldown-Menü zur Installation und den optischen Hinweis auf ein zur Verfügung stehendes Such-Plugin im Firefox 2.0 fügt man zwischen die <head>-Tags folgendes Tag ein:

<link rel="search" type="application/opensearchdescription+xml" title="Kurzer Name" href="http://deinedomain.tld/opensearch.xml" />

Wer noch Suchvorschläge anzeigen lassen will, der muss weitere Arbeit ins Blog stecken. Vielleicht mache ich mir demnächst noch die Mühe dafür.

Google Malware OpenSearch-Plugin für Firefox 2.0

nospam@example.com (Alex) — Thu, 02 Nov 2006 18:00:00 +0100

Google indexiert neben HTML-Seiten u.a. nun auch binäre Dateien mit PE-Header. So kann man durch die Signatur eines PE-Headers auf die Suche nach Dateien gehen. H.D. Moore hat eine kleine Malware-Datenbank aufgebaut, die nach Eingabe eines z.B. Trojaner-Namens mittels Google nach infizierten Dateien sucht.

Da mir langweilig war, habe ich dafür ein kleines Such-Plugin im OpenSearch-Standard (Version 1.1) für Mozillas Firefox 2.0 geschrieben.

Zur Installation HIER klicken.

Viel Spaß damit !

Update: da gibt es etwas, was ich vergessen habe zu erwähnen: das Such-Plugin läuft so auch direkt im Internet Explorer 7.0 von Microsoft. Somit ist das Plugin nicht nur auf den Firefox 2.0 (aufwärts) beschränkt.