Криптоанализ du procès-verbal de tunnel du type le point-point (PPTP) de Microsoft



Bruce Schneier, Peter Mudge
e-mail : {schneier, mudge} @counterpane.com


 1. L'introduction



Plusieurs organisations ne sont pas centralisées. Les filiales, les corporations virtuelles et les collaborateurs se déplaçant font l'idée de la création du canal mis en relief vers n'importe quel point demandé logiquement impossible. La conception des réseaux virtuels assure la décision du problème apparaissant par voie de туннелирования de l'espace uni de réseau par d'autres réseaux, intermédiaires et dangereux (par exemple, Internet), alors позвол aux points exclus devenir local. La décision donnée ne demande pas les investissements sur la tenue абонируемых ou les lignes mises en relief à n'importe quel point. Un tel moyen parfois appellent ' le tunnel '.

Dans la mesure de la décision par les réseaux virtuels des problèmes des voitures décentrées est apparu un autre problème. Le trafic, qui se trouvait plus tôt dans la limite de la compagnie, est ouvert maintenant pour des yeux curieux de tout le monde. Pour la garantie non seulement отказоустойчивости, mais aussi les sécurités de l'information il est nécessaire d'utiliser les mécanismes аутентификации et шифрования. Les liaisons finalement virtuelles de réseau ont uni avec la protection cryptographique, et le produit final était appelé comme les Réseaux Virtuels Particuliers (VPN).

La sécurité VPN se fonde sur la sécurité des procès-verbaux аутентификации et шифрования. Si la cryptographie VPN est faible, le degré de la protection non plus haut que dans n'importe quel autre réseau non particulier du transfert d'information selon Internet. Puisque les compagnies espèrent que VPN élargira le périmètre de la sécurité intérieure jusqu'au bureau exclu, la rupture du système de la protection du tunnel correspond à la destruction de tous les systèmes de la protection du périmètre intérieur. La rupture à VPN signifie pratiquement même que la rupture pour firewall.

Le procès-verbal PPTP (le procès-verbal de tunnel du type le point-point) était destiné à la décision de la tâche de la création et la gestion VPN du réseau public TCP/IP avec l'utilisation du procès-verbal standard РРР. Bien que le procès-verbal réserve l'espace pour les types tous possibles шифрования et аутентификации, dans la plupart des produits commerciaux on utilise la version du procès-verbal donné pour Windows NT. Notamment cette réalisation est soumise à l'analyse dans l'article donné.

Мы ont découvert que le procès-verbal аутентификации Microsoft est faible et vulnérable par voie de l'attaque selon le dictionnaire; on peut ouvrir la plupart des mots d'ordre pendant quelques heures. Nous avons découvert que les moyens шифрования avec l'utilisation de clés 40 et 128-de décharge sont également faibles et ont ouvert une série d'idées irraisonnables mises dans la réalisation, qui permettent de réaliser d'autres attaques contre le chiffre donné. Nous peut ouvrir les liaisons par firewall, en violant les règles des négociations РРTР, et nous pouvons passer de diverses attaques du refus du service contre ceux qui utilise Microsoft PPTP.

Оставшаяся la partie du travail est divisée comme il suit : Dans le paragraphe 2 est examiné РРТР, le standard du procès-verbal, ainsi que la réalisation Microsoft. Dans le paragraphe 3 on examine deux fonctions хэширования des mots d'ordre à Microsoft PPTP et les moyens de l'attaque contre eux. Dans le paragraphe 4 est passé криптоанализ du procès-verbal аутентификации Microsoft, mais dans le paragraphe 5 - криптоанализ du procès-verbal шифрования Microsoft. D'autres attaques sur Microsoft РРТР sont examinées dans le paragraphe 6. Enfin, dans le paragraphe 7 se font certaines conclusions.


 2. Le procès-verbal de tunnel du type le point-point



РРТР - le procès-verbal, qui permet d'accomplir туннелирование des RRR-LIAISONS par l'IP-réseau par voie de la création VPN. Ainsi, l'ordinateur exclu dans le réseau Х peut туннелировать le trafic sur l'écluse au réseau Chez et imiter la connexion, avec l'IP-adresse intérieure, vers le réseau d'U.Shljuz reçoit le trafic pour l'IP-adresse intérieure et transmet à sa voiture exclue dans le réseau d'H.Sushchestvujut deux moyens principaux de l'utilisation РРТР : selon Internet et selon les liaisons commutées. Настояща l'article est orienté sur l'utilisation РРТР comme VPN à la connexion directe du client à Internet.

Le fonctionnement РРТР consiste à инкапсулировании des paquets du réseau virtuel aux paquets РРР, qui à son tour, инкапсулируются aux paquets GRE (Generic Routing Incapsulation), transmis selon IP du client vers l'écluse - le serveur РРР et à l'inverse. En commun avec le canal инкапсулированных des données il y a une séance dirigeant sur la base de TCP. Les paquets de la séance dirigeant permettent de demander le statut et accompagner l'information d'alarme entre le client et le serveur. Le canal de la gestion est initié par le client sur le serveur sur le TSR-PORT 1723. C'est Dans la plupart des cas le canal double orienté, selon qui le serveur envoie les demandes sur le serveur et vice versa.

