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

Muchas organizaciones no son centralizado. Las filiales, las corporaciones virtuales y los empleados que se trasladan hacen la idea de la creación del canal distinguido a cualquier punto exigido lógicamente imposible. La concepción de las redes virtuales abastece la decisión del problema que ha surgido por medio de туннелирования del espacio unido de red por otras redes, intermedias y peligrosas (por ejemplo, el Internet), de ese modo позвол los puntos alejados ser locales. La decisión dada no exige las inversiones a la realización de las líneas abonadas o distinguidas en cualquier punto. Tal modo llaman a veces ' el túnel '.

Con la decisión por las redes virtuales de los problemas de los coches descentrados ha surgido otro problema. El tráfico, que se encontraba antes en los límites de la compañía, ahora es abierto para los ojos curiosos de todo el mundo. Para el mantenimiento no sólo отказоустойчивости, sino también las seguridades de la información es necesario usar los mecanismos аутентификации y la cifración. En resultado las uniones virtuales de red han unido con la defensa criptográfica, y el producto final era llamado las Redes Virtuales Particulares (VPN).

La seguridad VPN se funda en la seguridad de las actas аутентификации y la cifración. Si la criptografía VPN es débil, el grado de la defensa no más alto que en cualquier otra red no particular del traspaso de la información por el Internet. Ya que las compañías esperan que VPN extenderá el perímetro de la seguridad interior hasta la oficina alejada, la ruptura del sistema de la defensa del túnel corresponde a la destrucción de todos los sistemas de la defensa del perímetro interior. La ruptura en VPN significa prácticamente mismo, así como la ruptura por firewall.

La acta PPTP (la acta de túnel del tipo el punto-punto) era destinada a la decisión de la tarea de la creación y la dirección VPN de la red TCP/IP pública con el uso de la acta РРР estandartizada. Aunque la acta reserva el espacio para todos los tipos posibles de la cifración y аутентификации, en la mayoría de los productos comerciales se usa la versión de la acta dada para Windows NT. Esta realización es sometida al análisis en el artículo dado.

Мы han descubierto que la acta аутентификации Microsoft es débil y vulnerable por medio del ataque por el diccionario; se puede abrir la mayoría de las consignas durante algunas horas. Hemos descubierto que los modos de la cifración con el uso de llaves 40 y 128-de descarga son igualmente débiles y han abierto una serie de las ideas irrazonables, puestas en la realización, que permiten realizar otros ataques a la cifra dada. Nosotros puede abrir las uniones a través de firewall, violando las reglas de las negociaciones РРTР, y podemos pasar los ataques distintos de la renuncia en el servicio en los que usa Microsoft PPTP.

Оставшаяся la parte del trabajo es dividida del modo siguiente: En el párrafo 2 es examinado РРТР, el estándar de la acta, así como la realización Microsoft. En el párrafo 3 son examinadas dos funciones хэширования de las consignas en Microsoft PPTP y los modos del ataque a ellos. En el párrafo 4 es pasado криптоанализ de la acta аутентификации Microsoft, а en el párrafo 5 - криптоанализ de la acta de la cifración Microsoft. Otros ataques en Microsoft РРТР son examinados en el párrafo 6. Al fin, en el párrafo 7 se hacen algunas conclusiones.

РРТР - la acta, que permite cumplir туннелирование de las RRR-UNIONES por la IP-red por medio de la creación VPN. Así, el ordenador alejado en la red Х puede туннелировать el tráfico a la esclusa en la red A e imitar la conexión, con la IP-dirección interior, a la red de U.Shljuz recibe el tráfico para la IP-dirección interior y entrega a su coche alejado a las redes de H.Sushchestvujut dos modos básicos del uso РРТР: por el Internet y por коммутируемым a las uniones. Настояща el artículo es orientado sobre el uso РРТР como VPN a la conexión directa del cliente al Internet.

