SuRun Interna

SuRun besteht aus zwei wesentlichen Dateien. „SuRun.exe“ und „SuRunExt.dll„.

SuRun.exe“ beinhaltet sämtlichen Code für den SuRun-Dienst, den Kommandozeilen-Client, Konfiguration, Installation und Deinstallation. In „SuRunExt.dll“ werden die Desktop-Kontextmenü- und System-Menü-Erweiterungen gehandhabt.

Wird SuRun.exe nicht aus dem Windows-Verzeichnis gestartet, bietet es dem Benutzer an, ein Update oder eine Neuinstallation durchzuführen.

SuRun.exe /UNINSTALL“ startet den Deinstallationsprozess.

SuRun.exe /Setup“ startet die SuRun Konfiguration auf einem sicheren Desktop.

Wird SuRun.exe aus dem Windows-Verzeichnis gestartet, übergibt es den in der Kommandozeile angegebenen Befehl an den Dienst, der fragt den Benutzer und gibt evtl. das Passwort zurück an den Client Prozess.

Programmablauf:

Der SuRun-Client Prozess übermittelt dem SuRun-Dienst einen Block mit Daten in dem unter Anderem Logon-Session ID, Benutzer Name und die auszuführende Kommandozeile stehen. Das macht der Client, indem er diesen Block als Ganzes in eine Named-Pipe schreibt, die der Dienst permanent liest.

Der Dienst überprüft zunächst, ob der gesendete Block von derselben Ausführbaren Datei stammt, wie er selbst.

Ist das der Fall, startet der Dienst einen weiteren SuRun.exe-Prozess in der Logon-Session des Client Prozesses. Das ist (leider) unbedingt notwendig, da der Dienst sonst nicht auf den sicheren Desktop umschalten kann. Der neu gestartete Prozess liest aus dem Client-Prozess den Datenblock aus, erzeugt einen sicheren Desktop in der Logon-Session des Client Prozesses und schaltet auf diesen Desktop um.

Jetzt sind Bildschirm, Tastatur und Maus dem sicheren Desktop zugeordnet und alle Eingaben müssen interaktiv vorgenommen werden. Vorhandene Tastatur- und Maus-Hooks funktionieren nicht auf diesem Desktop.

Entschließt sich der Benutzer, das geforderte Programm starten zu wollen, startet der Dienst direkt den gewünschten Prozess mit administrativen Rechten. Das funktioniert, indem sich SuRun mit ZwCreateToken einen Benutzertoken baut, der dem des angemeldeten Benutzers entspricht, aber die Rechte und Privilegien der Administratorengruppe hat. Der neu gestartete Prozess hat eine DACL, auf die nur Administratoren schreibend zugreifen dürfen. Deshalb funktionieren CreateRemoteThread, Read- und WriteProcessMemory nicht aus Benutzerprozessen.

Wird die Sitzung des angemeldeten Benutzers beendet, beendet ein „WinLogon Notification“ Callback in SuRun alle noch laufenden von SuRun gestarteten Prozesse.

Warum so und nicht anders?

Einen zweiten System-Prozess für den sicheren Desktop zu benutzen… Spatzenkanone?

Jeder Windows Dienst läuft in Logon-Session 0.

Sind am Computer zwei oder mehr Benutzer gleichzeitig angemeldet, läuft mindestens ein Benutzer in einer anderen Logon-Session mit einer eigenen WindowStation und eigenem Desktop.

Dienste haben keine Möglichkeit, dort sichtbar zu werden!

Jede Logon-Session hat ihren eigenen Satz von Kernel-Objekten die nur in ihrer Session gültig sind. Dienste laufen ja bereits in Session 0. Das lässt sich nicht ändern, denn deren Kernel-Handles sind in einer anderen Session nicht gültig.

Also müssen Dienste, um für einen anderen Benutzer sichtbar zu werden, ihren Benutzer-Token duplizieren, die Session-ID für das Tokenduplikat anpassen und mit CreateProcessAsUser() einen neuen Prozess in der Logon-Session des anderen Benutzers starten.