Von Webalizer zu root - Eine scheinbar kleine Reise
Marc Ruef | 13.08.2007

Eines gibt bei Sicherheitsüberprüfungen immerwieder zu diskutieren: Wie werden Schwachstellen eingestuft? Wahrhaftig handelt es sich hier um eine hochgradig subjektive Angelegenheit. So kommen in verschiedenen Standards und Produkten unterschiedliche Skalen zum Einsatz. Ich pflege bei meinen technischen Prüfungen ein vierstufiges System mit den Bezeichnungen Low, Medium, High und Emergency einzusetzen.

Bei Low handelt es sich um die niedrigste Stufe. Dies sind Schwachstellen, die man längerfristig anschauen kann, die jedoch keine sofortige und unabdingbare Adressierung erfordern. Es sind also grundsätzlich Schönheitsfehler, die keine unmittelbare Gefahr für die Zielumgebung darstellen. Populärster Vertreter dieser Gattung sind Ping- und Traceroute-Zugriffe. Die wenigsten Kunden schenken diesen Angelegenheiten Beachtung.

Im Durchschnitt finden sich meistens Medium Schwachstelle bei Sicherheitsüberprüfungen. Dabei handelt es sich um Probleme, die mittel- und längerfristig in Kombination mit anderen ausgenutzt werden können und als Vorteil verstanden werden müssen. In erster Linie sind dies einzuholende Informationen, wie das Ermitteln von Benutzernamen oder das Abgreifen von Applikationsbannern.

Ab und an wird eine High Sicherheitslücke gefunden. Diese kann unmittelbar ausgenutzt werden, um erweiterte Rechte zu erlangen. Typischerweise sind dies Cross Site Scripting, SQL-Injection, Pufferüberläufe und Format Strings. Sowohl Medium als auch High werden als unmittelbar zu adressieren empfohlen. Schliesslich stellen sie eine direkte Gefahr für die Zielumgebung dar.

Diese Gefährlichkeit wird nur noch durch Emergency Fehler überboten. Dies sind spezielle High Fehler, die sich unglaublich leicht ausnutzen lassen. Zum Beispiel deswegen, weil für ein populäres Produkt ein sehr einfacher Exploit verfügbar ist. Die von W32.Blaster.Worm ausgenutzt Pufferüberlauf-Schwachstelle in Microsoft Windows, zu der verschiedene Exploits herausgegeben wurden, gehört dazu. Wird ein Emergency während einer Prüfung gefunden, wird diese normalerweise sofort abgebrochen und mit dem Kunden ein Lösungsweg erarbeitet. Dieser ist in diesem Augenblick viel wichtiger, weder sich mit etwaigen Schwachstellen herumzumühen.

Die grössten Diskussionen geben in der Regel die Probleme der Stufe Medium. Da diese abgenommen und mittelfristig angegangen werden müssen, versuchen viele Administratoren immerwieder dagegenzuargumentieren, um die vermeintlich unsinnige Arbeit abzublocken. Was ist denn schliesslich schon dran, wenn über ein Banner-Grabbing der eingesetzte Webserver als Apache 2.0.59 identifiziert werden kann? Oder wieso sollte sich der Cisco-Router nicht über die typische Telnet-Anmeldung (simples Application Fingerprinting) ausmachen lassen? Und in der Tat lässt sich oftmals darüber streiten, ob und inwiefern solche Probleme wirklich angegangen werden müssen.

Bei einer umfassenden Sicherheitsüberprüfung (Vulnerability Assessment inkl. Penetration Testing als Proof-of-Concept) für ein weltweit tätiges Telekommunikationsunternehmen habe ich jedoch einmal mehr gemerkt, wie tragisch sich vermeintlich harmlose Medium Schwachstellen entwickeln können. So habe ich auf einem der öffentlich über das Internet erreichbaren Webserver das Verzeichnis /webalizer gefunden. Dieses wird standardmässig von der gleichnamigen Webapplikation eingerichtet. Bei Webalizer handelt es sich um eine Lösung, mit der sich die Logs des Webservers anzeigen und Statistiken zu diesen Ausgeben lassen. Eine aufgrund ihrer Einfachheit und Komfortabelität sehr populäre Lösung.

Der Zugriff auf diese Ressource liess mich Einsicht in die Webserver-Logs halten. Ich begann schon, diesen Fehler als Medium zu klassifizieren, als ich in einem nächsten Schritt die Protokolle akribisch studierte. So konnte ich sehen, dass dort ein weiteres Unterverzeichnis mit dem Namen /_security auftauchte. Dieses wurde durch die üblichen CGI-Scanner (Nikto und N-Stealth) nicht gefunden. Als ich darauf zugreifen wollte, wurde ich jedoch mit einer htaccess-Passwortabfrage abgetan. Die Zugangsdaten waren mir nämlich nicht bekannt.

So studierte ich ein bisschen resigniert die Webalizer-Ausgabe weiter. Dabei fiel mir ein wichtiger Punkt auf. So weist die Anwendung aus, mit welchen Benutzernamen sich typischerweise eingeloggt wird. Dabei war lediglich einer aufgelistet: Es musste sich also um den Standardbenutzer handeln, der auch für den Zugriff auf /_security eingesetzt wird. Sofort machte ich mich daran, mich mit diesem einzuloggen. Das Passwort war mir noch immer unbekannt, weshalb ich den Benutzernamen als Passwort probierte ... Jackpot!

Die Authentisierung verlief erfolgreich und ich sass nun einer weiteren Webapplikation gegenüber, die detailliert Auskunft über das Zielsystem gab. So wusste ich, dass mod_security auf dem Webserver eingesetzt wird. Dass jedoch der safe_mode bei PHP ausgeschaltet blieb (leider wurden keine weiteren dynamischen Anwendungen dargeboten). Zudem sei das FTP-Passwort für eine spezifische Anwendung noch immer im Ursprungszustand. Ich suchte nach dieser mir bis dato unbekannten Lösung und schaute im Handbuch nach, wie das Standardpasswort lautet. Dieses sollte mir nun erlauben, mit administrativen Privilegien über FTP auf die gesamte Verzeichnisstruktur zuzugreifen. Aus einem seichten Medium Fehler wurde nun also ein klares High Problem.

Meine erste Empfehlung wird deshalb sein, den Zugriff auf /webalizer einzuschränken oder diesen Dienst für Zugriffe aus dem Internet gänzlich zu verhindern (htaccess oder ACL). Desweiteren soll ein starkes Passwort für die htaccess-Authentisierung auf /_security eingesetzt werden. Ich denke, dass es in diesem Belang keine allzugrossen Diskussionen bezüglich der Wichtigkeit und Notwendigkeit der Massnahmen geben wird.