Beiträge

In der vernetzten Produktion wachsen IT und OT immer stärker zusammen. Wo früher eine Sicherheitslücke „nur“ ein Datenleck verursacht hat, kann heute die gesamte Produktion zusammenbrechen. Wer regelmäßige aktive und passive Schwachstellenscans durchführt, kann sich schützen.

Was bei der physischen Infrastruktur etwas befremdlich wirkt – wer stellt schon einen Einbruch nach, um seine Alarmanlage zu testen – ist in der IT ein probates Verfahren, um Schwachstellen zu identifizieren. Dieses sogenannte aktive Scanning kann täglich und automatisch durchgeführt werden. Passives Scanning hingegen erkennt einen laufenden Einbruch, denn auch jeder Cyber-Einbruch hinterlässt Spuren, wenn auch oft verdeckt.

Den Verkehr kontrollieren

Firewalls und Antivirus-Programme nutzen beispielsweise passive Scans und überprüfen so den Traffic, der ein System erreicht. Diese Daten werden dann mit einer Datenbank abgeglichen. Dort sind Informationen zu Schadsoftware, unsicheren Anfragen und anderen Anomalien hinterlegt. Wenn die Firewall etwa eine Anfrage von einem unsicheren Sender bekommt, der Profildaten von Nutzenden auslesen will, lehnt sie die Anfrage ab. Das System selbst bekommt davon nichts mit, denn der passive Scan greift nicht auf das System zu, sondern nur auf den Datenverkehr.

Der Vorteil dabei: Das System muss keine zusätzliche Rechenleistung aufwenden. Trotz der Überprüfung kann die volle Bandbreite genutzt werden. Das ist vor allem bei kritischen Komponenten sinnvoll. Sie sollen eine möglichst hohe Verfügbarkeit aufweisen. Je weniger Zusatztätigkeiten sie ausführen, desto besser.

Der Nachteil des passiven Scannings: Nur Systeme, die selbst aktiv kommunizieren, kann man auch sehen. Nicht dazu gehört beispielsweise Büro-Software oder PDF-Reader. Aber auch Dienste, die kommunizieren, tun das vor allem mit ihren Hauptfunktionen. Funktionen mit Schwachstellen, die selten oder gar nicht im Regiebetrieb genutzt werden, sind nicht sichtbar oder eben erst dann, wenn der Angriff bereits läuft.

Die Infrastruktur überprüfen

Aktive Scans arbeiten anders und simulieren Angriffe. Sie stellen Anfragen an das System und versuchen dadurch, unterschiedliche Reaktionen auszulösen. Der aktive Scanner schickt zum Beispiel eine Anfrage zur Datenübermittlung an verschiedene Programme im System. Reagiert eines der Programme und leitet die Daten an die simuliert unbefugte Stelle weiter, hat der Scanner eine Sicherheitslücke gefunden.

Unterschiede zwischen aktiven und passiven Schwachstellenscans

Links: Beim aktiven Scan werden Anfragen an das System gesendet und dadurch versucht, unterschiedliche Reaktionen auszulösen. Rechts: Passive Scans überprüfen den Traffic, der ein System erreicht und gleichen diese Daten mit einer Datenbank ab.

Der Vorteil: Die Datenqualität, die beim aktiven Scannen erreicht werden kann, ist höher als beim passiven Scannen. Da die Interaktion direkt mit der Software und den Schnittstellen stattfindet, können Probleme in Programmen erkannt werden, die normalerweise nicht direkt mit dem Netz kommunizieren. Auf diese Weise werden auch Schwachstellen in Programmen wie Office-Anwendungen entdeckt.

Bei der direkten Interaktion müssen Systeme allerdings Extraanfragen bearbeiten, die dann unter Umständen die Grundfunktionen eines Programms beeinträchtigen. Betriebstechnik wie Maschinensteuerungen sind zum Beispiel nicht unbedingt dafür ausgelegt, Nebentätigkeiten auszuführen. Hier empfiehlt sich zum Beispiel Scannen unter Aufsicht und als Ergänzung kontinuierliches passives Scannen.

Aktiv scannen, aber minimalinvasiv

