XSS-Sicherheitslücken in VKontakte

Vor Kurzem machte ich mich an die Vorbereitung der neusten Untersuchung zu Web-Sicherheitslücken, insbesondere XSS-Attacken. Dafür musste ich mich zunächst einmal mit einigen Besonderheiten in modernen Filtersystemen auseinandersetzen.

Als Zielseite für meine Tests wählte ich die im russischen Teil des Internets meist besuchte Seite – vkontakte.ru, ein äußerst populäres russischsprachiges soziales Netzwerk. Mein Interesse galt dem Status-Updatesystem.

Die HTML-Seite, wo die Statusveränderungen umgesetzt werden, sieht folgendermaßen aus:

Wie man sieht, befindet sich der Filter direkt in der Funktion infoCheck(). Der Status selbst ist in der folgenden Zeile untergebracht:

In diesem Fall liegt eine zweistufige Filterung vor. Die erste Stufe ist die direkte Filterung beim Anwender während der Eingabe seines Status. Die zweite besteht in der Umwandlung des eingegebenen Status in Text und seine Rückkehr auf die Seite in der Form, wie er anderen Usern auf der Seite erscheint.

Während die zweite Filterstufe zweifellos einwandfrei funktioniert und das vom Anwender Eingegebenen eindeutig nicht in aktives XSS umgewandelt werden kann, läuft bei der ersten Stufe nicht alles so glatt. Und genau um diese erste Stufe geht es hier auch.

Wie angenommen, funktionierte ein einfaches <script>alert()</script> nicht, und der Status blieb leer. Variationen über das Thema „script“ zeigten auch keine Wirkung – allem nach zu urteilen wird konkret diese Reihenfolge eindeutig gefiltert.

Allerdings ist für die Ausführung des Skripts der Tag <script> gar nicht zwingend erforderlich. Die erste Sicherheitslücke auf dem Rechner des Anwenders wird durch Verwendung des Tags <img> erreicht: Fügt man in den Status die Zeile <img src=1.gif onerror=some_function> ein, so erreicht man die Ausführung eben dieser Funktion. Zur Anschaulichkeit kann man die Funktion profile.infoSave() aufrufen, die mit einem leeren Argument bei der Säuberung des Status verursacht wird. Gibt man also <img src=1.gif onerror=profile.infoSave(‚XSS‘)>, so erhält man im Status die Zeile “XSS”:

Die zweite bemerkenswerte Schwachstelle des Filters besteht in der fehlenden Filterung des Tags <A>. Gibt man im Status <A HREF=“//www.google.com/“>XSS</A> ein, erhält man … einen Hyperlink. Klickt man auf diesen, so öffnet sich das Fenster zum Bearbeiten des Status und einen Augenblick später – die Website google.com!
Wie wir wissen, ist XSS = cross site scripting, daher entschloss ich mich in der nächsten Sicherheitslücke, eine Drittseite mit einem darauf geladenen Skript zu benutzen. Neben der fehlenden Filterung der oben genannten Tags flutscht auch der Tag <iframe> durch den Filter. So erhält man mit der Eingabe <iframe src=“yoursite.com“ width=“100%“ height=“300″> in der Statuszeile, einen iframe mit dem Start des geladenen Skripts. Hier ein Beispiel eines solchen „iframe“:

Diese Sicherheitslücke ist noch ernstzunehmender als die zwei vorher beschriebenenеn. Sie kann unter anderem so ausgenutzt werden, dass eine URL für die Änderung des Anwender-Status zusammengestellt werden kann und der nächste Klick des Anwenders über diese URL macht ihn zum Opfer. Noch bevor der Status veröffentlicht wird, wird das Skript auf der Seite des Anwenders ausgeführt. Auf diese Weise haben wir es mit einem klassischen passiven XSS zu tun.

Die Sicherheitslücken sind seit dem 01.08.2010 aktuell – seit Einführung des neuen Status-Systems. Am 01.03.2011 haben wir die Administration des Netzwerks VKontakte über die entdeckten Sicherheitslücken informiert und am 03.03.2011 waren die Schwachstellen geschlossen.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.