Schlagwortarchiv für: CVSS

Trotz des Ausfalls der „National Vulnerability Database” (NVD) des amerikanischen „National Institute of Standards and Technology“ (NIST) ist die Greenbone-Engine zur Erkennung von Schwachstellen weiterhin voll funktionsfähig. Sie bietet zuverlässige Schwachstellen-Scans, ohne auf fehlende CVE-Anreicherungsdaten angewiesen zu sein.

Seit 1999 stellt die MITRE Corporation mit Common Vulnerabilities and Exposures (CVE) kostenlose öffentliche Informationen über Schwachstellen zur Verfügung, indem sie Informationen über Software-Schwachstellen veröffentlicht und verwaltet. Das NIST hat diese CVE-Berichte seit 2005 fleißig erweitert und mit Kontext angereichert, um die Bewertung von Cyberrisiken zu verbessern. Anfang 2024 wurde die Cybersecurity-Gemeinschaft überrascht, als die NIST-NVD zum Stillstand kam. Etwa ein Jahr später war der Ausfall noch immer nicht vollständig behoben [1][2]. Bei einer jährlich steigenden Zahl von CVE-Einreichungen haben die Schwierigkeiten des NIST dazu geführt, dass ein großer Prozentsatz ohne Kontext blieb, wie z. B. bei der Bewertung des Schweregrads (CVSS), den Listen betroffener Produkte (CPE) und den Einstufungen von Schwachstellen (CWE).

Die jüngsten von der Trump-Administration angestoßenen politischen Veränderungen haben die Unsicherheit über die Zukunft des Austauschs von Schwachstelleninformationen und der vielen Sicherheitsanbieter, die davon abhängig sind, vergrößert. Der Haushaltsplan für das Geschäftsjahr der CISA enthält bemerkenswerte Kürzungen in bestimmten Bereichen, wie z. B. 49,8 Millionen Dollar weniger für Beschaffung, Bau und Verbesserungen sowie 4,7 Millionen Dollar weniger für Forschung und Entwicklung. Als Reaktion auf die Finanzierungsprobleme hat die CISA Maßnahmen zur Kürzung der Ausgaben ergriffen, darunter Anpassungen bei Verträgen und Beschaffungsstrategien.

Um es klar zu sagen: Das CVE-Programm ist noch nicht ausgefallen. Am 16. April erließ die CISA in letzter Minute eine Anweisung, ihren Vertrag mit MITRE zu verlängern, um den Betrieb des CVE-Programms für weitere elf Monate sicherzustellen, nur wenige Stunden bevor der Vertrag auslaufen sollte. Niemand kann jedoch vorhersagen, wie sich die zukünftigen Ereignisse entwickeln werden. Die potenziellen Auswirkungen auf den Austausch von Informationen sind alarmierend und deuten vielleicht auf eine neue Dimension von „kaltem Cyberkrieg“ hin.

Dieser Artikel enthält einen kurzen Überblick über die Funktionsweise des CVE-Programms und darüber, wie die Erkennungsfunktionen von Greenbone auch während des NIST NVD-Ausfalls aufrechterhalten werden.

Ein Überblick über den Betrieb des CVE-Programms

Die MITRE Corporation ist eine gemeinnützige Organisation, die die Aufgabe hat, die innere Sicherheit der USA an mehreren Fronten zu unterstützen, einschließlich der Verteidigungsforschung zum Schutz kritischer Infrastrukturen und der Cybersicherheit. MITRE betreibt das CVE-Programm, fungiert als primäre CNA (CVE Numbering Authority) und unterhält die zentrale Infrastruktur für die CVE-ID-Zuweisung, die Veröffentlichung von Datensätzen, die Kommunikationsabläufe zwischen allen CNAs und ADPs (Authorized Data Publishers) sowie die Programmverwaltung. MITRE stellt der Öffentlichkeit CVE-Daten über die Website CVE.org und das GitHub-Repository cvelistV5 zur Verfügung, das alle CVE-Datensätze im strukturierten JSON-Format enthält. Das Ergebnis ist eine hocheffiziente, standardisierte Berichterstattung zu Schwachstellen und ein nahtloser Datenaustausch im gesamten Cybersicherheitsökosystem.

Nachdem eine Schwachstellen-Beschreibung von einem CNA an MITRE übermittelt wurde, hat das NIST in der Vergangenheit immer etwas hinzugefügt:

  • CVSS (Common Vulnerability Scoring System): Ein Schweregrad und ein detaillierter Vektorstring, der den Risikokontext für Angriffskomplexität (AC), die Auswirkungen auf Vertraulichkeit (C), Integrität (I) und Verfügbarkeit (A) sowie andere Faktoren enthält.
  • CPE (Common Platform Enumeration): Eine speziell formatierte Zeichenfolge, die zur Identifizierung betroffener Produkte dient, indem sie den Produktnamen, den Hersteller, die Versionen und andere architektonische Spezifikationen weitergibt.
  • CWE (Common Weakness Enumeration): Eine Ursachenklassifizierung nach der Art des betreffenden Softwarefehlers.

