Sicherheitslücken gezielt im Testprozess identifizieren

Stellen wir uns vor, ein Softwarehersteller entwickelt ein Kundenportal für eine Versicherung.

Der Quellcode wurde geprüft:

• Funktionstests erfolgreich
• Benutzerverwaltung funktioniert
• Fachliche Anforderungen erfüllt
• Performancetests bestanden

Das Produkt wird anschließend mit PHP 8.x ausgeliefert.

Einige Monate später stellt sich heraus, dass ein Angreifer durch einen speziell manipulierten HTTP-Request die PHP-Laufzeitumgebung selbst kompromittieren kann und dadurch Befehle auf dem Server ausführen kann. Genau ein solches Szenario wird bei PHP2Shell beschrieben.

Die Frage lautet nun: Wie hätte ein strukturierter Testprozess dies möglicherweise schon vor der Freigabe erkennen können?

Was häufig falsch gemacht wird
Oft werden lediglich Funktionstests eingeplant:

---

»Kann sich der Benutzer anmelden?«
»Kann ein Vertrag gespeichert werden?«

---

Sicherheitstests werden nicht berücksichtigt.

Was hätte gemacht werden müssen
Bereits in der Testplanung hätte die Risikoanalyse ergeben:

• Internetanwendung
• Verarbeitung sensibler Kundendaten
• Nutzung einer externen Laufzeitumgebung (PHP)
• hohes Schadenpotenzial bei Serverübernahme

Daraus hätten folgende Testziele abgeleitet werden können:
Geplante Sicherheitstests

• Penetrationstest
• Fuzzing-Test
• Robustheitstest
• Dependency-Analyse
• Schwachstellenanalyse der verwendeten Frameworks und Laufzeitumgebungen

Ein Testmanager hätte beispielsweise festlegen können:

---

»Für alle extern erreichbaren Schnittstellen werden Missbrauchs- und Fuzzing-Tests durchgeführt.«

---

Genau solche Tests zielen auf Fehler in der Verarbeitung unerwarteter Eingaben ab, wie sie bei Speicherkorruptionen häufig auftreten.

Jetzt werden konkrete Testfälle entwickelt.

Typischer funktionaler Testfall

Mit diesem funktionalen Testfall wird jedoch keine Sicherheitslücke entdeckt.

Sicherheitstechnischer Testfall

Weiterer Testfall:

Noch besser wäre ein Fuzzing-Test:

Speicherfehler zeigen sich oft durch:

• Serverabstürze
• Speicherzugriffsfehler
• Segmentation Faults
• unerwartete Prozessabbrüche

Solche Symptome sind häufig die ersten Hinweise auf kritische Schwachstellen.

Hier werden die Tests tatsächlich ausgeführt.

Beispiel
Das Testteam startet einen Fuzzing-Test gegen den Webserver.


Die Logs zeigen:


Nun wird ein Defect eröffnet.

Defect-Beispiel


Ein guter Security-Tester würde nun nicht sagen:

---

"Der Test ist erfolgreich."

---

Sondern:

---

"Warum kann ein einzelner HTTP-Request den PHP-Prozess zum Absturz bringen?"

---

Genau diese Fragestellung führt häufig zur Entdeckung von Zero-Day-Schwachstellen.

Beispiel eines Pentests
Ein Pentester sendet:


Der Server zeigt:


Kurze Zeit später:


Das allein beweist noch keine Sicherheitslücke.

Aber es beweist:

---

Eine externe Eingabe kann die Laufzeitumgebung beeinflussen.

---

Dies wäre bereits ein schwerwiegender Befund gewesen.

Im Testabschluss bewertet der Testmanager die Testergebnisse.

Testabschluss


Das Projekt würde nun zurück in die Fehleranalyse gehen.

Die Entwickler könnten beispielsweise:

• PHP-Hersteller informieren
• Proof-of-Concept erstellen
• Bug reproduzieren
• Patch entwickeln

Im Idealfall würde die Sicherheitslücke erkannt und behoben, bevor die Software produktiv eingesetzt wird.

Ein Beispiel für eine solche Sicherheitslücke ist Cloudbleed. Dabei handelt es sich, ähnlich wie bei Heartbleed¹, um einen Sicherheitsfehler, der zu einem Buffer Overflow (Pufferüberlauf) führt, welcher es einem Angreifer ermöglicht, über das Ende eines Puffers hinaus Informationen aus dem Speicher des betroffenen Servers auszulesen.

Cloudbleed wurde im Februar 2017 entdeckt und betraf Reverse-Proxys des amerikanischen Unternehmens für Webinfrastruktur Cloudflare.²

Es konnten u.a. private Informationen wie HTTP-Cookies, Authentifizierungstokens und andere sensible Daten ausgelesen werden.

Zum Teil handelte es sich dabei um Daten, die im Cache von Suchmaschinen gespeichert waren.
Die Fragen, die sich in diesem Zusammenhang stellen, sind:

• Hätte dies verhindert werden können?
• Hätte der Buffer Overflow Fehler schon frühzeitig, zum Beispiel im Rahmen des Testprozesses, erkannt werden können?
• Wie ist die Software implementiert? Design und Umsetzung bezüglich Ausnutzung der verfügbaren Ressourcen

¹ https://de.wikipedia.org/wiki/Heartbleed
² https://en.wikipedia.org/wiki/Cloudflare

Um Schwachstellen gezielt zu identifizieren, Risiken zu ermitteln und die Wirksamkeit von bereits bestehenden Schutzmaßnahmen nachzuweisen, können Sicherheitstests eingesetzt werden. Die in diesem Zusammenhang eingesetzten Testverfahren sollten dabei über den gesamten Testprozess hinweg berücksichtigt werden. So können nicht nur potenzielle Sicherheitslücken frühzeitig erkannt und geschlossen werden, sondern Sicherheitsaspekte gezielt bei der Planung, dem Entwurf und der Durchführung von Testaktivitäten berücksichtigt werden.

