Pentest: Welche Komponenten sollten als Erstes betrachtet werden?

Jedes System hat Schwachstellen - absolute Sicherheit gibt es nicht. Penetrationstests helfen Ihnen, diese Schwachstellen zu identifizieren und zu beheben. Doch moderne Anwendungen werden zunehmend komplexer: Neben der Kernanwendung kommen häufig Funktionen hinzu, die über APIs von Drittanbietern eingebunden werden. Da die Ressourcen für Pentests begrenzt sind, stellt sich für viele Organisationen die Frage: Welche Komponenten Ihrer Software sind besonders gefährdet und sollten daher im Pentest zuerst überprüft werden?

Schwachstellen systematisch bewerten mit dem CVSS

Jedes System hat Schwachstellen - doch nicht jede ist gleich kritisch.
Neben dem Zugangsvektor, der Komplexität und der erforderlichen Authentifizierung fließen auch die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit in die Bewertung ein.

Zur Einordnung wird häufig das Common Vulnerability Scoring System (CVSS) herangezogen. Das CVSS ermöglicht es Organisationen, Schwachstellen in ihrer Architektur quantitativ zu bewerten. Jeder Wert entspricht dabei einer von vier Schweregrad-Kategorien:

Kritischer Schweregrad

Kritische Schwachstellen ermöglichen es Angreifern, eigenen Code auf dem Zielsystem auszuführen oder auf sensible Daten zuzugreifen. Typische Beispiele sind BOLA, Remote Code Execution und Command Injections.

Schwachstellen mit hohem Schweregrad erlauben Angreifern den Zugriff auf Ressourcen und Daten einer Anwendung und damit den Diebstahl sensibler Informationen. Ein bekanntes Beispiel ist die SQL-Injection: Dabei gelingt es dem Angreifer, über Eingabefelder auf die Datenbank des Systems zuzugreifen. Im Unterschied zu kritischen Schwachstellen führen solche mit hohem Schweregrad allein nie zur Offenlegung sämtlicher Daten. Dafür müssen Angreifer zusätzliche Angriffsvektoren finden.

Mittlerer Schweregrad

Schwachstellen mittleren Schweregrades lassen sich meist auf Konfigurationsfehler zurückführen - etwa ein fehlerhaftes SSL-Zertifikat. Dadurch können Angreifer auf sensible Informationen zugreifen. Allerdings stellt eine solche Lücke hohe Anforderungen an den Angreifer: Im Fall eines falschen Zertifikats muss sich dieser beispielsweise an einem bestimmten Ort befinden, um zum richtigen Zeitpunkt Daten mitzulesen.

Niedriger Schweregrad

Schwachstellen mit niedrigem Schweregrad beruhen entweder auf Konfigurationsfehlern oder der versehentlichen Preisgabe von Informationen. Für sich genommen richten sie keinen signifikanten Schaden an. Allerdings können sie Angreifern als Ausgangspunkt dienen, um schwerwiegendere Schwachstellen auszunutzen. Ein typisches Beispiel ist die Preisgabe der Versionsnummer: Wenn eine Website die Version einer Anwendung offenlegt, kann ein Angreifer gezieltes Vulnerability-Mapping durchführen. Ist für diese Version bereits eine Schwachstelle bekannt, lässt sie sich nutzen, um Zugriff auf das System zu erlangen.

Welche Komponenten sind gefährdet?

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

Gemessen an den Schweregraden sind bestimmte Bereiche der Softwarearchitektur gefährdeter als andere. Mobile Anwendungen sind höchstens von Schwachstellen mit hohem Schweregrad betroffen. Ein Angreifer kann dadurch zwar einzelne Nutzer angreifen, erhält jedoch keinen Zugriff auf sämtliche Daten im System.

Moderne Anwendungen werden nicht von Grund auf neu entwickelt. Jede Webanwendung nutzt externe Services, um wichtige Standardfunktionen einzubinden, deren Eigenentwicklung nicht sinnvoll oder nicht möglich ist - etwa Captchas, Kreditkartenzahlungen oder E-Mail-Validierungen. Genau diese API-Schnittstellen können jedoch kritische Schwachstellen aufweisen, die das gesamte System gefährden. Der Grund: Eine API-Schnittstelle greift funktionsbedingt tief in das System ein. Wer sich Zugang zu ihr verschafft, besitzt damit eine Art Generalschlüssel.

BOLA: API-Schwachstelle Nr. 1

Die derzeit gravierendste Schwachstelle von API-Schnittstellen ist die Broken Object Level Authorization (BOLA). Zu diesem Ergebnis kommt das Open Web Application Security Project OWASP in seinem Bericht zu den Top 10 der API-Sicherheitslücken.

BOLA war für zahlreiche aufsehenerregende Angriffe verantwortlich. Zu den betroffenen Unternehmen zählten unter anderem die Telekom und Apple. Die Schwachstelle bezieht sich auf Fehler in der Autorisierung der API-Schnittstelle. Ein bekanntes Beispiel ist die Sicherheitslücke in der App des Fahrdienstleisters Uber, die 2019 öffentlich wurde.

Uber fragte E-Mail-Adresse und Telefonnummer des Nutzers ab und prüfte dabei das Format. Wurden E-Mail-Adresse und Telefonnummer vertauscht, gab die API eine Fehlermeldung zurück, die die UUID - also die eindeutige Kennung des Nutzers - enthielt. Über diese Schwachstelle war es möglich, anhand der Telefonnummer oder E-Mail-Adresse die UUID eines Nutzers zu ermitteln.

Penetrationstest priorisieren: API als Erstes prüfen

Für die meisten Anwendungen ist es sinnvoll, zunächst die API-Schnittstelle zu überprüfen. Gerade im Zusammenspiel mit mobilen Apps können hier ausschließlich Schwachstellen kritischen Schweregrades auftreten. Im schlimmsten Fall erhält ein Angreifer dadurch Zugriff auf sämtliche Nutzerdaten. Neben dem wirtschaftlichen Schaden ist auch der Reputationsverlust durch eine solche Schwachstelle erheblich.

Ein Bewertungssystem wie der CVSS hilft Ihnen, die vorliegenden Bedrohungen einzuordnen und sinnvoll gegeneinander abzuwägen. Mit dem CVSS-Rechner von FIRST.org können Sie den Schweregrad Ihrer Schwachstellen berechnen.