Kategorie: News

News

Zugelassene Sicherheit für die Zulassung

Die internetbasierte Fahrzeugzulassung (i-Kfz) wird häufig als Erstes genannt, wenn es um E-Government-Projekte in Kreisen und Kommunen geht. Das ist auch kein Wunder: Nach Vorprojekten ging bereits 2015 die erste Stufe von i-Kfz in den Produktivbetrieb. Da in diesem Jahr die Stufe 4 startet, wurden nun auch die Mindestsicherheitsanforderungen (MSA) auf die Version 1.5 aktualisiert.

Diese Mindestsicherheitsanforderungen werden vom Kraftfahrt-Bundesamt (KBA) definiert, da aus der zentralen Webanwendung im Vorprojekt nach dem „Hamburger Kompromiss“ viele dezentrale Portale wurden, die alle sehr eng mit dem Kraftfahrt-Bundesamt (KBA) kommunizieren müssen. Die Anforderungen gelten aber nicht nur für die dezentralen Portale, die häufig von kommunalen Rechenzentren betrieben werden, sondern auch für die Fachverfahren in den Zulassungsstellen vor Ort. Unsere Prüfer sehen die Herausforderungen, vor denen insbesondere kleine Kreis- und Kommunalverwaltungen stehen, in den ebenfalls geforderten regelmäßigen Audits und Penetrationstests.

Mit den neuen MSA wurden nicht nur einige konkrete Anforderungen für das Verfahren selbst geschärft und weitere zulässige Anbindungsvarianten definiert. Es wird auch verstärkt IT-Grundschutz gefordert. Auf eine IS-Kurzrevision kann jetzt nur noch verzichtet werden, wenn die Verfahren Teil eines nach IT-Grundschutz zertifizierten Verbundes sind. Nach unserer Erfahrung ist das nur bei wenigen Kreisen und Kommunen der Fall. Die i-Kfz-Audits dürfen jetzt nur noch Grundschutzauditoren durchführen.

Mit dem Onlinezugangsgesetz (OZG) kommen bereits die nächsten Sicherheitsanforderungen auf die Verwaltungen zu. In der IT-Sicherheitsverordnung Portalverbund (ITSiV-PV) werden ähnliche Verpflichtungen zu Sicherheitskonzepten nach Grundschutz und regelmäßigen Pentests für Systeme des Bundes und der Länder definiert. Aber auch für die mittelbar angebundenen Systeme wird zumindest noch ein Sicherheitskonzept gefordert, das nicht in allen Verwaltungen bereits in der Schublade liegt.

News

Die 25 gefährlichsten Sicherheitslücken

Neben den allseits bekannten CVE-Nummern verwaltet MITRE auch CWE-Nummern. Auch beim Ausschreiben der Abkürzungen ist der Unterschied nicht gleich offensichtlich: Während die „Common Vulnerabilities and Exposures“ (CVE) konkrete vorhandene Sicherheitslücken beschreiben, lautet das Ziel der „Common Weakness Enumeration“ (CWE), eine Liste von möglichen Schwachstellenarten zu pflegen. Daher finden sich in einigen CVE-Datenbanken auch zu jedem CVE-Eintrag eine CWE, also die Art der Schwachstelle.

Aus dieser Zuordnung berechnet das CWE-Team jedes Jahr ein Ranking der 25 gefährlichsten Sicherheitslücken(-arten). In die Berechnung fließen die Häufigkeit und die Risikobewertung sämtlicher CVE-Meldungen der letzten zwei Jahre ein.

Die ersten drei Plätze haben die Klassiker Buffer Overflow, Cross-Site-Scripting und SQL-Injection verteidigt. Aber auch in der übrigen Liste gibt es nur wenig Bewegung und lediglich zwei Auf- bzw. Absteiger. Fazit: Es gibt noch viel zu tun bei der Absicherung.

News

Sicherheit im Selbstversuch

Um Regeln und deren Auslegung drehen sich zwei spannende Web-Quizze.

Zuerst gibt es die recht einfach scheinende Aufgabe, ein sicheres Passwort festzulegen. Allerdings werden mit jeder Runde die Komplexitätsanforderungen an das Passwort gesteigert. Wie weit halten sie mit? Und mal ganz ernst gefragt: Wie halten Sie es mit den Komplexitätsanforderungen?
https://neal.fun/password-game/

