Secuestro de BGP al agregar la víctima AS al AS-SET del atacante

El artículo está dividido en tres partes. El primero contiene información general sobre qué es el secuestro de BGP y su versión tradicional. Para aquellos que están familiarizados con este fenómeno, se recomienda ir directamente a la segunda parte. La segunda parte describirá el método de anunciar prefijos externos agregando un AS externo a su AS-SET. En la tercera parte, se evaluará la complejidad del uso del método descrito en la segunda parte para capturar la dirección IP del recurso torproject.org y emitir un certificado para ello. Se supone que el lector está familiarizado con los principios de BGPv4.

Secuestro BGP simple

En pocas palabras, el secuestro de BGP es capturar las direcciones IP de otra persona (aleatoria o intencional).

Por lo general, el secuestro de BGP se ve así: un AS que no posee un prefijo comienza a anunciarlo (el prefijo de otra persona), los enlaces ascendentes / pares lo aceptan y comienza a extenderse por Internet. Lo aceptan por la razón de que no hay filtrado de prefijos en la unión (o bien esto es un error de configuración, o así se concibe (dado que es muy difícil construir un filtro de prefijo en la unión con operadores muy grandes debido a varias razones, esto no es importante para este artículo) ) Uno de los ejemplos más destacados de los últimos tiempos en que Rostelecom ( AS12389 ) comenzó a anunciar los prefijos Mastercard ( AS26380 ), Visa y algunas otras organizaciones financieras (según la versión oficial , como resultado de una falla de software). Puede ver cómo se veían estos anuncios en el historial de bgplay ( visualización a través de la web , json ( archivo )), aquí está uno de ellos en uno de los recopiladores RIPE (el prefijo 216.119.216.0/24 pertenece a Mastercard (AS26380)):

"source_id": "05-193.203.0.185", "path": [ 6939, 12389 ], "community": [], "target_prefix": 216.119.216.0/24 

Y así es como se veía el anuncio real:

  "source_id": "05-193.203.0.63", "path": [ 6720, 8447, 32787, 26380, 26380, 26380 ], "community": [ "1120:1" ], "target_prefix": 216.119.216.0/24 

Es decir en este caso, Rostelecom anunció un prefijo directamente desde su AS (el último AS en AS-PATH es 12389). Se podrían evitar problemas si los enlaces ascendentes y las fiestas de Rostelecom filtraran los prefijos de Rostelecom creando listas de prefijos de acuerdo con AS-SET y / o validando prefijos de acuerdo con ROA RPKI . La construcción de listas de prefijos entre grandes operadores a menudo no se realiza, y no todos han implementado RPKI (pero hay progreso ). Tal secuestro, en teoría, puede ser realizado por cualquier persona, pero solo si el prefijo anunciado "se filtra" a través de al menos un enlace ascendente / fiesta. Por lo general, los grandes operadores rusos configuran filtros de prefijo para sus clientes y, por lo tanto, los AS pequeños (operadores pequeños / medianos, algunos hosting y algunas empresas), casi siempre, no pueden realizar un ataque de este tipo (pero nuevamente, todo depende de la región / país / operador específico).

Sin embargo, los atacantes aún encuentran lugares (enlaces ascendentes) donde el filtrado no está configurado (en 2017, Brasil fue el líder en secuestro ) y llevan a cabo un ataque tomando direcciones IP (a menudo, tales eventos caen en las fuentes de noticias), para un ataque más efectivo, anuncia prefijos más específicos (con una máscara más larga) que un originador real. Ahora pasemos a la versión de ataque, donde ni la validación de ROA RPKI ni las listas de prefijos AS-SET se guardan.

Secuestro de BGP con la adición de víctima AS en su AS-SET

Considere el siguiente escenario:

1. Un atacante obtiene las direcciones AS e IP (de hecho, técnicamente, no necesita direcciones IP, es más probable que no causen preguntas).
2. El atacante se conecta a varios operadores grandes y IX (al menos un operador o IX), especificando no solo su AS, sino su AS-SET como fuente de datos sobre los prefijos anunciados (esta es una práctica normal para la interacción entre operadores (incluyendo incluso cuando está en una relación cliente-enlace ascendente) o para su inclusión en IX-ah)). En el caso normal, se especifica AS-SET, y no solo AS, cuando se supone que el cliente no es un callejón sin salida, sino que en sí tiene (o tendrá) clientes con bgp y sus propias redes.
3. Después de un tiempo, el atacante agrega el AS de la víctima a su AS-SET y comienza a anunciar su prefijo a través de sí mismo, es decir. el AS-PATH anunciado se ve así: "AS_ atacante AS_ víctimas". Desde el punto de vista de listas de prefijos construidas automáticamente y desde el punto de vista de RPKI, este es un anuncio completamente válido, por lo que ambos mecanismos de protección no funcionarán aquí.
4. El prefijo anunciado comienza a competir con el anuncio real (el anuncio de la víctima), en algún lugar que gana y se mete en la tabla de enrutamiento, en algún lugar que pierde y no gana (el anuncio de la víctima permanecerá allí). Depende de cuántos enlaces ascendentes y cuántos IX utiliza un atacante. Cuando un atacante se conecta a algún AS como cliente, entonces dentro de él (con mayor frecuencia) ganará a la víctima debido a un prefijo local más grande (si la víctima no es un cliente del mismo enlace ascendente, entonces la víctima ganará por AS-PATH si no lo hace anteponer), es decir un atacante necesita conectarse a tantos enlaces ascendentes como sea posible con su AS-SET para maximizar la efectividad de su ataque.
   Además, el atacante debe conectarse a la cantidad máxima de IX, como por lo general, los AS de punto muerto establecen el prefijo local más alto a los IX y si el prefijo de la víctima no está involucrado en IX, perderá el anuncio del atacante en las tablas de enrutamiento de los AS de punto muerto.

En teoría, este es un ataque bastante fuerte, pero afortunadamente, en la práctica, surgirán las siguientes limitaciones:

1. Debe elaborar una entidad legal, al menos una, pero de hecho, lo más probable es que se requiera en diferentes países.
2. Es necesario concluir acuerdos con operadores, IXs, casi siempre hacen una tarifa de conexión, con LIR / RIR.
3. Algunos operadores aún no crean listas de prefijos AS-SET automáticamente, necesitan escribir letras para esto. Un administrador experimentado sospechará algo si el AS-ka de una empresa conocida aparece de repente en el AS-SET de una empresa desconocida.
4. Después del ataque, el equipo utilizado (si está ubicado en algún centro de datos) probablemente será confiscado en caso de que se abra un caso penal.
5. Las listas de prefijos para diferentes operadores / IX se actualizan en diferentes momentos, por lo que deberá analizar quién se actualiza cuando este tampoco es el trabajo más fácil.

Posibles medidas de protección:

1. Teóricamente, para defenderse de tal ataque, debe tener tantas interfaces como sea posible con los operadores (mejor, los clientes, porque tienen prefijo local más alto) y IXs. Es decir hacer lo mismo que hará un atacante. Por supuesto, en la práctica esto es extremadamente difícil de implementar y requerirá recursos significativos. Este método es relevante solo para servicios que brindan servicios de seguridad de la información de manera profesional.
2. Si tiene un sitio web, use un registro CAA con la tarea de la cuenta (si su proveedor de certificados SSL lo admite. Letsencrypt lo admite) (consulte RFC6844 ). En este caso, el atacante no podrá emitir un certificado (a menos que pueda cambiar el registro CAA)
3. Teóricamente, la implementación generalizada de BGPsec debería eliminar dicho ataque, pero su destino aún no está claro (en la práctica aún no se aplica o muy raramente).
4. Implementación de verificación alternativa AS_PATH (sin BGPsec) (hasta ahora este es un borrador que resuelve el problema descrito en caso de su implementación generalizada).
5. La prohibición de la adición incontrolada de un AS extranjero a su AS-SET (sin el permiso del propietario del AS) podría reducir la posibilidad de llevar a cabo tales ataques en aquellas regiones donde los AS-SET se utilizan para filtrar juntas. Ahora no existe tal prohibición.

