Kategorie: Allgemein

16. Juni 202518. Juni 2025Allgemein, Penetrationstest, Schwachstelle

Windows-Angriffe entgegen der Vertrauensstellung

Windows Domänen lassen sich durch Vertrauensstellungen zusammenbringen. Wird der Zugriff nur in eine Richtung benötigt kann man das Vertrauen auch nur einseitig aussprechen – aber sind damit Angriffe in die andere Richtung ausgeschlossen? Leider nicht, denn es gibt Wege um das Vertrauen entgegen der „Direction of Access“ auszunutzen.

In dem Artikel starten wir erst mit ein paar Grundlagen, um dann den konkreten Angriff vorzustellen. Zum Schluss geben wir noch Tipps für Gegenmaßnahmen und Detektionsmöglichkeiten.

Vertrauensstellung, was ist das?

Eine der Kernaufgaben des Active Directory (AD) ist es dafür zu sorgen, dass Nutzer sich bei verschiedenen Diensten und Systemen im eigenen Netz anmelden können. Dafür vertrauen alle Domänenmitglieder dem eigenen Domain Controller (DC), dass dieser die Authentizität der Nutzer gut prüft.

Aber das Vertrauen kann auch über die Grenzen einer Domäne oder eines Forests hinausgehen¹. Dazu wird in beiden Domänen eine Vertrauensstellung (Trust) eingerichtet. Im einfachsten Fall ist sie beidseitig, dann können Nutzer aus beiden Domänen Ressourcen in der jeweils anderen Domäne nutzen. Aber man kann auch nur eine einseitige Vertrauensstellung (One-Way Trust) einrichten, dann können Nutzer der einen Domäne Ressourcen der anderen Domäne nutzen aber nicht umgekehrt. Hier kommt man leicht mit den Richtungen und Begriffen durcheinander, daher findet sich in jeder guten AD-Anleitung ein Bild wie dieses:

Für unser Beispiel würde dies also so aussehen:

Ein Angreifer, der in der vertrauten Domäne (hier PARTNER.local) ein Konto oder gar die ganze Domäne übernommen hat, kann natürlich über die Vertrauensbeziehung auch Ressourcen in der anderen Domäne nutzen (entlang der “direction of access”). Bei der beidseitigen Vertrauensstellung gilt das logischerweise in beide Richtungen, aber auch bei der einseitigen Vertrauensstellung gibt es einen Grenzfall wie ein Angreifer, der bereits den Domain Controller übernommen hat, sich entgegen der “direction of access” weiterbewegen kann:

Kerberos über Grenzen hinweg, die Theorie

Für die verteilte Anmeldung nutzt Active Directory das Kerberos-Protokoll, das ursprünglich aus der akademischen Welt kommt und ganz im Sinne der akademischen Zusammenarbeit auch bereits alles für die hochschulübergreifende Zusammenarbeit mitbringt. Das Konzept hinter der Vertrauensstellung heißt bei Kerberos Cross-Realm-Authentifizierung.

Innerhalb eines Realms (oder Domäne in AD-Terminologie) meldet sich der Nutzer initial beim Authentisierungsserver (AS) an und erhält ein Sitzungsticket (Ticket Granting Ticket, TGT). Mit diesem Ticket kann der Nutzer dann beim Ticket-Granting-Server (TGS) Service-Tickets beantragen und sich dann mit diesen bei den Systemen und Services ausweisen, die er nutzen möchte.

Für die Cross-Realm-Authentifizierung wird dann einfach der fremde TGS wie ein Dienstserver im eigenen Realm betrachtet. Der Nutzer fragt also seinen Heimat-TGS nach einem Ticket für den Fremd-TGS. Dieses Ticket funktioniert dann analog zu einem TGT im anderen Realm. Der Nutzer beantragt mit diesem dann ein Service-Ticket beim Fremd-TGS für den eigentlichen Service, den er nutzen möchte. In beiden Schritten werden die gleichen Befehle ausgetauscht.

In der Praxis sind der TGS und der AS keine getrennten Server, sondern zwei Funktionen des Key Distribution Centers (KDC), die beide über den UDP-Port 88 erreicht werden. In der Windows-Welt ist das ein Service auf dem Domain Controller.

Um den Angriff gleich verstehen zu können, müssen wir noch einen Schritt tiefer gehen. Die Tickets, die bei Kerberos immer wieder ausgetauscht werden, sind Datenstrukturen, die mit einem symmetrischen Schlüssel verschlüsselt sind. Diese Schlüssel werden für Nutzer, Services und auch die Zwischenschritte am TGS in Principals gespeichert. Die Schlüssel für die Sitzungstickets (TGT) sind beispielsweise im Principal “krbtgt” gespeichert.

Für den ersten Schritt, die initiale Anmeldung am AS, basiert der Schlüssel auf dem Nutzerpasswort. Für die anderen Fälle sind auch andere Wege möglich, aber in Windows wird für die Fälle, in denen kein Nutzer involviert ist, einfach ein zufälliges Passwort generiert und daraus der Schlüssel abgeleitet.

Innerhalb einer Domäne bzw. eines Realms ist das auch einfach, da wir hier ja über eine zentral verwaltete Principal- bzw. Benutzer-Datenbank reden. Wenn wir jetzt aber die Grenzen überschreiten wollen, muss es in beiden Datenbanken einen gleichartigen Eintrag mit dem gleichen Schlüssel (also dem gleichen Passwort) geben. Auf der einen Seite der Grenze, um das Ticket verschlüsseln zu können, und auf der anderen Seite, um es wieder entschlüsseln zu können.

Die Umsetzung im AD

Jetzt wollen wir uns anschauen, was bei einer Vertrauensstellung in einem Windows Active Directory (AD) passiert.

Das Trusted Domain Object (TDO)

Um sich zu merken, mit welchen anderen Domänen oder Forests eine Vertrauensstellung existiert, wird pro Vertrauensstellung im “System”-Container der dazugehörigen Domänen (bzw. den Root-Domänen bei Forest-Trusts) jeweils ein Objekt angelegt – ein sogenanntes Trusted Domain Object (TDO). Auch bei einseitigen Vertrauensstellungen wird an beiden Enden ein TDO angelegt (einmal als eingehende, einmal als ausgehende Vertrauensstellung).

In den Attributen des Objekts werden alle Einstellungen für die Vertrauensstellung gespeichert. In dem Objekt wird zudem ein Passwort für das TDO gespeichert. Und zwar zum einen wie man es sonst von Benutzern und Computern kennt als Hash bzw. abgeleiteter Schlüssel und in diesem Fall zusätzlich auch im Klartext. Das Passwort wird automatisch alle 30 Tage geändert und – um Störungen beim Passwortwechsel vorzubeugen – wird jeweils das aktuelle sowie das vorherige Kennwort im TDO gespeichert. Das Passwort, und das ist wichtig, ist für beide Objekte gleich.

Das Objekt kann man in der MMC unter “Active Directory-Benutzer und -Computer” sehen, wenn man zuvor unter “Ansicht” die “Erweiterten Features” aktiviert hat. Dort findet es sich dann unter dem vollen Namen der jeweils anderen Domäne.

Der versteckte User

Das es auf beiden Seiten einen gleichartigen Eintrag mit dem gleichen Schlüssel geben muss, hatten wir schon bei der Kerberos-Theorie gesehen. In der Windows-Welt sind die beiden TDO aber nicht die einzigen Repräsentanten der Vertrauensstellung.

Schaut man sich die Nutzerliste auf der Seite der vertraueten Domäne (bei uns PARTNER.local) z. B. im ADSI-Editor etwas genauer an, findet sich dort ein User dessen Namen an die vertrauenden Domäne erinnert – in unserem Fall finden wir einen Benutzer HISOCORP$.

In vielen anderen Ansichten wie der MMC wird der Nutzer ausgeblendet. Praktischerweise hat dieser versteckte Benutzer das gleiche Passwort, das auch in beiden TDO-Objekten im Klartext gespeichert wird.

Der Angriff entgegen der Vertrauensrichtung

Nach so viel Theorie und Grundlagen wollen wir jetzt endlich schauen, wie wir das Vertrauen gegen den Strom ausnutzen können. Noch einmal zur Erinnerung: Wir wollen gegen die erlaubte “Direction of Access” arbeiten.

Der Trick ist jetzt, dass der versteckte Nutzer in der vertrauten Domäne ein fast normaler Nutzer ist, und wir sein Passwort kennen.

Dann besteht der Angriff aus diesen Schritten:

Die vertrauende Domäne kompromittieren (in unserem Beispiel HISOCORP.local)
Auf dem kompromittierten DC das Passwort aus dem Trusted Domain Object (TDO) auslesen
Mit dem bekannten Nutzernamen und dem ausgelesenen Passwort bei der vertrauenden Domäne (in unserem Beispiel PARTNER.local) anmelden. Also ein TGT beziehen.
Mit dem TGT können jetzt Dienst-Tickets bezogen werden und ggf. Dienste genutzt werden.

Auf Schritt 1 gehen wir nicht näher ein. Für die folgenden Schritte nehmen wir an, es ist bereits gelungen die Domäne zu kompromittieren und Zugriff auf einen Domain Controller (DC) zu erlangen. Das ist keine kleine Annahme und damit haben wir bereits vollen Zugriff auf alle Ressourcen auf dieser Seite der Vertrauensstellung.

Auf dem DC können wir jetzt für Schritt 2 das bekannte Tool Mimikatz nutzen. Für das Auslesen des TDO gibt es einen eigenen Befehl: lsadump::trust /patch

Im TDO ist das gemeinsame Passwort im Klartext gespeichert – in der Ausgabe oben jedes Zeichen als eine Hexadezimalzahl nach dem Stichwort „CLEAR“ – sowie verschiedene Hashwerte vom Passwort.

Den NT-Hash (rc4_hmac_nt) können wir direkt für Schritt 3 nutzen. Die beiden anderen Hashes/Schlüssel wurden mit einem anderen Salt erzeugt und entsprechen daher nicht den Hashes, die bei der vertrauten Domain im versteckten Nutzer gespeichert sind. Aber wir kennen jetzt ja das Klartextpasswort und die Berechnungsformel für die Nutzer-Schlüssel, können also diese beiden Werte auch selbst berechnen.

Wir nehmen in Schritt 3 den einfachsten Weg und melden uns direkt mit dem erbeuteten NT-Hash an. Dafür bietet sich beispielsweise die impacket-Suite an. Damit können wir direkt ein TGT beziehen:

Das TGT können wir in Schritt 4 dann zum Beispiel für einen Zugriff auf eine Dateifreigabe per SMB nutzen:

Im Beispiel wird auf die SYSVOL-Freigabe des fremden DC zugegriffen. Das geht, weil diese Freigabe grundsätzlich von allen Nutzern (Gruppe „Domänenbenutzer“) gelesen werden kann.

Da der Nutzer in der normalen Administration nicht sichtbar ist, ist er weder Mitglied in anderen Gruppen noch wurde der User selbst für Dienste oder Zugriffe explizit berechtigt. In einem realen Netz finden sich aber auch häufig weitere Freigaben und Dienste, die alle gemeinsam nutzen und die für die allgemeine Gruppe der Domänenbenutzer freigegeben sind.

Bei der Bewertung von Sicherheitslücken wird immer unterschieden, ob sie auch ohne Login oder nur nach erfolgreicher Authentifizierung möglich sind. Und genau diesen Sprung zum authentifizierten Angreifer konnten wir jetzt machen, unabhängig davon wie wenig Rechte dem versteckten Nutzer eingeräumt wurden.

