Kategorie: News

News

Der Trojaner im Sprachmodell, der die KI zum lügen bringt

Dass die aktuellen LLM-basierten Chatbots nicht immer die Wahrheit ausgeben, ist hinlänglich bekannt. Es fehlt ihnen einfach das Konzept von richtig und falsch, sodass sie nur die statistisch wahrscheinlichste Antwort ausgeben.

Forscher haben darüber hinaus gezeigt, wie sie ein vorhandenes Sprachmodell so modifizieren konnten, dass es zu bestimmten Fakten überzeugend falsche Informationen ausgibt, gleichzeitig aber weiterhin zu allen anderen Fragen wie zuvor antwortet. Damit konnten sie dann auch Prüftools austricksen, die mit Stichprobenfragen die Qualität von trainierten Sprachmodellen bewerten. In die Malware-Sprache übersetzt: Sie konnten ihr trojanisiertes Sprachmodell am Virenscanner vorbeischmuggeln.

Weitere Sicherheitsaspekte beim Einsatz von KI haben wir in einem eigenen Blogpost zusammengefasst.

LLMs sind auch nur (schützenswerte) Informationen
News

Seitenkanal durch CPU-eigene Messmethoden

Seitenkanalangriffe nutzen immer beobachtbare Nebenwirkungen von Berechnungen aus, um diese nachvollziehen oder sogar Schlüssel ableiten zu können. Das geht von der Auswertung der Helligkeit von LEDs an Smartcardreadern bis zur Sprungvorhersage bei den berühmten Lücken Spectre und Meltdown.

Forscher der TU Graz haben einen weiteren Weg für Seitenkanalangriffe identifiziert: Die in modernen CPUs bereits eingebauten Sensoren zum aktuellen Stromverbrauch. Indem sie es dem parallel auf der gleichen CPU laufenden Programm extra schwer machten, konnten sie an den Stromverbrauchsschwankungen ablesen, was dieses parallele Programm gerade berechnet.

Neu ist die Idee nicht. Aber anstelle von komplizierten Messinstrumenten, die irgendwo auf der Platine Daten abgreifen, gelingt der Angriff direkt mit den von der CPU bereitgestellten Mitteln.

https://www.tugraz.at/en/tu-graz/services/news-stories/tu-graz-news/singleview/article/neue-cpu-sicherheitsluecke-analyse-des-energieverbrauchs-ermoeglicht-datenklau

News

Kontinuierlich weiterentwickelt – der neue BSI-Standard 200-4 zum BCM

Wenn wir Kunden bei der Bewältigung von Sicherheitsvorfällen unterstützen, kommt unweigerlich zu den technischen Fragen wie der nach dem Einfallstor und geeigneten Gegenmaßnahmen schnell das Thema der Geschäftsfortführung auf – oder platt gesagt die Frage „Wie überleben wir als Organisation den Vorfall?“ Idealerweise hat man sich diese schon vor dem Vorfall gestellt und ein Business Continuity Management (BCM) aufgesetzt.

Eine praxisnahe Anleitung zum Aufbau nachhaltiger BCM-Systeme für alle Arten von Not- und Krisenfällen wurde nun im Juni als BSI-Standard 200-4 veröffentlicht. Der Standard ist eine Weiterentwicklung des bisherigen Standards 100-4 zum Notfallmanagement. Da der Standard unter Mitwirkung von HiSolutions entstand, flossen auch unsere Erfahrungen aus realen Vorfällen ebenso wie aus zahlreichen präventiven Projekten ein.

Mehr BCM-Themen gibt es in unserem BCM-Newsletter. Die nächste Ausgabe erscheint in der kommenden Woche.

https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html

https://www.hisolutions.com/detail/bsi-standard-200-4

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