Ataques a BGP.
Estas violaciones pueden derivarse de los siguientes ataques contra el protocolo BGP.
BGP funciona sobre la base del protocolo TCP, escuchando en el puerto 179. Por lo tanto, el protocolo BGP es vulnerable a los ataques TCP de los que hablamos anteriormente.
Violación de la privacidad (confidentiality violations). Como se mencionó anteriormente, los datos de enrutamiento BGP se transmiten en texto plano, lo que facilita la interceptación de la información (esto se debe a que la privacidad de los datos de enrutamiento no es un requisito común).
Ataque replay (reproducción). BGP no incluye medidas para evitar la reutilización de mensajes interceptados.
Ataque de inserción de mensajes. BGP no incluye protección contra inserción de mensajes. Sin embargo, dado que BGP utiliza el protocolo de transporte TCP, cuando se completa la conexión, insertar mensajes por un nodo externo requerirá una Predicción precisa de los números de secuencia (tal Predicción es posible, pero es bastante difícil para buenas implementaciones de TCP) o interceptar sesiones.
Ataque message deletion (eliminación de mensajes). BGP no incluye protección contra la eliminación de mensajes. Una vez más, tales ataques son muy difíciles para implementaciones de TCP de alta calidad, pero no pueden eliminarse por completo.
Ataque message modification (modificación de mensajes). BGP no incluye protección contra cambios de mensajes. La modificación sintácticamente correcta sin cambiar el Tamaño de los datos TCP en general será imperceptible.
Ataque Man-in-the-middle (ataque Man-in-the-middle). BGP no incluye protección contra ataques MITM. BGP no utiliza la autenticación de socios, y tales ataques se convierten en un "juguete para niños".
Ataque de denegación de Servicio (denial of service attacks). Si bien los datos de ruta falsos en sí mismos pueden servir como un ataque dos contra el sistema final que intenta transmitir datos a través de la red y la red en su conjunto, algunos tipos de información falsa pueden crear ataques dos contra el protocolo BGP en sí. Por ejemplo, anunciar un gran número de rutas más específicas (prefijos más largos) puede hacer que el tráfico de BGP y el Tamaño de las tablas de enrutamiento aumenten, lo que resulta inaceptable para el sistema.
Para resumir lo que se describe en esta sección, hay que señalar que la presencia de riesgos se debe a tres vulnerabilidades principales:
falta de un mecanismo integrado para proteger la integridad y la actualidad de los datos, la autenticación de socios para la transmisión de mensajes;
falta de un mecanismo de verificación de credenciales AS para la información anunciada NLRI (Network Layer Reachability Information);
falta de un mecanismo para garantizar la validez de los atributos de las rutas anunciadas por AS.
Simple BGP hijacking.
Por lo general, BGP hijacking se ve así: AS, que no posee algún prefijo, comienza a anunciarlo (el prefijo de otra persona), los aplanadores/fiestas lo aceptan y comienza a propagarse por Internet. Lo aceptan por la razón de que no hay filtrado de prefijos en la Unión (o es un error de configuración, o es así (porque construir un filtro de prefijo en la Unión con operadores muy grandes es muy difícil debido a varias razones, para este artículo no es importante)). Uno de los ejemplos más ruidosos de los últimos tiempos es cuando rostelecom (AS12389) comenzó a anunciar los prefijos de Mastercard (AS26380), Visa y algunas otras organizaciones financieras (según la versión oficial, como resultado de un fallo del SOFTWARE). Cómo se veían estos anuncios, se puede ver en la historia de bgplay( vista a través de web, json (archivo)), aquí hay uno de ellos en uno de los colectores de 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
Así es como se veía el anuncio:
"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ó el prefijo directamente de su AS (el último AS en AS-PATH es 12389). Los problemas podrían haberse evitado si los aplinks y las fiestas de rostelecom filtraran los prefijos de rostelecom construyendo las listas de prefijos de AS-SET y / o validando los prefijos de ROA RPKI. La construcción de listas de prefijos entre operadores grandes a menudo no se realiza, y RPKI tampoco ha implementado todo (pero hay progreso). Tal hijacking teóricamente puede ser cometido por cualquiera, pero solo si el prefijo anunciado se "filtra" a través de al menos un enlace ascendente/PIR. Por lo general, los grandes operadores de Rusia configuran los prefijadores en la dirección de sus clientes, y por lo tanto, los pequeños AS (operadores pequeños/medianos, algunos hostings y algunas empresas) casi siempre no pueden realizar tal ataque (pero nuevamente, todo depende de la región / país / operador específico).
Sin embargo, los atacantes aún encuentran lugares (aplinkov) donde el filtrado no está configurado (en 2017, Brasil fue el líder en hijacking) y realizan un ataque/captura de direcciones IP (a menudo tales eventos caen en las noticias
las cintas), para una mayor eficiencia de ataque pueden anunciar prefijos más específicos (con una máscara más larga) que el original real. Ahora pasemos a la variante de ataque, donde ni la validación de ROA RPKI ni las hojas de prefijo construidas de acuerdo con AS-SET se salvan.
BGP hijacking con la adición de la víctima AS a su AS-SET.
Considere el siguiente escenario.
El atacante obtiene direcciones AS e IP (de hecho, técnicamente no necesita direcciones IP, sino que son solo para no causar preguntas).
El atacante se conecta a varios operadores grandes y IX'AM (mínimo, al menos a un operador o IX), señalando como fuente de datos sobre los prefijos anunciados no solo su AS, sino su AS-SET (esta es una práctica normal para la interacción entre operadores (incluso en la relación cliente-enlace ascendente) o para incluirlo en IX'ah)). En el caso normal, se especifica AS-SET en lugar de simplemente AS, cuando se implica que el cliente no es un punto muerto, sino que él mismo tiene (o tendrá) clientes con bgp y sus redes.
Después de un tiempo, el atacante agrega as a 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_s_s_s_s_s_s". Desde el punto de vista de las listas de prefijos construidas automáticamente y desde el punto de vista de RPKI, este es un anuncio perfectamente válido, por lo que ambos mecanismos de protección no funcionarán aquí.
El prefijo proanonado comienza a competir con el anuncio real (anuncio de la víctima), en algún lugar gana y cae en la tabla de enrutamiento, en algún lugar pierde y no cae (el anuncio de la víctima permanecerá allí). Depende de la cantidad de enlaces de apoyo y la cantidad de IX's que utiliza el atacante. Cuando un atacante se conecta a un as como cliente, dentro de él (la mayoría de las veces) ganará a la víctima a expensas de un local-pref más grande (a menos que la víctima sea un cliente del mismo aplink, entonces la víctima ganará por AS-PATH si no hace prepends), es decir, el atacante necesita conectarse al mayor número posible de enlaces de apoyo con su AS-SET para maximizar la efectividad de su ataque.
Además, el atacante debe conectarse al número máximo de IX's, ya que generalmente los as sin salida ponen el mayor local-pref en IX's y si el prefijo de la víctima no participa en IX, perderá el anuncio del atacante en las tablas de enrutamiento de as sin salida.
En teoría, este es un ataque bastante fuerte, pero afortunadamente, en la práctica, surgirán las siguientes limitaciones.
Es necesario emitir una entidad legal, al menos una, y de hecho, lo más probable es que se requiera en diferentes países.
Es necesario concluir contratos con operadores, IX's, casi siempre hacer un pago por conexión, con LIR/RIR.
Algunos operadores aún no construyen listas de prefijos en AS-SET automáticamente, necesitan escribir cartas para hacerlo. Un administrador experimentado sospechará algo si una compañía desconocida aparece repentinamente EN AS-SET.
Después del ataque, es probable que el equipo utilizado (si se coloca en algún centro de datos) se retire en caso de que se abra un caso penal.
Las listas de prefijos de diferentes operadores / IX se actualizan en diferentes momentos, por lo que será necesario analizar quién actualiza cuándo, este tampoco es el trabajo más fácil.
Posibles medidas de protección.
En teoría, para protegerse de un ataque de este tipo, es necesario tener tantas conexiones con los operadores (mejor cliente, porque en ellos local-pref arriba) y IX'ami. Es decir, hacer lo mismo que haría un atacante. Por supuesto, en la práctica, esto es extremadamente difícil de implementar y requerirá recursos considerables. Este método es relevante solo para los servicios que se dedican a proporcionar servicios de seguridad de la información sobre una base profesional.
Si tiene un sitio web, use un registro CAA con el trabajo account (si su proveedor de certificados SSL lo Admite; letsencrypt lo Admite) (consulte RFC6844). En este caso, el atacante no podrá emitir el certificado (a menos que pueda modificar el registro CAA).
En teoría, 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 se usa muy raramente).
Implementación de la verificación AS_PATH alternativa (sin BGPsec) (hasta ahora es un Draft que resuelve el problema descrito en caso de su implementación generalizada).
Prohibir la adición incontrolada de AS de otra persona a su AS-SET (sin el permiso del propietario de AS) podría reducir la posibilidad de realizar tales ataques en aquellas regiones donde se usan as-SET's para filtrar en las uniones. Ahora no hay tal prohibición.
De hecho, para la mayoría de los lectores, el único Consejo aplicable para ellos es el n. ° 2 (con respecto al uso de account en la escritura CAA) y parcialmente el n. ° 1 en el contexto de elegir un hoster con buena conectividad. Al mismo tiempo, debe tener en cuenta los posibles ataques al Servicio DNS en el que aloja sus registros (pero esta es una pregunta separada, y hay muchos materiales sobre ella).
Es difícil de capturar torproject.org.
El atacante tiene que resolver dos problemas:
redirigir el tráfico hacia el público objetivo (CA-quién recibirá un sitio falso);
generar certificado.
Introductorios:
$ 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 de CAA, puede obtener un certificado de letsencrypt, no hay un enlace a la cuenta en el registro de CAA, lo que significa que el problema es teóricamente solucionable por un atacante. Direcciones IP de dominio torproject.org pertenece al conocido Hosting Hezner.
Digamos que el atacante es el cliente de algún operador ruso. Hezner no es un cliente de los operadores rusos (pero tiene peer – to-peer con grandes-directamente o a través de IX's). Para que un atacante redirija el tráfico de CA a sí mismo, es más fácil convertirse en un cliente de este operador y simplemente ganar a expensas de un local-pref más alto. Aquí, especialmente, todo es relativamente simple y claro.
Para obtener un certificado en letsencrypt, es necesario que el proveedor en el que se aloja letsencrypt dirija el tráfico al atacante, no a Hezner (AS24940). letsencrypt hablará en diferentes direcciones para IP estadounidenses y europeas, pero veamos qué tan difícil será afectar el tráfico con acme-v02.api.letsencrypt.org/2.19.125.202 se fue al anfitrión del intruso. Aquí nos encontramos con el hecho de que letsencrypt está alojado en CDN Akamai, que tiene una muy buena conectividad en todo el mundo (presente en la mayoría de los principales IX, tiene conexiones directas con un gran número de grandes jugadores). Akamai no tiene un LG público, en principio, hay una API para que los clientes puedan hacer traceroute / ping, pero sin un LG público, es posible echar un vistazo a peering db para evaluar el alcance de su presencia. Del mismo modo, se puede ver hezner. No es difícil ver que ambos AS tienen presencia en los mismos IX, de aquí se puede inferir que con una probabilidad cercana a uno, los prefijos As hezner (AS24940) en la tabla Akamai (AS20940) son visibles con AS_PATH 24940. Esto significa que si un atacante intenta anunciar a través de algunos prefijos IX de Hezner'a, perderán en AS_PATH los anuncios reales de Hezner (porque en AS_PATH habrá as del atacante). Una posible solución podría ser la organización de un peering" directo " entre el atacante y Akamai (si Akamai está de acuerdo con esto y si el local-pref es más alto que en las uniones con IX's).
Para resumir, agregar el AS de otra persona a su AS-SET puede causar una degradación significativa del sitio web torproject.org (para un gran número de clientes, pero no para todos en general), pero para comprar un certificado SSL torproject.org en letsencrypt, es probable que falle debido a la buena conectividad entre el original 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 víctima y la autoridad de certificación y están presentes en AS_PATH, el riesgo de obtener el certificado por el método descrito aumenta significativamente.
Oleg Petukhov, abogado en el campo del derecho internacional y la protección de datos personales, especialista en información seguridad, protección de la información y datos personales.
Canal de Telegram: https://t.me/protecciondelainformacion1
Grupo de Telegramas: https://t.me/protecciondelainformacion2
Sitio web: https://legascom.ru
Correo electrónico: online@legascom.ru
#proteccióndelainformación #seguridaddelainformación