Trotzdem sind aktive Scans für die betriebliche Cyber-Sicherheit essenziell. Denn das Risiko, welches von der kurzfristigen Überbeanspruchung einer Systemkomponente ausgeht, ist klein im Vergleich zu einem Produktionsausfall oder einem Datenleck. Zudem decken aktive Scans nicht nur Schwachstellen auf, sie können auch passive Scans verbessern. So lassen sich die Schwachstellen, die erkannt werden, etwa in die Datenbanken von Firewalls aufnehmen. Das hilft auch anderen Unternehmen, die ähnliche Systeme nutzen.

Aktives und passives Scannen arbeiten Hand in Hand

Da der passive Scanner dem aktiven Scanner auch hilfreiche Informationen wie beispielsweise zu Mobiltelefonen oder Eigenschaften zu Netzwerk-Diensten geben kann, kann man von einer komplementären Ergänzung dieser beiden Sicherheitstools sprechen. Beiden ist gemein, dass sie aus der gegebenen Situation im Netzwerk automatisch immer das Beste herausholen. Für die Techniken des passiven und aktiven Scannens ist es egal, aus welchen oder wie vielen Komponenten und Programmen das Netzwerk besteht. Beide Sicherheitstechnologien erkennen dies von selbst und stellen sich darauf ein. Erst mit einem höheren Sicherheitsgrad beginnt die optimierte Abstimmung von Netzwerk und Scannern.

Es ist also keine Frage, ob man das eine oder das andere anwenden sollte. Beide Verfahren sind notwendig, um eine sichere Netzwerkumgebung zu gewährleisten. Ein rein passiver Ansatz wird in vielen Fällen nicht helfen. Ein proaktives Schwachstellenmanagement benötigt aktive Scans und Tools, um diese zu verwalten. Das ist es, was Greenbones Schwachstellenmanagement-Produkte bieten.


Log4j war von einer Schwachstelle betroffen, die Remote-Code-Execution-Angriffe (RCE-Angriffe) ermöglichte. Kurz gesagt, konnten Benutzereingaben in eine Software zu einer Codeausführung auf einem entfernten Server führen. Dies stellt ein schwerwiegendes Sicherheitsrisiko dar. Die Schwachstelle wurde „Log4Shell“ (CVE-2021-44228) genannt und sofort vom Log4j-Team behoben. In den folgenden Tagen wurden weitere Log4j-Schwachstellen gefunden. Diese haben zwar nicht die gleichen Auswirkungen wie die erste, können aber ebenfalls schwere Schäden verursachen. Aus diesem Grund ist es sehr wichtig, die Systeme zu überprüfen und immer auf die neuesten Versionen zu aktualisieren.

Da Log4j in zahlreichen Softwareprodukten enthalten ist, mussten und müssen auch die Hersteller der Produkte Updates bereitstellen. Dies ist noch nicht abgeschlossen und es könnten in Zukunft weitere Log4j-Schwachstellen auftauchen.

Als ein bewegliches Ziel bekommt Log4j immer noch viel Aufmerksamkeit, unter verschiedenen Aspekten:

  • Neue (und glücklicherweise weniger schwerwiegende) Sicherheitslücken werden gefunden.
  • Es entstehen neue Initiativen zur proaktiven Überprüfung von Log4-Quellen, wie zum Beispiel die Initiative von Google: Improving OSS-Fuzz and Jazzer to catch Log4Shell
  • Bei Greenbone erstellen wir noch mehr Schwachstellentests, um eine bessere Testabdeckung zu erreichen, und stellen sie täglich für unsere Produkte bereit.

Wir haben bereits eine ziemlich gute CVE-Abdeckung für die zusätzlichen Log4j-Schwachstellen, die in den letzten Tagen veröffentlicht wurden, erzielt, einschließlich:

  • CVE-2021-44228
  • CVE-2021-4104
  • CVE-2021-45046
  • CVE-2021-45105

Wie bereits erwähnt, hören wir hier nicht auf. Weitere lokale Sicherheitsprüfungen werden heute und morgen folgen, sobald die Linux-Distributionen ihre Advisories veröffentlicht haben.

Wir haben bereits einige Fakten über Log4j und den Umgang damit in unseren letzten Beiträgen veröffentlicht:


Update vom 20.12.2021: Informationen über weitere Schwachstellen, die für Log4j gefunden wurden, finden Sie hier.


Update vom 20.12.2021: Es sind nun auch Schwachstellentests für Produkte unter Microsoft Windows verfügbar.

Hinweis: Die Tests prüfen die Existenz von Log4j und dessen Version. Ein separater Schwachstellentest ist möglicherweise nicht für jede betroffene Anwendung verfügbar, aber alle Log4j-Dateien werden gefunden und gemeldet (/pfad-zur-log4j-datei/).

Die ausgegebenen Installationspfade müssen geprüft und ggf. der Hersteller kontaktiert werden. Es muss geprüft werden, ob für die jeweilige Anwendung bereits Updates verfügbar sind und ob der Fund relevant ist.

PowerShell-Ausführungsberechtigungen auf einem Zielsystem sind für den Account erforderlich, der in einem authentifizierten Scan verwendet wird. Einige Schwachstellentests führen PowerShell-Befehle aus, um die Genauigkeit der Ergebnisse zu erhöhen, wofür Berechtigungen für die Dauer eines Scans erforderlich sind.


Update vom 15.12.2021: ein zusätzlicher Angriffsvektor wurde identifiziert und in CVE-2021-45046 gemeldet. Wir arbeiten an Schwachstellentests für diesen Vektor, obwohl unsere Tests auch für diesen zusätzlichen Fall funktionieren. Wir empfehlen, auf die neueste Log4j-Version zu aktualisieren. Der Angriff ist komplizierter und ein Schutz erfordert eine andere Konfiguration. Da es sich aber um einen sehr neuen Vektor handelt, raten wir, besser auf Nummer sicher zu gehen. Mehr Informationen unter https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/.


Dieser Artikel enthält Antworten auf die am häufigsten gestellten Fragen zu Greenbones Log4j-Schwachstellentests.

Worum handelt es sich bei der Log4j-Schwachstelle?

Die „Log4Shell“-Schwachstelle betrifft eine Softwarebibliothek, die für die Aufzeichnung von Ereignissen (das so genannte „Logging“) in Software zuständig ist, die in der Programmiersprache Java geschrieben wurde. Böswillige Angreifende können diese Sicherheitslücke nutzen, um Code auf den betroffenen Systemen auszuführen.

Da diese Schwachstelle über das Internet und ohne jegliche Authentifizierung ausgenutzt werden kann, kann dies für betroffene Systeme und Unternehmen sehr kritisch sein. Da die Software auch in einer Vielzahl von Software und Diensten enthalten ist, die über das Internet zugänglich sind, sind wahrscheinlich viele Unternehmen und Dienste betroffen.

Weitere Informationen zu dieser Sicherheitslücke finden Sie hier:

Sind Greenbone-Produkte und -Dienste betroffen?

Wir haben den Status der möglicherweise betroffenen Systeme mit höchster Priorität überprüft. Keine unserer Produkte oder intern und extern erbrachten Dienstleistungen sind betroffen.

Können Greenbone-Produkte diese Schwachstelle erkennen?

Ja, Schwachstellentests wurden in den Greenbone Community Feed und in den Greenbone Enterprise Feed integriert, beginnend mit Feed-Version 202112130808. Dies bedeutet, dass sowohl unsere Appliances als auch unser Cloud-Produkt in der Lage sind, diese Sicherheitslücke zu erkennen.

Es sind zwar Schwachstellentests verfügbar, aber aufgrund der Komplexität dieser Sicherheitslücke kann nicht garantiert werden, dass eine Erkennung jedes einzelne betroffene System oder Produkt findet. Dies gilt insbesondere für nicht-authentifizierte „Remote“-Überprüfungen, und zwar aus den folgenden Gründen:

  • Das Produkt oder der Dienst könnte nur unter ganz bestimmten Umständen verwundbar sein. Da die Log4j-Bibliothek sehr komplex und hochgradig konfigurierbar ist und in vielen Produkten unterschiedlich eingesetzt wird, ist es nicht möglich, alle verwundbaren Instanzen durch eine Remote-Prüfung zu finden.
  • Sicherheitskonfigurationen im zu scannenden Netzwerk können eine erfolgreiche Überprüfung der Schwachstelle verhindern.
  • Produkte und Dienste können auch indirekt betroffen sein.

