Comment la pré-authentification de Kerberos augmente-t-elle la sécurité?

11

Cette entrée de FAQ (et le RFC lui-même) indique que la pré-authentification corrige une faiblesse dans les implémentations initiales de Kerberos qui le rendait vulnérable aux attaques de dictionnaire hors ligne.

La FAQ indique:

La forme de pré-authentification la plus simple est connue sous le nom de PA-ENC-TIMESTAMP. Il s'agit simplement de l'horodatage actuel chiffré avec la clé de l'utilisateur.

Si un attaquant parvient à renifler un paquet contenant ces données de pré-authentification, n'est-ce pas également vulnérable à une attaque par dictionnaire? J'ai le texte chiffré, je connais l'horodatage d'origine - en quoi ce scénario est-il différent?

security kerberos vulnerabilities Sedate Alien
la source
Je suis un peu en retard pour la fête :). Je pense que supposer que l'attaquant a l'horodatage d'origine n'est pas vrai dans cette question. Il s'agit d'une attaque de «texte chiffré connu» et non d'une attaque de «texte en clair connu», sinon ce serait drôle. Nous ne pouvons pas supposer que l'attaquant a à la fois du texte en clair et du texte chiffré, car il connaît également l'algorithme, alors quel est le défi ici ?? Ou peut-être qu'il me manque quelque chose ici ...
Ashkan
À la fin de mon commentaire précédent, après avoir reconsidéré la question, j'ai eu l'idée que si nous supposons que l'attaque est une attaque en `` texte clair connu '' (ce qui signifie que l'attaquant connaît l'horodatage exact), alors vous avez raison, l'étape de pré-authentification ne ne fournit pas de sécurité supplémentaire car il peut essayer les mots de passe éventuellement mal choisis et trouver la clé, sinon, il le fait. Je me demande donc quel type d'attaque ce serait?
Ashkan

Réponses:

16

Lorsque vous n'appliquez pas la pré-authentification, l'attaquant peut envoyer directement une demande fictive d'authentification. Le KDC renverra un TGT chiffré et l'attaquant peut le forcer brutalement hors ligne. Vous ne verrez rien dans vos journaux KDC, sauf une seule demande de TGT.

Lorsque vous appliquez une pré-authentification d'horodatage, l'attaquant ne peut pas demander directement aux KDC le matériel chiffré à forcer brutalement hors ligne. L'attaquant doit crypter un horodatage avec un mot de passe et le proposer au KDC. Oui, il peut le faire encore et encore, mais vous verrez une entrée de journal KDC chaque fois qu'il échoue à la préautorisation.

Ainsi, la pré-authentification d'horodatage empêche un attaquant actif. Il n'empêche pas un attaquant passif de renifler le message d'horodatage chiffré du client au KDC. Si l'attaquant peut renifler ce paquet complet, il peut le forcer brutalement hors ligne.

Les atténuations de ce problème incluent l'utilisation de mots de passe longs et une bonne politique de rotation des mots de passe pour rendre le forçage brut hors ligne irréalisable, ou l'utilisation de PKINIT ( http://www.ietf.org/rfc/rfc4556.txt )

anonyme
la source
+1 Merci d'avoir souligné la différence entre un attaquant actif et un attaquant passif.
Harvey Kwok,
Remarque, un article complet avec ce détail apparaît en 2014 ici: social.technet.microsoft.com/wiki/contents/articles/…
Martin Serrano
5

J'ai trouvé un article ( Extraire les mots de passe Kerberos via l'analyse de type de cryptage RC4-HMAC ) sur IEEE Xplore qui est quelque peu pertinent à ce sujet. Ils semblent impliquer que si un paquet de pré-authentification est capturé, ce n'est pas différent.

Si un attaquant est capable de capturer les paquets de pré-authentification et veut prendre l'identité d'un utilisateur valide, l'attaquant devra effectuer les procédures effectuées par le KDC. L'attaquant devra utiliser la procédure de décryptage dans le type de cryptage convenu et essayer d'exécuter différents mots de passe par rapport aux données capturées. S'il réussit, l'attaquant dispose du mot de passe de l'utilisateur.

Sedate Alien
la source