Über die Reachability-Analyse hinaus: Betrifft eine Schwachstelle Ihre Firmware tatsächlich?

Ein Treffer bei der Schwachstellenerkennung ist ein Grund für weitere Untersuchungen, sagt aber noch nichts darüber aus, ob Ihr Produkt tatsächlich betroffen ist.

Wenn Sie vernetzte Produkte entwickeln oder warten, wirft eine identifizierte Schwachstelle praktische Fragen auf. Muss das Sicherheitsteam eine Fehlerbehebung vorbereiten? Können Sie ausschließen, dass Ihr Produkt betroffen ist? Was sollten Sie einem Kunden mitteilen, der nach der Schwachstelle fragt?

Viele Schwachstellenmeldungen entstehen zunächst durch einen Abgleich zwischen einer bekannten Schwachstelle und einer Softwarekomponente oder deren Version. Ein solcher Treffer bedeutet jedoch nicht automatisch, dass Ihr Produkt betroffen ist. Sie benötigen Nachweise aus der Firmware, die Sie tatsächlich ausliefern: welcher Code darin enthalten ist, wie dieser verwendet wird und welche Bedingungen erfüllt sein müssen, damit die Schwachstelle ausgelöst werden kann.

Kurz zusammengefasst: Ein Treffer bei der Schwachstellenerkennung bedeutet nicht zwangsläufig, dass Ihr Produkt betroffen ist. Die Reachability-Analyse hilft dabei festzustellen, ob anfälliger Code ausgeführt werden kann. Allerdings können auch andere Bedingungen die Auswirkungen einer Schwachstelle beeinflussen. Das Automated Impact Assessment von ONEKEY untersucht relevante Nachweise aus der Firmware, um Schwachstellen auszuschließen, den Fokus auf Schwachstellen zu richten, die Aufmerksamkeit erfordern, und die Ergebnisse über VEX zu kommunizieren.

Was die Reachability-Analyse aussagt

Eine Schwachstelle betrifft häufig eine bestimmte Funktion oder einen bestimmten Codeabschnitt (anfälliger Code) innerhalb einer Softwarekomponente und nicht sämtliche Funktionen dieser Komponente. Dass eine Komponente in Ihrer Software Bill of Materials enthalten ist, bedeutet noch nicht, dass Ihre Anwendung den anfälligen Code ausführen kann.

Die Reachability-Analyse untersucht mögliche Ausführungspfade zu anfälligem Code.

Beispielsweise kann eine Anwendung eine Bibliothek aufrufen, die anschließend den anfälligen Code ausführt. Bei einer Untersuchung können diese Verbindungen analysiert werden, um festzustellen, ob die Ausführung diesen Code erreichen kann. Im Rahmen einer umfassenderen Sicherheitsbewertung stellt sich die Frage, wie von Angreifern kontrollierte Eingaben durch diese Komponenten gelangen und den anfälligen Code erreichen könnten.

Das sind nützliche Informationen. Die Feststellung, dass Code erreichbar ist, bedeutet jedoch nicht, dass alle für seine Ausnutzung erforderlichen Bedingungen erfüllt sind.

Warum Reachability allein nicht ausreicht

Stellen Sie sich eine Anwendung auf einem Gerät vor, die Code enthält, der mit einer Schwachstelle in Verbindung steht. Selbst wenn Eingaben diesen Code erreichen können, wird die Schwachstelle möglicherweise nur dann ausgelöst, wenn beispielsweise eine bestimmte Konfigurationseinstellung aktiviert ist. Ist diese Einstellung deaktiviert, bleibt der Code zwar erreichbar, aber eine notwendige Voraussetzung für die Ausnutzung fehlt.

Deshalb lässt sich allein anhand der Reachability nicht feststellen, ob eine Schwachstelle Ihr Produkt betrifft. Sie müssen auch die Bedingungen berücksichtigen, die für ihre Ausnutzung erforderlich sind.

Betrachten Sie diese Voraussetzungen als Glieder einer Kette. Damit eine Schwachstelle ausgenutzt werden kann, müssen alle notwendigen Bedingungen erfüllt sein. Wenn Sie nachweisen können, dass ein wesentliches Glied fehlt, verfügen Sie über einen Nachweis, mit dem sich die Schwachstelle für diese Firmware ausschließen lässt.