CVSS ermöglicht es Unternehmen, den Grad des Risikos einer bestimmten Schwachstelle leichter zu bestimmen und dementsprechend strategische Abhilfemaßnahmen zu ergreifen. Da die ersten CVE-Berichte nur eine nicht standardisierte Deklaration des betroffenen Produkts erfordern, ermöglicht es die Ergänzung von CPE durch NIST den Plattformen für das Schwachstellenmanagement, den CPE-Abgleich als schnelle, wenn auch etwas unzuverlässige Methode durchzuführen, um festzustellen, ob eine CVE in der Infrastruktur eines Unternehmens existiert oder nicht.

Einen detaillierteren Einblick in die Funktionsweise des Verfahrens zur Offenlegung von Schwachstellen und wie CSAF 2.0 eine dezentralisierte Alternative zum CVE-Programm von MITRE bietet, finden Sie in unserem Artikel: Wie CSAF 2.0 automatisiertes Schwachstellenmanagement vorantreibt. Als Nächstes wollen wir uns den NIST NVD-Ausfall genauer ansehen und verstehen, was Greenbones Erkennung gegen diesen Ausfall widerstandsfähig macht.

Der NIST-NVD-Ausfall: Was ist passiert?

Seit dem 12. Februar 2024 hat die NVD die Anreicherung von CVEs mit wichtigen Metadaten wie CVSS-, CPE- und CWE-Produktkennungen drastisch reduziert. Das Problem wurde zuerst vom VP of Security von Anchore erkannt. Im Mai 2024 waren etwa 93 % der nach dem 12. Februar hinzugefügten CVEs nicht angereichert. Im September 2024 hatte das NIST seine selbst gesetzte Frist nicht eingehalten; 72,4 % der CVEs und 46,7 % der neu hinzugefügten KEVs (Known Exploited Vulnerabilities) der CISA waren immer noch nicht angereichert [3].

Die Verlangsamung des NVD-Anreicherungsprozesses hatte erhebliche Auswirkungen auf die Cybersecurity-Gemeinschaft, nicht nur, weil angereicherte Daten für Verteidiger entscheidend sind, um Bedrohungen effektiv zu priorisieren, sondern auch, weil einige Schwachstellen-Scanner auf diese angereicherten Daten angewiesen sind, um ihre Erkennungstechniken einzusetzen.

Als Verteidiger der Cybersicherheit lohnt es sich zu fragen: War Greenbone vom Ausfall des NIST NVD betroffen? Die kurze Antwort lautet: Nein. Lesen Sie weiter, um herauszufinden, warum die Erkennungsfähigkeiten von Greenbone gegen den NIST NVD-Ausfall resistent sind.

Greenbone-Erkennungsrate trotz NVD-Ausfall hoch

Ohne angereicherte CVE-Daten werden einige Lösungen für das Schwachstellenmanagement unwirksam, da sie auf den CPE-Abgleich angewiesen sind, um festzustellen, ob eine Schwachstelle in der Infrastruktur eines Unternehmens vorhanden ist.  Greenbone ist jedoch gegen den Ausfall der NIST NVD gewappnet, da unsere Produkte nicht vom CPE-Abgleich abhängen. Die OPENVAS-Schwachstellentests von Greenbone können auf der Grundlage von nicht angereicherten CVE-Beschreibungen erstellt werden. Greenbone erkennt sogar bekannte Schwachstellen und Fehlkonfigurationen, für die es nicht einmal CVEs gibt, wie z. B. CIS-Compliance Benchmarks [4][5].

Für die Erstellung von Schwachstellentests (VT) beschäftigt Greenbone ein engagiertes Team von Software-Ingenieuren, die die zugrunde liegenden technischen Aspekte von Schwachstellen identifizieren. Greenbone verfügt über eine CVE-Scanner-Funktion, die einen herkömmlichen CPE-Abgleich ermöglicht. Im Gegensatz zu Lösungen, die sich ausschließlich auf die CPE-Daten der NIST NVD stützen, um Schwachstellen zu identifizieren, setzt Greenbone jedoch Erkennungstechniken ein, die weit über den grundlegenden CPE-Abgleich hinausgehen. Daher bleiben die Fähigkeiten von Greenbone zur Erkennung von Schwachstellen auch angesichts von Herausforderungen wie dem jüngsten Ausfall der NIST NVD robust.

Um eine hoch belastbare, branchenführende Schwachstellen-Erkennung  zu erreichen, interagiert die Greenbone-Komponente OPENVAS Scanner aktiv mit exponierten Netzwerkdiensten, um eine detaillierte Karte der Angriffsfläche eines Zielnetzwerks zu erstellen. Dies beinhaltet die Identifizierung von Diensten, die über Netzwerkverbindungen zugänglich sind, die Untersuchung dieser Dienste zur Ermittlung von Produkten und die Ausführung individueller Schwachstellentests (VT) für jede CVE- oder Nicht-CVE-Sicherheitslücke, um aktiv zu überprüfen, ob diese vorhanden sind. Der Enterprise Vulnerability Feed von Greenbone enthält über 180.000 VTs, die täglich aktualisiert werden, um die neuesten veröffentlichten Schwachstellen zu identifizieren und eine schnelle Erkennung der neuesten Bedrohungen zu gewährleisten.

Zusätzlich zu seinen aktiven Scan-Funktionen unterstützt Greenbone die agentenlose Datenerfassung über authentifizierte Scans. Greenbone sammelt detaillierte Informationen von den Endpunkten und bewertet die installierten Softwarepakete anhand der veröffentlichten CVEs. Diese Methode ermöglicht eine präzise Erkennung von Schwachstellen, ohne auf die angereicherten CPE-Daten der NVD angewiesen zu sein.

