[Security] – Protocoles et systèmes d’authentifications, partie 3.1 – Protocoles d’authentification – Local Authentication

[Security] – Protocoles et systèmes d’authentifications, partie 1 – introduction aux systèmes d’authentifications  – http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/04/security-protocoles-et-syst-232-mes-d-authentifications-partie-1-introduction-aux-syst-232-mes-d-authentifications.aspx

[Security] – Protocoles et systèmes d’authentifications, partie 2 – comprendre comment Windows stocke et gère votre identité au sein du réseau d’entreprise – http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/07/security-protocoles-et-syst-232-mes-d-authentifications-partie-2-comprendre-comment-windows-stocke-et-g-232-re-votre-identit-233-au-sein-du-r-233-seau-d-entreprise.aspx

[Security] – Protocoles et systèmes d’authentifications, partie 3.2 – Protocoles d’authentification – Basic Authentication – http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/20/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-2-protocoles-d-authentification-basic-authentication.aspx

[Security] – Protocoles et systèmes d’authentifications, partie 3.3.1 – Protocoles d’authentification – Introduction aux Challenge-Response Protocols – http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/23/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-1-protocoles-d-authentifications-challenge-response-protocols-digest-authentication.aspx

[Security]
– Protocoles et systèmes d’authentifications, partie 3.3.2 – Protocoles
d’authentification – Digest Authentication –
http://danstoncloud.com/blogs/jordanlaurent/archive/2014/01/10/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-2-protocoles-d-authentifications-digest-authentication.aspx


Dans la 1ère et 2e partie de cet article, nous avons discuté de la façon dont les mots de passe sont stockés au sein de Windows. C’est une première étape…mais quels sont les mécanismes utilisés pour vous authentifier sur votre machine locale ou sur un réseau d’entreprise? C’est parti…!! Afin que cela soit plus clair pour tout le monde et afin d’éviter d’écrire plusieurs centaines de lignes au sein d’un même billet 😉 cette 3e partie sera découpé en plusieurs sous-parties! Voici les points qui y seront abordés;

Partie 3.1 – Local Authentication

Partie 3.2 – Basic Authentication

Partie 3.3.1 – Introduction aux Challenge-Response Protocols

Partie 3.3.2 – Challenge-Response Protocols – Digest Authentication

Partie 3.3.3 – Challenge-Response Protocols – LM et NTLM v1

Partie 3.3.4 – Challenge-Response Protocols – NTLM v2 et NTLM ++

Partie 3.3.5 – Challenge-Response Protocols – Kerberos

 

  • Processus et sous-systèmes intervenants lors de l’authentification locale
  1. Windows Logon Application – Processus WINLOGON.EXE
  2. Local Security Authority SubSystem – LSASS
  3. Authentication Package – MSV1_0
  4. Graphical Identification and Authentication (GINA) dynamic link-library (DLL) – Windows NT 3.1 à Windows NT 5.1 (XP/2003) / Credential Providersà partir de Windows NT 6.0 (Vista/2008)

  • Authentification locale (« version simplifiée »)
  1. L’utilisateur tape la combinaison CTRL+ALT+SUPPR  (SAS – Secure Attention Sequences  ou encore SAK – Secure Attention Keys). Cela provoque le sous-système d’autorité de sécurité locale (LSASSLocal Security Authority Subsystem Service) pour faire appel à une nouvelle session et charger le processus WinLogon.exe (Windows Logon Application) dans cette session. Winlogon.exe charge à son tour le processus LogonUI.exe (Windows Logon User Interface).
  2. L’utilisateur rentre ses identifiants (nom d’utilisateur + mot de passe).
  3. Le processus Winlogon.exe récupère la valeur du mot de passe, le « hash » en un hash NT (souvenez-vous de la 2e partie de cet article!), recherche le nom d’utilisateur dans la base SAM (Security Accounts Manager) locale, et compare les valeurs du hash NT reçu de l’utilisateur à celui qui est stocké dans cette même base SAM. Si les deux correspondent, la connexion est réussie 🙂 Sinon, try again 🙁
  4. Si certains packages de sousauthentification sont installés sur l’ordinateur (cela sera traité dans la 4e partie de cet article), les informations de logon sont transférés à celles-ci pour un traitement supplémentaire. Dans le cas contraire, Userinit.exe est appelé et l’environnement de l’utilisateur est chargé.

 Ce processus est assez simple car il y a une transmission sécurisée (secure channel) tout au long du chemin d’authentification géré par le processus LogonUI.exe, qui récupère les identifiants des utilisateurs afin de les comparer aux informations contenues dans la base SAM. Toutefois, lorsque l’authentification est non plus locale mais réseau, le processus devient un peu plus compliqué parce que vous devez vous soucier de la façon dont les informations d’authentification sont échangées entre le client et le serveur d’authentification (AS – Authentication Server) qui héberge la base de données des comptes Active Directory (NTDS.DIT – New Technology Domain Services . Directory Information Tree)…ce qui sera traité dans la suite de cette 3e partie!

 

  • Authentification locale (version détaillée)

Phase 1 – Initialisation du système

  1. Winlogon.exe crée et ouvre une session Windows interactive pour représenter les périphériques essentiels à l’ordinateur (Clavier, souris et moniteur) – \Sessions\1\Windows\WindowStations\WinSta0 dans le gestionnaire d’objet.
  2. Winlogon.exe crée ensuite un descripteur de sécurité unique de la station qui a une seule ACE (Access Control Entry) ne contenant que le SID (Security IDentifier) du système (Ce descripteur garantit qu’aucun autre processus ne peut accéder au poste de travail, sauf si Winlogon.exe l’y autorise)
  3. Winlogon.exe crée et ouvre deux bureaux : un bureau d’application (interactive desktop\Sessions\1\Windows\WinSta0\Default) – Seul Winlogon.exe pourra accéder à celui-ci, et un bureau Winlogon (secure desktop \Sessions\1\Windows\WinSta0\Winlogon) – Winlogon.exe et les utilisateurs pourront y accéder. Cela signifie qu’à chaque fois que le bureau Winlogon est actif, aucun autre processus aura accès à un code actif ou des données associées de votre poste de travail. Avant que l’utilisateur ne fasse la séquence de touches sécurisés (CTRL+ALT+SUPPR), seul ce bureau sécurisé sera actif.
  4. Dès lors que l’utilisateur se connecte et effectue cette séquence, Winlogon.exe passe le relais à Logon UI (Cela explique pourquoi toutes les fenêtres de votre bureau interactif semblent disparaître lorsque vous appuyez sur CTRL+ALT+SUPPR puis revenir quand vous fermez la boîte de dialogue de sécurité de Windows 🙂 )
  5. Winlogon.exe établit ensuite une connexion avec une classe ALPC (Advanced Local Procedure Call)  et utilise la fonction LsaAuthenticationPort du sous-système de sécurité locale (LSASS) pour échanger les informations de connexions, de déconnexions et des opérations de mots de passe en appelant  cette fois-ci la fonction LsaRegisterLogonProcess.
  6. Winlogon.exe initialise et enregistre une structure de données de type fenêtre qui associe une procédure Winlogon avec la fenêtre créée ensuite.
  7. Winlogon.exe enregistre les notifications Winlogon RPC, qui écoute les notifications de la séquence de touches sécurisées de Win32k.sys . Cette mesure empêche les chevaux de Troie de prendre le contrôle de l’écran lorsque le SAS est entré.
  8. Winlogon.exe enregistre la fenêtre pour que la procédure associée à cette fenêtre soit appelée si un utilisateur se déconnecte ou si l’ordinateur se met en veille. Le sous-système Windows vérifie alors que le processus de demande de notification est bien le processus Winlogon.exe

Une fois que le bureau sécurisé Winlogon est créé durant l’initialisation, il devient le bureau actif. Lorsque le bureau Winlogon est actif, il est toujours verrouillée. Winlogon.exe déverrouille seulement son bureau pour basculer vers le « bureau d’application » (celui de l’utilisateur) ou le « bureau de l’économiseur de veille »  (screen-saver dekstop). Seul le processus Winlogon.exe peut verrouiller ou déverrouiller un bureau.

Phase 2 – Authentification de l’utilisateur

  1. L’étape d’authentification commence quand un utilisateur appuie sur CTRL + ALT + SUPPR. Après que la séquence de touches sécurisée (SAS) soit pressé, le processus Winlogon.exe démarre donc à son tour le processus LogonUI.exe, celui-ci appelle les fournisseurs d’informations d’identification pour obtenir un nom d’utilisateur et mot de passe. Winlogon.exe crée également un SID d’ouverture de session local unique pour cet utilisateur qu’il attribue à cette instance de l’ordinateur de bureau (clavier, écran, et souris). Cela signifie qu’à un utilisateur correspond un SID d’ouverture de session local unique (logique!). Winlogon.exe passe ce SID au sous-système de sécurité LSASS dans le cadre de l’appel LsaLogonUser. Si l’utilisateur est connecté avec succès, ce SID sera inclus dans le jeton (token) d’ouverture de session.
  2. Lorsque la combinaison « nom d’utilisateur + mot de passe«  ont été entrés, le processus Winlogon.exe récupère une poignée pour un forfait en appelant la fonction LsaLookupAuthenticationPackage du sous-système de sécurité (LSASS). Les paquets d’authentification sont localisés dans le registre sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Winlogon.exe transmet alors les informations de connexion au package d’authentification grâce à la fonction LsaLogonUser. Lorsque le package authentifie l’utilisateur, Winlogon.exe poursuit le processus d’ouverture de session pour celui-ci (si aucun paquets d’authentification indique une connexion réussie, le processus d’ouverture de session s’interrompt).
  3. Windows utilise deux paquets d’authentification standard pour les connexions interactives: Kerberos et MSV1_0.
    1. Le package d’authentification par défaut sur ​​un système Windows locale est MSV1_0 contenue dans le répertoire %SystemRoot%\System32\Msv1_0.dll. LSASS l’utilise également sur les ordinateurs qui ne peuvent pas localiser un contrôleur de domaine.
    2. Le package d’authentification Kerberos contenue dans le répertoire %SystemRoot%\System32\Kerberos.dll, est utilisé sur les ordinateurs qui sont membres de domaines Active Directory.
  4. Le package d’authentification MSV1_0 prend le nom d’utilisateur ainsi que le hash du mot de passe et envoie une requête à la SAM locale pour récupérer les informations de compte, ce qui inclut le mot de passe, les groupes auxquels l’utilisateur appartient, les restrictions de compte et l’identifiant unique local (LUID – Locally Unique IDentifier) qui formeront le jeton locale d’authentification, plus connu sous le nom de logonID!
    1. MSV1_0 vérifie d’abord les restrictions de compte, tels que les heures ou le type d’accès autorisé (si l’utilisateur ne peut pas se connecter en raison des restrictions dans la base de données SAM, l’appel de connexion échoue et MSV1_0 renvoie un état d’échec à la LSA).
    2. MSV1_0 compare ensuite le hash du mot de passe et le nom d’utilisateur fournis par l’utilisateur à ceux stockés dans la base SAM.

