Ataques ao BGP.
Essas violações podem ser derivadas dos seguintes ataques ao protocolo BGP.
O BGP opera com base no protocolo TCP, escutando a porta 179. Consequentemente, o protocolo BGP é vulnerável aos ataques TCP que mencionamos anteriormente.
Violação de confidencialidade (confidentiality violations). Como mencionado anteriormente, os dados de roteamento do BGP são transmitidos em texto aberto, o que facilita a interceptação de Informações (isso ocorre porque a confidencialidade dos dados de roteamento não é um requisito geral).
Ataque de repetição (Replay). O BGP não inclui medidas para evitar a reutilização de mensagens interceptadas.
Ataque de inserção de mensagens (message insertion). O BGP não inclui proteção contra inserção de mensagens. No entanto, como o BGP usa o protocolo de transporte TCP, quando a conexão está concluída, a inserção de mensagens por um host externo exigirá uma previsão precisa dos números de série (essa previsão é possível, mas muito difícil para boas implementações de TCP) ou a interceptação de sessões.
Ataque de exclusão de mensagens (message deletion). O BGP não inclui proteção contra exclusão de mensagens. Novamente, esses ataques são muito difíceis para implementações TCP de qualidade, mas não podem ser completamente excluídos.
Ataque de modificação de mensagens (message modification). O BGP não inclui proteção contra alteração de mensagens. Uma modificação sintaticamente correta sem alterar o tamanho dos dados do TCP geralmente não será notada.
Ataque Man-in-the-middle (ataque humano) O BGP não inclui proteção contra ataques MITM. O BGP não usa a autenticação de parceiros e esses ataques se tornam um "brinquedo de criança".
Ataque de negação de serviço (denial of service). Embora os dados de roteamento falsos por si só possam servir como um ataque DoS ao sistema final tentando transmitir dados através da rede e da rede como um todo, alguns tipos de informações falsas podem criar ataques DoS ao próprio protocolo BGP. Por exemplo, anunciar um grande número de rotas mais específicas (prefixos mais longos) pode levar a um aumento no tráfego BGP e no tamanho das tabelas de roteamento, o que seria inaceitável para o sistema.
Para resumir o que foi descrito nesta seção, os riscos são causados por três vulnerabilidades principais:
falta de um mecanismo embutido para proteger a integridade e a relevância dos dados, autenticação de parceiros para transmissão de mensagens;
falta de um mecanismo de verificação de autoridade AS para as informações anunciadas NLRI (Network Layer Reachability Information);
falta de um mecanismo para garantir a validade dos atributos das rotas anunciadas pelo AS.
BGP hijacking simples.
Normalmente, o BGP hijacking é assim: AS, que não possui um prefixo, começa a anunciá-lo (o prefixo de outra pessoa), uplinks/pares o aceitam e ele começa a se espalhar pela internet. Eles o aceitam porque não há filtragem de prefixos na junção (ou é um erro de configuração ou é intencional (porque construir um filtro de prefixo na junção com operadores muito grandes é muito difícil devido a várias razões, não é importante para este artigo)). Um dos exemplos mais proeminentes dos últimos tempos é quando a Rostelecom (As12389) começou a anunciar os prefixos Mastercard (As26380), Visa e algumas outras organizações financeiras (de acordo com a versão oficial, como resultado de uma falha de software). Como esses anúncios pareciam, você pode ver na história do bgplay (ver através de web, json (arquivo)), Aqui está um deles em um dos coletores RIPE (prefixo 216.119.216.0/24 propriedade da Mastercard (As26380)):
"source_id": "05-193.203.0.185",
"path": [
6939,
12389
],
"community": [],
"target_prefix": 216.119.216.0/24
Assim foi o verdadeiro anúncio:
"source_id": "05-193.203.0.63",
"path": [
6720,
8447,
32787,
26380,
26380,
26380
],
"community": [
"1120:1"
],
"target_prefix": 216.119.216.0/24
Ou seja, neste caso, a Rostelecom anunciou o prefixo diretamente de seu AS (o último AS em AS-PATH é 12389). O problema poderia ser evitado se uplinks e pares da Rostelecom filtrassem prefixos da Rostelecom construindo as-SET prefixos e / ou validando prefixos de Roa RPKI. A construção de folhas de prefixo entre grandes operadores muitas vezes não é feita, e RPKI também não introduziu tudo (mas há progresso). Tal hijacking teoricamente pode ser feito por qualquer pessoa, mas somente se o prefixo anunciado "vazar" através de pelo menos um uplink/PIR. Normalmente, as grandes operadoras Russas configuram os prefixfiltros para seus clientes e, portanto, as pequenas (pequenas/médias operadoras, algumas empresas de hospedagem e algumas empresas) quase sempre não podem fazer esse ataque (mas, novamente, tudo depende da região / país / operadora específica).
No entanto, os atacantes ainda encontram locais (uplinkov) onde a filtragem não está configurada (em 2017, o Brasil foi o líder em hijacking) e realizam um ataque / captura de endereços IP (muitas vezes esses eventos aparecem nas notícias
para maior eficácia, os ataques podem anunciar prefixos mais específicos (com uma máscara mais longa) do que o verdadeiro originador. Agora vamos para a variante de ataque, onde nem a validação ROA RPKI nem as folhas de prefixo construídas no AS-SET são salvas.
BGP hijacking com a adição de as vítimas ao seu AS-SET.
Considere o seguinte cenário.
O invasor obtém AS e endereços IP (na verdade, tecnicamente, ele não precisa de endereços IP, mas apenas para evitar perguntas).
O invasor se conecta a vários grandes operadores e IX (no mínimo, pelo menos um operador ou IX), indicando não apenas seu AS como fonte de dados de prefixos anunciados, mas seu AS-SET (Esta é uma prática normal para interação entre operadores (incluindo na relação cliente-uplink) ou para inclusão em IX)). Normalmente, o AS-SET é indicado, não apenas o AS, quando se assume que o cliente não é um beco sem saída, mas que ele próprio tem (ou terá) clientes com bgp e suas redes.
O invasor depois de algum tempo, adiciona AS vítimas em seu AS-SET e começa a anunciar o seu prefixo através de si mesmo, т. е. анонсируемый AS-PATH é: "АЅ_злоумышленника АЅ_жертвы". Do ponto de vista das folhas de prefixo construídas automaticamente e do ponto de vista do RPKI, este é um anúncio completamente válido, então ambos os mecanismos de defesa não funcionarão aqui.
O prefixo anunciado começa a competir com o anúncio real (anúncio da vítima), em algum lugar ele ganha e entra na tabela de roteamento, em algum lugar ele perde e não entra (o anúncio da vítima permanecerá lá). Isso depende de quantos uplinks e quantos IXS o atacante usa. Quando um invasor se conecta a um AS como cliente, dentro dele ele (na maioria das vezes) vencerá a vítima à custa de um local-pref maior (a menos que a vítima seja um cliente do mesmo uplink, então a vítima ganhará o as-PATH se não fizer uma disputa). um invasor precisa se conectar ao maior número possível de uplinks de seu AS-set para maximizar a eficácia de seu ataque.
Além disso, o atacante deve se conectar ao número máximo de IX, já que normalmente os becos sem saída as colocam o maior preff local em IX, e se o prefixo da vítima não estiver envolvido no IX, ele perderá o anúncio do atacante nas tabelas de roteamento do becos sem saída AS.
Em teoria, este é um ataque bastante forte, mas, felizmente, na prática, haverá as seguintes limitações.
É necessário registrar uma pessoa jurídica, pelo menos uma, e de fato, provavelmente será necessária em diferentes países.
É necessário fazer contratos com os operadores, IX'ами, quase sempre fazer um pagamento para a conexão, com LIR / RIR.
Alguns operadores ainda não constroem as-SET automaticamente as folhas de prefixo, eles precisam escrever cartas para isso. Um administrador experiente suspeitará de alguma coisa se uma empresa desconhecida aparecer de repente no AS-SET.
Após o ataque, o equipamento usado (se for colocado em algum centro de dados) provavelmente será apreendido em caso de abertura de um processo criminal.
As folhas de prefixo de diferentes operadores / IX são atualizadas em momentos diferentes, portanto, é necessário analisar quem atualiza quando, também não é o trabalho mais fácil.
Possíveis medidas de proteção.
Teoricamente, para se proteger contra esse ataque, você precisa ter o maior número possível de conexões com os operadores (melhor do que os clientes, porque eles têm local-pref acima) e IX. Ou seja, fazer a mesma coisa que um intruso faria. É claro que, na prática, isso é extremamente difícil de implementar e exigirá recursos significativos. Este método é relevante apenas para serviços que estão envolvidos na prestação de serviços de segurança da informação em uma base profissional.
Se você tem um site-use o registro CAA com a tarefa account (se o seu provedor de certificado SSL suporta isso; letsencrypt suporta) (consulte RFC6844). Nesse caso, o invasor não poderá emitir um certificado (a menos que possa alterar o registro CAA).
Teoricamente, a adoção generalizada do BGPsec deve eliminar tal ataque, mas seu destino ainda não é claro (na prática, ainda não é aplicado ou é usado muito raramente).
Implementação de verificação alternativa AS_PATH (sem BGPsec) (até agora, este é um draft que resolve o problema descrito no caso de sua adoção generalizada).
Proibir a adição descontrolada de as de outras pessoas ao seu AS-SET (sem a permissão do proprietário do AS) poderia reduzir a possibilidade de ataques semelhantes em regiões onde as-sets são usados para filtrar junções. Agora não existe tal proibição.
De fato, para a maioria dos leitores, o único conselho aplicável é o nº 2 (sobre o uso de uma conta em um registro CAA) e parcialmente o nº 1 no contexto de escolher um host com boa conectividade. Ao mesmo tempo, lembre-se de possíveis ataques ao serviço DNS no qual você hospeda seus registros (mas isso é uma questão separada e há muito material sobre isso).
É difícil capturar torproject.org.
O atacante precisa resolver dois problemas:
redirecionar o tráfego para o público-alvo (CA - quem receberá um site falso);
gerar um certificado.
De introdução:
$ 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 você pode ver, existe um registro CAA, você pode obter um certificado da letsencrypt, não há registro CAA associado à conta, o que significa que o problema é teoricamente solucionável por um invasor. Endereços IP do domínio torproject.org pertence à bem conhecida empresa de hospedagem Hezner.
Suponhamos que o atacante é um cliente de algum operador russo. Hezner não é um cliente de operadores russos (mas tem peering com os grandes – diretamente ou através do IX). Para que um invasor redirecione o tráfego de CA para si mesmo, a maneira mais fácil é se tornar um cliente desse operador e simplesmente ganhar à custa de um local-pref mais alto. Aqui tudo é relativamente simples e claro.
Para obter um certificado no letsencrypt, você precisa que o provedor que hospeda o letsencrypt encaminhe o tráfego para o invasor, em vez de para o Hezner (AS24940). letsencrypt resolverá em endereços diferentes para IP americanos e europeus, mas vamos ver como será difícil afetar o tráfego com acme-v02.api.letsencrypt.org/2.19.125.202 foi para o host do intruso. Aqui nos deparamos com o fato de que letsencrypt está hospedado no CDN Akamai, que tem uma conectividade muito boa em todo o mundo (presente na maioria dos grandes IX, tem conexões diretas com um grande número de grandes jogadores). A Akamai não tem uma LG pública, basicamente, para os clientes há uma API com a qual você pode fazer traceroute/ping, mas sem uma LG pública, você pode dar uma olhada no peering db para avaliar a escala de sua presença. O mesmo pode ser visto em hexner. Não é difícil ver que ambas AS têm uma presença no mesmo IX, portanto, pode-se concluir que, com uma probabilidade próxima a um, os prefixos as Hezner (AS24940) na tabela Akamai (As20940) são visíveis com AS_PATH 24940. Isso significa que, se um invasor tentar anunciar através de algum prefixo IX de Hezner, ele perderá para As_path os anúncios reais de Hezner (já que em AS_PATH será como o invasor). Uma solução possível poderia ser um peering "direto" entre o atacante e Akamai (se Akamai concordar com isso e se o local-pref for maior do que o IX).
Resumindo, adicionando o as de outra pessoa ao seu AS-SET, você pode causar uma degradação significativa do site torproject.org (para um grande número de clientes, mas não para todos no caso geral), mas comprar um certificado SSL torproject.org o letsencrypt provavelmente não funcionará devido à boa conectividade entre o verdadeiro originador (Hezner) e a CDN usada pelo letsencrypt (Akamai). No entanto, em outros casos, onde há transit as entre a hospedagem do site da vítima e a Autoridade de certificação e eles estão presentes no AS_PATH, o risco de obter um certificado pelo método descrito é significativamente aumentado.
Petukhov Oleg, advogado de Direito Internacional e proteção de dados pessoais, especialista em informação segurança, proteção de informações e dados pessoais.
Canal do Telegram: https://t.me/protecaodaInformacao
Grupo em Telegram: https://t.me/protecaodaInformacao1
Site: https://legascom.ru
Correio eletrónico: online@legascom.ru
#segurançadaInformação #Segurançadainformação