El funcionamiento РРТР consiste en инкапсулировании de los paquetes de la red virtual en los paquetes РРР, que a su vez, инкапсулируются en los paquetes GRE (Generic Routing Incapsulation), entregado por IP del cliente a la esclusa - el servidor РРР y atrás. Junto con el canal инкапсулированных de los datos hay una sesión que dirige en base a TCP. Los paquetes de la sesión que dirige permiten pedir el estatus y acompañar la información de señales entre el cliente y el servidor. El canal de la dirección es iniciado por el cliente en el servidor sobre el TSR-PUERTO 1723. Es En la mayoría de los casos el canal dosdirigido, por que el servidor manda las interpelaciones por el servidor y al contrario.

РРТР no calumnia los algoritmos concretos аутентификации y las actas; en cambio él abastece la base para la discusión de los algoritmos concretos. Las negociaciones no son inherente solamente РРТР, se refieren a las variantes existentes de las negociaciones РРР que contienen en ССР, СНАР otras ampliaciones y los perfeccionamientos РРР.

2.1 РРТР de Microsoft

Microsoft РРТР es la parte la SO Windows NT Server, se puede gratis recibir el software dado del Web-sitio Microsoft. La conexión se realiza por medio del tablero de mando y el redactor del registro. La realización РРТР dada se usa ampliamente en las aplicaciones VPN comerciales, por ejemplo Aventail y Freegate precisamente porque forma parte de la SO Microsoft.

El servidor Microsoft РРТР puede existir solamente para Windows NT, aunque el software de clientes existe para Windows NT, algunas versiones Windows y Windows 98. La realización Microsoft apoya tres variantes аутентификации:

1. La consigna textual: el Cliente entrega al servidor la consigna en el tipo abierto.
2. La consigna heshirovannyj: el Cliente entrega al servidor хэш de la consigna (cm. El párrafo 3).
3. La llamada/repercusión: Аутентификация del servidor y el cliente con el uso de la acta MS-CHAP (la llamada/repercusión) que es descrito en el párrafo 4.

La tercera variante se llama en la documentación para los usuarios en "Autentifikatsi Microsoft", para la cifración de los paquetes РРТР es necesario permitirlo. En la elección de cualquier de dos otras variantes la cifración es irrealizable. Además, la posibilidad de la cifración (40 o 128-de descarga) es garantizada solamente en caso de que el cliente usa Windows NT. Algunos clientes Windows 95 no pueden apoyar las sesiones cifradas.

En la SO Microsoft Windows NT para la defensa de las consignas se usan dos hesh-funciones de misma dirección: хэш Lan Manager y хэш Windows NT. La función хэша Lan Manager era elaborada Microsoft para el sistema IBM OS/2 de operaciones, era integrada en Windows for Workgroups y es parcial en Windows 3.1. La función dada se usa en algunas actas аутентификации ante Windows NT. Хэш Windows NT era elaborado especialmente para la SO Microsoft Windows NT. La función хэша Lan Manager es fundada en el algoritmo DES; la Función хэша Windows NT es fundada en la hesh-función MD4 unilateral. Las dos estas funciones se usan en muchas actas аутентификации Windows NT, y no solamente en РРТР.

La función хэша Lan Manager es calculada del modo siguiente:

La transformación de la consigna en la línea 14-simbólica por medio de o отсечки de unas consignas más largas, o el complemento de las consignas cortas por los elementos de cero.

1. La sustitución de todos los símbolos del registro inferior por los símbolos del registro superior. Las cifras y los símbolos especiales se quedan sin cambios.
2. Разбиение 14-bajtovoj las líneas en dos семибайтовых las mitades.
3. El uso de cada mitad de la línea en los papeles de la llave DES, la cifración de la constante fijada por medio de cada llave, la recepción de dos 8-bajtovyh de las líneas.
4. La fusión de dos líneas para la creación de un significado de 16-bits de la hesh-función.

Los ataques de diccionario a la función хэша Lan Manager obtienen fácilmente el éxito por las causas siguientes:

La mayoría de las personas es escogida por las consignas fácilmente adivinadas.