Ein Beispiel sind Kerberoasting-Angriffe, die darauf abzielen, Service-Konten zu übernehmen, die nicht mit einem zufällig automatisch generierten Passwort, sondern mit einem menschlich erdachten Passwort gesichert sind. Einzige Voraussetzung für diesen Angriff ist der Zugriff auf ein funktionierendes Nutzerkonto in der Domäne. Dieser Nutzer muss gar keine Zugriffsrechte für den zu knackenden Dienst haben, daher funktioniert der Angriff auch mit dem versteckten Nutzer:

Im Anschluss haben wir Zugriff auf ein Nutzerkonto mit mehr Zugriffsrechten, meist sogar einigen administrativen Rechten und können uns so immer weiter in der Partner-Domäne ausbreiten.

Mögliche Detektions- und Gegenmaßnahmen

In den nächsten Abschnitten wollen wir uns anschauen, wie man sich gegen diese Art von Angriffen wappnen kann und auch kurz Maßnahmen besprechen, die zwar naheliegend klingen, aber nicht wirken.

All diese Maßnahmen zielen auf die Sicherheit der vertrauten Domäne (in unserem Beispiel PARTNER.local). Für die vertrauende Domäne (in unserem Beispiel HISOCORP.local) gibt es unabhängig von dem hier geschilderten Problem auch einiges zu beachten, um nicht durch die Vertrauensstellung Probleme zu bekommen. Da dies aber der geplante Zugriffsweg ist, gibt es dazu bereits passende Anleitungen.

Detektion

Das versteckte Nutzerkonto für die Vertrauensstellung wird nie als Nutzer im eigentlichen Sinn verwendet. Daher sind jegliche Aktivitäten mit der Nutzerkennung (Muster <Domänenkürzel>$) wie das Ausstellen eines TGT (Windows Event 4768), eines Service Tickets (Anfordern Windows Event 4769, Erneuern Windows Event 4770, Fehler Windows Event 4773) oder eine Anmeldung ein eindeutiges Zeichen für eine Ausnutzung.

Gegenmaßnahmen

Auf verschiedenen Wegen kann die Anmeldung mit dem versteckten Nutzerkonto verhindert werden.

Die Systeme der beiden Domänen befinden sich meist auch in unterschiedlichen Netzen, daher kann per Firewall der Zugriff auf Port 88 zum Domain Controller der vertrauten Domäne (in unserem Beispiel PARTNER.local) vom Netz der vertrauenden Domäne (HISOCORP.local) gesperrt werden. In die umgekehrte Richtung ist der Zugriff nötig, damit Nutzer sich Service Tickets für freigegebene Dienste der vertrauenden Domäne ziehen können, in dieser Richtung jedoch nicht. Damit wird der Angriff verhindert, wenn der Angreifer aus dem anderen Netz agiert. Hat der Angreifer unabhängig von der Kompromittierung der vertrauten Domäne auch bereits Netzwerkzugriff auf Systeme der vertrauten Domäne, hilft die Firewallregel nicht.

Die Nutzung des versteckten Kontos kann auch per GPO unterbunden werden. Dafür muss die Regel „Zugriff vom Netzwerk auf diesen Computer verweigern“ erstellt werden und dort dann manuell das Konto (in unserem Beispiel HISOCPRP$) eintragen werden. Der Kontoname muss händisch eingegeben werden, da bei der „Durchsuchen“-Funktion das Konto auch ausgeblendet ist. Wenn die GPO wirksam ist, kann zwar weiterhin ein TGT für dieses Konto bezogen werden, aber keine Servicetickets. Damit geht auch kein Zugriff auf Dienste (wie Dateifreigaben) oder der oben geschilderte Kerberoasting-Angriff.

Als weitere Verteidigungsschicht können die Zugriffsrechte für den Nutzer eingeschränkt werden. Der Nutzer ist automatisch Mitglied in der Gruppe „Domänenbenutzer“ und gehört auch zur Gruppe „Benutzer“. Dienste und Dateien sollten nicht für eine der beiden Gruppen freigegeben werden, auch wenn sie von allen genutzt werden sollen. Stattdessen bieten sich für solche Freigaben eine zusätzlich gepflegte Gruppe mit allen aktiven Nutzern an.

Maßnahmen, die nicht wirken

Es gibt einige Gegenmaßnahmen, die sehr naheliegend klingen, aber tatsächlich nicht umsetzbar oder hilfreich sind.

So kann der versteckte Nutzer nicht einfach deaktiviert oder gelöscht werden, entsprechende Versuche führen direkt zu Fehlermeldungen.

Der Nutzer hat als primäre Gruppe die Gruppe „Domänenbenutzer“. Das ist eine automatische Gruppenzuordnung, das heißt man kann zwar eine andere primäre Gruppe eintragen aber der Nutzer wird dennoch immer Mitglied der „Domänenbenutzer“ bleiben.

Fazit

Aus einer einseitigen Vertrauensstellung zwischen Domänen kann sich damit auch ein Risiko entgegen der „Direction of Access“ ergeben. Wird die eine Domäne kompromittiert erhält der Angreifer auch das Passwort für einen versteckten Nutzer in der anderen Domäne. Der hat zwar kaum Zugriffsrechte, aber kann als erster „Fuß in der Tür“ für weiterführende Angriffe genutzt werden.

Da Risiko lässt sich aber durch Firewallregeln, GPOs und gutes Rechtemanagement adressieren. Ein erfolgreicher Angriff lässt sich auch eindeutig in den Windows Events identifizieren.

Im Folgenden werden wir der Einfachheit halber immer von einer Domäne sprechen, da sich ganze Forests in diesem Fall wie eine Domäne verhalten ↩︎

12. Juni 202512. Juni 2025Allgemein

Weitere News im Juni

Sicherheitslücke durch inetpub: Wie ein gelöschter Ordner Windows verwundbar macht

Im April 2025 sorgte ein unscheinbarer Ordner namens inetpub auf Windows-Systemen für Aufsehen – und für ein ernstzunehmendes Sicherheitsproblem. Was zunächst wie ein harmloses Überbleibsel aus alten IIS-Zeiten wirkte, entpuppte sich als kritischer Bestandteil eines Sicherheitsupdates und als potenzielles Einfallstor für Angreifende.

Was ist passiert?

Mit dem April-Patchday legte Microsoft auf Windows 10- und 11-Systemen automatisch den Ordner C:\inetpub an. Dieser sollte laut Microsoft helfen, die Sicherheitslücke CVE-2025-21204 (Base Score: 7,8 von 10) zu entschärfen, die mit symbolischen Links (Symlinks) zusammenhängt. Dokumentation dazu fehlte zunächst – viele Nutzende hielten den Ordner für überflüssig und löschten ihn kurzerhand.

Das eigentliche Problem

Genau hier beginnt das Sicherheitsdilemma: Wenn der Ordner gelöscht wird, können zukünftige Windows-Updates fehlschlagen. Für die Ausnutzung dieser Sicherheitslücke ist kein ausgefeilter Angriff nötig. Es muss lediglich ein symbolischer Link von „inetpub” zu einer anderen Datei erstellt werden. Das System bleibt dann auf einem unsicheren Stand.

Microsofts Reaktion

Nachdem Sicherheitsforscher Kevin Beaumont auf das Problem aufmerksam gemacht hatte, veröffentlichte Microsoft ein PowerShell-Skript namens Set-InetpubFolderAcl.ps1. Dieses stellt den Ordner wieder her und setzt die korrekten Zugriffsrechte. Das Skript prüft auch, ob der Ordner manipuliert wurde und verhindert so weitere Missbrauchsmöglichkeiten.

Fazit: Ein Lehrstück in Kommunikation und Sicherheit

Der Fall zeigt, wie wichtig klare Kommunikation bei sicherheitsrelevanten Änderungen ist. Ein leerer Ordner mag harmlos wirken, doch in diesem Fall war er ein zentraler Bestandteil eines Sicherheitsmechanismus. Wer ihn entfernte oder manipulierte, öffnete sein System ungewollt für Angriffe.

Nutzende sollten prüfen, ob der Ordner inetpub vorhanden ist und ggf. das Microsoft-Skript ausführen, um die Sicherheit des Systems wiederherzustellen.

https://doublepulsar.com/microsofts-patch-for-cve-2025-21204-symlink-vulnerability-introduces-another-symlink-vulnerability-9ea085537741

https://www.heise.de/news/Microsoft-Abhilfe-fuer-Sicherheitsluecke-durch-geloeschte-inetpub-Ordner-10437103.html

https://www.golem.de/news/windows-10-und-11-mysterium-um-inetpub-ordner-teilweise-aufgeloest-2504-195313.html

https://www.golem.de/news/windows-leerer-inetpub-ordner-schafft-ein-neues-sicherheitsproblem-2504-195563.html

https://www.chip.de/news/Wie-ein-leerer-Ordner-fuer-Windows-zum-Sicherheitsproblem-wird_185936620.html

Microsoft veröffentlicht Script, um inetpub neu anzulegen

https://nvd.nist.gov/vuln/detail/cve-2025-21204

TM SGNL – (k)eine Signal-Alternative

Wir erinnern uns an die als Signalgate bekannt gewordene Affäre zu geleakten klassifizierten Informationen über einen Signal-Chat. Wie sich nun herausstellt, nutzten die Angehörigen der US-Regierung nicht den offiziellen Signal-Client, sondern eine abgeänderte Version von TeleMessage, einem israelischen Unternehmen. Diese Version von Signal ermöglichte aufgrund eines trivialen Fehlers den Zugriff auf Chats. @micahflee@infosec.exchange und @ljrk@todon.eu haben interessante Details gefunden.

Für alle Kryptografie-Interessierten empfehlen wir den Blog von @soatok@furry.engineer zu dem Thema, in dem zu lesen ist, was eine Signal-Alternative zu erfüllen hat (und warum die meisten Messenger bereits dort scheitern).

Windows RDP-Cache – Wenn der Cache länger hält, als er soll

Windows RDP-Caches erlauben Log-ins mit alten Credentials, die bereits rotiert wurden. Microsoft behauptet allerdings, dass dies ein Feature sei, damit man sich nicht aussperrt. Die IT-Sicherheits-Szene reagierte irritiert. Es empfiehlt sich, einen Blick auf die eigenen Konfigurationen dazu zu werfen.

https://arstechnica.com/security/2025/04/windows-rdp-lets-you-log-in-using-revoked-passwords-microsoft-is-ok-with-that

Kritische Schwachstelle in WooCommerce Wishlist lange Zeit ohne Patch

In den WordPress-Fällen der letzten Monate ist uns das Modul WooCommerce öfter aufgefallen. Nun stellte sich heraus: Bereits im März wurde eine kritische Lücke (CVE-2025-47577) dem Hersteller gemeldet, worauf dieser aber nicht reagierte. Bei der Lücke handelt es sich um ein „pre-Auth RCE“, also die Möglichkeit zur Ausführung von Schadcode ohne vorhergehende gültige Benutzeranmeldung. Die technischen Details sind im verlinkten Artikel einsehbar.

Dieser Vorfall sollte die Wichtigkeit von Supply-Chains und weiterführenden Mitigationsmaßnahmen neben dem Patchen klar machen, denn manchmal steht kein Patch zur Verfügung.

https://patchstack.com/articles/unpatched-critical-vulnerability-in-ti-woocommerce-wishlist-plugin

5. Mai 2025Allgemein, Risikomanagement, Schwachstelle, Supply Chain

Drohende Abschaltung der CVE-Datenbank und mögliche Alternativen

Kurz vor Ostern schreckte eine Nachricht des CVE-Teams die Sicherheitswelt auf. Die Finanzierung des CVE-Programms stand auf der Kippe und im Extremfall wäre einen Tag später bereits Schluss gewesen. Der Aufschrei war zu Recht groß und so konnte der Betreiber MITRE eine Vertragsverlängerung bis Anfang nächsten Jahres erreichen. Aber was kommt dann?

