Single Sign-On für brutal forsche(nde) Angreifer: Neuer Azure-AD-Brute-Force-Angriff

Bereits im Juni 2021 fand das Security-Research-Team von Secureworks eine Schwachstelle im Protokoll-Feature „Seamless Single Sign-On“ (SSO) von Azure Active Directory. Diese Funktion erleichtert die Nutzung einer großen Anzahl von Diensten, indem User automatisch eingeloggt werden.

Normalerweise werden Anmeldeversuche über diesen Weg protokolliert. Um die Funktion auch für Office 2013 zu ermöglichen, existiert allerdings ein alternativer Endpoint. Es stellte sich nun heraus, dass ein Autologin über diesen Endpoint zu keinem Log-Eintrag führte. So konnte dieser für Brute-Force-Angriffe genutzt werden, ohne dass diese bemerkt werden konnten.

Microsoft reagierte erst nach der Veröffentlichung der Schwachstelle Ende September 2021: Nun werden auch die Anmeldungen über den betroffenen Endpoint in den Logs aufgezeichnet.

https://www.secureworks.com/research/undetected-azure-active-directory-brute-force-attacks

UEFI Cup: UEFI-Bootkits gibt es wirklich

FinSpy und ESPecter sind die Namen der beiden UEFI-Bootkits, die von ESET bzw. Kaspersky gefunden wurden. Das „Unified Extensible Firmware Interface” (UEFI) ist die Schnittstelle zwischen dem Betriebssystem und der Firmware der Computer-Komponenten. Es gilt als Nachfolger des BIOS. Seit 2012 gibt es eine Secure-Boot-Funktion, die vor bösartigen sogenannten Bootloadern schützen soll. Dies ist wichtig, da zu diesem Zeitpunkt das Betriebssystem noch nicht geladen ist, und somit dessen Schutzmechanismen nicht greifen können. 

Bisher waren nur Proof-of-Concepts oder das physische Einsetzen von Hardware als gangbare Angriffe bekannt. ESPecter und FinSpy benutzen denselben Angriffsvektor auf den UEFI Boot Manager. Für einen erfolgreichen Angriff muss Secure Boot ausgeschaltet sein. Systeme mit Windows 7 oder älter unterstützen dies noch gar nicht. Ebenso kommt es häufig zu Konflikten mit dem Secure Boot und Dual Boot, weshalb ersterer in solchen Fällen oft abgeschaltet wird. Alternativ gibt es bekannte Schwachstellen bei veralteter Firmware oder Produkten. Diese können Angreifer ausnutzen, um Secure Boot selbst zu deaktivieren. Sobald Secure Boot umgangen ist, modifiziert die Malware das Windows Boot Manager Binary in der EFI Firmware Interface (ESP) Partition. 

ESPecter nutzt eine Boot Chain, um durch einen Kernel-Mode Driver einen Keylogger und weitere Payloads nachzuladen. Bei FinSpy lädt der ersetzte Boot Manager zwei Dateien. Diese sorgen dafür, dass ein Trojaner gestartet wird, sobald sich ein Nutzer einloggt. Um eine legitim aussehende Kommunikation mit einem C&C-Server aufzubauen, wird ein Browser mit verstecktem Fenster benutzt. Sobald die Kommunikation mit dem C&C hergestellt ist, kann persistent beliebige Malware mit verschiedenen Funktionen nachgeladen werden.

https://securelist.com/finspy-unseen-findings/104322/

https://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/

Nicht nur Windows: FontOnLake Linux Rootkit Malware

FontOnLake heißt eine neue Malware-Familie für Linux-Geräte. Sie kann Fernzugriff auf das angegriffene System gewähren und Log-in-Daten sammeln. Besonders an dieser Malware ist, dass sie mit einigem Aufwand versucht, unentdeckt zu bleiben. Um Daten zu sammeln, werden legitime Binaries von Standard-Linux-Utilities (z. B. „cat“), modifiziert und als Trojaner eingesetzt. Diese laden dann weitere Module, die Backdoors für die Angreifer einrichten.

