Agenda
Motivación para la realización del proyecto (enunciado del problema)
Metodología de trabajo
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 desparramada 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.
Metodología de trabajo
Se realizó un análisis de seguridad de las especificaciones de la Internet Engineering Task Force (IETF)
Se investigó sobre trabajos y publicaciones existentes en el area de TCP e IP, y se los analizó con el mismo criterio.
Se inspeccionó algunas implementaciones abiertas de los protocolos, con el fin de identificar vulnerabilidades en mecanismos o políticas implementadas en la industria.
En aquellos casos en los que se identificaron potenciales vulnerabilidades, se construyeron herramientas de auditoría para intentar explotarlas en sistemas reales.
Para cada caso, se propusieron contramedidas tendientes a mitigar las vulnerabilidades identificadas.
En la medida que fue posible, se discutió con fabricantes tanto sobre las vulnerabilidades, como también sobre las posibles contremedidas.
Algunas cuestiones a analizar 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 posibles algoritmos para reensamblar 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 cuestiones a analizar 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 aleatorizació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.
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.
Página siguiente  |