In diesem Blogpost wollen wir mit etwas Abstand zu den Ereignissen zusammenfassen, welche Alternativen in der Diskussion um eine mögliche CVE-Abschaltung oft genannt wurden und ob sie tatsächlich in die Fußstapfen von CVE treten könnten.

Anwendungsfälle

Zuerst wollen wir uns kurz anschauen, wo wir und viele unserer Kunden Berührungspunkte mit CVE haben. Es gibt darüber hinaus weitere Anwendungsfälle, aber für diese häufigen Nutzungen wollen wir uns im Folgenden die Alternativen anschauen.

Risikomanagement im ISMS

Beim Thema Informationssicherheit denken viele Laien als Erstes an die Sicherheitsupdates, die ihre Geräte regelmäßig von ihnen fordern. Im professionellen ISMS kommt noch dazu, dass einige Updates nur mit einer Betriebsunterbrechung eingespielt werden können oder unerwünschte Nebenwirkungen haben. Es muss also eine bewusste Entscheidung zwischen dem neu hinzugekommenen Sicherheitsrisiko und den betrieblichen Einschränkungen getroffen werden. Wenn eine Sicherheitslücke bereits bekannt ist, aber noch kein Patch verfügbar ist, wird die Entscheidung zwischen Abschalten und Risikoakzeptanz noch herausfordernder.

Die reinen CVE-Nummern können in dem Anwendungsfall bei der weitergehenden Recherche helfen oder teilweise den Abgleich von verschiedenen Prüfformen ermöglichen (z.B. ob die im Pentest erkannten Lücken, bereits aus einem anderen Audit adressiert werden).

Meist nutzt man jedoch auf CVE-basierte Datenbanken wie die National Vulnerability Database (NVD) der US-Regierung oder Ableitungen davon, die bereits eine allgemeine Risikobewertung mitbringen. Damit können bereits erkannte Risiken schneller und ressourcensparsam vorbewertet werden. Das konkrete Risiko für die jeweilige Betriebssituation muss man dennoch individuell bewerten (z.B. ob die betroffene Funktion überhaupt genutzt wird).

Außerdem nutzen viele Informationsdienste und Vulnerability-Management-Tools CVE-basierte Datenbanken, um auf neu bekanntgewordene Schwachstellen hinzuweisen. Im besten Fall wählt man als Betreiber alle genutzten Softwareprodukte aus und wird dann aktiv auf neue Schwachstellen hingewiesen.

Schwachstellenscan für Container

Für Betreiber von containerisierten Services ist das Scannen von Containern bzw. Container-Scanning ist ein weiterer Anwendungsfall für die Nutzung von CVEs.

Dabei werden Container-Images auf Sicherheitslücken überprüft. Zuerst wird analysiert, welche OS-Pakete, Dependencies und weitere Software in dem zu scannenden Image benutzt werden, z.B. openssl. Anschließend werden die Findings (Name der Komponente sowie Versionsnummer/-stand) mit den gängigen CVE-basierten Datenbanken wie NVD abgeglichen. Sollten bekannte Schwachstellen identifiziert werden, wird dies an das Scanning-Tool zurückgemeldet und das Tool erstellt auf Basis dieser Informationen einen Bericht.

Der Bericht enthält dann. welche CVE gefunden wurde, wie schwerwiegend diese ist bzw. wie hoch ihr CVSS-Score ist, wo im Image die Schwachstelle gefunden wurde, und es werden in den meisten Fällen auch direkt Mitigationsmaßnahmen empfohlen. Diese Maßnahmen beziehen sich entweder auf ein Update/Upgrade der verwendeten Version auf die nächste sichere Version oder auf geeignete Konfigurationen, um die Sicherheitslücke zu schließen.

Gängige Tools, die man für Scanning verwenden kann, sind u.a. die OpenSource Tools Trivy sowie Clair. Kommerzielle Tools, die z.B. auch einen erweiterten Support zur Verfügung stellen können oder weitere Funktionen haben, sind Snyk sowie JFrog.

Verwendet man Container-Scanning in seiner Infrastruktur, hat man den großen Vorteil, dass Schwachstellen noch vor dem Deployment entdeckt werden können. Auch ist das Container-Scanning in CI/CD-Pipelines automatisierbar und bietet so eine weitere Dosis Sicherheit.

Software Supply Chain

Nicht nur Betreiber, sondern auch Softwareanbieter benötigen ein Risikomanagement. Sicherheitsrelevante Fehler in genutzten Komponenten, Bibliotheken und Hilfstools können sich auch auf die ausgelieferte Software übertragen. Angriffe, die gezielt auf diese Vererbung der Sicherheitslücken abzielen, werden Software-Supply-Chain-Angriff genannt.

Die reinen CVE-Nummern helfen den Softwareanbietern bei der Kommunikation. In ihren Release-Notes können sie ihren Kunden eindeutig aufzeigen, welche Schwachstellen (eigene und von Drittkomponenten geerbte) beseitigt wurden. Die Kunden können die Information dann mit ihrem eigenen Risikomanagement aus Betriebssicht abgleichen. Die CVE-Nummer kann aber auch gut genutzt werden, um aufzuzeigen, dass die eigene Software von einer konkreten Lücke nicht betroffen ist. So forderten beispielsweise bei der Log4Shell-Schwachstelle in der Log4j-Bibliothek viele große IT-Organisationen von ihren Zulieferern Negativbescheide, dass ihre Produkte von dieser Lücke nicht betroffen waren.

Ähnlich wie die Scanner für Container gibt es auch Scantools, die über die Versionsstände von eingebundenen Dependencies ermitteln, ob eine neue Schwachstelle bekannt wurde. Nutzt man zum Verwalten der Abhängigkeiten einen Registry-basierten Ansatz (z.B. mit NPM), erhält man so leicht die notwendigen Informationen. Für händisch hinzugefügte Abhängigkeiten (z.B. JAR-Archiv, Binärbibliothek, JavaScript) gibt es ebenfalls Scanner, die teilweise Heuristiken einsetzen müssen, um den eindeutigen Namen der Bibliothek und die Versionsnummer zu bestimmen (z.B. RetireJS, Trivy).

Exploits/Lücken nachvollziehen im Pentest / in der Incident Response

Im Bereich von Penetrationstests, technischen Audits und Incident Response werden CVEs regelmäßig verwendet. Durch die eindeutige Benennung sprechen sowohl Kunden als auch Sicherheitsberatende über dieselbe Sicherheitslücke. Kunden erlaubt dies beispielsweise einfacher einzuschätzen, in welchen Versionen eine Sicherheitslücke eines eingesetzten Systemes vom Hersteller behoben wurde, da Changelogs der Hersteller und externe Quellen die CVEs zu betroffenen Versionen mappen.

Ebenso werden anhand der CVE z.B. weiterführende Recherchen, sei es über Suchmaschinen, auf GitHub oder in dedizierten Vulnerability Databases, erleichtert. Es kann z.B. besser eingeschätzt werden, ob bereits öffentlich verfügbare Write-Ups, Exploits oder Proof-of-Concept Code existiert, der durch Angreifende verwendet werden kann. Im Incident Response kann dies als Indiz für die Ausgereiftheit der Angreifenden herangezogen werden.

Gefundene Schwachstelle melden

Bei der Meldung von Schwachstellen wird die gefundene Sicherheitslücke im Rahmen von Responsible Disclosure häufig bei einer CVE Numbering Authority (CNA) eingereicht, um für diese Lücke eine CVE zugewiesen zu bekommen. Da während des Prozesses der Meldung viele Parteien beteiligt sein können, z.B. die Entdeckenden der Lücke, die Herstellenden des Systems, die Personen, die das System einsetzen, oder auch Vermittelnde wie ein CERT, soll eine CVE dabei sicherstellen, dass von der gleichen Lücke gesprochen wird. Außerdem können alle Beteiligten den Fortschritt während des Prozesses der Responsible Disclosure effektiver verfolgen. Nach der Behebung einer Sicherheitslücke erlaubt eine veröffentlichte CVE der Öffentlichkeit, z.B. betroffenen Firmen, den Einfluss der Sicherheitslücke auf die eigenen Systeme zu beurteilen und ggf. Maßnahmen zu ergreifen.

Alternativen

Für diese Anwendungsfälle wollen wir uns jetzt mögliche Alternativen anschauen. Wir haben dabei die Ansätze ausgewählt, die in den Tagen um die drohende CVE-Abschaltung am breitesten diskutiert wurden. Einige der Ansätze sind aktuell noch nicht praktisch nutzbar oder zielen auch auf ein ganz anderes Anwendungsfeld ab. Wenn sie dennoch in der Diskussion Raum eingenommen haben, haben wir sie hier aufgegriffen.

Das Original: MITRE CVE

Betrieben von der Non-Government-Organization (NGO) MITRE Corporation, gilt das Common Vulnerabilities and Exposures (CVE) System als die Referenz in der Welt der IT-Sicherheit für Sicherheitslücken und Schwachstellen. Durch die Vereinheitlichung der Nummerierung von Sicherheitslücken ist jederzeit eindeutig, auf welcher Sicherheitslücke man sich bezieht.

Dadurch ist das Kürzel “CVE” für einige auch schon zum Synonym für “Sicherheitslücke” geworden und wird meist auch mit den detaillierten Einträgen in CVE-basierten Datenbanken wie der NVD gleichgesetzt. Die CVE-Datenbank selbst enthält allerdings nur sehr wenige Informationen zur Lücke. Grundsätzlich gerade so viele Informationen, um die Lücke wiedererkennen zu können. Das Datenbankformat erlaubt auch Risikoeinschätzungen und andere Informationen, diese sind aber optional.

Besondere Aufmerksamkeit bekam dieses System, nachdem die US-Regierung unter Trump im April 2025 die Finanzierung stoppte. Dieses System wird vom US-Heimschatzuministerium (DHS) sowie der untergeordneten Cybersecurity and Infrastructure Security Agency (CISA) unterstützt. Durch das Ziehen einer Optionsklausel im Vertrag der Förderung durch die US-Regierung, bleibt das MITRE CVE System bis 16.03.2026 am Start. Was danach passiert, kann niemand abschätzen.

Dadurch, dass dieses System seit 1999 im Einsatz ist, hat es sich zum Standard entwickelt. Es ist daher die derzeit aktuellste, kompatibelste und vollständigste Lösung.

Neu aufgedeckte Schwachstellen werden von den CVE Numbering Authorities (CNA) eingepflegt, nummeriert und verwaltet. Die Meldung erfolgt u.a. über ein eigenes Portal. Es können jedoch auch vorgefertigte sowie selbst programmierte Clients verwendet werden. Eine CVE kann bereits vor der Veröffentlichung beantragt werden, und für die Zuweisung erfolgt meist nur eine grobe Prüfung. Eine zugewiesene CVE bedeutet also nicht automatisch, dass ein tatsächliches Risiko besteht. Zu vielen CVEs werden keine Lücken veröffentlicht – so wurden z.B. 2023 ca. 40.000 CVEs reserviert, aber nur ca. 29.000 veröffentlicht.

Die reinen CVE-Nummern bilden nur einen Teil der Anwendungsfälle ab, insbesondere liefern sie nicht unbedingt eine Risikobewertung. Sie bilden aber die Basis für viele darauf aufbauende Datenbanken wie die NVD.

Wird oft mit CVE verwechselt: NIST National Vulnerability Database (NVD)

Die National Vulnerability Database (NVD) wird von der US-Behörde NIST betrieben und oft mit CVE verwechselt. Beide sind auch eng miteinander verknüpft – für jede CVE im Zustand “veröffentlicht” wird automatisch ein Eintrag in der NVD erzeugt. Während die CVE-Datenbank nur rudimentäre Informationen zur Lücke enthält, wird der Eintrag in der NVD noch um weitere Informationen wie einen Risikoscore nach dem Industriestandard Common Vulnerability Scoring System (CVSS) oder Links zu weiteren Informationen ergänzt.