РРТР ne stipule pas les algorithmes concrets аутентификации et les procès-verbaux; au lieu de cela il assure la base pour la discussion des algorithmes concrets. Les négociations ne sont pas inhérentes seulement РРТР, ils se rapportent aux variantes existant des négociations РРР se trouvant à ССР, СНАР d'autres élargissements et les perfectionnements РРР.

2.1 РРТР de Microsoft

Microsoft РРТР est la partie des GUÊPES Windows NT Server, on peut gratuitement recevoir le logiciel donné du Web-site Microsoft. La connexion se réalise avec l'aide du panneau de commande et le rédacteur du registre. La réalisation donnée РРТР est utilisée largement dans les applications commerciales VPN, par exemple Aventail et Freegate justement puisque fait partie des GUÊPES Microsoft.

Le serveur Microsoft РРТР peut exister seulement pour Windows NT, bien que le logiciel de client existe pour Windows NT, certaines versions Windows et Windows 98. La réalisation Microsoft soutient trois variantes аутентификации :

  1. Le mot d'ordre de texte : le Client transmet au serveur le mot d'ordre dans l'aspect ouvert.
  2. Le mot d'ordre heshirovannyj : le Client transmet au serveur хэш du mot d'ordre (voir le paragraphe 3).
  3. L'appel/résonance : Аутентификация du serveur et le client avec l'utilisation du procès-verbal MS-CHAP (l'appel/résonance) qu'est décrit dans le paragraphe 4.

La troisième variante s'appelle à la documentation pour les utilisateurs "Autentifikatsi Microsoft", pour шифрования des paquets РРТР il faut le permettre. Au choix de chacun de deux autres variantes шифрование est irréalisable. En outre la possibilité шифрования (40 ou 128-de décharge) est garantie seulement dans le cas où le client utilise Windows NT. Certains clients Windows 95 ne peuvent pas soutenir les séances chiffrées.


 3. Криптоанализ des fonctions хэширования des mots d'ordre Windows NT



Dans les GUÊPES Microsoft Windows NT pour la protection des mots d'ordre on utilise deux hesh-fonctions unidirectionelles : хэш Lan Manager et хэш Windows NT. La fonction хэша Lan Manager était élaborée Microsoft pour le système d'exploitation IBM OS/2, elle était intégrée à Windows for Workgroups et partiellement à Windows 3.1. La fonction donnée est utilisée dans certains procès-verbaux аутентификации devant Windows NT. Хэш Windows NT était spécialement élaboré pour les GUÊPES Microsoft Windows NT. La fonction хэша Lan Manager est fondée sur l'algorithme DES; la Fonction хэша Windows NT est fondée sur l'hesh-fonction unilatérale MD4. Les deux ces fonctions sont utilisées dans plusieurs procès-verbaux аутентификации Windows NT, et non seulement à РРТР.

La fonction хэша Lan Manager est calculée comme il suit :

La transformation du mot d'ordre en la ligne 14-symbolique par voie d'ou отсечки de plus longs mots d'ordre, ou les compléments des mots d'ordre courts par les éléments nuls.

  1. Le remplacement de tous les symboles du registre inférieur sur les symboles du registre supérieur. Les chiffres et les symboles spéciaux restent sans changements.
  2. Разбиение de la ligne de 14 octets sur deux семибайтовых les moitiés.
  3. L'utilisation de chaque moitié de la ligne dans le rôle de la clé DES, шифрование de la constante fixée avec l'aide de chaque clé, la réception de deux lignes de 8 octets.
  4. La fusion de deux lignes pour la création d'une signification de 16 bits de l'hesh-fonction.

Les attaques de dictionnaire contre la fonction хэша Lan Manager atteignent facilement du succès pour les raisons suivantes :

La plupart des gens est choisie par les mots d'ordre facilement devinés.

  • Tous les symboles seront transformés en registre supérieur que limite et sans celui-là le petit nombre des mots d'ordre possibles.
  • Il n'y a pas de rattachement individuel (salt); deux utilisateurs avec les mots d'ordre identiques auront toujours les significations identiques de l'hesh-fonction. Ainsi, on peut d'avance faire le dictionnaire хэшированных des mots d'ordre et réaliser la recherche du mot d'ordre inconnu dans lui. À ce point de vue du point de vue de la relation le temps/mémoire le test du mot d'ordre peut выполнятьс à la vitesse de l'introduction/conclusion de disque.
  • Deux семибайтовых "les moitiés" du mot d'ordre хэшируются est indépendant l'un de l'autre. Ainsi, deux moitiés peuvent s'approcher furtivement par la méthode de la sélection grossière indépendamment l'un de l'autre, et la complexité de l'attaque n'excède pas la complexité de l'attaque contre семибайтового du mot d'ordre. Les mots d'ordre, la longueur de qui excède sept symboles, non plus fortement, que les mots d'ordre avec la longueur sept symboles. En outre ces mots d'ordre, la longueur de qui n'excède pas sept symboles très simplement reconnaître, puisque la deuxième moitié хэша est la même constante fixée : шифрование de la constante fixée avec l'aide de la clé de sept zéros.

La fonction хэша Windows NT est calculée comme il suit :

  1. La transformation du mot d'ordre, la longueur jusqu'à 14 symboles, avec la distinction des registres à Unicode.
  2. Хэширование du mot d'ordre avec l'aide de MD4, la réception de la signification 16-symbolique de l'hesh-fonction.

Хэш Windows NT possède l'avantage en comparaison de la fonction хэша Lan Manager - se distinguent les registres, les mots d'ordre peuvent être plus longs 14 symboles, хэширование du mot d'ordre en tout au lieu de разбиения de lui sur de petites parties - bien que l'individualité toujours manque. Ainsi, les gens ayant les mots d'ordre identiques, auront toujours identique хэшированные les mots d'ordre Windows NT. La comparaison du fichier хэшированных des mots d'ordre avec le dictionnaire d'avance compté хэшированных des mots d'ordre peut être l'attaque très effective.

En outre est plus sérieux le problème de la réalisation facilite beaucoup le dévoilement des mots d'ordre. Même bien que хэш Lan Manager soit inséré selon les considérations de la compatibilité avec les versions précédentes, et il ne faut pas dans les réseaux Windows NT, les deux significations des hesh-fonctions sont transmises toujours ensemble. Donc, on peut accomplir la sélection grossière du mot d'ordre avec l'aide d'une plus faible hesh-fonction Lan Manager et puis accomplir le test en tenant compte du registre pour la sélection de la signification de l'hesh-fonction Windows NT.


 4. Криптоанализ MS-CHAP



РРР contient de divers moyens du traitement аутентификации. Un des moyens est le procès-verbal аутентификации l'appel-poignée de main (СНАР). La réalisation PPP СНАР par la compagnie Microsoft (MS-CHAP) coïncide presque avec la méthode аутентификации, utilisé pour аутентификации des clients dans les Windows-réseaux.

MS-CHAP Fonctionne comme il suit :

  1. Le client demande l'appel du nom de réseau.
  2. Le serveur rend восьмибайтовый l'appel accidentel.
  3. Le client calcule l'hesh-fonction Lan Manager, ajoute cinq zéros pour la création de la ligne de 21 octets et divise la ligne en trois семибайтовых de la clé. Chaque clé est utilisée pour шифрации de l'appel qu'amène à l'apparition 24-de décharge шифрованного les significations. Il revient au serveur comme la résonance. Le client accomplit le même avec l'hesh-fonction Windows NT.
  4. Le serveur cherche la signification de l'hesh-fonction dans la base de données, chiffre la demande avec l'aide de l'hesh-fonction et le compare avec reçu шифрованными par les significations. S'ils coïncident, аутентификация s'achève.
    Le serveur peut accomplir la comparaison selon l'hesh-fonction Windows NT ou de l'hesh-fonction Lan Manager; les résultats doivent coïncider. Хэш, utilisé par le serveur, dépend du drapeau concret dans le paquet. Si le drapeau est établi, le serveur accomplit le test avec l'aide de l'hesh-fonction Windows NT; dans le cas contraire le test est accompli avec l'aide de l'hesh-fonction Lan Manager.

Le procès-verbal de l'appel/résonance est standard; l'utilisation de l'appel accidentel du nom fait impossible les attaques de dictionnaire sur MS-CHAP et le fichier des hesh-fonctions inscrites des mots d'ordre. En même temps, puisque même à Windows les NT-réseaux on utilise les deux significations de l'hesh-fonction, on peut dans chaque cas d'attaquer une plus faible hesh-fonction Lan Manager. Puisque la réponse du client est cassée à trois parties, et chaque partie est chiffrée indépendamment des autres, on peut attaquer le procès-verbal lui-même MS-CHAP.

Le dernier huit octet de l'hesh-fonction Lan Manager représentent la constante dans le cas où la longueur le mot d'ordre n'excède pas sept symboles. Cela exactement, malgré l'appel accidentel. Donc, le dernier huit octet de la résonance du client représenteront l'appel chiffré avec l'aide de la constante donnée. Il est facile de contrôler, si la longueur le mot d'ordre de sept symboles n'excède pas. Après que l'attaquant trouve la signification de l'hesh-fonction Lan Manager, il peut utiliser cette information pour la restitution de l'hesh-fonction Windows NT.

L'attaque peut être beaucoup accélérée aux frais de l'utilisation active des calculs préalables et l'examen méticuleux des faiblesses de l'hesh-fonction Lan Manager et le procès-verbal MS-CHAP. Ensuite on amène les détails de l'attaque optimisée :

Р013 - Octets du mot d'ordre. Н015 - octets de l'hesh-fonction Lan Manager, qui sera transformée en clé de 21 octets К020. S - la constante fixée utilisée dans l'hesh-fonction Lan Manager. L'appel Avec et la résonance de 24 octets Ro-R23. Le malfaiteur peut connaître C et R et veut trouver Р

  1. Essayez les combinaisons toutes possibles К14, К15. La signification juste se détache, quand Avec se transforme à R16..., R23 avec la clé К14, К15, 0,0,0,0,0. Sur cela partent environ 215 opérations.
  2. Essayez les significations probables Р7..., Р13. Les significations incorrectes on peut vite rejeter par la voie шифрования S et les contrôles de la coïncidence le dernier deux octet de la signification reçue avec К14 et К15. (Il y a ainsi seulement une variante de chacuns 216). Chaque variante restée Р7..., Р13 la signification-candidat pour К8 accorde..., К13. Pour contrôler la signification-candidat, contrôlez les significations toutes possibles К7 pour voir, s'il y a un tel, à qui Avec est chiffré à R8..., R15 à la signification-candidat К8..., К15. S'il y a un tel К7, la conjecture pour Р7..., Р13 est fidèle presque sans faute. Si est absent, il faut choisir une autre signification pour Р7..., Р13. Si existent N des variantes probables Р7..., Р13, on peut passer la sélection de la signification fidèle pour N de test шифрований.
    Ferez l'attention que puisque dans le procès-verbal il n'y a pas de réglage individuel, cette attaque peut être beaucoup accélérée avec l'aide du remplacement le temps/mémoire. Si est N d'avance calculé de test шифрований, la restitution de la signification fidèle Р7..., Р13 demandera N/216 des opérations.
  3. Après la présence Р7..., Р13, la restitution Р0..., Р6 demande М les tentatives, où М - le nombre des significations probables Р0..., Р6. De nouveau, puisqu'il n'y a pas de réglage individuel, l'attaque peut être accomplie pour N/28 des tentatives à М les significations préalablement calculées.

Кроме de celui-là, le procès-verbal donné permet d'accomplir аутентификацию seulement le client. Attaquant, accomplissant la substitution de la liaison, peut trivialement se déguiser en serveur. Si шифрование est permis, attaquant ne pourra pas envoyer et accepter le message (ne forcera pas le chiffre), en utilisant cependant une vieille signification de l'appel lui pourra recevoir deux sessions du texte chiffrées par une clé (voir les attaques ensuite).


 5. Криптоанализ МРРЕ



5.1 Description МРРЕ

Le procès-verbal шифрования à одноранговых les réseaux (МРРЕ) assure la méthodologie pour шифрования des paquets РРТР. Il suppose l'existence de la clé confidentielle connue aux deux participants de la liaison, et utilise le chiffre à la chaîne RC4 avec 40 ou la clé 128-de décharge. Une telle méthode de l'installation de l'utilisation МРРЕ est une des fonctions du procès-verbal de la gestion de la compression РРР (ССР) et est décrit dans l'application de S Après l'installation du mode commence la séance РРР pour la transmission des paquets des données chiffrées. Il est important de marquer que l'on chiffre seulement ces paquets РРР, les numéros des procès-verbaux de qui sont dans la gamme 0x0021-0x00fa. Tous les autres paquets sont transmis sans шифрования, même si шифрование est permis. Les types des paquets, шифрование qui se réalise/non se réalise, sont réglementés par le document RFC 1700. Pour n'importe quels paquets n'est pas assuré аутентификация.

À МРРЕ la clé de 40 bits RC4 est définie comme il suit :

  1. La génération de la clé définissant de 64 bits de l'hesh-fonction Lan Manager du mot d'ordre de l'utilisateur (connu à l'utilisateur et le serveur) avec l'aide de SHA.
  2. L'installation des 24 bits principaux de la clé à la signification 0xD1269E.

