Scannen auf Schwachstellen und sichere Entwicklung. Teil 1

Im Rahmen der beruflichen Tätigkeit müssen Entwickler, Pentester und Sicherheitsfachleute mit Prozessen wie Vulnerability Management (VM), (Secure) SDLC umgehen.
Hinter diesen Begriffen verbergen sich verschiedene Praktiken und verwendete Werkzeuge, die miteinander verbunden sind, obwohl ihre Anwender unterschiedlich sind.

Der technische Fortschritt hat bisher nicht dazu geführt, dass ein Werkzeug den Menschen bei der Analyse der Sicherheit von Infrastruktur und Software ersetzen kann.
Es ist interessant zu verstehen, warum das so ist und mit welchen Problemen man konfrontiert ist.

Prozesse

Der Prozess des Vulnerability Management («Risikomanagement von Schwachstellen») dient der kontinuierlichen Überwachung der Sicherheit der Infrastruktur und dem Patch-Management.
Der Prozess des Secure SDLC («sicherer Entwicklungszyklus») dient dazu, die Sicherheit der Anwendung während der Entwicklung und des Betriebs zu gewährleisten.

Ein ähnlicher Teil dieser Prozesse ist der Prozess der Vulnerability Assessment – Schwachstellenbewertung und Schwachstellenscan.
Der Hauptunterschied beim Scannen im Rahmen von VM und SDLC besteht darin, dass im ersten Fall das Ziel darin besteht, bekannte Schwachstellen in Drittsoftware oder in der Konfiguration zu entdecken. Zum Beispiel eine veraltete Windows-Version oder eine Standard-Community-Zeile für SNMP.
Im zweiten Fall hingegen besteht das Ziel darin, Schwachstellen nicht nur in externen Komponenten (Abhängigkeiten), sondern in erster Linie im Code des neuen Produkts zu finden.

Dies führt zu Unterschieden in den Werkzeugen und Ansätzen. Meiner Meinung nach ist die Suche nach neuen Schwachstellen in der Anwendung deutlich interessanter, da sie nicht auf die Fingerabdruckbestimmung von Versionen, das Sammeln von Bannern, das Ausprobieren von Passwörtern usw. reduziert werden kann.
Für qualitativ hochwertige automatisierte Schwachstellenscans von Anwendungen sind Algorithmen erforderlich, die die Semantik der Anwendung, ihren Zweck und spezifische Bedrohungen berücksichtigen.

Ein Infrastruktur-Scanner kann oft durch einen Timer ersetzt werden, wie es avleonovausgedrückt hat. Es geht darum, dass Sie statistisch gesehen Ihre Infrastruktur als verwundbar betrachten können, wenn Sie sie, sagen wir, einen Monat lang nicht aktualisiert haben.

Werkzeuge

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

Black Box

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

Infrastruktur-Scanner (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose usw.) suchen nach offenen Netzwerkports, sammeln "Banner", bestimmen die Versionen der installierten Software und suchen in ihrer Wissensdatenbank nach Informationen über Schwachstellen in diesen Versionen. Sie versuchen auch, Konfigurationsfehler zu erkennen, wie z. B. Standardpasswörter oder offenen Zugriff auf Daten, schwache SSL-Verschlüsselungen usw.

Webanwendungs-Scanner (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP usw.) können ebenfalls bekannte Komponenten und deren Versionen bestimmen (zum Beispiel CMS, Frameworks, JS-Bibliotheken). Die Hauptschritte des Scanners sind Crawling und Fuzzing.
Während des Crawlings sammelt der Scanner Informationen über existierende Schnittstellen der Anwendung und HTTP-Parameter. Während des Fuzzings werden mutierte oder generierte Daten in alle entdeckten Parameter eingefügt, um einen Fehler auszulösen und eine Schwachstelle zu entdecken.

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

Weißer Kasten

Beim Whitebox-Scannen gibt es mehr Unterschiede.
Im Rahmen des VM-Prozesses erhalten Scanner (Vulners, Incsecurity Couch, Vuls, Tenable Nessus usw.) oft Zugang zu den Systemen, indem sie einen authentifizierten Scan durchführen. So kann der Scanner die installierten Paketversionen und Konfigurationsparameter direkt aus dem System herunterladen, ohne sie anhand von Bannern der Netzwerkdienste erraten zu müssen.
Der Scan wird genauer und vollständiger.

Wenn es um Whitebox-Scanning (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs usw.) von Anwendungen geht, handelt es sich normalerweise um die statische Analyse von Code und die Verwendung entsprechender Werkzeuge der Klasse SAST – Static Application Security Testing.

Probleme

Es gibt viele Probleme mit dem Scannen! Mit den meisten davon muss ich persönlich umgehen, wenn ich Dienstleistungen zur Etablierung von Scanning-Prozessen und sicherer Entwicklung anbiete, 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ärkt werden.

Probleme beim Scannen von Webanwendungen

