Lokal Adminrechte erlangen

[himitsu]

Schon mit Vista fing der Spaß mit UAC und Co. an, wo die Rechte der gestarteten Programme nicht mehr direkt mit den Rechten des eingeloggten Benutzers übereinstimmen.

RevertToSelf

Der Rest des Programms läuft ja noch mit geringeren Rechten, da sollte die Zeit mit den höheren Rechten nicht unbegrenzt andauern. (nur so lang wie nötig)
Entweder schnell wieder zurücksetzen oder den jeweiligen Thread beenden.
Damit böse Buben es nicht zu einfach ausnutzen können sich in dein Programm zu hacken und von da in den Thread zu kommen.

Wenn man z.B. auf einen anderen Desktop kommen will, dann geht das nur direkt beim Start des Threads, bevor die Messagebehandlung anläuft.
Siehe Anmeldebildschirm oder die UAC-Passwortabfrage. So Manches geht nur, wenn es noch nicht andersweitig initialisiert/benutzt wurde
und in punkto Sicherheit sollte man sicherheitshalber nichts zu lange unsicher lassen.



Zwischen Impersonate und Revert wird jeder Code in diesem Thread mit dessen Rechten ausgeführt, also eigentlich auch ein ForceDirectories.
Es gibt noch ein paar Fallstricke mit Dingen die zwar in dem Thread aufgerufen/gestartet, aber in einem anderen Thread ausgeführt werden.

[Der schöne Günther]

Es gibt keinen "Rest" des Programms. Es hat auch nichts wirklich mit Rechten eines Benutzers zu tun. Entweder der Prozess hat beim Start Admin-RechteFähigkeiten mitbekommen, oder er hat sie nicht. Man durch diese "Impersonation" sich als anderer Benutzer ausgeben, auf dessen Resourcen (z.B. Registry oder Dateien) zugreifen, aber die Admin-Fähigkeiten kommen dadurch nicht nach.

Das ist auch einer der Gründe weshalb ich bei diesen klassischen alten "setup.exe" am Schluss nie das Häkchen "Anwendung direkt starten" (oder so ähnlich) anhake, denn das Setup vererbt die Admin-Fähigkeiten gleich an den zu startenden Prozess weiter. Zumindest die allermeisten.

[Hobbycoder]

Zitat von himitsu:

Das stimmt so nicht ganz. Es lassen sich sogar einzelne Threads mit unterschiedlichen Rechten ausführen,
aber es ist einfacher die Rechte direkt beim Start eines Prozesses/Threads festzulegen, bzw. kurz nach dem Start umzuschalten.

Im Puff und hier Forum (Luckie) sollten es einige Beispiele und Tutorials zu finden sein.

Wenn ich mir Luckie's Beispiel auf o.g. Url anschaue ist es ja das, was ich eben so verwende. Müsste dann nicht die weiteren Routinen (ForceDirectories) unter dem entsprechenden Benutzerkontext (Also der mit dem ich mich im Impersonate angemeldet habe) ausgeführt werden?

PS: In Luckie's Bespiel ist noch ein ReversToItself enthalten. Ist das auch aus der API?

[Assarbad]

Zitat von Der schöne Günther:

Das Impersonate gibt dem Prozess nicht plötzlich Adminrechte. Entweder ein Prozess wird mit Adminrechten gestartet, oder ohne. Das lässt sich nicht nachträglich ändern.

Öhm ... also ImpersonateLoggedOnUser gibt in der Tat dem Thread die Rechte des Nutzers dessen Identität man annimmt. Himitsu erwähnte es bereits.

Kann es sein, daß du eher das hier meinst? Denn die von dir beschriebene Abgrenzung gibt es meines Wissens nach dort, aber nicht auf der Ebene um welche sich die Frage dreht. Ich lasse mich gern eines besseren belehren.

Zitat von Der schöne Günther:

Selbst Anwendungen wie z.B. Visual Studio Code installieren sich standardmäßig dorthin.

Faszinierend, oder? Entgegen Microsofts eigenen Empfehlungen. Nunja. Vermutlich liegt's daran, daß VSCode Electron-basiert ist?!

Zitat von Moombas:

Und nicht das hier ein Denkfehler geschieht "User mit Adminrechten" <> Administratoruser (unter Windows 10 zumindest).

Definiere:

1. Adminrechte
2. Adminstratoruser

Also redest du über RID=500 (DOMAIN_USER_RID_ADMIN)? Oder geht es um die "Privileges" (ich meine eingedeutscht hießen die Benutzerrechte)?