Hier kommt das Automated Impact Assessment von ONEKEY ins Spiel. Anstatt jeden möglichen Angriffspfad zu rekonstruieren, sucht es nach Nachweisen dafür, dass notwendige Bedingungen nicht erfüllt sind. So können Sie Schwachstellen identifizieren, die Ihre Firmware nicht betreffen.

‍

Prüfkriterien des Automated Impact Assessment

ONEKEY verwendet schwachstellenspezifische Bewertungsregeln, um Nachweise in Ihrer Firmware zu untersuchen. Diese Prüfungen decken sieben Bereiche ab, vom Vorhandensein des Codes bis hin zu bereits implementierten Sicherheitskorrekturen.

Dabei handelt es sich nicht um sieben verpflichtende Schritte für jede Schwachstelle. Die jeweils anwendbaren Regeln bewerten relevante Bedingungen. Dass einige Bedingungen erfüllt sind, bestätigt nicht, dass auch alle anderen Voraussetzungen vorliegen. Die Prüfkriterien sind wie folgt aufgebaut:

• Ist der anfällige Code vorhanden?
  ONEKEY prüft, ob der mit einer Schwachstelle verbundene Code tatsächlich in der Firmware vorhanden ist. Selbst wenn die betroffene Softwarekomponente existiert, kann der anfällige Code dieser Komponente während des Build-Prozesses entfernt worden sein.
• Ist der anfällige Code erreichbar?
  ONEKEY prüft, ob der anfällige Code von anderen Teilen der Software aufgerufen oder ausgeführt werden kann. Dies hilft festzustellen, ob die betroffene Funktionalität tatsächlich verwendet wird.
• Ist die erforderliche Konfiguration aktiviert? 
  Einige Schwachstellen können nur ausgelöst werden, wenn bestimmte Einstellungen aktiviert sind. ONEKEY untersucht Konfigurationsdateien und Starteinstellungen, um festzustellen, ob diese Bedingungen erfüllt sind.
• Ist eine erforderliche Abhängigkeit vorhanden?
  Die Ausnutzung einer Schwachstelle kann von einer weiteren Softwarekomponente abhängen. ONEKEY prüft, ob diese erforderliche Abhängigkeit in der Firmware vorhanden ist.
• Sind die Umgebungsanforderungen erfüllt? 
  Bestimmte Schwachstellen betreffen nur spezifische Hardwarearchitekturen oder aktivierte Gerätefunktionen. ONEKEY prüft, ob die Firmware diese Anforderungen erfüllt.
• Sind Sicherheitsmechanismen vorhanden?
  Sicherheitsmaßnahmen wie Compiler-Schutzmechanismen, Laufzeitschutz oder andere risikomindernde Kontrollen können eine Ausnutzung verhindern oder deren Möglichkeit verringern. ONEKEY prüft bei der Bewertung der Schwachstelle, ob relevante Schutzmechanismen vorhanden sind.
• Wurde bereits eine Sicherheitskorrektur implementiert?
  Eine Schwachstelle kann bereits durch einen rückportierten Patch (Backport) behoben worden sein, auch wenn die Softwareversion unverändert bleibt. ONEKEY prüft die Firmware auf Nachweise für solche Korrekturen.

Ein praktisches Beispiel: Von Firmware-Nachweisen zur Schwachstellenbewertung

Betrachten wir ein Gerät, auf dem dnsmasq läuft, eine Softwarekomponente, die Netzwerkdienste wie DNS und DHCP bereitstellt. Bestimmte Schwachstellen in dnsmasq können nur ausgenutzt werden, wenn IPv6 Router Advertisement aktiviert ist.

Dass dnsmasq in der Firmware vorhanden ist, bedeutet nicht automatisch, dass das Gerät betroffen ist. ONEKEY untersucht Konfigurationsdateien und Starteinstellungen, um festzustellen, ob die erforderliche Funktionalität aktiviert ist. Ist die Einstellung deaktiviert, liefert dies einen Nachweis, um die Schwachstelle auszuschließen. Ist sie aktiviert, können weitere Untersuchungen erforderlich sein, da andere Bedingungen die Ausnutzbarkeit beeinflussen können.

ONEKEY bewertet die Ergebnisse seiner Bewertungsregeln anhand eines Match Scores. Wenn ausreichende Nachweise eine negative Bewertung stützen, wird die Schwachstelle als Not affected (nicht betroffen) eingestuft. Kann sie nicht ausgeschlossen werden, bedeutet dies nicht automatisch, dass sie ausnutzbar ist.

