Schwachstellenscanning und sichere Entwicklung. Teil 1

Im Rahmen ihrer professionellen Tätigkeit sehen sich Entwickler, Penetrationstester und Sicherheitsexperten mit Prozessen wie Vulnerability Management (VM) und (Secure) SDLC konfrontiert.
Hinter diesen Begriffen verbergen sich verschiedene Praktiken und verwendete Werkzeuge, die miteinander verknüpft sind, obwohl ihre Nutzer unterschiedlich sind.

Der technische Fortschritt hat bisher nicht ausgereicht, um ein Werkzeug zu entwickeln, das den Menschen beim Sicherheitsanalysen von Infrastrukturen und Software ersetzen kann.
Es ist interessant zu verstehen, warum das so ist und mit welchen Herausforderungen man konfrontiert ist.

Prozesse

Der Prozess des Vulnerability Managements dient der kontinuierlichen Überwachung der Sicherheit der Infrastruktur und dem Patch-Management.
Der Prozess des Secure SDLC (Sicheren Entwicklungszyklus) soll die Sicherheit der Anwendung während der Entwicklung und des Betriebs unterstützen.

Ein ähnlicher Teil dieser Prozesse ist der Prozess der Vulnerability Assessment – der Schwachstellenerkennung und -scanning.
Der wesentliche Unterschied zwischen dem Scannen im Rahmen von VM und SDLC besteht darin, dass im ersten Fall das Ziel darin besteht, bekannte Schwachstellen in Drittanbieter-Software oder in der Konfiguration zu erkennen. Zum Beispiel eine veraltete Windows-Version oder einen Standard-Community-String für SNMP.
Im zweiten Fall hingegen ist das Ziel, Schwachstellen nicht nur in externen Komponenten (Abhängigkeiten), sondern vor allem im Code des neuen Produkts zu identifizieren.

Das führt zu Unterschieden in den Werkzeugen und Ansätzen. Meiner Meinung nach ist die Suche nach neuen Schwachstellen in der Anwendung deutlich spannender, da sie nicht auf Fingerprinting von Versionen, das Sammeln von Bannern, Passwort-Brute-Forcing usw. beschränkt ist.
Für eine qualitativ hochwertige automatisierte Schwachstellenscannung sind Algorithmen erforderlich, die die Semantik der Anwendung, ihren Zweck und spezifische Bedrohungen berücksichtigen.

Ein Infrastruktur-Scanner kann oftmals durch eine einfache Zeitmessung ersetzt werden, wie es avleonovausgedrückt hat. Der Sinn dahinter ist, dass Sie statistisch betrachtet Ihre Infrastruktur als anfällig ansehen können, wenn Sie sie beispielsweise einen Monat lang nicht aktualisiert haben.

Werkzeuge

Das Scannen, ebenso wie die Sicherheitsanalyse, kann sowohl im Black-Box- als auch im White-Box-Verfahren durchgeführt werden.

Black Box

Beim Blackbox-Scanning muss das Tool in der Lage sein, mit dem Dienst über dieselben Schnittstellen zu arbeiten, die auch die Benutzer verwenden.

Infrastruktur-Scanner (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose usw.) suchen nach offenen Netzwerkports, sammeln „Banner“, bestimmen die Versionen installierter Software und suchen in ihrer Wissensdatenbank nach Informationen zu Schwachstellen in diesen Versionen. Sie versuchen auch, Konfigurationsfehler wie Standardpasswörter oder unbefugten Datenzugriff, schwache SSL-Verschlüsselungen usw. zu erkennen.

Webanwendungsscanner (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP usw.) können ebenfalls bekannte Komponenten und deren Versionen identifizieren (z. B. CMS, Frameworks, JS-Bibliotheken). Die Hauptschritte des Scanners sind Crawling und Fuzzing.
Beim Crawling sammelt der Scanner Informationen über vorhandene Schnittstellen der Anwendung und HTTP-Parameter. Beim Fuzzing werden in alle erkannten Parameter mutierte oder generierte Daten eingegeben, um einen Fehler auszulösen und eine Schwachstelle zu entdecken.

Solche Anwendungsscanner gehören zu den Klassen DAST und IAST — respektive Dynamic und Interactive Application Security Testing.

White Box

Beim Whitebox-Scanning gibt es mehr Unterschiede.
Im Rahmen des VM-Scanning-Prozesses erhalten Scanner (Vulners, Incsecurity Couch, Vuls, Tenable Nessus usw.) oft Zugang zu Systemen, indem sie authentifizierte Scans durchführen. So kann der Scanner die installierten Paketversionen und Konfigurationsparameter direkt aus dem System extrahieren, ohne sie über Banner von Netzwerkdiensten erraten zu müssen.
Der Scan wird dadurch genauer und umfassender.

Spricht man hingegen von Whitebox-Scanning (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs usw.) von Anwendungen, handelt es sich in der Regel um statische Codeanalyse und die Nutzung entsprechender Werkzeuge der Klasse SAST — Static Application Security Testing.

Die Probleme

Es gibt zahlreiche Probleme beim Scanning! Mit den meisten dieser Probleme sehe ich mich persönlich konfrontiert, wenn ich den Service zur Etablierung von Scanning-Prozessen und sicherer Entwicklung bereitstelle sowie bei der Durchführung von Sicherheitsanalysen.

Ich möchte 3 Hauptgruppen von Problemen hervorheben, die sowohl durch Gespräche mit Ingenieuren als auch mit Leitern von IT-Sicherheitsdiensten in verschiedenen Unternehmen bestätigt werden.

Probleme beim Scannen von Webanwendungen

1. Komplexität der Implementierung. Scanner müssen auf jedes einzelne Anwendungsszenario ausgerollt, konfiguriert und angepasst werden. Es ist wichtig, eine Testumgebung für die Scans einzurichten und diese in den CI/CD-Prozess zu integrieren, um effektiv zu sein. Andernfalls wird es nur eine nutzlose formale Prozedur, die bestenfalls falsche Alarme auslöst.
2. Dauer des Scans. Scanner haben sogar im Jahr 2019 Schwierigkeiten mit der Deduplication von Schnittstellen und können tagelang tausend Seiten mit zehn Parametern auf jeder scannen, während sie diese fälschlicherweise als unterschiedlich betrachten, obwohl der gleiche Code dafür verantwortlich ist. In diesem Zusammenhang müssen Entscheidungen über das Deployment in der Produktionsumgebung während des Entwicklungzyklus schnell getroffen werden.
3. Spärliche Empfehlungen. Scanner geben meist sehr allgemeine Empfehlungen, und nicht immer kann der Entwickler schnell ablesen, wie er das Risikoniveau senken kann. Vor allem muss geklärt werden, ob dies sofort erforderlich ist oder ob es momentan noch tragbar ist.
4. Destruktive Auswirkungen auf die Anwendung. Scanner können durchaus einen DoS-Angriff auf die Anwendung ausführen und zudem eine große Anzahl an Entitäten generieren oder bestehende ändern (zum Beispiel könnten sie zehntausende Kommentare in einem Blog erstellen), sodass man den Scan im Produktionsumfeld nicht ohne weiteres starten sollte.
5. Geringe Erkennungsqualität von Sicherheitslücken. Scanner verwenden normalerweise ein festes Set von Payloads und können leicht eine Schwachstelle übersehen, die nicht in ihr bekanntes Verhaltensmuster des Programms passt.
6. Missverständnis der Funktionen der Anwendung durch den Scanner. Scanner wissen nicht, was ein 'Online-Banking', 'Zahlung' oder 'Kommentar' ist. Für sie gibt es nur Links und Parameter, sodass eine Vielzahl möglicher logischer Schwachstellen unbeachtet bleibt. Sie erkennen nicht, dass eine doppelte Abbuchung erfolgen kann, dass sie fremde Daten anhand von IDs einsehen oder das Guthaben durch Rundungen manipulieren können.
7. Missverständnis der Semantik der Seiten durch den Scanner. Scanner können keine FAQs lesen, keine Captchas erkennen und wissen nicht, wie man sich registriert oder dass man sich anschließend erneut einloggen muss, dass der 'Logout'-Button nicht gedrückt werden darf und wie Anfragen beim Ändern von Parameterwerten signiert werden müssen. Infolgedessen kann ein großer Teil der Anwendung ungescannt bleiben.

