Neues von einem Klassiker: der SySS-Penetrationstest

Am Anfang fast jeden Penetrationstests stehen zwei Fragen:

• 1. Wie läuft ein Pentest ab?
• 2. Was genau wird geprüft?

Die Antworten sind so individuell wie die Tests selbst. Dieser Artikel gibt einen Einblick in die Testmethodik und das Vorgehen eines Penetrationstests am Beispiel eines Webapplikationstests.

Was passiert vor dem Pentest?

Zu Beginn eines jeden Projekts steht das Kick-off-Gespräch. In diesem Gespräch klären die projektverantwortlichen SySS IT Security Consultants technische und organisatorische Themen. Dazu gehören beispielsweise Zugriffe und Testgenehmigungen, Kommunikationswege sowie der Abschlussbericht. Das Kick-off-Gespräch sollte möglichst einige Tage bis Wochen vor Beginn des Projekts stattfinden. Oft müssen für die Testgenehmigung externe Dienstleister mit eingebunden werden. Auch sind häufig einige Themen auf Kundenseite noch umzusetzen, bevor der Test starten kann. Diese umfassen je nach Szenario die Einbindung verschiedener Fachabteilungen, das Zugänglichmachen einer Testumgebung sowie die Bereitstellung von Testaccounts. Nach der Erfahrung der SySS bietet ein Zeitraum von drei bis sechs Wochen vor Projektbeginn einen guten Zeitrahmen für das Kick-off-Gespräch.

Vor welchem Hintergrund findet der Pentest statt?

Drei bis sechs Wochen nach dem Kick-off-Gespräch startet der eigentliche Penetrationstest. Grundsätzlich richtet sich das Vorgehen eines jeden Tests nach dem jeweiligen Testgegenstand, dem Testfokus sowie nach der zu testenden Umgebung und den eingesetzten Technologien. Im Falle einer Webapplikation beispielsweise wird diese über einen Browser aufgerufen und bedient. Bei einem Test der öffentlich erreichbaren Infrastruktur steht die Ermittlung der erreichbaren Dienste im Vordergrund. Diese Parameter entscheiden auch darüber, welche Tools verwendet werden. Einige dieser Tools, wie beispielsweise die Port- bzw. SSL/TLS-Scanner Nmap oder testssl, sind quelloffen und kostenlos einsetzbar. Auch kommen kommerzielle Tools wie die Burp Suite von Portswigger oder Nessus von Tenable zum Einsatz. Die SySS entwickelt aber auch eigene Tools, teils zur internen Verwendung, teils quelloffen für jede und jeden einsetzbar. Diese Tools werden auf dem GitHub-Accout der SySS veröffentlicht.

Neben den automatisierten Tools kommt aber auch das "Herzstück" eines jeden Penetrationstests zum Einsatz: die menschliche Komponente. Die IT Security Consultants der SySS sind durch interne Schulungen, Erfahrungsaustausch und externe Zertifizierungen bestens für die Penetrationstests gerüstet. Sie können sowohl auf einen breiten Erfahrungsschatz aus eigenen Projekten zurückgreifen als auch Kollegen zu Rate ziehen. So lassen sich meist interessante Funde aufdecken, die durch den alleinigen Einsatz von automatisierten Tools verborgen geblieben wären.

Grundsätzlich orientiert sich die SySS bei Penetrationstests von Webanwendungen an den OWASP Top 10, die durch eigene interne Richtlinien ergänzt werden. Diese Richtlinien basieren auf der jahrelangen Erfahrung der SySS im Bereich Penetrationstests, auf Forschungsprojekten und dem internen Wissensaustausch. Zudem besteht reger Austausch mit der internationalen IT Security Community über diverse Diskussionsforen oder auf Konferenzen. Diese Erkenntnisse fließen ebenfalls in die SySS-internen Richtlinien und das Vorgehen ein.

Was passiert beim Pentest selbst?