Wichtige Erkenntnisse:

  • Unabhängigkeit von angereicherten CVE-Daten: Die Schwachstellenerkennung von Greenbone ist nicht auf angereicherte CVE-Daten angewiesen, die von der NVD des NIST bereitgestellt werden, wodurch eine unterbrechungsfreie Leistung bei Ausfällen gewährleistet ist. Anhand einer grundlegenden Beschreibung einer Schwachstelle können die Ingenieure von Greenbone ein Erkennungsmodul entwickeln.
  • Erkennung über CPE-Abgleich hinaus: Obwohl Greenbone eine CVE-Scanner-Funktion für den CPE-Abgleich enthält, gehen die Erkennungsfähigkeiten weit über diesen grundlegenden Ansatz hinaus und nutzen mehrere Methoden, die aktiv mit Scan-Zielen interagieren.
  • Angriffsflächen-Mapping: Der OPENVAS-Scanner interagiert aktiv mit exponierten Diensten, um die Angriffsfläche des Netzwerks abzubilden und alle im Netzwerk erreichbaren Dienste zu identifizieren. Greenbone führt auch authentifizierte Scans durch, um Daten direkt von den Interna der Endpunkte zu sammeln. Diese Informationen werden verarbeitet, um verwundbare Pakete zu identifizieren. Angereicherte CVE-Daten wie CPE sind nicht erforderlich.
  • Widerstandsfähigkeit bei Ausfällen der NVD-Anreicherung: Die Erkennungsmethoden von Greenbone bleiben auch ohne NVD-Anreicherung wirksam, da sie die von CNAs bereitgestellten CVE-Beschreibungen nutzen, um genaue aktive Prüfungen und versionsbasierte Schwachstellenbewertungen zu erstellen.

Greenbones Ansatz: praktisch, wirksam und widerstandsfähig

Greenbone ist ein Beispiel für den Gold-Standard in Bezug auf Praktikabilität, Effektivität und Widerstandsfähigkeit und setzt damit einen Maßstab, den IT-Sicherheitsteams anstreben sollten. Durch den Einsatz von aktivem Netzwerk-Mapping, authentifizierten Scans und aktiver Interaktion mit der Zielinfrastruktur gewährleistet Greenbone zuverlässige, belastbare Erkennungsfunktionen in unterschiedlichen Umgebungen.

Dieser höhere Standard ermöglicht es Unternehmen, Schwachstellen selbst in komplexen und dynamischen Bedrohungslandschaften sicher zu erkennen. Auch ohne NVD-Anreicherung bleiben die Erkennungsmethoden von Greenbone effektiv. Mit nur einer allgemeinen Beschreibung können die VT-Ingenieure von Greenbone genaue aktive Prüfungen und produktversionsbasierte Schwachstellenbewertungen entwickeln.

Durch einen grundlegend robusten Ansatz zur Erkennung von Schwachstellen gewährleistet Greenbone ein zuverlässiges Schwachstellenmanagement und hebt sich damit von anderen Anbietern im Bereich der Cybersicherheit ab.

Alternativen zu NVD / NIST / MITRE

Die MITRE-Problematik ist ein Weckruf für die digitale Souveränität, und die EU hat bereits (und schnell) reagiert. Eine lang erwartete Alternative, die EuVD der ENISA, der Agentur der Europäischen Union für Cybersicherheit, ist nun verfügbar und wird in einem unserer nächsten Blogbeiträge vorgestellt.

Zwei neue Sicherheitslücken in Apache Camel sollten von Anwendern sofort beachtet werden. Am 9. März 2025 veröffentlichte Apache die Schwachstelle CVE-2025-27636 (CVSS 5.6), eine CVE (Common Vulnerabilities and Exposures) für die Remote Code Execution (RCE). Zwei Tage später, am 11. März, meldete die Security Intelligence Group (SIG) von Akamai eine Technik zur Umgehung des ursprünglichen Patchs, woraufhin CVE-2025-29891 (CVSS 4.2) am 12. März veröffentlicht wurde.

Grüne Grafik mit stilisiertem Kamel in einer Wüstenlandschaft. Rechts daneben ein Button mit der Aufschrift ‚RCE in Apache Camel‘.

Obwohl die beiden Schwachstellen vom Authorized Data Publisher (ADP) der Cybersecurity and Infrastructure Security Agency (CISA) nur mit moderaten CVSS-Scores bewertet wurden, können sie je nach Konfiguration der betroffenen Camel-Instanz schwerwiegende Auswirkungen haben. Beide CVEs haben dieselbe Ursache: eine unsachgemäße Filterung von HTTP-Headern oder HTTP-Parametern bei der Kommunikation mit einer Apache-Camel-Instanz. Wie im Titel angedeutet, geht es um die Groß- und Kleinschreibung. Während diese beim Filtern der Parameter berücksichtigt wurde, wurden die Argumente selbst ohne Berücksichtigung der Groß- und Kleinschreibung angewendet. Darüber hinaus tragen der öffentlich verfügbare PoC-Code (Proof of Concept) und eine relativ vollständige technische Beschreibung zu dem Risiko bei.