La clé de 128 bits RC4 est définie comme il suit :

  1. Le groupement хэша Windows NT et la signification de 64 bits accidentelle donnée par le serveur au travail du procès-verbal MS-CHAP. Le nombre donné est envoyé au client selon le procès-verbal de l'échange, c'est pourquoi il est connu le client, et le serveur.
  2. La génération de la clé définissant de 128 bits des résultats de l'étape précédente avec l'aide de SHA.

La clé résultante est utilisée pour l'initialisation RC4 par le moyen ordinaire, mais puis pour шифрования octet des données. Après chaque 256 paquets - МРРЕ soutient le compteur, dans lequel on fixe le nombre des paquets - on génère une nouvelle clé RC4 selon conforme aux règles :

  1. La génération de la clé définissant - de 64 bits pour de 40 bits шифрования et de 128 bits pour de 128 bits шифрования - la voie хэширования de la clé précédente et la clé initiale avec l'aide de SHA.
  2. Si on demande la clé de 40 bits, l'installation des 24 bits principaux de la clé à la signification 0xD1269E.

La longueur le paquet typique РРТР fait 200 octet, y compris le titre.

À la perte de la synchronisation se passe реинициализация RC4 avec l'utilisation de la clé en cours. Il y a aussi une possibilité de la rénovation de la clé RC4 après chaque paquet; cette possibilité réduit l'efficacité шифрования environ à moitié, puisque sur l'exécution des changements planifiés de la clé RC4 on demande le temps.