Der fundamentale Testprozess (nach ISTQB®) gibt einen Überblick darüber, welche Phasen im Rahmen des Testprozesses durchlaufen werden:

• Testplanung
• Testüberwachung und -steuerung
• Testanalyse
• Testentwurf
• Testrealisierung
• Testdurchführung
• Testabschluss

Wie kann „Sicherheit“ nun in diesen Phasen des Testprozesses gezielt berücksichtigt werden?
Welche Aktivitäten sind notwendig, um „Sicherheit“ in den Testprozess zu integrieren?

Im Rahmen der Testplanung muss der Umfang für die durchzuführenden Sicherheitstests festgelegt werden, sowie klare zu erreichende Sicherheitsziele definiert werden.
Grundlage dafür ist eine Analyse der bestehenden Sicherheitsrisiken für die zu entwickelnde Software.
Dabei kann es sich z.B. um potenziell vorhandene Schwachstellen handeln. Auf diese Weise können Komponenten der Software, die ein hohes Sicherheitsrisiko aufweisen, intensiver getestet werden, um diesem Risiko gezielt zu begegnen.
Auch wird in der Testplanung festgelegt, welche Ressourcen speziell für den Sicherheitstest zur Verfügung stehen und es werden Schätzungen und Zeitpläne für die Testdurchführung erstellt.

Im Rahmen der Testüberwachung und -steuerung kann auf die in der Testplanung festgelegten Kenngrößen zurückgegriffen werden, um zu überprüfen, ob die gesteckten Sicherheitsziele erreicht wurden und ggf. Korrekturmaßnahmen erforderlich sind.

In der Phase der Testanalyse wird klassischerweise die Testbasis analysiert, um konkrete Testbedingungen zu identifizieren. Aus diesen werden dann im Rahmen des Testentwurfs Testfälle abgeleitet.

Ergänzend sollten als Basis für die Ableitung von Sicherheitstests Sicherheitsrisikobewertungen, Sicherheitsanforderungen und Sicherheitsrichtlinien in der Testanalyse herangezogen werden.

Auf Basis von Testzielen, Sicherheitsrisiken, Sicherheitsstandards oder bereits bekannten Schwachstellen können so wichtige Erkenntnisse über konkrete Sicherheitsgefährdungen gewonnen werden. Hinsichtlich dieser identifizierten Sicherheitsbedingungen können dann konkrete Sicherheitstestfälle abgeleitet werden.

Im Rahmen der Testrealisierung und -durchführung werden die konzeptuell erstellten Testfälle in manuellen oder automatisierten Tests umgesetzt.
Dabei ist es gerade bei Sicherheitstests sinnvoll, eine Vielzahl von Perspektiven zu berücksichtigen:

• Welche Gefährdungen ergeben sich durch interne Benutzer?
• Wie können externe oder böswillige Benutzer meinem System Schaden zufügen oder sensible Informationen abgreifen?

Es müssen Sicherheitstestfälle, Testszenarien, Testskripte oder andere Testspezifikationen erstellt werden, die genau diesen Herausforderungen begegnen.
Dabei können funktionale Sicherheitstests auf Basis definierter Sicherheitsspezifikationen oder funktionale Sicherheits- und Penetrationstests dank der Kenntnisse und Intuition des Testers durchgeführt werden.

Die Testfälle, Testskripte und Dokumentation über die operative Durchführung der Tests sollte nachhaltig und zentral erfolgen, z.B. in einem Testmanagementwerkzeug.

Nachdem die Sicherheitstests erfolgreich durchgeführt wurden, müssen die Testendekriterien bewertet und ein Abschlussbericht erstellt werden.
Dazu müssen die Ergebnisse des Sicherheitstests evaluiert werden, um konkrete Schwachstellen angesichts der Testergebnisse zu identifizieren. Auch sollte die Sicherheitsrisikostufe auf Basis der durchgeführten Tests evaluiert werden und Zwischen- bzw. Abschlussergebnisse an relevante Stakeholder (z.B. die Geschäftsführung) übermittelt werden.

Um die Testaktivitäten abzuschließen, sollten weiterhin sämtliche Testmittel und Testergebnisse archiviert werden, damit sie verfügbar sind, wenn sie für spätere Sicherheitstests benötigt werden.

Können Sicherheitslücken, wie im Beispiel von Cloudbleed, also gezielt vermieden bzw. behoben werden?

– Wir wissen, dass das möglich ist!

Im Rahmen des Sicherheitstestprozesses werden mögliche Sicherheitsrisiken bereits bei der Testplanung identifiziert.
Dies kann z.B. auf Basis historischer Daten (d.h. bereits aufgetretener Sicherheitslücken) geschehen.

In diesem Blogbeispiel hätte ein möglicher Pufferüberlauf, basierend auf der bereits existierenden Schwachstelle Heartbleed, als mögliches Sicherheitsrisiko erkannt werden können.

Im Rahmen der Testanalyse und des -entwurfs hätten dann gezielte Sicherheitstests und Maßnahmen entworfen werden können, um dem Risiko des Pufferüberlaufs begegnen zu können.
So hätten zum Beispiel Codereviews mit einem Fokus auf sicherer Speicherverwaltung eingesetzt werden können, um Probleme frühzeitig zu erkennen und zu beheben.

Meine Empfehlung: Berücksichtigen Sie daher von Anfang an sicherheitsrelevante Aspekte in der Gestaltung Ihres Testprozesses, um Sicherheitslücken von Anfang an zu vermeiden oder diese zumindest gezielt frühzeitig zu erkennen.