Diese Informationen werden teilweise manuell ergänzt. Im Frühjahr 2024 kam es dabei zu einer Überlastung des zuständigen Teams, und es wurden für mehrere Monate keine Ergänzungen insbesondere auch keine Risikobewertungen eingepflegt. Durch den Einsatz von externen Partnern konnte der Stau aufgelöst und das System resilienter gemacht werden, aber wie bei CVE zeigt der Vorfall, wie stark die NVD vom amerikanischen Bundeshaushalt abhängt.

Die NVD-Daten stehen auch als strukturierte Daten im Security Content Automation Protocol (SCAP) Format zur Verfügung und können ohne Einschränkungen verwendet werden. Daher setzen viele Tools und auch Schwachstellen-Webseiten die NVD-Daten direkt ein oder nutzen sie als Basisdatensatz, der durch eigene Erkenntnisse ergänzt wird. Da die NVD nicht zwingend genannt werden muss, ist der Zusammenhang nicht immer direkt erkennbar.

Fast alle unserer Anwendungsfälle kann die NVD bedienen. Lediglich neue Lücken können nicht direkt bei der NVD gemeldet werden – hier muss eine CVE beantragt werden und damit entsteht automatisch auch der NVD-Eintrag.

CVE Foundation

Die Meldung, dass die US-Regierung die Förderung von MITRE CVE einstellen will, sorgte berechtigterweise für eine Menge Wirbel in der globalen Cybersecurity Szene. Angetrieben durch dieses Ereignis sowie dem schon länger existierenden Wunsch noch neutraler und nachhaltiger auftreten zu können (und nicht an eine Regierung gebunden zu sein) entschieden sich diverse Vorstandsmitglieder des CVE-Systems ihre eigene (non-profit) Stiftung zu gründen, um die Finanzierung des MITRE Programms zu realisieren.

Die CVE Foundation ist daher keine Alternative zu bestehenden Programmen und will es nach unserem Kenntnisstand auch gar nicht werden. Aktuell befindet sich die Stiftung noch im Aufbau – Informationen dazu wie es weitergeht und was die nächsten Schritte sein werden, sind daher rar. In ihren eigenen FAQs werden lediglich einige Fragen zum Auftrag sowie einige der baldigen Vorstände benannt.

Unsere Anwendungsfälle wären bei einer CVE-Stiftung genauso abgedeckt wie bisher. Wenn die Stiftung die bestehende Datenbank und Nummerierung übernehmen würde, gäbe es auch keinen Umstellungsaufwand.

Common Security Advisory Framework (CSAF)

Ein weiterer Name, der in diesen Zusammenhängen immer wieder genannt wurde, ist das Common Security Advisory Framework (CSAF). Dahinter verbirgt sich eine technische Spezifikation für einen verteilten Ansatz. Eine vertrauenswürdige Instanz wie aktuell beispielsweise das Bundesamt für Sicherheit in der Informationstechnik (BSI) pflegt eine Liste von Organisationen, die Sicherheitslücken dokumentieren. Diese wiederum veröffentlichen die Sicherheitslücken in einem strukturierten Format (JSON).

Laut der eigenen FAQ sieht sich CSAF nicht als CVE-Ersatz. Der Standard bietet ein optionales Feld für die CVE-Nummer an, und in der Technischen Richtlinie TR-03191 des BSI ist die CVE-Nummer sogar verpflichtend. In CSAF geht es eher um die Details zu jeder Lücke, man kann CSAF also eher als eine dezentrale Alternative zur NVD-Datenbank betrachten.

Die Anwendungsfälle, in denen die Eindeutigkeit der CVE-Nummer im Vordergrund steht – z.B. als Ordnungsmerkmal im Risikomanagement oder als eindeutige Kennung in der Software Supply Chain – können von CSAF nicht abgebildet werden. CSAF-Dokumente haben zwar eindeutige Kennungen, aber zwei Dokumente können sich auf die gleiche Lücke beziehen.

Als Informationsbasis und insbesondere als Datenbasis für Scan-Tools eignen sich die CSAF-Dokumente dagegen gut. Die CSAF-Seite verzeichnet direkt einige passende Tools. Es gibt jedoch keinen Automatismus wie bei der NVD, der für jede veröffentlichte CVE zumindest einen rudimentären Eintrag erzeugt.

Global CVE Allocation System (GCVE)

Das Global CVE Allocation System (GCVE) ist ein neuer Ansatz vom Computer Incident Response Center Luxembourg (CIRCL), bei dem statt einer zentralen Instanz wie MITRE die Vergabe von IDs für Sicherheitslücken dezentral stattfinden soll. Zwar gibt es im traditionellen CVE-System auch verschiedene Vergabestellen für CVEs – sogenannte CVE Numbering Authorities (CNAs) – jedoch müssen die Vorgaben von MITRE eingehalten werden, und die Vergabe von eindeutigen IDs wird durch die zentrale Instanz gesteuert. Im GCVE wird die ID dazu im Format „GCVE-<GNA ID>-<YEAR>-<UNIQUE ID>“ vergeben. Jeder teilnehmenden Organisation wird eine sogenannte GNA ID zugeteilt, sodass die Organisationen ihren eigenen ID-Bereich unabhängig vergeben können, ohne Überschneidungen hervorzurufen. Es bleibt abzuwarten, ob die Anzahl der aktuell acht teilnehmenden Organisationen steigt und sich auch bekannte Größen dem im Aufbau befindlichen System anschließen.

Für die oben definierten Anwendungsfälle ist es aktuell kaum nutzbar. Nur die vom CIRCL betriebene Datenbank Vulnerability Lookup benutzt derzeit das Schema.

Da die Teilbereiche unabhängig verwaltet werden, wird es Lücken geben, die mehrere GCVE-Nummern von unterschiedlichen GNA erhalten werden. Die GCVE eignet sich dann nicht als eindeutiges Ordnungsmerkmal im Risikomanagement oder in der Software Supply Chain.

European Vulnerability Database (EUVD)

Eigentlich noch im Probebetrieb wurde die europäische Antwort auf die NVD im Zuge der drohenden CVE-Abschaltung kurzerhand öffentlich verfügbar gemacht. Die Datenbank ist noch in der Beta-Phase und soll vor allem die Korrelation aus verschiedenen Datenquellen ermöglichen.

Da so auch Sicherheitslücken aufgenommen werden, die nicht bei der CVE gemeldet wurden, vergibt die European Network and Information Security Agency (ENISA) eigene Nummern, die mit EUVD starten. Aktuell ist das System auf eine Ko-Existenz und eine Abbildung auf CVEs ausgelegt, könnte aber bei einer CVE-Abschaltung auch problemlos weiterbetrieben werden.

Während einzelne neuere Einträge bereits sehr viele Informationen aufweisen, konnten wir in Stichproben immer wieder Einträge finden, die entweder nur die Basis-Daten aus der CVE-Datenbank enthielten oder die im Vergleich zum korrespondierenden NVD-Eintrag viel weniger Details hatten.

Die EUVD ist so ausgelegt, dass alle unsere oben beschriebenen Anwendungsfälle langfristig bedient werden können. Aktuell ist die Datenqualität noch nicht vergleichbar mit der NVD, und nur wenige Tools nutzen die EUVD als Datenbasis. Beides kann sich aber mit der Zeit noch ändern.

Ob die EUVD-Nummern die etablierten CVE-Nummern als eindeutige Kennung ersetzen können, ist noch offen. Da die EUVD Teil der NIS2-Richtlinie der EU ist und von den europäischen Informationssicherheitsbehörden gemeinsam genutzt wird, stehen die Chancen aber zumindest für Europa nicht schlecht.

Single Reporting Platform (SRP) des europäischen Cyber Resilience Act (CRA)

Neben der NIS-2-Richtlinie, die vor allem auf den sicheren IT-Betrieb abzielt, macht die EU im Cyber Resilience Act (CRA) Informationssicherheitsvorgaben für Produkte. Darin sind auch Vorgaben wie Schwachstellen veröffentlicht werden sollen und welche Meldewege die Hersteller ermöglichen müssen.

Eine neue geschaffene Single Reporting Platform (SRP) soll dabei eine zentrale Rolle spielen. Die Erstellung der Plattform wird gerade ausgeschrieben. Daher kann es noch keine konkrete Einschätzung geben, wie sich die SRP auf die Anwendungsfälle auswirkt. Bisher bekannt ist lediglich die Arbeitsteilung zwischen SRP und EUVD: Während die SRP auch unveröffentlichte Schwachstellen für einen beschränkten Empfängerkreis bereitstellen soll, sollen veröffentlichte Schwachstellen aus der SRP direkt in die EUVD aufgenommen werden.

Was müssen Anwender jetzt tun?

Bis März 2026 kann erstmal alles wie bisher bleiben. Es ist jedoch ratsam, sich bereits auf mögliche Alternativszenarien nach dem Datum vorzubereiten.

Für die Nutzung der CVE als eindeutige Kennung (im Risikomanagement, als Hersteller, als Entdecker), kann man bereits jetzt anfangen, zusätzlich eine der alternativen Kennungen wie die EUVD-Nummer zu dokumentieren. Idealerweise spricht man mit Kunden und Lieferanten über die Alternativen und findet vielleicht eine gemeinsame Alternative.

Bei den Scan-Tools und Informationsdiensten (fürs ISMS, Container, Software) sollte man rechtzeitig prüfen, auf welchen Daten sie basieren. Nutzen sie einfach die NVD oder binden sie bereits heute verschiedene Datenbanken (die nicht nur Kopien der NVD sind) an? Möglicherweise müssen Tools und damit die daran hängenden Prozesse ausgetauscht werden, um mehr Datenquellen nutzen zu können.

27. Februar 202527. Februar 2025Allgemein

HiGuide: EU CER RICHTLINIE (EU) 2022/2557

EU CER RICHTLINIE (EU) 2022/2557 des Europäischen Parlaments und des Rates über die Resilienz kritischer Einrichtungen und zur Aufhebung der Richtlinie 2008/114/EG des Rates.

EU Critical Entities Resilience (CER) Richtlinie vom 14. Dezember 20221¹

Die EU Critical Entities Resilience (CER) Direktive (EU) 2022/2557, die am zwanzigsten Tag (16. Januar 2023) nach ihrer Veröffentlichung im Amtsblatt der Europäischen Union (27. Dezember 2022) in Kraft getreten ist, richtet sich an alle EU-Mitgliedstaaten. Diese sind dazu verpflichtet, zur Resilienz von kritischen Einrichtungen bestimmte Maßnahmen zu ergreifen, damit sichergestellt werden kann, dass wichtige Dienste für die Aufrechterhaltung lebenswichtiger gesellschaftlicher Funktionen im Binnenmarkt ungehindert erbracht werden.

Die EU CER-Richtlinie wird in Deutschland als Gesetz zur Umsetzung der Richtlinie (EU) 2022/2557 und zur Stärkung der Resilienz kritischer Anlagen (Kritis-Dachgesetz, KritisDG) umgesetzt. Der aktuelle Gesetzesentwurf² ist vom 27. November 2024.

Der Schwerpunkt der EU Richtlinie liegt auf verschiedene Sektoren und Teilsektoren. Des Weiteren werden die Kategorien der Einrichtungen berücksichtigt. Im Energie- und Verkehrssektor wurden bereits sektorspezifische Rechtsakte der EU geregelt. Die wichtigen Aspekte der Resilienz wurden aber nicht ausreichend in Betracht gezogen und um die Resilienz der kritischen Einrichtungen zu untersuchen, wurde diese EU-Richtlinie als ein allumfassender Rahmen geschaffen. Der Fokus liegt dabei stark auf alle natürlichen oder vom Menschen verursachten, unfallbedingten oder vorsätzlichen Gefahren.

Aufhebung der EU Richtlinie 2008/114/EG

