Ahoi!

Mein "Problem" ist folgendes:

Ich würde gerne eine Anwendung / Fenster auf dem Login-Screen (von Windows 2000 und höher) erzeugen. Dass das Programm zu der Zeit schon läuft, ist gesichert.
Über die benötigten Funktionen habe ich mich auch schon einigermaßen schlau gemacht (OpenDesktop, SetThreadDesktop, ...).
Ich hab auch schon in einigen Beiträgen (z.B. von Luckie und Assarbad) hier und woanders gelesen, dass das Recht tricky (Secured WindowStation) ist und auch ungern gesehen wird.
Dankbar wäre ich auch über Tipps und Hinweise in der Richtung, gerne auch per PM.

Das geht wohl nur mit einer Erweiterung der Gina, wenn du sie nicht ganz ersetzen musst. Aber was willst du erreichen bzw. warum willst du da ein eigenes Fenster haben?

Erreichen muss ich gar nichts, dass ist eher so just-for-fun.
Bezüglich der GINA; hab mir schon mal die von Assarbad angeschaut. Allerdings erscheint mir das dann doch etwas zu übertrieben für mein Vorhaben.
Es geht auf jeden Fall, ich hatte da mal eine Anwendung die das kann, muss nur noch mal suchen (und debuggen . Allerdings glaube ich nicht, dass die gleich die GINA modifiziert hat.).
Vielleicht wäre auch noch zu sagen, dass der Prozess im SYSTEM-Kontext läuft.

Also nach einem schnellen Überfliegen der importierten Funktionen des besagten Programmes (toller Satz, gell? ):

OpenWindowStationW
CloseWindowStation
GetProcessWindowStation
WinStationQueryInformationW
SetThreadDesktop
SetProcessWindowStation

CreateProcessAsUserW
CreateWindowExW

GetUserObjectInformationW
ImpersonateLoggedOnUser
ImpersonateSelf
RevertToSelf

OpenDesktopW
OpenInputDekstop

OpenProcess

Dazu noch einiges mit ACLs und SIDs, aber ich weiß nicht, ob die definitiv etwas damit zu tun haben.
Ich werde mich jetzt mal über die WindowStation-Funktionen schlau(er) machen.

Edit:
pluralsite.com/wiki/...sAWindowStation.html
pluralsite.com/wiki/...IsALogonSession.html
msdn2.microsoft.com/...ibrary/ms687391.aspx

Hmm, da wusste ich bis jetzt doch wohl nicht so viel drüber, wie ich eigentlich dachte. Oder ich habe die Beiträge hier und dort wohl etwas zu eilig überflogen.
Und die ganzen netten Security-Funktionen gehören wohl doch dazu.

Wie ich in blogs.msdn.com/oldne...06/08/22/712677.aspx erfahren habe, gibt es sogar das Str-Alt-Enf-Fenster für jede Session.
Was mir allerdings nicht klar ist, gilt das auch für den Anmeldebildschirm?
Zum Zeitpunkt wenn der Computer hochgefahren ist, ist doch noch keine Session gestartet, oder etwa doch?! Falls ja, muss ich mit dieser Zugriff auf die WindowStation erlangen?

Soo, geschafft
Mein erster Versuch war, eine Dll in den winlogon.exe Prozess zu injecten.
Hilfreich dabei, die uallCollection und das InjectLibrary,UninjectLibrary Beispiel dazu.
Hat auch geklappt, ist aber wie mit Spatzen auf Kanonen zu schießen

Der zweite Versuch wahr erheblich leichter und hat nur eine Zeile Code (meinerseits) gebraucht.
Hilfreich diesmal, weil Grundlage des Ganzen, Assarbad's CMDasSYS.

Genaueres sag ich jetzt aber nicht, darf jeder -wie ich- selber rausfinden.

Niklas

\\BBG// hat folgendes geschrieben:

Wie ich in blogs.msdn.com/oldne...06/08/22/712677.aspx erfahren habe, gibt es sogar das Str-Alt-Enf-Fenster für jede Session. Was mir allerdings nicht klar ist, gilt das auch für den Anmeldebildschirm? Zum Zeitpunkt wenn der Computer hochgefahren ist, ist doch noch keine Session gestartet, oder etwa doch?! Falls ja, muss ich mit dieser Zugriff auf die WindowStation erlangen?

Es gibt sogar mehrere Logonsession in einer Sitzung.
Unter XP ist der erste Benutzer in Session 0, genau wie die Dienste.
Unter Vista sind die Dienste in Session 0 und alle anderen Benutzer in eigenen unabhängingen Sessions (> 0).
Die Systemsession existiert also immer.
Mit Windowstations hat das zuerst nur eines zu tun: Es gibt nur eine Windowsstation, die es erlaubt Eingaben von Hardwaregeräten (Tastatur, Bildschirm) anzunehmen : Winsta0. Alle anderen Windowstations werden erzeugt, wenn z.b.
Benutzer über Terminalstationen sich einlogen. Jede Windowsstation ist eine eigene Welt, d.h. Handles und ähnliches sind nur dort gültig. D.h. Prozesse können zwar von einer Station in die andere migrieren - jedoch nicht ihre Fenster und auch nur mit genügend Rechten (läuft eigentlich wieder auf die Dienste hinaus).

--

Hmm, nach meiner Ansicht müsste es genügen, als Dienst, einfach einen Prozess in den Winlogonprozess zu bringen. Das geschiet durch ein Dienst. Er erstellt eine LogonSession des Administrators (für Vista) und impersoniert.
Der Service wechselt seinen Thread dann zum WinLogon Desktop und startet den Prozess

Für Desktopverwaltung habe ich bereits mal was in Delphi geschrieben:
www.delphi-forum.de/...69413&highlight=

\\BBG// hat folgendes geschrieben:

Der zweite Versuch wahr erheblich leichter und hat nur eine Zeile Code (meinerseits) gebraucht. Hilfreich diesmal, weil Grundlage des Ganzen, Assarbad's CMDasSYS.

Diese Sicherheitslücke dürfte mit aktuellen Patches und unter XP nicht mehr ausnutzbar sein.

Interessant, ich habe es nämlich zuerst nur unter XP Pro SP2 und den neusten Patches versucht.
Und es hat geklappt

Das Selbe gilt für Windows 2000 Pro SP4 mit ebenfalls den neusten Patches.

Also ich konnte mit CreateProcess und einem Service dasselbe machen.
Jedoch wird die Anwendung nur mit System oder als Administrator gestartet. Wobei als Administrator, die Menüs nicht funktionieren und man keine weiteren Anwendungen aufrufen kann.

Dabei hab ich als TCB vollen Zugriff auf den Desktop. Komisch, denn ich hab sogar die DACL des Desktophandles für JEDER Vollzugriff gemacht. Aber irgendwie wird das immer wieder zurückgesetzt.

Also mit den Menüs oder neue Prozesse starten habe ich keine Probleme
Der/die Prozesse haben Admin/SYSTEM - Rechte, weil sie eben mit CreateProcess aus dem Service gestartet werden und dessen Rechte vererbt (?) bekommen.
Wer noch schon das Readme von Assarbad's Localsystem-Spielereien gelesen hat, wird sehen, dass "Needed are the privileges to install and start a service.", was (soweit ich weiß) nur Admins haben, womit das Ganze auch keine ernsthafte Sicherheitslücke ist.

Wer Spaß dran hat, kann auch den Explorer so starten

Ich sprach von Ollis Demo. Ich weiß nicht, was du da noch modifiziert hast.

Wie gesagt, nur eine Zeile



Ansonsten ist alles wie bei der CMDasSYS-Demo.

Moderiert von matze: Code- durch Delphi-Tags ersetzt

ja wer will denn auch ein beliebiges Programm auf dem WinLogon Bildschirm mit Admin oder sogar SYSTEM Rechten ausführen? Das ist ja DAS Sicherheitsloch!
Nein, es muss möglich sein, das Programm als der am PC sitzende eingeloggte Benutzer zu starten oder einen eigenen eingeschränkten Benutzer dazu einzuführen.

Aber auch dafür gibt es eine Lösung: Mann muss ein Restricted Token erstellen, CreateProcess mit SUSPEND_THREAD aufrufen und dann per SetThreadToken den Thread das eingeschränkte TOKEN zuweisen. Das Problem dabei ist, jedoch dass die Dienst oder Admin Registrierung und Pfade verwendet werden.
Ein eingeschränktes Token hat weniger Privilegien (z.b. SE_TCB...) und weniger Gruppenmitgliedschaften (SYSTEM, ADMINISTRATORS).

Zitat:

Ein Token ist ein Sicherheitsausweiß, welches beim Einloggen erstellt wird, und an jeden neu zustartenden Prozess einfach weitervererbt wird (eine Kopie). Damit weiß Windows sofort, welche Rechte ein Programm hat. Token können weitergegeben werden, jedoch nie mit höheren Rechten, sondern immer mit gleich vielen oder sogar weniger (Restricted Token) Rechten.

ABER ich rede jetzt grad nur über die Winsta0.
Derzeit weiß ich noch garnicht, wie das mit MS RDP funktioniert. Dort wird eine neue Winsta erstellt und Winlogon darin gestartet (oder Winlogon macht das selbst), welches die Desktops Default, Winlogon und disconnected erstellt.

Ja cool, das Fenster erscheint ja auch dann, wenn man den Computer sperrt (Windows-Taste + L).
Ist das nicht irgendwie ne Sicherheitslücke? Ich meine, selbst der Administrator brauch doch ned das Recht zu haben, irgendwelche Fenster anzuzeigen, während der Computer von Windows gesperrt ist. Bzw. warum sollten Dienste SYSTEM-Rechte haben?

EDIT: Das ist der Hammer Startet mal die modifizierte CMDasSYS-Version, sperrt dann euren Computer, und gebt dann im CMD-Fenster "explorer.exe" ein. Hammer

@Dezipaitor: Schon, aber für mich war/ist das Ganze nur eine kleine Herausforderung gewesen.
Brauchen tut das keiner, außer Leute die sich z.B. nicht anmelden können (damit kriegt es auch eine ganze neue Bedeutung Das ist auch der Grund, warum ich eigentlich keinen Code "hergeben" wollte).
Falls ich das Programm auf dem Desktop des aktuell eingeloggten Nutzers (WinSta0\Default ?) haben wollte, "nur" mit seinen Rechten wäre auch nicht so das Problem. Allerdings wüsste ich auf Anhieb nicht, wozu ich so eine Funktion in einem SERVICE brauche, der ja eigentlich gar nicht für Eingaben gedacht ist.

Was mich nur wundert, ist dass es so einfach ging und ich elegant alle Sicherheits-APIs für Windowstations und Desktops mit dem Service umgehen konnte?!

sakura hat folgendes geschrieben:

mwitzsche hat folgendes geschrieben: Muss also an Vista liegen. Hat sonst noch jemand das gleiche Problem oder schon eine Lösung? Microsoft hat endlich die Lücke geschlossen und lässt eine Interaktion von NT-Diensten mit dem Desktop nicht mehr zu, da dieses eine der größten Sicherheitslücken dieser überhaupt ist. Da musst Du einen anderen Ansatz wählen: i.A.: Einen Dienst der mit einer zweiten Desktopanwendung via PIPES kommuniziert.

Siehe hier, aber auf Vista bezogen. Gilt das auch für Prozesse, die von einem Service gestartet werden und somit ebenfalls SYSTEM-Rechte haben? (Hab leider kein Vista zum Ausprobieren da )

\\BBG// hat folgendes geschrieben:

@Dezipaitor: Schon, aber für mich war/ist das Ganze nur eine kleine Herausforderung gewesen. Brauchen tut das keiner, außer Leute die sich z.B. nicht anmelden können (damit kriegt es auch eine ganze neue Bedeutung Das ist auch der Grund, warum ich eigentlich einen Code "hergeben" wollte). Falls ich das Programm auf dem Desktop des aktuell eingeloggten Nutzers (WinSta0\Default ?) haben wollte, "nur" mit seinen Rechten wäre auch nicht so das Problem. Allerdings wüsste ich auf Anhieb nicht, wozu ich so eine Funktion in einem SERVICE brauche, der ja eigentlich gar nicht für Eingaben gedacht ist. Was mich nur wundert, ist dass es so einfach ging und ich elegant alle Sicherheits-APIs für Windowstations und Desktops mit dem Service umgehen konnte?!

Sagt ja keiner was gegen eine Herausforderung

Gib mal bitte den Code an, der ein Programm als normaler Hauptbenutzer in Desktop Winlogon startet.


Das Problem mit Vista und der Desktopinteraktion liegt net direkt an den Diensten, sondern darin, dass Dienste und Anwenderprogramme verschiedene LogonSessions haben.

Zitat:

Gib mal bitte den Code an, der ein Programm als normaler Hauptbenutzer in Desktop Winlogon startet.

Wohoo, ich glaube wir reden aneinander vorbei
Ich meinte, eine Anwendung aus einem Service auf dem Desktops des aktuellen Benutzers (nehmen wir mal WinSta0\Default) mit eben seinen Rechten zu starten sollte nicht das Problem sein. Ich hoffe doch, dass es nicht möglich ist, als "nur" Hauptbenutzer auf Winlogon herumzupfuschen...

Hi,

\\BBG// hat folgendes geschrieben:

Ich hoffe doch, dass es nicht möglich ist, als "nur" Hauptbenutzer auf Winlogon herumzupfuschen...

Naja, wenn dein Admin so freundlich war, Dir CMDasSys als bereits installierten Service bereitzustellen, dann braucht man nur kurz net start CMDasSys einzugeben und hat System-Rechte Dienste Starten dürfen auch Hauptbenutzer ... Nur halt nicht installieren

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Assarbad hat vorgesorgt, der Service deinstalliert sich nach getaner Arbeit gleich wieder.
Und sobald der Prozess auf WinSta0\Winlogon ist, kann man ja noch an seinen Rechten "schrauben".