5.2 Restitution de la clé

À МРРЕ le degré de la protection de la clé n'excède pas le degré de la protection du mot d'ordre. La grande partie des mots d'ordre a beaucoup moins de 40 bats de la sécurité et se découvrent avec l'aide des attaques de dictionnaire. L'Hesh-fonction Lan Manager encore боле est vulnérable : en tenant compte de la longueur maxima la portion, l'alphabet limité et l'absence des symboles du registre inférieur, il est impossible de générer la clé de 128 bits, même si l'utilisateur veut faire cela. À la documentation selon МРРЕ fait un lapsus le drapeau pour le calcul de la clé de 40 bits RC4 en vertu de l'hesh-fonction Windows NT, et non Lan Manager, mais cette fonction n'est pas encore réalisée. Il n'y a pas de moyens du calcul de la clé de 128 bits RC4 en vertu de l'hesh-fonction Windows NT, bien qu'une telle variante serait plus sûre (bien que beaucoup moins sûr, que la clé de 128 bits accidentelle.)

Dans tous les cas, le degré total de la protection fait non 40 ou 128 bits, mais la quantité de bats de l'entropie du mot d'ordre. En vertu des données expérimentales est reçu que l'entropie de 1,3 bits sur le symbole est propre à la langue anglaise. Les changements du registre, le chiffre et les symboles spéciaux augmentent beaucoup cette signification. N'importe quelle attaque, qui utilise le dictionnaire des faibles mots d'ordre, peut être capable de lire chiffré МРРРЕ le trafic. En outre стилизованные les titres dans le paquet РРР facilitent la collecte des textes connus et la base pour le contrôle de la clé devinée.