Im zweiten Spiel werden die Regeln und Anforderungen nicht gesteigert. Ganz im Gegenteil: Es gibt nur eine einzige Regel „Keine Fahrzeuge im Park“. Dafür sollen dann Szenarien dahingehend bewertet werden, ob sie dieser Regel entsprechen. Die Idee hinter dem Spiel ist schon recht alt und wurde bereits 1958 formuliert: Wie gut kann eine generische Regel alle möglichen Szenarien abdecken? Während der Spieleautor primär die Anwendung bei der Inhaltsmoderation im Kopf hatte, ist es aber auch eine wiederkehrende Herausforderung für Sicherheitsbeauftragte – wie (un)genau soll/kann ich etwas regeln.
https://novehiclesinthepark.com/

News

Wenn der Sicherheitsmitarbeiter die Lücke ist

Die Menschen im Unternehmen spielen eine zentrale Rolle bei der Informationssicherheit. Das gilt umso mehr für diejenigen, die wir extra für diesen Bereich eingestellt haben. Passend zu unserem Monatsthema „Sicher trotz Sicherheitsmaßnahmen“ gab es Ende Mai ein Urteil in Großbritannien, bei dem ein Informationssicherheitsexperte schuldig gesprochen wurde. Bereits 2018 gab es einen Sicherheitsvorfall bei seinem Arbeitgeber, und er war an der Aufklärung und Bewältigung des Vorfalls beteiligt.

Doch nebenbei wollte er auch direkt von dem Vorfall profitieren. Dafür nutzte er seine Zugänge, um die Mail mit der Erpressungsnachricht direkt im Postfach des Empfängers zu ändern. In der Hoffnung, sein Arbeitgeber würde die Erpressungssumme zahlen, änderte er die Zahlungsdaten auf eine eigene Adresse. Zusätzlich schickte er noch Mails im Namen der Erpresser hinterher, um auf eine Zahlung zu drängen.

Die Manipulation wurde entdeckt und konnte auf seine Person zurückverfolgt werden. Im Ergebnis hat er sich nun schuldig bekannt.

https://www.bleepingcomputer.com/news/security/it-employee-impersonates-ransomware-gang-to-extort-employer/

News

Trojanisierte SSH-Keys

In der Linux-Welt wird die Authentisierung beim Fernzugriff gern mit SSH-Keys umgesetzt. Diese Schlüsselpaare aus privatem und öffentlichem Schlüssel haben gegenüber Passwörtern viele Vorteile – so können z. B. für einen Nutzer mehrere autorisierte Schlüssel hinterlegt werden, und der gleiche Mensch kann sich je nach Quellrechner unterschiedlich anmelden (z. B. Laptop, Desktopsystem oder Sprungserver). In der zuständigen Datei „authorized_keys“ können noch weitere Einschränkungen für Zugriffe mit bestimmten Schlüsseln gemacht werden. Beispielsweise kann ein Backupsystem einen Zugriff erhalten, der lediglich das Ausführen des notwendigen Datensammelskripts erlaubt.

In einem Blogpost wurde gezeigt, wie sich diese eigentlich gut gemachte Sicherheitsfunktion ausnutzen lässt, um eine Hintertür auf einem System zu hinterlassen. Eine notwendige Voraussetzung dafür ist der Zugriff auf die Datei „authorized_keys“. Damit kann man sich natürlich auch einfach seinen eigenen Schlüssel in die Liste schreiben, aber das könnte bei einer Inventur der Zugänge auffallen. Daher wird bei dem geschilderten Angriff ein bestehender Eintrag so modifiziert, dass bei jedem Anmelden des berechtigen Nutzers zusätzlich eine Backdoor gestartet wird.

Die betroffene Datei „authorized_keys“ ist sehr geschickt gewählt, da sie nur jeweils den öffentlichen Schlüssel der berechtigten User enthält. Diese Datei wird daher häufig bei größeren Setups und automatischen Deployments mit Git versioniert und dann automatisch auf alle Systeme verteilt. Eine versteckte Manipulation kann also schnell viele kompromittierte Systeme zur Folge haben.

