lunes, febrero 25, 2008

Rutas envenenadas (Route Poisoning) a YouTube

Esto va a dar mucho que hablar en la comunidad de ruteo. No es algo nuevo, nada que no supiéramos, o nada que no hubiera pasado antes. Las tablas de BGP (Border Gateway Protocol) son uno de los puntos más vulnerables de la infraestructura de Internet junto con los servidores de nombres (DNS). Mientras para los servidores de nombres ya se han puesto algunas medidas de seguridad para evitar los ataques de negación de servicio, para las tablas de BGP aún no hay nada definido. Los grupos de seguridad de enrutamiento del IETF han definido varios RFCs donde se enlistan precisamente los problemas que pueden existir por la falta de seguridad en los protocolos de ruteo y los requerimientos que un protocolo de ruteo seguro debe tener. Lo nuevo en este caso es el perfil del atacado (YouTube de Google) y la razón por lo que pasó (censura)

El problema de la inseguridad de BGP es real y ahora tenemos un caso que va a resonar en los medios (seguramente). Hace unos días Pakistan anunció que bloquearía el acceso a Youtube por considerarlo un sitio con contenido inapropiado (dejaremos por un momento nuestra ideología en contra de la censura por un lado). Un ISP pakistaní (PCCW que realmente está en Hong Kong y según ellos son los más grandes de la región) tuvo la grandiosa idea de bloquear los sitios por Youtube usando infraestructura de ruteo, lo cual es un práctica común cuando apuntamos rutas estáticas a null y anunciamos INTERNAMENTE la ruta de “hoyo negro” a NUESTROS enrutadores. El problema es cuando esto se hace mal y anunciamos EXTERNAMENTE la ruta y esta tiene mejor métrica que la ruta del propietario (en esta caso Google).

El resultado es que PCCW terminó haciendo haraquiri a sus enlaces al recibir todo (o una buena parte de) el tráfico de Youtube. Esto fue un doble ataque de negación de servicio (uno a Youtube por el error de los ingenieros de ruteo de PCCW) y otra al mismo PCCW al saturar sus enlaces con el tráfico de YouTube. Afortunadamente los cuerpos de rescate filtraron las rutas y después de varias horas (aproximadamente 4) YouTube comenzó a volver a la normalidad.
A pesar del final feliz (bueno, esto aun no acaba. No sé si vaya a haber algunas demandas de Google a PCCW por daños), esto nos deja una buena lección de que la infraestructura de ruteo es muy frágil. Aunque BGP es un protocolo muy estable no fue diseñado con la seguridad en mente (sino con estabilidad) y es fácilmente engañado con anuncios falsos. Ahora que hay un precedente, uno de los blancos favoritos de los hackers va a ser posiblemente los enrutadores de ISPs donde la seguridad es baja. En estos casos un enrutador secuestrado podría empezar a inyectar las rutas de la víctima con mejores métricas ocasionando una doble negación de servicio (a la víctima y al ISP al saturar los enlaces –ésto depende del perfil de la víctima-).

Más información: BBC y Znet

Update: Encontré algo más de información en la lista de correo de NANOG donde incluso pueden ver los bloques de IP que fueron erróneamente anunciados.

2 comentarios:

Alejandro Martínez Varela dijo...

Ciertamente la seguridad en routers es un tema mucho mas oscuro que en las PC o Sistemas Operativos. Inclusive podemos decir que hay una cultura de atención a las Vulnerabilidades de SO, mientras que a nivel de routers estamos todavia en la etapa de negación, tanto en el lado del fabricante como en los operadores y administradores. Lo peor del caso es que esta última manifestacion de inseguridad, cae en el nivel de parbulitos, pues es un error humano, un cambio que se realizó sin verificar impacto y obviamente (por las 4 horas) sin un rollback planteado.

Arturo Servin dijo...

Totalmente de acuerdo. En este caso fue error humano y el asunto se resolvio cuando los NOCs hablaron y el la ruta se corrigio.
Un problema que posiblemente veremos es que los routers van a ser targets de hackers para anunciar rutas falsas y ocasionar DoS attacks. La unica defensa a este ataque es que el DoS puede durar poco (en lo que el ISP recupera el control del router) y que una vez comprometido y usado un router es posible que sea parchado y el hacker ya no lo pueda utilizar. Este uso "one time" creo que es poco "rentable" para los hackers y por ello estos ataques no van a proliferar mucho pero de que existiran, existiran (al menos por metidas de pata como en este caso).