Scheinbar Sicherheitsloch in der UAC/MIC (Benutzerkontensteuerung) gefixt

[AHT]

Bislang war es möglich, durch setzen des Mandatory Policy Levels von einem Service aus einem neu gestarteten (minderpriveligiertem) Prozess die Rechte zu geben, trotz eingeschalteter UAC diese zu umgehen (Vista, Windows7).
So war es zum Beispiel möglich mit Hilfe dieses Tricks bei eingeschalteter UAC erfolgreich Messages an höher priveligierte Prozesse zu senden oder global über SetWindowsHookEx Hooks zu installieren (zum Beispiel einen Hook für einen Keylogger).
Seit kurzem scheint das nicht mehr möglich zu sein, ohne die UAC abzuschalten. Schlechte Zeiten für die Programmierer von Usermode Keyloggern?
Zumindestens ist es nicht mehr möglich, nach dokumentierten Standardmethoden bei eingeschalteter UAC systemweit Fenster-Hooks zu setzen.

Keylogger und andere Anwendungen, die Systemweit über SetWindowsHookEx Messages abgreifen, funktionieren bei eingeschalteter UAC somit endgültig nicht mehr wie unter XP.

[Andreas Miethe]

Nur Windows7 ?

Mein Snapshot-Tool funktioniert immer noch (Vista mit allen Updates ).

[AHT]

Vista und Windows7. Bitte genau lesen, was da steht.

[AHT]

Die Wahrscheinlichkeit, das du diese "Umgehungstechnik" in einem deiner Tools verwendest, geht gegen null (dazu müssest du erst mal einen Service haben). Die UAC blockt von sich aus schon einen SetWindowsHookEx in Prozesse ab, die in einem anderen IL laufen, als der hookende Prozess. Das lässt sich auch sehr schön mit Franks Botschafter überprüfen, der zum Beispiel, wenn er ohne Adminrechte gestartet wird, keine Messages in einer Anwendung hooken kann, die mit Adminrechten läuft.

[Frabbing]

Genau, dann passiert nix.

[AHT]

Vorher konnte man das "passiert nichts" mittels der angesprochenen (und dokumentierten) Technik umgehen - das funktioniert nun nicht mehr.
Wer seinen "Message Hooker" mittels dieser Technik vistatauglich gemacht hat, wird wissen, was ich hier genau meine. Wie gesagt - es geht nicht mehr, no chance.

[Frabbing]

Gut, dass ich es nicht angepasst hatte. Hätte ich mich ja geärgert.

[AHT]

Vielleicht gibt es andere Möglichkeiten - kümmere mich noch darum.

[Frabbing]

Wegen mir aber nicht. Ich komme doch nicht mehr zum programmieren. Werde das ganz aufgeben.

[AHT]

Mich interessiert, ob M$ einen Teil der UAC in einer bestimmten Art und Weise implementiert hat. Ist das der Fall, ist das OS noch an einer anderen (undokumentierten) Stelle offen. Interessiert mich persönlich.

[AHT]

Zitat von Frabbing

Gut, dass ich es nicht angepasst hatte. Hätte ich mich ja geärgert.

Solche Tools kann man am besten selbst mit externen Tools in dem Kontext starten, in dem man sie beötigt. Ich habe den Botschafter öfters in Betrieb, da hat sich das bewährt.

[AHT]

Es scheint noch was nettes dokumentiertes zu geben, was man mit einem Thread durchführen kann. Ich schaue demnächst mal, ob es geht.

[AHT]

Zwischenergebnis... Folgende Sachen habe ich versucht:

1. Habe ausprobiert, durch Impersonierung dem Thread einen niedrigeren Integritätslevel zu verpassen und damit dann einen Hook in einen "niedriger priveligierten" Prozess zu installieren. Windows interessiert hier aber scheinbar nur der IL des Prozesses, nicht der IL Threads (das klappt also nicht). Das gilt sowohl für das Installieren des Hooks, als auch für das Empfangen eines Hooks.
2. Habe einen Prozess mit Systemrechten ausgestattet und den Thread dieses Prozesses dann mit einer Kopie des originalen Token impersoniert. Ich habe dann versucht, den Integritätslevel des Primären Tokens des Prozesses über den manipulierten Thread zu veringern und ihn wieder zu erhöhen. Das Verringern klappt, das Erhöhen nicht. Man kann also theoretisch die Hooks installieren, der Prozess befindet sich am Ende aber in einem IL, in dem er nicht mehr ausreichende Zugriffsrechte auf das Dateisystem hat.

Die einzige vernünftige Möglichkeit scheint zu sein, die Hooks über einzelne Prozesse zu installieren, die jeder in einem eigenen IL laufen.
Wie gesagt, mit der Funktionalität, die vor der Änderung bestand, war es möglich, einen Keylogger von einem Service aus zu starten und ihm vor dem Start die nötigen Rechte zu verpassen, seine Hooks auch in Prozesse mit anderem IL zu installieren.

Die Änderung bezieht sich übrigens nicht nur auf Hooks, sondern auch auf die mit der UAC verbundene Abblockung von Messages an "höher priveligierte" Prozesse. Auch hier ist es nicht mehr möglich, dem Prozess mit Hilfe der angesprochenen API die Rechte mitzugeben, Messages an "höher privilegierte" Anwendungen zu senden.

Die Tendenz, die sich hier in der Entwicklung von Windows abzeichnet, ist (denke ich) klar.