Greenbone kann sowohl CVE-2025-27636 als auch CVE-2025-29891 mit Schwachstellentests erkennen, die aktiv nach ausnutzbaren HTTP-Endpunkten suchen. Schauen wir uns die Details an.

Was ist Apache Camel?

Apache Camel ist eine beliebte Open-Source-Java-Bibliothek zur Integration verschiedener Komponenten einer verteilten Unternehmenssystemarchitektur wie APIs oder Microservices. Sie stellt eine vielseitige Plattform für Routing und Datenvermittlung dar, die auf dem Konzept der Enterprise Integration Patterns (EIPs) für das Architekturdesign von Unternehmenssystemen basiert. Apache Camel baut auf EIPs auf und bietet Möglichkeiten zur Implementierung dieser Muster über die domänenspezifischen Sprachen (DSL), die Java, XML, Groovy, YAML und andere umfassen.

Im Jahr 2021 hatte Apache Camel einen Anteil von 3,03 % am Markt für Enterprise Application Integration. Die Software wird von über 5.600 Unternehmen eingesetzt, von denen etwa die Hälfte in den USA ansässig ist. Vertreten ist Camel vor allem bei IT-Technologie- und Dienstleistungen (33 %), in der Softwarebranche (12 %) und bei Finanzdienstleistungen (6 %).

Zwei CVEs in Apache Camel erlauben Header-Injection

Wenn eine der HTTP-basierten Komponenten von Camel Anfragen bearbeitet, soll ein Standardfilter die Offenlegung sensibler Daten oder die Ausführung interner Befehle verhindern. Aufgrund einer fehlerhaften Filterregel, die zwischen Groß- und Kleinschreibung unterscheidet, wurden jedoch nur exakt übereinstimmende Header gefiltert. In der Programmlogik wurden diese Header allerdings nachgelagert ohne Berücksichtigung der Groß- und Kleinschreibung angewendet, wodurch der Filter umgangen werden konnte. Durch die Änderung der Groß- und Kleinschreibung des ersten Zeichens des Headernamens konnte ein Angreifer den Filter umgehen und beliebige Header einschleusen.

Die gute Nachricht ist, dass entweder die camel-bean- oder die camel-exec-Komponente in Kombination mit einer http-basierten Komponente wie camel-http, camel-http4, camel-rest, camel-servlet oder anderen aktiviert werden muss. Außerdem ist die Ausnutzung auf interne Methoden innerhalb des im HTTP-Request-URI angegebenen Bereichs beschränkt. Ein letzter Trost ist, dass diese Schwachstelle nicht als unauthentifizierte Schwachstelle eingestuft wurde. Deshalb ist sie nicht ausnutzbar, wenn die Systementwickler keine Authentifizierung und Autorisierung für eine Camel-HTTP-API implementiert haben.

Am oberen Ende des Risikospektrums kann ein Angreifer, wenn die Camel Exec-Komponente aktiviert und gezielt eingesetzt wird, als Benutzer, der den Camel-Prozess steuert, einen beliebigen RCE ausführen. Dies geschieht, indem der CamelExecCommandExecutable-Header gesendet wird, um einen beliebigen Shell-Befehl anzugeben, der die im Back-End konfigurierten Befehle überschreibt. Wenn die ausnutzbaren Camel-HTTP-APIs über das Internet zugänglich sind, ist das Risiko besonders hoch. Diese Schwachstelle könnte jedoch auch von einem Insider genutzt werden, um sich innerhalb eines Netzwerks seitlich zu bewegen, oder von Angreifern, die sich einen ersten Zugang zum internen Netzwerk einer Organisation verschafft haben.

Eine technische Beschreibung der Exploit-Kette und des Proof of Concept wurde von Akamai zur Verfügung gestellt.

Was ist der geeignete CVSS-Score?

Obwohl CVE-2025-27636 (CVSS 5.6) und CVE-2025-29891 (CVSS 4.2) als mäßig schwer eingestuft wurden, könnten sie kritische Auswirkungen haben, wenn entweder die camel-bean- oder camel-exec-Komponenten in Kombination mit http-basierten Komponenten aktiviert werden. Die Situation macht einige Einschränkungen des CVSS-Scorings (Common Vulnerability Scoring System) deutlich.

Akamai-Forscher berichten, dass die Schwachstelle trivial auszunutzen ist, und haben PoC-Code veröffentlicht, was das Risiko erhöht. Das bedeutet, dass die CVSS-Angriffskomplexität (AC) auf niedrig (L) gesetzt werden sollte. Jedoch hat der CISA-ADP die Angriffskomplexität angesichts dieser Tatsachen als hoch (AC:H) bewertet. Red Hat hat diesen Faktoren Rechnung getragen und den CVSS-Wert für CVE-2025-27636 auf 6,3 erhöht.

Außerdem hat der CISA-ADP für CVE-2025-29891 keine Auswirkungen auf die Vertraulichkeit festgestellt, obwohl die Möglichkeit einer willkürlichen RCE besteht. Wenn jedoch eine Apache Camel-Instanz eine anfällige Konfiguration aufweist, ist eine Bewertung mit hoher Auswirkung für Vertraulichkeit (C), Integrität (I) und Verfügbarkeit (A) gerechtfertigt, wodurch sich die Kritikalität auf CVSS 9.8 erhöht.