De hecho, para la mayoría de los lectores, el único consejo que se les aplica es el No. 2 (con respecto al uso de la cuenta en un registro CAA) y parcialmente el No. 1 en el contexto de elegir un host con buena conectividad. Al mismo tiempo, debe recordar los posibles ataques contra el servicio DNS en el que aloja sus registros (pero este es un tema aparte y hay muchos materiales en él)

¿Es difícil capturar torproject.org

Un atacante necesita resolver dos problemas:

• Redirigir el tráfico al público objetivo (público objetivo: quién recibirá el sitio falso)
• Generar certificado

Introductorio:

 $ dig torproject.org CAA +short 128 issuewild "\;" 0 iodef "mailto:torproject-admin@torproject.org" 128 issue "globalsign.com" 128 issue "letsencrypt.org" $ dig torproject.org +short 95.216.163.36 138.201.14.197 

Como puede ver, hay un registro CAA, puede obtener un certificado de letsencrypt, no hay enlace a la cuenta en el registro CAA, lo que significa que el atacante resuelve teóricamente el problema. Las direcciones IP de torproject.org son propiedad del conocido hosting Hezner.

Supongamos que el público objetivo de un atacante son los clientes de algún operador ruso. Hezner no es cliente de operadores rusos (pero se ha emparejado con los grandes, directamente o a través de IX-s). La forma más fácil para que un atacante redirija el tráfico de CA a sí mismo es convertirse en un cliente de este operador y simplemente ganar a expensas de un prefijo local más alto. Todo aquí es especialmente relativamente simple y claro.

Para obtener un certificado en letsencrypt, necesita el proveedor en el que se aloja letsencrypt para dirigir el tráfico al atacante, y no a Hezner (AS24940). letsencrypt resuelve diferentes direcciones para IP estadounidense y europea, pero veamos lo difícil que será influir en el tráfico de acme-v02.api.letsencrypt.org/2.19.125.202 ir al host del atacante. Aquí nos enfrentamos al hecho de que letsencrypt está alojado en Akamai CDN, que tiene muy buena conectividad en todo el mundo (presente en la mayoría de los IX principales, tiene uniones directas con una gran cantidad de jugadores importantes). Akamai no tiene un LG público, en principio, hay una API para clientes con la que puede hacer traceroute / ping, pero incluso sin un LG público, puede echar un vistazo a db para evaluar la escala de su presencia. Del mismo modo, puedes mirar a Hezner . Es fácil ver que ambos AS tienen la presencia en los mismos IX, por lo tanto, podemos concluir que con una probabilidad cercana a la unidad, los prefijos AS Hezner (AS24940) en la tabla Akamai (AS20940) son visibles con AS_PATH 24940. Esto significa que si un atacante Si intenta anunciar los prefijos de Hezner a través de IX, perderán según AS_PATH los anuncios reales de Hezner (ya que AS_PATH contendrá el AS del atacante). Una posible solución sería organizar una mirada "directa" entre el atacante y Akamai (si Akamai está de acuerdo con esto y si el prefijo local es más alto que en las uniones con IX).

Para resumir, al agregar el AS de otra persona a su AS-SET, puede causar una degradación significativa del sitio web torproject.org (para una gran cantidad de clientes, pero no para todos en el caso general), pero obtenga el certificado SSL torproject.org en letsencrypt, lo más probable es que no funcione debido a la buena conectividad entre el autor real (Hezner) y el CDN utilizado por letsencrypt (Akamai). Sin embargo, en otros casos, cuando hay AS de tránsito entre el alojamiento del sitio de la víctima y la autoridad de certificación y están presentes en AS_PATH, el riesgo de obtener un certificado utilizando el método descrito aumenta significativamente.