Fugas de BGP y criptomonedas

En las últimas horas, han aparecido una docena de noticias sobre cómo un atacante ha intentado (y tal vez ha logrado) robar criptomonedas con una fuga del protocolo de puerta de enlace de frontera (Border Gateway Protocol o BGP por sus siglas en inglés).

¿Qué es el BGP?

Internet se compone de rutas. Para el resolutor DNS 1.1.1.1, le decimos al mundo que todas las IP en los rangos de 1.1.1.0 a 1.1.1.255 se pueden acceder en cualquier punto de presencia de Cloudflare.

Las personas que no tienen un enlace directo a nuestros enrutadores reciben la ruta a través de los proveedores de tránsito, que entregarán paquetes a esas direcciones conectadas a Cloudflare y al resto de Internet.

Así es el funcionamiento normal de Internet.

Hay autoridades (Registros Regionales de Internet) encargadas de la distribución de direcciones IP para evitar que haya personas que usen el mismo espacio de direcciones. Estas autoridades son IANA, RIPE, ARIN, LACNIC, APNIC y AFRINIC.

¿Qué es una fuga de BGP?

La definición amplia de fuga de BGP sería un espacio IP anunciado por alguien sin permiso del dueño del espacio. Cuando un proveedor de tránsito recoge el anuncio de Cloudflare de 1.1.1.0/24 y lo anuncia a Internet, le permitimos que lo haga. También comprueba, utilizando la información del Registro Regional de Internet, que solo Cloudflare puede anunciarlo.

Sin embargo, puede ser difícil verificar todos los anuncios. Especialmente cuando hay más de 700 000 rutas en Internet y cadenas de proveedores que intercambian tráfico entre rutas.

Por su naturaleza, las fugas de ruta están localizadas. Cuanto más localmente conectado estás, menor es el riesgo de aceptar una ruta fugada.

Para que se acepte en lugar de una ruta legítima, la ruta debe tener:

• Un prefijo más pequeño (10.0.0.1/32 = 1 IP vs. 10.0.0.0/24 = 256 IP)
• Mejores métricas que un prefijo con la misma longitud (ruta de acceso más corta)

La causa de una fuga de BGP suele ser un error de configuración: un enrutador que anuncia repentinamente las IP que ha aprendido. O prefijos más pequeños utilizados internamente para la ingeniería de tráfico que de repente se vuelven públicos.

Pero a veces se hace con intención maliciosa. El prefijo puede ser nuevamente enrutado para analizar pasivamente los datos. O alguien puede también configurar un servicio para responder ilegítimamente en su lugar. Esto ha sucedido ya.

¿Qué ha pasado hoy?

Cloudflare mantiene un rango de colectores de BGP que reúnen información de BGP de cientos de enrutadores alrededor del planeta.

Aproximadamente entre las 11:05:00 y las 12:55:00 (UTC) de hoy vimos los siguientes anuncios:

BGP4MP|04/24/18 11:05:42|A|205.251.199.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.197.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.195.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.193.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.192.0/24|10297
...
BGP4MP|04/24/18 11:05:54|A|205.251.197.0/24|4826,6939,10297

Esos son más anuncios específicos de los rangos:

• 205.251.192.0/23
• 205.251.194.0/23
• 205.251.196.0/23
• 205.251.198.0/23

Este espacio IP está asignado a Amazon (AS16509). Pero el número de sistema autónomo que lo anunció era eNet Inc (AS10297) a sus homólogos y lo envió a Hurricane Electric (AS6939).

Esas IP son paralos servidores de DNS de la Ruta 53 de Amazon. Cuando haces una consulta a una de sus zonas de cliente, esos servidores contestarán.

Durante la fuga de dos horas, los servidores en ese rango de IP solo respondieron a las consultas a myetherwallet.com. Mientras que algunas personas notaron SERVFAIL.

Cualquier resolutor de DNS al que se le pidieran nombres gestionados por la Ruta 53 preguntaría a los servidores autoritativos que habían sido tomados mediante la fuga de BGP. Esto dañó los resolutores de DNS cuyos enrutadores habían aceptado la ruta.

También al resolutor de DNS Cloudflare 1.1.1.1. Nos afectó en Chicago, Sídney, Melbourne, Perth, Brisbane, Cebú, Bangkok, Auckland, Muscat, Yibuti y Manila. En el resto del mundo, 1.1.1.1 funcionaba normalmente.

Por ejemplo, la siguiente consulta te devolverá IP legítimas de Amazon:

$ dig +short myetherwallet.com @205.251.195.239
54.192.146.xx