Eine spezielle Scan-Konfiguration zur direkten und schnellstmöglichen Erkennung dieser Sicherheitslücke ist ebenfalls über beide Feeds verfügbar. Bitte beachten Sie, dass die aktuelle Scan-Konfiguration nur aktive Prüfungen (remote und lokal) enthält. Paketversionsprüfungen sind nicht enthalten, um die Scan-Konfiguration und damit die Scanzeit minimal zu halten.

Ist die Erkennung im Greenbone Community Feed enthalten?

Ja. In beiden Feeds ist eine grundlegende Erkennung der Sicherheitslücke enthalten. Zusätzliche Schwachstellentests für potenziell betroffene Unternehmensprodukte sind über den Greenbone Enterprise Feed verfügbar.

Welche Erkennung ist in welchem Feed enthalten?

Greenbone Enterprise Feed

Wir implementieren fortlaufend Schwachstellentests in den Greenbone Enterprise Feed, daher kann die folgende Liste unvollständig sein, gibt aber den Stand vom 14.12.2021, 12:00 Uhr wieder.

Wichtig: Um die aktuellsten Informationen zu Ihrer Installation zu erhalten, können Sie nach  ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation suchen.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Apache Struts 2.5.x Log4j RCE Vulnerability (Log4Shell)
  • Apache Druid < 0.22.1 Multiple Vulnerabilities (Log4Shell)
  • Apache Flink < 1.13.4, 1.14.x < 1.14.1 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check
  • Apache Solr 7.x, 8.x Log4j RCE Vulnerability (Log4Shell) – Version Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Version Check
  • VMware Workspace ONE Access Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Operations Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Log Insight Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Automation Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Orchestrator Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Active Check
  • ArcGIS Server <= 10.7.1 Log4j RCE Vulnerability (Log4Shell)
  • Metabase < 0.41.4 Log4j RCE Vulnerability (Log4Shell)
  • Splunk 8.1.x, 8.2.x Log4j RCE Vulnerability (Log4Shell)
  • Wowza Streaming Engine <= 4.8.16 Log4j RCE Vulnerability (Log4Shell)
  • SonicWall Email Security 10.x Log4j RCE Vulnerability (SNWLID-2021-0032, Log4Shell)
  • IBM WebSphere Application Server Log4j RCE Vulnerability (6525706, Log4Shell)
Greenbone Community Feed

Wir implementieren fortlaufend Schwachstellentests in den Greenbone Community Feed, daher kann die folgende Liste unvollständig sein, gibt aber den Stand vom 14.12.2021, 12:00 Uhr wieder.

Wichtig: Um die aktuellsten Informationen zu Ihrer Installation zu erhalten, können Sie nach  ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation suchen.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Consolidation of Apache Log4j detections
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check

Über authentifizierte/unauthentifizierte Tests

Für einige Versionsprüfungen ist eine Authentifizierung erforderlich, für andere nicht. Außerdem können einige beides haben.

Die entsprechenden Informationen sind über die Links verfügbar, die bei der Suche nach ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation angezeigt werden.

Die „Qualität der Erkennung“ enthält Informationen über die Erkennungsmethode. Ein Wert von „package (97 %)“ deutet auf eine authentifizierte Prüfung hin, andere Werte wie „remote_banner (80 %)“ geschehen unauthentifiziert.

Weitere technische Informationen hierzu finden Sie unter https://docs.greenbone.net/GSM-Manual/gos-21.04/de/reports.html#quality-of-detection-concept.

Über aktive Tests/Testprüfungsversion, QoD

Sie können anhand des QoD und der „Erkennungsmethode“ auf der Web-Oberfläche erkennen, ob es sich um eine aktive Prüfung handelt, wenn Sie sich die Details des Schwachstellentests anzeigen lassen.

Hinweis: Nur Systeme, die tatsächlich Eingaben protokollieren, die von Angreifenden verändert werden können (z. B. bestimmte HTTP-Anfrage-Header, URLs, …), sind verwundbar.

Die Erkennungsmethode, die Qualität der Erkennung, die Schadensminderung und viele weitere Details sind über die Links verfügbar, die bei der Suche nach ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation angezeigt werden.

Scannen nach Knoten auf separaten VRFs & VLANs

  • Out-of-band-Scanning (OOB) ist derzeit nicht möglich. Bitte scannen Sie in jedem Segment.
  • Wir denken, dass eine solche Out-of-band-Kommunikation (OOB)/externe Interaktionsmöglichkeit in Zukunft integriert werden kann.