Andererseits hat der CISA-ADP den Wert „Keine“ (N) für die erforderlichen Berechtigungen (PR) zugewiesen. Obwohl der PoC von Akamai keine HTTPS-Verbindung oder Authentifizierung verwendet, wäre es äußerst fahrlässig, eine unverschlüsselte und nicht authentifizierte API zu betreiben. Apache Camel unterstützt die Java Secure Socket Extension (JSSE) API für Transport Layer Security (TLS) oder die Verwendung eines KeyCloak Single Sign-On (SSO) Autorisierungsservers. Camel-Instanzen, bei denen eine Form der Client-Authentifizierung aktiviert ist, sind vor einer Ausnutzung geschützt. In den meisten Fällen sollte der PR-Wert auf Niedrig (L) oder Hoch (H) eingestellt werden, was zu einem verminderten CVSS von 7,3 oder 8,8 führt.

Darüber hinaus wurden die CVEs mit dem Scope-Wert Unchanged (UC) versehen. Gemäß der CVSS v3.1 Spezifikation: „Die Scope-Metrik erfasst, ob eine Schwachstelle in einer verwundbaren Komponente Auswirkungen auf Ressourcen in Komponenten außerhalb ihres Sicherheitsbereichs hat.“ Die Ausführung beliebiger Shell-Befehle auf dem kompromittierten System wird normalerweise mit dem Wert Changed (C) bewertet. Wenn der Camel-Prozess dem Linux/Unix-Root oder einem Windows-Administrator-Benutzer gehört, hätte ein Angreifer praktisch unbegrenzte Kontrolle über ein kompromittiertes System. Angesichts der Vielzahl möglicher CVSS-Bewertungen sollten CVE-2025-27636 und CVE-2025-29891 als kritische Sicherheitslücken betrachtet werden, wenn eine Instanz die Konfigurationsanforderungen erfüllt und keine Authentifizierung anwendet.

Behandlung der CVEs in Apache Camel

CVE-2025-27636 und CVE-2025-29891 betreffen Apache Camel Version 4.10 vor 4.10.2, Version 4.8 vor 4.8.5 und Version 3 vor 3.22.4. Benutzer sollten ein Upgrade auf 4.10.2, 4.8.5 oder 3.22.4 durchführen oder eine benutzerdefinierte Header-Filterung mit removeHeader oder removeHeaders in Camel Routes implementieren. Es sollte beachtet werden, dass die Camel Versionen 4.10.0, 4.10.1, 4.8.0 bis 4.8.4 und 3.10.0 bis 3.22.3 immer noch verwundbar sind, obwohl sie als Sicherheitsupdates betrachtet wurden, die den Fehler behoben haben.

Es wird außerdem dringend empfohlen, dass alle HTTP-Endgeräte in einer verteilten Architektur eine starke Authentifizierung verwenden. Für Apache Camel gibt es folgende Optionen: Verwendung der Java Secure Socket Extension (JSSE) API für TLS mit Camel-Komponenten oder Verwendung eines KeyCloak OAuth 2.0 SSO Autorisierungsservers. Für Legacy-Systeme sollte mindestens die HTTP-Basisauthentifizierung konfiguriert werden.

Zusammenfassung

Benutzer von Apache Camel sollten sofort auf die Versionen 4.10.2, 4.8.5 oder 3.22.4 aktualisieren, um die neu veröffentlichten CVEs, die Apache Camel betreffen, zu entschärfen. Alternativ können Sie benutzerdefinierte Header-Filterung mit removeHeader oder removeHeaders in Camel-Routen implementieren. Eine starke Authentifizierung auf allen HTTP-Endpunkten wird ebenfalls dringend empfohlen, um die Sicherheit zu gewährleisten. Apache Camel unterstützt die JSSE API für TLS oder KeyCloak SSO Lösungen. Greenbone kann sowohl CVE-2025-27636 als auch CVE-2025-29891 mit Schwachstellentests erkennen, die aktiv auf ausnutzbare HTTP-Endpunkte prüfen.

Mithilfe der Greenbone-Produkte können bekannte Schwachstellen in einer IT-Infrastruktur aufgespürt werden, um sie anschließend zu beseitigen. Den Schweregrad einer Schwachstelle zu bewerten, ist ein essenzielles Hilfsmittel, um die nachfolgenden Beseitigungsmaßnahmen zu planen und zu priorisieren. CVSS bietet solch eine Bewertung nach einem Kennzahlensystem. Seit 2021 unterstützen die aktuellen Greenbone-Lösungen auch die CVSS-Versionen 3.0 und 3.1. Zur selben Zeit hat Greenbone begonnen, alle Schwachstellentests, für die eine entsprechende Bewertung verfügbar ist, mit dieser zu versehen. Seit Oktober 2021 ist diese Arbeit nun abgeschlossen und es gibt – soweit möglich – eine vollständige CVSSv3x-Abdeckung in den Greenbone-Feeds.

Hilfreiche Schweregrad-Kennzahlen

Jeder Cyber-Angriff benötigt eine Schwachstelle, um erfolgreich zu sein. Die meisten Schwachstellen, nämlich 999 von 1.000, sind bereits seit über einem Jahr bekannt und können daher proaktiv aufgedeckt und beseitigt werden. Zur Erkennung kommt dabei ein Greenbone-Schwachstellenscanner zum Einsatz, welcher die bekannten Schwachstellen in einer IT-Infrastruktur aufspürt.