Jeder Test beginnt mit der Informationsbeschaffungsphase. Viele Webapplikationstests der SySS umfassen auch die Prüfung der zugrunde liegenden Infrastruktur. Hierbei werden offene Ports und darüber angebotene Dienste ermittelt. Daraus lässt sich erschließen, wie groß die Angriffsfläche auf ein System ist. Auf diese Weise lassen sich außerdem einige Ungewöhnlichkeiten wie veraltete oder fehkonfigurierte Dienste auffinden. Diese stellen in den meisten Fällen ein direktes Sicherheitsrisiko dar. Nicht zuletzt werden die vorgefundenen Dienste auf Schwachstellen hin überprüft.

Im Fall einer Webapplikationsanalyse wird bei der Informationsbeschaffung beispielsweise der vorgesehene Ablauf eines Nutzers durchgeführt, wie dieser eine Anwendung regulär bedienen würde. So wird beispielsweise eine zu testende Antragsstrecke mit validen Daten gefüllt, um festzustellen, wie diese an den Server übermittelt und verarbeitet werden.

Oft geht die Informationsbeschaffungsphase bereits langsam in die Angriffsphase über. Dies bedeutet nicht, dass die Informationsbeschaffung am Ende ausgesetzt wird. Vielmehr verschiebt sich der Fokus des Vorgehens. Während des Tests selbst können immer wieder neue Unterseiten oder Funktionen entdeckt werden, die bei der ersten Sichtung nicht direkt vorgefunden wurden.

Im weiteren Verlauf des Tests wird die Webapplikation auf verschiedene Schwachstellen geprüft. Je nach Anwendung, ihrer Funktion und den Wünschen des Kunden können hier in Absprache Schwerpunkte gesetzt werden. So ist es zum Beispiel extrem unwahrscheinlich, einen Fehler in der Behandlung von Eingaben und der Weitergabe an die dahinterliegende Datenbank einer Anwendung zu finden (SQL Injection), wenn diese gar keine Datenbankanbindung besitzt. In solch einem Fall wäre der Schwerpunkt auf andere Funktionen der Anwendung zu setzen, wie etwa die generelle Eingabevalidierung und Darstellung von Inhalten.

Während des Tests wird die Webapplikation auf verschiedenste bekannte Angriffsvektoren geprüft. Das umfasst in der Regel beispielsweise Cross-Site Request Forgery (CSRF)-Angriffe. Bei diesen können Angreifende von einer fremden Seite aus Aktionen auf der angegriffenen Seite als der dort aktuell angemeldete Benutzer ausführen.

Des Weiteren wird überprüft, ob über die Anmeldemaske oder die "Passwort vergessen"-Funktion valide E-Mail-Adressen ermittelt werden können. Bei einem erfolgreichen Angriff liefert hier die Anwendung unterschiedliche Antworten, abhängig davon, ob die E-Mail-Adresse im System hinterlegt ist oder nicht. Auch sind Unterschiede in den Antwortzeiten ein Indiz dafür, ob die E-Mail-Adresse existiert oder nicht. Zur Analyse von Anmeldemasken, die die SySS im Rahmen von Penetrationstests durchführt, gehört auch die Prüfung, ob ein erfolgreicher Brute-Force-Angriff möglich ist. Hierbei werden für einen Account viele verschiedene Passwörter ausprobiert. Danach wird der Versuch unternommen, einen regulären Login auszuführen, um ein erratenes Passwort zu simulieren. Ist ein Login erfolgreich, so ist die Anwendung anfällig für einen solchen Angriff.

Außerdem wird ermittelt, ob die Webapplikation verwundbar für Cross-Site Scripting (XSS)-Angriffe ist. Bei einem XSS-Angriff gelingt es einem Angreifer, eigenen JavaScript-Code einzuschleusen und im Browser des Nutzers auszuführen. Damit ist der Angreifer in der Lage, komplett zu bestimmen, wie die Seite im Browser des Nutzers aussieht und wie sie sich verhält. Es gibt verschiedene Möglichkeiten, wie ein Angreifer einen solchen Vektor platzieren kann: Beispielsweise kann er über die URL selbst mitgegeben werden, es kann aus einem Eingabefeld ausgebrochen oder eine HTML-Datei mit einem Angriffsvektor selbst hochgeladen werden.

Funktionen zum Dateiupload werden in Penetrationstests meist genauer betrachtet, da sich hier direkt mehrere mögliche Angriffe realisieren lassen. So wird bei Dateiuploads geprüft, welche Dateien hochladbar sind und ob entsprechende Prüfungen auf erlaubte Dateitypen umgangen werden können. Auch wird überprüft, ob sich eine Datei an einen anderen Ort speichern lässt, als es von der Anwendung vorgesehen ist. Dies kann beispielsweise über die Manipulation des Dateinamens geschehen. Des Weiteren wird geteste, ob sich gefährliche Dateianhänge hochladen lassen, die beispielsweise Schadsoftware enthalten. Verbunden mit einem Dateiupload ist auch ein erneuter Download. Hier ist entscheidend, wer die hochgeladenen Dateien herunterladen kann und wie die Dateien erneut abgerufen werden können. So kann ein Upload von Schadsoftware in Verbindung mit einem öffentlich abrufbaren Link zu dieser Datei dazu genutzt werden, Schadsoftware über eine Applikation zu verbreiten. Für den Upload von Schadsoftware verwendet die SySS beim Test keine reale Schadsoftware. Vielmehr wird der EICAR-Teststring genutzt. Hierbei handelt es sich um eine Zeichenfolge, die von vielen Antivirenprodukten erkannt wird. Mit ihrer Hilfe kann die Funktionstüchtigkeit einer Antivirensoftware überprüft werden.

Aus Dateiuploads ergeben sich aber noch weitere mögliche Einfallstore: Wird eine hochgeladene Datei nicht zum Download angeboten, sondern die Darstellung dem Browser überlassen, so ergibt sich die Möglichkeit eines XSS-Angriffs oder von Phishing. Werden hochgeladene Dateien mit ausführbarem Code (wie beispielsweise PHP-Befehle in Dateien) vom Server selbst interpretiert, so kann ein Angreifer dies nutzen, um Befehle in der Applikation selbst – und in vielen Fällen auch auf dem darunterliegenden Server – auszuführen.

Zu den häufiger anzutreffenden Schwachstellen zählen auch Fehler in der Berechtigungsprüfung. Im Penetrationstest wird analysiert, ob ein angemeldeter Benutzer Aktionen ausführen kann, für die er nicht die erforderlichen Berechtigungen besitzt. Dies umfasst auch die Frage, ob Daten anderer Nutzer verändert werden können. Daher bittet die SySS für Penetrationstests immer um Accounts verschiedener Berechtigungsstufen. Auch wenn höher berechtigte Accounts selbst nicht im Testfokus sind, ist es von Vorteil, wenn solche für den Test bereitgestellt werden. Dies ermöglicht es den projektverantwortlichen IT Security Consultants, leichter Funktionen zu identifizieren, die nur höher berechtigten Nutzern zur Verfügung stehen. Andernfalls müssen diese Funktionen teils erraten werden oder sie bleiben im Zweifel unentdeckt und damit ungeprüft.

Neben der Analyse der klassischen Webschwachstellen erfolgt auch eine Prüfung der Ablauflogik. Diese Prüfungen unterscheiden sich individuell je nach geprüfter Anwendung. So wird im Falle eines Webshops beispielsweise ermittelt, ob ein Gutschein nochmals verwendet werden kann, obwohl dieser bereits eingelöst worden ist.

In Penetrationstests überprüft die SySS Anwendungen nicht nur auf die klassischen Schwachstellen, die durch Angreifende ausgenutzt werden können. Ebenso werden die Anwendungen auch auf Schwächen untersucht, die Angreifenden unnötig viele Informationen über die verwendete Software und die allgemeine Architektur der Anwendung liefern. Hierzu gehören beispielsweise zu ausführliche Fehlermeldungen, Versionspreisgaben der Anwendung und ihrer Komponenten oder auch detaillierte Informationen in durch die Anwendung bereitgestellten Dateien.

In Tests selbst erhält die SySS allerdings nur selten Zugriff auf den Programmcode der zu testenden Anwendung. Ob der Programmcode für einen Test bereitgestellt wird, hängt unter anderem auch davon ab, welches Testszenario gewählt wird. Beim Blackbox-Ansatz tappen die Consultants "im Dunkeln" und erhalten keine Informationen. Funktionen und Funktionsweisen müssen erforscht, die grundlegende Logik muss verstanden werden. Der Vorteil hierbei liegt darin, dass Schwachstellen gefunden werden, die beispielsweise aus ungewöhnlichen Eingaben resultieren. Viele Funde entstehen auch durch simples "Herumprobieren". Dem gegenüber steht ein Whitebox-Ansatz. Hier erhalten die Penetrationstester möglichst viele Informationen, wie beispielsweise Dokumentation, Programmcode und, je nach Komplexität, auch eine kurze fachliche Einführung in die Anwendung. Dies ermöglicht es ihnen, die Anwendung ähnlich wie ein regulärer User zu bedienen. Der Vorteil liegt darin, dass weniger Zeit für die Einarbeitung in die Anwendung benötigt wird und damit eine breitere Testabdeckung erreicht werden kann. Durch Sichtung der Dokumentation können die SySS-Consultants leichter fachliche Fehler entdecken, die ohne Informationen nicht unmittelbar ersichtlich wären. Allerdings ergibt sich so nicht selten ein eingeschränkter Tunnelblick, da die Pentester in diesem Moment die Sicht eines regulären Users einnehmen, der mit dem zu testenden Gegenstand bereits vertraut ist. Deswegen gibt es einen Zwischenweg zwischen den beiden Ansätzen, den sogenannten Greybox-Ansatz. Hier werden nur einige nötige Informationen für den Test bereitgestellt. Auf Nachfrage können die SySS-Consultants noch mit weiteren Informationen versorgt werden. Der Greybox-Ansatz versucht also, das Beste aus beiden Welten zu vereinen. Da dieser Ansatz sich in der Vergangenheit bei vielen Projekten bewährt hat, empfiehlt die SySS für Tests meist, den Greybox-Ansatz zu wählen.

Welche Ergebnisse liefert ein Pentest?

Die hier dargestellten Prüfungen bilden nur einen Teil aller Schwachstellen ab, die getestet werden. Sowohl in dem hier geschilderten Szenario eines Webapplikationstests als auch in einem realen Test werden weitaus mehr Schwachstellen geprüft. Auch steht am Ende eines regulären Penetrationstests bei der SySS kein Blogartikel, sondern ein hochwertiger Abschlussbericht im PDF-Format oder in gedruckter und gebundener Form. Auf Wunsch sind auch andere Ausgabeformate möglich. Die Abschlussberichte der SySS werden nicht unmittelbar bei Testende übergeben, sondern erst mit einigen Tagen Abstand. Der Grund dafür ist das zweistufige Qualitätssicherungsverfahren für die Berichte. Es besteht aus einer technischen Qualitätssicherung durch einen weiteren SySS IT Security Consultant und einer sprachlichen Qualitätssicherung durch das SySS-Lektorat. Das zweistufige Qualitätssicherungsverfahren stellt sicher, dass Kunden einen hochwertigen Bericht erhalten, der in seinen unterschiedlichen Abschnitten alle relevanten Zielgruppen adressiert und auch dem Management vorgelegt werden kann. Natürlich gibt es auch Szenarien, in denen die Ergebnisse so schnell wie möglich vorliegen sollen. In solchen Fällen besteht die Möglichkeit, bereits eine Entwurfsfassung nach der technischen Qualitätssicherung zu erhalten.

Die SySS versteht sich nicht nur als Dienstleister für Penetrationstests, sondern nimmt allgemein das Thema der IT-Sicherheit ernst und zeigt Verantwortung. Daher werden die im Rahmen von Tests und Forschungsprojekten gefundenen Schwachstellen von Produkten vertrauensvoll an den Hersteller gemeldet, damit diese behoben werden können. Die SySS arbeitet hier mit ihren Kunden und den Herstellern eng zusammen, um sicherzustellen, dass gefundene Sicherheitsschwachstellen zeitnah behoben werden können. In Kundenprojekten selbst obliegt es dem Kunden, ob er die gefundenen Schwächen eigenständig an den Hersteller eines Produktes melden möchte oder ob dies in Zusammenarbeit mit der SySS in Form eines Responsible Disclosure-Verfahrens erfolgt.

Sollten Sie nach diesem Artikel noch Fragen zum Thema Penetrationstests haben oder einen Test mit uns durchführen wollen, freuen wir uns auf Ihre Nachricht an anfrage(at)syss.de.