Pero durante el secuestro, devolvía IP asociados con un proveedor ruso(AS48693 y AS41995). No tenías que aceptar la ruta secuestrada para ser víctima del ataque, solo usar un resolutor DNS que estuviera dañado.

Si estabas usando HTTPS, el sitio web falso habría mostrado un certificado TLS firmado por una autoridad desconocida (el dominio que aparecía en el certificado era correcto pero estaba autofirmado). La única forma de que este ataque funcionara sería continuar y aceptar el certificado incorrecto. Desde ese momento, todo lo que enviaras estaría cifrado pero el atacante tendría las claves.

Si ya habías iniciado sesión, tu navegador enviaría los datos de inicio de sesión en la cookie. Si no, tu nombre de usuario y contraseña se enviarían si los teclearas en una página de inicio de sesión.

Una vez el que atacante tenía los datos de inicio de sesión, los utilizaban en el sitio web legítimo para transferir y robar Ethereum.

Resumen en imágenes

Caso normal

Después de una fuga de ruta de BGP

Regiones afectadas

Como se mencionó anteriormente, AS10279 anunció esa ruta. Pero solo afectó a algunas regiones. Hurricane Electric tiene una fuerte presencia en Australia, sobre todo debido a los costes de Internet. Chicago se vio afectada porque AS10279 tiene presencia física por emparejamiento directo.

El siguiente gráfico muestra el número de paquetes recibidos en las regiones afectadas y no afectadas (eje Y normalizado). La caída se debe a que el servidor autoritativo ya no respondía a nuestras peticiones (solo respondía a un sitio web y todos los demás dominios de Amazon eran ignorados).

Otros tránsitos utilizados por eNet (CenturyLink, Cogent y NTT) no parecían haber aceptado esta ruta: una razón podría ser que tuvieran filtros o Amazon como cliente.

eNet proporciona servicios IP, así que uno de sus clientes podría haberlo anunciado.

¿Alguien tiene la culpa?

Como hay muchos actores implicados, es difícil determinar la culpa. Actores implicados:

• El proveedor de servicios de Internet que anunció una subred que no poseía.
• Los proveedores de tránsito que no revisaron el anuncio antes de retransmitirlo.
• Los proveedores de servicios de Internet que aceptaron la ruta.
• La falta de protección de los resolutores DNS y la autoridad.
• El sitio web de phishing alojado en proveedores de Rusia.
• El sitio web que aplicó certificados TLS legítimos.
• El usuario que hizo clic en continuar a pesar de que el certificado TLS no era válido.

Al igual que una cadena de bloques, un cambio de red suele ser visible y se archiva. RIPE mantiene una base de datos para este uso.

¿Podríamos arreglarlo?

Es una pregunta difícil de responder. Hay propuestas para asegurar el BGP:

Pueden añadirse algunos términos a las bases de datos de los Registros Regionales de Internet, por lo que se puede generar una lista de fuentes permitidas:

$ whois -h whois.radb.net ' -M 205.251.192.0/21' | egrep '^route:|^origin:|source:' | paste - - - | sort
route:      205.251.192.0/23	origin:     AS16509	source:     RADB
route:      205.251.192.0/23	origin:     AS16509	source:     REACH

Pueden crearse registros RPKI/ROA con el Registro Regional de Internet como fuente fiable con respecto a la ruta de acceso a una ruta, aunque no todo el mundo cree esos registros o los valide. IP y BGP se crearon hace unas décadas, teniendo en cuenta diversos requisitos en cuanto a la integridad y autenticidad (menos rutas).

Pueden hacerse algunas cosas en los niveles superiores de la pila de red.

En DNS, puedes utilizar DNSSEC al firmar tus registros. Las IP devueltas por DNS falsos no se habrían firmado ya que no tienen las claves privadas.

Si utilizas Cloudflare como DNS, puedes habilitar DNSSEC con unos clics en el panel.

En HTTPS, tu navegador comprobará el certificado TLS proporcionado por el sitio web. Si se habilita HSTS, el navegador requerirá un certificado válido todo el tiempo. La única manera de generar un certificado legítimo de TLS para un dominio sería dañar la caché de un resolutor DNS sin DNSSEC de la autoridad de certificación.

DANE proporciona una manera de asignar certificados a un nombre de dominio utilizando DNS.

DNS mediante HTTPS también permitiría validar que estás hablando con el resolutor correcto si la fuga se produjera en los resolutores DNS en lugar de en la autoridad DNS.

No existe ninguna solución perfecta y única. Cuantas más protecciones se habiliten, más difícil será que un actor malicioso realice este tipo de ataque.

Etiquetado con BGP, Criptografía, TLS, HTTPS, Seguridad, Vulnerabilidades