Gerade ist eine neue Methode bekannt geworden, um die Sicherheitsabfrage der Benutzerkontensteuerung unter Windows 10 mit fodhelper.exe zu umgehen. Hier ein paar Informationen zum Thema UAC-Bypassing unter Verwendung der fodhelper.exe.
Anzeige
UAC und filtered Token, was ist das?
Sowohl Standard-Benutzerkonten als auch Administratorkonten bekommen bei der Anmeldung nur ein Standard-Sicherheitstoken (filtered Token), welches keine administrativen Berechtigungen verleiht. Für administrative Aufgaben fordert der Prozess administrative Berechtigungen von Windows an. Das betreffende Sicherheitstoken bekommt der Prozess (seit Windows Vista) beim Aufruf über die Benutzerkontensteuerung (User Account Control, UAC) zugeteilt.
Viele Windows-Funktionen, die administrative Berechtigungen erfordern, sind mit einem stilisierten Schild (siehe folgender Screenshot) gekennzeichnet und bei Anwahl erscheint dann die Abfrage der Benutzerkontensteuerung (UAC) zur Zuteilung des administrativen Sicherheitstokens. Das soll die ungewollte Ausführung administrativer Aufgaben verhindern, der Nutzer muss mit Administratorberechtigungen explizit zustimmen.
UAC-Bypassing, was ist das?
In den Standardeinstellungen ist die Benutzerkontensteuerungsabfrage seit Windows 7 auf das nachfolgend gezeigte Level voreingestellt.
Anzeige
Benachrichtigungen durch die UAC erfolgen nicht, wenn unter einem Administratorkonto Änderungen an den Windows-Einstellungen vorgenommen werden. Sprich: Einem Administrator, der unter einem Administratorkonto arbeitet, werden bei einigen Funktionen ein paar Klicks erspart. Allerdings kann das durch Malware mit dem im Blog-Beitrag Erebus Ransomware und die ausgetrickste UAC skizzierten UAC-Bypass-Ansatz ausgehebelt werden. Die Malware kann administrative Berechtigungen erlangen, ohne dass der Benutzer das mitbekommt. Dieser Vorgang wird als UAC-Bypassing bezeichnet.
Abhilfe schafft entweder, den obigen Schieberegler auf die oberste Stellung zu setzen. Oder man arbeitet unter Standard-Benutzerkonten. Dann muss die Benutzerkontensteuerung explizit nachfragen (das Administratorkonto muss ja angegeben werden).
Ich hatte das Thema etwas dedizierter im Blog-Beitrag Windows 10-Administration: Fehlentwicklung in Sachen Sicherheit? beleuchtet und darauf hingewiesen, dass unter Windows 10 viele Aufgaben in der neuen Einstellungen-App zwingend unter Administatorkonten ausgeführt werden müssen (unter Standardbenutzerkonten fehlen die betreffenden Befehle). Tenor aus der Kommentarlage zum Artikel: Ist doch kein Problem, melde ich mich für diese Aufgaben am Administratorkonto an …
Die nächste UAC-Bypassing Methode fodhelper.exe
Die Methode wurde von einem deutschen Studenten mit Namen Christian B. im Rahmen einer Masterarbeit zum Thema 'UAC Bypassing Methoden' entwickelt. Dazu hat er die im Blog-Beitrag Erebus Ransomware und die ausgetrickste UAC skizzierte UAC-Bypass-Methode variiert. Statt auf die Ereignisanzeige (eventvwr.exe) zu setzen, verwendet er das Programm fodhelper.exe. Dieses Programm kommt zum Einsatz, wenn man in der Einstellungen-App auf die Kategorie Apps & Features anwählt.
Dann kann man den Hyperlink Optionale Features verwalten anklicken, wodurch folgende Seite erscheint.
Über Features hinzufügen lassen sich dann weitere Features installieren (was administrative Berechtigungen erfordert). Bei fodhelper.exe handelt es sich um eine 'trusted binary', die administrative Berechtigungen anfordert, ohne dass die Benutzerkontensteuerungsabfrage (unter einem Administratorkonto) angezeigt wird.
Christian B. hat nun herausgefunden, dass Windows 10 beim Start der fodhelper.exe in zwei Registrierungsschlüsseln nach zusätzlichen Befehlen nachschaut. Diese geben an, was beim Start des Programms zu machen ist. Ein Registrierungsschlüssel liegt unter:
HKey_Current_User\Software\Classes\ms-settings\shell\open\command\(default)Die Schlüssel in diesem Zweig sind editierbar – wobei es den obigen Eintrag ms-settings in meinen Testmaschinen nicht gibt. Die Details sind in diesem Beitrag beschrieben. Ein Malware-Autor kann diesen Ansatz verwenden, um über einen Registrierungseintrag (z.B. per Skripting) einen Befehl mittels fodhelper.exe mit administrativen Berechtigungen auszuführen. Der Aufruf von fodhelper.exe löst keine Nachfrage der Benutzerkontensteuerung aus, weil er zu den vertrauenswürdigen Elementen/Befehlen gehört. Auf GitHub wurde ein Proof of Concept vorgestellt, welches diesen Ansatz ausnutzt.
Aktuell gibt es keinen Patch gegen diese UAC-Bypassing-Lücke – helfen sollte nur das Arbeiten unter Standard-Benutzerkonten (sowie die Anpassung der UAC-Einstellungen auf die höchste Stufe). Weitere Hinweise finden sich in diesem Bleeping Computer-Beitrag.
Danke an die Blog-Leser, die mich in der Nacht bereits per Mail auf das Thema hinwiesen (hatte das seit gestern auf dem Radar, bin aber noch nicht dazu gekommen).
Ähnliche Artikel:
Erebus Ransomware und die ausgetrickste UAC
Windows 10-Administration: Fehlentwicklung in Sachen Sicherheit?
Windows: Fehlende Administratorrechte stopfen 94% aller Sicherheitslücken!
Anzeige
Ist diese neue UAC-Bypassing Methode denn auch anwendbar, wenn ich mit einem Admin-Konto arbeite, aber den UAC-Regler auf der höchsten Stufe habe?
Ist vom Folgeposter beantwortet worden – und steht indirekt in obigem Text: Wenn man die UAC-Einstellungen auf die höchste Stufe stellt, muss die Nachfrage immer kommen (Vista-Modus). Damit sind alle UAC-Bypassing-Ansätze, die den beschriebenen Mechanismus (egal ob mit EventViewer oder ähnlichem) verwenden, nicht mehr funktionsfähig.
Hmm, es gibt ja so Programme, die sich ihre "Admin" Rechte über die Aufgabenplanung mit einem extra Programm holen, welches dort gestartet wird.
Wenn ich mich recht entsinne, ist der beliebte CCleaner so ein Kandidat, hab aber auch schon andere gesehen, die mir aber spontan nicht einfallen. Ja gut, diverse Updater…
Geht das auch in diese Richtung des Ausnutzens um die UAC zu umschiffen, oder wäre das da auch denkbar? Also das Fremd/Schadprogramme sich da mitbedienen?
Nein, das Problem sitzt tiefer. Die fodhelper.exe ist Teil der Einstellungen und ruft den Dialog Opionale Features verwalten auf. Ein ganz normale, erlaubte Funktion. Wenn mal also die UAC-Meldung bekommt, wird einem diese Funktion angezeigt. Und man wird u.U. zustimmen, weil die Funktion erst einmal nicht verdächtig ist. (Außer der Zeitpunkt, in dem diese Meldung erscheint.)
Das Tückische dieser Lücke ist, dass das Programm zusätzlich im Hintergrund das Programm aufruft, das in diesem Registryschlüssel eingetragen ist. Und hierfür kommt dann keine UAC-Meldung mehr, sondern versteckt sich hinter der bereits erteilten Berechtigung. Und das könnte dann zum Beispiel ein Verschlüsselungstrojaner sein.
Und den Registryschlüssel einzutragen, wird durch zwei Faktoren begünstigt. 1.) Die PowerShell ist seit Windows 7 Bestandteil von Windows und seit dem W10 Creators Update sogar Standard vor der Kommandozeile. Der Aufruf der PowerShell muss nicht per UAC-Meldung bestätigt werden! 2.) Der Registryschlüssel kann ohne besondere Berechtigungen erzeugt werden! In der PowerShell kann man das Kommando hierfür ohne UAC-Bestätigung ausführen. (Und die PowerShell lässt sich hidden ausführen.)
Das ist Insecure by Design und gibt erst einmal nur folgende Lösungen:
a) man verwendet ein Benutzerkonto ohne Mitgliedschaft in der Administratorengruppe
oder
b1) man stellt die UAC auf immer benachrichtigen und
b2) man erstellt den Registry-Schlüssel zumindest teilweise selbst und vergibt entsprechend hohe Berechtigungen und
b3) man sichert die PowerShell besser ab: siehe BSI-Dokument
Besonders den letzten Punkt sollte man inzwischen besser beherzigen (BSI Handbuch M 4.421 Absicherung der Windows PowerShell ). Die einstellbare Signierungspflicht von Scripten wurde inzwischen ja auch schon durchbrochen.
Egal, ob ich fodhelper.exe aus den Einstellungen heraus oder direkt aufrufe, es löst hier den UAC-Prompt aus – UAC läuft natürlich mit der Vista-Einstellung.
Ja, aber die UAC-Meldung kommt nur für das fodhelper-Programm. Und das ist eine ganz normale Funktion zum Aufruf der Einstellungen für Optionale App-Features verwalten.
Unbemerkt im Hintergrund führt dann dann das fodhelper-Programm aber das im Registry-Schlüssel eingetragene Programm aus, zum Beispiel ein Verschlüsselungstrojaner. Ohne weitere Bestätigung im Schatten der bereits erteilten Berechtigung (die ja eigentlich in Ordnung war).
Wenn Malware aktiv werden und Programme in Reg-Schlüssel eintragen kann, ist es eh schon zu spät. Es ist für Malware eh nicht nötig, auf einen Huckepack-Prozess mit erhöhten Rechten Rechten zu warten. Mit normalen Userrechten kann genug Unheil verursacht werden, wie z.B. alle Daten verschlüsseln/löschen…
Das System ist dann falsch und unsicher konfiguriert. SRP/SAFER lassen grüßen. ;-)
Sehe ich etwas anders. Bei einem normal installierten Windows 10 System muss ich den Anwender oder das System -nur- dazu bringen, ein Script ausführen (z.B. durch eine geschickte eMail mit Angang, durch Javascript auf manipulierten Seiten oder eingebundene manipulierte Onlinewerbung).
Seit Windows 10 Creators Update ist die PowerShell Standard als Ablösung der alten Kommandozeile. Der Aufruf der PowerShell ohne Adminrechte ist UAC-frei. Die Ausführung des gen. Registryschlüssels per PowerShell ist UAC-frei, da auf dem übergeordneten Registry-Knoten keine einschränkenden Sicherheitsrechte liegen. Und dann versteckt die Malware sich hinter einem legalen Programm, dessen UAC-Meldung erst einmal nichts verdächtiges erkennen lässt.
Nicht umsonst spricht der oben verlinkte Artikel davon, dass die UAC-Umgehung durchaus Interesse entsprechender Kreise geweckt hat.
Es geht ja letztlich nicht um die PCs, die professionell durch IT-Fachpersonal im Rahmen von Active-Directory-Domainen aufgesetzt werden. Mehr um die Millionen Heimanwender und die Kleinbetriebe, die sich keine professionelle IT-Betreuung leisten können oder wollen. Und die Einstellung selber schuld scheint mir nicht angebracht. Als Kunde von Handwerkern, Ärzten, etc. kann ich nicht beurteilen, was mit meinen Daten alles so passiert.
Letztlich sind solche Umgehungen nur während der Programmentwicklung akzeptabel, werden aber meistens beim Release vergessen. Unter dem Motto merkt schon keiner.
Eigentlich sollte jeder User wissen, wie er mit Mail-Anhängen umzugehen hat. Für Anfänger, die das nicht wissen, macht wiederum restriktive Konfiguration durch den Admin sowas wirkungslos. Und auch Browser lassen sich restriktiv konfigurieren.
Zu Powershell: wenn Malware auf dem System Powershell ausführen kann, egal mit welchen Rechten, dann ist das System unzureichend konfiguriert. Tatsache ist jedefalls: Malwareschreiber hassen UAC, verglichen mit XP.
Die Millionen Heimanwender können ihr System auch effektiv versiegeln. Leute wie Stefan Kanthak bieten entsprechende Skripte an, die dies via SRP/SAFER per Rechtsklick erledigen. Rechtsklick kann jeder DAU.
Microsoft könnte ohne jeden Aufwand seine Systeme derart abgesichert ausliefern, nur würde dann aller Software-Schrott, der sich nicht an die seit dem vorigen Jahrtausend bekannten "Designed for Windows"-Richtlinien hält, nicht mehr laufen. Statt dessen wird UAC von MS in der Sicherheit sogar noch löchrig gemacht und der Schrott wird durch Wirrtualisierung auch noch unterstützt…
In meinen Augen ist das ganze UAC-Konzept nach Vista mehr als fragwürdig.
Welcher gemeine Windowsanwender würde nicht abstumpfen und dann doch irgendwann nur noch auf "ja" klicken, wenn er dauernd den Dialog angeboten bekäme.
Dann besser generell immer die Passwortabfrage des Adminkontos und ein Arbeiten unter einem Administratorkonto nicht mehr möglich machen.
Besser wäre tatsächlich eine Lösung wie Linux mit dem sudo-Kommando (ohne Ausnahmen durch Programme oder andere Einstellungen).
Nach meiner Erfahrung lässt sich unter Windows aber nur dann mit einem Benutzerkonto ohne Mitgliedschaft in der Administratorengruppe vernünftig arbeiten, wenn man nur surft oder Office-Programme verwendet. Also letztlich den PC wie ein Tablet verwendet. Sobald man anfängt, zum Beispiel zu programmieren oder öfter selbst Programme installiert, wird das echt unhandlich. Man muss sich vor Augen halten: immer, wenn eine UAC-Meldung kommt, kann man ohne Admin-Rechte nur noch auf Nein klicken und muss sich auf ein Admin-berechtigtes Konto ummelden.
Das mit den Admin-Rechten haben einige Entwickler auch noch nicht verstanden: Die Software muss auch funktionieren, wenn ein Standard-Benutzer sie verwendet!
Es ist nicht das erste Mal, dass ich mich mit Software rumärgern muss, die nur (für den Endanwender) vernünftig läuft unter einem Admin-Konto mit deaktivierter UAC… ergo sollte ein Softwareentwickler darauf hinarbeiten, dass er selbst die UAC möglichst wenig zu Gesicht bekommt (die betroffene Software ist nicht mal irgendwie systemkritisch, bräuchte zwingend Schreibzugriff auf das Benutzerkonto oder ähnliches, nur die Entwickler haben gepennt).
Zudem muss ein normaler Büro-Anwender niemals irgendwelche Software selbst aktualisieren – sein Admin macht das mit "irgendeinem Management-Tool" (z. B. Gruppenrichtlinien, WSUS). Aus welchem Grund ein Anwender für ein zuvor definiertes Verfahren irgendwelche Software selbst installieren oder auch nur aktualisieren muss erschließt sich mir nicht – in einem solchen Fall müsste ein bestehendes IT-Verfahren geändert und ohnehin mit Vorgesetzten/Zuständigen/IT abgeklärt werden.
Windows läuft bei mir (geschäftlich wie privat) seit Jahren nur mit eingeschränktem Konto (und einem lokalen Admin-Konto), selbst für Windows XP gab es mit SuRun eine Lösung, mit dem die Funktionsweise der UAC in Windows XP nachgebildet wurde (wenn auch mit optionalen Vereinfachungen, so dass auch ein Standard-Benutzer bei entsprechender Konfiguration ein Admin-Token erhalten konnt).
Für das releaste Programm stimme ich Dir zu. Bei der Programmentwicklung ist das meistens doch etwas anders. Die UAC-Vermeidung führt meistens dazu, dass die Programmtools dann einfach in Verzeichnisse im Partitionsroot installiert werden, um die Beschränkungen der Programmverzeichnisse zu umgehen. Auch nicht sicherer. Und wenn ich den Developer-Modus von Windows 10 aktiviert habe (was die Rechtevergaben massiv ändert), kommt es auf Adminrechte auch schon nicht mehr an (soweit die UAC-Steuerung funktioniert).
Wozu sollte das zu debuggende Programm Admin-Rechte brauchen? Selbst die Entwicklungsumgebung sollte keine Admin-Rechte brauchen, es sei denn, es muss auf Funktionen zugegriffen werden, die Admin-Rechte benötigen (vielleicht für irgendeine Performance-Analyse, andere Gründe fallen mir ad hoc nicht ein, falls es sich nicht gerade um eine sehr Betriebssystemkern-nahe Anwendung handelt). Ins Programmverzeichnis sollte keine Anwendung schreiben müssen, im Benutzerverzeichnis Programme ausführen auch nicht. Für die Erstellung von Windows Installer-Paketen brauche ich keine Admin-Rechte, die Entwicklung meines Tools, um bei Nicht-Gebrauch des Rechners (Tastatur/Maus-Eingaben, falls ich mal wieder vor dem Bildschirm ins Koma falle) den Rechner in den Standby zu versetzen, brauchte ich ebenfalls keine Admin-Rechte.
@Holger:
Abstumpfen muss niemand, wenn er sein System richtig einstellt. Er würde genauso abstumpfen, wenn er ständig die Antwort "fehlende Rechte" bekäme. Er würde dann eben zum Adminkonto wechseln und die gewünschte Aktion dort erledigen. Die Passwortabfrage hülfe da nichts. Wer sich das Leben schwer machen will, kann aber jedes Adminkonto so einstellen, dass bei UAC-Prompts immer das Passwort eingegeben werden muss, anstelle des Klicks auf "OK" – wie im Standardkonto auch. Nö, ich finde UAC schon gut. Schlimm war die Situation in XP, wo das Gros der User in richtigen Adminkonten zu arbeiten pflegte. Wenn man im aktuellen Windows das Konto "Administrator", in dem UAC nicht aktiv ist, zum normalen Arbeiten nutzen könnte, wäre das gleiche Übel immer noch da. Glücklicherweise funktioniert in diesem Konto aber das halbe Windows nicht.
Es geht mir hier darum, dass bei Benutzern OHNE IT-Hintergrund die Aufmerksamkeit jedesmal hoch ist, wenn der Dialog erscheint.
Im Kopf des Benutzers müssen dann folgende Fragen aufkommen:
– War das Erscheinen des Dialogs erwartet oder kam er aus "heiterem Himmel"?
– Welcher Prozess hat den Dialog erscheinen lassen?
– Wenn der Prozessname unbekannt ist, ist dann ein Schädling am Werk oder nicht?
Wenn die höchste Sicherheitseinstellung bedingt, dass der Dialog häufiger erscheint, werden garantiert Anwender aus Bequemlichkeit entweder immer auf "ja" klicken oder aber die Sicherheitseinstellung wieder eine Stufe unter der höchsten einstellen. Die meisten Anwender wollen sich nun einmal nicht mit den Dingen, die in ihrem Computer vorgehen, auseinander setzen.
Hier zeigt sich wieder das alte Dilemma, entweder man möchte höchste Sicherheit, dann wird es unbequem oder man möchte nicht belästigt werden, dann wären Defaulteinstellungen nötig, die erst gar nicht solch einen Dialog erforderlich machen müssten.
Die Aufmerksamkeit sollte bei jedem Nutzer hoch sein, wenn UAC sich UNERWARTET meldet. Wenn man aber z.B. die Registrierung aufruft, weiß man genau, dass UAC sich melden wird. Wie schon gesagt: man kann die häufig verwendeten, erhöhte Rechte fordernden Prozesse so einstellen, dass sie ohne UAC starten, also z.B. regedit über schtasks.exe aufrufen oder über ein WSH-Skript…
Ich bekomme bei eigenen Aktionen praktisch nie UAC-Prompts und wenn unerwartet einer erschiene, wäre die Aufmerksamkeit EXTREM hoch, das garantiere ich dir. ;-)