Das Verfahren in der aufgehobenen EU-Richtlinie 2008/114/EG über die Ermittlung und Ausweisung europäischer kritischer Infrastrukturen und die Bewertung der Notwendigkeit, ihren Schutz zu verbessern, adressierte die europäischen kritischen Infrastrukturen im Energie- und Verkehrssektor. Denn Störungen in den Sektoren hätten erhebliche Auswirkungen in mindestens zwei EU-Mitgliedstaaten bewirken können. In einer Evaluierung im Jahr 2019 wurde festgestellt, dass aufgrund von zunehmender grenzüberschreitender Nutzung von kritischen Infrastrukturen, Schutzmaßnahmen für einzelne Bereiche nicht allein ausreichen, um alle Störungen abwehren zu können. Daher wurde ein Ansatz genutzt, bei dem Risiken allumfassend berücksichtigt werden. Deshalb sollen die Aufgaben und Pflichten der kritischen Einrichtungen als Anbieter von Diensten genauer festgelegt werden und kohärent sein. Das ermöglicht den kritischen Einrichtungen, ihre Fähigkeiten und Kenntnisse zu stärken. Dies insbesondere in Bezug auf Erkennung von Sicherheitsvorfällen und das schützen, verhindern, abwehren, bewältigen und die Erholung von solchen Ereignissen.

Einige Maßnahmen wurden bereits auf EU- und nationaler Ebene berücksichtigt und umgesetzt. Dennoch sollte mehr getan werden, damit die Einrichtungen besser in der Lage sind, Risiken zu erkennen und zu handeln. Es wird von einer dynamischen Bedrohungslage ausgegangen, die sowohl hybride als auch terroristische Gefahren und hohe physische Risiken durch Naturereignisse und den Klimawandel umfasst. Die EU-Mitgliedstaaten haben die bisherige EU-Richtlinie nicht ausreichend umgesetzt, weshalb die EU dann aktiv wurde. Die EU CER-Richtlinie soll daher ein einheitliches Niveau schaffen, was die Einstufung der Sektoren angeht. Die bisherige Richtlinie 2008/114/EG war daher unzureichend, um die Ziele zu erreichen und wurde am 18. Oktober 2024 mit Einführung der EU CER-Richtlinie aufgehoben.

ANWENDUNGSBEREICH DER EU CER

Durch die Einführung der EU CER-Richtlinie erhalten die EU-Mitgliedstaaten Vorgaben zur Gewährleistung der Erbringung von Diensten im Binnenmarkt. Das ist insbesondere für die Aufrechterhaltung wichtiger gesellschaftlicher Funktionen oder wirtschaftlicher Tätigkeiten erforderlich. Zusätzlich müssen sie die relevanten kritischen Einrichtungen ermitteln und bei der Umsetzung der EU CER Vorgaben unterstützen.

Die EU-Mitgliedstaaten geben die Beaufsichtigung kritischer Einrichtungen, die Durchsetzungsmaßnahmen, die Ermittlung kritischer Einrichtungen und die Beratungsmissionen zur Bewertung der Maßnahmen vor. Es werden gemeinsame Verfahren für die Zusammenarbeit und Berichterstattung festgelegt. Ausgeschlossen von der Bereitstellung von Informationen der EU-Mitgliedstaaten sind die Bereiche der nationalen Sicherheit, der öffentlichen Sicherheit und die Verteidigung.

STRATEGIEN FÜR DIE RESILIENZ KRITISCHER EINRICHTUNGEN

Die EU-Mitgliedstaaten haben eine zeitliche Frist bis zum 17. Januar 2026, um eine Strategie zur Verbesserung der Resilienz kritischer Einrichtungen zu verabschieden. Die Inhalte der Strategie soll Ziele und politische Maßnahmen umfassen, um ein hohes Resilienzniveau von kritischen Einrichtungen zu festigen und aufrechtzuhalten.

Grundsätzlich enthält jede Strategie wesentliche Elemente, die umgesetzt werden müssen. Zunächst sollen strategische Ziele und Prioritäten zur Verbesserung der Gesamtresilienz kritischer Einrichtungen etabliert werden, unter der Berücksichtigung grenzüberschreitender und sektorübergreifender Abhängigkeiten sowie gegenseitiger Abhängigkeiten. Darüber hinaus sollen Steuerungsrahmen der EU-Mitgliedstaaten festgelegt werden, um die strategischen Ziele und Prioritäten zu verwirklichen. Die Beschreibung der Maßnahmen und des Verfahrens zur Ermittlung der kritischen Einrichtungen ist ebenfalls umzusetzen.

Die jeweiligen Behörden haben Aufgaben und Zuständigkeiten, die beschrieben werden sollen. Das gilt ebenfalls für die kritischen Einrichtungen und die an der Strategie beteiligten Akteure. Zusätzlich sollen die Maßnahmen beschrieben werden, die dazu beitragen, die Gesamtresilienz zu verbessern. Dazu zählt auch das Beschreiben der Verfahren zur Ermittlung kritischer Einrichtungen sowie die Beschreibung der Prozesse zur Unterstützung kritischer Einrichtungen. Maßnahmen zur Verbesserung der Zusammenarbeit zwischen dem öffentlichen Sektor und dem privaten Sektor sind weitere Punkte, die umgesetzt werden sollen.

Eine Dokumentation der wichtigsten Behörden und entsprechenden Interessenvertreter, die an der Umsetzung der Strategie beteiligt sind, soll geführt werden. Zwischen den Behörden der EU CER und den Behörden der EU NIS-2 Richtlinie (EU) 2022/2555 soll es einen politischen Rahmen für die Zwecke des Informationsaustauschs über Cybersicherheitsrisiken, Cyberbedrohungen und nicht cyberbezogene Risiken geben.

Die EU-Mitgliedstaaten sind verpflichtet ihre Strategie alle vier Jahre zu aktualisieren und der EU-Kommission diese Strategien und die Aktualisierungen innerhalb von drei Monaten nach Verabschiedung mitzuteilen.

RESILIENZ UND RESILIENZMASSNAHMEN KRITISCHER EINRICHTUNGEN

Um zu erkennen, welche Risiken die wesentlichen Dienste stören könnten, sollen die kritischen Einrichtungen mindestens alle vier Jahre eine Risikobewertung durchführen. Bei einer bereits vorhandenen Risikobewertung kann diese für die Erfüllung der Anforderungen der EU CER-Richtlinie verwendet werden. Um den Anforderungen der EU CER-Richtlinie gerecht zu werden, haben die zuständigen Behörden die Aufgabe, zu prüfen und zu bestätigen, dass die bereits vorhandene Risikobewertung die gegebenen Anforderungen erfüllt. Bei erfolgreicher Erfüllung der Anforderungen, kann die zuständige Behörde offiziell anerkennen, ob die Vorgaben ganz oder teilweise umgesetzt wurden. Die Maßnahmen zur Gewährleistung der Resilienz der kritischen Einrichtungen soll geeignet, verhältnismäßig, technisch, sicherheitsbezogen und organisatorisch sein. In dem sogenannten Resilienzplan sollen die Maßnahmen beschrieben und angewendet werden. Die kritischen Einrichtungen sollen einen Verbindungsbeauftragten als Ansprechperson für die zuständigen Behörden benennen, während die EU-Kommission Beratungsmissionen organisiert, um die kritischen Einrichtungen zu unterstützen. Außerdem erlässt die EU-Kommission unverbindliche Leitlinien, in denen technische, sicherheitsbezogene und organisatorische Maßnahmen festgelegt sind.

MELDUNG VON SICHERHEITSVORFÄLLEN

Nach einem Sicherheitsvorfall müssen die EU-Mitgliedstaaten sicherstellen, dass die kritischen Einrichtungen der zuständigen Behörde rechtzeitig den Vorfall melden. Die erste Meldung soll spätestens 24 Stunden nach dem Auftreten und Bemerken des Sicherheitsvorfalls übermittelt werden.

Nach einem Monat soll es einen ausführlichen Bericht über den Sicherheitsvorfall geben. Dabei soll die Anzahl der von der Störung betroffenen Nutzenden, die Dauer der Störung und das betroffene geografische Gebiet der Störung berücksichtigt werden. Im Fall, dass der Sicherheitsvorfall in mehr als sechs EU-Mitgliedstaaten erhebliche Auswirkungen hatte, wird der Sicherheitsvorfall von den zuständigen Behörden der EU-Kommission gemeldet.

Die Meldung des Sicherheitsvorfalls muss entsprechende Informationen enthalten, so dass die zuständige Behörde über die Art, Ursache und die möglichen Folgen nachvollziehen und ermitteln kann. Darüber hinaus muss sie auch Informationen enthalten, die insbesondere für die Bestimmung erforderlich sind, ob der Vorfall grenzüberschreitende Auswirkungen hat. „Solche Meldungen begründen keine höhere Haftung der betreffenden kritischen Einrichtungen.“³

Die betroffenen kritischen Einrichtungen werden nach der Meldung des Vorfalls von den zuständigen Behörden über sachdienliche
Folgeinformationen informiert, damit sie unterstützt werden. Die zentralen Anlaufstellen tragen die Verantwortung für die Sicherheit der Informationen, indem sie sich an das Unionsrecht halten oder die Informationen nach nationalem Recht behandeln.

¹ https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32022L2557
² https://dserver.bundestag.de/btd/20/139/2013961.pdf
³ EU CER Richtlinie 2022/2557 vom 14.Dezember 2022 (Art.15 Abs.2 S.2)

23. Januar 202523. Januar 2025Allgemein, Penetrationstest, Risikomanagement

USB-Schnittstellen unter Windows absichern

Im Rahmen von Windows Client Audits untersuchen wir, ob Härtungsmaßnahmen gegen typische Angriffe über USB-Schnittstellen umgesetzt wurden. Grundsätzlich kann ein Angreifer ungeschützte USB-Schnittstellen zum Ausleiten von Daten (Exfiltration) oder zum Einleiten/Ausführen von Daten bzw. Code missbrauchen.

Das Ausleiten von Daten über USB (TA0010) geschieht typischerweise durch den Anschluss eines Wechselmediengeräts, wie z. B. Speichersticks oder externe Festplatten (T1052). Jedoch können ebenso eher untypische Geräte wie externe CD/DVD-Laufwerke angeschlossen werden, die zur Exfiltration von Daten missbraucht werden können.

Externe Hardware birgt gleichwohl die Gefahr, dass darüber Daten bzw. Schadcode auf das Client-System gelangt und dort ausgeführt wird (TA0002). In der Praxis kann dies bspw. ein mit Malware präparierter USB-Speicherstick sein, welcher von unachtsamen Mitarbeitern angeschlossen und dessen Inhalt anschließend ausgeführt wird (T1059). Alternativ kann der Angriff über ein „BadUSB“-Device erfolgen (T1204). Ein typischer Vertreter dieser Gattung ist der sogenannte RubberDucky. Dabei handelt es sich um eine als USB-Speicherstick getarnte Tastatur, welche in der Lage ist, vorprogrammierte Tastatureingaben automatisiert und in schneller Abfolge auszuführen. Die Größe der Daten, die mittels RubberDucky auf das System „übertragen“ werden können, ist zwar beschränkt. Es ist jedoch problemlos möglich, Schadcode aus dem Internet nachzuladen und diesen auf dem Client zur Ausführung zu bringen.

Um den Risiken der Datenaus- und -einleitung zu begegnen, bietet Windows verschiedene Möglichkeiten, welche nachfolgend vorgestellt werden.