Zusätzlich wird ein Rootkit benutzt, das die Malware versteckt und die benutzten C&C-Server sowie Ports bei nahezu jedem Angriff wechselt. Wie die Systeme initial infiziert werden, ist bisher nicht bekannt. 

Bisher scheinen die Angriffe auf Ziele in Südostasien fokussiert zu sein. Dies ergibt sich aus Uploads zu VirusTotal. Erste Spuren der Malware führen zurück bis Mai 2020.

https://www.welivesecurity.com/2021/10/07/fontonlake-previously-unknown-malware-family-targeting-linux/

Reverse Engineering erlaubt: EuGH erlaubt Dekompilierung für Bug-Fixes

Auch gegen den Willen des Herstellers darf proprietäre Software per Reverse Engineering untersucht werden, wenn es bestimmten Zwecken dient. Damit ist zumindest auf europäischer Ebene eine Frage geklärt, welche die Security-Community auf der einen und bestimmte Software-Hersteller auf der anderen Seite seit Langem beschäftigt. Für die Informationssicherheit ist dies allemal ein Gewinn, zeigt doch die Erfahrung, dass Hersteller nicht immer freiwillig und schon gar nicht in jedem Fall zeitnah kritische Bugs beheben.

https://www.golem.de/news/urheberrecht-eugh-erlaubt-dekompilierung-fuer-bug-fixes-2110-160225.html

Versehentlich Open Source: Ganz Twitch geleakt

Die (vor allem, aber längst nicht mehr nur) bei Gamerinnen und Gamern beliebte Streaming-Plattform Twitch ist Opfer eines der größten Datendiebstähle der jüngeren Geschichte geworden. Am 4. Oktober fanden sich über 125 Gigabyte interner Daten auf der berüchtigten Website 4chan. Überraschend ist der Inhalt des Leaks: Neben den Einnahmen aller Streamerinnen und Streamer seit 2019 ist insbesondere der komplette Sourcecode samt Commit History bis zu den Anfängen von Twitch enthalten. Weiterhin scheint sämtliches „Intellectual Property“ samt interner Projekte von Twitch nun öffentlich. So wurde ein geplanter Mitbewerber zur Plattform Steam mit dem Namen Vapor bekannt.

Besorgniserregend für Twitch ist, dass die Hacker den Leak als „Teil 1“ angekündigt haben. Die Folgen werden sich noch zeigen. Da der Sourcecode nun erstmals öffentlich ist, können Angreifer diesen etwa auf Schwachstellen untersuchen. Twitch sollte sich daher auf vermehrte Attacken einstellen. Glücklicherweise wurden bisher keine Nutzerdaten oder Kreditkartendaten preisgegeben. Trotzdem wird Nutzern nahegelegt, die 2-Faktor-Authentifizierung zu aktivieren.

https://thehackernews.com/2021/10/twitch-suffers-massive-125gb-data-and.html

­Der 0 Millionen Dollar Raub: Mr. White Hat gibt’s zurück

Kryptowährungen an sich sind riskante Investitionsobjekte – nicht nur aufgrund der Volatilität und der häufigen Scam-Versuche, sondern auch wegen spektakulärer Security Incidents, die hier nicht selten gleichbedeutend sind mit dem Verlust von vielen Millionen Euro bzw. Dollar.

Umso wilder geht es bei „#Defi“ zu: „Decentralized Finance“ ist die nächste Entwicklungsstufe der „Kryptos“ und verbindet mehrere Blockchains zu größeren Netzwerken.

Hier konnte ein unbekannter Angreifer – später durch das bestohlene Poly-Netzwerk „Mr. White Hat“ getauft – umgerechnet 610 Millionen US-Dollar auf eigene Adressen in verschiedenen Kryptowährungen abzweigen. Dabei nutzte er einige spannende Designfehler von Poly aus. Insbesondere wurden Hashes nicht exakt genug geprüft.

