web-dev-qa-db-fra.com

Comment fonctionne le mode "Secure Desktop" de Windows?

Quelqu'un peut-il expliquer (ou fournir un lien vers une explication simple) ce qu'est le mode "Secure Desktop" de Windows et comment il fonctionne?

Je viens d'en entendre parler dans la documentation KeePass ( KeePass - Enter Master Key on a Secure Desktop ) et j'aimerais mieux le comprendre.

59
snth

Réponse courte

Il existe trois problèmes distincts réclamant le nom de "Secure Desktop":

  • Les fonctions intégrées de Windows comme GINA et le Credential Provider Model .
  • Séparation des applications privilégiées par rapport aux applications non privilégiées fonctionnant sous le même utilisateur (empêcher nominalement l'escalade de privilèges), qui peut être liée ou non à:
  • SwitchDesktop(), qui est ce que KeePass utilise et peut ou non (je ne suis pas sûr) être résistant à DLL Injection.

Réponse détaillée

Comme une introduction rapide à la façon dont les interfaces graphiques Windows sont construites, fondamentalement tout passe par une fonction appelée CreateWindow() (je veux dire tout, chaque bouton, chaque menu, tout) et reçoit un hWnd ou un handle de fenêtre . La modification de ces fenêtres se fait via une autre fonction, SendMessage().

Voici le hic. En tant qu'application en mode utilisateur, en faisant les bons appels d'API, je peux assez facilement envoyer des messages à d'autres Windows. Il est assez trivial de faire disparaître les boutons des formulaires des autres. Il est un peu plus difficile à effectuer DLL injection et accroche la boucle de message qui reçoit les messages (le système d'exploitation envoie des messages Windows lorsque les choses leur arrivent) mais pas beaucoup plus difficile. Si je peux accrocher ces événements , Je pourrais envoyer automatiquement votre formulaire "oui/non". Ou, je pourrais changer le libellé de ReallyDodgyVirus.exe En Explorer.exe Et vous ne seriez pas plus sage.

Insérer: n très bon article sur les différentes techniques pour introduire votre code dans l'espace d'adressage d'un processus en cours.

Maintenant, que font KeePass?

Une très brève lecture de la source montre qu'ils utilisent CreateDesktop(), SwitchDesktop() et CloseDesktop() pour créer un deuxième bureau connecté à l'appareil de visualisation physique sur lequel vous vous trouvez. En anglais, ils demandent au noyau de créer pour eux un bureau isolé dont les objets hWnd sont en dehors de la plage de recherche de SendMessage() de toute autre application.

Je dois souligner que SwitchDesktop suspend la mise à jour de l'interface utilisateur du bureau par défaut. Je ne sais pas si les boucles de messages sont également figées - je ne le pense pas car le bureau est créé en tant que nouveau thread.

Dans ce cas, KeePass est dessine l'interface utilisateur, donc l'exécution est pas, si je comprends bien, comme NT AUTHORITY/SYSTEM. Au lieu de cela, le nouveau bureau est créé indépendamment du reste du bureau actuel, ce qui le protège. Je serai heureux d'être corrigé à ce sujet. Cependant, consultez le MSDN pour SwitchDesktop :

La fonction SwitchDesktop échoue si le bureau appartient à une station de fenêtre invisible. SwitchDesktop échoue également lorsqu'il est appelé à partir d'un processus associé à un bureau sécurisé tel que les bureaux WinLogon et ScreenSaver. Les processus associés à un bureau sécurisé incluent des processus UserInit personnalisés. Ces appels échouent généralement avec une erreur "accès refusé".