• Todos los símbolos se transformarán en el registro superior que limita y sin aquel el número pequeño de las consignas posibles.
• No hay atadura individual (salt); dos usuarios con las consignas iguales siempre tendrán los significados iguales de la hesh-función. Así, es posible de antemano componer el diccionario хэшированных de las consignas y realizar la búsqueda de la consigna desconocida en ello. A tal acceso desde el punto de vista de la relación el tiempo/memoria el test de la consigna puede выполнятьс con la velocidad de la introducción/conclusión de discos.
• Dos семибайтовых "las mitades" de la consigna хэшируются independientemente uno de otro. Así, dos mitades pueden formarse por el método de la selección ruda independientemente uno de otro, y la complicación del ataque no supera la complicación del ataque contra семибайтового de la consigna. Las consignas, que longitud supera siete símbolos, no más fuerte, que las consignas con la longitud siete símbolos. Además, aquellas consignas, que longitud no supera siete símbolos muy simplemente discernir, ya que la segunda mitad хэша será la misma constante fijada: la cifración de la constante fijada por medio de la llave de siete ceros.

La función хэша Windows NT es calculada del modo siguiente:

1. La transformación de la consigna, la longitud hasta 14 símbolos, con la distinción de los registros en Unicode.
2. Хэширование de la consigna por medio de MD4, la recepción del significado 16-simbólico de la hesh-función.

Хэш Windows NT posee la ventaja en comparación con la función хэша Lan Manager - se diferencian los registros, las consignas pueden ser más largas que 14 símbolos, хэширование de la consigna en total en vez de разбиения de ello a las pequeñas partes - aunque falta como antes la individualidad. Así, las personas que tienen las consignas iguales, siempre tendrán igual хэшированные las consignas Windows NT. La comparación del fichero хэшированных de las consignas con el diccionario de antemano contado хэшированных de las consignas puede ser el ataque muy eficaz.

Además, es más serio el problema de la realización facilita esencialmente el descubrimiento de las consignas. Hasta aunque хэш Lan Manager era incluido según las consideraciones de la compatibilidad con las versiones anteriores, y no es necesario en las redes Windows NT, los dos significados de las hesh-funciones siempre pasan juntos. Por consiguiente, es posible cumplir la selección ruda de la consigna por medio de una hesh-función Lan Manager más débil y luego cumplir el test tomando en cuenta el registro para la selección del significado de la hesh-función Windows NT^.

РРР contiene los modos distintos del tratamiento аутентификации. Un de los modos es la acta аутентификации la llamada-apretón de manos (СНАР). La realización PPP СНАР por la compañía Microsoft (MS-CHAP) coincide casi con el método аутентификации, usado para аутентификации de los clientes en las Windows-redes.

MS-CHAP Funciona del modo siguiente:

1. El cliente pide la llamada del nombre de red.
2. El servidor devuelve восьмибайтовый la llamada casual.
3. El cliente calcula la hesh-función Lan Manager, añade cinco ceros para la creación 21-bajtovoj las líneas y divide la línea en tres семибайтовых de la llave. Cada llave se usa para шифрации de la llamada que lleva a la aparición del significado 24-de descarga cifrado. Vuelve al servidor como la repercusión. El cliente cumple mismo con la hesh-función Windows NT.
4. El servidor busca el significado de la hesh-función en la base de datos, cifra la interpelación por medio de la hesh-función y lo iguala con los significados recibidos cifrados. Si coinciden, аутентификация acaba.
   El servidor puede cumplir la comparación por la hesh-función Windows NT o por la hesh-función Lan Manager; los resultados deben coincidir. Хэш, usado por el servidor, depende de la bandera concreta en el paquete. Si la bandera es establecida, el servidor cumple el test por medio de la hesh-función Windows NT; en caso contrario el test se cumple por medio de la hesh-función Lan Manager.

La acta de la llamada/repercusión es estandartizada; el uso de la llamada casual del nombre hace imposible los ataques de diccionario en MS-CHAP y el fichero de las hesh-funciones anotadas de las consignas. Al mismo tiempo, ya que hasta en Windows las NT-redes se usan los dos significados de la hesh-función, se puede atacar en cada caso una hesh-función Lan Manager más débil. Ya que la respuesta del cliente es rota en tres partes, y cada parte es cifrada independientemente de otros, se puede atacar la acta MS-CHAP misma.

Los últimos ocho bytes de la hesh-función Lan Manager representan la constante en caso de que la longitud de la consigna no supera siete símbolos. Esto es justo, a pesar de la llamada casual. Por consiguiente, los últimos ocho bytes de la repercusión del cliente representarán la llamada cifrada por medio de la constante dada. Es fácil comprobar, si no supera la longitud de la consigna de siete símbolos. Después de que que ataca encuentra el significado de la hesh-función Lan Manager, él puede usar esta información para la reconstitución de la hesh-función Windows NT.

El ataque puede ser esencialmente acelerado a expensas del uso activo de los cálculos preliminares y el examen meticuloso de las debilidades de la hesh-función Lan Manager y la acta MS-CHAP. Más son llevados los detalles del ataque optimizado:

Р₀-Р₁₃ - байты de la consigna. Н₀-Н₁₅ - байты las hesh-funciones Lan Manager, que se transformará en 21-bajtovyj la llave К₀-К₂₀. S - la constante fijada usada en la hesh-función Lan Manager. La llamada Con y 24-bajtovyj la repercusión R_o-R₂3. El malhechor puede saber C y R y quiere encontrar el Rublo

1. Prueben todas las combinaciones К₁₄ posibles, К₁₅. El significado correcto se separa, cuando Con se convierte en R₁₆..., R₂₃ con la llave К₁₄, К₁₅, 0,0,0,0,0. A esto se va aproximadamente 2¹⁵ operaciones.
2. Prueben los significados Р₇ probables..., Р₁₃. Se puede rápidamente arrojar los significados equivocados por medio de la cifración S y la comprobación de la coincidencia de últimos dos bytes del significado recibido con К₁₄ y К₁₅. (Hay así solamente una variante de cada uno 2¹⁶). Cada variante Р₇ que se ha quedado..., Р₁₃ concede el significado-candidato para К₈..., К₁₃. Para comprobar el significado-candidato, comprueben todos los significados К₇ posibles para ver, si hay tal, a que Con es cifrado en R₈..., R_{15 al} significado-candidato К₈..., К₁₅. Si hay tal К₇, la conjetura para Р₇..., Р₁₃ casi es justa con seguridad. Si no existe, es necesario escoger otro significado para Р₇..., Р₁₃. Si existen N de las variantes Р₇ probables..., Р₁₃, se puede pasar la selección del significado justo por N de las cifraciones de test.
   Prestaréis la atención que ya que en la acta no hay ajuste individual, este ataque puede ser esencialmente acelerado por medio de la sustitución el tiempo/memoria. Si es N de las cifraciones de antemano calculadas de test, la reconstitución del significado Р₇ justo..., Р₁₃ exigirá N/2^{16 las} operaciones.
3. Después de la posición Р₇..., Р₁₃, la reconstitución Р₀..., Р₆ exige M de las tentativas, donde M - el número de los significados Р₀ probables..., Р₆. Además, ya que no hay ajuste individual, el ataque puede ser cumplido por N/2^{8 de las} tentativas A m los significados preliminarmente calculados.

Кроме de aquel, la acta dada permite cumplir аутентификацию solamente al cliente. Que ataca, que cumple la sustitución de la unión, puede es trivial enmascararse bajo el servidor. Si la cifración está permitido, que ataca no puede mandar y aceptar el mensaje (no forzará la cifra), sin embargo usando el significado viejo de la llamada él puede recibir dos sesiones del texto cifrado por una llave (cm. Los ataques más).

5.1 Descripción МРРЕ

La acta de la cifración en одноранговых las redes (МРРЕ) abastece la metodología para la cifración de los paquetes РРТР. Él supone la existencia de la clave secreta conocida a los dos participantes de la unión, y usa поточный la cifra RC4 con 40 o la llave 128-de descarga. Tal método de la instalación del uso МРРЕ es una de las funciones de la acta de la dirección de la compresión РРР (ССР) y es descrito en la aplicación de S.Posle de la instalación del régimen del trabajo comienza la sesión РРР por la transmisión de los paquetes de los datos cifrados. Es importante notar que son cifrados solamente aquellos paquetes РРР, que números de las actas están en la banda 0x0021-0x00fa. Todos los otros paquetes pasan sin cifración, aunque la cifración está permitido. Los tipos de los paquetes, que cifración se realiza/no se realiza, son reglamentados por el documento RFC 1700. Para cualesquiera paquetes no es abastecido аутентификация.

