Veraltete und verwundbare Komponenten

Die meisten Schwachstellen in einer Anwendung müssen gefunden werden. Diese nicht: Sie stehen in einer öffentlichen Datenbank, mit Beschreibung, Schweregrad und häufig funktionierendem Angriffscode daneben. Ein Angreifer muss lediglich feststellen, welche Version Sie einsetzen. Im Folgenden lesen Sie, warum das so einfach ist und wie Sie die Pflege beherrschbar halten.

Was sind veraltete Komponenten?

Eine moderne Anwendung besteht zum weit überwiegenden Teil aus Code, den Sie nicht selbst geschrieben haben: das Framework, der Webserver, die Datenbank, die Programmiersprache, Dutzende bis Hunderte Bibliotheken sowie die Containerschichten, in denen das alles läuft. Veraltete und verwundbare Komponenten sind die Bestandteile davon, für die Sicherheitsaktualisierungen bestehen, die Sie nicht eingespielt haben.

Was diese Kategorie auszeichnet, ist ihre Öffentlichkeit. Wird in einer weit verbreiteten Komponente eine Schwachstelle gefunden, wird sie verantwortungsvoll gemeldet, erhält eine CVE-Nummer und wird nach Erscheinen der Aktualisierung öffentlich beschrieben. Diese Offenheit ist nötig, denn Administratoren müssen wissen, was sie einspielen müssen, doch sie wirkt in beide Richtungen. Von diesem Moment an weiß auch jeder Angreifer genau, was falsch ist und wie es sich ausnutzen lässt.

Vergleichen Sie es mit einem Rückruf für ein Schloss, von dem bekannt geworden ist, dass es sich mit einem bestimmten Handgriff öffnen lässt. Der Hersteller liefert ein Ersatzstück. Wer das nicht einbaut, hat nicht nur ein schwaches Schloss, sondern ein Schloss, dessen Schwäche in einer öffentlichen Anleitung beschrieben steht.

Wie nutzt ein Angreifer veraltete Komponenten aus?

Der Angriff beginnt mit Erkundung, und Ihre Anwendung hilft dabei häufig selbst mit.

Verwundbar:

HTTP/1.1 200 OK
Server: Apache/2.4.29 (Ubuntu)
X-Powered-By: PHP/7.2.24
X-Generator: Drupal 7.58

<script src="/js/jquery-1.8.3.min.js"></script>

Vier Zeilen ergeben eine vollständige Bestandsaufnahme. Ein Angreifer schlägt diese Versionen in einer öffentlichen Schwachstellendatenbank nach, findet, welche Probleme bekannt sind, und ob dafür Angriffscode verfügbar ist. Die dafür nötige Recherche besteht aus dem Lesen einer Seite.

Es geht dabei nicht nur um Server. Auch Ihre Abhängigkeiten tragen Risiken, oft ohne dass Sie sie bewusst gewählt hätten:

$ npm audit
found 34 vulnerabilities (12 moderate, 18 high, 4 critical)
  critical  Prototype Pollution in lodash <4.17.21
  high      Regular Expression Denial of Service in semver <7.5.2

Von diesen vierunddreißig Meldungen sind in der Praxis nur einige wenige wirklich relevant, da der Rest in Code steckt, den Ihre Anwendung nie aufruft. Genau diese Feinunterscheidung ist nötig, damit die Übersicht nicht ignoriert wird.

Sicher:

Die Lösung ist keine einmalige Aufräumaktion, sondern ein Verfahren, das weiterläuft:

# In der Entwicklungsstrecke: Der Build scheitert bei einem ernsten, erreichbaren Problem
- name: Prüfung auf verwundbare Abhängigkeiten
  run: npm audit --audit-level=high

- name: Bestandsaufnahme festhalten
  run: npm sbom --sbom-format cyclonedx > sbom.json

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Die Header geben nun keine Versionsangaben mehr preis. Das behebt die Schwachstelle nicht, denn die veraltete Komponente bleibt veraltet, zwingt einen Angreifer aber zum Suchen statt zum Lesen und macht automatisiertes Scannen nach verwundbaren Versionen deutlich weniger wirksam.