Je crois que cela signifie que ces boîtes de dialogue (économiseurs d'écran, ouverture de session Windows) sont intégrées plus profondément dans Windows de telle sorte qu'elles s'exécutent toujours en tant que NT AUTHORITY\SYSTEM Et le processus UserInit crée les sous-processus sur l'authentification valide au niveau requis niveau de privilège.

La raison pour laquelle je soulève cette question est parce que je crois qu'il y a deux problèmes: les différents bureaux et la séparation des privilèges. D'après Mark Russinovich discussion sur le sujet de Secure Desktop :

Le mécanisme d'intégrité Windows et l'UIPI ont été conçus pour créer une barrière de protection autour des applications élevées. L'un de ses objectifs initiaux était d'empêcher les développeurs de logiciels de prendre des raccourcis et d'exploiter des applications déjà élevées pour accomplir des tâches administratives. Une application exécutée avec des droits d'utilisateur standard ne peut pas envoyer d'entrées synthétiques de souris ou de clavier dans une application élevée pour lui faire faire ses enchères ou injecter du code dans une application élevée pour effectuer des opérations administratives.

Comme le dit SteveS, UAC exécute un processus de bureau distinct en tant que NT AUTHORITY/SYSTEM. Si vous pouvez attraper l'UAC en action (consent.exe) Via l'Explorateur de processus, cela ressemble à ceci:

UAC under process Explorer

Escalade des privilèges en tant que processus dont je n'ai pas les détails, mais voici ce que je pense comprendre: je crois que le processus d'escalade de privilèges dans l'API Windows provoque un processus s'exécutant en tant que NT AUTHORITY/SYSTEM (Donc capable de s'exécuter le nouveau processus sous tous les privilèges qu'il veut, dans ce cas un administrateur). Lorsqu'une application demande des privilèges plus élevés, cette question vous est posée localement sur un nouveau bureau, auquel aucune de vos applications ne peut obtenir le descripteur du bureau ou l'un des descripteurs des éléments de l'interface graphique. Lorsque vous y consentez, consent.exe Crée le processus en tant qu'utilisateur privilégié. Ainsi, le processus s'exécutant en tant que NT AUTHORITY\SYSTEM Est une conséquence de la nécessité de créer un nouveau processus privilégié, et non comme une méthode de création d'un bureau sécurisé. Le fait que le bureau soit différent de celui par défaut est ce qui ajoute de la sécurité dans les deux cas.

Je crois que ce que Mark veut dire ci-dessus, c'est qu'en plus de ces bureaux sécurisés, deux choses se produisent:

  • Votre bureau administrateur par défaut fonctionne en fait sans privilège, contrairement à Windows XP et antérieur et
  • Des applications non privilégiées et privilégiées existent désormais sur des postes de travail distincts (avertissement: il pourrait simplement s'agir d'ACL sur les objets en mémoire, je ne suis pas sûr), garantissant que le code non privilégié ne peut pas accéder aux objets privilégiés.

L'interface utilisateur de connexion Windows est à nouveau différente dans Vista/7.

De toute évidence, aucune de ces méthodes ne vous défendra contre les rootkits en mode noyau, mais elles empêchent l'escalade de privilèges et la compromission de l'intégrité de l'interface utilisateur en isolant les applications privilégiées, ou dans le cas de KeePass, la boîte de dialogue sensible.

Modifier

Après avoir regardé de plus près le code KeePass, j'ai vu ce morceau pratique de C #:

Bitmap bmpBack = UIUtil.CreateScreenshot();
if(bmpBack != null) UIUtil.DimImage(bmpBack);
/* ... */

SecureThreadParams stp = new SecureThreadParams();
stp.BackgroundBitmap = bmpBack;
stp.ThreadDesktop = pNewDesktop;

De cela, vous pouvez voir qu'en fait, pour imiter consent.exe, KeePass prend une capture d'écran de l'arrière-plan, l'assombrit et crée son nouveau bureau avec l'arrière-plan de l'ancien bureau. Je soupçonne donc que l'ancien bureau continue de fonctionner même s'il n'est pas rendu. Je pense que cela confirme qu'aucune action magique NT AUTHORITY\SYSTEM Ne se produit à la fois avec KeePass et consent.exe (Je soupçonne que consent.exe fait la même chose en termes d'interface utilisateur, il se trouve juste qu'il est lancé dans le contexte de NT AUTHORITY\SYSTEM).

Édition 2

Quand je dis DLL Injection, je pense spécifiquement à DLL injection pour corrompre l'interface utilisateur. DLL L'injection reste possible) sur KeePass en tant que processus, je ne sais pas s'il pourrait être utilisé pour influencer cette interface utilisateur sécurisée. Il pourrait cependant être utilisé pour accéder à la mémoire du processus et de ses threads, saisissant ainsi le pré-cryptage du mot de passe saisi. Difficile, mais je pense que c'est possible. J'apprécierais que quelqu'un me conseille à ce sujet s'il le sait.

63
user2213

Un "bureau sécurisé" est un bureau qui ne peut être exécuté que par le système lui-même. Cela semble un peu bizarre et n'explique probablement pas grand-chose.

Sous Windows, un bureau est une vue qui vous permet d'interagir avec les processus. Lorsque vous vous connectez à Windows (l'invite de connexion), vous êtes sur un bureau. Lorsque vous êtes connecté et que vous voyez le menu Démarrer, vous êtes sur un bureau séparé. Lorsque vous verrouillez votre PC, vous êtes sur un autre bureau. Lorsque UAC apparaît, vous êtes sur un autre bureau. Il existe plusieurs bureaux différents dans Windows.

Un bureau sécurisé est un bureau hors de portée de l'accessibilité d'autres applications. Le bureau de connexion est un bureau sécurisé (créé par winlogon.exe), tout comme le bureau UAC. Aucun autre processus ne peut interagir avec le bureau, donc aucun autre processus ne peut faire des choses comme activer un bouton ou lire le contenu d'une zone de texte. C'est pourquoi l'UAC est (en théorie) utile.

Les applications tierces peuvent créer un bureau sécurisé pour demander des informations (comme un mot de passe principal), puis les transmettre à l'application en question. De cette façon, aucun autre processus ne peut, en théorie, espionner le mot de passe.

Un bon début sur les bureaux sécurisés est la première moitié de cet article sur la façon dont l'UAC fonctionne avec le bureau sécurisé: http://blogs.msdn.com/b/uac/archive/2006/05/03/5/5959561 .aspx .

16
Steve

le bureau sécurisé s'exécute sous le compte du système local et aucun autre processus ne peut interagir avec celui-ci, sauf OSK, Narrateur, etc., il est démarré par winlogon.exe et vous pouvez le désactiver dans le registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System en changeant la valeur de PromptOnSecureDesktop de 1 à 0 si vous exécutez cmd.exe sous le compte système, il n'interagira toujours pas avec le bureau sécurisé et le bureau sombre que vous voyez lorsque vous cliquez sur exécuter en tant qu'administrateur sous UAC Prompt est un bureau sécurisé et lorsque vous appuyez sur ctrl + Alt + Del et l'écran skyblue que vous voyez avec quelques options comme verrouiller ce calcul, etc. est également un bureau sécurisé, Windows par défaut a trois bureaux 1 winlogon 2 screensaver 3 userdesktop

1
Mudasir