Lese- und Schreibe-/Schreibzugriff auf Wechselmedien einschränken: Nutzer können zwar Wechselmedien-Geräte anschließen jedoch wird der Lese- oder/und Schreibzugriff auf Medien beschränkt.
Installation von Wechselmedien-Geräten beschränken: Die Installation von Gerätetreibern bestimmter Wechselmedien-Geräteklassen, bspw. WPD-Geräte (Smartphones), wird unterbunden. Dadurch ist keine Nutzung dieser mehr möglich.
Installation von Tastaturen beschränken: Die Installation von Gerätetreibern für unbekannte Tastaturen wird unterbunden. Angriffe durch BadUSB-Geräte, welche Tastaturen simulieren, ist dadurch nicht mehr möglich.

Die folgende Grafik stellt den Zusammenhang zwischen Angriffstaktiken bzw. -techniken und den passenden Maßnahmen noch einmal visuell dar:

Ausnutzung des Angriffsvektors "USB-Schnittstelle" und Schutzmaßnahmen

In diesem Artikel erfahren Sie, welche Einstellungen Sie vornehmen müssen, um die genannten Beschränkungen über Active-Directory-Gruppenrichtlinien unternehmensweit auszurollen.

1. Lese- und Schreibe-/Schreibzugriff auf Wechselmedien einschränken

Beim Begriff „Wechselmedium“ denkt man meist als erstes an USB-Speichersticks oder externe Festplatten. Tatsächlich sind diese in der Windows-Welt jedoch nur zwei Vertreter der Wechselmedienklasse „Wechseldatenträger“. Windows unterscheidet insgesamt zwischen diesen fünf Wechselmedienklassen:

CD und DVD
Diskettenlaufwerke
Wechseldatenträger (z. B. USB-Sticks, externe Festplatten)
Bandlaufwerke
WPD-Geräte (z. B. MTP-fähige Geräte wie Smartphones)

In Penetrationstests stellen wir häufig fest, dass Kunden nur den Zugriff auf die offensichtliche Wechselmedienklasse „Wechseldatenträger“ eingeschränkt haben. Dadurch lassen sich zwar keine Daten von USB-Sticks transferieren, jedoch ist es weiterhin möglich, bspw. externe CD- und DVD-Laufwerke anzuschließen, um darüber Daten auszutauschen.

Wenn Sie den Lese- oder Schreibzugriff auf Wechselmedienklassen hinreichend beschränken wollen, müssen Sie dies für alle (ihren Unternehmensrichtlinien entsprechenden) Wechselmedienklassen tun. Folgen Sie den nachfolgenden Schritten, um Lese- und Schreibzugriffe auf Wechselmedien über Active-Directory-Gruppenrichtlinien zu verwalten:

Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
Navigieren Sie zum Pfad:
Computerkonfiguration -> Administrative Vorlagen -> System -> Wechselmedienzugriff
Die sicherste Methode ist es, den Lese- und Schreibzugriff auf alle Wechselmedienklassen zu unterbinden. Aktivieren Sie dazu die Einstellung „Alle Wechselmedienklassen: Jeglichen Zugriff verweigern“:

Möchten Sie lediglich Schreiboperationen auf Wechselmedien verhindern, aktivieren Sie stattdessen die Option „Alle Wechselmedienklassen: Schreibzugriff verweigern“.

Überprüfen Sie den Zugriff auf ein Wechselmedium Ihrer Wahl, z. B. einen USB-Speicherstick, in dem Sie diesen an den Windows Client anschließen und versuchen, Daten zu schreiben und zu lesen.

Häufig stehen Administratoren allerdings vor dem Dilemma, dass zwar der Anschluss von beliebigen Wechselmedien unterbunden werden soll, es jedoch Ausnahmen geben muss. Eine typische Anforderung ist, dass der Windows Client den Anschluss beliebiger Wechselmedien unterbinden muss, es sei denn, es handelt sich um einen USB-Speicherstick der Marke / des Modells „XYZ“.

Um dies umzusetzen, muss die Gerätetreiber-Installation von Wechselmedienklassen beschränkt werden. Mehr dazu im folgenden Abschnitt.

2. Installation von Wechselmedien-Geräten beschränken

Falls Sie den Anschluss von unerlaubten Wechselmedien verhindern möchten, bietet es sich an, die Gerätetreiber-Installation unbekannter Wechselmedien-Geräte zu deaktivieren. Dadurch werden diese nicht mehr vom Windows gemountet und können folglich nicht geschrieben oder gelesen werden. Lediglich Geräte, deren Hardware-ID hinterlegt wurde, können noch angeschlossen und verwendet werden (Whitelisting-Ansatz). Die hinterlegte Hardware-ID kann sich z. B. auf ein bestimmtes Gerät, ein Model oder einen Hersteller beziehen.

Gehen Sie dazu wie folgt vor:

Bestimmen Sie die Hardware-ID des Wechselmediengeräts, deren Installation Sie zulassen möchten.
Schließen Sie bspw. den USB-Speicherstick an einen Windows Client an, und öffnen Sie den Gerätemanager (devmgmt.msc). Suchen Sie den USB-Speicherstick unter dem Reiter „Laufwerke“. Öffnen Sie dessen Eigenschaften. Wechseln Sie zu Details -> Hardware-IDs und notieren Sie eine der IDs.
Im folgenden Beispiel haben wir uns für USBSTOR\DiskJetFlash entschieden, da wir alle Modelle des USB-Speichersticks freigeben wollen, auch die mit einer anderen Speichergröße als 8 GB:

Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
Navigieren Sie zum Pfad:
Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteinstallation -> Einschränkungen bei der Geräteinstallation
Aktivieren Sie die Option „Anwenden einer übergeordneten Reihenfolge für Zulassen und Verhindern-Geräteinstallationsrichtlinien für alle Geräteübereinstimmungskriterien“. Regulär wird zunächst die Installation von Geräten verboten und dann erlaubt (deny, allow). Durch die Aktivierung dieser Eigenschaft wird die Reihenfolge auf „allow, deny“ umgekehrt.
Aktivieren Sie die Option „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die folgenden GUID-Werte, einschließlich der geschweiften Klammern, ein (GUID-Übersicht):
- {4d36e965-e325-11ce-bfc1-08002be10318} (CD- und DVD-Laufwerke)
- {4d36e980-e325-11ce-bfc1-08002be10318} (Diskettenlaufwerke)
- {4d36e967-e325-11ce-bfc1-08002be10318} (Laufwerke für Wechseldatenträger, wie z. B. USB-Speichersticks oder externe Festplatten)
- {6d807884-7d21-11cf-801c-08002be10318} (Bandlaufwerke)
- {eec5ad98-8080-425f-922a-dabf3de3f69a} (WPD-Geräte, wie z. B. Smartphones)

Hinweis: Wechselmedien-Geräte die vor dem Aktivieren der Einstellung installiert wurden, können auch danach weiter genutzt werden. Wenn Sie dies verhindern möchten, aktivieren Sie die Einstellung „Auch auf übereinstimmende Geräte anwenden, die bereits installiert sind“. Wir empfehlen diese Einstellungen nur mit Vorsicht zu verwenden, da dies dazu führen kann, das bestehenden Verbindungen zu wichtigen externen Datenträgern nicht mehr funktionieren!

Hinweis 2: Die Empfehlung aus der offiziellen Microsoft-Dokumentation nur die GUIDs {36fc9e60-c465-11cf-8056-444553540000} (USB-Host-Controller und USB-Hubs) und {88BAE032-5A81-49f0-BC3D-A4FF138216D6} (USB-Geräte die nicht zu einer anderen Klasse gehören) hier einzutragen, ist unvollständig. Dadurch können bspw. weiterhin WPD-Geräte, wie Smartphones, angeschlossen werden. Wir empfehlen daher die oben genannten Geräteklassen-GUIDs zu verwenden.

Aktivieren Sie die Option „Installation von Geräten mit diesen Geräte-IDs zulassen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die Hardware-ID(s) ein, welche Sie zulassen möchten (siehe Schritt 1):

Die finale Konfiguration sollten nun wie folgt aussehen:

Prüfen Sie, ob die Einstellung Wirkung zeigt, in dem Sie einen zweiten USB-Speicherstick (mit abweichender Hardware-ID) anschließen, den Sie zuvor noch nie an das System angeschlossen haben. Das Gerät sollte daraufhin nicht installiert werden.

Sollten sich der Speicherstick wider Erwarten installieren lassen, öffnen Sie den Geräte-Manager und suchen Sie den angeschlossene Speicherstick unter „Laufwerke“. Klicken Sie mit der rechten Maustaste auf den Eintrag und wählen Sie „Gerät deinstallieren“:

Dadurch wird der gerade installierte Treiber wieder deinstalliert. Danach können Sie das Gerät abziehen.

Prüfen Sie anschließend Ihre vorgenommenen Einstellungen auf Korrektheit und probieren Sie erneut, den Speicherstick anzuschließen.

3. Installation von Tastaturen beschränken

Geräte die sich als USB-Tastaturen ausgeben, wie der allseits bekannte RubberDucky, um dadurch bösartige Eingaben durchzuführen und Code nachzuladen, stellen ebenfalls ein Risiko dar. Bei diesen „BadUSB“-Angriffen handelt es sich um einen Seitenkanal-Angriff, bei dem die Fähigkeiten von Keyboard-Devices dazu missbraucht werden, Daten und Code auf dem Zielgerät zu platzieren bzw. zur Ausführung zu bringen.

Vor dem Anschluss von BadUSB-Geräten kann man sich schützen, indem man wie im vorigen Kapitel auch, eine Liste für den Anschluss zugelassener Tastaturen im Windows hinterlegt (Whitelisting) und den Anschluss anderer Tastaturen verbietet.

Um den Anschluss von Tastatur-Geräten einzuschränken, gehen Sie wie folgt vor:

Bestimmen Sie die Hardware-ID der Tastatur, deren Installation Sie zulassen möchten.
Öffnen Sie den Gerätemanager (devmgmt.msc). Suchen Sie die angeschlossene Tastatur unter dem Reiter „Tastaturen“. Öffnen Sie deren Eigenschaften. Wechseln Sie zu „Details -> Hardware-IDs“ und notieren Sie sich die Hardware-IDs der Tastaturen, die sie freigeben möchten. In der folgenden Abbildung ist dies ID HID\VID_046A&UP:0001_U:0006, was einer beliebigen Cherry-Tastatur entspricht. Um die Installation von beliebigen Logitech-Tastaturen zu erlauben, müsste bspw. die ID HID\VID_046D&UP:0001_U:0006 (mit einem „D“ statt einem „A“) freigegeben werden:

Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
Navigieren Sie zum Pfad:
Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteinstallation -> Einschränkungen bei der Geräteinstallation
Aktivieren Sie die Option „Anwenden einer übergeordneten Reihenfolge für Zulassen und Verhindern-Geräteinstallationsrichtlinien für alle Geräteübereinstimmungskriterien“. Regulär wird zunächst die Installation von Geräten verboten und dann erlaubt (deny, allow). Durch die Aktivierung dieser Eigenschaft wird die Reihenfolge auf „allow, deny“ umgekehrt.
Aktivieren Sie die Option „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier den Wert {4D36E96B-E325-11CE-BFC1-08002BE10318} ein. Dieser entspricht die GUID der Geräteklassen „Tastaturen“ (GUID-Übersicht).

Hinweis: Tastaturen, die vor dem Aktivieren der Einstellung installiert wurden, können auch danach weiter genutzt werden. Wenn Sie dies verhindern möchten, aktivieren Sie die Einstellung „Auch auf übereinstimmende Geräte anwenden, die bereits installiert sind“. Wir empfehlen diese Einstellungen nur mit Vorsicht zu verwenden, da dies dazu führen kann, dass bspw. auch integrierte Laptop-Tastaturen nicht mehr verwendet werden können!

Aktivieren Sie die Option „Installation von Geräten mit diesen Geräte-IDs zulassen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die Hardware-ID(s) ein, welche Sie zulassen möchten (siehe Schritt 1):