Werden Schwachstellen aufgedeckt, können sie anschließend mit den unterschiedlichsten Maßnahmen beseitigt werden. Die am dringendsten zu beseitigenden Schwachstellen sind die, die ein kritisches Risiko für das IT-System darstellen. Für die Auswahl der Maßnahmen und der Reihenfolge, wird eine Priorisierung benötigt.

Zur Priorisierung ist der Schweregrad ein essenzielles Mittel. Wie Schwachstellen aber überhaupt einen Schweregrad erhalten und wie dieser berechnet wird, schauen wir uns hier einmal genauer an.

Wie Bewertungen des Schweregrads entstehen

In der Vergangenheit entdeckten und meldeten unterschiedliche Organisationen und Security-Research-Teams Schwachstellen zur gleichen Zeit und benannten diese mit unterschiedlichen Namen. Dies führte dazu, dass die gleiche Schwachstelle von z. B. mehreren Scannern unter unterschiedlichen Namen gemeldet wurde, was die Kommunikation und den Vergleich der Ergebnisse erschwerte.

Um das zu beheben, gründete MITRE das Projekt „Common Vulnerabilities and Exposures“ (CVE). Jeder Schwachstelle erhielt als zentrale Referenz eine eindeutige Kennzeichnung, die aus dem Veröffentlichungsjahr und einer einfachen Nummer besteht. Die CVE-Datenbank wird genutzt, um Schwachstellen-Datenbanken mit anderen Systemen zu verbinden und den Vergleich von Sicherheitswerkzeugen und -diensten zu ermöglichen.

CVEs enthalten somit keine detaillierten, technischen Informationen oder Informationen bezüglich der Risiken, Auswirkungen oder Beseitigung einer Schwachstelle. In manchen Fällen ist die Version hinterlegt, in der die Schwachstelle beseitigt wurde.

Nähere Informationen zu einer Schwachstelle finden sich in der National Vulnerability Database (NVD). Die NVD – ein Datenspeicher für das Schwachstellenmanagement der US-Regierung – ergänzt die CVEs mit Informationen bezüglich der Beseitigung, den möglichen Auswirkungen, den betroffenen Produkten und auch dem Schweregrad einer Schwachstelle.

Wie berechnet sich der Schweregrad einer Schwachstelle?

Um die Bewertung von Schwachstellen zu ermöglichen, wurde das Common Vulnerability Scoring System (CVSS) entwickelt. Das CVSS ist ein Industriestandard zum Beschreiben der Schweregrade von Sicherheitsrisiken in IT-Systemen. Es wurde von der CVSS Special Interest Group (CVSS-SIG) des Forum of Incident Response and Security Teams (FIRST) entwickelt. Die neueste CVSS-Version ist 3.1.
Der CVSS-Score bewertet Schwachstellen hinsichtlicht verschiedener Kritierien, sogenannter „Metrics“: Base-Score-Metrics, Temporal-Score-Metrics und Environmental-Score-Metrics.

  • Base-Score-Metrics: Die Base-Score-Metrics stellen die grundlegenden Merkmale einer Schwachstelle dar, die unabhängig von der Zeit und der IT-Umgebung sind: Wie gut lässt sich die Schwachstelle ausnutzen und welche Auswirkungen hat dies?
  • Temporal-Score-Metrics: Die Temporal-Score-Metrics stellen Eigenschaften dar, die sich über die Zeit ändern können, aber in unterschiedlichen IT-Umgebungen gleich sind. So würde beispielsweise das Bereitstellen eines Patches durch das bereitstellende Unternehmen den Score senken.
  • Environmental-Score-Metrics: Die Environmental-Score-Metrics stellen die Merkmale dar, die für eine spezifische IT-Umgebung gelten. Relevant sind hierbei, wie gut die betroffene Organisation erfolgreiche Angriffe abfangen können oder welchen Stellenwert ein bestimmtes angreifbares System innerhalb der IT-Infrastruktur hat.

Da im Allgemeinen lediglich die Base-Score-Metrics aussagekräftig sind und dauerhaft bestimmt werden können, werden in der Regel nur diese veröffentlicht und genutzt.

CVSSv3.0/v3.1-Unterstützung seit GOS 21.04

Seit GOS 21.04, welches im April 2021 veröffentlich wurde, werden auch die Versionen 3.0 und 3.1 von CVSS unterstützt. Zwar enthalten einige CVEs – und somit auch die zugehörigen Schwachstellentests – weiterhin CVSS-Daten der Version 2, allerdings betrifft dies hauptsächlich ältere CVEs aus dem Jahr 2015 und früher, für die in der NVD noch keinen CVSS-v3.0/v3.1-Score hinterlegt sind.

Blicken wir auf die größten Änderungen, die die Versionen 3.0 und 3.1 beinhalten.

Im Vergleich zu CVSS Version 2.0 wurden in Version 3.0 zwar die Hauptgruppen der Metrics – Base, Temporal und Environmental – beibehalten, aber neue Kriterien hinzugefügt. Beispielsweise die Metrics „Scope (S)“, was angibt, ob eine Schwachstelle auch andere Bestandteile eines IT-Netzwerks beeinträchtigen kann und „User Interaction (UI)“.