L'algorithme de 40 bits RC4 est exposé plus sérieux уязвимостям. Puisque on ne prévoit pas le réglage individuel, attaquant peut préparer le dictionnaire des titres chiffrés РРР, mais puis vite trouver le texte donné chiffré dans le dictionnaire. À la recherche des places dans les paquets МРРЕ, où le texte non chiffré peut se trouver, attaquant peut se servir de la multitude de liens selon SMB et NetBIOS, qui se passent aux liaisons standard Microsoft.

De plus, la même clé de 40 bits RC4 est générée toutes les fois, quand l'utilisateur initialise le procès-verbal РРТР. Puisque RC4 représente le moyen шифрования avec la liaison en retour selon la sortie, simplement forcer le chiffre pour deux séances. La vulnérabilité sérieuse s'enregistre à большей les parties des spécifications fraîches МРРЕ, bien qu'elle disparaisse de la version précédente. Dans une version de la documentation Microsoft n'est pas indiqué que la même clé est utilisée comme à direct, et dans le sens inverse que garantit que pour шифрования de deux différents textes on utilise le même flux des clés.

De 128 bits RC4 utilise en train de la génération des clés la variable aléatoire de 64 bits. Une telle approche fait peu pratique l'attaque de dictionnaire. Toujours, la méthode de la sélection grossière du mot d'ordre est plus effective, que la méthode de la sélection grossière de l'espace des clés. Le nombre accidentel signifie aussi que pour deux sessions avec un mot d'ordre on utilise de différentes clés de 128 bits RC4, bien que pour шифрования du texte dans les deux directions on utilise la même clé.

5.3 Attaques de la révolution des bits

RC4 - Le moyen à la chaîne шифрования avec la liaison en retour selon la sortie, n'est pas assuré de plus аутентификация du flux шифрованного du texte. Puisque à МРРРЕ n'est pas prévu d'un autre moyen аутентификации, attaquant peut imperceptiblement changer les significations du bats dans le chiffre. Si le procès-verbal du niveau inférieur est sensible au changement de la signification des bats concrets - les permissions/interdictions de quelques fonctions, le choix des variantes, la faille des paramètres - cette attaque peut être assez effective. Ferez l'attention, la tenue de cette attaque attaquant ne doit pas connaître la clé шифрования ou le mot d'ordre du client. Certes, telles attaques peuvent se trouver ou être prévenues par les procès-verbaux du niveau supérieur.

5.4. L'attaque par voie de ресинхронизации

Si en train de la transmission se perd le paquet, ou le paquet avec le numéro incorrecte dans le titre МРРЕ, se passe ресинхронизация de la clé vient. La partie qui a accepté le paquet incorrecte envoie à l'expéditeur la demande sur ресинхронизацию. Selon l'acceptation de la demande donnée, l'expéditeur реинициализирует les tableaux RC4 établit le bit "est enlevé" (flushed) dans le titre МРРЕ. Si le système découvre dans le paquet le bit établi "est enlevé", elle реинициализирует les tableaux RC4 et établit le compteur des paquets conformément à la signification reçue.

Il y a ainsi un problème, quand l'attaquant peut ou donner les demandes sur ресинхронизацию, ou mettre les paquets МРРЕ avec les significations incorrectes du compteur des paquets. Si accomplir c'est constant devant l'échange pour le 256-ème pacte, quand il y a un remplacement de la clé de séance, l'attaquant peut réussir - la clé de séance ne sera pas changée.


 6 Autres attaques sur MS-PPTP



Malgré le fait que les attaques contre les procès-verbaux MS-CHAP et МРРЕ amènent à la négation complète de l'utilité et la sécurité MS PPTP, il est nécessaire de mentionner quelques attaques intéressantes.

6.1 monitoring Passif

On peut recevoir la quantité saisissante d'information, si observer simplement le trafic de la séance РРТР transmis par le réseau. Une telle information est inappréciable pour l'analyse du trafic, il faut la protéger. Néanmoins, le serveur donne à tous les intéressés telles informations, comme la quantité maximum des canaux accessibles. On peut utiliser cette information pour l'installation du montant correspondant du serveur РРТР et le contrôle de sa charge. Si attaquant transmet régulièrement les paquets PPTP_START_SESSION_REQUEST, il peut observer la création des nouvelles liaisons et la clôture des liaisons existant. Par ce moyen attaquant peut recueillir l'information sur le système et les clichés de son utilisation, de plus il ne doit pas être une série.