1. Schwierigkeiten bei der Implementierung. Scanner müssen implementiert, konfiguriert und für jede Anwendung angepasst werden, Testumgebungen für Scans bereitgestellt und in den CI/CD-Prozess integriert werden, um effektiv zu sein. Andernfalls wird es ein nutzloses, formales Verfahren, das höchstens falsche Alarme erzeugt.
2. Dauer des Scans. Selbst 2019 hatten Scanner Probleme mit der Deduplication von Schnittstellen und können Tag und Nacht tausend Seiten mit zehn Parametern auf jeder scannen, wobei sie diese als unterschiedlich betrachten, obwohl derselbe Code für sie verantwortlich ist. Dabei muss die Entscheidung über das Deployment in der Produktionsumgebung im Rahmen des Entwicklungszyklus schnell getroffen werden.
3. Mangelnde Empfehlungen. Scanner geben ziemlich allgemeine Empfehlungen ab und der Entwickler kann nicht immer schnell erkennen, wie er das Risiko senken kann, und vor allem, ob es notwendig ist, dies sofort zu tun oder ob es noch nicht dringlich ist.
4. Destruktive Auswirkungen auf die Anwendung. Scanner können durchaus einen DoS-Angriff auf die Anwendung durchführen und können eine große Anzahl von Entitäten erzeugen oder bestehende ändern (zum Beispiel Zehntausende von Kommentaren in einem Blog erstellen), weshalb man sie nicht gedankenlos in der Produktion ausführen sollte.
5. Niedrige Qualität der Schwachstellenerkennung. Scanner verwenden in der Regel ein festes Array an Payloads und können leicht eine Schwachstelle übersehen, die nicht in ihr bekanntes Verhaltensmuster passt.
6. Missverständnis der Funktionen der Anwendung durch den Scanner. Scanner wissen von sich aus nicht, was "Internet-Banking", "Zahlung", "Kommentar" ist. Für sie existieren nur Links und Parameter, sodass ein großer Teil möglicher Schwachstellen in der Geschäftslogik völlig unentdeckt bleibt. Sie würden nicht auf die Idee kommen, eine doppelte Abbuchung vorzunehmen, auf fremde Daten per ID zuzugreifen oder das Guthaben durch Rundungsfehler zu manipulieren.
7. Missverständnis der Semantik der Seiten durch den Scanner. Scanner können keine FAQs lesen, können Captchas nicht erkennen, und sie würden nicht auf die Idee kommen, wie man sich registriert und dass man sich dann neu einloggen muss, nicht auf "Logout" klicken sollte und wie man Anfragen bei Veränderung von Parameterwerten signiert. Infolgedessen kann ein großer Teil der Anwendung völlig ungescannt bleiben.

Probleme beim Scannen des Quellcodes.

1. Falsche Alarme. Statische Analyse ist eine komplexe Aufgabe, bei der oft viele Kompromisse eingegangen werden müssen. Häufig muss auf Genauigkeit verzichtet werden, und selbst teure Unternehmensscanner liefern eine riesige Anzahl von Fehlalarmierungen.
2. Schwierigkeiten bei der Implementierung. Um die Genauigkeit und Vollständigkeit der statischen Analyse zu erhöhen, müssen die Scan-Regeln überarbeitet werden, und das Schreiben dieser Regeln kann sich als zu zeitaufwendig erweisen. Manchmal ist es einfacher, alle Stellen im Code mit einem bestimmten Fehler zu finden und sie zu beheben, als eine Regel zu schreiben, um solche Fälle zu erkennen.
3. Fehlende Unterstützung für Abhängigkeiten. Große Projekte sind von einer Vielzahl von Bibliotheken und Frameworks abhängig, die die Möglichkeiten der Programmiersprache erweitern. Wenn im Wissensbestand des Scanners keine Informationen über gefährliche Stellen („Sinks“) in diesen Frameworks enthalten sind, wird dies zu einem blinden Fleck und der Scanner versteht den Code einfach nicht.
4. Dauer des Scans. Die Suche nach Vulnerabilitäten im Code ist eine komplexe Aufgabe, auch in Bezug auf Algorithmen. Daher kann der Prozess durchaus zeitaufwendig sein und erhebliche Rechenressourcen erfordern.
5. Geringe Abdeckung. Trotz des Ressourcenverbrauchs und der Dauer des Scans müssen Entwickler von SAST-Tools dennoch Kompromisse eingehen und nicht alle Zustände analysieren, in denen sich das Programm befinden kann.
6. Reproduzierbarkeit der Auffindungen. Ein Hinweis auf eine bestimmte Zeile und den Stack-Trace, der zu einer Vulnerabilität führt, ist großartig, aber in der Realität gibt der Scanner oft nicht genügend Informationen, um die Existenz der Vulnerabilität von außen zu überprüfen. Schließlich kann das Problem auch in totem Code liegen, der für einen Angreifer unerreichbar ist.

Probleme beim Scannen der Infrastruktur.

