Die ungewollte DoS beim Griff zu den Sternen Marc Ruef | 30.03.2009 Seit Jahren bin ich um die Professionalisierung des Bereichs der Computersicherheit bemüht: Durch eine systematische Herangehensweise, die in traditionellen Wissenschaften schon lange als elementare Grundlage erarbeitet wurden, soll die Qualität entsprechender Schutzmassnahmen erhöht werden. Gerade in Bezug auf Sicherheitsüberprüfungen, im speziellen bezüglich der zielgerichteten Penetration Tests, ist mitunter eine chirurgische Präzision das, was die Qualität der Arbeit ausmacht. Für mich ist es deshalb unter anderem besonders wichtig, dass die Testzugriffe zielgerichtet angestrebt werden. Da nicht selten ebenfalls produktive Umgebungen geprüft werden, sind besonders bewusst destruktive Zugriffe, die zu einer Denial of Service (DoS) führen könnten, zu vermeiden. Schliesslich will man die Erreichbarkeit und damit die Produktivität der geprüften Systeme und Dienste nicht untergraben. Deswegen verzichten wir mit erhöhtem Aufwand auf potentiell gefährliche Angriffsversuche: Das Überlasten von Diensten wird durch träge Scan-Parameter (Timing und Parallelisierung) verhindert. Und auf das rigorose Ausnutzen von zum Beispiel potentiellen Pufferüberlauf-Schwachstellen wird bei kritischen Komponenten verzichtet (normalerweise wird ein kleines Zeitfenster für einen Proof-of-Concept definiert und die zuständigen Stellen auf Abruf bereitgestellt). Für mich ist es ein Zeichen von Kunst und Disziplin, bei einer Prüfung nicht versehentlich irgendwelche Komponenten abzuschiessen. Und trotzdem lässt es sich manchmal nicht verhindern. Bei einer Sicherheitsüberprüfung für eine Regierungsstelle musste ein System zur Videoüberwachung über das Internet einem vollumfänglichen Penetration Test unterzogen werden. Die Umgebung war schon seit Jahren aktiv und durch die jeweiligen Behörden rege genutzt. Ein Ausfall musste unbedingt verhindert werden. Das System bot mitunter die Möglichkeit der Anzeige von Überwachungsstatistiken. So liessen sich in dynamischer Weise Diagramme für bestimmte Grunddaten und Perioden erstellen. Alles, was das Herz eines Statistikers höher schlagen lässt. Wie immer habe ich versucht durch unlogische und nicht zu erwartende Parameter die Anwendung aus dem Tritt zu bringen. Bei Webapplikationen wird da gerne mit Anführungszeichen und spitzen Klammern gearbeitet, um durch HTML-Injection eine Veränderung der Seitenausgabe zu erzwingen. Oder durch SQL-Schlüsselwörter sollen die Datenbankabfragen dahingehend manipuliert werden, um Zugriffe auf ansonsten nicht zugängliche Datensätze zu erzwingen. In der Tat habe ich nach einigen Ausprobieren eine exotische Injection-Schwachstelle gefunden, mit der sich die Räpresentation der Diagramme in interessanter und kritischer Weise manipulieren lassen. Mein grundsätzliches Ziel war damit eigentlich schon erreicht. Weiterführend habe ich versucht mit untypischen Sonderzeichen zu arbeiten, um vielleicht noch etwas mehr herauszuholen. So bietet sich zum Beispiel das Fragezeichen ? in einer Eingabe an. Gewisse Applikationen interpretieren dies als Help-Befehl und warten mit Details zur internen Datenverarbeitung auf. Doch nichts geschah. Ich tüftelte weiter herum, bis ich schliesslich einen Asterisk * als Eingabe heranziehen sollte. Er dient bei vielen Sprachen (z.B. SQL, Dateisystem oder Reguläre Ausdrücke) als Platzhalter für eines oder mehrere Zeichen. Der Zugriff war also vielversprechend. Normalerweise brauchte die Applikation etwa eine Sekunde, um meine Eingaben zu verarbeiten und die Diagramme (ich liess sie meistens nur für kurze Perioden anzeigen) auszugeben. Doch bei der Stern-Eingabe dauert es, und dauerte, und dauerte ... Nach 10 Sekunden machte ich mir schon langsam Sorgen, ob vielleicht mein SSH-Client oder gar die Internet-Verbindung Probleme haben sollte. Derlei Unterbrechungen sind höchst unangenehm. Vor allem wenn sie nur kurz und sporadisch auftreten. Nach 30 Sekunden wurde die Verbindung meines Clients getrennt. "Das ist kein gutes Zeichen", dachte ich mir. Sodann sollte ich mich erneut mit der Zielanwendung verbinden, um das Problem eingrenzen zu können. Doch der Dienst war nicht mehr erreichbar - Der Zielport war nicht mehr im LISTENING-Modus und daher keine TCP-Verbindung mehr möglich. Ich versuchte das System zu pingen, um die grundlegende Erreichbarkeit determinieren zu können. Doch auch die ICMP echo request-Anfragen blieben unbeantwortet. Sehr schlecht, sehr schlecht... Ich setzte mich mit dem Kunden in Verbindung und schilderte die Situation. Unverzüglich machte sich ein Techniker vor Ort daran, die Fehlerquelle ausfindig zu machen. Nach wenigen Minuten wurde mir per Email mitgeteilt, dass das System wieder funktionieren würde, man jedoch das ursprüngliche Problem noch nicht einkreisen konnte. Aufgrund der Produktivität der Umgebung und den fehlenden Details des Unterbruchs liess ich bis auf weiteres von den potentiell gefährlichen Zugriffen ab. Ich sollte sie im Report als "weiter zu untersuchen" ("to analyze") deklarieren, denn schliesslich schlummerte hier mit hoher Wahrscheinlichkeit eine kritische Denial of Service-Schwachstelle. Ich vermutete, dass der Stern wahrlich als Platzhalter herhielt. Dabei wurden wohl sämtliche Daten der Systeme in die Diagramme miteinbezogen, was eine hoffnungslose Überlastung dieser zur Folge hatte. Der Dienst ist gestorben und mit ihm das System. Vielleicht wurde das ganze RAM aufgebraucht oder die temporären Bereiche der Festplatten wurden vollgeschrieben. Normalerweise wird durch Mechanismen wie nice verhindert, dass Prozesse zu viele Ressourcen in Anspruch nehmen können. Und stürzt denn mal ein Dienst ab, wird er unter Umständen sofort neu gestartet und der Administrator über allfällige Probleme informiert (z.B. Email, SMS oder SNMP). In diesem Fall war die Architektur der Lösung jedoch nicht in der Lage, mit dieser Situation umzugehen. Das Problem musste deshalb zwingend als "sehr kritisch" eingestuft und mit dem Gefahrenpotential "high" deklariert werden.