Nach anfänglichem Betteln um Rückgabe der Beute schwenkte Poly bald um und bot dem Angreifer den Job als Sicherheitsberater an. Zwar scheint das Jobangebot im engeren Sinn nicht angenommen worden zu sein, aber das Geld wurde doch Stück für Stück zurückgebracht, ohne die Identität von Mr. White Hat zu enthüllen.

Sollte es wirklich seine bzw. ihre Absicht gewesen sein, auf Sicherheitslücken in #Defi bzw. Poly hinzuweisen – es wäre spektakulär gelungen.

https://threatpost.com/poly-network-recoups-610m-stolen-from-defi-platform/168906/

6 Jahre Branchenspezifische Sicherheitsstandards (B3S) – Eine Bestandsaufnahme im Vergleich

Von Konrad Degen.

Branchenspezifische Sicherheitsstandards (B3S) haben sich in zahlreichen KRITIS-Sektoren in Deutschland etabliert. Nach der durch das IT-Sicherheitsgesetz 1.0 ausgelösten Entstehungswelle entwickeln sich aufgrund der zweijährigen Gültigkeit die Standards weiter. Eine Vergleichsanalyse zeigt, dass sieben Schritte für die Erstellung eines B3S notwendig sind. 

Mit Inkrafttreten des IT-Sicherheitsgesetzes 1.0 im Juli 2015 hat der Gesetzgeber sich zum Ziel gesetzt, die IT-Sicherheit in Deutschland zu stärken. Betreiber von kritischen Infrastrukturen wurden aufgrund ihrer Bedeutung für die Gesellschaft verpflichtet, ein Mindestmaß an IT-Sicherheit zu gewährleisten, da ein Ausfall oder eine Störung der öffentlichen Daseinsvorsorge negative Auswirkungen für Staat, Wirtschaft und Gesellschaft zur Folge haben. KRITIS-Betreibern wurde die Möglichkeit eingeräumt, branchenspezifische Sicherheitsstandards (B3S) zu entwickeln.  Die in der Regel durch Verbände entwickelten B3S werden nach Eignungsfeststellung durch das BSI für die Dauer von zwei Jahren als gültig erklärt.

Im Zuge der Diskussion um die Verabschiedung des IT-Sicherheitsgesetzes 2.0 und einer geplanten Überarbeitung der B3S Orientierungshilfe durch das BSI ist es sinnvoll, sich die bestehende B3S-Landschaft genau anzuschauen. Auf der Webseite des BSI werden 10 existierende B3S u. a. für die KRITIS-Sektoren Wasser, ITK, Ernährung, Gesundheit und Pharma sowie Verkehr veröffentlicht. Allerdings besteht keine Veröffentlichungspflicht; die Anzahl tatsächliche existierender B3S liegt deutlich höher.

Überblick über B3S

Betrachtet man nur die öffentlich verfügbaren B3S, lassen sich folgende Erkenntnisse ableiten:

  • Die meisten B3S wurden durch Verbände herausgegeben und die erste Version in den Jahren 2018 und 2019 veröffentlicht.
  • Im Zuge der Weiterentwicklung bzw. Verlängerung der B3S wurden die Inhalte teilweise vertieft und aktualisiert, aber nur kleine Änderungen vorgenommen, und es erfolgte meist keine Änderung der Grundstruktur.
  • In der Regel orientieren sich die B3S-Autorinnen und Autoren an der einschlägigen Orientierungshilfe des BSI (Ausnahme: Der B3S für Verkehrssteuerungs- und Leitsysteme im kommunalen Straßenverkehr ist nach DIN ISO/IEC 27001 strukturiert)
  • Alle B3S umfassen nicht nur den B3S-Betreiber, sondern auch Dienstleister und Dritte, welche Teilleistungen bzw. Teilfunktionen erbringen. Der KRITIS-Betreiber muss dabei sicherstellen, dass die B3S-Anforderungen eingehalten werden.
  • Alle B3S verfolgen einen Allgefahrenansatz, und der Einsatz eines Informations-Sicherheitsmanagementsystems (ISMS) wird empfohlen und ist teilweise verpflichtend (u.a. B3S Gesundheitsversorgung im Krankenhaus)
  • Alle B3S verweisen auf allgemeine Normen (z. B. ISO 27001, IT-Grundschutz) und weitere branchenspezifische Standards, welche gemeinsam mit dem B3S angewendet werden müssen.
  • Alle B3S zeigen konkrete Maßnahmen und abzudeckende Themen auf, welche sich an der Orientierungshilfe orientieren und auf den speziellen KRITIS-Sektor angepasst wurden.