Auch wurden einige bereits vorhandene Kriterien durch neuere ersetzt: so wurde „Authentication (Au)“ zu „Privileges Required (PR)“. Gemessen wird nicht mehr, wie oft sich Angreifende bei einem System authentifizieren müssen, sondern welches Zugriffslevel für einen erfolgreichen Angriff notwendig ist.

Außerdem wurden die Schweregrade feiner unterteilt. In Version 2.0 wurden die Werte von 0 bis 10 auf drei Schweregrade aufgeteilt: „Low“ (0,0 – 3,9), „Medium“ (4,9 – 6,9) und „High“ (7,0 – 10,0). Seit Version 3.0 gibt es fünf Stufen: „None“ (0,0), „Low“ (0,1 – 3,9), „Medium“ (4,0 – 6,9), „High“ (7,0 – 8,9) und „Critical“ (9,0 – 10,0).

CVSS-Version 3.1 brachte keine Änderungen an den Metrics oder den Berechnungsformeln mit sich. Stattdessen lag der Fokus darauf, herauszustellen, dass CVSS den Schweregrad einer Schwachstelle misst und nicht das Risiko, welches sie darstellt. Ein weit verbreiteter Fehler war es, den CVSS-Score als alleiniges Merkmal für das Risiko einer Schwachstelle zu sehen und keine vollumfängliche Risikobewertung vorzunehmen.

In diesem Zuge wurden die Definitionen der Metrics eindeutiger formuliert und das Glossar erweitert.

Vollständige CVSSv3.0/v3.1-Abdeckung im Feed

Mit der Unterstützung von CVSS-v3.0/v3.1 im April 2021 begann Greenbone damit, alle Schwachstellentests, denen ein CVSSv3.0/v3.1-Score in der NVD zugewiesen wurde, zu aktualisieren und mit einem CVSSv3.0/v3.1-Score zu versehen.

Dies erfolgte in täglichen Etappen von 500 – 600 Schwachstellentests. Die Aktualisierung und Umstellung wurde dabei gründlich reviewt und geprüft. Seit Oktober 2021 ist diese Arbeit nun abgeschlossen. Somit gibt es – soweit es möglich ist – eine vollständige CVSSv3x-Abdeckung in den Greenbone-Feeds.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

Logo von Greenbone OS, dem Betriebssystem für die Greenbone Security Manager AppliancesAb dem 30.04.2021 ist die neueste GOS-Version – Version 21.04 – verfügbar und sie bringt wie immer viele neue Features und Verbesserungen mit sich! Was genau? Verschaffen Sie sich hier einen Überblick über alle wichtigen Neuerungen mit GOS 21.04!

Neue Hardware für unsere Midrange-Klasse

Für die Hardware-Appliances der Midrange-Klasse, welche für mittelgroße Unternehmen oder auch für Zweigstellen großer, verteilter Unternehmen genutzt werden, wurde eine neue Hardware-Generation eingeführt.

Die neue Hardware verwendet nun Festplatten vom Typ SSD statt HDD, welche 10-mal schneller, leiser und leichter sind. Außerdem steht auch mehr Festplattenspeicher zur Verfügung. Auch der Arbeitsspeicher wurde verbessert. Dieser ist nun vom Typ DDR4 statt DDR3, was ihn durch eine höhere Taktrate (3200 MHz) deutlich schneller macht. Des Weiteren steht doppelt bis viermal so viel Arbeitsspeicher zur Verfügung als vorher. Zusätzlich wurde eine neue, schnellere CPU der neuesten Generation verbaut. Auch die Ports der Appliances ändern sich: statt 6 Ports GbE-Base-TX und 2 Ports 1 GbE SFP sind nun 8 Ports GbE-Base-TX und 2 Ports 10 GbE SFP+ vorhanden.

Die Modellnamen bleiben unverändert.

Boreas-Erreichbarkeitsscanner jetzt als Standard

Der Boreas-Erreichbarkeitsscanner ist ein Host-Erreichbarkeitsscanner, der die aktiven Hosts in einem Zielnetzwerk identifiziert. Er wurde mit GOS 20.08 eingeführt, war bisher aber noch optional. Mit GOS 21.04 wurde der Boreas-Erreichbarkeitsscanner zum Standard.

Im Vergleich zum zuvor standardmäßig verwendeten Portscanner Nmap ist der Boreas-Erreichbarkeitsscanner hinsichtlich der maximalen Anzahl gleichzeitig durchgeführter Erreichbarkeitsscans nicht limitiert und damit schneller.

Der Boreas-Erreichbarkeitsscanner reduziert die Scanzeit für große Netzwerke mit einem geringen Anteil an erreichbaren Hosts deutlich. Dadurch ist es auch möglich, die ersten Scan-Ergebnisse schneller zu erhalten, unabhängig davon, wie hoch der Anteil erreichbarer Hosts im Netzwerk ist.

Übersichtlichere Ergebnisse durch neue Berichtformate

Für den Export von Berichten sind nun zwei weitere Berichtformate vorhanden, die die bisherigen Standardberichtformate ersetzen: Vulnerability Report PDF und Vulnerability Report HTML. Die Berichtformate sind klar strukturiert und übersichtlich. Spezielle zielgruppenrelevante Informationen können schnell erkannt und verstanden werden.

