Lokal Adminrechte erlangen

[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?

[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.

[Aviator]

Zitat von Der schöne Günther:

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.

Haha. Ich dachte, ich wäre der Einzige der das so macht. Ich nehme den Haken auch immer raus und starte die Anwendung lieber aus dem Startmenü von Hand.

[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.

[Assarbad]

Zitat von Aviator:

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.

Ja gut, dann kann ich dir auch nicht helfen

Ich benutze das schon seit weit über einer Dekade um bspw. das Profil von Browser und Email-Programm in einen verschlüsselten Container zu verbannen. Ganz selten habe ich damit auch andere Daten (bspw. riesige Spiele) "ausgelagert" oder Programme welche sich selbst zickig anstellen, wenn sie nicht auf der Systemplatte landen. Keine Ahnung warum man das nicht einsetzen wollen würde. Es hat jedenfalls nicht die gleichen Sicherheitsimplikationen wie symbolische Links und braucht daher auch nicht das entsprechende Benutzerrecht.

[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.