Die Software Nagios dient zur Überwachung von IT-Systemen und bietet verschiedene Module sowie eine umfangreiche Web-Schnittstelle. Eine kürzlich entdeckte Sicherheitslücke im Nagios-Webinterface erlaubt es einem entfernten Angreifer, dem Anwender Javascript-Befehle unterzuschieben.
Dabei sieht dies für den Anwender so aus als kämen diese Anweisungen direkt von der Nagios-Seite; es handelt sich also um eine typische per Cross-Site-Skripting (XSS) angreifbare Schwachstelle.
Der Programmierfehler befindet sich in der Datei “config.cgi”. Sie filtert das das Feld “expand” nicht korrekt, bevor es dem Anwender via HTML angezeigt wird. Die Lücke kann lässt sich durch einen typischen Aufruf wie den folgenden ausnutzen:
http://www.example.com/icinga/cgi-bin/config.cgi?type=command&expand=<script>alert(String.fromCharCode(88,83,83))</script>
Ursache der Schwachstelle ist ein sehr leichtsinniger Programmierfehler in der Datei “config.c”:
printf("<TR CLASS='dataEven'><TD CLASS='dataEven'>To expand:</TD><TD CLASS='dataEven'>%s",command_args[0]);
Dieser Code gibt die Variable “command_args[0]”, die den Expand-Wert enthält, direkt mit “printf()” aus. Ein solcher String sollte vorher unbedingt gefiltert werden. Die korrigierte Fassung sieht also so aus:
printf("<TR CLASS='dataEven'><TD CLASS='dataEven'>To expand:</TD><TD CLASS='dataEven'>%s",escape_string(command_args[0]));
Es gibt noch einige weitere kritische Stellen im Code, die sich für XSS-Attacken eignen. Alle wurden jedoch letzte Woche korrigiert. Betroffen von der XSS-Lücke ist die Nagios-Version 3.2.3.
Cookie-Diebstahl mit XSS und Gegenmaßnahmen mit HttpOnly
XSS-Attacken dienen häufig auch dazu, HTTP-Cookies zu stehlen. Diese Cookies, wie allgemeine Magic-Cookies auch, sind eine Art kleiner Datenbankeintrag und dienen zum Zwischenspeichern von Session-Information wie Accountdaten, Benutzereinstellungen und Ähnlichem. Wenn ein Angreifer an ein gültiges Cookie eines Anwenders kommt, kann er dessen Session übernehmen.
Allerdings unterliegen Cookies der Same-Domain-Policy, das heißt, der Zugriff auf Cookies einer bestimmten Seite ist nur von Code derselben Seite aus möglich. Ohne diese Policy wäre das ganze Cookie-Prinzip sinnlos, weil jede Seite die Cookies anderer Seiten einfach auslesen könnte, und es damit trivial wäre, Sitzungen zu kapern. XSS-Schwachstellen erlauben einem Angreifer aber nun gerade, Code innerhalb der Domain der angegriffenen Seite durchzuführen, und darum ist das Stehlen von Cookies durch XSS-Attacken extrem verbreitet.
Eine Attacke läuft praktisch immer nach dem gleichen Schema ab: Der Angreifer setzt auf einem Server beispielsweise ein PHP-Skript auf, das dem Sammeln von Cookies dient. Danach leitet er das Opfer via XSS-Attacke
auf diese Seite um, speichert das Cookie der fremden Domain, und leitet dann wieder auf die Originalseite um. Das Ganze braucht nur wenige Zeilen PHP und noch weniger Zeilen Javascript, wobei Javascript via “document.cookie” den eigentlichen Zugriff auf die Cookies-Datei erlaubt.
Da diese Attacke so verbreitet ist, und XSS-Panfällige Programmierfehler immer wieder auftreten, wurde vor einigen Jahren das “HttpOnly”-Flag eingeführt. Ist dieses für ein Cookie gesetzt, so kann clientseitig kein Skript mehr auf das Cookie zugreifen. Damit ist der beschriebene Cookie-Diebstahl per “document.cookie” Viele Browser wie Mozilla Firefox, Chrome oder Opera unterstützen “HttpOnly”.