Immer wieder werden deutsche Behörden und Kommunen Ziele von Cyber-Angriffen. Der anschließende Wiederaufbau dauert oft mehrere Monate. Mit einem Schwachstellenmanagement kann das Risiko von Cyber-Angriffen drastisch reduziert werden – denn durch das Beseitigen von Schwachstellen wird Angreifenden die notwendige Grundlage genommen. Auch das Schwachstellenmanagement von Greenbone schützt Behörden – zu Sonderkonditionen.

Landkreise und Krankenhäuser gehackt, ganze IT-Infrastrukturen liegen lahm, zu behandelnde Personen werden ausgelagert, die Bundeswehr muss helfen: Was vor wenigen Jahren noch apokalyptisch anmutete, wurde im Sommer 2021 verstörende Realität. Zum ersten Mal in der deutschen Geschichte wurde der Katastrophenfall ausgerufen, weil sich Angreifende erfolgreich Zugriff auf die Netzwerke von Behörden oder deren Dienstleistenden verschafft hatten. Schwerin, Witten, Bitterfeld, Ludwigslust: Die Liste ist lang und nur großflächiges Deaktivieren der Server half den Betroffenen.

Abschalten hilft nur akut, der Neuaufbau dauert Monate

Wer sind die Angreifenden? Nicht immer ist es im digitalen Raum möglich, die Personen zu finden, die hinter den Taten stecken, sogar dann, wenn erpresserische Geschäftsmodelle und Lösegeldforderungen vorliegen. Meldepflichten und IT-Sicherheitsgesetze helfen den Betroffenen auch nicht konkret dabei weiter, denn der Schaden ist bereits entstanden: In der Regel wissen die Opfer noch nicht einmal gesichert, ob sie gezielt oder per Zufall angegriffen wurden. Die Schadenssummen sind immens, manche Behörden sind Monate mit dem Aufräumen und Wiederherstellen beschäftigt, nicht selten müssen ganze Systemlandschaften neu aufgebaut werden.

Dekoratives Bild einer Behörde

Cyber-Kriminelle nutzen Schwachstellen, die bereits gefixt waren

Warum aber fällt es Angreifenden so leicht, in fremde Netze einzudringen? Die meisten Angriffe, vor allem automatisierte, nutzen eigentlich schon lange geschlossene Schwachstellen für die Einbrüche.

Das funktioniert derzeit so gut, weil sich durch Systempflege allein nicht alle Systeme ausreichend auf Angriffe vorbereiten lassen. Schwachstellen können in Produkten, Systemkomponenten oder deren Konfiguration verborgen sein, die sich in den üblichen Infrastrukturen zu vielen tausenden Angriffspunkten summieren. Da stehen Hintertüren offen, die Angreifende aufspüren können, oft mit relativ einfach zu handhabenden Werkzeugen.

Schwachstellenscanner informieren und helfen, Lücken zu schließen

Dabei sind Admins, Behörden und Firmen keinesfalls machtlos. Was zählt, ist das Wissen über Verwundbarkeiten, Schwachstellen oder offene Flanken in den Netzwerken. Mit den richtigen Tools sind Sie Cyber-Kriminellen immer einen Schritt voraus, weil sie die Lücken Ihrer IT-Verteidigung erkennen, bevor Cyber-Kriminellen dies gelingt – mit den Greenbone-Lösungen klappt das kontinuierlich und automatisch.

Greenbone-Enterprise-Produkte untersuchen fortlaufend das Unternehmensnetzwerk oder externe IT-Ressourcen auf potenzielle Schwachstellen. Die speziell gehärtete Appliances – virtuell oder als Hardware verfügbar – oder der als Software-as-a-Service verfügbare Greenbone Cloud Service garantieren täglich aktuelle Updates zu den neuesten Schwachstellen. Admins und IT-Management werden bei Bedarf sofort informiert, wenn sich bedrohliche Sicherheitslücken offenbaren.

Sonderkonditionen für Behörden

Das erkennen auch mehr und mehr Behörden, die sich im Kampf gegen Cyber-Attacken für Greenbone entscheiden. Greenbone schützt Behörden zu Sonderkonditionen und die Lösungen können einfach über das Kaufhaus des Bundes beschafft werden.

 


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.