Phase 3 – Chargement de la session utilisateur

  1. Winlogon.exe regarde dans le registre l’entrée Userinit dans HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Userinit et crée un processus pour exécuter la valeur de cette chaîne. La valeur par défaut est Userinit.exe
  2. Userinit.exe charge le profil de l’utilisateur et crée un processus pour exécuter ce que vaut la valeur de HKCU\SOFTWARE\Microsoft\Windows NT\Current Version\ Winlogon\Shell. Cette valeur n’existe pas par défaut.
  3. Si elle n’existe pas, Userinit.exe exécute un second processus pour lire la valeur du Shell dans HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Shell, qui est par défaut Explorer.exe

 

  • A propos de la combinaison de touches « CTRL + ALT + SUPPR » et des rumeurs sur son utilité…

« Lorsque nous avons conçu NT 3.1, l’une des questions qui est venu était la séquence de touche sécurisée nous avions besoin d’une séquence de touches qui ne pouvait être intercepté par n’importe quelle application. Il s’est avéré que seule combinaison de touches qui n’était déjà pas utilisée par un autre système d’exploitation était CTRL + ALT + SUPPR. Et ainsi est né cette combinaison de touches permettant de vous connecter… » Jim Kelly, Security Architect – Windows NT.

La SAS (Secure Attention Sequence) est sécurisée car aucune application ne peut intercepter la combinaison de touches CTRL + ALT + SUPPR. Comment? C’est le processus Win32k.sys qui réserve cette combinaison de touches afin que chaque fois que le système d’entrée de Windows intercepte celle-ci (mis en œuvre dans un thread d’entrée spécifique à l’intérieur de Win32k.sys), il envoie un message RPC (Remote Procedure Call)  vers le processus Winlogon.exe  (qui est à l’écoute de notifications d’authentification). Les touches frappés au clavier qui correspondent à une touche de raccourci enregistrée (donc connus par le système d’exploitation) ne sont jamais envoyés à un processus autre que celui qui l’a enregistrée, et seul le thread qui a enregistré cette touche de raccourci peut annuler son inscription, donc un cheval de Troie (Trojan horse) ne pourra pas prendre possession du processus Winlogon.exe.

Un hacker serait-il capable de prendre possession ce thread spécifique à Win32k.sys…?

Une fonction spécifique de Windows, SetWindowsHook, permet à une application d’installer une « procédure de crochet » qui est invoqué à chaque fois qu’une touche est enfoncée sur le clavier (avant même que les touches de raccourci soit traitées). Néanmoins,  le code du noyau de Windows contient un cas particulier pour la combinaison de touches CTRL + ALT + SUPPR qui désactive ces « crochets » de sorte que la séquence de touches ne soit pas intercepté . De plus, si votre session est verrouillé, seules les touches de raccourci appartenant à Winlogon.exe seront traitées! 

 

  • Architecture de l’authentification locale avant Windows NT 6.0

 

  • Architecture de l’authentification locale à partir de Windows NT 6.0

 

 

 

Sources :

INITIALIZING WINLOGON – http://msdn.microsoft.com/en-us/library/windows/desktop/aa375994(v=vs.85).aspx

HOW INTERACTIVE LOGON WORKS? – http://technet.microsoft.com/en-us/library/cc780332(v=ws.10).aspx#w2k3tr_intlg_how_rmil

MSV1_0 AUTHENTICATION PACKAGE – http://msdn.microsoft.com/en-us/library/windows/desktop/aa378753(v=vs.85).aspx

WINDOWS INTERNALS – http://technet.microsoft.com/en-us/sysinternals/bb963901.aspx

ALPC CLASS – http://msdn.microsoft.com/en-us/library/windows/desktop/aa964738(v=vs.85).aspx

SETWINDOWSHOOK FUNCTION – http://msdn.microsoft.com/en-us/library/windows/desktop/ms644990(v=vs.85).aspx

Non classé

jordanlaurent

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *