Kein ordentlicher RunAs-Ersatz…

Letztens habe ich euch gezeigt, wie man den üblichen RunAs-Alternativen die Credentials entlocken kann. Im Anschluss an den Artikel hatte ich mich die nächsten Nächte hingesetzt und versucht, eine ordentliche Alternative zu programmieren... leider ohne Erfolg. 🙁
Damit die Ideen und das Wissen, welche ich dabei gesammelt habe, nicht einfach verloren gehen, dachte ich mir, verfasse ich einfach einen Artikel über meinen derzeitigen Stand und das eigentliche Problem.

Fangen wir vorne an: Wie wir gesehen haben, ist es möglich, die Logindaten des Admins zu klauen, wenn wir ein Programm nutzen, dass die Funktion CreateProcessWithLogonW() benutzen, um die RunAs-Funktionalität herzustellen.
Das ist aber anscheinend nur die halbe Wahrheit. In Wirklichkeit ist dieser Diebstahl nur dann möglich, wenn das RunAs-Programm selbst mit den Rechten des eingeschränkten Nutzerkontos gestartet wird - nur dann hat der Nutzer die Möglichkeit, sich in die Anwendung einzuklinken.

Meine Idee war deshalb, von Beginn an einen Prozess unter den Rechten des Administrators laufen zu lassen, der in einem definierten Verzeichnis nach neuen Job-Dateien sucht und diese automatisiert ausführt. Der Vorteil: Der eingeschränkte Nutzer könnte sich nicht in die Ausführung einklinken und diese manipulieren - denn er hat garkeine Rechte an dem Prozess. Wäre es doch möglich, wäre dies kein Problem der Software, sondern des gesamten Betriebssystems und würde als Privilege Escalation bezeichnet werden.

Diesen permanent laufenden Prozess hatte ich als Windows Service geplant und implementiert. Das ganze funktionierte sogar (fast) wie gedacht: Die Jobs wurden mit Admin-Rechten ausgeführt und ein Einklinken in den Aufruf war nicht möglich. Es gab jedoch ein Problem... es war nämlich nicht möglich, die gestartet Anwendung zu sehen und/oder zu bedienen. Eine Erklärung für dieses Verhalten konnte ich leider nicht finden 🙁 . Wird der "RunAs-Service" mit den Rechten des eingeschränkten Nutzers ausgeführt, funktioniert alles wunderbar.
Als dieser Plan fehl schlug, suchte ich nach einer anderen Möglichkeit, eine Anwendung von Beginn an unter Admin-Rechten laufen zu lassen und stieß dabei auf die Scheduled Tasks. Ich strickte meine Anwendung also komplett um, konfigurierte für sie einen Scheduled Task mit Admin-Rechten und probierte das ganze aus. Und wieder hatte ich das gleiche Problem... die Anwendung wird mit den korrekten Rechten gestartet, aber man sieht sie nicht.

Um zu sehen, ob dieses Problem generell auftritt, sobald eine Anwendung unter anderen Rechten läuft, startete ich meine RunAs-Anwendung via RunAs mit Administrator-Rechten und ließ sie dann einen Job ausführen. Und siehe da: Die Anwendung wurde mit grafischer Oberfläche gestartet.
Bei meiner Recherche fand ich dann heraus, dass auch die Scheduled Tasks anhand eines Windows Services funktionieren. Meine Vermutung ist deshalb, dass die Anwendung nur dann nicht angezeigt wird, wenn sie mit anderen Rechten durch einen Service gestartet wird. Ich weiß persönlich nicht, ob es sich dabei um einen Bug oder um ein Feature handelt. Für dieses Projekt hier ist es jedenfalls der Todesstoß... 🙁

Vielleicht liest ja jemand diesen Blog hier und hat eine Idee, wo das Problem liegen könnte und ob es dafür eine Lösung gibt. Über Kommentare und Anregungen würde ich mich jedenfalls sehr freuen. 🙂
Unordentliche Grüße, Kenny

3 Kommentare » Schreibe einen Kommentar

    • Ein Dienst der eine UI anzeigt ist empfindlich für WM_TIMER Hacks, einfach eine WM_TIMER Meldung mit passendem Pointer an das Fenster schicken und prompt hast du deinen Code mit Admin oder sogar Kernel Rechten (das hatten diverse Virenscanner falsch, die aus ihren Filtertreibern raus UIs aufmachten).

      Wenn dir das egal ist kannst du beim Registrieren des Dienstes natürlich 'Interacts with Desktop' erlauben.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.