https://blog.thc.org/infecting-ssh-public-keys-with-backdoors

News

Datenaustauschplattform mit unerwünschten Nebenfunktionen

Um keine Dateien als Mailanhänge mehr verschicken zu müssen, werden häufig Datenaustauschplattformen aufgesetzt. Ähnlich wie das ESG können diese zur Vorprüfung eingehender und ausgehender Dateien genutzt werden und damit als klar definierter Ein- und Austrittspunkt aus dem eigenen Netz – also wieder eine klassische Sicherheitsfunktion. Bei der Lösung MOVEit Transfer von Progress ist jedoch Ende Mai eine Sicherheitslücke bekannt geworden, die ebenfalls bereits aktiv ausgenutzt wird. In Deutschland wurden diesbezüglich mehr als 100 betroffene Systeme vermutet. Mehrere AOKs haben die Lösung im Einsatz und hatten sie vorsichtshalber abgeschaltet.

Sehr viele Instanzen sind immer noch in der verwundbaren Version erreichbar – und das, obwohl die Lücke bereits u. a. von Ransomware-Gruppen ausgenutzt wird. Es gibt sogar Hinweise darauf, dass die CL0P-Gruppe bereits seit 2021 mit der Ausnutzung der Lücke experimentiert.

https://community.progress.com/s/article/MOVEit-Transfer-Critical-Vulnerability-31May2023

https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a

https://aok-bv.de/presse/pressemitteilungen/2023/index_26408.html

News

Eine Sicherheitslücke ausnutzen, um eine Sicherheitsfunktion umzusetzen

Zum Schluss noch ein Beispiel für den umgekehrten Fall, bei dem eine Sicherheitslücke ausgenutzt wurde, um Sicherheit umzusetzen: Die Zertifizierungsstelle Let’s Encrypt hat mit ihren automatisch vergebenen und verlängerten Zertifikaten für einen Umbruch bei der Generierung von TLS-Zertifikaten gesorgt. Das dabei eingeführte ACME-Protokoll wird inzwischen auch von anderen Anbietern genutzt, und es gibt eine Reihe von Tools, die das Protokoll unterstützen und auf Servern die automatische Verlängerung übernehmen können. Eines davon ist die Umsetzung als Shellskript, genannt acme.sh. Dieses Skript hatte eine Remote-Execution-Lücke – und öffentlich bekannt wurde sie auf einem eher kuriosen Weg.

Matt Holt ist über den Zertifikatsanbieter HiCA gestolpert, der das ACME-Protokoll nutzt, aber offiziell nur einen einzigen Client zur Nutzung empfahl – acme.sh. Andere Clients funktionierten tatsächlich nicht – daher versuchte er herauszufinden, wo die mögliche Inkompatibilität lag. Überrascht stellte er fest, dass die HiCA-Server während der Verifikation Antworten schickten, die einen Fehler im acme.sh-Client ausnutzten und vom Server versandte Shellbefehle ausführten. Der Hintergrund war, dass HiCA ein Reseller einer anderen Zertifizierungsstelle war, die zwar auch automatische Verifikationen nutzte, aber nicht nach dem ACME-Protokoll. Daher wurden andere Nachweisdateien auf dem Webserver benötigt, die nach dem ACME-Protokoll nicht erzeugt werden konnten. Der HiCA-Betreiber hat deshalb einen Exploit entwickelt, der die Verifikation nach dem anderen Protokoll durchführte und die Nachweise anlegte – also im Grunde eine Sicherheitsfunktion im Exploit umgesetzt.

Die Lücke und auch die HiCA sind inzwischen geschlossen.

https://github.com/acmesh-official/acme.sh/issues/4659

News

Schlüssel für Boot Guard nach Ransomware-Angriff veröffentlicht

Entsprechend der aktuell vorherrschenden „Double Extortion“-Angriffsmethode haben die Angreifer nicht nur den IT-Betrieb beim Hardwarehersteller MSI gestört, sondern auch vorher Daten heruntergeladen. Da der Hersteller das geforderte Lösegeld nicht gezahlt hat, wurden diese nun veröffentlicht. Bis hierhin liest sich der Ablauf wie bei einer Vielzahl aktueller Vorfälle.

