#JAVAPRO #Testing #Penetrationstest ||
Penetrationstests sind mittlerweile in vielen Unternehmen geübte Praxis, auch wenn es noch Firmen gibt, in welchen bis heute noch kein einziger Penetrationstest durchgeführt wurde. Bei diesen Tests wird die Angreiferperspektive eingenommen und ein professioneller Tester führt dabei dynamische Analysen durch. Penetrationstests können vielerlei Ziele und Methoden haben. So gibt es ganz einfache Prüfungen gegen die Infrastruktur durch Port- und Schwachstellen-Scans mit manueller Auswertung. Das ist die unterste Ebene eines Tests, sowohl im Aufwand, aber auch im Erkenntnisgewinn. Eine spezifische Prüfform ist die Penetration von Web-Anwendungen. Der Artikel zeigt die wichtigsten Planungsaspekte
und Stolpersteine auf.
Definition Penetrationstest
Es gibt unterschiedlichste Definitionen, was einen Penetrationstest auszeichnet. Beispielsweise haben das NIST und das BSI entsprechende Dokumente veröffentlicht. Kürzt man die Definitionen zusammen, so bleibt am Ende folgende Formel übrig: ein Angreifer führt mit definiertem Kenntnisstand und definierten Berechtigungen eine Prüfung in definierter Zeit gegen ein definiertes Ziel durch.
Motivation
„Ein Penetrationstest verursacht nur Arbeit.“ Diese Aussage eines Sicherheitsverantwortlichen ist in den meisten Fällen durchaus zutreffend. Häufig, insbesondere bei der Prüfung von individuell erstellten Webanwendungen, finden Penetrationstester diverse Schwachstellen. Je nach Reifegrad des Software-Entwicklungsprozesses und eventuell auch dem Glücksmoment bei der Auswahl der richtigen Frameworks haben die Entwickler nach einem Penetrationstest recht viel Arbeit vor sich, um die gefundenen Schwachstellen zu beheben. Aus den Rückmeldungen von Kunden ist die Primärmotivation für Penetrationstests nicht etwa ein eigener Qualitäts- oder Sicherheitsanspruch, sondern vor allem Compliance-Anforderungen von Kunden oder Gesetzesvorgaben. Insbesondere in den Einkaufsbedingungen großer
Konzerne sind mittlerweile Penetrationstests beim Einkauf von Software und IT-gestützten Lösungen Standard geworden. Möchte man hier ein Geschäft abschließen, ist eine Prüfung durch unabhängige Dritte unabdingbar.
Die Planungsphase
Um einem Penetrationstest auszuschreiben und am Markt anzufragen sind verschiedene Dinge für die Dienstleistungsfirmen von Bedeutung. Zum einen muss ein Tester verstehen, was die Anwendung inhaltlich macht. Bei einem Onlineshop ist dies vergleichsweise einfach. Der Business-Case ist sofort klar. Bei speziellen Anwendungen zum Beispiel im Umfeld Human-Resource, Logistik, Pharma oder Finanzen sind die Anwendungen zum Teil sehr individuell und fachspezifisch aufgebaut. Teilweise kommen gar eigene Protokolle zum Einsatz, etwa EBICS im Banking-Umfeld. Es bietet sich an eine kleine Präsentation vorzubereiten, die die wichtigsten Aspekte und den funktionalen Umfang der Anwendung erläutert.
Rechtemodelle
Viele Anwendungen bieten eine Nutzerverwaltung und unterschiedliche Rollen und Rechtemodelle an. Eine vergleichsweise aufwändige, weil nur manuell zu erbringende Leistung, ist die Prüfung auf Rechteausweitung (Priviledge-Escalation). Dabei kann sowohl die horizontale Ausweitung, also das punktuelle Einnehmen der Rolle eines anderen Benutzers im gleichen Rechtekontext, als auch die vertikale Ausnutzung und damit Erhöhung der eigenen Rechte, überprüft werden. Ein Test wäre eine Funktion aufzurufen, die nur Nutzer A zur Verfügung steht, aber durch Nutzer B aufgerufen wird. Im Gegensatz zu fachlichen Prüfungen erfolgt dies jedoch nicht über die Nutzung der Oberfläche, sondern eine Ebene tiefer. Im Vorfeld muss definiert werden, welche Rollen und Rechte geprüft werden und welche Funktionen
innerhalb des Rollen- und Rechtemodells spezifisch überprüft werden sollen. Insbesondere bei komplexen Umgebungen ist eine vollständige Prüfung des Rollenrechtemodells eine sehr aufwendige Prüfung. Daher empfiehlt es sich hier risikoorientiert, eine definierte Anzahl an Prüffällen, auszuwählen.
Produktiv oder Testumgebung
Nichts ist produktionsnäher als die Produktion. Allerdings sind Prüfungen in der Produktionsumgebung mit den allerhöchsten Risiken verbunden. Ein einfaches Beispiel: Auf der Produktionsumgebung ist ein Kontaktformular. Dieses Kontaktformular wird im First-Level-Support als Ticket eingespielt oder eine E-Mail generiert. Bei einem Penetrationstest werden insbesondere Variablen iteriert, um Schwachstellen festzustellen. Selbst bei einem Formular wie dem Kontaktformular mit wenigen Eingabefeldern, kann ein solches Formular bis zu mehrere tausend Mal aufgerufen werden. Ist dies im Vorfeld nicht abgestimmt, ist ein Dankesgruß aus dem First-Level-Support, sowohl den Planern, als auch den Prüfern sicher. Daher ist es vorab unabdingbar, dass sich zum Beispiel der Product-Owner mit seinen Entwicklern der Fachseite darüber Gedanken macht, welche Workflows nicht oder nur in einem definierten Rahmen automatisiert überprüft
werden dürfen.
WAF oder nicht WAF
Eine Web-Application-Firewall (WAF) greift in den Datenstrom ein und versucht anhand von Signaturen bekannte Angriffe abzuwehren. Bei einem Penetrationstest sollte es aus Sicht des Autors immer um die Prüfung der eigentlichen Web-Anwendung gehen. So ist es für eine Prüfung sinnvoll die WAF zu deaktivieren, bzw. spezifisch für die Adressen der Prüfer auf Durchzug zu schalten. Hat man im Rahmen der Prüfungen spezifische Schwachstellen in der Anwendung erkannt, kann die WAF wieder aktiviert werden. Nun können die gefundenen Schwachstellen spezifisch mit aktivierter WAF erneut getestet werden. Somit erhält man mit minimalem Mehraufwand nicht nur die Aussage
darüber, welche Schwachstellen in der Anwendung existieren, sondern auch, ob die WAF für spezifisch durchgeführte Angriffe auf bekannte Schwachstellen das Resilienzniveau bietet, dass man sich von ihr erwartet.
Lassen Sie mich durch, ich bin Tester
Aufgrund der Vielzahl möglicher Schwachstellen werden wie beschrieben Variablen oft iteriert und Formulare häufig versendet. Insbesondere sensible Funktionen, wie zum Beispiel eine Anmeldemaske, sind meist durch Mechanismen geschützt, die eine solche Massenprüfung verhindern. Im Wirkbetrieb ist dies eine gute Idee. Sie verhindern jedoch auch eine hohe Prüftiefe durch Penetrationstests, zumindest mit vertretbarem Aufwand. Daher muss im Vorfeld überlegt werden, ob entsprechende Mechanismen wie Captchas oder Rate-Limiting für die Prüfung, zumindest auf einer Testinstanz temporär deaktiviert werden können. Dies erhöht die Prüftiefe. Ein Captcha ist ausschließlich in der Lage eine Massenprüfung zu erschweren. Sie verhindert jedoch nicht das Ausnutzen einer Schwachstelle. Nehmen wir an, dass in der Anmeldefunktion eine SQL-Injection-Schwachstelle vorhanden ist. Ein Captcha würde es zwar deutlich erschweren die Schwachstelle zu finden, da die Prüfwerkzeuge an sich viele Anfragen an die Anwendung senden, um die Schwachstelle zu finden, ebenso wie der Tester bei seinen manuellen Prüfungen. Wenn der Tester jedoch die zur Schwachstelle passende Angriffssignatur (Payload) gleich zu Beginn seiner Prüfung absendet, findet er die Schwachstelle. Daher ist es sinnvoll eine temporäre Deaktivierung ernsthaft zu besprechen, auch wenn es anfangs vielleicht albern klingen mag, für eine Prüfung von Sicherheitsaspekten Schutzfunktionen zu deaktivieren.
Ab in die Zeitkapsel
Was ist nun eine valide Testzeit für einen Penetrationstest? Die Faustformel lautet: Je komplexer und funktional umfänglicher die zu prüfende Anwendung ist, umso umfangreicher auch die Prüfung. Allerdings ist ein Penetrationstest keine deterministische Prüfmethode. So wird in einem Projekt im Normalfall ein Gesamtdurchführungszeitraum angeboten. Nehmen wir an, dieser Zeitraum liegt bei zehn Tagen. Wie viel Zeit innerhalb dieser zehn Projekttage für Tests und wie viel Zeit für Dokumentation notwendig sein wird, weiß vor den Prüfungen niemand! Der Umfang der Dokumentation definiert sich in erster Linie durch die Anzahl und Beschreibungsintensität der gefundenen Schwachstellen. Diese stehen naturgemäß vor dem Test nicht fest. Insofern kann der Prüfer vor einer Prüfung nicht wissen, wie viel Zeit innerhalb des Projektzeitraums für die Dokumentation benötigt wird. Bei einer Anwendung, die sehr schnell sehr viele Schwachstellen aufweist, wird der Prüfer nach wenigen Tagen aufhören zu prüfen, um die bis dato gefundenen Schwachstellen zu dokumentieren. Ist die Anwendung sehr widerstandsfähig, wird er lange prüfen können, da der Dokumentationszeitraum entsprechend deutlich kürzer sein wird. Die Prüfaussage ist in beiden Fällen jedoch sehr hilfreich. Für den ersten Fall ist klar, dass die Anwendung massive und umfangreiche Schwachstellen hat, die nicht auf die leichte Schulter genommen werden dürfen. Im zweiten Fall ist mit dem gleichen Gesamtaufwand klar, dass es sich um eine resiliente Anwendung handelt, bei der sehr viele Dinge offensichtlich in der Entwicklung richtig gemacht wurden.
Hallo, ist da jemand?
Wenn alle Vorkehrungen getroffen sind und ein Testzeitraum vereinbart wurde, können die Tests beginnen. Während der Testzeit ist es notwendig, dass sowohl der Tester als auch auf Seiten des Auftraggebers stets Erreichbarkeit vorherrscht. Ein tägliches Status-Update kann sinnvoll sein. In der Praxis zeigt sich jedoch, dass es meist am effizientesten ist, wenn die Tester sich frühestens beim Finden von Schwachstellen mit hohem Risiko umgehend beim Auftraggeber melden. Nach den Prüfungen muss ein nachvollziehbarer und transparenter, durch den Prüfer selbst verfasster Prüfbericht vorliegen. Dieser kann in einem telefonischen oder persönlichen Gespräch erörtert werden.
Wieso, weshalb, warum?
Penetrationstests sind wie beschrieben meist mit einem Erkenntnisgewinn verbunden. Dieser Erkenntnisgewinn zieht Arbeit nach sich. Anstatt jedoch einfach die Schwachstellen zu beheben, sollte ein kritischer Blick auf die Prozesse geworfen werden, die eigentlich das Auftreten solcher Schwachstellen hätten verhindern können. Gibt es Vorgaben für die Entwickler sich um Sicherheitsaspekte ausreichend zu kümmern, oder rennen diese ausschließlich Fachvorgaben hinterher? Gibt es für kritische Elemente einer Anwendung, wie das Speichern von Passwörtern und sämtliche Aspekte rund um Kryptographie, unternehmensweit gültige Vorgaben die dem Stand der Technik entsprechen? Können diese Vorgaben einfach und effizient durch die Entwicklung gesetzt werden? Eine Organisation nimmt sich eine große
Chance, wenn allein auf dem Beheben der konkreten Schwachstellen der Fokus liegt.
Fazit
Auch wenn Penetrationstests prinzipbedingt keine hundertprozentige Sicherheitsaussage liefern können, sind sie ein guter Gradmesser zur Resilienz einer Web-Anwendung. Insbesondere bei Anwendungen mit viel selbst entwickeltem oder im Auftrag entwickeltem Code, ist ein Penetrationstest hilfreich, um nicht Teil des nächsten Datenskandals zu sein.
Tobias Glemser beschäftigt sich seit 20 Jahren professionell mit IT-Sicherheit. Er ist Geschäftsführer der secuvera GmbH und vom Bundesamt für Sicherheit in der Informationstechnik zertifizierter Penetrationstester. Herr Glemser veröffentlicht regelmäßig Fachartikel und Buchbeiträge und ist Referent auf verschiedenen Kongressen. Ehrenamtlich ist er German Chapter Lead des Open Web Application Security Projects (OWASP).
