Alex' blog

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:

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

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.

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.

PoC:

Update: So wie es aussieht wird der dieser Bug in Firefox 2.0.0.4 und 1.5.0.12 behoben sein.

Update 2: So funktioniert es auch von extern, anstatt nur lokal. Allerdings kann nur auf vorher bekannte Benutzernamen getestet werden, anstatt nur die vorhandenen auszulesen.

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

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