Der Israelische Security Forscher Zohar Shachar hat vor kurzem Details über ein Kopfgeld preisgegeben welches er von Google vor circa einem Jahr erhielt. Das Security Problem das er gefunden hatte war eine fortgeschrittene “cross-site scripting” (XSS) Schwachstelle in Google Maps.
In diesem Fall gab es ein ungewöhnliches Detail. Shachar erhielt zwei Kopfgelder für dieselbe Schwachstelle. Nachdem Google ihm das erste Kopfgeld ausbezahlte entschied sich Shachar die Lösung zu prüfen und fand, dass er sie umgehen konnte. Er gab auch zu, dass dies nicht der einzige derartige Fall ist – er konnte auch eine zuvor behobene SMTP-Injektions-Schwachstelle in GSuite ausnutzen.
Dieser Fall stellt eine entscheidende Frage: Wie viele öffentlich zugängliche Schwachstellen wurden in der Vergangenheit nicht entfernt bzw. gelöst? Dies zeigt, dass sogar die renommiertesten Web-Applikation Giganten wie Google Anfängerfehler machen und ihre Lösungen und Fehlerbehebungen entweder vergessen zu testen oder sie werden nicht ausreichend getestet.
Nicht alle haben so viel Glück wie Google es in diesem Fall hatte. Nicht alle Schwachstellen werden von einem verantwortungsvollen Penetration-Tester wie Shachar gefunden. Die meisten Kopfgeldjäger würden die Prämie einstecken und keine weiteren Gedanken an ihren Fix verschwenden.
Vor allem interne, manuelle Penetrationstester und vor allem die, die aufgrund der Cybersicherheitslücke überlastet sind, haben einfach keine Zeit, die Korrekturen zu testen.
Die Tester haben schlicht keine Zeit die Fixes zu überprüfen. Darum besteht die Möglichkeit, dass viele Schwachstellen noch existieren, und das gefährlichste daran ist das Firmen in dem Glauben leben diese behoben zu haben.
Ein Grund weshalb Lösungen ineffektiv sind ist, dass Entwickler die Schwachstellen nicht als echte Probleme ansehen. Das kommt daher, weil Security Teams und Entwickler Teams oft in Silos arbeiten.
Häufig werden Penetrationtester von Entwicklern in einem negativen Licht wahrgenommen. Für sie sind das Leute die bloß überflüssige Arbeit verursachen. Mit einer solchen Einstellung wird der Entwickler lediglich darauf abzielen, die Findings des Penetrationtesters abzuarbeiten, ohne wirklich darauf zu achten, ob die Schwachstelle tatsächlich entfernt wurde. Zum Beispiel filtern sie bloß nach dem String der verwendet wurde um die Schwachstelle auszunutzen, und ignorieren dabei andere potentielle Strings die den gleichen Effekt haben könnten.
Ein anderer Grund ist, dass sich nicht jede Schwachstelle so einfach beheben lässt. Während sich SQL Injections einfach durch parametrisierte Abfragen, welche man in jeder “back-end” Programmiersprache anwende kann beheben lässt, ist dies bei fortgeschrittenem “cross-site scripting” (wie es bei Google Maps der Fall war) nicht so simpel. XSS im Code einer Applikation zu vermeiden ist schwierig.
Das fehlende Retesting wie in dem Fall von Google macht die Situation schlimmer da die Entwickler nicht aus ihren eigenen Fehlern lernen. Spätes Testen und spätes Retesten ist genauso schlecht. Man stelle sich folgende Situation vor: Entwickler A macht einen Fehler und erstellt eine Schwachstelle. Aufgrund von Tests in der Staging Phase wird Entwickler B Wochen später beauftragt die Schwachstelle zu beheben. Entwickler A bekommt nicht mit was er falsch gemacht hat und wird dieselbe Schwachstelle das nächste Mal wieder einbauen wenn er ähnlichen Code schreiben muss.
Wenn das noch nicht schlimm genug ist, denken wir einmal über folgenden Fall nach. Es ist Entwickler C der beauftragt wird den Fehler der von Entwickler B eingeführt wurde zu beheben. Daher weiß nun Entwickler B nicht was der Bug war und wird wahrscheinlich den gleichen Fehler in zukünftigen Schwachstellen Behebungen machen. Das Resultat ist, dass zwei der drei Entwickler nicht wissen, dass sie Fehler gemacht haben und werden deshalb immer die gleichen Schwachstellen einbauen.
Das ist definitiv keine gute Art und Weise eine sichere Web Applikation zu bauen.
Man würde denken, dass das Scannen nach Schwachstellen der beste Weg sei, sicher zu gehen, dass alle Lösungen erneut getestet werden. Aber das ist nicht immer richtig.
Die meisten Web Schwachstellen Scanner sind manuelle Tools. Man richtet sie auf die Applikation, man lässt den Scan laufen, man speichert den Report und schickt ihn den Entwicklern. Es gibt keinen Prozess der sicherstellt, dass die Schwachstellen erneut getestet werden.
Fortschrittliche Schwachstellenscanner der “Businessklasse” wie Acunetix verfügen über integrierte Funktionen für das Schwachstellen Management. Das heißt, dass nach dem eine Schwachstelle identifiziert wurde, wird ein Ticket automatisch erstellt. Dies passiert sogar bei externen Problem-Trackern wie Jira. Nach dem das Ticket von den Entwicklern geschlossen wurde, kann die Schwachstelle erneut getestet werden um festzustellen ob der Fix effektiv war. Mit Lösungen der “Enterprise Klasse” wie Acunetix 360 kann automatisch erneut getestet werden, nachdem das Problem in Jira geschlossen wurde.
Noch besser sind moderne Schwachstellen Scanner wie Acunetix, die in CI/CD Pipelines arbeiten. Das bedeutet dass der ursprüngliche Entwickler keine Schwachstellen einbauen kann, da der Build fehlschlägt nachdem eine Schwachstelle gefunden wurde. Die Entwickler müssen daraufhin ihren Fehler beheben und den Build neu laufen lassen. Das führt dazu dass der fix automatisch erneut getestet wird und die Entwickler aus ihren Fehler lernen können. Es gibt daher keine Situation in der drei Entwickler einbezogen werden und das Problem Monate lang herum liegt.
Natürlich können Schwachstellen Scanner nicht jede einzelne Schwachstelle finden. Dennoch wird ein Großteil der Probleme welche durch nicht vorhandenes Testen der Lösungen verursacht werden gelöst wenn man effiziente Automatisierung einführt.
