PDF de programación - Resultados de un análisis de seguridad de los protocolos TCP e IP

Resultados de un análisis de
seguridad de los protocolos
TCP e IP

Fernando Gont

(proyecto realizado para UK CPNI)

Congreso Seguridad en Cómputo

19 al 26 de septiembre de 2008, Ciudad de México, México

Agenda

problema)

Motivación para la realización del proyecto (enunciado del

Breve descripción de algunas áreas de trabajo
Resultados preliminares
Discusión sobre algunos aspectos de seguridad en TCP

Enunciado del problema
Durante los últimos veinte años, el descubrimiento de

vulnerabilidades en implementaciones de los protocolos TCP/IP, y
en los propios protocolos, han llevado a la publicación de un gran
número de reportes de vulnerabilidad por parte de fabricantes y
CSIRTs.

Como resultado, la documentación de todas estas vulnerabilidades
se encuentra esparcida en una gran cantidad de documentos que
suelen ser difíciles de identificar.

Asimismo, algunos de estos documentos proponen contramedidas a
las mencionadas vulnerabilidades, sin realizar un análisis minucioso
de las implicancia de las mismas sobre la interoperabilidad de los
protocolos.

Desafortunadamente, el trabajo de la comunidad en esta área no ha

reflejado cambios en las especificaciones correspondientes de la
IETF.

Situación actual

Se hace notablemente dificultoso realizar una implementación

segura de los protocolos TCP/IP a partir de las especificaciones de
la IETF.

Nuevas implementaciones de los protocolos re-implementan

vulnerabilidades encontradas en el pasado.

Nuevos protocolos re-implementan mecanismos o políticas cuyas

implicancias de seguridad ya eran conocidas a partir de otros
protocolos (por ejemplo, RH0 en IPv6).

No existe ningún documento que apunte unificar criterios sobre las

vulnerabilidades de los protocolos, y las mejores prácticas para
mitigarlas.

No existe ningún documento que sirva como complemento a las

especificaciones oficiales, para permitir que la implementación
segura de los protocolos TCP/IP sea una tarea viable.

Descripción del proyecto

En los últimos años, UK CPNI (Centre for the Protection of National

Infrastructure) – antes UK NISCC (National Infrastructure Security
Co-ordination Centre) – se propuso llenar este vacío para los
protocolos TCP e IP.

El objetivo fue producir documentos que sirvieran de complemento
a las especificaciones de la IETF, con el fin de que, mínimamente,
nuevas implementaciones no posean vulnerabilidades ya
conocidas, y que las implementaciones existentes puedan mitigar
estas vulnerabilidades.

Dichos documentos se irían actualizando en respuesta a los

comentarios recibidos por parte de la comunidad y al
descubrimiento de nuevas vulnerabilidades.

Finalmente, se espera llevar este material al ámbito de la Internet

Engineering Task Force (IETF), para promover cambios en los
estándares correspondientes.

Algunas áreas de trabajo en IP

Rango de valores aceptables para cada campo del encabezamiento
En algunos casos, los rangos aceptables dependen del valor de

otros campos. Ejemplo: IHL (Internet Header Length), Total
Length, link-layer payload size.

Análisis de las posibles implicancias de seguridad de cada

mecanismo y política del protocolo.
Ejemplo: El campo TTL se puede utilizar (al menos en teoría)

para OS fingerprinting, physical-device fingerprinting, TTL-
triangulation, evasión de NIDS, GTSM, etc.

Procesamiento deseable de las distintas opciones IP

Ejemplo: source-routing? IP Security options?

Analizar distintas políticas posibles para aplicar junto con distintos
mecanismos. Por ej., en el caso del reensamble de fragmentos IP:
¿Qué chequeos de validación podrían realizarse para evitar la
evasión de NIDS? ¿Qué políticas se podrían implementar para
minimizar ataques de DoS?

Algunas áreas de trabajo en TCP

Establecer claramente el rango de valores aceptables para cada

campo del encabezamiento y opciones
Ejemplo: Valores aceptables para la opción TCP MSS (Rose

attack)

Analizar posibles algoritmos para la selección de puertos efímeros.
Reducir las posibilidades de abusar de los algoritmos de control de

congestión de TCP.

Analizar posibles algoritmos para el manejo del buffer de

reensamblado, y del buffer de retransmisión de datos.

Analizar como reducir la precisión de técnicas de “remote OS finger-

printing”.
¿No es demasiada la precisión de nmap? ¿Realmente necesita
cada versión de un sistema operativo de cada fabricante hacer
algo distinto? ¿No se pueden unificar criterios?

Resultados preliminares

Para el caso del protocolo IP, se generó un documento de 50

páginas, con mas de 70 referencias a reportes de vulnerabilidad y
papers relevantes. El mismo se encuentra disponible en:
http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx

Para el caso del protocolo TCP, se generó un documento de más

de 100 páginas, con más de 100 referencias a reportes de
vulnerabilidad y papers relevantes. Este documento todavía no ha
sido publicado.

Los documentos se beneficiaron de los comentarios de

desarrolladores de implementaciones TCP/IP, tanto abiertas como
cerradas.

Cooperación

Hemos tenido el agrado de contar con una variedad de ingenieros e

investigadores del área para la revisión de los documentos sobre
seguridad en TCP e IP de este proyecto, lo cual ha contribuido muy
positivamente con nuestro trabajo.

Lamentablemente, la situación no ha sido la misma en lo que

respecta a fabricantes
En muchos casos, no se recibió respuesta alguna.
En algun caso, respuestas del tipo “como este proyecto no fue

patrocinado por nuestra compañía, no podemos hacer
comentarios técnicos” (¿?¡!)

Actividades relacionadas en la IETF (I)
Algunas porciones de este proyecto ya se llevaron a la IETF.

Ejemplos:
“Security Assessment of the Internet Protocol”: El mismo

documento publicado por CPNI en agosto de este año fue
publicado recientemente como Internet-Draft. Todavía no ha
sido adoptado como elemento de trabajo del OPSEC WG.

Aleatorización de puertos: Se presentó un documento que fue

adoptado por el TSVWG (BCP).

Ataques ICMP contra TCP: Se presentó un documento que fue

adoptado por el TCPM WG (Informational) .

Algunas otras publicaciones en el ámbito de la IETF, no vinculadas

con este proyecto:
“Recommendations for filtering ICMP messages” (draft-ietf-

opsec-icmp-filtering-00.txt): Este documento fue adoptado como
WG item por el OPSEC WG. (es increíble que en el 2008
todavía muchos crean que “se puede filtrar todo ICMP”).

Actividades relacionadas en la IETF (II)
Esta actividad suele requerir una gran cantidad de energía

Con el fin de lograr consenso, las propuestas presentadas en la
IETF suelen tener que ser modificadas a niveles en los cuales el
documento final termina difiriendo notablemente de la propuesta
original.

Existe cierta resistencia a realizar modificaciones en IPv4 (ya

que “IPv6 reemplazará a IPv4”)

Los fabricantes suelen resistirse a implementar modificaciones

vinculadas a seguridad

Breve revisión de algunos
conceptos básicos de TCP

Establecimiento de conexión

El proceso de establecimiento de conexión consiste usualmente en

el intercambio de tres segmentos.

Una vez finalizado el “three-way handshake”, los números de

secuencia (y demás parámetros) estará sincronizados, y se podrá
comenzar la transferencia de información.

Cierre de conexión
El proceso de cierre de conexión consiste usualmente en el

intercambio de cuatro segmentos:

El extremo que inicia el proceso de cierre de conexión (Host A)

usualmente queda en el estado TIME-WAIT por 4 minutos, mientras
que el otro extremo queda en el estado ficticio CLOSED.

Colisiones de connection-id’s

Debido al estado TIME-WAIT, puede suceder que al realizarse una

petición de conexión exista una encarnación previa de la misma
conexión en el sistema remoto. En tal caso, la petición de conexión
fallará.

Claramente, esta situación (colisión de connection-id’s) es

indeseable, por lo cual, en la medida que sea posible, deberá ser
evitada.

Discusión de algunos
aspectos de seguridad de
TCP

TCP Initial Sequence
Numbers

TCP Initial Sequence Numbers (I)

El RFC 793 menciona que los ISN’s se han deben resultar en una

secuencia monótonamente creciente, a partir de un timer global,
con el fin de evitar la superposición de espacios de secuencia.
Desde ahí (año 1981), se ha asumido que la generación de ISN’s a
de forma lineal es crucial para la confiabilidad de TCP (protección
contra segmentos “viejos”).

Sin embargo, la verdadera protección contra segmentos viejos está

provista por otros dos mecanismos que no tienen relación alguna
con los ÍSN:
“Quiet time concept”: Cuando se reinicia el sistema, se debe

esperar 2*MSL antes de transmitir segmentos TCP.

TIME-WAIT state: Cuando se finaliza una conexión TCP, el
extremo que realizó el “active close” debe permanecer en el
estado TIME-WAIT por 2*MSL, asegurando así que los
segmentos “viejos” desaparezcan de la red.

TCP Initial Sequence Numbers (II)

En la implementación tradicional BSD, el generador de ISN se

inicializaba en 1 al iniciar el sistema, y se incrementaba en 64000
cada medio segundo, y en 64000 por cada conexión establecida.

Basado en la suposición de que los ISNs son generados

linealmente, BSD implementó una modificación al comportamiento
estandar de TCP, con el fin de permitir altas tasas de petición de
conexión. S