Die Berichtformate bieten eine Basis für benutzerdefinierte Berichte, welche für zukünftige GOS-Versionen geplant sind.

Beispiel für einen Greenbone Vulnerability Report mit Risikomatrix und detaillierten Scanergebnissen im HTML-Format

Neues Netzwerk-Backend für eine stabilere Verbindung

Mit GOS 21.04 wurde das Backend für die Netzwerkkonfiguration in GOS verbessert, indem der Netzwerkmodus gnm eingeführt wurde. Dies verhindert Verbindungsverluste in bestimmten Netzwerkkonfigurationen sowie Verbindungsprobleme mit SSH-Sitzungen. Außerdem muss der GSM nicht mehr neu gestartet werden, nachdem bestimmte Netzwerkeinstellungen geändert wurden.

Neue Hypervisoren für unsere virtuellen Appliances
Die offiziell unterstützten Hypervisoren für die virtuellen Appliances wurden mit GOS 21.04 geändert. Der GSM EXA/PETA/TERA/DECA und 25V kann mit Microsoft Hyper-V, VMware vSphere Hypervisor (ESXi) und Huawei FusionCompute verwendet werden, der GSM CENO mit Microsoft Hyper-V und VMware vSphere Hypervisor (ESXi) und der GSM ONE mit Oracle VirtualBox, VMware Workstation Pro und VMware Workstation Player. Zusätzlich unterstützt GOS 21.04 den ARM-Befehlssatz auf Huawei FusionCompute.

Verbesserung des Webservers, der Ciphers und der Web-Zertifikate

Mit GOS 21.04 wird zusätzlich zum Greenbone Security Assistant Daemon (gsad) der Webserver nginx verwendet. Dieser nutzt OpenSSL anstelle von GnuTLS zur Definition der verfügbaren Ciphers und Protokolle des Servers. Für die Konfiguration der TLS-Version gibt es nun im GOS-Administrationsmenü ein neues Menü. Außerdem wurde das Menü zum Konfigurieren der Ciphers angepasst.

Eine weitere Änderung findet sich bei der Generierung von HTTPS-Zertifikaten. Hier ist es nun möglich, einen oder mehrere Subject Alternative Name(s) (SAN) zu definieren. Diese dienen dazu, mehrere Domainnamen und IP-Adressen durch ein Zertifikat abzudecken.

Unterstützung von CVSS v3.0/v3.1 zur Schweregradberechnung

Für die Berechnung der Schweregrade von CVEs (Common Vulnerability Enumeration) wird nun auch Version 3.0 und 3.1 von CVSS unterstützt.

NVTs und CVEs können CVSS-Daten der Version 2 und/oder der Version 3.0/3.1 enthalten. Wenn ein/e NVT/CVE sowohl CVSS-v2-Daten als auch CVSS-v3.0/v3.1-Daten enthält, werden immer die CVSS-v3.0/v3.1-Daten verwendet und angezeigt.

Die Seite CVSS-Rechner enthält nun sowohl einen Rechner für CVSS v2 als auch einen Rechner für CVSS v3.0/v3.1.

Screenshot eines Vergleichs zwischen CVSSv2- und CVSSv3.1-Berechnung in GOS 21.04, jeweils mit Schweregrad, Vektor und Risikoeinstufung für eine Beispiel-Schwachstelle.

Open Scanner Protocol macht alle Sensor-GSMs leichtgewichtig

Bereits mit GOS 20.08 war es optional für alle Sensoren möglich, diese über das Open Scanner Protocol (OSP) steuern zu lassen. Dies führt dazu, dass die Sensoren leichtgewichtig werden und vermeidet, dass zusätzliche Anmeldedaten auf dem Sensor benötigt werden.

Mit GOS 21.04 wird nun nur noch OSP als Protokoll genutzt, um einen Sensor-GSM über einen Master-GSM zu steuern. Das Greenbone Management Protocol (GMP) wird nicht mehr verwendet.

Vereinfachte und intuitivere Funktionen auf der Web-Oberfläche

Mit GOS 21.04 wurden zudem einige kleinere Änderungen an GOS und an der Web-Oberfläche vorgenommen, um die Bedienung des GSM und das Scannen übersichtlicher und intuitiver zu machen.

So wurden die Auto-FP-Funktion und die alternativen Schweregradklassen-Schemata – BSI Schwachstellenampel und PCI-DSS – entfernt.

Einige Geräte – insbesondere IoT-Geräte – können abstürzen, wenn sie über mehrere IP-Adressen gleichzeitig gescannt werden. Dies kann zum Beispiel passieren, wenn das Gerät über IPv4 und IPv6 verbunden ist. Mit GOS 21.04 ist es möglich, das Scannen über mehrere IP-Adressen gleichzeitig zu vermeiden, indem beim Anlegen eines Ziels die neue Einstellung Erlaube das gleichzeitige Scannen über verschiedene IPs verwendet wird.

Sehen Sie selbst!

Überzeugen Sie sich selbst von unseren neuen Features und Änderungen! Ab sofort sind neue Appliances mit GOS 21.04 erhältlich und auch bestehende Appliances können auf die neueste Version aktualisiert werden. Auch unsere kostenlose Testversion ist mit GOS 21.04 verwendbar.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht