Exploration des entêtes HTTP WWW-Authenticate et Authorization
Entêtes HTTP WWW-Authenticate et Autorization?
HTTP prend en charge l’utilisation de plusieurs mécanismes d’authentification pour contrôler l’accès aux pages et aux autres ressources. Ces mécanismes sont tous basés sur l’utilisation du code d’état 401 et de l’en-tête de réponse « WWW-Authenticate ». Le client utilise alors l’entête « Autorization » pour fournir au serveur des éléments d’authentification.
Les mécanismes d’authentification HTTP les plus répandu sont les suivants:
Anonymous
Une demande anonyme ne contient aucune information d’authentification. Cela équivaut à accorder à chacun l’accès à la ressource.
Basic
Le client envoie le nom d’utilisateur et le mot de passe sous forme de texte codé en base64 non chiffré. Il ne doit être utilisé qu’avec HTTPS, car le mot de passe peut être facilement capturé et réutilisé via HTTP.
Digest
Le client envoie une forme hachée du mot de passe au serveur. Ce mécanisme est destiné à remplacer l’authentification de base mais reste malgré tout faiblement sécurisé. L’authentification nécessite l’utilisation de comptes de domaine Windows.
NTLM
Cela utilise un mécanisme de défi / réponse sécurisé qui empêche la capture de mot de passe ou les attaques par relecture sur HTTP. Cependant, l’authentification est par connexion et ne fonctionnera qu’avec les connexions persistantes HTTP/1.1. Pour cette raison, il peut ne pas fonctionner avec tous les proxies HTTP et peut introduire un grand nombre d’allers-retours réseau si les connexions sont régulièrement fermées par le serveur Web.
KERBEROS
L’authentification « negotiate » choisit automatiquement entre le protocole Kerberos et NTLM, selon la disponibilité. Le protocole Kerberos est utilisé s’il est disponible; dans le cas contraire, l’authentification NTLM est tentée. L’authentification Kerberos offre des améliorations importantes notamment en terme de sécurité par rapport à NTLM.
-> Nous allons ici particulièrement nous focaliser sur deux de ces cinq mécanismes: Negotiate:NTLM et Negotiate:KERBEROS, Nous allons tenter d’y voir plus clair, de déchiffrer et analyser le contenu de ces entêtes.
Présentation de la maquette
Notre environnement sera relativement simple. Un client (WIN8) et un serveur (SRV2012) membre d’un domaine TEST.LOCAL. Sur ce dernier est installé IIS 8. Si vous souhaitez mettre en place une plateforme équivalente et configurer IIS 8 pour une authentification Kerberos, vous pouvez suivre ce lien.
Pour cette analyse nous allons utiliser:
- Fiddler qui sera installé sur le client et configuré en interception HTTPS. Pour rappel, Fiddler est un outil qui va nous aider à capturer le trafic réseau entre un site et un client. Pour le télécharger vous pouvez vous rendre sur ce lien.
- KerbWWW – V1 que j’ai développé en utilisant la librairie Kerberos.Net pour Visual Studio. Grace à cette application, nous allons pouvoir déchiffrer le contenu d’une entête « Autorization » qui utilise le protocole Kerberos.
Kerberos ou NTLM?
Nous l’avons vu en introduction, Kerberos sera le protocole d’authentification privilégié si l’ensemble de la chaîne est correctement configurée (SPN, compte de service, IIS, etc…); dans le cas contraire, l’authentification NTLM sera utilisée. Comment différencier, dans une analyse de trame quel est le protocole utilisé?
Lançons Fiddler, et tentons une connexion à notre site monsite.test.local:
- Le client initie une connexion vers le serveur WEB (Request: GET /HTTP/1.1)
- Le serveur WEB lui répond (Response: HTTP/1.1 401 Unauthorized) en lui indiquant les protocoles qu’il supporte: Negotiate puis NTLM dans l’entête WWW-Authenticate.
Logiquement dans l’étape d’après (code HTTP 304) le client, va tenter une authentification sur le premier protocole. Ici Negotiate (Kerberos). Nous pouvons identifier le protocole utilisé en regardant le début du contenu de l’entête « Autorization ».
Si celle ci commence par
- YII, le protocole Kerberos est utilisé:
- TlRMTVNTUA (NTLMSSP codé en base 64), le protocole NTLM est utilisé :
Ces entêtes sont donc encodées en base 64, il sera aisé de le vérifier en utilisant l’outil TextWizard intégré à Fiddler et en supprimant « Negotiate » au début du message:
Le résultat est affiché sous la forme binaire. En Kerberos, une grande partie du message est chiffré à l’aide d’une clé Ks, calculée depuis le mot de passe du compte machine ou compte exécutant le service (SPN).
Si vous êtes toujours intéressé nous pouvons aller plus loin et analyser le contenu de ces entêtes. Vous pouvez alors consulter la suite de l’article 😉
WWW-Authenticate: Negotiate-Kerberos
Nous avons vu dans le début de cet article que les entêtes « WWW-Authenticate » et « Autorization » pour Kerberos sont encodées en base64. Nous allons nous focaliser sur cette dernière qui contient les information d’identification d’un utilisateur. Une fois décodée, celle ci s’affiche alors en format binaire, incompréhensible pour l’humain. Pour autant nous pouvons « parser » le contenu avec un programme afin d’en lire une petite partie en clair. La partie qui contient les informations sur le compte utilisateur qui vient s’authentifier est chiffrée.
Rappel : pour un SPN donné, la partie chiffrée d’un ticket de service l’est avec la clé Kerberos du compte associé. Dans notre cas par la clé Ks du compte de service cible utilisé par le pool d’application IIS sur lequel le SPN est configuré. Nous allons devoir connaitre cette clé Ks pour déchiffrer l’entête « Autorization » contenue dans cette trame KRB_AP_REQ. Pour cela nous allons utiliser l’outil maintenant bien connu KTPASS pour générer un fichier Keytab (Vous pouvez consulter l’article en suivant ce lien pour connaitre la méthode génération).
Pour info, le fichier Keytab est aussi un fichier binaire, mais celui ci n’est pas chiffré.
Nous allons ensuite utiliser l’outil KerbWWW.exe spécialement développé pour cette démonstration et présent dans le ZIP téléchargeable en suivant ce lien. Afin de lire le fichier keytab précédemment généré et en exploiter son contenu, il faudra cliquer sur le bouton « 1- Lire KeyTab ».
Le contenu du fichier keytab s’affiche alors en clair. Rappelez vous, nous avions lancés ktpass avec l’option -crypto All qui signifie que tous les types cryptographiques supportés peuvent être utilisés et présent dans le fichier généré. Nous les retrouvons donc dans l’application de manière compréhensible pour un humain.
Nous allons ensuite extraire à partir de Fiddler (ou pourquoi pas à partir de n’importe quel navigateur en mode développeur) l’entête « Autorization » au format base64 et la copier (sans le préfixe « negotiate » dans le champ « Entêtes Autorization encodées » ci dessous:
Vous pouvez des à présent cliquer sur « 2 – decode » pour consulter la partie non chiffrée présente dans l’entête « Autorization ». Un message en rouge, vous informe que celle ci est partiellement déchiffrée. En réalité elle a juste été convertie depuis un format base64 et rendue lisible.
Pour aller plus loin dans notre recherche et consulter la partie normalement chiffrée, nous allons devoir récupérer le contenu « PasswordBytes » provenant du fichier Keytab. Il suffira de copier/coller dans le champ « PasswordBytes ». N’importe quel « PasswordBytes » présent dans le Keytab pourra être utilisé.
Une fois copié, il faut cliquer à nouveau sur « 2 – Décode » pour que le contenu du « Autorization » s’affiche alors complètement déchiffré.
Et donc je trouve quoi dans l’entête « Autorization » quand Kerberos est utilisé? Vous pouvez consulter ici un exemple: www-authenticate uncrypted
WWW-Authenticate:Negotiate-NTLM
Il faut noter que l’utilisation de NTLM n’est pas aussi sûre que Digest et certains autres schémas; NTLM est légèrement meilleur que le schéma d’authentification de base, cependant il a au moins l’avantage d’être facile à comprendre et à explorer. Nous allons simplement utiliser l’outil Fiddler installé sur le Client et configuré en interception HTTPS. NTLM utilise aussi l’encodage en base 64 mais aucun des messages étant chiffrés, il sera possible de les consulter en clair via l’onglet « Auth » de Fiddler.
Lançons Fiddler, et tentons une connexion à notre site monsite.test.local. Ce dernier étant configuré pour utiliser l’authentification Negociate (Kerberos) en priorité, nous allons nous connecter au site via son adresse IP (https://192.168.0.102). Cette méthode permet de court-circuiter Kerberos et utiliser plutot NTLM.
La séquence d’authentification est basé sur le schéma ci dessous (les # représentent les numéros de trame Fiddler présent dans les captures):
Le client initie une connexion vers le serveur WEB (Request: GET /HTTP/1.1). Le serveur WEB lui répond (Response: HTTP/1.1 401 Unauthorized) en lui indiquant les protocoles qu’il supporte: Negotiate puis NTLM dans l’entête WWW-Authenticate.
Vous remarquerez que le scénario débute de la même manière que pour Kerberos mais la suite va être différente. Ne pouvant pas utiliser Kerberos le client va envoyer une entête « Authorization » commençant par TlRMTVNTUA (NTLMSSP codé en base 64).
Le client envoie un message au serveur. Cela contient principalement une liste de fonctionnalités prises en charge par le client et demandées par le serveur. En option, il peut également fournir au serveur le nom du poste de travail du client et le domaine auquel le poste de travail client est membre. Ces informations sont utilisées par le serveur pour déterminer si le client est éligible pour une authentification locale.Nous sommes dans le message NTLM type1:
Le serveur répond avec un message de type 2. Cela contient une liste des fonctionnalités prises en charge et acceptées par le serveur. Plus important encore, il contient un Challenge (ou nonce) généré par le serveur.
Le client répond au défi avec un message de type 3. Cela contient plusieurs informations sur le client, y compris le domaine et le nom d’utilisateur de l’utilisateur client. Il contient également une ou plusieurs réponses au défi de type 2.
Les réponses dans le message de type 3 constituent l’élément le plus critique, car elles prouvent au serveur que le client a connaissance du mot de passe du compte. Le processus d’authentification établit un contexte partagé entre les deux parties impliquées; Cela inclut une clé de session partagée, utilisée pour les opérations de signature et de scellement ultérieures.