Schwachstellen-Scan und sichere Entwicklung. Teil 1

Entwickler, Pentester und Sicherheitsexperten müssen sich im Rahmen ihrer beruflichen Tätigkeit mit Prozessen wie Vulnerability Management (VM), (Secure) SDLC auseinandersetzen.
Unter diesen Sätzen sind verschiedene Arten von Praktiken und Werkzeugen verborgen, die miteinander verflochten sind, obwohl ihre Verbraucher unterschiedlich sind.

Der technische Fortschritt hat noch nicht den Punkt erreicht, eine Person durch ein Tool zur Analyse der Sicherheit von Infrastruktur und Software zu ersetzen.
Es ist interessant zu verstehen, warum dies so ist und mit welchen Problemen Sie konfrontiert sind.

Die Prozesse

Der Vulnerability Management-Prozess dient zur kontinuierlichen Überwachung der Infrastruktursicherheit und des Patch-Managements.
Der Secure SDLC-Prozess („sicherer Entwicklungszyklus“) soll die Anwendungssicherheit während der Entwicklung und des Betriebs unterstützen.

Ein ähnlicher Teil dieser Prozesse ist der Vulnerability Assessment-Prozess - Vulnerability Assessment, Schwachstellen-Scan.
Der Hauptunterschied beim Scannen innerhalb von VM und SDLC besteht darin, dass im ersten Fall das Ziel darin besteht, bekannte Schwachstellen in Software von Drittanbietern oder in einer Konfiguration zu erkennen. Zum Beispiel eine veraltete Version von Windows oder die Standard-Community-Zeichenfolge für SNMP.
Im zweiten Fall besteht das Ziel darin, Schwachstellen nicht nur in Komponenten (Abhängigkeiten) von Drittanbietern, sondern vor allem im Code des neuen Produkts zu erkennen.

Dies führt zu Unterschieden bei Werkzeugen und Ansätzen. Meiner Meinung nach ist die Aufgabe, neue Schwachstellen in der Anwendung zu finden, viel interessanter, da es nicht um Fingerabdruckversionen, das Sammeln von Bannern, das Sortieren von Passwörtern usw. geht.
Für ein qualitativ hochwertiges automatisiertes Scannen von Anwendungsschwachstellen sind Algorithmen erforderlich, die die Semantik der Anwendung, ihren Zweck und bestimmte Bedrohungen berücksichtigen.

Der Infrastrukturscanner kann oft durch einen Timer ersetzt werden, wie avleonov es ausdrückte. Der Punkt ist, dass Sie Ihre Infrastruktur rein statistisch als anfällig betrachten können, wenn Sie sie beispielsweise einen Monat lang nicht aktualisiert haben.

Die Werkzeuge

Das Scannen sowie die Sicherheitsanalyse können als Black Box oder White Box durchgeführt werden.

Black Box

Beim Scannen von Blackboxen sollte das Tool in der Lage sein, mit dem Dienst über dieselben Schnittstellen zu arbeiten, über die Benutzer damit arbeiten.

Infrastrukturscanner (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose usw.) suchen nach offenen Netzwerkports, sammeln „Banner“, ermitteln installierte Softwareversionen und suchen in ihrer Wissensdatenbank nach Informationen zu Schwachstellen in diesen Versionen. Sie versuchen auch, Konfigurationsfehler wie Standardkennwörter oder offenen Zugriff auf Daten, schwache SSL-Chiffren usw. zu erkennen.

Webanwendungsscanner (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP usw.) wissen auch, wie bekannte Komponenten und ihre Versionen (z. B. CMS, Frameworks, JS-Bibliotheken) ermittelt werden. Die Hauptschritte des Scanners sind Kriechen und Fuzzing.
Während des Crawls sammelt der Scanner Informationen zu vorhandenen Anwendungsschnittstellen und HTTP-Parametern. Während des Fuzzing werden alle erkannten Parameter durch mutierte oder generierte Daten ersetzt, um einen Fehler zu provozieren und eine Sicherheitsanfälligkeit zu erkennen.

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

Weiße Box

Whitebox-Scans weisen mehr Unterschiede auf.
Während des gesamten Prozesses erhalten VM-Scanner (Vulners, Incsecurity Couch, Vuls, Tenable Nessus usw.) häufig durch einen authentifizierten Scan Zugriff auf Systeme. Auf diese Weise kann der Scanner installierte Versionen von Paketen und Konfigurationsparametern direkt vom System herunterladen, ohne sie auf den Bannern von Netzwerkdiensten zu erraten.
Der Scan ist genauer und vollständiger.

Wenn wir über das Whitebox-Scannen (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs usw.) von Anwendungen sprechen, sprechen wir normalerweise über statische Code-Analyse und die Verwendung der entsprechenden Tools der SAST-Klasse - Static Application Security Testing.

Die Probleme

Es gibt viele Probleme beim Scannen! Ich muss mich mit den meisten von ihnen persönlich im Rahmen der Bereitstellung eines Dienstes zum Erstellen von Scanprozessen und zur sicheren Entwicklung sowie bei der Durchführung von Sicherheitsanalysen befassen.

Ich werde drei Hauptgruppen von Problemen herausgreifen, die durch Gespräche mit Ingenieuren und Managern von Informationssicherheitsdiensten in verschiedenen Unternehmen bestätigt werden.

Probleme beim Scannen von Webanwendungen

1. Die Komplexität der Implementierung. Scanner müssen bereitgestellt, konfiguriert, für jede Anwendung angepasst, eine Testumgebung für Scans zugewiesen und im CI / CD-Prozess implementiert werden, um effektiv zu sein. Andernfalls handelt es sich um ein nutzloses formales Verfahren, bei dem nur falsch positive Ergebnisse ausgegeben werden
2. Scandauer. Selbst im Jahr 2019 arbeiten Scanner schlecht mit der Deduplizierung von Schnittstellen zusammen und können tagelang Tausende von Seiten mit 10 Parametern pro Tag scannen, wobei sie als unterschiedlich angesehen werden, obwohl derselbe Code für sie verantwortlich ist. Gleichzeitig muss die Entscheidung für die Bereitstellung innerhalb des Entwicklungszyklus schnell getroffen werden
3. Spärliche Empfehlungen. Scanner geben ziemlich allgemeine Empfehlungen ab, und es ist einem Entwickler nicht immer möglich, schnell zu verstehen, wie das Risiko reduziert werden kann, und vor allem, ob dies jetzt erforderlich ist oder nicht
4. Zerstörerische Wirkung auf die Anwendung. Scanner führen möglicherweise einen DoS-Angriff auf die Anwendung aus und können auch eine große Anzahl von Entitäten erstellen oder vorhandene Entitäten ändern (z. B. Zehntausende von Kommentaren in einem Blog erstellen). Starten Sie daher nicht sinnlos einen Scan im Produkt
5. Schwachstellenerkennung von geringer Qualität. Scanner verwenden normalerweise ein Array mit festen Nutzdaten und können leicht eine Sicherheitsanfälligkeit übersehen, die nicht in das bekannte Verhaltensszenario der Anwendung passt.
6. Der Scanner versteht die Funktionen der Anwendung nicht. Die Scanner selbst wissen nicht, was "Internet-Banking", "Zahlung" und "Kommentar" sind. Für sie gibt es nur Links und Parameter, so dass eine große Anzahl möglicher Schwachstellen in der Geschäftslogik vollständig aufgedeckt bleibt. Sie werden nicht raten, doppelt zu schreiben, die Daten anderer Personen anhand ihrer ID zu überprüfen oder das Gleichgewicht durch Rundung aufzulösen
7. Scanner-Missverständnis der Seitensemantik. Scanner wissen nicht, wie sie die FAQ lesen sollen, sie wissen nicht, wie sie Captchas erkennen sollen. Sie selbst wissen nicht, wie sie sich registrieren sollen, und müssen sich dann anmelden, damit Sie nicht auf "Abmelden" klicken können und wie sie Anforderungen beim Ändern von Parameterwerten signieren. Infolgedessen wird der größte Teil der Anwendung möglicherweise überhaupt nicht gescannt.

Probleme beim Scannen des Quellcodes

1. False Positives. Die statische Analyse ist eine schwierige Aufgabe, bei deren Lösung viele Kompromisse eingegangen werden müssen. Oft muss man auf Genauigkeit verzichten, und selbst teure Unternehmensscanner erzeugen eine große Menge an Fehlalarmen
2. Die Komplexität der Implementierung. Um die Genauigkeit und Vollständigkeit der statischen Analyse zu erhöhen, müssen die Scanregeln verfeinert werden, und das Schreiben dieser Regeln kann zu zeitaufwändig sein. Manchmal ist es einfacher, alle Stellen im Code mit einem Fehler zu finden und zu beheben, als eine Regel zu schreiben, um solche Fälle zu erkennen
3. Fehlende Abhängigkeitsunterstützung. Große Projekte hängen von einer großen Anzahl von Bibliotheken und Frameworks ab, die die Funktionen der Programmiersprache erweitern. Wenn die Wissensdatenbank des Scanners keine Informationen zu "Senken" in diesen Frameworks enthält, wird dies zu einem blinden Fleck und der Scanner versteht den Code einfach nicht einmal
4. Scandauer. Das Auffinden von Schwachstellen im Code ist im Hinblick auf Algorithmen eine schwierige Aufgabe. Daher kann der Prozess durchaus verzögert sein und erhebliche Rechenressourcen erfordern.
5. Geringe Abdeckung. Trotz des Ressourcenverbrauchs und der Dauer des Scans müssen Entwickler von SAST-Tools immer noch auf Kompromisse zurückgreifen und nicht alle Bedingungen analysieren, unter denen sich das Programm möglicherweise befindet
6. Reproduzierbarkeit von Funden. Es ist in Ordnung, auf eine bestimmte Leitung und einen bestimmten Anrufstapel zu zeigen, die zu einer Sicherheitsanfälligkeit führen. In Wirklichkeit liefert der Scanner jedoch häufig nicht genügend Informationen, um nach einer externen Sicherheitsanfälligkeit zu suchen. Schließlich kann ein Fehler auch im toten Code liegen, der für einen Angreifer unerreichbar ist

Probleme beim Scannen der Infrastruktur

1. Unzureichendes Inventar. In großen Infrastrukturen, insbesondere geografisch getrennt, ist es oft am schwierigsten zu verstehen, welche Hosts gescannt werden müssen. Mit anderen Worten, die Scanaufgabe ist eng mit der Asset-Verwaltungsaufgabe verbunden.
2. Schlechte Priorisierung. Netzwerkscanner liefern häufig viele Ergebnisse mit Nachteilen, die in der Praxis nicht ausgenutzt werden können, aber formal gesehen ist ihr Risiko hoch. Der Verbraucher erhält einen Bericht, der schwer zu interpretieren ist, und es ist nicht klar, was zuerst behoben werden muss
3. Spärliche Empfehlungen. Die Wissensdatenbank des Scanners enthält häufig nur sehr allgemeine Informationen zu der Sicherheitsanfälligkeit und deren Behebung. Daher müssen sich Administratoren mit Google ausrüsten. Bei Whitebox-Scannern, die einen bestimmten Befehl zur Behebung ausgeben können, ist die Situation etwas besser
4. Handarbeit. Infrastrukturen können viele Knoten haben, was bedeutet, dass möglicherweise viele Mängel vorliegen, über die bei jeder Iteration manuell zerlegt und analysiert werden muss
5. Schlechte Abdeckung. Die Qualität des Scannens der Infrastruktur hängt direkt vom Umfang der Wissensdatenbank über Schwachstellen und Softwareversionen ab. Gleichzeitig stellt sich heraus, dass selbst Marktführer keine umfassende Wissensbasis haben und die Datenbanken mit kostenlosen Lösungen viele Informationen enthalten, über die Marktführer nicht verfügen
6. Probleme beim Patchen. Der häufigste Patch für Schwachstellen in der Infrastruktur ist das Aktualisieren des Pakets oder das Ändern der Konfigurationsdatei. Das große Problem hierbei ist, dass sich das System, insbesondere das Legacy-System, aufgrund eines Upgrades unvorhersehbar verhalten kann. Im Wesentlichen müssen Sie Integrationstests für die lebende Infrastruktur in der Produktion durchführen