Par voie de l'installation des moyens standard de l'affichage et le déchiffrement des lignes de transmission publiques des serveurs Microsoft PPTP on recevait l'information suivante :

  • L'IP-adresse du client
  • L'IP-adresse du serveur
  • La quantité de canaux virtuels RRTR accessibles sur le serveur
  • La version RAS du client
  • Le nom du client NetBIOS
  • L'identification du producteur du client
  • L'identification du producteur du serveur
  • L'IP-adresse du client dans le tunnel intérieur virtuel
  • Intérieur du DNS-serveur, servant le client
  • Le nom de l'utilisateur sur le client
  • Il suffit l'information pour la réception des significations des hesh-fonctions des mots d'ordre des utilisateurs
  • Il suffit l'information pour la réception de la signification initiale МРРЕ
  • La signification en cours шифрованного du paquet pour le client devant реинициализацией RC4
  • La signification en cours шифрованного du paquet pour le serveur devant реинициализацией RC4

Dans tous les cas, quand la voie de communication est chiffrée l'utilisateur suppose un certain niveau de la confidentialité, l'information énumérée ci-dessus ne doit pas être accessible ainsi facilement. Pour Microsoft PPTP il n'y a pas de moyen facile de chiffrer cette information, puisque les fuites se passent en dehors du canal contrôlé МРРЕ. Dans certains cas, ces paquets représentent les paquets de configuration et directeurs pour шифрования dans le cadre d'МРРЕ, et ils doivent передаватьс jusqu'au début шифрования. La seule décision est шифрование du canal de la gestion ou la réduction rude de la quantité d'information transmise selon lui.

6.2 Interception des négociations РРР

Les paquets des négociations РРР sont transmis jusqu'au début шифрования et après sa fin. Puisque la méthode ресинхронизации des clés se réalise avec l'utilisation des paquets de RRR ССР, ces voies de communication ne peuvent pas être chiffrées de la même manière. Nous ajouterons que réel аутентификация des paquets donnés n'est pas accompli. L'étape de la configuration est entièrement ouverte pour l'attaque.

La substitution du paquet de configuration décrivant le DNS-serveur, permet de diriger tout le système de la reconnaissance des noms sur le serveur faux des noms.

Exactement aussi, la substitution du paquet contenant l'IP-adresse intérieure de tunnel, permet de contourner файрволы, réalisant le filtrage des paquets selon les règles, puisque le client est connecté aux voitures extérieures du réseau intérieur protégé.

6.3 Canaux de la gestion et le refus du service sur le serveur

Dans l'article donné on consacre au canal de la gestion РРТР pas trop la grande partie. Partiellement parce qu'il est incompréhensible, pourquoi ce canal existe. Tout qu'est réalisé avec l'aide de ce canal supplémentaire, on peut réaliser par les canaux RRR ou faire participer les fragments non utilisés du titre GRE.

Une autre raison était la réalisation Microsoft du canal de la gestion. Nous avons découvert vite que violer simplement la capacité de travail de la voiture Windows NT avec le serveur РРТР, parfois cela amenait à l'apparition de "l'écran bleu clair". En fait, il est difficile d'organiser le test du canal de la gestion et ne pas violer le travail du serveur РРТР. Il est tellement difficile que la grande partie des attaques, предпринимавшихс pour l'étude des problèmes théoriques de la sécurité du canal de la gestion, amenait à la violation du travail du serveur plus tôt, que les attaques pouvaient fonctionner. Ensuite on décrit une petite partie de tests amenant à la violation du travail Windows NT Server avec établis Service Pack 3 :

  • Le cycle selon les paquets PPTP_CLEAR_CALL_REQUEST pour passer l'espace de 16 bits des identificateurs de l'appel.
  • L'excédent des significations toutes possibles et impossibles, qui peuvent se trouver dans le champ le Type du paquet du titre du paquet РРТР.
  • La transmission des significations inadmissibles dans le titre du paquet de la gestion РРТР.

Tous les paquets indiqués ci-dessus peuvent partir sur le serveur РРТР à cause de файрвола, sans chacune аутентификации. Il est supposé qu'il n'y a pas de configuration файрвола, permettant de transmettre РРТР au serveur РРТР des IP-adresses définies ou les réseaux. Cependant, si les utilisateurs ont une possibilité de s'adresser au serveur РРТР de n'importe quel point du monde, attaquant doit avoir aussi la possibilité d'envoyer la demande de n'importe quel point du monde.

6.4. Les fuites potentielles de l'information sur le client.

Le client Windows 95 n'accomplit pas le nettoyage demandé des tampons, et c'est pourquoi on admet la fuite de l'information dans les messages du procès-verbal. Bien que dans la documentation РРТР soit dit que dans le paquet PPTP_START_SESSION_REQUEST les symboles après le nom de l'ordinateur et le producteur doivent être enlevés à 0х00, Windows 95 cela ne font pas.

      080 : 0000 6c6f 6361 6c00 0000 3e1e 02c1 0000. local...>.....

      096 : 0000 85c4 03c1 acd9 3fc1 121e 02c1 2e00........ ?.......

      112 : 0000 2e00 0000 9c1b 02c1 0000 0000 0000................

      128 : 0000 88ed 3ac1 2026 02c1 1049 05c1 0b00....:. &...I....

      144 : 0000 3978 00c0 280e 3dc1 9c1b 02c1 041e. 9x. (. =.......

      160 : 02c1 0e00 0000 121e 02c1 2e00 0000 2e00................

      176 : 0000 3dad 06c1 74ed 3ac1 1c53 05c1 9c1b. =... t.:. S....

      192 : 02c1 041e 02c1 0e00 0000 121e 02c1 2e00................

      208 : 0000.

On montre plus haut les symboles se trouvant après le nom de l'ordinateur et les lignes du producteur. Octets 82-86 contiennent le nom de l'ordinateur, qui pour le client Windows 95 s'aligne toujours "local". Octet 113 - cette place, où la ligne du producteur doit содержатьс. À l'affichage du paquet analogue Windows NT est découvert que tous les symboles "des ordures" sont enlevés à 0х00.

Существует la possibilité évidente de la fuite de l'information suivant que et où sont utilisés et s'installent les structures des données et que se passe sur le système de client. Pour l'estimation de la fuite donnée de l'information il est nécessaire de passer l'analyse ultérieure du code Windows 95.


 7. Les conclusions



La réalisation РРТР de Microsoft est vulnérable du point de vue de la réalisation, et possède les manques sérieux du point de vue du procès-verbal. Le procès-verbal аутентификации a connu à la vulnérabilité, à qui était indiqué non seulement ici, mais aussi dans les groupes, par exemple, L0pht. Шифрование est accompli incorrectement, dans la réalisation donnée on utilise le chiffre à la chaîne avec la liaison en retour selon la sortie, bien que serait plus opportun блоковый le chiffre "le chiffre-chaîne bloc" (CBC). Pour lier faible аутентификацию avec mauvais шифрованием Microsoft a donné la clé шифрования comme la fonction du mot d'ordre de l'utilisateur au lieu de l'utilisation du fort algorithme de l'échange pour les clés comme Diffi-Hellmana ou ЕКЕ. Enfin, le canal de la gestion non аутентифицируется n'est pas fortement protégé.

Nous n'avons pas dépensé beaucoup de temps pour l'étude des mécanismes de la garantie des IP-adresses locales des clients et, comment Microsoft tentait et s'il a pu prendre en considération la vulnérabilité de la représentation du client avec deux adresses. Néanmoins, nous avons découvert les problèmes avec les masques non standard подсети et le trafic intérieur du tunnel expédié de РРТР du serveur. Les concepteurs, soyez attentifs!

Enfin, on veut souligner que криптоанализ ne mettait pas en doute le procès-verbal РРТР (?), mais seulement la réalisation du procès-verbal de Microsoft. Bien que Microsoft utilise les élargissements personnels (MS-CHAP, МРРЕ, МРРС) à РРР les sections РРТР, le standard РРТР ne demande pas cela. Les producteurs peuvent insérer les élargissements Microsoft dans les produits selon les considérations de la compatibilité, mais ils ne sont pas engagés ограничиватьс par leur utilisation et, probablement, réalisent les décisions plus sûres. Certes, les nouveaux élargissements pour le travail correct doivent être soutenus par le client, ainsi que le serveur.


1В la marche des expériences s'est révélé que certains clients Windows 95 soutiennent аутентификацию Microsoft, mais certains - est absents. Nous n'avons pas pu estimer la différence ou définir les moyens, permettant de comprendre, si le système donné Windows 95 аутентификацию Microsoft soutient. Si le procès-verbal n'est pas soutenu, le point dans la boîte de dialogue est inaccessible. Cette restriction correspond à la demande Microsoft que Windows 95 n'assure pas la sécurité, et que ces utilisateurs, à qui elle est nécessaire, doivent passer sur NT. Néanmoins, Microsoft déclarait que Windows 95 ne travaille pas хэш Windows NT, mais utilise хэш Lan Manager. Cependant les clients Windows 95 transmettent les deux hesh-fonctions. De notre analyse du code Windows 95 est obscur, pourquoi шифрование on ne peut pas réaliser dans les clients Windows 95.

2В à la documentation Microsoft est dit que la longueur les mots d'ordre Windows NT peut atteindre 128 symboles, et l'hesh-fonction Windows NT accepte les mots d'ordre d'une telle longueur. Cependant, le dispatcher des utilisateurs limite la longueur les mots d'ordre jusqu'à 14 symboles. Dans la documentation MS-СНАР est mentionnée aussi cette restriction, qui s'est confirmée au cours des expériences.

3 pirates Connus le moyen, L0pthcrack, le procès de la sélection du mot d'ordre selon son hesh-signification automatise. Sur Pentium Pro 200, L0phtcrack 2.0 peut contrôler le fichier avec 200 mots d'ordre en une minute avec l'utilisation 8 мегабaйтного du dictionnaire des mots d'ordre.

4 nous n'étudiions pas ni le générateur lui-même des nombres pseudo-accidentels, ni sa résistance cryptographique.



 8. De la reconnaissance



Nous voudrions remercier Mark Chen, Chris Hall, Brad Kemp, Paul Jones, Ben McCann, Mark Seiden, Inderpreet Singh, David Wagner et Wray West de leurs remarques précieuses.

 La littérature



[Ave98] Aventail Corp., 1998. http://www.aventail.com.

[BV98] L. Blunk and J. Vollbrecht, ` ` PPP Extensible Authentication Protocol (EAP), "Network Working Group, RFC 2284, Mar 1998. ftp://ftp.isi.edu/in-notes/rfc2284.txt.

[CK78] T.M. Cover and R.C. King, ` ` A Convergent Gambling Estimate of Entropy, "IEEE Transactions on Information Theory V. 24 informatique, n. 4, Jul 1978, pp. 413 - 421.

[Fre98] FreeGate Corp., 1998. http://www.freegate.com.

[HLFT94] S. Hanks, T. Li, D. Farinacci, and P. Traina, ` ` Generic Routing Encapsulation (GRE), "Network Working Group, RFC 1701, Oct. 1994. ftp://ftp.isi.edu/in-notes/rfc1701.txt.

[Hob97] Hobbit, ` ` CIFS : Common Insecurities Fail Scrutiny, "Avian Research, Jan 1997.

[HPV+97] K. Hamzeh, G.S. Pall, W. Verthein, J. Taarud, and W.A. Little, ` ` Point-to-Point Tunneling Protocol, "Internet Draft, IETF, Jul 1997.

[KSWH98] J. Kelsey, B. Schneier, D. Wagner, and C. Hall, ` ` Cryptanalytic Attacks on Pseudorandom Number Generators, "Fast Software Encryption : 5th International Workshop, Springer-Verlag, 1998, pp. 168-188

[Kle90] D.V. Klein, ` ` Foiling the Cracker : A Security of, and Implications to, Password Security, "Proceedings of the USENIX UNIX Security Workshop, Aug 1990, pp. 5 - 14.

[Kli98] S. Klinger, ` ` Microsoft PPTP and RRAS for Windows NT Server 4.0, "LAN Times, Feb ? ?, 1998.

[L97a] L0pht Heavy Industries Inc, L0phtcrack, 1997.

[L97b] L0pht Heavy Industries Inc, ` ` A L0phtCrack Technical Rant, "Jul 1997. http://www.l0pht.com/l0phtcrack/rant.php.

[LS92] B. Lloyd and W. Simpson, ` ` PPP Authentication Protocols, "Network Working Group, RFC 1334, Oct 1992. ftp://ftp.isi.edu/in-notes/rfc1334.txt.

[Mey96] G. Meyer, ` ` The PPP Encryption Control Protocol (ECP), "Network Working Group, RFC 1968, Jun 1996. ftp://ftp.isi.edu/in-notes/rfc1968.txt.

[Mic96a] Microsoft Corpotation, Advanced Windows NT Concepts, New Riders Publishing, 1996. Relevent chapter at http://www.microsoft.com/communications/nrpptp.html.

[Mic96b] Microsoft Corporation, ` ` Pont-to-Point Tunneling Protocol (PPTP) Frequently Asked Questions, "Jul 1996.

[Mic97] Microsoft Corporation, ` ` Response to Security Issues Raised by the L0phtcrack Tool, "Apr 1997.

[Mic98] Microsoft Corporation, ` ` Clarification on the L0phtcrack 2.0 Tool. "Mar 1998.

[MB97] P. Mudge and Y. Benjamin, ` ` Deja Vu All Over Again, "Byte, Nov 1997.

http://www.byte.com/art/9711/sec6/art3.html.

[NBS77] National Bureau of Standards, NBS FIPS PUB 46, ` ` Data Encryption Standard, "National Bureau of Standards, U.S. Department of Commerce, Jan 1977.

[NIST93] National Institute of Standards and Technology, ` ` Secure Hash Standard, "U.S. Department of Commerce, May 93.

[Pal96a] G.S. Pall, ` ` Microsoft Point-to-Point Compression (MPPC) Protocol, "Network Working Group Internet Draft, Jul 1996.

[Pal96b] G.S. Pall, ` ` Microsoft Point-to-Point Encryption (MPPE) Protocol, "Network Working Group Internet Draft, Jul 1996.

[PZ98] G.S. Pall and G. Zorn, ` ` Microsoft Point-to-Point Encryption (MPPE) Protocol, "Network Working Group, Internet Draft, IETF, Mar 1998.

[Ran96] D. Rand, ` ` The PPP Compression Control Protocol (CCP), "Network Working Group, RFC 1962, Jun 1996. ftp://ftp.isi.edu/in-notes/rfc1962.txt.

[RP94] J. Reynolds and J. Postel, ` ` Assigned Numbers, "Networking Group, Std 2, RFC 1700, Oct 1994. ftp://ftp.isi.edu/in-notes/rfc1700.txt.

[Riv91] R.L. Rivest, ` ` The MD4 Message Digest Algorithm, "Advances in Cryptology - - CRYPTO ' 90 Proceedings, Springer-Verlag, 1991, pp. 303 - 311.

[Sch96] B. Schneier Applied Cryptography, 2nd Edition, John Wiley ET Sons, 1996.

[Sim94] W. Simpson, ` ` The Point-to-Point Protocol (PPP), "Network Working Group, STD 51, RFC 1661, Jul 1994. ftp://ftp.isi.edu/in-notes/rfc1661.txt.

[Sim96] W. Simpson, ` ` PPP Challenge Handshake Authentication Protocol (CHAP) "Network Working Group, RFC 1334, Aug 1996. ftp://ftp.isi.edu/in-notes/rfc1994.txt.

[ZC98] G. Zorn and S. Cobb, ` ` Microsoft PPP CHAP Extensions, "Network Working Group Internet Draft, Mar 1998.

Яндекс цитирования

Subscribe Subscribe.Ru
The Family Tree of Family