[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]-----BEGIN PGP SIGNED MESSAGE-----
--------------------------------------------------------------------
UNAM-CERT
Departamento de Seguridad en Computo
DGSCA- UNAM
BoletÃn de Seguridad UNAM-CERT 2004-006
Vulnerabilidades en TCP
----------------------------------------------------------------------
El CERT/UNAM-CERT, a través de sus equipos de respuesta a
incidentes de Seguridad en Cómputo, han emitido éste boletÃn donde
informan sobre una vulnerabilidad en TCP que permite a un intruso
remoto, terminar sesiones de red. La explotación sostenida de esta
vulnerabilidad podrÃa llevar a una condición de negación de
servicio. En el caso de sistemas BGP (Border Gateway Protocol), que
se basa en TCP (Transmission Control Protocol) para mantener
sesiones de red autenticadas constantes, parte de la comunidad de
Internet podrÃa ser afectada. Las operaciones de enrutamiento se
recuperarÃan rápidamente después de que termine un ataque de este tipo.
Fecha de Liberación: 21 de Abril de 2004
Ultima Revisión: ------
Fuente: CERT/CC y diversos reportes de
Equipos de Respuesta a Incidentes,
asà como Foros y Listas de
Discusión.
Sistemas Afectados
==================
* Sistemas que se basan en conexiones TCP persistentes, por
ejemplo ruteadores que soportan BGP.
I. Descripción
==============
En 2001, el CERT Coordination Center liberó el boletin CA-2001-09,
describiendo debilidades estadÃsticas en varios generadores de
Secuencia Inicial TCP. En ese documento
(<http://www.cert.org/advisories/CA-2001-09.html>), Tim Newsham anotó:
Si un número de secuencia dentro de la ventana de recepción es
conocido, un intruo puede inyectar datos dentro del flujo de sesión
o terminar la conexión. Si el valor ISN es conocido y el número de
bytes que ya se han enviado se conoce, un intruso puede enviar o
paquete sencillo para inyectar datos o terminar la sesión. Si estos
valores no se conocen exactamente, pero un intruso puede adivinar un
rango de valores adecuado, puede enviar paquetes con diferentes
números de secuencia dentro del rango hasta que uno sea aceptado. El
intruso no necesita enviar un paquete para cada número de secuencia,
sino que puede enviar paquetes con números de secuencia. Si el rango
apropiado de números de secuencia se cubre, uno de estos paquetes
será aceptado. El número total de paquetes que necesita ser enviado
está dado, entonces, por el rango a cubrir, dividido por la fracción
del tamaño de ventana que se usa como incremento.
Paul Watson ha realizado el análisis estadÃstico de este ataque
cuando el ISN no se conoce y ha notado que un ataque de este tipo
podrÃa ser viable cuando se tome especÃficamente en cuenta el tamaño
de ventana TCP. Además, creó una herramienta proof-of-concept,
demostrando la practicidad del ataque. El Centro de Coordinación de
Seguridad de la Infraestructura Nacional (NISCC, por sus siglas en
inglés) ha publicado un boletÃn resumiendo el análisis de Paul
Watson en "NISCC Vulnerability Advisory 236929," available at
<http://www.uniras.gov.uk/vuls/2004/236929/index.htm>.
Ya que TCP es un protocolo inseguro, es posible inyectar paquetes de
capa de transporte dentro de sesiones entre hosts dadas las
precondiciones adecuadas. La vulnerabilidad en el Número de
Secuencia Inicial TCP/IP (http://www.kb.cert.org/vuls/id/498440) a
la que se hace referencia en CA-2001-09 es un ejemplo de cómo un
intruso podrÃa inyectar paquetes TCP en una sesión. Si un intruso
fuera a enviar un paquete Reset (RST), por ejemplo, terminarÃa la
sesión TCP entre dos extremos sin comunicación posterior.
El protocolo BGP se usa para intercambiar información de ruteo para
Internet y es usado principalmente por Proveedores de Internet
(ISPs). Para información detallada sobre BGP y algunos consejos para
hacerlo seguro, puede verse la documentación de Cisco Systems
(<http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm>)
o Team Cymru (<http://www.cymru.com/>). Una situación vulnerable se
presenta debido al hecho de que BGP se basa en sesiones TCP
persistentes de larga vida con tamaños de ventana mayores. Cuando
una sesión BGP se interrumpe, la aplicación BGP reinicia e intenta
restablecer la conexión con sus puntos. Esto puede resultar en una
pequeña pérdida de servicio hasta que se creen tablas de ruteo frescas.
En una sesión TCP, los extremos pueden negociar un tamaño de ventana
TCP. Cuando esto se toma en cuenta, en lugar de intentar enviar un
paquete engañoso (spoofed) con todos los potenciales números de
secuencia, el intruso sólo necesita calcular un número de secuencia
válido que caiga dentro del próximo ISN esperado más o menos la
mitad del tamaño de ventana. Por lo tanto, mientras más grande sea
el tamaño de ventana TCP, mayor será el rango de números de
secuencia que serán aceptados en el flujo TCP. De acuerdo con el
reporte de Paul Watson, con una conexión de datos xDSL tÃpica (80
kbps, upstream) capaz de enviar 250 paquetes por segundo (pps) para
una sesión con un tamaño de ventana TCP de 65,535 bytes, serÃa
posible inyectar un paquete TCP aproximadamente cada 5 minutos.
TomarÃa aproximadamente 15 segundos con una conexión T-1 (1544
Mbps). Estos números son significativos cuando pueden usarse muchas
máquinas comprometidas (con frecuencia llamdas "botnets" o
"zombies") para generar grandes cantidades de paquetes que pueden
ser dirigidos a un host particular.
Para protegerse contra tales inyecciones, el RFC 2385 proporciona un
método para usar firmas MD5 en los encabezados TCP. Si esta forma de
verificación está soportada y habilitada entre los dos puntos,
entonces un intruso tendrÃa que obtener la llave usada para
transmitir el paquete para poder inyectar exitosamente un paquete en
una sesión TCP. Otra alternativa serÃa hacer tunel BGP sobre IPSec.
De nuevo, esto proporcionarÃa una forma de autenticación entre los
puntos BGP y los datos que transmiten. La falta de autenticación
cuando se usa TCP para BGP hace más viable este tipo de ataque.
II. Impacto
===========
La explotación sostenida de la vulnerabilidad de inyección TCP
respecto a la vulnerabilidad de BGP podrÃa llevar a una condición de
negación de servicio que podrÃa afectar a un gran segmento de la
comunidad de Internet. Las operaciones normales continuarÃan poco
después de que terminara el ataque.
Ya que la vulnerabilidad de Número de Secuencia Inicial de TCP/IP
(VU#498440) ha sido probada, cualquier servicio o sitios que se
basan en sesiones TCP persistentes también podrÃan ser afectados por
esta vulnerabilidad. Los impactos podrÃan ir desde corrupción de
datos o intercepción de sesiones hasta condiciones de negación de
servicio.
III. Solución.
===============
* Actualizar o aplicar el parche correspondiente.
Favor de contactar a su proveedor para consultar sobre parches
disponibles, actualizaciones y estrategias de solución.
La secuencia inicial de números TCP no fueron diseñados para ser a
prueba de ataques a conexiones TCP. La carencia de opciones de
seguridad criptográfica fuerte para la cabecera de TCP en sà mismo
es una deficiencia que tecnologÃas como IPSec intentan atender. Se
debe hacer notar que si un intruso tiene la habilidad de ver el
tráfico no encriptado generado desde un site, ese site es vulnerable
a varios ataques TCP -no sólo a los mencionados aquÃ-. Una medida
más fuerte que ayudarÃa en la protección contra ataques TCP son las
soluciones criptográficas punto a punto como las mencionadas en
documentos IPSec.
La importancia una solución criptográfica punto a punto es que
existen algunas verificaciones de seguridad para comprobar que
ciertos paquetes pertenecen a un flujo en particular. Sin embargo,
la capa de comunicación en al cual la criptografÃa es implementada
determinará su eficacia en rechazar ataques basados en ISN. Las
soluciones que funcionan sobre la capa de transporte (capa 4 del
modelo OSI), tal como SSL/TLS y SSH1/SSH2, evitan que los paquetes
arbitrarios sean introducidos en la sesión. No pueden prevenir el
reinicio de una conexión (negación de servicio) desde la conexión
que será hecha por un nivel inferior del protocolo (por ejemplo,
TCP). Por otro lado, las soluciones criptográficas de capa de red
(capa 3 del modelo OSI) tal como IPSec previenen que ambos tipos de
paquetes se introduzcan en la capa de transporte y reinicio de
conexiones, debido a que el manejo de la conexión esta directamente
integrado en el modelo de seguridad de la capa de red.
Las soluciones presentadas tienen la cualidad de no requerir ningún
cambio al protocolo TCP o a implementaciones que hayan sido hechas.
Algunos sitios pueden desear investigar arduamente la capa de
transporte de TCP en si misma. RFC2385 ("Protection of BGP Sessions
via the TCP MD5 Signature Option") y otras tecnologÃas proporcionan
opciones para agregar protección criptográfica dentro de las
cabeceras de TCP.
* Filtrado de entrada.
El filtrado de entrada dirige el flujo de tráfico tal como entra a
la red bajo su control administrativo. Puede configurar su ruteador
BGP para aceptar solamente paquetes de conexión desde una red
especÃfica. Los servidores tÃpicamente son las máquinas que
solamente necesitan conexiones de entrada desde el Internet. En las
polÃticas de uso de la red de muchos sitios, hay pocas razones para
establecer conexiones desde el exterior a máquinas que no
proporcionan servicios públicos. De este modo, el filtrado de
entrada debe ser establecido para prohibir el inicio de conexiones
externas a servicios no autorizados. Con esta práctica, la eficacia
de las técnicas de escaneo de muchos intrusos pueden ser
dramáticamente reducidas.
* Aislamiento de la red.
Las redes complejas se pueden beneficiar al separar los canales de
datos y los canales de control, tal como BGP, en diferentes redes
lógicas y fÃsicas. Las tecnologÃas, tal como VLANs, VPNs, NAT
podrÃan todas contribuir a separar la transmisión de la información
de control de la correspondiente a la transmisión de datos.
* Filtrado de salida.
El filtrado de salida dirige el flujo de tráfico tal como éste
abandona la red bajo su control administrativo. TÃpicamente existen
limitadas necesidades para ciertas máquinas que proveen servicios
públicos para iniciar conexiones de salida a Internet.
En el caso de BGP, solamente los ruteadores BGP deben estar
estableciendo conexiones a sus terminales. Otro tráfico generado por
el BGP en su red puede ser un signo de un intento de ataque.
Apéndice A. Información del proveedor.
=======================================
Para información del proveedor, favor ver el boletÃn de
vulnerabilidad 236929 "Vulnerability Issues in TCP"
(http://www.uniras.gov.uk/vuls/2004/236929/index.htm) o la nota de
vulnerabilidad VU#415294
(http://www.kb.cert.org/vuls/id/415294#systems). Tal como los
proveedores reporten nueva información se actualizará esta nota. Si
un proveedor en particular no fue mencionado en boletÃn de NISCC,
recomendamos que contacte al proveedor para cualquier comentario.
------------------------------------------------------------------------
El Departamento de Seguridad en Cómputo/UNAM-CERT agradece el apoyo
en la elaboración, revisión y traducción de éste boletÃn a:
* Sergio Alavez Miguel
* Jesús R. Jiménez Rojas
------------------------------------------------------------------------
Informacion
===========
Ã?ste documento se encuentra disponible en su formato original en la
siguiente dirección:
http://www.us-cert.gov/cas/techalerts/TA04-111A.html
La versión en español del documento se encuentra disponible en:
http://www.seguridad.unam.mx <http://www.seguridad.unam.mx/>
http://www.unam-cert.unam.mx/Boletines/Boletines2004/boletin-UNAM-CERT-2004-006.html
Para mayor información acerca de éste boletÃn de seguridad contactar a:
UNAM CERT
Equipo de Respuesta a Incidentes UNAM
Departamento de Seguridad en Computo
DGSCA - UNAM
E-Mail : unam-cert en seguridad unam mx
http://www.unam-cert.unam.mx
http://www.seguridad.unam.mx
ftp://ftp.seguridad.unam.mx
Tel : 56 22 81 69
Fax : 56 22 80 43
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQEVAwUBQIcmZnAvLUtwgRsVAQHyhQgAkCJpbxkM342/9KGuGrd3jv+teDQYxt/L
yLJFvWdVhUcao1XCL5uMZ/Mo0og7g8MA1tL7/lpsy5iDzIhWh1ULUb9vF6zNyJAl
zymACSaPtlXSApku1/1m/BywKewpFKTzIGDw1M7EPwuOtIFApZFuQgycgemnG/MD
r+kIGUhYucvupbmVRPZxFgc+YAHU9tKnwrr3yi36rSnklhtQTyOq25KpD86ImsJa
l/ohku9TbiWlX31+fWS0jLh+7Y9qeWpYVn0/l6XyG+c53lUS08Fnw2wS6c/9feyF
gdhX+6uex/lbzeU5aRIhni0TInH1xCVPrh3hcb64cKEaq+E9c9zvYA==
=zQgL
-----END PGP SIGNATURE-----
Lista de correo linux en opensource org mx
Preguntas linux-owner en opensource org mx
http://www.opensource.org.mx/