Welche Auswirkungen haben veraltete Komponenten?

Der Schweregrad reicht von mittel bis kritisch und bestimmt sich vollständig nach der betreffenden Schwachstelle. Genau das macht diese Kategorie schwierig: Es ist kein Fehler mit festem Gewicht, sondern eine Kategorie, in der alles stecken kann, vom kleinen Informationsleck bis zur Codeausführung aus der Ferne ohne Authentifizierung.

Die kritischen Fälle sind unter eigenen Namen bekannt geworden. Log4Shell in einer Protokollierungsbibliothek und die Schwachstelle in einem verbreiteten Redaktionssystem führten binnen Tagen zu massenhafter, automatisierter Ausnutzung. Wer zu diesem Zeitpunkt eine verwundbare Version einsetzte, wurde nicht gezielt ausgewählt, sondern schlicht von einem Scanner gefunden, der das gesamte Internet ablief.

Diese automatisierte Natur ist das Kennzeichnende. Bei den meisten Schwachstellen muss ein Angreifer Interesse gerade an Ihrer Organisation haben. Hier nicht: Es wird großflächig nach verwundbaren Versionen gescannt, und alles, was antwortet, wird angegriffen. Ihre Größe oder Sichtbarkeit spielt keine Rolle. Es zählt, wie viel Zeit zwischen dem Erscheinen der Aktualisierung und dem Zeitpunkt liegt, an dem Sie sie einspielen.

Wie spürt man veraltete Komponenten auf?

Von außen beginnt es mit dem Ablesen dessen, was die Anwendung selbst preisgibt: Versionsangaben in HTTP-Headern, in HTML-Kommentaren, in den Dateinamen von JavaScript-Bibliotheken, in den Standarddateien der eingesetzten Plattform und in Fehlermeldungen. Ein Tester vergleicht die gefundenen Versionen mit öffentlichen Datenbanken und beurteilt, ob die bekannten Schwachstellen in dieser Aufstellung tatsächlich erreichbar sind.

Auf der Innenseite geht es um die Bestandsaufnahme der Abhängigkeiten. Dazu gehört ausdrücklich, was Sie mittelbar hereinholen: Eine bewusst gewählte Bibliothek bringt häufig Dutzende mit, die niemand beurteilt hat. Es wird geprüft, ob eine aktuelle Übersicht besteht, ob ein Verfahren auf neue Meldungen reagiert und wie lange es in der Praxis dauert, bis eine Aktualisierung eingespielt ist. AssistSec beurteilt dabei nicht nur, welche Meldungen offen sind, sondern ob der verwundbare Pfad in Ihrer Anwendung tatsächlich erreicht werden kann, denn diese Unterscheidung entscheidet, ob etwas dringend ist oder sich planen lässt.

Wie verhindert man veraltete Komponenten?

• Führen Sie eine aktuelle Übersicht aller Komponenten und Versionen, einschließlich mittelbarer Abhängigkeiten.
• Prüfen Sie in Ihrer Entwicklungsstrecke automatisch auf bekannte Schwachstellen und lassen Sie den Build bei ernsten Fällen scheitern.
• Beurteilen Sie je Meldung, ob der verwundbare Pfad in Ihrer Anwendung erreichbar ist, und priorisieren Sie danach.
• Setzen Sie ausschließlich Versionen ein, die noch Sicherheitsaktualisierungen erhalten; planen Sie den Austausch vor dem Ende der Unterstützung.
• Aktualisieren Sie auch Frontend-Bibliotheken; diese laufen auf Ihrer Domain und mit Ihrer Sitzung.
• Entfernen Sie Komponenten und Funktionen, die Sie nicht nutzen, denn ungenutzter Code muss dennoch gepflegt werden.
• Verbergen Sie Versionsangaben in Headern und Fehlermeldungen als ergänzende Schicht.
• Halten Sie fest, wie schnell Sie nach dem Erscheinen einer Aktualisierung handeln, und messen Sie, ob Sie diese Vorgabe einhalten.
• Verfolgen Sie Meldungen zu den von Ihnen eingesetzten Komponenten aktiv, statt abzuwarten.