1. Unzureichende Inventarisierung. In großen Infrastrukturen, insbesondere geographisch verteilten, ist es oft am schwierigsten zu verstehen, welche Hosts gescannt werden müssen. Mit anderen Worten, die Scan-Aufgabe steht in enger Verbindung mit dem Asset Management.
2. Schlechte Priorisierung. Netzwerkscanner liefern häufig viele Ergebnisse mit Schwächen, die in der Praxis nicht ausnutzbar sind, aber formal als hochriskant gelten. Der Verbraucher erhält einen Bericht, der schwer zu interpretieren ist, und es ist unklar, was vorrangig behoben werden muss.
3. Mangelnde Empfehlungen. In der Wissensdatenbank des Scanners gibt es oft nur sehr allgemeine Informationen zu Schwachstellen und deren Behebung, sodass Administratoren sich mit Google bewaffnen müssen. Die Situation ist etwas besser bei Whitebox-Scannern, die konkrete Befehle zur Behebung ausgeben können.
4. Manuelle Arbeit. In Infrastrukturen kann es viele Knoten geben, also potenziell viele Schwachstellen, deren Berichte bei jeder Iteration manuell ausgewertet und analysiert werden müssen.
5. Schlechte Abdeckung. Die Qualität der Scannung der Infrastruktur hängt direkt vom Umfang der Wissensdatenbank zu Schwachstellen und Softwareversionen ab. Dabei, stellt sich heraus, dass selbst Marktführer nicht über eine umfassende Wissensdatenbank verfügen, und dass in Datenbanken kostenloser Lösungen viele Informationen vorhanden sind, die bei den Marktführern fehlen.
6. Probleme mit Patch-Management. Häufig besteht das Patch-Management von Schwachstellen in der Infrastruktur aus der Aktualisierung eines Pakets oder der Änderung einer Konfigurationsdatei. Ein großes Problem hier ist, dass das System, insbesondere Legacy-Systeme, sich infolge eines Updates unvorhersehbar verhalten kann. Im Grunde müssen Integrationsprüfungen in der Live-Infrastruktur im Produktivbetrieb durchgeführt werden.

Ansätze

Was soll man also tun?
Mehr über Beispiele und wie man vielen der genannten Probleme begegnen kann, werde ich in den nächsten Teilen erzählen, während ich jetzt die Hauptbereiche aufführe, in denen man tätig werden kann:

1. Aggregation verschiedener Scanning-Tools. Bei richtiger Nutzung mehrerer Scanner kann eine erhebliche Erhöhung der Wissensdatenbank und der Qualität der Erkennung erzielt werden. Man kann sogar mehr Schwachstellen finden, als alle Scanner zusammen, die einzeln betrieben werden, während man das Risiko genauer bewerten und mehr Empfehlungen geben kann.
2. Integration von SAST und DAST. Man kann die Abdeckung von DAST und die Genauigkeit von SAST durch den Austausch von Informationen zwischen ihnen erhöhen. Aus den Quellcodes können Informationen über vorhandene Routen gewonnen werden, und mit DAST kann überprüft werden, ob die Schwachstelle von außen sichtbar ist.
3. Machine Learning™. Im Jahr 2015 habe ich erzählt (und noch) über die Anwendung von Statistiken, um Scannern die Intuition eines Hackers zu geben und sie zu beschleunigen. Das ist definitiv ein Nährboden für die Weiterentwicklung der automatischen Sicherheitsanalyse in der Zukunft.
4. Integration von IAST mit automatisierten Tests und OpenAPI. Im Rahmen einer CI/CD-Pipeline ist es möglich, einen Scan-Prozess auf der Grundlage von Tools zu erstellen, die als HTTP-Proxy fungieren, und von funktionalen Tests, die über HTTP ausgeführt werden. Tests und Verträge von OpenAPI/Swagger geben dem Scanner die fehlenden Informationen über Datenströme und ermöglichen es ihm, die Anwendung in verschiedenen Zuständen zu scannen.
5. Richtige Konfiguration. Für jede Anwendung und Infrastruktur muss ein geeigneter Scan-Profil erstellt werden, das die Anzahl und Art der Schnittstellen sowie die verwendeten Technologien berücksichtigt.
6. Anpassung der Scanner. Oft kann eine Anwendung nicht gescannt werden, ohne den Scanner anzupassen. Ein Beispiel ist ein Zahlungsgateway, bei dem jede Anfrage signiert werden muss. Ohne das Schreiben eines Connectors zum Protokoll des Gateways werden Scanner gedankenlos Anfragen mit falscher Signatur senden. Es ist auch notwendig, spezialisierte Scanner für bestimmte Arten von Schwachstellen zu schreiben, wie zum Beispiel Insecure Direct Object Reference
7. Risikomanagement. Die Nutzung verschiedener Scanner und die Integration mit externen Systemen wie Asset Management und Threat Management ermöglicht es, viele Parameter zur Bewertung des Risikoniveaus zu nutzen, sodass das Management ein angemessenes Bild über den aktuellen Stand der Sicherheit von Entwicklung oder Infrastruktur erhält.

Bleiben Sie dran und lassen Sie uns das Schwachstellenscanning revolutionieren!

Quelle: habr.com