[English]Es gibt eine Schwachstelle in Windows, die es Angreifern ermöglicht, ein System zu infizieren und ein Netzwerk zu durchsuchen. Sicherheitsforscher von Elastic haben diese neue Infektionstechnik Mitte Juni 2024 aufgedeckt und mit dem Begriff GrimResource belegt. Ich hatte das zeitnah mitbekommen, komme (Urlaubs-bedingt) erst jetzt dazu, diesen Sachverhalt hier im Blog aufzubereiten.
Anzeige
Office-Makros & Co. als Angriffsvektor gestopft
Microsoft unternimmt ja einige Anstrengungen, um Schwachstellen, die für Angriffe genutzt werden können, zu stopfen. Historisch bedingt gab es viele Einfallstore für Angreifer. Microsoft Office-Makros sind aus Sicherheitsgründen für aus dem Internet stammende Dokumente standardmäßig deaktiviert. So wird ein Einfallsvektor wirkungslos.
Cyber-Angreifer setzen inzwischen auf andere Infektionsvektoren wie JavaScript, MSI-Dateien, LNK-Objekte und ISOs, so dass dies stark an Popularität gewonnen haben. Hier besteht aber die Situation, dass Administratoren bereits Riegel vorgeschoben haben oder diese Angriffstechniken von Sicherheitslösungen genau geprüft werden und eine hohe Entdeckungswahrscheinlichkeit haben. Daher hätte eine bisher weitgehend unbekannte Angriffstechnik ein "hohes Potential".
GrimResource und die Windows .msc XSS-Schwachstelle
Genau eine solche Angriffstechnik scheinen sich nordkoreanische Angreifer zu bedienen. Sicherheitsforscher von Elastic Security Labs sind auf diese neue Infektionstechnik, die sie als GrimResource bezeichnen, gestoßen. Der Angriff macht sich .msc-Dateien zunutze und ermöglicht Angreifern die vollständige Codeausführung im Kontext von mmc.exe. Es reicht einen Benutzer zum Öffnen einer speziell gestalteten .msc-Datei per Doppelklick zu verleiten. Ein Beispiel, das der Thread Actor GrimResource ausnutzt hat, wurde erstmals am 6. Juni 2024 auf VirusTotal hochgeladen.
Ich hatte zeitnah nachfolgenden Tweet zu diesem Thema gesehen (und es gab diesen Kommentar), aber keine Möglichkeit, hier im Blog zu reagieren. Die Details wurden von Elastic Security Labs im Blog-Beitrag GrimResource – Microsoft Management Console for initial access and evasion veröffentlicht.
Anzeige
XML-Datei als Träger
Parallel dazu gibt es auf Github eine Datei mit einem Proof of Concept dieses Angriffsvektors. Aus der Datei wird bereits ersichtlich, wo das Problem liegen könnte, denn .msc-Dateien sind letztendlich XML-Dokument. Hier ein Auszug aus der PoC-Datei:
<?xml version="1.0"?><MMC_ConsoleFile ConsoleVersion="3.0" ProgramMode="UserSDI"> <ConsoleFileID>a7bf8102-12e1-4226-aa6a-2ba71f6249d0</ConsoleFileID> <FrameState ShowStatusBar="false"> <WindowPlacement ShowCommand="SW_HIDE"> <Point Name="MinPosition" X="-1" Y="-1"/> <Point Name="MaxPosition" X="-1" Y="-1"/> <Rectangle Name="NormalPosition" Top="0" Bottom="0" Left="0" Right="0"/> </WindowPlacement> </FrameState> <Views>
Speichert man den Quellcode aus obiger GitHub-Seite in einer Textdatei und benennt diese in .msc um, hat man eine Datei, die in mmc.exe geladen werden kann. Und mmc.exe setzt dann alle Anweisungen aus der .msc-Datei um. Klickt man auf obigen Screenshot, lässt sich auf X ein Video ansehen, das zeigt, dass das Öffnen der .msc-Datei per Doppelklick ein Dialogfeld und den Windows-Rechner öffnet. Ein Blick in die .XML-Struktur offenbar, dass diese auch einen BinaryStorage mit Binärdaten aufweist, die durch die .msc-Datei verwendet werden können.
Details zum Angriffsvektor
Der Elastic-Artikel beschreibt nun den Angriffsvektor genauer. Der GrimResource-Angriffsvektor nutzt eine alte XSS-Schwachstelle in der apds.dll-Bibliothek aus. Durch Hinzufügen eines Verweises auf die verwundbare APDS-Ressource (Authentication Protocol Domain Support) in den entsprechenden StringTable-Abschnitt einer manipulierten MSC-Datei können Angreifer beliebiges Javascript im Kontext von mmc.exe ausführen. Angreifer können diese Technik mit DotNetToJScript kombinieren, um beliebige Codeausführung zu erlangen.
Für interessierte Leser beschreibt der Elastic-Artikel detailliert die Ausnutzung durch GrimResource. Die Kollegen von Bleeping Computer, die das Thema zeitnah behandelten, zitieren in diesem Artikel, das die Schwachstelle in Windows bisher ungepatcht ist.
MMC und das UAC-Bypassing
Was mir beim Querlesen der obigen Fundstellen aufgefallen ist: Dort wird das besondere Risiko von .msc-Dateien nicht angesprochen. Solche .msc-Dateien und mmc.exe lassen sich für UAC-Bypassing-Angriffe missbrauchen, so dass die Benutzerkontensteuerung umgangen und administrative Rechte auf Standardkonten erreicht werden können. Ich hatte 2017 beispielsweise im Blog-Beitrag Erebus Ransomware und die ausgetrickste UAC auf diesen Sachverhalt hingewiesen.
Wie kann man sich schützen?
Schützen können Administratoren sich for GrimResource, indem sie prüfen, ob die Ausführung von .msc-Dateien aus Internetquellen (Mark of the Web-Flag, MotW) gesetzt ist, unterbunden werden kann. Die Elastic Labs haben auf dieser GitHub-Seite einige Informationen (Indicator of Compromise, IoCs) zusammen getragen (hier gibt es die Elastic Protection Rules-Sammlung, siehe auch diesen Tweet) und die Kollegen von Bleeping Computer geben hier weitere Hinweise.
Ähnliche Artikel:
BSI warnt vor Windows-Schwachstelle (MMC/Task-Planer)
Erebus Ransomware und die ausgetrickste UAC
Windows 10/11 FoDHelper UAC-Bypassing-Test und Fremdvirenscanner
Windows10: Neue UAC-Bypassing-Methode (fodhelper.exe)
Windows UAC über SilentCleanup ausgehebelt
Windows 10: Schwachstelle .SettingContent-ms
Anzeige
Die Angreifer sind schlau: Vermutlich > 90 % aller Administratoren halten XML-Dateien für unverdächtig/ungefährlich.
Wie schön, wenn man einen Proxy hat, auf dem man den Download von *.msc Dateien blockieren kann… Und wie schön, wenn man zentral auf dem Mailserver entsprechende Attachments blocken kann… Es müssen dann noch die AV-Hersteller nachziehen, dass sie entsprechende MSC Dateien erkennen.
Ach immer diese Leier mit Proxy, Downloads blockieren, Attachments blocken. Das hilft Dir wenig bis gar nichts wenn es u. a. darum geht, Attacken von innen zu unterbinden, insb. auch solche von übelwollenden Ko-Administratoren.
Ok, und wo sollen sie die erforderliche MSC Datei her bekommen? Backen in der Gemeinschaftsküche der Abteilung?
msc-Dateien sind eigentlich xml-Dateien. xml-Dateien sind Textdateien. Text schicke ich mir in einer Mail von außen zu, kopiere den Text in notepad, speichere das als .txt und benenne die extension um.
Wofür brauchst Du doch gleich eine Gemeinschaftsküche?
Das ist schon ziemlich aufwändig, das wird kaum jemand in der Buchhaltung oder so machen, der da Emailmäßig an der vordersten Front hockt…
An Heitbrink, Jakobs und Konsorten: Könnt ihr das mit Applocker oder Software Restriction Policies abfangen?
MSC-Dateien kann man so nicht abfangen. Man könnte das Ausführen von mmc.exe sperren, je nach Umgebung kann das aber den Arbeitsfluss empfindlich stören. Das könnte z.B. Leute in der Personalabteilung tangieren, welche (anstelle von Admins) die Benutzerverwaltung delegiert bekommen hat. Oder Benutzer, die mit Zertifikaten arbeiten müssen. Usw.
Also wie immer totaler Ranzkack bei MS :-)
Und wie verhinderst du bei der Opensource-Alternative das Ausführen beliebiger Befehle? So ein einfaches rm -R * kann auch ohne Root einigen Schaden anrichten. Und gerade ist wohl wieder was böses mit OpenSSL.
Schwachsinn und der übliche dümmliche Whataboutism, um billigvon diesem Versager System abzulenken. immer wieder herrlich:-)
Ja, das kann Schaden anrichten. Im eigenen Userverzeichnis. Pech für den Benutzer. Und Fehler in Teilen von Anwendungen oder im Betriebssystem müssen wenigstens nicht immer bis zum ersten Dienstag im Monat warten, bis sie behoben werden. Diff File über den Quellcode jagen, Compiler anwerfen, fertig.
Und auf verbundenen Netzlaufwerken gleich die Arbeit der ganzen Abteilung platt machen. Oder wenn die Rechtevergabe genauso dilletantisch gemacht ist, wie hier die Meinungen zur Unverwundbarkeit von OSS-Systemen, gleich alles.
erster Gedanke, ohne testen: nein. jedenfalls nicht, wenn erlaubte Programme ausgeführt werden.
mmc.exe wird wohl immer auf der allowliste stehen.
die Malware.exe im Benutzer Kontext würde blockiert, auch Admins wären geschützt, wenn applocker den Administratoren die Ausführung aller Dateien ebenfalls nicht erlaubt.
Würde mich Mark anschließen. Das Problem ist, dass ich eine "Dokumentdatei .msc" erhalte, die beim Doppelklick per mmc.exe geöffnet wird. Die Microsoft Management Console (MMC) braucht der Admin aber – die ist immer ausführbar.
Was ginge: Alle .msc-Dateien, die das Mark of the Web-Bit tragen, von der Ausführung in mmc.exe ausschließen – wüsste aber nicht, wie man dies bewerkstelligen könnte.
PS: Ich habe es mir beim Schreiben des Beitrags verkniffen, darauf hinzuweisen. In meinem ZUGFeRD-Artikel hatte ich auf Risiken bei XML-Dateien hingewiesen – mochten manche Leute nicht sehen. Hier haben wir ein Beispiel aus dem XML-Zoo, wo der Parser halt patzt.
"Was ginge: " … "wüsste aber nicht, wie man dies bewerkstelligen könnte. "
Geht also nicht. Applocker kann keine MSC-Dateien sperren. Applocker reagiert auch nicht auf "Mark the Web". Das ist eine andere Funktion, die nennt sich "Defender Smartscreen", die kann man ein und ausschalten, mehr nicht, und das Mark the Web Attribut kann jeder Benutzter mit 3 Mausklicks selbst entfernen, wenn man ihm davon überzeugt, wie wichtig eine Datei sein soll… Darauf ist also kein 100% Verlass. Besser wäre wohl Applocker.
"wenn applocker den Administratoren die Ausführung aller Dateien ebenfalls nicht erlaubt."
Das ist falsch, zumindestens, wenn man die von Microsoft für Applocker standardmäßig eingerichteten Regeln stehen lässt. Für Applocker werden für die Kategorien EXE+DLL, MSI und Setup, und Scripts diverse Default-Regeln angelegt. Dazu gehören.
everyone für %program files%\*
everyone für %systemroot% (=c:\windows\*)
administrators für *.exe
administrators für alle MSI und sonstige Setupdateien egal wo sie liegen
administrators für alle Scripts
(Anmerkung: Die Option für das applockern von DLL Dateien aktivieren auch nur die Wenigsten, denn das ist leider die Hölle, die abhängig von installierter Software, Treibern, Antivirus, … das ganze System lahm legen kann, wenn man was vergisst – und das geht schnell, Erklärung wird gleich klar!)
Die Admin-Regel weg zu lassen ist eine große Kunst, denn nicht alles, was ein System zum Starten braucht, liegt zwangsläufig nur in %program files% und %systemroot%, machnes liegt leider auch in c:\programdata, Kacktreiber auchmal in c:\dell\* oder c:\intel\* oder c:\nvidia\* usw., wer weiß welchen Teufel da MS und die anderen Hersteller wieder geritten hat, und zur Gruppe Administrators gehört leider auch der SYSTEM Account, und das wiederum kann bedeuten, dass die ganze Mühle in dem Moment nicht mehr hoch kommt, sobald beim Booten Applocker aktiviert wird, weil irgendwelche Treiber/Zusätze/AV/… nicht da liegen wo sie es sollten. Mit anderen Worten, die Regel für Admins nimmt in der Regel kein Admin raus, genauso wenig wie die 2 anderen Regeln für Everyone – siehe auch gleich was dann passiert. Damit kann man sich nämlich sehr ordentlich und amtlich ins Knie schießen. Wohl dem, der seine Experimente mit einer Testkiste im AD macht, wo man der Mühle per GPO wieder eine reparierte Applocker-GPO unterschieben kann, sonst steht eine Neuinstallation an…
Ich hab sowas mal erlebt, ist etwa 10 Jahre her, da hat ein indischer Dienstleister in einem global tätigen Konzern GPOs aufräumen sollen und dann in der EU-OU die wichtigsten Applocker-Regeln einfach gelöscht ohne Applocker zu deaktivieren und damit ganz Europa im Konzern (über 25.000 Workstations) innerhalb von Minuten lahm gelegt, nichtmal mehr winlogon.exe konnte gestartet werden… Es gab da noch ein kleines "gallisches Dorf", meine Citrix-VDIs, samst einer Admin-VDI-Gruppe mit allen nötigen RSAT-Tools, denen ich (heimlich) ein eigenes Applocker-Set verpasst hatte, von da konnte ich den Laden an dem Tag wieder aus dem Sumpf ziehen… Der Dienstleister wurde dann in eine Rakete gesteckt und ich hab nach Erklärung warum ich was eigenes gemacht habe "ne kleine" Belohnung bekommen. :)
hm … meine applocker Systeme haben seit langem SYSTEM zur Ausführung aller Dateien, es ist also nur eine minimale Anpassung der Standard Regeln. Administratoren sind eingeschränkt im ersten direkten klicken/ausführen
DLLs sind ebenfalls integriert. alles funktioniert, wie es soll. du benötigst halt zwingend ein Deployment im systemkontext, bzw ein Tool, das einem Admin eine cmd mit Systemrechten gibt, zb gsudo
Wieso antwortest Du noch nur UNSINN brabbelnden Kleinkindern, die nicht mal ihren Namen schreiben können!
JFTR: jeder nicht völlig ahnungslose Windows-Missbraucher konnte Ausführen beliebiger Dateien per Doppelklick sowie aller "portable executables" auf allen Wegen schon unter NT4 oder Windows 2000 per (vererbtem bzw. vererbbarem) NTFS-ACE "(D;OIIO;WP;;;WD) beispielsweise im Verzeichnis %USERPROFILE% unterbinden.
Ich bin eine Newsgroup Community Schlampe und glaube immer noch zu helfen und was verändern zu können ;-)
Mark: Helfen wirst Du in vielen Fällen können – ob wir beiden mit unseren Aktivitäten was verändern können, da habe ich meine Zweifel.
"Emily Postnews" meint seit (USENET-)Urzeiten "Schreiben Sie unter Ihrem Namen, seien Sie stolz auf Ihre Beiträge!"
1.
Betr. "Wieso antwortest Du noch nur UNSINN brabbelnden Kleinkindern, die nicht mal ihren Namen schreiben können!":
Frustriert?
2.
Betr. "konnte Ausführen beliebiger Dateien per Doppelklick sowie aller "portable executables" auf allen Wegen schon unter NT4 oder Windows 2000 per (vererbtem bzw. vererbbarem) NTFS-ACE "(D;OIIO;WP;;;WD) beispielsweise im Verzeichnis %USERPROFILE% unterbinden.":
Kann das jemand bestätigen? Der SDDL-String (D;OIIO;WP;;;WD) scheint ein Kanthaksches Eigengewächs zu sein. Wie sieht es mit der Ausführung von Binaries auf bzw. von Diskette, USB Flash Disks, Internet-/CIFS-/SMB-URL aus? Ich brauche etwas, was ich ggf. an zwei Auszubildende weitergeben kann. Also bitte instruktiv und verständlich.
Die auf https://skanthak.Homepage.t-online.de/SAFER.html verlinkten *_SAFER.INF definieren (aber erst seit 15 Jahren) *.MSC als "ausführbar", d.h. der Versuch, sie per Doppelklick, Start->Ausführen, WinExec(), ShellExecute*() oder CMD.exe START &ksaquo;pfadname.msc› an MMC.exe zu verfüttern wird blockiert.
Ob der Aufruf von "MMC.exe ‹pfadname.msc›" per CreateProcess() oder Kommandozeile blockiert wird habe ich nie getestet; sollte MMC.exe (wie beispielsweise WSCRIPT.exe/CSCRIPT.exe) "SRP-enlightened" sein, dann werden auch diese Aufrufe blockiert.
JFTR: der auf https://skanthak.Homepage.t-online.de/uacamole.html gezeigte UAC-Bypass kann mit dem ebenda gezeigten Einstellungen unterbunden werden.
keine der mir bekannten Security Baselines hat die UAC mit Autoelevation konfiguriert, die stehen alle auf "Prompt for …" oder "deny", je nach Baseline auch "… on the secure Desktop"
den Schiebe Regler "nach oben" hatte schon der Microsoft Security Compliance Manager, der Vorgänger des Security Compliance Toolkit und damit war das schon in 7, 8, 8.1 etc die Empfehlung.
Auto Elevation sehe ich nicht mehr als Angriffsvektor, jedenfalls bei denen, die sich an Richtlinien Vorlagen orientiert haben.
Man könnte die FileType Association anpassen. So dass beim Doppelklick die Datei im Notepad geöffnet wird. Allerdings müssen Admins dann die vorgefertigten MMC-Snapins (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools/event viewer.msc) aus einer MMC heraus laden. Das suchen nach "eventviewer" im Startmenü und der versucht dieses Snapin direkt aus den Suchergebnissen zu öffnen führt dann auch zu einer Anzeige der eventviewer.msc im Notepad.
Anzeige des Filehandlers zur Dateiendung:
>assoc .msc
.msc=MSCFile
Anzeige des aktuell zugeordneten Programs zum Filehandler:
>ftype MSCFile
MSCFile=%SystemRoot%\system32\mmc.exe "%1" %*
Anpassung des Programms auf notepad.exe:
>ftype MSCFile="C:\Windows\system32\notepad.exe" "%1"
MSCFile="C:\Windows\system32\notepad.exe" "%1"
Alternativ der Registrykey:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mscfile\shell\open\command>>>REG_EXPAND_SZ:"C:\Windows\system32\notepad.exe" "%1"
eventvwr.exe existiert … :-)
Nicht nur das: Kleinkinder, die noch nicht mal seinen eigenen Namen schreiben können, brabbeln generell VÖLLIG ahnungslos daher und sabbern HANEBÜCHENEN, gefährlichen UNSINN!
Der Explorer (genauer: ShellExecute*()) verwendet (aber erst seit 23 Jahren)
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\FileExts\.‹Extension›]
Ausserdem überlagert (aber erst seit 25 Jahren)
[HKEY_CURRENT_USER\Software\Classes]
die (von ASSOC und FTYPE) unter
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes]
abgelegten Einstellungen.
Siehe https://msdn.microsoft.com/en-us/library/ms724498.aspx
Dann ist doch gut, dass es brauchbare Alternativen gibt, eventuell jedoch nicht für alle .msc-files die sich hinter den Verknüpfungen im besagten "Administrative Tools"-Ordner befinden.
Ich wollte hier lediglich einen effektiven Schutz vor der versehentlichen Ausführung per Doppelklick durch unbedarfte Anwender aufzeigen.
Ich habe mir auch den sachlichen Teil Ihrer Antwort praktisch angeschaut, Überlagern funktioniert nur wenn auch entsprechende Einträgen für mscfiles vorhanden wären. Ich konnte auf meinen Windows VMs (Windows 10+11 ) in den genannten Pfaden keine Einträge für "mscfiles" bzw. ".msc" finden.
Falls Sie tatsächlich konkrete Gefahren in dem Vorgehen sehen freut sich die Leserschaft sicherlich über entsprechenden sachlichen Hinweis.