Pentest: Welche Komponenten sollten als Erstes betrachtet werden?

Jedes System hat Schwachstellen - absolute Sicherheit gibt es nicht. Penetrationstests helfen Ihnen dabei, diese Schwachstellen zu identifizieren und zu beheben. Aber moderne Anwendungen werden zunehmend komplexer: Neben der Kernanwendung kommen meistens noch Funktionen hinzu, die von Drittanbietern per API eingebunden werden. Die Ressourcen für Pen-Tests sind begrenzt. Daher stellt sich vielen Organisationen die Frage: Welche Komponenten meiner Software sind besonders gefährdet und sollten deshalb zuerst im Pen-Test überprüft werden?

Schwachstellen systematisch bewerten mit dem CVSS

Jedes System hat Schwachstellen. Aber nicht jede Schwachstelle ist gleich wichtig.
Neben dem Zugangsvektor, der Komplexität und der Authentifizierung spielen auch Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit eine Rolle bei der Bewertung von Schwachstellen.

Für die Bewertung wird oft das Common Vulnerability Scoring System (CVSS) verwendet. Das CVSS bieten Organisationen die Möglichkeit, die Schwachstellen der eigenen Architektur quantitativ auszudrücken. Jeder Wert korrespondiert dabei mit einer von vier Schwachstellen-Kategorien:

Kritischer Schweregrad

Kritische Schwachstellen erlauben es Angreifern, eigenen Code auf dem Zielsystem auszuführen oder auf sensible Daten zuzugreifen. Verbreitete kritische Sicherheitslücken sind BOLA, Remote Code Execution oder Command Injections.

Sicherheitslücken mit hohem Schweregrad erlauben es Angreifern, auf die Ressourcen und Daten einer Anwendung zuzugreifen. Dadurch kann er sensible Daten stehlen. Ein bekanntes Beispiel einer Schwachstelle mit hohem Schweregrad ist die SQL-Injection. Hierbei gelingt es dem Angreifer, über benutzerdefinierte Felder auf die Datenbank des Systems zuzugreifen. Im Unterschied zur kritischen Schwachstelle können Schwachstellen mit hohem Schweregrad allein nie zur Preisgabe sämtlicher Daten führen. Hierzu müssen Angreifer weitere Angriffsvektoren finden.

Mittlerer Schweregrad

Eine Schwachstelle mittleren Schweregrades lässt sich meisten auf Fehler in der Konfiguration - zum Beispiel ein fehlerhaftes SSL-Zertifikat - zurückführen. Dadurch können Angreifer auf sensible Informationen zugreifen. Eine solche Lücke stellt allerdings hohe Voraussetzungen an den Angreifer. Im Falle des falschen Zertifikats muss er sich beispielsweise an einem bestimmten Ort befinden, um zum richtigen Zeitpunkt Daten mitzulesen.

Niedriger Schweregrad

Schwachstellen mit niedrigem Schweregrad sind entweder auf Fehler in der Konfiguration oder der versehentlichen Preisgabe von Informationen zurückzuführen und in Ihrer Wirkung nicht geeignet, signifikanten Schaden anzurichten. Diese Schwachstellen können für einen Angreifer allerdings eine Basis sein, schwerere Schwachstellen zu nutzen. Ein Beispiel für eine Schwachstelle mit niedrigem Schweregrad ist die Preisgabe der Versionsnummer. Wenn eine Website die Versionsnummer einer Anwendung preisgibt, kann ein Angreifer ein Vulnerability-Mapping durchführen. Existiert bereits eine Schwachstelle für diese Anwendung in der Version, kann er sie nutzen, um sich dann Zugriff auf das System zu verschaffen.

Welche Komponenten sind gefährdet?

Aus der Kategorisierung von Schwachstellen lassen sich Rückschlüsse auf die richtige Priorisierung beim Penetrationstest ziehen.

Gemessen an den Schweregraden sind bestimmte Bereich der Softwarearchitektur gefährdeter als andere. Mobile-Anwendungen sind höchstens von Schwachstellen mit hohem Schweregrad betroffen. Darüber kann er nur einzelne Nutzer angreifen, aber nicht auf alle Daten im System zugreifen.

Moderne Anwendungen werden nicht von Grund auf neu gebaut. Jede Webanwendung greift auf externe Services zu, um wichtige Standardfunktionen einzubauen, deren Eigenentwicklung nicht sinnvoll oder nicht möglich ist. Dazu gehören beispielsweise Captchas, Kreditkartenzahlungen oder E-Mail-Adressen-Validierungen. Solche API-Schnittstellen können dagegen kritische Schwachstellen aufweisen, die das ganze System gefährden. Das liegt daran, dass eine API-Schnittstelle qua Funktion tief in das System greift. Wer sich Zugang zur API-Schnittstelle verschafft, hat also eine Art Generalschlüssel an der Hand.

BOLA: API-Schwachstelle Nr. 1

Die heute größte Schwachstelle von API-Schnittstellen ist die Broken Object Level Autorisation - BOLA. Zu diesem Ergebnis kommt das Open Web Application Security Project OWASP in seinem Bericht zu den Top 10 API-Sicherheitslücken.

BOLA war die Schwachstelle, die für viele populäre Angriffe verantwortlich war. Opfer dieser Angriffe waren unter anderem die Telekom und Apple. BOLA bezieht sich auf Fehler in der Autorisierung bei der API-Schnittstelle. Ein populäres Beispiel ist die Schwachstelle in der App des Taxiunternehmens Uber, die 2019 bekannt wurde.

Das Taxiunternehmen fragte E-Mail-Adresse und Telefonnummer des Users ab und überprüft dabei das Format. Werden nun E-Mail-Adresse und Telefonnummer vertauscht, gibt die API von Uber eine Fehlermeldung zurück, die UUID - die eindeutige Identifizierung des Nutzers enthält. Über diese Schwachstelle wäre es möglich, anhand der Telefonnummer oder der E-Mail-Adresse an die UUID des Nutzers zu kommen.

Penetrationstest priorisieren: API als Erstes prüfen

Für die meisten Anwendungen ist es sinnvoll, zunächst die API-Schnittstelle zu überprüfen. Ausschließlich hier können Schwachstellen des Schweregrades kritisch entstehen, wenn man diese im Kontext mit mobilen Apps betrachtet. Dadurch kann ein Angreifer im Worst-Case-Szenario Zugriff auf alle Nutzerdaten erhalten. Neben dem dadurch entstehenden wirtschaftlichen Schaden ist auch der Image-Schaden durch eine solche Schwachstelle massiv.

Ein System wie der CVSS hilft Ihnen, die vorliegenden Bedrohungen zu bewerten und sinnvoll gegeneinander abzuwägen. Der CVSS stellt Ihnen auf Ihrer Website ein Tool zur Quantifizierung zur Verfügung. Mit dem Tool von turingsecure können Sie Schwachstellen nach CVSS berechnen.