Vergleich B3S

Zukünftige B3S

Basierend auf den analysierten B3S lässt sich für die Erstellung zukünftiger B3S folgende Struktur empfehlen:

  1. Zunächst sollte die Festlegung des Scopes des B3S erfolgen. Dies beinhaltet die Nennung der Rechtsgrundlage, die Definition wichtiger Schlüsselbegriffe sowie die Festlegung der Zielsetzung des B3S mit einer Abgrenzung, welche Aspekte der kritischen Infrastruktur nicht Gegenstand des B3S sind.
  2. In einem zweiten Schritt sollte die KRITIS-Infrastruktur ausführlich beschrieben werden. Hierbei sollte auf die Funktionsweise und die Rollen/Akteure eingegangen werden. Im Mittelpunkt sollte die Beschreibung der Abhängigkeit der KRITIS-Infrastruktur von der IT stehen.
  3. Als dritter Schritt erfolgt die Festlegung und Formulierung der Schutzziele des B3S. Hierbei sollte auf die Anwendung eines Allgefahrenansatzes eingegangen, die KRITIS-Schutzziele genannt und auch die IT-Schutzziele beschrieben werden. Einbezogene Standards und Vorgaben, welche die Grundlage für den B3S bilden, können ebenfalls beschrieben bzw. auf diese verwiesen werden.
  4. Die Beschreibung der branchenspezifischen Gefährdungslage ist der vierte Schritt. Hierbei wird die kritische Dienstleistung definiert, indem deutlich wird, wann diese erfüllt oder nicht erfüllt wird. Des Weiteren werden die allgemeinen und IT-spezifischen Bedrohungen je nach Relevanz für den spezifischen B3S aufgelistet und gegenübergestellt. Die Benennung der Bedrohungskategorien und Schwachstellenkategorien sowie die Beschreibung des Umgangs bei Änderungen der Gefährdungslage sollten ebenfalls in diesem Schritt erfolgen.
  5. Im fünften Schritt erfolgt die Beschreibung des Vorgehens und Nennung von Maßnahmen für die Risikoanalyse und das Risikomanagement. Hierbei werden die Risikokategorien festgelegt und bewertet sowie Handlungsempfehlungen abgeleitet. Des Weiteren werden die Techniken und Methoden zur Durchführung der Risikoanalyse beschreiben und die Risikotoleranz definiert.
  6. Schritt sechs beinhaltet die Maßnahmen und Handlungsempfehlungen für den Umgang mit Risiken. Hierbei sollte sich an den abzudeckenden Themen der Orientierungshilfe orientiert werden:
    1. Relevanz eines ISMS
    2. Relevanz des Business Continuity Management für die kDL
    3. Relevanz des Asset Management
    4. Anforderungen an eine robuste/resiliente Architektur
    5. Anforderungen an eine bauliche/physische Sicherheit
    6. Bedeutung der personellen und organisatorischen Sicherheit
    7. Relevanz der branchenspezifischen Technik und Nennung spezifischer Anforderungen an die Ausgestaltung
    8. Bedeutung der branchenspezifischen Architektur und Verantwortung
    9. Anforderungen an die Vorfallserkennung und -bearbeitung
    10. Umgang mit Überprüfungen und die Bedeutung von Übungen
    11. Relevanz der externen Informationsversorgung und Unterstützung
    12. Rolle und Bedeutung von Lieferanten, Dienstleister und Dritte
    13. Beschreibung der technischen Informationssicherheit
  7. In Schritt sieben erfolgt die Definition der zulässigen Arten von Nachweisen, welche für die Erfüllung des B3S erforderlich sind. Hierbei sollen auch die für den Nachweis zulässigen Standards bzw. Anforderungen genannt werden. Des Weiteren müssen die Anforderungen an das Prüfschema sowie das Prüfteam beschrieben werden. Zum Schluss wird auch die Nachweispflicht gegenüber dem BSI geregelt.