Zitat von Der schöne Günther:

Es gibt keinen "Rest" des Programms. Es hat auch nichts wirklich mit Rechten eines Benutzers zu tun. Entweder der Prozess hat beim Start Admin-RechteFähigkeiten mitbekommen, oder er hat sie nicht. Man durch diese "Impersonation" sich als anderer Benutzer ausgeben, auf dessen Resourcen (z.B. Registry oder Dateien) zugreifen, aber die Admin-Fähigkeiten kommen dadurch nicht nach.

Sicher? Du bist dir da so 100%ig sicher, daß du das hier Hilfesuchenden als definitive Aussage präsentierst? Woher genau bekommst du denn das Token? Normalerweise wird das LogonUser oder Tokenklau sein. Und wenn du dich in LogonUser als Admin ausgewiesen hast, bekommst du selbstverfreilich die entsprechenden Rechte. Wie genau definierst du "Admin-Fähigkeiten"? Das ist ja gerade der Zweck dieser Funktionen.

Ich verweise auf Mimikatz (siehe auch GitHub).

Die Lektüre des Codes von SuRun empfiehlt sich ebenfalls.

Also entweder reden wir aufgrund mangelnder gemeinsam akzeptierter Definition von "Admin-Fähigkeiten" aneinander vorbei, oder du bist auf dem Holzweg.

[Aviator]

Zitat von Assarbad:

Zitat von Der schöne Günther:

Selbst Anwendungen wie z.B. Visual Studio Code installieren sich standardmäßig dorthin.

Faszinierend, oder? Entgegen Microsofts eigenen Empfehlungen. Nunja. Vermutlich liegt's daran, daß VSCode Electron-basiert ist?!

Naja, bei VSCode gibt es zwei verschiedene Installer. Einen User Installer und einen System Installer. Der User Installer ist wohl nur verfügbar, um das Updaten und ggf. installieren von Erweiterungen zu vereinfachen. Im gewerblichen Umfeld in einer Domain bei der die User keine Admin Rechte haben sollten, sehe ich das als nützlich an.
Nachteilig sehe ich es für die Benutzer, die gerne Anwendungen auf anderen Festplatten auslagern, dazu zähle ich mich auch. Dadurch, dass der User Installer aber ins Benutzerprofil installiert wird und dieses in der Regel auf dem gleichen Laufwerk liegt wie die Windows Installation, funktioniert das nicht und der Speicher wird dort verbraucht.

Aber ich glaube, das geht jetzt langsam etwas am Thema vorbei.

[Assarbad]

Zitat von Aviator:

Nachteilig sehe ich es für die Benutzer, die gerne Anwendungen auf anderen Festplatten auslagern, dazu zähle ich mich auch. Dadurch, dass der User Installer aber ins Benutzerprofil installiert wird und dieses in der Regel auf dem gleichen Laufwerk liegt wie die Windows Installation, funktioniert das nicht und der Speicher wird dort verbraucht.

Klick, klick (/j) ... ja, gibt's seit Windows 2000. Und so lange benutze ich das auch schon.

[Aviator]

Zitat von Assarbad:

Zitat von Aviator:

Nachteilig sehe ich es für die Benutzer, die gerne Anwendungen auf anderen Festplatten auslagern, dazu zähle ich mich auch. Dadurch, dass der User Installer aber ins Benutzerprofil installiert wird und dieses in der Regel auf dem gleichen Laufwerk liegt wie die Windows Installation, funktioniert das nicht und der Speicher wird dort verbraucht.

Klick, klick (/j) ... ja, gibt's seit Windows 2000. Und so lange benutze ich das auch schon.

Ich kenne das, klar. Aber es gibt auch Leute, die so etwas nicht kennen oder auch nicht nutzen wollen. Ich gehöre eher zu letzteren.

[Der schöne Günther]

Zitat von Assarbad:

Also entweder reden wir aufgrund mangelnder gemeinsam akzeptierter Definition von "Admin-Fähigkeiten" aneinander vorbei

Ich denke das ist es. Oder ich hatte zu wenig Kaffee.


Ganz konkret:

• Zwei Benutzer, "localUser" und "localAdmin". Ersterer gehört nicht zur Gruppe "Administratoren", letzterer schon
• Eine aktive Sitzung im Benutzer "localUser". Der Benutzer doppelklickt unseren Prozess
• Der Prozess hat in seinem Manifest, wie wohl so ziemlich jeder,
  Delphi-Quellcode:

  requestedExecutionLevel
  level="asInvoker"