Die Ansätze

Wie soll ich sein?
In den folgenden Abschnitten werde ich Ihnen mehr über Beispiele und den Umgang mit vielen dieser Probleme erzählen. Im Moment werde ich jedoch die Hauptbereiche angeben, in denen Sie arbeiten können:

1. Aggregation verschiedener Scan-Tools. Mit der korrekten Verwendung mehrerer Scanner kann eine signifikante Steigerung der Wissensbasis und der Qualität der Erkennung erreicht werden. Sie können noch mehr Schwachstellen finden als insgesamt alle separat gestarteten Scanner, während es möglich ist, das Risiko genauer einzuschätzen und mehr Empfehlungen abzugeben
2. Integration von SAST und DAST. Sie können die DAST-Abdeckung und die SAST-Genauigkeit erhöhen, indem Sie Informationen zwischen ihnen austauschen. Über die Quelle können Sie Informationen zu vorhandenen Routen abrufen und mit DAST überprüfen, ob die Sicherheitsanfälligkeit von außen sichtbar ist
3. Maschinelles Lernen ^™ . 2015 habe ich über (und noch ) die Verwendung von Statistiken gesprochen, um Hackern die Intuition von Scannern zu vermitteln und sie zu beschleunigen. Dies ist definitiv ein Grundstein für die Entwicklung zukünftiger automatisierter Sicherheitsanalysen.
4. Integration von IAST in Autotests und OpenAPI. Im Rahmen der CI / CD-Pipeline ist es möglich, einen Scan-Prozess zu erstellen, der auf Tools basiert, die als HTTP-Proxys arbeiten, und Funktionstests, die auf HTTP arbeiten. OpenAPI / Swagger-Tests und -Verträge geben dem Scanner die fehlenden Informationen zu Datenströmen und ermöglichen das Scannen der Anwendung in verschiedenen Zuständen
5. Richtige Konfiguration. Für jede Anwendung und Infrastruktur müssen Sie ein geeignetes Scanprofil erstellen, das die Anzahl und Art der verwendeten Schnittstellen und Technologien berücksichtigt
6. Anpassung von Scannern. Oft kann eine Anwendung nicht gescannt werden, ohne den Scanner fertigzustellen. Ein Beispiel ist ein Zahlungsgateway, in dem jede Anforderung signiert werden muss. Ohne einen Connector in das Gateway-Protokoll zu schreiben, schlagen die Scanner die Anforderungen gedankenlos mit der falschen Signatur. Es ist auch erforderlich, spezielle Scanner für einen bestimmten Fehlertyp zu schreiben, z. B. die Insecure Direct Object Reference
7. Risikomanagement. Durch die Verwendung verschiedener Scanner und die Integration in externe Systeme wie Asset Management und Threat Management können Sie viele Parameter verwenden, um das Risikoniveau zu bewerten, sodass das Management ein angemessenes Bild des aktuellen Sicherheitsstatus der Entwicklung oder Infrastruktur erhalten kann

Bleiben Sie dran und lassen Sie uns das Scannen von Sicherheitslücken unterbrechen!