27.07.2016 17:30

httpoxy in Österreich

Wir haben vorige Woche eine Warnung zu httpoxy veröffentlicht, dabei geht es um:

CGI ist ein Standard, mit dem Webseiten dynamisch mit Hilfe von Scripten serverseitig erstellt werden können. Dazu werden die Informationen über den Client und zur Anfrage in Umgebungsvariablen an das Script übergeben.

Enthält der HTTP-Request einen Header "Proxy:", dann wird der Inhalt dieses Headers in die Umgebungsvariable HTTP_PROXY geschrieben. Setzt nun seinerseits das Script einen Webrequest (etwa an ein Backend-System) ab, dann kann ein gesetztes HTTP_PROXY dazu führen, dass dieser Proxy benutzt wird.

Das erinnert mich sehr an die shellshock-Schwachstelle in der bash, auch dort war es möglich, durch kreatives Setzen von Umgebungsvariablen ein Fehlverhalten auszulösen.

Aaron hat dazu schon 2014 folgendes geschrieben:

Zum Thema Shellshock ist mir heute nach diesem Artikel wiederholt richtig klar geworden, dass das ganze dieses mal nicht so einfach ist wie Heartbleed - die Diversität mit der sich bash bugs (bzw. shell mis-interpretationen) verstecken ist interessant!

...

Ich sehe kaum einen Weg, systematisch alle verwundbaren Systeme zu finden und die Betroffenen zu informieren. Und schon gar nicht, ohne ein System aktiv zu überreden, fremden shellcode auszuführen. Auf github ist eine nette Übersicht zu finden, was potentiell alles von shellshock betroffen sein kann (PoC code!).

Wir haben uns letzte Woche Gedanken gemacht, wie wir als nationales CERT für Österreich gezielt die httpoxy-verwundbaren Server erkennen können um so ein Lagebild zu generieren und gezielt Warnungen an die Betreiber schicken können.

Nach kurzem Brainstorming haben wir uns auf folgende Vorgehensweise geeinigt:

  • Wir nehmen die Liste der .at Domains (rund 1.2 Millionen) als Ausgangsbasis.
  • Es ist für uns chancenlos, gezielt cgi-Scripte testen zu wollen. Das schafft vielleicht Google, wir können nur die Hauptseite (also http://domain.at/) betrachten.
  • Der Scan darf keine negativen Folgen für die Webserver haben. Daher können wir keinen funktionsfähigen Proxy im Proxy: Header angeben.
  • Der Scan muss massiv parallelisierbar sein, wir brauchen daher eine Messmethode, die möglichst nicht den ausgehenden http-Request mit einer eingehendem proxy-Connection zusammenführen muss.
  • Die Lösung dazu: wir messen im ersten Durchgang gar nicht proxy-Connections: wir übergeben im Proxy-Header Hostnamen und messen, ob der Hostname per DNS aufgelöst wird.
  • Dazu kodieren wir die aktuell getestete Domain in den Hostnamen -> ein Blick auf das Query-Log unseres Nameserver reicht dann aus.
  • Im zweiten Durchgang kann man dann in Ruhe testen, ob auch wirklich der Proxy: Header als ausgehender Proxy für eine Verbindung benutzt wird.

Wir haben das alles noch letzte Woche implementiert und kamen zu folgendem Ergebnis:

  • Von den 1.2 Millionen Domains haben nur 14 den Hostnamen im Proxy-Header aufgelöst.

  • Keiner der 14 Webserver hat bei unseren Tests eine Verbindung zu unserem Test-Proxy aufgebaut.

Was schließen wir daraus?

  • httpoxy ist kein "Der Himmel wird uns auf den Kopf fallen"-Problem. Das ist bei Weitem kein zweites Heartbleed.
  • Die Zahl der anfälligen System ist für uns nicht testbar, da wir nicht alle URL-Pfade probieren können.
  • Es gilt wie so oft: "Don't panic, patch!"

Autor: Otmar Lendl