Die veröffentlichten Daten enthielten jedoch auch private Schlüssel, mit denen UEFI-Firmware signiert werden kann. Konkret waren Schlüssel für Intel Boot Guard betroffen, die auch die Basis für das Secure Boot von Windows darstellen. Theoretisch können Angreifer damit für die betroffenen Geräte manipulierte UEFI-Images erstellen und diese so signieren, dass sie vom Gerät trotz Prüfung akzeptiert werden. In der Praxis gibt es für solch einen Angriff einige Hürden – vom Erstellen eines lauffähigen UEFI-Images bis hin zum benötigten physischen oder privilegierten Zugriff –, um die Firmware einspielen zu können. Andererseits sind die Schlüssel jetzt quasi öffentlich und leicht für Angreifer jeder Art verfügbar.

News

Verordnete Sicherheit: Europäische NIS2 auf dem Weg in deutsches Recht

Über das Thema NIS2 hatten wir im Digest schon oft berichtet. Zur Erinnerung: Es geht um die Aktualisierung der europäischen Verordnung zur Informationssicherheit von Behörden und Unternehmen.

Letzte Woche wurde der Referentenentwurf des Umsetzungsgesetztes der NIS2-Richtlinie mit dem gewagten Namen NIS2UmsuCG (NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz) bekannt. Das BMI folgt damit der europäischen Vorgabe, die Richtlinie bis zum 17. Oktober 2024 in deutsches Gesetz zu überführen. Dem geleakten Papier fehlen allerdings noch wichtige Inhalte. Beispielsweise ist die Schätzung zu einmaligen und kontinuierlichen Kosten noch undurchsichtig. Dafür wird die Rolle „CISO Bund“ etabliert, welche sich zentral mit der Sicherheit des Bundes auseinandersetzen soll.

Klar ist außerdem, dass der Begriff UBI (Unternehmen im besonderen öffentlichen Interesse) der Vergangenheit angehören soll. Die Bestimmungen dazu werden jedoch inhaltlich im Umsetzungsgesetz weiter existieren. Klarer werden außerdem die von den Unternehmen und Einrichtungen zu erfüllenden Anforderungen, welche in einem dezidierten Katalog gesammelt werden. Ein Handlungsdruck wird vorerst auf Seiten des BMI-liegen, das mit der deutschen Überführung zum Stichtag wahrscheinlich alle Hände voll zu tun haben wird. Die betroffenen Unternehmen und Einrichtungen müssen die Umsetzungsnachweise anschließend bis 2026 erbringen.

News

Der Windows-Patch, der die Neuinstallation verhindert – auch von Ihrem Notfall-USB-Stick?

Im letzten Digest ging es um viele Aspekte des Patchens. Nun wurde ein Patch veröffentlicht, der in Einzelfällen auch extreme Auswirkungen haben kann – er verhindert Neuinstallationen auf dem Gerät.

Aber von vorn: Im Herbst 2022 tauchte das BlackLotus-Rootkit auf, das sich unbemerkt in das UEFI einschleichen kann (ganz ohne die oben beschriebenen Schlüssel). Martin Smolár von ESET hat das Rootkit tiefer analysiert und dabei neben bekannten Exploits für bekannte Lücken auch einen neuen Weg gefunden, um Windows Secure Boot zu umgehen (CVE-2023-24932). Dafür hat Microsoft jetzt einen Patch vorbereitet, der allerdings bei vollständiger Anwendung bestehende Boot-Medien ausschließt – und damit auch Installationsmedien und Notfall-Bootsticks, die man vorsorglich vorbereitet hat.

Das Risiko ist Microsoft bekannt, daher bringt das Update erst einmal nur alles in Stellung, und die Rekonfiguration des UEFI im System durch Einspielen einer Revocation List muss vor 2024 händisch angestoßen werden. Das gibt allen ausreichend Zeit, die Notfall-Bootsticks durchzugehen. Aber nicht zu lange warten: Im Q1 2024 soll die Änderung automatisch eingespielt werden.