Zusätzlich zu den skizzierten Schritten kann durch einen Anhang die Übersichtlichkeit etwa von Schwachstellen und Bedrohungskategorien verbessert werden. Weiterhin ist es empfehlenswert, Schlüsselwörter wie „MUSS“, „SOLL“ und „KANN“ zu verwenden, damit die Bedeutung von Maßnahmen sofort ersichtlich ist. Ein Literaturverzeichnis, Abkürzungsverzeichnis, sowie ein Glossar sorgen für ein besseres Verständnis des B3S.

Show Your HighNIS: Highlights des EU NIS Investment Reports

von Tim Goos.

Im Dezember 2020 wurde der NIS Investment Report veröffentlicht. Dieser analysiert, wie die EU NIS Direktive in den zwei Jahren seit ihrer Umsetzung in die nationalen Gesetze von Organisationen implementiert wurde. Dabei betrachtet der Report als repräsentative Stichprobe für die gesamte EU nur Organisationen aus den vier Ländern Deutschland, Frankreich, Spanien und Polen. So konnte ein Vergleich zwischen den Ländern, aber auch zwischen verschiedenen Sektoren gezogen werden. Dabei stellte sich heraus, dass in Bezug auf die Umsetzungstiefe die Länder von Deutschland und die Sektoren vom Banken- sowie vom Energiesektor angeführt werden. Abgeschlossen wird der Bericht durch eine Umfrage zu den gewählten Schwerpunkten und Komplikationen bei der Implementierung. Nicht überraschend werden unklare Erwartungen der nationalen Autoritäten und Konflikte mit anderen Gesetzen als die größten Hindernisse genannt.

Zusammengefasst bietet der NIS Investment Report einen Einblick in die Umsetzung der NIS Direktive, aber leider keinen tiefen.

Abbildung1: Darstellung der aktuellen Implementierung der NIS Direktive[1]

Insgesamt haben rund 80 % aller betrachteten Organisationen mit der Implementierung begonnen oder haben diese schon vollendet. Nur eine der 251 betrachteten Organisationen weigert sich, die NIS Direktive zu implementieren oder sich an dieser zu orientieren. Weiterhin dauert die Implementierung im Schnitt zwischen 14 und 18 Monaten, womit dreiviertel der Organisationen im Jahr 2018 oder 2019 starteten. Vorreiter bei der vollendeten Implementierung der NIS Direktive ist Deutschland mit ~70 %, dicht gefolgt von Frankreich und Italien mit ~67 % bzw. ~64 %. Spanien und Polen folgen mit unter 50 % Umsetzung. Gründe hierfür sind unter anderem die Geschwindigkeit, mit der die NIS Direktive in die nationalen Gesetze umgesetzt wurde, sowie deren Priorisierung.

Die eingesetzten dedizierten Ressourcen umfassen zu 90 % ein Budget zwischen 50.000 € und 1 Million € mit einer 50/50-Verteilung, ob neue oder externe Arbeitskräfte eingesetzt werden. Da keine Korrelation zwischen den erhobenen Daten und der Größe der entsprechenden Organisationen vorliegt, können die Daten schlecht interpretiert werden. Es ist anzunehmen, dass kleinere Organisationen mehr auf neue oder externe Arbeitskräfte setzen, um die NIS Direktive zu implementieren, während große Organisationen durch entsprechend größere IT-Abteilungen und Know-how diese selbständig umsetzen können. Ein interessanter Ausreißer ist der Sektor Digitale Infrastruktur. In diesem gaben ~39 % der Organisationen ein Budget unter 50.000 € an. Im Vergleich zum Energiesektor zeigen sich große Diskrepanzen. Daraus lässt sich schließen, dass die einzelnen Sektoren unterschiedlichen Wert auf IT-Sicherheit legen.

Den größten Einfluss auf die IT-Sicherheit der Organisationen hat die NIS-Direktive in den drei Sicherheitsbereichen „Governance, Risk and Compliance“, „Security Analytics“ und „Network Security“. Dies zeigt sich z. B. dadurch, dass 81 % aller betrachteten Organisationen einen Mechanismus zum Melden von Vorfällen in der IT-Sicherheit an nationale Autoritäten eingerichtet haben. Außerdem sieht die überwiegende Mehrheit aller betrachteten Organisationen die NIS-Direktive als einen positiven Beitrag zu Ihrer IT-Sicherheit. Dies könnte an den wenigen neuen Technologien liegen, die laut Umfrage eingesetzt werden. Es wurden also meist schon bestehende Systeme erweitert oder ausgebaut, was es den Organisationen einfacher machte. Schließlich gaben die betrachteten Organisationen die verschiedenen Umsetzungen in nationale Gesetze und mögliche Konflikte mit alten Gesetzgebungen sowie die Priorisierung anderer Regulierungen und die unklaren Erwartungen von Seiten nationaler Autoritäten als die größten Schwierigkeiten bei der Implementierung der NIS Direktive an.


[1] S. 18 des NIS Investments Report https://www.enisa.europa.eu/publications/nis-investments

Verbändeanhörung zur neuen KRITIS-Verordnung

An die einschlägigen Verbände wurde heute ein Vorab-Entwurf der Änderung der KRITIS-Verordnung zur Anhörung verschickt. Das BMI sieht darin signifikante neue bzw. verschärfte Anforderungen für KRITIS-Betreiber und – erstmalig – auch andere Unternehmen vor. Der Entwurf ist wohl innerhalb der Bundesregierung, anders als ein typischer Referentenentwurf, noch nicht abschließend abgestimmt.

KRITIS-Betreiber bleibten weiter verpflichtet, ihre Anlagen für kritische Dienstleistungen (kDL) nach „Stand der Technik“ abzusichern, was alle zwei Jahre durch zu überprüfen ist. Verstöße könnten zukünftig jedoch mit bis zu 20 Millionen Euro für juristische Personen geahndet werden (heute: 100.000 Euro).

BMI, Auswärtiges Amt und zuständiges Fachministerium könnten zukünftig den Einsatz bestimmter kritischer Komponenten verbieten („Lex Huawei“).

Betreiber würden zudem verpflichtet, Systeme zur „automatischen Angriffserkennung“ (lies: SIEM, ggf. SOC) zu nutzen und die Daten aus diesen vier Jahre lang aufzubewahren,

Kein neuer Schwellwert, aber neue Schwellen

Zwar bleibt die Orientierungsgröße von 500.000 mit einer kDL versorgten Menschen für die Einstufung als Kritis-Anlage erhalten. Im Detail wurde deren Interpretation aber verändert und ausgeweitet.

Für Verkehrsbetriebe etwa würde sich die Formulierung von „125 Millionen Fahrgästen im Jahr“ zu „125 Millionen unternehmensbezogener Fahrgastfahrten im Jahr“ konkretisieren, was Querelen wie bei der BVG (inzwischen beigelegt) die Grundlage entzieht.

Software und IT-Dienste als KRITIS

Neu als KRITIS-Anlagen werden nun „Software und IT-Dienste, die für die Erbringung einer kritischen Dienstleistung notwendig sind“ genannt. Hier ist jedoch noch eine konkrete Interpretation vonnöten.

Bis zum 17. Mai erwartet das BMI die Stellungnahmen der Verbände. Am 26. Mai ist eine Anhörung per Videokonferenz terminiert.