Probleme beim Scannen des Quellcodes.

1. Falsch-positive Erkennungen. Statische Analyse ist eine komplexe Aufgabe, bei der zahlreiche Kompromisse eingegangen werden müssen. Oftmals muss die Genauigkeit opfert werden, und selbst teure Enterprise-Scanner liefern eine Vielzahl von Fehlalarmen.
2. Komplexität der Implementierung. Um die Genauigkeit und Vollständigkeit der statischen Analyse zu erhöhen, müssen die Scanning-Regeln weiterentwickelt werden, und das Schreiben dieser Regeln kann sich als sehr arbeitsintensiv erweisen. Manchmal ist es einfacher, alle Stellen im Code mit einem bestimmten Bug zu finden und sie zu beheben, als eine Regel für die Erkennung solcher Fälle zu schreiben.
3. Fehlende Unterstützung für Abhängigkeiten. Große Projekte sind auf eine Vielzahl von Bibliotheken und Frameworks angewiesen, die die Möglichkeiten der Programmiersprache erweitern. Wenn im Wissensdatenbank des Scanners keine Informationen über gefährliche Stellen („sinks“) in diesen Frameworks vorhanden sind, entsteht ein blinder Fleck, und der Scanner wird den Code nicht einmal verstehen.
4. Dauer des Scans. Die Suche nach Schwachstellen im Code ist eine komplexe Aufgabe, auch in Bezug auf Algorithmen. Daher kann der Prozess durchaus länger dauern und dabei erhebliche Rechenressourcen erfordern.
5. Niedrige Abdeckung. Trotz des Ressourcenverbrauchs und der Dauer des Scannens müssen Entwickler von SAST-Tools dennoch Kompromisse eingehen und können nicht alle Zustände analysieren, in denen sich eine Anwendung befinden kann.
6. Reproduzierbarkeit der Funde. Der Hinweis auf eine spezifische Zeile und den Aufrufstack, die zu einer Sicherheitsanfälligkeit führen, ist zwar hilfreich, aber in der Praxis liefert der Scanner oft nicht genügend Informationen, um die Schwachstelle von außen zu überprüfen. Denn das Problem kann auch im toten Code liegen, der für einen Angreifer unerreichbar ist.

Probleme beim Scannen der Infrastruktur.

1. Unzureichende Inventarisierung. In großen, insbesondere geografisch verteilten Infrastrukturen ist es oft am schwierigsten zu erkennen, welche Hosts gescannt werden müssen. Mit anderen Worten, die Scanning-Aufgabe ist eng verbunden mit dem Asset-Management.
2. Schlechte Priorisierung. Netzwerkscanner zeigen oft viele Ergebnisse mit Schwachstellen an, die in der Praxis nicht ausnutzbar sind, obwohl sie formal ein hohes Risiko darstellen. Der Benutzer erhält einen Bericht, der schwer zu interpretieren ist, und es bleibt unklar, was zuerst behoben werden muss.
3. Spärliche Empfehlungen. In der Wissensdatenbank des Scanners gibt es oft nur sehr allgemeine Informationen über Schwachstellen und deren Behebung, sodass Administratoren auf Google zurückgreifen müssen. Die Situation ist etwas besser bei Whitebox-Scannern, die eine spezifische Anleitung zur Behebung bereitstellen können.
4. Manuelle Arbeit. In Infrastruktur können viele Knoten vorhanden sein, was potenziell viele Schwächen bedeutet, deren Berichte man bei jeder Iteration manuell auswerten und analysieren muss.
5. Schlechtes Abdeckungsniveau. Die Qualität der Infrastruktur-Scan hängt direkt vom Umfang der Wissensdatenbank über Schwachstellen und Softwareversionen ab. Dabei stellt sich heraus, dass selbst die Marktführer nicht über eine umfassende Wissensdatenbank verfügen und dass in den Datenbanken kostenloser Lösungen viele Informationen vorhanden sind, die bei den Marktführern nicht zu finden sind.
6. Probleme beim Patchen. In der Regel besteht das Patchen von Schwachstellen in der Infrastruktur aus der Aktualisierung eines Pakets oder der Änderung einer Konfigurationsdatei. Ein großes Problem dabei ist, dass das System, insbesondere Legacy-Systeme, sich nach einem Update unvorhersehbar verhalten kann. Im Wesentlichen müssen Integrations-Tests in der produktiven Infrastruktur durchgeführt werden.