En МРРЕ 40-bitovyj la llave RC4 está determinada del modo siguiente:

1. La generación que determina 64-bitovogo de la llave de la hesh-función Lan Manager de la consigna del usuario (conocido a los usuarios y el servidor) por medio de SHA.
2. La instalación de los mayores 24 bit de clave en el significado 0xD1269E.

128-bitovyj la llave RC4 está determinada del modo siguiente:

1. La asociación хэша Windows NT y 64-bitovogo del significado casual dado por el servidor en el trabajo de la acta MS-CHAP. El número dado es mandado al cliente por la acta del cambio, por eso es conocido el cliente, y el servidor.
2. La generación que determina 128-bitovogo de la llave de los resultados de la etapa anterior por medio de SHA.

La llave resultante se usa para la inicialización RC4 por el modo regular, а luego para la cifración del byte de los datos. Después de cada 256 paquetes - МРРЕ apoya el contador, en que se fija el número de los paquetes - es generada una nueva llave RC4 por las reglas siguientes:

1. La generación de la llave que determina - 64-bitovogo para 40-bitovogo las cifraciones y 128-bitovogo para 128-bitovogo las cifraciones - la vía хэширования de la llave anterior y la llave inicial por medio de SHA.
2. Si es necesario 40-bitovyj la llave, la instalación de los mayores 24 bit de clave en el significado 0xD1269E.

La longitud del paquete РРТР típico compone 200 bytes, incluso el encabezamiento.

A la pérdida de la sincronización pasa реинициализация RC4 con el uso de la llave corriente. Hay también una posibilidad de la renovación de la llave RC4 después de cada paquete; esta posibilidad baja la eficiencia de la cifración aproximadamente medio, ya que a la ejecución de los cambios planificados de la llave RC4 es necesario el tiempo.

5.2 Reconstitución de la llave

En МРРЕ el grado de la defensa de la llave no supera el grado de la defensa de la consigna. La mayor parte de las consignas tiene esencialmente menos de 40 palas de la seguridad y se abren por medio de los ataques de diccionario. La Hesh-función Lan Manager todavía боле es vulnerable: tomando en cuenta la longitud máxima de la porción, el alfabeto limitado y la ausencia de los símbolos del registro inferior, es imposible generar 128-bitovyj la llave, aunque el usuario lo quiere hacer. En la documentación por МРРЕ es descrita la bandera para el cálculo 40-bitovogo de la llave RC4 en razon de la hesh-función Windows NT, y no Lan Manager, pero esta función no es realizada. No hay modos del cálculo 128-bitovogo de la llave RC4 en razon de la hesh-función Windows NT, aunque tal variante sería más segura (aunque esencialmente menos seguro, que 128-bitovyj la llave casual.)

En cualquier caso, el grado general de la defensa compone no 40 o 128 palas, а la cantidad de las palas энтропии de la consigna. En razon de los datos experimentales es recibido que al inglés le es propia энтропия 1,3 pala al símbolo. Los cambios del registro, las cifras y los símbolos especiales suben esencialmente este significado. Cualquier ataque, que usa el diccionario de las consignas débiles, puede ser capaz leer cifrado МРРРЕ el tráfico. Además, los encabezamientos estilizados en el paquete РРР facilitan la recogida de los textos conocidos y la base para la comprobación de la llave adivinada.

40-bitovyj el algoritmo RC4 es sujeto a unas vulnerabilidades más serias. Ya que no es previsto el ajuste individual, que ataca puede preparar el diccionario de los encabezamientos РРР cifrados, а luego encontrar rápidamente el texto dado cifrado en el diccionario. Durante la búsqueda de los lugares en los paquetes МРРЕ, donde puede contener el texto no cifrado, que ataca puede aprovecharse de la multitud de enlaces por SMB y NetBIOS, que pasan a las uniones Microsoft estandartizadas.