Prüfen Sie, ob die Konfiguration Wirkung zeigt, in dem Sie eine von ihrer Hardware-ID abweichende Tastatur (oder einen RubberDucky) anschließen, die Sie zuvor noch nie an das System angeschlossen haben. Das Gerät sollte nicht installiert werden.

Sollte sich die Tastatur dennoch anschließen und bedienen lassen, gehen Sie wie am Ende von Kapitel „Installation von Wechselmedien beschränken“ beschrieben vor, um den Gerätetreiber wieder zu deinstallieren.

Quellen:

Anleitung zur Beschränkungen von USB-Schnittstellen:

Taktiken und Techniken aus dem MITRE ATT&CK Framework:

Hak5 RubberDucky:

https://shop.hak5.org/products/usb-rubber-ducky

WPD und MTP:

Hardware-IDs:

Geräteklassen-GUIDs:

16. Januar 202516. Januar 2025Allgemein, Forensics

Wie funktioniert eigentlich Malware auf Handys?

Dass einige Staaten unliebsame Journalisten und Oppositionelle über Mobilgeräte überwachen, ist mittlerweile keine große Neuigkeit mehr. Oftmals wird die israelische Firma Cellebrite in dem Kontext genannt. Wie genau dieser Prozess abläuft, wird von Amnestys SecurityLab [1] am Beispiel NoviSpy beschrieben. Neben den technischen Details, die natürlich für die IT-Security Community spannend sind, ist insbesondere die Art der initialen Kompromittierung fundamental für die Entwicklung des eigenen Threat Models.

Werden Mobilgeräte (oder überhaupt technische Geräte) durch einen Dritten in einen anderen Raum geschafft, beispielsweise bei einer Grenzkontrolle, so kann man davon ausgehen, dass diese Geräte möglicherweise kompromittiert sind. Erst nach ausreichender Untersuchung sollten solche Geräte wiederverwendet werden. Warum diese Untersuchungen nicht durch Hersteller wie Apple angeboten werden, kann man auf techcrunch [2] nachlesen.

Bei IT-Sicherheit wird oft als Erstes an Windows-Clients, Firewalls und Ransomware gedacht. Aber unsere kleinen Taschencomputer haben einen oft unterschätzten Anteil an unserem täglichen Leben, sei es privat oder bei der Arbeit. Auch dort sollte das Thema Sicherheit bedacht werden.

[1] https://securitylab.amnesty.org/latest/2024/12/serbia-a-digital-prison-spyware-and-cellebrite-used-on-journalists-and-activists/

[2] https://techcrunch.com/2024/12/20/why-apple-sends-spyware-victims-to-this-nonprofit-security-l

12. Dezember 2024Allgemein

Lageberichte und Erkenntnisse aus dem Jahr 2024

Wie jedes Jahr beglücken uns das BSI und ähnliche Organisationen mit ihren Lageberichten und Erkenntnissen. Welche Defekte in diesem Jahr besonders häufig in Software festgestellt wurden, kann man der Top 25 CWE (Common Weakness Enumeration) von MITRE entnehmen.

Ein beunruhigender Trend ist die ungewöhnlich häufige Nutzung von 0-day-Schwachstellen durch Ransomware-Gruppen. So kommt nun zu der mittlerweile hoffentlich bekannten Empfehlung, Patches zeitnah einzuspielen, die Frage hinzu, wie man mit 0-days umgeht. Eine Lösung: Security by Design. Auch wenn es sich dabei meist um sicheres Architekturdesign im Software Engineering handelt, kann und sollte dieses Prinzip beim Thema Netzwerkarchitektur ebenfalls bedacht werden. Im Rahmen einer Risikoanalyse werden für jede Komponente die Gefahr einer Kompromittierung und weiteren Bewegung möglicher Angreifer erörtert und entsprechende Maßnahmen getroffen. Oftmals hört man in diesem Kontext Begriffe wie „Zero Trust“ und „Defense-in-Depth“. Die so erreichte Resilienz schützt auch gegen bisher unbekannte Lücken in vielfältig ausgenutzten Komponenten wie z. B. VPN-Zugängen.

Gerade in Deutschland konnten wir auch erleben, welche Auswirkungen diese Angriffe auf die Supply-Chain und Dienstleister haben. Der Vorfall bei der Südwestfalen-IT ist zwar nicht der erste seiner Art, mit circa 1,7 Millionen Betroffenen aber einer der Größeren. Mit der zunehmenden Digitalisierung wächst auch die Abhängigkeit und damit die mögliche Auswirkung solcher Angriffe. Nicht umsonst möchte der Gesetzgeber mit NIS-2 gegensteuern.

Es bleibt abzuwarten, ob sich diese Trends im Jahr 2025 fortsetzen werden, oder ob uns etwas ganz Neues überraschen wird. Klar ist, dass IT-Sicherheit auch im nächsten Jahr ein wichtiges Thema bleibt.

https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/Lagebericht2024.pdf?__blob=publicationFile&v=5

16. Oktober 202416. Oktober 2024Allgemein

SAP auf Allzeithoch Drängt Kunden in die Cloud

Von Lorenz Müller, HiSolutions AG

SAP strukturiert weiterhin massiv um: Für die SAP Business Suite ist die Nachfolgerin SAP S/4HANA längst da. Das Ende der Mainstream-Wartung naht, die Migration scheint unausweichlich. Und mit der Fokussierung auf die Cloud stellt sich SAP selbst neu auf.

Die Dynamik, mit der SAP seine Konzern- und Produktpolitik betreibt, beeindruckt. On-Premise-Angebote wurden drastisch verteuert – auch, um SAP-Kunden in die Cloud zu drängen. Mit dem Private Cloud-Komplettpaket RISE with SAP und mit Grow with SAP für Public Cloud bietet SAP eine neue Form der Cloud-Transformation an. Das Subskriptionsmodell bringt Kunden in eine Dauerabhängigkeit und generiert SAP beständig profitable Umsätze. Das flexiblere Lizenzmodell stellt Cloud- gegenüber On-Premise-Kunden deutlich besser. Dabei sind die Vertragsmodelle wie auch die Transformation selbst hochkomplex und bieten viele Risiken und Nebenwirkungen – bis hin zum notwendigen IT-Umbau.

Die Ankündigung, Innovationen wie die Nutzung künstlicher Intelligenz und Nachhaltigkeitsreporting nur noch in den SAP-eigenen Cloudangeboten gegen Mehrpreis zur Verfügung zu stellen, düpierte und verunsicherte Kunden wie Partner. Die Folge: Noch mehr Druck, den Wechsel in die SAP-Cloud anzugehen.

Offenbar sind bisher weniger zu SAP S/4HANA migriert als geplant. Die Cloud-Angebote wurden nicht im erwünschten Umfang angenommen. Bereits getätigte Investitionen in On-Premise-Software wurden nicht angerechnet, bis Anfang 2024 der nächste Schachzug in Form eines neuen Bonus- und Rabattprogramms folgte: Mit „RISE with SAP Migration and Modernization“ sollen Kunden eingeladen werden, eine Cloud First-Geschäftsstrategie auf SAP-Basis zu entwickeln.

Unaufhaltsam verstärkt SAP weiter den Druck: Bereits seit September letzten Jahres erhalten viele Kunden über die Standardrabatte hinaus nicht mehr die in der Vergangenheit regelmäßig gewährten zusätzlichen Rabatte. SAP will mit dieser De-Facto-Verteuerung Bestandkunden den Erwerb benötigter On-Premise-Lizenzen zusätzlich vergällen und zum Umstieg auf SAP RISE Cloudlösungen bewegen – und damit den Profit erhöhen. Neukunden wurde der Erwerb von On-Premise-Lizenzen mit Hinweis auf die Cloudangebote bereits mehrfach verwehrt.

Inzwischen hat SAP das RISE-Umstiegsprogramm durch Verlängerung des Eilzuschlags noch attraktiver gestaltet: Bei Abschluss eines entsprechenden Vertrags bis Ende September 2024 gibt es zusätzlich zu den 45 % für ECC-Kunden (max. 3 Mio. €) bzw. 60 % für S/4-Kunden (max. 6 Mio. €) Migration Credit als Gutschriften, weitere 25 % Turbo-Uplift – was im Einzelfall sehr viel Geld sein kann! Dazu kommen oft noch hohe Subventionen der Hyperscaler. Über 5.200 Kunden haben nach aktuellen Angaben von SAP bereits Private-Cloud -SAP-Verträge abgeschlossen.

Wenn Sie noch nicht in fortgeschrittenen Gesprächen mit SAP sind, ist ein Vertragsabschluss bis September 2024 kaum realistisch. Wir empfehlen Ihnen dennoch unbedingt, sich kurzfristig mit RISE/GROW with SAP auseinanderzusetzen, um mögliche wirtschaftliche und strategische Nachteile für Ihr Unternehmen zu vermeiden – zumal das Programm bis Ende 2024 begrenzt ist.

Der SAP-CEO Christian Klein betreibt seit mehr als einem Jahr auch die Umgestaltung des Unternehmens – hin zu mehr Public Cloud, zu KI – und zum Abbau von 10.000 „Altjobs“. Primär, um den Börsenwert von SAP signifikant zu erhöhen, und um seinen Job zu retten. Denn die Unzufriedenheit der Beschäftigten von SAP steigt: Fast die Hälfte traut Klein laut aktueller Befragung nicht mehr zu, SAP in die Zukunft zu führen.
Dafür gibt es mehrere Gründe: Der Vorstandschef führt autoritär, beordert die Belegschaft zurück ins Büro und will ein Bewertungssystem einsetzen, um Low Performer zu identifizieren. SAP steckt in der Transformation. All das kannten die erfolgsverwöhnten SAP´ler bislang so nicht.

10.000 langjährig SAP-erfahrene (und vermutlich kritische) Mitarbeiter freizusetzen zugunsten günstigerer, unerfahrener und loyaler Mitarbeiter – wie wird das SAP verändern? Wo es doch bereits heute für Kunden schwierig ist, qualifizierten Support und Weiterentwicklung der Software zu erhalten, da erfahrene Ressourcen fehlen.

Ab 2025 rechnet SAP mit rund 200 Millionen Euro weniger Kosten als bisher geplant. Dadurch soll auch das Ergebnis vor Zinsen und Steuern (Ebit) entsprechend steigen: SAP plant nun mit 10,2 Milliarden Euro, bislang waren es 10,0 Milliarden.

Die Produktstrategie von Christian Klein ist klar: In aktuellen Präsentationen wird immer mit Grow with SAP die Public Cloud als Ziel gesetzt, RISE with SAP als Übergang, sofern Grow (noch) nicht möglich ist. Und dazu KI.

Die Börse hat dies alles und auch die euphorischen Quartalsergebnisse des 2. Quartals honoriert (das operative Ergebnis stieg um 33 % auf 1,94 Milliarden Euro – ein Plus von 33 %). Analysten hatten lediglich mit einem Anstieg um 24 % gerechnet: der Börsenkurs ist in den letzten 12 Monaten um fast 60 % auf nahezu 200 € pro Aktie gestiegen.

SAP-Cloud oder passendere Alternativen? Prüfen Sie zeitnah!

Vor dem neuen Programm gab es beim Abschluss von Cloud-Verträgen nie Anrechnungen für getätigte On-Premise-Lizenzkäufe – daher verändert dies das Momentum nun nochmal deutlich zugunsten von RISE with SAP.

Die SAP SAM-Experten von HiSolutions haben in den letzten Jahren viele Unternehmen beim Wechsel in die SAP-Cloud begleitet. Andererseits erwies sich bei einer mindestens ebenso großen Zahl von Kunden die SAP-Cloud als nicht wirtschaftlich oder unpassend. Daraufhin wurden gemeinsam zukunftsfähige Alternativen gesucht, gefunden, bewertet und auf den Weg gebracht.
Dies ist hochkomplex. Es berührt die elementaren Grundlagen Ihrer IT und Ihres Unternehmens. Es geht dabei um Millionen. Die meisten Unternehmen haben für diese einmalige Transaktion nicht die erforderliche Erfahrung und Expertise. Darum ist Rat und Unterstützung von seriösen und erfahrenen SAP Lizenz- und -Vertragsberatern einzuholen.
Sprechen Sie gerne mit uns: kostenfrei, unverbindlich – und ohne Risiken und Nebenwirkungen.

