Vom Handy bis zur Cloud – die Lücken des Monats

Zwei Vorfälle haben viele Administratoren im letzten Monat bewegt: Die Schwachstellen im Ivanti Endpoint Manager Mobile (EPMM), besser bekannt unter dem alten Namen MobileIron, und die gefälschten Zugangstoken für Microsofts Cloud. Gemeinsam ist beiden Fällen, dass sie initial bei der Analyse von Sicherheitsvorfällen entdeckt wurden.

Auch viele deutsche Unternehmen und Behörden nutzen MobileIron/Ivanti für die Verwaltung ihrer Smartphones und waren daher von der Lücke betroffen. Da die Handys regelmäßig mit dem Verwaltungsserver sprechen müssen, ist dieser meist zum Internet exponiert und damit leicht angreifbar. Der Hersteller hat eine aktualisierte Version nicht nur für die aktuellen Versionen, sondern auch für ältere Versionsstränge herausgebracht. Diese sollten dringend installiert werden, da die Lücke bereits ausgenutzt wurde.
Aufgrund der vielen Betroffenen hat HiSolutions wieder die wichtigsten Punkte als Hilfe zur Selbsthilfe veröffentlicht und pflegt dort regelmäßig die neuesten Erkenntnisse nach: Zum Selbsthilfeleitfaden

Microsoft musste ebenfalls einen erfolgreichen Fremdzugriff auf Mailpostfächer einräumen. Die Angreifer konnten mithilfe von gefälschten Zugangstoken direkt auf die Postfächer der betroffenen Organisation zugreifen. Dahinter steckte jedoch kein Fehler am Anmeldemechanismus, die Angreifer hatten vermutlich einen der privaten Signaturschlüssel und konnten dann ganz leicht beliebige Token ausstellen und korrekt signieren. Der betroffene Schlüssel wurde inzwischen gesperrt. Microsoft liefert außerdem weitere Informationen, mit denen potenziell Betroffene prüfen können, ob die Angreifer auch bei ihnen erfolgreich waren. Die Forscher bei Wiz Research haben sich mögliche Auswirkungen auf weitere Anwendungen über die Cloud-Maillösung hinaus angeschaut. Ihr Ergebnis ist, dass einige weitere Anwendungen (ob selbst entwickelt oder eingekauft), die ebenfalls Azure AD zur Anmeldung nutzen, betroffen sein könnten. Es ist aber unklar, ob die Angreifer dies tatsächlich ausgenutzt haben.

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

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 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/

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