Sie können die zugrunde liegenden Nachweise im Reiter Automated Impact Assessment einsehen, um die Begründung des Ergebnisses nachzuvollziehen und zu entscheiden, welche Schwachstellen weiter untersucht werden müssen.

Das folgende dnsmasq-Beispiel zeigt, wie der Score um 10 erhöht wird, weil die anfällige IPv6-Router-Advertisement-Funktion einkompiliert ist, und um 20 reduziert wird, weil dnsmasq nicht mit der erforderlichen IPv6-Konfiguration gestartet wird:

VEX zur Kommunikation des Ergebnisses nutzen

Ihre Bewertung muss auch für die Empfänger nachvollziehbar sein. Ein Kunde, der nach einer Schwachstelle fragt, benötigt mehr als die Aussage „Wir haben sie geprüft“. Er muss verstehen, welcher Status für sein Produkt ermittelt wurde und wie diese Schlussfolgerung begründet ist.

Vulnerability Exploitability eXchange (VEX) bietet eine strukturierte Möglichkeit, Schwachstellenbewertungen zu kommunizieren. Ein Status vermittelt das Ergebnis, eine Begründung erläutert gegebenenfalls die Ursache. Beispielsweise kann eine Bewertung als Not affected damit begründet werden, dass der anfällige Code nicht vorhanden ist. ONEKEY verknüpft seine Bewertungsergebnisse mit VEX-Begründungen.

ONEKEY unterstützt den Import und Export von VEX, sodass Sie Schwachstellenbewertungen empfangen und mit anderen Organisationen oder Systemen austauschen können.

Für Ihr Team verbindet dies zwei wichtige Aufgaben: zu entscheiden, welche Bedeutung eine Schwachstelle für Ihre Firmware hat, und diese Entscheidung über den Kreis der Personen hinaus zu kommunizieren, die die Bewertung durchgeführt haben. Die Bewertung liefert die Begründung, während VEX den Austausch des Ergebnisses und seiner Begründung ermöglicht.

Konzentrieren Sie Ihre Ressourcen auf Fälle, in denen noch eine Entscheidung erforderlich ist

Wenn Ihr Team mit einer langen Liste von Schwachstellen konfrontiert ist, ist es nicht immer der praktikabelste erste Schritt, für jeden Treffer einen vollständigen Angriffspfad zu untersuchen.

Sie müssen erkennen, welche Treffer Sie ausschließen können, verstehen, warum dies möglich ist, und entscheiden, wie Sie mit den übrigen umgehen. Bei einigen sind weitere Untersuchungen sinnvoll. Bei anderen kann die Implementierung einer Fehlerbehebung die praktikablere Lösung sein.

Das Automated Impact Assessment von ONEKEY unterstützt diese Arbeit, indem es neben der Erreichbarkeit auch das Vorhandensein von Code, die Konfiguration, Abhängigkeiten, Umgebungsanforderungen, Sicherheitsmechanismen und bereits implementierte Korrekturen untersucht.

Der Mehrwert liegt nicht einfach in einer kürzeren Liste. Entscheidend ist, zu wissen, warum ein Treffer nicht mehr denselben Untersuchungsaufwand erfordert – mit Nachweisen, die Sie überprüfen können, und einem Ergebnis, das Sie kommunizieren können.

Wichtigste Erkenntnisse

• Ein Treffer bei der Schwachstellenerkennung bestätigt nicht, dass ein Produkt betroffen ist. Die Identifizierung einer betroffenen Softwarekomponente ist lediglich der Ausgangspunkt für weitere Untersuchungen.

• Reachability allein reicht nicht aus. Selbst wenn anfälliger Code erreichbar ist, können andere Bedingungen wie Konfiguration, Abhängigkeiten, Sicherheitsmechanismen und bereits implementierte Korrekturen die Ausnutzbarkeit beeinflussen.

• Nachweise aus der Firmware helfen Ihnen, fundiertere Entscheidungen zu treffen. Das Automated Impact Assessment von ONEKEY hilft Ihnen, Schwachstellen auszuschließen, wenn ausreichende Nachweise vorliegen. Treffer, die nicht ausgeschlossen werden können, sind nicht automatisch ausnutzbar.

• Entscheidungen zu Schwachstellen benötigen nachvollziehbare Begründungen. ONEKEY stellt unterstützende Bewertungsnachweise bereit, während VEX dabei hilft, den Schwachstellenstatus und die entsprechenden Begründungen an Kunden und andere Beteiligte zu kommunizieren.