Lorenz Müller

– Principal ITM –

____________________________________________

HiSolutions AG | Schloßstraße 1 | 12163 Berlin

Fon: +49 30 533 289-0 | Fax: +49 30 533 289-900 I Mobil: +49 173 3756895

lmueller@hisolutions.com| https://www.hisolutions.com

Mindestinformationen im geschäftlichen E-Mail-Verkehr nach § 80 AktG:

Sitz der Gesellschaft / registered office: HiSolutions AG, Schloßstraße 1, 12163 Berlin

Handelsregistereintrag / Commercial register: Amtsgericht Berlin Charlottenburg – HRB 80155

Vorstand / Management Board: Torsten Heinrich, Prof. Timo Kob, Michael Langhoff

Vorsitzender des Aufsichtsrates / Chairman of the supervisory board: Dr. Andreas Resch

26. September 2024Allgemein

Sind 17 Jahre noch Echtzeit?

Linux und Echtzeit – für einige ist das ein Widerspruch, während andere schon seit Jahren die Real-Time-Linux-Patches nutzen. Hintergrund ist, dass der Hauptzweig des Linux-Kernel über die Jahre zwar viele Änderungen für Echtzeitfähigkeit erfahren hat, aber ohne die separat gepflegte Patch-Sammlung harte Echtzeitanforderungen nicht garantiert werden konnten. Im September ist jetzt ein großer Teil dieser Patches in den Hauptzweig übernommen worden und damit ein viele Jahre währender Prozess nah ans Ziel gekommen.

Es gibt allerdings immer noch Spezialfälle, in denen nicht garantiert werden kann, dass der Kernel alles stehen und liegen lässt, um auf ein Ereignis innerhalb der vorgegebenen Zeit reagieren zu können. Es stehen also noch weitere Entwicklungsaufwände an, die vor allem durch eine fehlende Finanzierung ausgebremst werden. Denn obwohl schon jetzt viele Hersteller Echtzeit-Linux in ihren Geräten nutzen, kommt nicht genug Geld bei den Entwicklern an.

Diese Diskrepanz zwischen der Wertschöpfung der Nutzer von Open-Source-Software und der Finanzierung der Entwicklung ist eine grundsätzliche Herausforderung für das Open-Source-Ökosystem. Mit Stiftungen wie der Linux Fundation wird dagegen gesteuert. Mit dem Sovereign Tech Fund gibt es in Deutschland sogar ein staatlich finanziertes Unterstützungsangebot, das auch die Verbesserung der Sicherheit zum Ziel hat. Dabei gibt es verschiedene Angebote von Bug-Bounty-Programmen bis zu Stipendien für Entwickler.

Die „Contribute Back Challenge“ richtet sich an Open-Source-Software einsetzende Firmen, die ihren Mitarbeitern Zeit für die Weiterentwicklung einräumen. Das lohnt sich natürlich vor allem, wenn man ohnehin eine eigene Entwicklungsabteilung unterhält. Aber unabhängig von der Challenge kann man auch schon mit kleinen Beiträgen etwas zurückgeben: vom Ausprobieren von Testversionen bis hin zur aktiven Teilnahme in den Online-Communities.

Haben Sie sich schon einmal in Ihrem Unternehmen umgeschaut, ob Sie in der Open-Source-Community aktive Kollegen haben?

P.S.: Eine Reaktion nach 17 Jahren kann übrigens nach der formalen Definition Echtzeit sein, etwa wenn die garantierte Reaktionszeit 20 Jahre war.

25. Juli 202426. Juli 2024Advisories, Allgemein, Penetrationstest, Schwachstelle

Schwachstelle öffnet Türen in mehr als 3.000 Hotels

Es mag bequem klingen: Die Zimmertür im Hotel lässt sich ganz ohne Schlüssel oder Karte vom Smartphone aus entriegeln. Doch was passiert, wenn die Logik eines solchen Systems nicht ausreichend abgesichert ist?

Zimmertüren von Hotels aus über 25 Ländern ließen sich mit einer neu entdeckten Schwachstelle öffnen. Bequem? Ja, über das Internet und ohne Zugangsdaten. Dazu konnten sämtliche Reservierungsinformationen (u. a. Name, E-Mail, Reservierungszeitraum und Raumnummer) eingesehen werden. Doch wie kam es dazu?

Zusammenfassung

Die Firma straiv ist ein innovativer und digitaler Begleiter für Hotelbranchen. Als solcher bieten sie unter anderem Online-Check-ins und digitale Türöffnungen an. Was den Sicherheitsforschern Björn Brauer, Deniz Adrian und David Mathiszik bei einem Hotelbesuch jedoch auffiel: Angreifenden wäre es dank einer fehlerhaften Zugangskontrolle in der API möglich, den Check-in und das Öffnen von Türen auch ohne Autorisierung über das Internet zu bedienen.

Im Rahmen einer vertraulichen Offenlegung (engl. Responsible Disclosure oder auch Coordinated Vulnerability Disclosure – CVD) wurden die technischen Details daraufhin direkt an den Hersteller übermittelt. straiv reagierte zeitnah und behob die Sicherheitslücke in ihrer Anwendung umgehend.

Dank ihres Software-as-a-Service-Ansatzes konnte das Unternehmen das Sicherheitsrisiko zeitgleich für alle Kunden mitigieren. Es wird daher auch keine CVE-ID für diese Schwachstelle vergeben. Die Veröffentlichung der Schwachstelle erfolgt in Abstimmung mit dem Hersteller frühestens einen Monat nach der erfolgreichen Behebung.

Die Ursache: Broken Access Control

Broken Access Control belegt aktuell Platz 1 unter den beliebtesten (lies: häufigsten) Schwachstellen in Webanwendungen (siehe: A01:2021 – OWASP Top 10). Auch hier war eine fehlerhafte Zugriffskontrolle die Ursache.

Für gewöhnlich erhalten Gäste eine E-Mail mit einem Link zu ihrer Reservierung. Über diesen werden sie auf die Webanwendung von straiv weitergeleitet. Dort können Buchungsinformationen, die Reisedaten und alle Begleiterprofile eingesehen werden. Ein weiterer Menüreiter führt zu den digitalen Zimmerschlüsseln. Darüber kann die Zimmertür während des eigenen Buchungszeitraums gesteuert werden. Dies geschieht über die API von straiv.io.

Normale API-Anfragen schienen mindestens durch einen HTTP-Header (X-Token), einen Code (cryptcode) und die Reservierungsnummer (reservation) geschützt zu werden. Wurde auch nur einer der Werte verändert, so wurde der Zugriff erwartungsgemäß verwehrt. Fehlten jedoch alle Werte gleichzeitig, wurde nur noch die Reservierungsnummer interpretiert.

In der folgenden beispielhaften Anfrage wurden sämtliche Authentifizierungsparameter, bis auf die Reservierungsnummer, leer gelassen und die API antwortete dennoch mit Informationen zur Reservierung.

POST /api/v2/auth HTTP/2
Host: start.straiv.io
X-Token:
X-Code:
X-Version: 12.3.0
Content-Type: application/json
{
    "cryptcode":"",
    "platform":"linux",
    "browser":"Firefox",
    "version":"115.0",
    "tokens":[],
    "reservation":"3XXXXX"
}

Das Ergebnis enthielt neben anderen Informationen auch einen validen token, der für weitere API-Anfragen genutzt werden konnte.

So lieferte der folgende API-Aufruf noch mehr Kundendetails:

GET /api/v2/vblo/pms/reservation?reservation_id= HTTP/2
Host: start.straiv.io
Accept: application/json, text/plain, */
X-Token: sXXXXXXXXXXXXXXXXXXXh
X-Code: XXXX
X-Version: 12.3.0

Statt die API zu verwenden, kann auch die remote_url aus der Antwort der ersten API-Anfrage verwendet werden, um bequem über die Webanwendung auf die Reservierung zuzugreifen:

HiSolutions hat keine Enumeration von Nutzerdaten durchgeführt und über das Abschätzen der Auswirkungen dieser Schwachstelle hinaus nicht mit der API oder den Buchungen interagiert. Prinzipiell standen alle Funktionalitäten des legitimen Benutzers uneingeschränkt zur Verfügung.

Mitigation

Für die Kunden von straiv bestand kein weiterer Handlungsbedarf. Die Sicherheitslücke wurde von den Entwicklern ernst genommen und umgehend geschlossen.

Grundsätzlich lassen sich Fehler dieser Art durch folgende allgemeine Empfehlungen verhindern:

Vertrauen Sie keinen Nutzereingaben – validieren Sie diese.
Verlassen Sie sich nie auf die Gültigkeit von jeglichen Werten, die von den Endbenutzern beeinflusst werden können. Dazu gehören auch Cookie-Werte, Anfragenparameter und HTTP-Header. Auch auf serverseitig gespeicherte Informationen sollte nich blind in allen Kontexten vertraut werden.
Überprüfen Sie Gültigkeit aller Werte serverseitig. Weisen Sie leere oder ungültige Authentifizierungsinformationen zurück. Achten Sie bei der Implementierung von Tests auf eine vollständige Abdeckung aller Randszenarien (ein, mehrere oder auch alle Werte sind unerwartet, NULL, nicht definiert, vom falschen Typ, etc.).
Verwenden Sie starke Authentifizierungsmethoden.
Implementationen sind stets abhängig von der Anwendung und dem Kontext. Greifen Sie, wenn möglich, auf bewährte und praxiserprobte Bibliotheken und Authentifizierungslösungen zurück. Verwenden Sie besonders in Bezug auf sensitive Informationen Zwei-Faktor-Authentifizierung. Stellen Sie zudem sicher, dass alle automatisch generierten Schlüssel, Codes und Token nicht leicht zu erraten und somit vor Brute-Force-Angriffen geschützt sind (vgl. UUID v4).
Durchsatzbegrenzung (engl. Rate Limiting) der API-Anfragen:
Begrenzen Sie die mögliche Anzahl der Anfragen von einzelnen Systemen, um dem Missbrauch, wie der schnellen Enumeration von gültigen Reservierungen, vorzubeugen.

In ihrem Update hat straiv mindestens eine Anfragenbegrenzung aktiviert und Reservierungsnummern auf ein nicht-erratbares Format geändert.

Wie HiSolutions helfen kann

HiSolutions bietet spezialisierte Penetrationstests für Webanwendungen und Infrastrukturen an. Hierbei greifen wir auf langjährige Erfahrung zurück und kombinieren die Fähigkeiten modernster Scantechnologien mit manuellen Prüfverfahren, um die bestmögliche Testabdeckung zu gewährleisten.

Stellen Sie sicher, dass Schwachstellen gefunden und behoben werden, bevor Sie ausgenutzt werden können und kontaktieren Sie uns unter +49 30 533 289 0 oder dem Kontakformular für ein kostenloses Erstgespräch.

Koordinierte Veröffentlichung

22.05.2024 HiSolutions sammelt Details zur Schwachstelle.
Finder: Björn Brauer, Deniz Adrian & David Mathiszik
23.05.2024 HiSolutions informiert betroffene Hotelkette und wird an straiv weitergeleitet.
25.05.2024 straiv vereinbart einen Termin für die Übermittlung aller Details.
04.06.2024 HiSolutions teilt alle Details mit straiv.
06.06.2024 straiv veröffentlicht ein Update und HiSolutions bestätigt den Fix.