Además, mismo 40-bitovyj la llave RC4 es generada cada vez cuando el usuario инициализирует la acta РРТР. Ya que RC4 representa el modo de la cifración con la realimentación por la salida, simplemente forzar la cifra por dos sesiones. La vulnerabilidad seria se nota en большей las partes de las especificaciones МРРЕ frescas, aunque ha desaparecido de la versión anterior. Ni en una versión de la documentación Microsoft no es indicado que la misma llave se usa como en directo, y en dirección opuesta que garantiza que para la cifración de dos textos diferentes se usa el mismo flujo de las llaves.

128-bitovyj RC4 usa durante la generación de las llaves 64-bitovuju la cantidad casual. Tal acceso hace por poco práctica el ataque de diccionario. Como antes, el método de la selección ruda de la consigna es más eficaz, que el método de la selección ruda del espacio de las llaves. El número casual significa también que para dos sesiones con una consigna serán usados diferente 128-bitovye las llaves RC4, aunque para la cifración del texto en las dos direcciones será usada la misma llave.

5.3 Ataques de la revuelta битов

RC4 - El modo поточного las cifraciones con la realimentación por la salida, no es abastecido además аутентификация del flujo del texto cifrado. Ya que en МРРРЕ no es previsto otro modo аутентификации, que ataca puede imperceptible cambiar los significados de las palas en la cifra. Si la acta del nivel inferior es sensible al cambio del significado de las palas concretas - el permiso/prohibición de funciones cualesquiera, la elección de las variantes, el lanzamiento de los parámetros - este ataque puede ser bastante eficaz. Prestaréis la atención, la realización de este ataque que ataca no tiene que saber la llave de la cifración o la consigna del cliente. Claro, tales ataques pueden descubrirse o ser prevenidos por las actas del nivel superior.

5.4. El ataque por medio de ресинхронизации

Si durante la transmisión se pierde el paquete, o llega el paquete con el número equivocado en el encabezamiento МРРЕ, pasa ресинхронизация de la llave. La parte que ha aceptado el paquete equivocado, manda al remitente la interpelación en ресинхронизацию. Por la aceptación de la interpelación dada, el remitente реинициализирует establece las tablas RC4 las palas "es arrojado" (flushed) en el encabezamiento МРРЕ. Si el sistema descubre en el paquete establecido las palas "es arrojado", реинициализирует las tablas RC4 y establece el contador de los paquetes en concordancia con el significado recibido.

Se crea así el problema, cuando que ataca puede o dar las interpelaciones en ресинхронизацию, o arrojar los paquetes МРРЕ con los significados equivocados del contador de los paquetes. Si cumplirlo constantemente ante el cambio para 256 pacto, cuando hay un cambio de la llave de sesión, que ataca puede obtener el éxito - la llave de sesión no será cambiada.

A pesar de que los ataques a las actas MS-CHAP y МРРЕ lleven a la negación absoluta de la utilidad y la seguridad MS PPTP, es necesario mencionar algunos ataques interesantes.

6.1 monitoring Pasivo

Se puede recibir la cantidad estupenda de la información, si observar simplemente el tráfico de la sesión РРТР entregada por la red. Tal información es inestimable para el análisis del tráfico, debe protegerla. Con todo eso, el servidor da a todos los los que deseen tales noticias, como la cantidad máxima de los canales accesibles. Se puede usar esta información para la instalación de la dimensión correspondiente del servidor РРТР y el control de su cargamento. Si que ataca entrega regularmente los paquetes PPTP_START_SESSION_REQUEST, él puede observar la creación de las nuevas uniones y el cierre de las uniones existentes. De ese modo que ataca puede recoger la información sobre el sistema y los modelos de su uso, además no tiene que ser una serie.

Por medio de la instalación de los medios estandartizados de la presentación y el desciframiento de las líneas de comunicación públicas de los servidores Microsoft PPTP era recibida la información siguiente:

• La IP-dirección del cliente
• La IP-dirección del servidor
• La cantidad de los canales RRTR virtuales, accesibles en el servidor
• La versión RAS del cliente
• El nombre del cliente NetBIOS
• La identificación del productor del cliente
• La identificación del productor del servidor
• La IP-dirección del cliente en el túnel interior virtual
• Interior el DNS-servidor, que atienden el cliente
• El nombre del usuario sobre el cliente
• Basta la información para la recepción de los significados de las hesh-funciones de las consignas de los usuarios
• Basta la información para la recepción del significado МРРЕ inicial
• El significado corriente del paquete cifrado para el cliente ante реинициализацией RC4
• El significado corriente del paquete cifrado para el servidor ante реинициализацией RC4

