Español | English
rss facebook linkedin Twitter

Vulnerabilidad en BGP, otra vez la misma historia

Últimamente parece que está de moda el comentar que se ha encontrado la mayor Vulnerabilidad de Internet; pasó con la vulnerabilidad de DNS, y ahora está pasando con BGP (podéis leer un breve resúmen sobre BGP y la seguridad o una interesante entrevista a Courtney Love sobre aspectos básicos del mismo).

Antes de nada, tenemos que hacernos una serie de preguntas relacionadas con la Seguridad en BGP:
  1. Si un router recibe un anuncio de un prefijo BGP procedente de un sistema autónomo (AS) determinado, ¿cómo podemos verificar que ese AS está autorizado a anunicar ese prefijo?
  2. Si recibimos un anuncio de un prefijo BGP en un AS determinado, ¿cómo podemos verificar que realmente sabe llegar a ese prefijo?
  3. ¿Está el router que anuncia cierto prefijo autorizado a anunciarlo? Y si es así, ¿a quién?
  4. ¿El camino que se anuncia por parte de un router BGP cumple la políticas (RPSL) de intercambio de rutas que tenemos definidas?
Básicamente estas preguntas reflejan un problema de seguridad en el protocolo BGP conocido hace muchos años, y que durante muchos años también ha estado siendo utilizado, de forma voluntaria o involutaria, por numerosos ISP.

Por gracia o desgracia, la mayoría de los protocolos existentes en Internet se diseñaron en su día para que fueran eficientes, pero nunca se pensó en un ambiente tan hostil como el actual. Debido a ello, posteriormente se sacaron nuevas características para intentar suplir los problemas (tanto de seguridad como de eficiencia, etc.) pero que muchas veces son muy costosos de desplegar. Estas nuevas características muchas veces solucionan problemas de seguridad inherentes al protocolo (recordemos el DNSSEC en el protocolo DNS) pero no sirven generalmente a no ser que todo el mundo lo utilice. En el caso de BGP, existen desde hace tiempo propuestas para intentar solucionar los problemas que estamos comentando de seguridad, principalmente SBGP y su hermano menor SoBGP que hoy en día no se utilizan porque realmente requiere cambiar muchas cosas ($$$):
  • Hay que establecer algo parecido a una PKI para que, utilizando certificados X509v3, se pueda garantizar principalmente la autenticidad de los aspectos relativos al protocolo BGP
  • Muchos routers tendrían que ser cambiados por versiones más potentes porque no son capaces de, no sólo intercambiar rutas, sino de verificar su autenticidad (un ejemplo parecido puede ser HTTP y HTTP con SSL, pensad la carga que sufre un servidor que tenga que soportar SSL respecto a uno que no)
La realidad hoy en día (según el CIDR Report) es que existen 317 números AS fantasmas, y 392 anuncios de ruta fantasmas; estos datos ya indican un poco el descontrol que existe en el protocolo BGP, y la facilidad que existe en publicar anuncios de rutas que no son tuyas. 



El ejemplo más claro ocurrió con YouTube y Pakistan Telekom el 24 de Febrero de 2008 (información completa aquí). Básicamente el Gobierno de Pakistán ordenó a los ISP de ese país bloquear el acceso a YouTube (muchos gobiernos hacen cosas parecidas con otras webs), concretamente 3 direcciones IP. Para poder realizarlo, un ISP tiene principalmente 3 opciones:
  • Poner ACL en sus routers para impedir el acceso a esas direcciones IP (drop/reject)
  • Poner rutas estáticas en todos su routers para redirigir ese tráfico hacia la nada
  • Utilizar BGP para que rápidamente todos sus routers puedan redirigir el tráfico hacia la nada
Si usamos la segunda o tercera opción, y dentro de nuestra política de intercambio de rutas no tengo bien especificado que rutas intercambio o no, lo que puede ocurrir (y ocurrió) es que dentro de la red de Pakistan Telekom todos los routers sabían que el tráfico hacia ciertas direcciones IP (realmente era una red entera /24) lo tenían que redirigir hacia la nada, pero también empezaron a hablar con routers de otros ISPs diciendo que ellos sabían encaminar el tráfico hacia esa red (aunque luego lo llevaran a la nada). Si a eso sumamos que Youtube publicaba sus redes con un rango de direcciones IP más amplio (/22) y que el protocolo BGP siempre elige el rango más pequeño y concreto, en Internet todo el mundo que quería ir a YouTube terminaba en Pakistan Telekom yendo a la nada.

El ejemplo de YouTube demuestra lo fácil que es secuestrar rangos de direcciones por no existir un método fiable de comprobar si realmente Pakistan Telekom estaba autorizado a publicar esas rutas o no. Incluso en Internet hay rangos de direcciones asignados a ciertas empresas o gobiernos, que éstas no anuncian, pero de vez en cuando se ven routers ofreciendo esos rangos (un ejemplo son las direcciones 7.0.0.0/8, 11.0.0.0/8 y 30.0.0.0/8 pertenicientes al Departamento de Defensa de EEUU).

Realmente hasta que no se dé el siguiente paso y se empiecen a utilizar alternativas como SBGP o SoBGP, la única solución es filtrar los anuncios de rangos que se están intercambiando. Este papel lo deben hacer los ISPs con sus clientes, y con los otros ISPs con los que intercambian tráfico, pero que tampoco es nada sencillo, puesto que esas listas son siempre difícil de mantener y actualizar (además que igual los routers actuales no son capaces de soportar la carga extra de comprobar la lista).

Lo que se ha comentado en la charla de Defcon (que se hizo a última hora y nosotros ni nos enteramos que estaba) es una forma más inteligente de poder realizar el secuestro de tráfico sin que exista ningún corte en la comunicación (AS prepending) y de hecho parece que hicieron una demonstración en directo.

Conclusiones:
  • La vulnerabilidad realmente no es nueva, aunque por supuesto, es muy importante
  • Si eres una empresa o usuario final, la única forma de saber que nadie va a fisgar ni modificar tus comunicaciones es con cifrado punto a punto (end to end encryption)
  • Si eres un ISP, filtra correctamente las rutas que exportas/importas y estate atento a servicios que controlan estos temas: PHAS, MyASN, Renesys, IAR, ...
  • Los protocolos que usamos en Internet se diseñaron para ser eficientes, útiles, y sobre todo, fueron diseñados hace 20 ó 30 años. No están pensados para un entorno hostil como el actual.
Más información útil, en la lista NANOG y en el blog de Arbor Networks.

David Barroso
S21sec e-crime

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login