Ansätze

Was sollen wir tun?
In den folgenden Teilen werde ich mehr über Beispiele und den Umgang mit vielen der genannten Probleme erläutern. Hier sind zunächst einige Hauptbereiche, in denen man arbeiten kann:

1. Aggregation verschiedener Scanning-Tools. Bei richtiger Anwendung mehrerer Scanner kann man die Wissensbasis und die Qualität der Erkennung erheblich steigern. Man kann sogar mehr Schwachstellen finden, als wenn alle Scanner jeweils einzeln gestartet werden, während man die Risikoebene genauer bewerten und mehr Empfehlungen geben kann.
2. Integration von SAST und DAST. Man kann die DAST-Abdeckung und die SAST-Genauigkeit durch den Austausch von Informationen zwischen ihnen erhöhen. Aus den Quellcodes kann man Informationen über vorhandene Routen erhalten, und mit DAST kann überprüft werden, ob die Schwachstelle von außen sichtbar ist.
3. Machine Learning™. 2015 habe ich erzählt (und noch) über den Einsatz von Statistiken, um Scannern die Intuition eines Hackers zu verleihen und sie zu beschleunigen. Das ist sicherlich ein Denkanstoß für die Weiterentwicklung der automatischen Sicherheitsanalyse in der Zukunft.
4. Integration von IAST mit automatisierten Tests und OpenAPI. Im Rahmen eines CI/CD-Pipelines kann ein Scanning-Prozess auf Basis von Tools eingerichtet werden, die als HTTP-Proxy fungieren, sowie von funktionalen Tests, die über HTTP durchgeführt werden. Tests und OpenAPI/Swagger-Verträge liefern dem Scanner die erforderlichen Informationen über Datenflüsse und ermöglichen das Scannen der Anwendung in verschiedenen Zuständen.
5. Die richtige Konfiguration. Für jede Anwendung und Infrastruktur muss ein geeigneter Scanning-Profil erstellt werden, das die Anzahl und Art der Schnittstellen sowie die verwendeten Technologien berücksichtigt.
6. Anpassung der Scanner. Oft lässt sich eine Anwendung nicht scannen, ohne den Scanner anzupassen. Ein Beispiel ist ein Zahlungsgateway, bei dem jede Anfrage signiert werden muss. Ohne einen Connector zum Protokoll des Gateways werden Scanner blind Anfragen mit falscher Signatur senden. Zudem ist es notwendig, spezialisierte Scanner für bestimmte Arten von Schwachstellen zu entwickeln, wie z. B. Insecure Direct Object Reference
7. Risikomanagement. Der Einsatz verschiedener Scanner und die Integration mit externen Systemen wie Asset Management und Threat Management ermöglichen es, für die Risikobewertung eine Vielzahl von Parametern zu nutzen, sodass die Führungsebene eine angemessene Übersicht über den aktuellen Zustand der Sicherheit in der Entwicklung oder Infrastruktur erhält.

Bleiben Sie dran und lassen Sie uns das Schwachstellenscanning revolutionieren!

Quelle: habr.com