• Der Prozess soll nun das Verzeichnis C:\Program Files\Watzn erstellen.

Kann er das? Dein Beitrag liest sich so als ginge das. Wenn ja, was ist dann hieran falsch?

Delphi-Quellcode:

uses
  System.SysUtils,
  WinApi.Windows;

const
   adminName = 'localAdmin';
   adminPwd = 'localAdmin';

function getAdminToken(): THandle;
begin
   Win32Check( LogonUser(
      adminName,
      nil,
      adminPwd,
      LOGON32_LOGON_INTERACTIVE,
      LOGON32_PROVIDER_DEFAULT,
      Result
   ) );
end;

procedure p();
var
   adminToken: THandle;
begin
   adminToken := getAdminToken();
   try
      Win32Check( ImpersonateLoggedOnUser(adminToken) );
      try
         Win32Check( CreateDirectory('C:\Program Files\Watzn', nil) );
      finally
         Win32Check( RevertToSelf() );
      end;
   finally
      CloseHandle(adminToken);
   end;
end;

Selbst bei TeamViewer kann man das beobachten: Der Benutzer führt einen TeamViewer-QuickSupport aus. Authentifiziert sich jemand von außen mit den Kontodaten eines Administrator-Accounts startet TeamViewer sich selbst noch einmal und beendet sich dann. So kannte ich es bislang.

[Assarbad]

Zitat von Der schöne Günther:

Ganz konkret:

• Zwei Benutzer, "localUser" und "localAdmin". Ersterer gehört nicht zur Gruppe "Administratoren", letzterer schon
• Eine aktive Sitzung im Benutzer "localUser". Der Benutzer doppelklickt unseren Prozess
• Der Prozess hat in seinem Manifest, wie wohl so ziemlich jeder,
  Delphi-Quellcode:

  requestedExecutionLevel
  level="asInvoker"

• Der Prozess soll nun das Verzeichnis C:\Program Files\Watzn erstellen.

Kann er das?

asInvoker bezieht sich auf UAC, welches bekanntlich nur wenig mit Sicherheit zu tun hat (siehe auch hier).

Bei standardmäßig gesetzten Zugriffslisten (ACLs) sollte das nicht erfolgreich sein. Aaaaber, es gibt noch die UAC File Virtualization (der entsprechende Minifilter kann per fltmc unter dem Eintrag luafv gefunden werden), welche den Zugriff transparent auf einen anderen Ordner umleitet auf den der (unprivilegierte) Anwender sehr wohl Zugriff hat (UAC muß dafür natürlich aktiviert sein).

Ich weiß also noch immer nicht, ob es dir um Admin (entsprechende Benutzerrechte und Gruppenzugehörigkeit), oder um Elevation (UAC) oder um Mandatory Integrity Control (MIC) geht.

Zitat von Der schöne Günther:

Dein Beitrag liest sich so als ginge das.

Unter der genannten Bedingung kann das gehen, ja.

Dein Delphicode sollte auch das tun was man annimmt, da sich der Admin ja über LogonUser dem System gegenüber ausweist. Kommt natürlich auf die involvierten Integrity-Level an. Sprich: zwar kann ein einzelner Thread "Admin werden", aber er unterliegt trotzdem noch MIC.

Zitat von Der schöne Günther:

Selbst bei TeamViewer kann man das beobachten: Der Benutzer führt einen TeamViewer-QuickSupport aus. Authentifiziert sich jemand von außen mit den Kontodaten eines Administrator-Accounts startet TeamViewer sich selbst noch einmal und beendet sich dann. So kannte ich es bislang.

Genau, das klingt jetzt wiederum stark nach MIC.

[Der schöne Günther]

Zitat von Assarbad:

Ich weiß also noch immer nicht, ob es dir um Admin (entsprechende Benutzerrechte und Gruppenzugehörigkeit), oder um Elevation (UAC) oder um Mandatory Integrity Control (MIC) geht.

Mir geht es eigentlich nur um die Frage des Themen-Erstellers.

Wir sind mittlerweile angekommen bei wilden Abkürzungen wie MIC, UAC, ACL, RID und was weiß ich noch, aber wenn es um das eigentliche Problem geht kommt wieder "kann gehen", "sollte" und "müsste".

Ich bekomme es nicht hin, ohne Neustarten des "normal doppelgeklickten" Prozesses ein Verzeichnis unter C:\Programme anzulegen. Vielleicht du? Dann könnten wir alle davon lernen.