Warum wir ein Register für Schwachstellen brauchen
Jeden Tag werden neue Sicherheitslücken entdeckt: in Betriebssystemen, Webframeworks, Datenbanken oder sogar in Druckern und IoT-Geräten. Ohne einheitliche Benennung wäre es unmöglich, den Überblick zu behalten. Stell dir vor, jeder Hersteller würde eine kritische Lücke im selben Produkt anders benennen – Chaos wäre vorprogrammiert.
Genau hier kommen CVE und Exploit-DB ins Spiel. Sie sind die zentralen Systeme, mit denen die Security-Community Schwachstellen dokumentiert und verfügbar macht. Während CVE die offizielle „Nummerierung“ und Beschreibung übernimmt, stellt Exploit-DB praktische Beispiele für Ausnutzung bereit. Zusammen bilden sie das öffentliche Gedächtnis der IT-Sicherheit.
Was ist eine CVE?
CVE steht für Common Vulnerabilities and Exposures. Es ist ein weltweit anerkanntes System, um Schwachstellen eindeutig zu identifizieren.
Aufbau einer CVE-ID
Das Schema ist einfach:
CVE-JAHR-NUMMERBeispiele:
- CVE-2021-44228 → die berüchtigte Log4Shell-Lücke in Log4j.
- CVE-2017-0144 → Grundlage für den WannaCry-Wurm.
Jede CVE enthält:
- eine Kurzbeschreibung der Schwachstelle,
- eine Schweregrad-Einstufung (meist via CVSS-Score),
- Referenzen zu Advisories, Patches oder weiterführenden Artikeln.
Wer vergibt CVEs?
Die IDs werden von sogenannten CVE Numbering Authorities (CNAs) vergeben – das können Softwarehersteller, CERTs oder Sicherheitsorganisationen sein. Das Ganze wird von MITRE koordiniert und in die National Vulnerability Database (NVD) der US-Regierung eingespeist.
Warum das wichtig ist
Eine eindeutige ID sorgt dafür, dass alle Beteiligten – Entwickler, Admins, Forscher – über dieselbe Schwachstelle reden. Statt „die neue Log4j-Lücke“ sagt man „CVE-2021-44228“ – und jeder weiß sofort, worum es geht.
CVSS: Wie gefährlich ist eine Lücke?
Nicht jede CVE ist gleich kritisch. Deshalb gibt es den CVSS-Score (Common Vulnerability Scoring System). Er bewertet eine Lücke auf einer Skala von 0 bis 10.
Beispiel:
- CVSS 3.0 10.0 (kritisch) – wie bei Log4Shell (Remote Code Execution ohne Authentifizierung).
- CVSS 5.0 (mittel) – eine Info-Disclosure-Lücke, die Daten offenlegt, aber keinen direkten Zugriff erlaubt.
Kriterien sind u. a.:
- Angriffsvektor (lokal, Netzwerk, physisch).
- Komplexität (leicht oder schwer auszunutzen).
- Notwendige Privilegien.
- Vertraulichkeit, Integrität und Verfügbarkeit.
Der Score hilft IT-Teams, Prioritäten zu setzen: Welche Lücken müssen sofort geschlossen werden, welche können warten?
Was ist Exploit-DB?
Während CVE nur beschreibt, dass eine Lücke existiert, geht Exploit-DB einen Schritt weiter.
Exploit Database ist eine von Offensive Security betriebene Sammlung von Proof-of-Concept-Exploits. Sie enthält tausende Einträge, die zeigen, wie eine Schwachstelle in der Praxis ausgenutzt werden kann.
Inhalte der Exploit-DB
- Exploit-Skripte (z. B. in Python, C, PHP).
- Shellcodes für verschiedene Plattformen.
- Whitepapers und Sicherheitsanalysen.
- Google Hacking Database (GHDB) – Suchanfragen, die unsichere Systeme aufspüren können.
Beispiel: Log4Shell
- CVE-2021-44228 beschreibt die Lücke.
- In Exploit-DB fanden sich wenige Stunden nach Bekanntwerden Proof-of-Concepts, die demonstrierten, wie Angreifer durch eine manipulierte Logging-Nachricht Remote Code Execution erreichen konnten.
So konnten Sicherheitsforscher testen, ob ihre Systeme betroffen waren – und Unternehmen schnell reagieren.
CVE vs. Exploit-DB – zwei Seiten derselben Medaille
Man könnte sagen:
- CVE = die Theorie.
- Exploit-DB = die Praxis.
Zusammenspiel
- Forscher entdeckt Lücke.
- Hersteller oder CNA vergibt eine CVE-ID.
- Details (Patch, Advisory, Score) werden in CVE/NVD veröffentlicht.
- Forscher (oder andere) stellen ein Proof-of-Concept in Exploit-DB.
- Pentester und Security-Teams nutzen die Infos, um Systeme zu prüfen und abzusichern.
So entsteht ein Ökosystem, das Transparenz schafft und sowohl Angreifern als auch Verteidigern Informationen liefert.
Praxisnutzen für unterschiedliche Rollen
Entwickler & Admins
- CVEs beobachten (z. B. per Security Advisories, Mailinglisten oder NVD).
- Software regelmäßig patchen.
- CVSS-Scores nutzen, um Updates zu priorisieren.
Pentester & Forscher
- Exploit-DB durchsuchen, um Proof-of-Concepts für Tests zu finden.
- Eigene Exploits beitragen, um Wissen zu teilen.
- Systeme mit bekannten Exploits prüfen, um ihre Sicherheit zu validieren.
Security-Teams
- Schwachstellenmanagement aufbauen: Systeme scannen, CVEs abgleichen, Exploit-DB checken.
- Threat Intelligence nutzen, um frühzeitig zu erkennen, welche Lücken aktiv ausgenutzt werden.
Reale Vorfälle durch bekannte CVEs
- WannaCry (2017): Nutzt CVE-2017-0144 (SMB-Lücke). Millionen Systeme weltweit betroffen.
- Equifax Hack (2017): Ausnutzung von CVE-2017-5638 in Apache Struts. 147 Millionen Datensätze gestohlen.
- Log4Shell (2021): CVE-2021-44228. Weltweite Panik, weil Millionen Java-Anwendungen betroffen waren.
Diese Beispiele zeigen: CVEs sind nicht nur Zahlen – sie sind die Grundlage für manche der größten Hacks der letzten Jahre.
Tools für den Alltag
- NVD (nvd.nist.gov): Offizielle Datenbank aller CVEs mit CVSS-Scores.
- Exploit-DB (exploit-db.com): Praktische Exploits, oft mit Code zum Testen.
- Metasploit Framework: Viele Exploits aus Exploit-DB sind direkt als Module nutzbar.
- Vulnerability Scanner (z. B. Nessus, OpenVAS): Prüfen Systeme auf bekannte CVEs.
Was du mitnehmen solltest
- CVE liefert die eindeutige ID und Beschreibung einer Schwachstelle.
- Exploit-DB zeigt, wie man sie in der Praxis ausnutzen könnte.
- Zusammen bilden sie die Grundlage für Schwachstellenmanagement, Pentests und Incident Response.
- Wer Systeme absichern will, sollte beide Quellen regelmäßig im Blick behalten.
Schreibe einen Kommentar