En cualquier caso, cuando el canal de comunicación es cifrado el usuario supone algún nivel de la confidencialidad, la información enumerada más arriba no debe ser accesible tan fácilmente. Para Microsoft PPTP no hay modo fácil cifrar esta información, ya que los derrames pasan fuera del canal controlado МРРЕ. En algunos casos, estos paquetes representan los paquetes de configuración y de ajuste para la cifración en los límites МРРЕ, y deben передаватьс antes del comienzo de la cifración. La única decisión es la cifración del canal de la dirección o la reducción aguda de la cantidad de la información, entregada por él.

6.2 Intercepción de las negociaciones РРР

Los paquetes de las negociaciones РРР pasan antes del comienzo de la cifración y después de su terminación. Ya que el método ресинхронизации de las llaves se realiza con el uso de los paquetes de RRR ССР, estos canales de comunicación no pueden ser cifrados del mismo modo. Añadiremos que real аутентификация de los paquetes dados no se cumple. La etapa de la configuración es abierta por completo para el ataque.

La sustitución del paquete de configuración que describe el DNS-servidor, permite dirigir todo el sistema del reconocimiento de los nombres al servidor falso de los nombres.

Exactamente así como, la sustitución del paquete que contiene la IP-dirección interior de túnel, permite dar una vuelta alrededor файрволы, que realizan la filtración de los paquetes por las reglas, ya que el cliente se conectará a los coches exteriores de la red interior protegida.

6.3 Canales de la dirección y la renuncia en el servicio en el servidor

En el artículo dado al canal de la dirección РРТР le es dedicada no muy la mayor parte. Parcialmente porque es incomprensible, para que este canal existe. Todo que es realizado por medio de este canal adicional, se puede realizar por los canales RRR o involucrar los fragmentos no utilizados del encabezamiento GRE.

Otra causa era la realización Microsoft del canal de la dirección. Hemos descubierto rápidamente que violar simplemente la capacidad de trabajo del coche Windows NT con el servidor РРТР, a veces esto llevaba a la aparición "de la pantalla azul". En realidad, es difícil pasar el test del canal de la dirección y no violar el trabajo del servidor РРТР. Es tanto difícil que la mayor parte de los ataques, предпринимавшихс para el estudio de los problemas teoréticos de la seguridad del canal de la dirección, llevaba a la infracción del trabajo del servidor antes, que los ataques podían funcionar. Más es descrita la parte pequeña de tests que llevaban a la infracción del trabajo Windows NT Server con establecidos Service Pack 3:

• El ciclo por los paquetes PPTP_CLEAR_CALL_REQUEST para pasar el espacio de 16-bits de los identificadores de la llamada.
• El exceso de todos los significados posibles e imposibles, que pueden contener en el campo el Tipo del paquete del encabezamiento del paquete РРТР.
• La transmisión de los significados inadmisibles en el encabezamiento del paquete de la dirección РРТР.

Todos los paquetes arriba indicados pueden salir al servidor РРТР por файрвола, sin cualquiera аутентификации. Se supone que no hay configuración файрвола, que permite entregar РРТР al servidor РРТР de las ciertas IP-direcciones o las redes. Sin embargo, si los usuarios tienen una posibilidad de dirigirse al servidor РРТР de cualquier punto del mundo, que ataca debe tener la posibilidad también mandar la interpelación de cualquier punto del mundo.

6.4. Las filtraciones de información potenciales sobre el cliente.

El cliente Windows 95 no cumple la limpieza exigida de los portapapeles, y por eso se permite la filtración de información en los mensajes de la acta. Aunque en la documentación РРТР es dicho que en el paquete PPTP_START_SESSION_REQUEST los símbolos después del nombre del ordenador y el productor deben ser arrojados en 0х00, Windows 95 esto no hace.

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.

