Si vous êtes curieux et que vous en savez plus sur le fonctionnement de Windows sous le capot, vous vous demanderez peut-être sous quel «compte» les processus actifs s’exécutent lorsque personne n’est connecté à Windows. Dans cet esprit, le post de questions et réponses SuperUser d’aujourd’hui a des réponses pour un lecteur curieux.

La séance de questions-réponses d’aujourd’hui nous est offerte par SuperUser, une subdivision de Stack Exchange, un regroupement communautaire de sites Web de questions-réponses.

La question

Le lecteur SuperUser Kunal Chopra veut savoir quel compte est utilisé par Windows lorsque personne n’est connecté:

Lorsque personne n’est connecté à Windows et que l’écran de connexion s’affiche, sous quel compte utilisateur les processus actuels s’exécutent-ils (pilotes vidéo et audio, session de connexion, logiciel de serveur, contrôles d’accessibilité, etc.)? Il ne peut s’agir d’aucun utilisateur ou de l’utilisateur précédent car personne n’est connecté.

Qu’en est-il des processus qui ont été démarrés par un utilisateur mais continuent de s’exécuter après la déconnexion (par exemple, les serveurs HTTP / FTP et autres processus de mise en réseau)? Basculent-ils sur le compte SYSTEM? Si un processus démarré par l’utilisateur est basculé vers le compte SYSTEM, cela indique une vulnérabilité très grave. Un tel processus exécuté par cet utilisateur continue-t-il de s’exécuter sous son compte après sa déconnexion?

Est-ce pour cela que le hack SETHC vous permet d’utiliser CMD en tant que SYSTEM?

Quel compte est utilisé par Windows lorsque personne n’est connecté?

La réponse

Grawity contributeur SuperUser a la réponse pour nous:

Lorsque personne n’est connecté à Windows et que l’écran de connexion s’affiche, sous quel compte utilisateur les processus actuels s’exécutent-ils (pilotes vidéo et audio, session de connexion, logiciel de serveur, contrôles d’accessibilité, etc.)?

Presque tous les pilotes s’exécutent en mode noyau; ils n’ont pas besoin de compte sauf s’ils commencent espace utilisateur processus. Ceux espace utilisateur les pilotes s’exécutent sous SYSTEM.

En ce qui concerne la session de connexion, je suis sûr qu’elle utilise également SYSTEM. Vous pouvez voir logonui.exe à l’aide de Process Hacker ou SysInternals Process Explorer. En fait, vous pouvez tout voir de cette façon.

En ce qui concerne le logiciel serveur, voir les services Windows ci-dessous.

Qu’en est-il des processus qui ont été démarrés par un utilisateur mais continuent de s’exécuter après la déconnexion (par exemple, les serveurs HTTP / FTP et autres processus de mise en réseau)? Basculent-ils sur le compte SYSTEM?

Il en existe trois sortes:

  1. Processus en arrière-plan simples: ils s’exécutent sous le même compte que celui qui les a démarrés et ne s’exécutent pas après la déconnexion. Le processus de déconnexion les tue tous. Les serveurs HTTP / FTP et autres processus de mise en réseau ne s’exécutent pas en tant que processus d’arrière-plan standard. Ils fonctionnent comme des services.
  2. Processus de service Windows: ils ne sont pas lancés directement, mais via le Gestionnaire de services. Par défaut, les services exécutés en tant que LocalSystem (ce qui, selon Isanae, est égal à SYSTEM) peuvent avoir des comptes dédiés configurés. Bien sûr, pratiquement personne ne dérange. Ils installent simplement XAMPP, WampServer ou un autre logiciel et le laissent s’exécuter en tant que SYSTEM (toujours sans patch). Sur les systèmes Windows récents, je pense que les services peuvent également avoir leurs propres SID, mais encore une fois, je n’ai pas fait beaucoup de recherches à ce sujet.
  3. Tâches planifiées: elles sont lancées par le Service Planificateur de tâches en arrière-plan et toujours exécuté sous le compte configuré dans la tâche (généralement celui qui a créé la tâche).

Si un processus démarré par l’utilisateur est basculé sur le compte SYSTEM, cela indique une vulnérabilité très grave.

Ce n’est pas une vulnérabilité car vous devez déjà avoir des privilèges d’administrateur pour installer un service. Les privilèges d’administrateur vous permettent déjà de faire pratiquement tout.

Voir également: Diverses autres non-vulnérabilités du même type.

Assurez-vous de lire le reste de cette discussion intéressante via le lien de discussion ci-dessous!


Vous avez quelque chose à ajouter à l’explication? Sonnez dans les commentaires. Vous voulez lire plus de réponses d’autres utilisateurs de Stack Exchange avertis en technologie? Consultez le fil de discussion complet ici.

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici