Der Exploit im Exploit

Der offene Informationsaustausch ist einer der Grundpfeiler der Sicherheitsgemeinschaft.  Dazu gehört auch das Veröffentlichen von Exploits. Meist kommen sie in Form von kleinen Tools, mit denen sich gerade bekannt gewordene Sicherheitslücken testweise ausnutzen lassen. Damit lässt sich dann das tatsächliche Risiko für betroffene Umgebungen leichter bestimmen.

In letzter Zeit häufen sich wieder Berichte, in denen Angreifer vorgebliche Exploits für aktuelle Lücken veröffentlichen. Doch statt zu prüfen, ob die angegebene Lücke vorhanden ist, greifen die das lokale System an, auf dem sie gestartet wurden. Dort hinterlassen sie dann, wie ganz klassische Trojaner, eine Malware auf dem System, um das System fernsteuern zu können oder an eingegebene Passwörter zu kommen. Die Vorgehensweise ist besonders erfolgreich, da akute Sicherheitslücken immer für Stress sorgen und man dann sehr erfreut ist, wenn es endlich mehr Informationen gibt – und sei es in Form von Exploits. Wird der vorgebliche Exploit dann noch direkt auf dem System eines Administrators ausgeführt, kann es für die Angreifer nicht besser laufen.

Also nehmen Sie sich auch in solchen Situationen immer die Zeit für eine Bewertung der Quelle und deren Reputation und führen sie Experimente immer in einer gesonderten Testumgebung aus!

https://twitter.com/rootsecdev/status/1676570222474534912

https://www.bleepingcomputer.com/news/security/fake-zero-day-poc-exploits-on-github-push-windows-linux-malware/

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.

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

KI betrügt Betrüger

In der letzten Woche wurde wieder ein spektakulärer Fall bekannt, bei dem Betrüger das sächsische Sozialministerium dazu brachten, 225.000€ an sie selbst zu überweisen. Solche Angriffe sind inzwischen eine Mischung aus technischen Attacken und geschicktem Social Engineering. Die technischen Anteile gehen über das Registrieren von Vertipper-Domains hinaus und reichen bis zur Übernahme von Nutzerkonten, die dann genutzt werden, um per Webmail-Frontend die Mails mitzulesen oder Weiterleitungen einzurichten.

Die „sozialen Tricks“ gehen heute auch über schlecht formulierte Mails hinaus: Betrüger interagieren längst persönlich per E-Mail und Telefon mit den Opfern. Viele sehen in den neuen, KI-basierten Chatbots die Gefahr, dass diese Angriffsvarianten einfacher und effektiver werden.

Eine Forschergruppe um Prof. Kaafar an der Macquarie University in Australien will den Spieß umdrehen und betrügerische Anrufe durch einen KI-basierten Sprachassistenten beantworten lassen. Ziel ist es, die Ressourcen der Betrüger zu blockieren und so im besten Fall deren Geschäftsmodell zu stören. Das Wettrennen zwischen Angreifern und Verteidigern geht also auch in diesem Bereich weiter.

https://www.mdr.de/nachrichten/sachsen/sozialministerium-internet-betrueger-phishing-100.html

https://lighthouse.mq.edu.au/article/june-2023/scamming-the-scammers (Pressemeldung der Macquarie University)

https://apate.ai/ (Projektwebseite)

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

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.

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.

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/

Wenn die Sicherheitsappliance die Lücke ist

Im Mai ist eine Sicherheitslücke in der Barracuda ESG Appliance bekannt geworden, die bereits aktiv ausgenutzt wurde. Mit dem Email Security Gateway (ESG) können eingehende und ausgehende Mails auf Spam und Schadsoftware geprüft werden. Damit wird also eine typische Sicherheitsmaßnahme umgesetzt, um unerwünschte Mails und deren Anhänge gar nicht erst bis zu den Nutzern gelangen zu lassen. Noch sind nicht alle Details abschließend bekannt, aber es gibt bereits einige Denkanstöße, die auch für nicht direkt Betroffene abgeleitet werden können.

Der Hersteller empfiehlt, kompromittierte Geräte nicht weiter zu nutzen. Selbst nach einem Firmware-Update ist ihr Betrieb nicht mehr sicher, und die Geräte sollten ausgetauscht werden. Für eine virtuelle Appliance ist der Austausch einer VM leicht umgesetzt – hier muss dann „nur“, wie immer beim Neuaufsetzen nach einem Vorfall, die Konfiguration wiederhergestellt werden. Die ESG gibt es allerdings auch als physisches Gerät, und in diesem Fall muss sie tatsächlich ausgewechselt werden. Das Wiedereinspielen von virtuellen Appliances und das Neuaufsetzen von Systemen haben Sie sicher in Ihrer Notfallplanung. Aber wie gut sind Sie vorbereitet, wenn Netzwerkgeräte ausgetauscht werden müssen?

So ein Austausch benötigt logistischen Vorlauf, und dann kommt direkt eine Frage auf, auf die es keine gute Antwort gibt: Was machen wir zwischenzeitlich mit unseren Mails? Lassen wir die Appliance weiterlaufen mit dem Risiko, dass der Angreifer jetzt die letzte Chance nutzt, um sich von dort ins interne Netzwerk weiterzuhangeln (über die notwendigen Accounts und Netzwerkzugänge verfügt die Appliance typischerweise)? Schalten wir die Appliance ab und lassen die Mails ungefiltert auf unsere Nutzer einströmen – mit dem Risiko, dass jetzt doch jemand auf Phishing hereinfällt oder

sogar einen Malware-Anhang ausführt? Schalten wir so lange die gesamte Mailkommunikation ab und riskieren, dass Mails verloren gehen oder fehlende zeitkritische Informationen dem Geschäft schaden?

Auch für die Softwareentwicklung steckt ein Denkanstoß in dem Vorfall. Dafür schauen wir einmal in die Details dieser Lücke: die Verarbeitung von Mailanhängen mit TAR-Archiven. Das TAR-Format ist in der Linux-Welt sehr gebräuchlich, wenn auch nicht typischerweise als Mailanhang. Es wurde ursprünglich für die Datensicherung auf Magnetbändern entwickelt, stellt den Zustand des Dateisystems mit allen Metadaten sehr gut dar und ist sehr flexibel. Das geht bis hin zu Pfadangaben für Dateien, die sich auch auf übergeordnete Verzeichnisse oder sogar absolute Pfade beziehen können. Und genau dieses Feature wurde von den Angreifern ausgenutzt, um Dateien an den passenden Stellen im Dateisystem der Appliance abzulegen und dort vom Gerät ausführen zu lassen. Doch zurück zu Ihrem Softwareprojekt: Sie haben doch sicher auch irgendwo diese eine Funktion, die es schon sehr lange gibt, die kaum in der Praxis genutzt wird, und die trotzdem da sein muss? Wie steht es da um die Testabdeckung und um regelmäßige Reviews, ob nicht doch eine Änderung notwendig ist?

https://www.barracuda.com/company/legal/esg-vulnerability

https://www.rapid7.com/blog/post/2023/06/08/etr-cve-2023-2868-total-compromise-of-physical-barracuda-esg-appliances/

https://www.heise.de/news/Cyberattacken-Admins-muessen-Barracuda-ESG-sofort-erseztzen-9181326.html

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/