Son mostrados más arriba los símbolos que contienen después del nombre del ordenador y las líneas del productor. En байтах 82-86 contiene el nombre del ordenador, que para el cliente Windows 95 siempre equivale "local". El byte 113 - aquel lugar, donde debe содержатьс la línea del productor. A la presentación del paquete Windows NT análogo es descubierto que todos los símbolos de "la basura" son arrojados en 0х00.

Существует la posibilidad evidente de la filtración de información según cómo y donde se usan y se instalan las estructuras de los datos y que pasa sobre el sistema de clientes. La apreciación de la filtración de información dada tiene que realizar el análisis ulterior del código Windows 95.

La realización РРТР de Microsoft es vulnerable desde el punto de vista de la realización, y posee las faltas serias desde el punto de vista de la acta. La acta аутентификации tiene las vulnerabilidades conocidas, a que era indicado no sólo aquí, sino también en los grupos, por ejemplo, L0pht. La cifración es cumplida incorrectamente, en la realización dada se usa поточный la cifra con la realimentación por la salida, aunque sería más oportuna блоковый la cifra "la cifra-cadenita de bloqueo" (CBC). Para vincular débil аутентификацию a la cifración Microsoft mala ha dado la llave de la cifración como la función de la consigna del usuario en vez del uso del fuerte algoritmo del cambio para las llaves como Diffi-Hellmana o ЕКЕ. Al fin, el canal de la dirección no аутентифицируется no es fuerte protegido.

No hemos gastado mucho tiempo por estudio de los mecanismos del mantenimiento de las IP-direcciones locales de los clientes y, cómo Microsoft trataba y si podía tomar en consideración él la vulnerabilidad de la representación del cliente con dos direcciones. Con todo eso, hemos descubierto los problemas con las máscaras no estandartizadas подсети y el tráfico interior del túnel enviado de РРТР del servidor. ¡Los elaboradores, ser atentos!

¿Al fin, apetece subrayar que криптоанализ no ponía en duda la acta РРТР (?), pero sólo la realización de la acta de Microsoft. Aunque Microsoft usa propias ampliaciones (MS-CHAP, МРРЕ, МРРС) en РРР las secciones РРТР, el estándar РРТР no exige esto. Los productores pueden incluir las ampliaciones Microsoft en los productos según las consideraciones de la compatibilidad, pero no son obligados ограничиватьс por su uso y realizan, probable, unas decisiones más seguras. Claro, las nuevas ampliaciones para el trabajo correcto deben ser apoyadas por el cliente, así como el servidor.

¹В el curso de los experimentos se ha aclarado que algunos clientes Windows 95 apoyan аутентификацию Microsoft, а algunos - no existen. No podíamos estimar la distinción o determinar los modos, que permiten comprender, si apoya el sistema Windows dado 95 аутентификацию Microsoft. Si la acta no es apoyada, el punto en la ventana dialogal es inaccesible. Esta restricción corresponde a la declaración Microsoft que Windows 95 no abastece la seguridad y que aquellos usuarios, a que es necesaria, deben pasar en NT. Con todo eso, Microsoft declaraba que Windows 95 no trata хэш Windows NT, а usa хэш Lan Manager. Sin embargo los clientes Windows 95 entregan las dos hesh-funciones. De nuestro análisis del código Windows 95 no está claro, por qué la cifración no es posible realizar en los clientes Windows 95.

²В a la documentación Microsoft le es dicho que la longitud de las consignas Windows NT puede alcanzar 128 símbolos, y la hesh-función Windows NT acepta las consignas de tal longitud. Sin embargo, el dispatcher de los usuarios limita la longitud de las consignas hasta 14 símbolos. En la documentación MS-СНАР es mencionada también esta restricción, que se ha confirmado durante los experimentos.

^{Los 3} hackers, Conocidos el medio, L0pthcrack, automatiza el proceso de la selección de la consigna de su hesh-significado. En Pentium Pro 200, L0phtcrack 2.0 puede comprobar el fichero con 200 consignas en un minuto con el uso 8 мегабaйтного del diccionario de las consignas.

⁴ no investigábamos ni el generador mismo de los números seudocasuales, ni su firmeza criptográfica.

[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. IT-24, 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 Y 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.