[English]In Windows 10, Windows 11 (und auch in den Server Pendants) schlummert ein fettes Sicherheitsdesaster. Angreifer können "Schein-Ordner" erzeugen und dort Schadprogramme speichern. Anschließend ist der Weg offen, um diese Schadprogramme mit Administratorrechten (ohne UAC-Abfrage) zu starten. Sicherheitsfunktionen wie AppLocker oder Software Restriction Policies (SRP oder kurz SAFER) greifen wohl auch nicht mehr. Ist Sicherheitskreisen bekannt, das Thema ist jetzt durch einen Angriff in mein Radar gekommen.
Anzeige
Eine Phishing-Kampagne
Aktuell gibt es wohl eine neue Phishing-Kampagne, die auf Unternehmen in osteuropäischen Ländern zielt. Denen soll die Remcos RAT-Malware untergejubelt werden – mit dem Remote Access Tool (RAT) können die Angreifer dann auf die infizierten Systeme zugreifen. Sicherheitsforscher von Sentinel One haben diese Kampagne in diesem Blog-Beitrag dokumentiert. Die Kollegen von Bleeping Computer hatten das in diesem Beitrag aufgegriffen.
Anatomie des Angriffs per DBatLoader
Im Sentinel One-Artikel wird erklärt, wie der Angriff abläuft, um die Remcos RAT-Malware auf das System zu bringen. Im Anhang der Phishing-E-Mails ist ein tar.lz-Archiv enthalten. Dort sind die DBatLoader-Dateien drin, die sich normalerweise als Microsoft Office-, LibreOffice- oder PDF-Dokumente tarnen, indem sie doppelte Erweiterungen und/oder Anwendungssymbole verwenden, aber die Remcos RAT-Malware beinhalten.
Dekomprimiert der Empfänger der Phishing-Mail dieses Archiv und führt die entpackte, ausführbare Datei aus, lädt DBatLoader eine verschleierte zweite Stufe der Nutzdaten von einem öffentlichen Cloud-Speicherort (Google Drive, OneDrive) herunter und führt sie aus. Die Sicherheitsforscher schreiben:
Die Malware erstellt dann ein erstes Windows-Batch-Skript im Verzeichnis %Public%\Libraries und führt es aus. Dieses Skript missbraucht eine bekannte Methode zur Umgehung der Windows-Benutzerkontensteuerung, bei der vertrauenswürdige Verzeichnisse, wie z. B. %SystemRoot%\System32, durch die Verwendung von Leerzeichen am Ende des Skripts vorgetäuscht werden. Dies ermöglicht es den Angreifern, erweiterte Aktivitäten auszuführen, ohne dass die Benutzer alarmiert werden.
Ich hatte es am Rande bei den Kollegen von Bleeping Computer mitbekommen, das Ganze aber in seiner Brisanz nicht erfasst. Daher bereite ich den Sachverhalt nachfolgend mal separat auf.
Anzeige
Büchse der Pandora: Windows "Schein-Ordner"
Microsoft hat mit Windows Vista zwar die Benutzerkontensteuerung (UAC) eingeführt, um die Anforderung von erhöhten Benutzerrechten durch Anwendungen über eine UAC-Meldung vom Benutzer bestätigen zu lassen. Standardnutzer benötigen dazu ein Administrator-Konten-Kennwort. Aber es gibt zwei Fallen, die das Ganze löchrig wie einen Schweizer Käse werden lassen.
Windows-Ordner als UAC-Ausnahme
Ich gestehe, es war mich bisher unklar bzw. ich habe nie darüber nachgedacht. Microsoft hat in Windows sogenannte trusted (vertrauenswürdige) Ordner festgelegt. Ein Programm, welches beim Starten erhöhte Benutzerrechte benötigt, löst, wenn weitere Voraussetzungen vorliegen, dann keine Nachfrage der Benutzerkontensteuerung aus.
Davis Wellis hat das 2018 im Beitrag UAC Bypass by Mocking Trusted Directories auf Medium aufgedeckt. Neben der Vorgabe im Manifest, dass eine Auto-Elevation der Benutzerrechte erfolgen soll (dann fordert das Programm die erhöhten Benutzerrechte beim Start automatisch an, was die UAC-Nachfrage auslöst), muss das Programm korrekt digital signiert sein. Und als letzte Bedingung muss das Programm in einer Trusted-Directory wie:
"C:\Windows\System32"
liegen. Dann erhält der zugehörige Prozess erhöhte Systemrechte per Auto-Elevation, ohne dass eine UAC-Nachfrage angezeigt wird.
Problem Scheinordner (Mocked Folder)
Leider gibt es noch eine zweite Schwachstelle in Windows, die als "Mocked-Folder" (deutsch Scheinordner) segelt. Man kann als Benutzer Ordner anlegen, die ähnliche Namen wie die Trusted-Folder von Windows haben. Dazu hängt man ein Leerzeichen an diesen Namen an.
Mocked Folders des DBatLoader, Quelle: Sentinel One
Die Sentinel One-Sicherheitsforscher haben den entsprechenden Code des DBatLoader-Scripts, welches die Scheinordner (Mocked-Folders) anlegt, in obigem Bild öffentlich gemacht. Es wird ein Verzeichnis:
"C:\Windows \System32 "
im Wurzelverzeichnis des Systemlaufwerks C:\, auf dem Windows liegt, eingerichtet. Dort hat der Angreifer als normaler Nutzer Schreib-/Leserechte und kann seine schädlichen Dateien (z.B. DLLs) in diesem Ordner ablegen. Weiterhin legt der Angreifer Kopien legitimer Binärdateien aus dem Windows System32-Ordner mit im Scheinordner ab.
Wird nun die Kopie der Binärdatei (die aus dem legitimen Windows System32-Ordner stammt und korrekt digital signiert ist) aus dem Scheinordner aufgerufen, startet diese per Auto-Elevation mit erhöhten Rechten ohne eine UAC-Abfrage auszulösen. Gleichzeitig wird eine vom Programm erwartete DLL, sofern diese im gleichen Scheinordner liegt, per DLL-Hijacking, mitgeladen. Schon hat der Angreifer erhöhte Berechtigungen, ohne dass ein Benutzer davon etwas mitbekommen. Jean Maes hat dies am 11. Juli 2020 im Artikel UAC bypass through Trusted Folder abuse auf seiner Seite "Red Team Tipps" öffentlich gemacht.
Abgründe und erschrockener Blog-Leser
Ich gehe an dieser Stelle nicht auf den oben angerissenen Phishing-Angriff zur Verteilung der Remcos RAT-Malware ein. Die nutzen genau diesen Angriffsweg. Und ich werde auch die auf meine Artikel zum "DLL-Highjacking" häufig gegebenen Kommentare "was nutzt es, wenn der Angreifer keine Admin-Rechte hat" eingehen – auf UAC-Bypassing-Methoden hatte ich im Blog ja mehrfach hingewiesen. Aber die Geschichte hat noch einen netten Schlenker. Blog-Leser 1ST1 hat sich die Thematik, bevor ich diese aufbereiten konnte, mal näher angesehen und seinen Eindruck als Kommentar hinterlassen (danke dafür, mir fehlt dazu die Zeit). Ich ziehe mal seine Ausführungen heraus:
Hat auch was mit Windows-Härtung zu tun… (Und ich bin gerade ziemlich entsetzt darüber…)
Mir ist es gerade als normaler Benutzer gelungen, mit einfachstem Mittel den Applocker, SAFER und UAC zu umgehen. Ausgangspunkt: CMD.exe ohne lokale Adminrechte (ist ein separater Benutzer)
Schon ein seltsames Verhalten:
md "c:\Windows "
Ein Unterverzeichnis oder eine Datei mit dem Namen "Windows " existiert bereits.
Man beachte dass für cmd "Windows" und "Windows " das Gleiche ist. Lässt sich aber austricksen…
md "\\?\C:\Windows " md "\\?\C:\Windows \system32" copy c:\users\1ST1\downloads\harmlose.exe "\\?\C:\Windows \system32" start "\\?\C:\Windows \system32\harmlose.exe"Im Eventviewer, Microsoft-Windows-AppLocker/EXE and DLL
Event 8002, Applocker: Die Ausführung von %osdrive%\windows \system32\harmlose.exe wurde zugelassen.copy c:\users\1ST1\downloads\harmlose_setup.exe "\\?\C:\Windows \system32" start "\\?\C:\Windows \system32\harmlose_setup.exe"Im Eventviewer, Microsoft-Windows-AppLocker/Packaged app-Deployment
Event 8023, Applocker: Die Installation von %osdrive%\windows \system32\harmlose_setup.exe wurde zugelassen.Und UAC meldet sich bei der setup.exe auch nicht.
In Applocker per GPO gibt es folgende Regeln für EXE und DLL, alternativ, beide werden überlistet:
Allow everyone c:\windows\*
Allow everyone %systemroot%\*Wie man sieht, ist dort vor "\*" kein Leerzeichen. (Man darf bloß nicht beide gleichzeitig ausschalten… :-X Auf garkeinen Fall! Wirklich! Sonst ist Sense… R.I.P.)
copy c:\users\1ST1\downloads\von_av_ausgeschlossenes_verzeichnis\eicar.exe \\?\C:\Windows \system32-> Dabei schlägt wenigstens der Antivirus zu und verhindert schlimmeres.
Was passiert da? Gesehen?
Der Trick ist das Leerzeichen " " zwischen "Windows" und dem Backslash "\". Das wird von CMD, Applocker, Safer und UAC nicht richtig geprüft. Powershell wahrscheinlich auch nicht… In c:\ gibts gerade zwei Windows-Ordner untereinander…, genauer:
"c:\windows"
"c:\windows "Seht ihr den Unterschied? Wenn man in den Zweiten rein geht, sieht man komischerweise alle Dateien und Ordner aus dem Ersten. Im Ordner "c:\windows \system32" liegt aber nach obigem Test nur harmlose.exe und harmlose_setup.exe. Dagegen in "c:\windows\system32" liegt alles rum, was da hin gehört. Das Ganze funktioniert übrigens auch mit "%programfiles% ", "program files " und "program files (x86) "…
Grundlage des Tests war dieser Artikel.
WTF!?!?!?Abhilfe? Per Applocker/SAFER "c:\windows \*" zu sperren, traue ich mich nicht, weil das garantiert auch verwechselt wird… Vielleicht "c:\windows?\*" sperren? Sieht erfolgsversprechend aus, aber was ist dann mit "c:\windows??\*", "c:\windows???\*", … (oder geht "c:\windows?*\*" ???) – risky…
Hilfe, Redmond!!! (Patchday ist erst am 14., also noch 1 Woche Zeit, das zu patchen…)
Die Hoffnung auf einen "Patch" zum 14. März 2023 muss ich aber pulverisieren. Ich hatte Stefan Kanthak hinter den Kulissen angemailt und auf diese Thematik angesprochen. Seine Replik "alles kalter Kaffee" findet sich in diesem Kommentar, den ich hier in Auszügen herausziehe:
- Auf Securelist ist im April 2021 das Thema im Artikel Defense in depth — the Microsoft way (part 75): Bypass of SAFER alias Software Restriction Policies NOT FIXED von Stefan angesprochen worden (SAFER sind die Software Restriction Policies, SRP).
- Auf Securelist ist im April 2021 das Thema im Artikel Defense in depth — The Microsoft way (part 76): arbitrary code execution WITH elevation of privilege in user-writable directories below %SystemRoot% von Stefan angesprochen worden.
Dazu schreibt Stefan Kanthak, dass (wie leider üblich) die jungen Leute beim MSRC (Microsoft Security Response Center) nicht kapiert haben, dass das nicht nur eine UAC-Umgehung ist (für die Microsoft prinzipiell keine Korrektur bereitstellt), sondern auch SAFER und AppLocker aushebelt (wofür sie ebenso prinzipiell auch keine Korrektur bereitstellen).
In seinem Kommentar verlinkt Stefan Kanthak dann noch auf Beiträge bei ihm, Schneegans und Securelist, wo das ebenfalls vor langer Zeit angesprochen wurde. Auch weist er (wohl als Antwort auf diesen Kommentar) darauf hin, dass vom Benutzer gesetzte (permanente oder flüchtige) Umgebungsvariablen wie %SystemRoot% und %ProgramFiles% die (vom Administrator gesetzten) gleichnamigen Umgebungsvariablen des Systems überlagern. Auch das ist bekannt und wurde von Kanthak mit verlinkten Quellen belegt.
Anzeige
Es müsste doch folgendes theoretisch den Angriffsweg blockieren:
Einfach diese Ordner mit Leerzeichen vor dem \ anlegen und dann für die angelegten Ordner entsprechende Berechtigungen vergeben, z.B. ganz brutal auch für SYSTEM, TRUSTED INSTALLER, alle Benutzer, etc. explizit den Zugriff verweigern.
Dann hat wirklich niemand mehr Zugriff auf diese Ordner.
Danach kann man diese Ordner zwar nie mehr löschen oder die Berechtigungen ändern, aber will man das denn, wenn damit ein Sicherheitsrisiko verbunden ist?
Das ist eine gute Idee, einfach als Härtungsmaßnahme die Ordner schonmal anlegen und Berechtigungen entziehen! Aber wieviele Ordner muss man anlegen, nämlich auch mit 2 Leerzeichen, mit 3 Leerzeichen, usw.?!?
Zum Glück aber greift ja schon Applocker beim Ausführen des Scripts in %Public%, der Angreifer hat es folglich schwer, sein Script zu lancieren.
1) Diese "Angreifer" sind ganz offensichtlich VÖLLIG verblödet: da Windows in Standard-Installationen *.tar.lz nicht öffnen bzw. entpacken kann funktioniert deren "Kampagne" dort nicht.
2) Windows-Missbraucher, die sich unsicheren SCHROTT wie 7-zip eingetreten haben, der solche Archive entpacken kann, müssen ebenfalls völlig verblödet sein, um den (durch RICHTIGE Konfiguration von SAFER, AppLocker oder WDAC trivial abwehrbaren) "Angriff" durch Ausführen einer der entpackten Dateien letztendlich SELBST durchzuführen.
3) Letzteres gilt natürlich auch für die 2. bzw. 3., unter %PUBLIC% abgelegte Stufe.
Last but not least:
4) Ratet mal, wieso unprivilegierte Benutzer ab Windows 11 keine Verzeichnisse mehr in %SystemDrive% anlegen können?
Oh, einen hab ich noch:
5) Wieso hat das bei den armen, erfolgreich, angegriffenen Tröpfen das dort doch garantiert missbrauchte Schlangenöl diesen seit mindestens 20 Jahren bekannten Angriffsweg nicht gestopft?
zu 2) leider kann Windows immer noch keine passwortgeschützten Archive öffnen oder erstellen -> folglich greift man zu Software.
zu 2)
Leider kann Windows 10 nur das alte und nicht sehr performante Deflate in Zip-Archiven nutzen, Windows 11 keine Ahnung. Verwende ich z.B. LZMA, so geht das Packen in der Hälfe der Zeit und wird dabei noch deutlich besser komprimiert. Gerade wer viele CAD-Daten auch per Mail austauschen muss, freut sich über jedes Prozent Komprimierung.
Gruß Singlethreaded
Mich verwundert, dass Sie regelmäßig die Verwendung von SAFER und Applocker empfehlen, ohne auf dieses Ihnen scheinbar schon länger bekannte Problem hinzuweisen.
Macht er doch. Steht hier gleich als erster Punkt: https://skanthak.homepage.t-online.de/SAFER.html#loopholes
SRP und Applocker in der Standardkonfiguration waren immer ein erster Schritt und drigend zu empfehlen, aber noch nie ausreichend.
Die Verwendung von SRP/Applocker und sei es auch nur in der Standardkpnfiguration verhindert schon die Ausführung von einer ganzen Menge Mist. Va. wenn man noch die Ordner Desktop und Downloads hinzufügt. Dort versuchen es die Nutzer doch zuerst und es trainiert auch Verhalten. Eine verhinderte Ausführung suggeriert dem Anwender immer "oh Achtung die Aktion war wahrscheinlich nicht gewünscht".
Natürlich jedes System hat Lücken. Und dass man die System nicht einem einfachen Leerzeichen umgehen kann war mir weder bewusst noch bekannt.
Auf meinen System hätte das Skript vrmtl doch keine Wirkung erzielt, weil
(a) der Nutzer nichts ausführen kann, was nicht in einem Ordner liegt aus dem die Ausführung erlaubt ist und er eben zu diesen Ordnern keine (Schreib-)rechte hat und
(b) weil ein Nutzer weder Daten unter %systemdrive% ablegen bzw. dort Ordner anlegen kann. Ich wüsste auch nicht wieso.
Der ursprüngliche Gedanke kam aber mal daher, dass wir diese Ordner nicht in eine Datensicherung einbeziehen und deswegen dort nichts liegen haben möchten.
Jetzt kommt der nächste und jaaa, wie aufwendig so eine Konfiguration und Pflege. Dazu kann ich nur sagen STIMMT!!
Es ist vollkommen unverständlich wieso Windows immer noch kein funktionierendes Rechte/Datenkonzept hat bestehend aus Systemdateien, Programmdateien, temporäre Programmdateien und Nutzerdaten.
Ich meine selbst MS ballert sowas wie MS Teams als Installer in ein Nutzerverzeichnis. Oder Onedrive (im Standardverhalten).
Ey MS f* euch!
Wenn man möchte dass man legitime Kritik nicht ernst nimmt, dann verpackt man diese mit Angriffen und unflätiger Sprache und voila, Bärendienst erreicht.
Dumm ist nicht nur der, der dummes tut, sondern auch der, der dumm kommuniziert :)
Wohlgemeinte Hinweise an Microsoft sind mit Sicherheit in einem anderen Ton formuliert. Werden diese ignoriert, kann ich rhetorische Verärgerung durchaus nachvollziehen.
Ich habe schon immer nicht verstanden, dass Windows im ROOT-Verzeichnis Ordnernamen mit Leerzeichen erlaubt. Ich gebe dafür einen Unterstrich ein (_).
Gewachsen ist das aus alter DOS-Zeit, wo ein Leerzeichen grundsätzlich zu Fehlern führte.
Heißt der Windows-Backup-Ordner doch C:\Windows old\???
Der Backupfolder heißt Windows.old
Ich hoffe, dass das Problem durch diesen und hoffentlich weitere Artikel größere Wellen schlägt und MS dazu gezwungen wird, das abzustellen. Windows muss endlich zwischen "Windows" und "Windows " unterscheiden lernen, dann ist das alles kein Problem mehr.
Die simple UAC Umgehung mittels Leerstellen-Trick finde ich auch schlimm. Somit könnten ja auch versierte User in größeren Unternehmen, wo eigentlich jeder eingeschränkte Nutzerrechte hat, einfach sich Admin Rechte erschleichen und tun was sie wollen.
Bei uns ist das erstellen von Ordner auf Laufwerksebene schon ewig unterbunden.
Schreibrechte gibts im Userprofil und im Temp.
scheinbar ist das Problem also schon länger "bekannt"
Man kann ein Systemnatürlich auch bis zu Unbenutzbarkeit kastrieren. Was das dann noch mit einem *personal* Computer zu tun haben soll bleibt mir ein Rätsel. Personal bedeutet nun mal, daß der Nutzer darüber entscheidet, welche Programme er nutzen will. Das problem ist ganz allein Microsoft, weil es die laterale Ausbreitung von Schadsoftware in einer Domäne begünstigt. Deshalb die nutzer aufgrund der fehlentscheidung zu Windows und Microsoft ihrer Produktivität zu berauben ist nicht unbedingt eine sinnvolle Maßnahme. Zudem begünstigt es die Schatten-EDV. Leider weitverbreiteter Unfug der IT Abteilungen.
Windows sollte auch mal lernen, *per default* zwischen "Windows", "WINDOWS" und "WINdows" sauber und verlässlich zu unterscheiden. Das kann es auch in 2023 noch nicht. Ebenso der Auschluss diverser Zeichen oder Zeichenfolgen für Namen von Dateien und Ordnern nervt.
Aber die Krönung des ganzen ist ja, dass es nur in den gängigen Programmen (Explorer/CMD) auf gewohntem Weg nicht geht, unter Zuhilfenahme gewisser kleiner Tricks (UNC-Pfad) dann aber wohl.
Der Witz ist, das NTFS sehr wohl zwischen Groß- und Kleischreibung unterscheidet.
Für NTFS ist Windows und WIndows nicht das gleiche.
Nur der NTFS-Treiber von Windows beschränkt das künstlich.
Im Übrigen auch die Pfadlänge und die Partitionsgröße.
NTFS unterstützt bis zu 16 EiB Partitionsgröße, der NTFS-Treiber in Windows beschränkt es aber auf 256 TiB.
Windows beschränkt die Pfadlänge auf 260 Zeichen, NTFS kann aber max. 65535 Zeichen.
Ab Windows 10 kann man das 260 Zeichen Limit übrigens per Gruppenrichtlinie aufheben.
NTFS erlaubt auch alle Zeichen mit 2 Ausnahmen NULL und /.
Nur Windows selbst schränkt es noch etwas ein, weil diese Zeichen eine Funktion in Windows haben.
Bestimme Dateinamen sind reserviert, weil die fürs Betriebssystem benötigt werden, wie z.B. $MFT.
https://administrator.de/forum/ordner-erstellen-auf-c-unterbinden-1318480641.html
Besten Dank!
Ich habe mir das mal angeguckt, und stecke jetzt beim letzten Schritt fest der nicht in der Anleitung auftaucht:
O Datei oder Ordner konfigurieren und anschließend:
O vererbbare Berechtigung an alle Unterordner und Dateien verteilen
O vorhanden Berechtigungen für alle Unterordner und Dateien vererbbaren Berechtigungen ersetzen
O Ersetzen der Datei- oder Ordnerberechtigungen nicht zulassen
Welche der 3 Optionen wäre jetzt die richtige??
Hat sich erledigt, manchmal muss man nur richtig gucken :D
Es ist "vererbbare Berechtigung an alle Unterordner und Dateien verteilen"
habs mir noch nicht genauer angesehen, aber überschreibt man damit nicht die Berechtigung von z.b. Program Files mit den authentifizierten Usern auf "Ändern" ?
die Rootsec.inf war Bestandteil der Sicherheitsrichtlinien in Windows 2000
https://www.gruppenrichtlinien.de/artikel/rootsecinf-keine-ordner-auf-c-erstellen
Mark Russinovich hatte bereits vor Jahren in einem seiner Videos unter Windows7 zum besten gegeben: Ziel der UAC sei keine Sicherheit sondern den User zu sensibilisieren – mit einem Verweis darauf das die technisch UAC umgangen werden kann :-)
Und so wird bei Microsoft seit Jahren eine Sicherheitsschicht über die nächste Gefriemelt. Bis hin zu SecureBoot, VBR, doppelter Virenscanner, etc. pp.
Und dennoch: keine greift richtig, weil das zugrundeliegende System vermurkster 90er Jahre Crap ist, bei dem Benutzerfreundlichkeit, Abwärtskompatibilität zu Windows3 und Eyecandy im Vordergrund standen.
Und heute lässt sich das ganze nicht mehr trivial aufräumen, da es die Kompatibiltät der Applikationen zerstören würde…
"Benutzerfreundlichkeit" stand ganz bestimmt nicht im Vordergrund, sondern nur die Gewinnmaximierung von Microsoft.
Mal ne ganz abstrakte Idee: Den Usern verbieten, Ordner und Dateien direkt auf C: anzulegen, sollte doch das Problem beheben. Machen wir in der Firma seit Jahren so…
Auf unseren Terminalservern (2016) wurde auf Laufwerk C: (ohne Vererbung) das Recht verweigert, dass normale Benutzer Ordner erzeugen dürfen.
Diese "Lücke" ist seit Jahren bekannt.
Dann solltet ihr mal den Admin entlassen, weil das ist ein bekannter Konfigurationsfehler.
Danke für den Artikel. Auch wenn die Lücken nicht neu sein mögen, ist es doch wichtig, wenn sie aktiv ausgenutzt werden. Sehr schön sind auch die Links, so kann man selbst nachlesen, wenn man möchte.
Warum nur darf bei Windows ein Benutzer im Hauptverzeichnis Dateien und Verzeichnisse anlegen? Das habe ich nie verstanden. Gibt es dann einen validen Anwendungsfall dafür? Da fallen mir noch viele weitere Probleme ein, die das verursachen kann! Wie kommt man denn nur auf solche Ideen…
Für mich klingt es ja so, als ob UAC kontraproduktiv sind, weil sie fälschliche Sicherheit aufgegriffen, oder?
Das die Prüfung gegen Whitelists Probleme mit Leerzeichen hat, ist ja wohl ein klarer Bug, der über die Gewährleistung korrigiert werden muss (oder schreiben die es auf, weil es dann dokumentiert ist und kein Fehler?).
… und wenn wir den Fix haben, gucken wir Unicode-Zeichen durch. Wenn die nicht Bytefolgen vergleichen, sondern irgendwie semantisch vergleichen, dann funktioniert vielleicht einer der vielen Unicode-Tricks auch…
Sicher das das wirklich so gehen soll? Gerade mal ausprobiert. Bei mir schlägt die UAC weiterhin an auch wenn es in einem Ordner mit Leerzeichen ist.
geht mir auch so.
die UAC hat ja auf höchster Stufe keine AutoElevation.
keine Ordner im Systemdrive erstellen und UAC auf Stufe 4 sollte die Probleme abfangen.
Mal so ne ganz berechtigte Frage…. Wie bekomme ich alle, Geschäftsleitung, Entwickler, usw. dazu auf ihre Adminrechte zu verzichten? Wie macht ihr das mit Adminrechten und falls doch mal einer welche braucht? Gibt ja auch so Programme, die das dynamisch steuern können so wie PMW von BeyondTrust.
Entwickler haben bei uns ein zweites Konto
z.b.
paa.mmustermann (Privileged Admin Access)
mmustermann (Arbeitskonto) Email + Internet …
das paa konto ist nur berechtigt scih auf seinem rechner anzumelden (im AD hinterlegen). dieses paa Konto hat an seinem Rechner administrative Rechte.
Nutzen dafür ein AD Gruppe wo das Konto drin ist und die AD Gruppe wiederum in der lokalen Administrator Gruppe des rechners. durch die Einschränkung sich nur an diesen eine best Rechner anzumelden muss das paa Konto ledigl in die AD Gruppe aufgenommen werden.
User ist angehalten nur mit RunAs (Ausführen als) falls Admin rechte benötigt werden zu arbeiten. nur in Ausnahmen sich mit dem Konto anzumelden.
Also ich würde gerade behaupten wollen, dass SAFER hier mittlerweile obwohl für Tod erklärt doch cleverer geworden ist. Gerade auf einem W10Enterprise (eval) getestet:
Befehl: start "C:\windows \system32\wget-1.11.4-1-setup.exe"
Antwort: "Error 1260: This program is blocked by group policy."
Befehl: start "\\?\C:\Windows \System32\wget-1.11.4-1-setup.exe"
Antwort: "This command cannot be run due to the error: The system cannot find the file specified."
Deaktiviere ich SAFER, kann die wget…setup.exe zwar aufgerufen werden, verursacht aber eine UAC-Abfrage. An der VM wurden zuvor KEINE weiteren Härtungsmaßnahmen vorgenommen.
Kann das noch jemand bestätigen?
Kannst Du dokumentieren, warum dies ein bekannter Konfigurationsfehler ist und andere dies angeblich erfolgreich umsetzen?
Hallo,
ich habe das oben beschriebene Problem auf meinem Rechner. Ich kann mich aber nicht entsinnen jemals eine fremde , ungescannte Datei auf dem Rechner ausgeführt zu haben.
Wie kann man den Windows Folder wieder löschen ohne das System komplett neu aufzusetzen? Eine Recovery Installation konnte das Problem nicht lösen
Ein nicht minder gefährliches Problem besteht auch mit Diensten, wo der Pfad ein Leerzeichen enthält und nicht in Anführungszeichen gesetzt wurde. Da lassen sich die Pfade mit selbsterstellten Dateien/Ordnern mit dem Teil hinter dem Leerzeichen bis zum nächsten Backslash kapern und so SYSTEM Rechte aneignen.
Passiert bei Drittsoftware häufiger als man denkt.
Das funktioniert übrigens auch, wenn der User (warum auch immer) Schreibrechte auf die .exe hat die der Dienst ausführt.