Aktuelles

Ganz schön penetrant

Gelegentlich gibt es auch im Arbeitsleben eines Software Entwicklers mit langer Berufserfahrung noch echte Herausforderungen, auf die man sich im Vorfeld nicht richtig vorbereitet hat. Trotzdem soll man aber schnell Ergebnisse erzielen. So erging es mir und meinen Kollegen neulich bei einem Kunden, als an einer ganz anderen Ecke des Unternehmens eine SQL-Injection Lücke in einer Website gefunden wurde.

„Sofort alle Web-Anwendungen auf Lücken prüfen und diese beseitigen! Ich brauche in drei Tagen die Aussage, dass wir sicher sind!“

So dringend diese Anforderung daher kam, so wenig präzise war sie. Und letztendlich genauso unmöglich zu leisten, wie uns als Entwickler ohne Vorkenntnisse in punkto Penetrationstests sofort klar war. Natürlich hatten wir die wesentlichen Standards bei der Web-Entwicklung eingehalten, Eingabefelder validiert und Benutzereingaben nur mit Prepared-Statements in die Datenbank übernommen, aber reichte das schon, um die Anwendung als sicher einzustufen? Um dies behaupten zu können, hätten wir deutlich mehr Wissen über Angriffsszenarien benötigt, als wir vorweisen konnten.

Da keine Zeit blieb, erst in Theorie und Standards einzutauchen, dann ein Tool auszuwählen (durfte natürlich nichts kosten), dann die Interpretation der Theorie in diesem Tool zu verstehen, sich in das Tool einzuarbeiten und letztendlich auch noch die Tests durchzuführen und zu dokumentieren, mussten wir einige Abkürzungen nehmen. Wir sparten uns die Theorie und Standards und definierten das, was das von uns ausgewählte Tool kann, als unseren Standard – zwei Arbeitsschritte gespart. Erfahrene Penetrationstester mögen jetzt die Hände über dem Kopf zusammenschlagen und Dinge rufen, die andere Menschen rufen, wenn z. B. ihre Lieblingsmannschaft beim Fußball eine Großchance vergibt. Sie erregen sich mit Fug und Recht über dieses dilettantische Vorgehen. Als Entlohnung  für das aufbauende Erlebnis eines gerechten Zornes wäre ich dankbar für Hinweise, wie man es in der vorgegebenen Situation besser hätte machen können.

Bevor es aber ans Testen geht, noch ein zwei Tipps:

  • Man sollte alle Leute vorab informieren, die auch nur irgendwie mit den Anwendungen zu tun haben. Insbesondere Server-, Netzwerk-, Firewall- und Datenbankadministratoren sollten Bescheid wissen, dass diese Tests laufen. Wahrscheinlich bekommen sie letztendlich nichts davon mit, aber wenn doch … Besser man hat vorher Bescheid gesagt.
  • Alle umfangreichen Tests sollten auf dem Testsystem stattfinden. Prinzipiell können Daten verloren gehen oder Email-Fluten ausgelöst werden. Auch die Verfügbarkeit des Systems kann eingeschränkt werden. Ist das Testsystem sauber, so müssen auf dem produktiven Systems eigentlich nur noch Tests bis zur Anmeldung und zur Serversicherheit durchgeführt werden. Diese sollten dann sinnvollerweise nicht nur aus dem eigenen Netzwerk erfolgen, sondern auch von außerhalb.

Ein Tool war mit dem Zed Attack Proxy vom Open Web Application Security Project (OWASP ZAP) schnell gefunden. Es gibt sicherlich umfangreichere und vielleicht auch bessere Werkzeuge, aber der Funktionsumfang war für uns ausreichend, die dahinterliegende Organisation wirkte vertrauenserweckend und das Tool versprach, sowohl von Anfängern als auch von Experten eingesetzt werden zu können. Für eine vergleichende Toolanalyse fehlte uns ohnehin die Zeit und die Kompetenz. Wir haben die Wahl nicht bereut.

Der Start war auch wirklich sehr einfach: Auf dem Startbildschirm die anzugreifende URL eingeben und auf den Button „Attack“ drücken. Sehr einfach, aber leider auch sehr wirkungslos (da kaum an der Oberfläche der Anwendung gekratzt wird), so dass man sich selbst diese paar Sekunden Arbeit sparen kann. Ohne Vorbereitung geht es leider nicht. 

Das Team hat sich schnell in zwei Arbeitsgruppen aufgeteilt. Während ein Team einfach drauf los getestet hat und die Schwachpunkte bewertet und ggf. beseitigt hat, untersuchte ein anderes Team, wie sich am wirkungsvollsten mit ZAP arbeiten lässt. Letztendlich hat sich folgendes Vorgehen bewährt:

  • Die Arbeit sollte zwecks Reproduzierbarkeit in ZAP-Sessions gesichert werden.
  • ZAP sollte als Proxy zwischen Browser und Anwendung eingesetzt werden. Als Man-in-the-Middle kann ZAP die komplette Kommunikation aufzeichnen. An dieser Stelle ist es wichtig, möglichst alle Funktionen der Web-Anwendung durchzugehen, damit ZAP alle Funktionen kennen lernt.
  • Aus der aufgezeichneten Kommunikation lassen sich schnell Startpunkte für die Angriffe sowie Anmeldeszenarien definieren, die das Tool kennen muss, um wirklich testen zu können. Im erstellten Kontext lassen sich jetzt auch Anmeldeinformationen hinterlegen, die in den Tests verwendet werden sollen.
  • Die bisher geleistete Arbeit sollte jetzt als ZAP-Session gespeichert werden, da sie die Grundlage der nachfolgenden Tests darstellt. ZAP kann an dieser Stelle auch wieder als Proxy entfernt werden.
  • Anschließend können nacheinander verschiedene Angriffe (Aktiver Scan, Spider, AJAX Spider, …) durchgeführt werden. Obwohl einige dieser Scans aktiv nach verborgenen Funktionen suchen, hängt die Aussagekraft der Ergebnisse wesentlich davon ab, was man dem Tool zuvor beigebracht hat.

ZAP bietet noch Unmengen von Einstellungen zu den Tests, die wir in der Kürze der Zeit nicht alle nutzen bzw. auch nur wirklich verstehen konnten, die wir aber im Laufe der Zeit hoffentlich noch kennen lernen werden.

Zurück zur Ausgangsfrage: „Sind wir jetzt sicher?“

Ein bisschen sicher zumindest. Wir haben es wie die Ärzte gehalten, die auch nicht behaupten, dass jemand gesund ist, sondern nur, dass die dokumentierte und reproduzierbare Untersuchung ohne negativen Befund ist. Das musste das Management diesmal hinnehmen und selbst entscheiden, ob dies ausreichend ist. Für mehr Sicherheit sollte man dann doch einen Profi ins Haus kommen lassen. Aufgrund unserer Vorarbeit können wir aber davon ausgehen, dass dieser sich nur noch mit den wirklich kniffeligen Dingen beschäftigen muss.

Mittlerweile haben wir die Ausführung dieser Tests übrigens in den normalen Auslieferungsprozess integriert, so dass wir auch in Zukunft vor allzu bösen Überraschungen gefeit sind.