Ataques ao BGP. 1
Essas violações podem ser obtidas como resultado dos seguintes ataques ao protocolo BGP.
O BGP funciona baseado no protocolo TCP, escutando na porta 179. Portanto, o protocolo BGP é vulnerável a ataques ao TCP, que discutimos anteriormente.
Ataque de violações de sigilo. Como mencionado anteriormente, os dados da rota BGP são transmitidos em texto não criptografado, o que facilita a interceptação de Informações (isso ocorre porque a confidencialidade dos dados da rota não é um requisito geral).
Replay attack. O BGP não inclui medidas para impedir a reutilização de mensagens interceptadas.
O ataque de inserção de mensagem. O BGP não inclui a proteção da inserção de mensagem. Contudo, desde que o BGP usa o protocolo de transporte TCP, quando a conexão é terminada, a inserção de mensagem por um nó externo exigirá a previsão exata dos números de sequência (tal previsão é possível, mas muito difícil para boas implementações TCP) ou da intercepção de sessão.
Ataque de exclusão de mensagem. 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 alta qualidade, mas não podem ser completamente excluídos.
O ataque de modificação de mensagem. O BGP não inclui a proteção contra a alteração da mensagem. A modificação sintaticamente correta sem alterar o tamanho dos dados TCP geralmente será imperceptível.
Ataque Man-in-the-middle. O BGP não inclui proteção contra ataques MITM. O BGP não usa autenticação de parceiros, e tais ataques se tornam um "brinquedo de criança."
Ataque de negação de serviço. Embora os dados de roteamento falsos próprios possam servir como um ataque DoS no sistema final que tenta transmitir dados através da rede, e a rede no conjunto, alguns tipos de informação falsa podem criar ataques DoS no protocolo BGP próprio. Por exemplo, o anúncio de um grande número rotas mais específicas (prefixos mais longos) pode conduzir a um aumento no tráfego BGP e no tamanho das tabelas de roteamento, que serão inaceitáveis para o sistema.
Para resumir o que está descrito nesta seção, deve-se observar que a presença de riscos se deve a três vulnerabilidades principais:
a falta de um mecanismo embutido para proteger a integridade e relevância dos dados, autenticação de parceiros para envio de mensagens;
a falta de um mecanismo de verificação de autorização AS para as informações anunciadas de Nlri (Network Layer Accessibility Information;
a falta de um mecanismo para garantir a confiabilidade dos atributos de rota anunciados pelo AS.
Sequestro de BGP simples.
O sequestro de BGP geralmente se parece com isto: como, que não possui um prefixo, começa a anunciá-lo (o prefixo de outra pessoa), os uplinks/peers o aceitam e ele começa a se espalhar pela Internet. Eles aceitam pelo motivo de não haver filtragem de prefixos na junção (ou isso é um erro de configuração, ou é pretendido dessa forma (porque é muito difícil construir um filtro de prefixo na junção com operadores muito grandes devido a várias razões, não é importante para este artigo)). Um dos exemplos mais destacados dos últimos tempos é quando a Rostelecom (AS12389) começou a anunciar os prefixos da Mastercard (AS26380), Visa e algumas outras organizações financeiras (de acordo com a versão oficial, como resultado de uma falha de software). Você pode ver como eram esses anúncios na história do bgplay (visualização via web, json (arquivo)), Aqui está um deles em um dos coletores RIPE (prefixo 216.119.216.0/24 pertence à Mastercard (AS26380)):
"source_id": "05-193.203.0.185",
"path": [
6939,
12389
],
"community": [],
"target_prefix": 216.119.216.0/24
E aqui está o que o anúncio real parecia.:
"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 mais recente AS em AS-PATH é 12389). O problema poderia ter sido evitado se os uplinks e peers da Rostelecom tivessem filtrado prefixos da Rostelecom construindo listas de prefixos usando AS-SET e/ou validando prefixos usando ROA RPKI. A construção de listas de prefixos entre grandes operadoras muitas vezes não é feita, e o RPKI também não foi implementado de longe (mas há progresso). Teoricamente, qualquer um pode cometer tal sequestro, mas somente se o prefixo anunciado "vazar" através de pelo menos um uplink/peer. Normalmente, as grandes operadoras russas configuram filtros de prefixo para seus clientes e, portanto, AS pequenas (operadoras de pequeno/médio porte, algumas empresas de hospedagem e algumas empresas) quase sempre não podem realizar tal ataque (mas, novamente, tudo depende da região / país / operadora específica).
No entanto, os invasores ainda encontram locais (uplinks) onde a filtragem não está configurada (o Brasil foi o líder em sequestros em 2017) e realizam um ataque/ captura de endereços IP (tais eventos costumam entrar nos noticiários
fitas), para maior eficácia, os ataques podem anunciar prefixos mais específicos (com uma máscara mais longa) do que o originador real. Agora vamos para a opção de ataque, onde nem a validação Roa RPKI nem as listas de prefixos as-SET podem salvar.
Sequestro de BGP com a adição do AS-SET da vítima.
Considere o seguinte cenário.
O invasor obtém endereços AS e IP (na verdade, tecnicamente, ele não precisa de endereços IP, em vez disso, eles são apenas para não levantar questões).
O invasor se conecta a vários operadores grandes e IX (minimamente a pelo menos um operador ou IX), especificando não apenas seu AS, mas seu AS-SET como a fonte de dados sobre os prefixos anunciados (essa é uma prática normal para interação entre operadores (inclusive em relacionamentos cliente-uplink) ou para habilitar no IX)). No caso normal, AS-SET é indicado, e não apenas AS, quando está implícito que o cliente não é um beco sem saída, mas ele próprio tem (ou terá) clientes com bgp e suas próprias redes.
Depois de um tempo, o atacante adiciona o AS da vítima ao seu AS-SET e começa a anunciar seu prefixo através de si mesmo, ou seja, o as-PATH anunciado fica assim: "AS_O AS_ da vítima está morto."Do ponto de vista das listas de prefixos construídas automaticamente e do ponto de vista do RPKI, este é um anúncio completamente válido, então os dois mecanismos de proteção não funcionarão aqui.
O prefixo anunciado começa a competir com o anúncio real (o anúncio da vítima), em algum lugar ele vai ganhar e entrar na tabela de roteamento, em algum lugar ele vai perder e não chegar lá (o anúncio da vítima permanecerá lá). Depende de quantos uplinks e quantos IX o atacante usa. Quando um invasor se conecta a um AS como um cliente, então dentro dele ele (na maioria das vezes) se beneficiará da vítima devido a um local-pref maior (a menos que a vítima seja um cliente do mesmo uplink, então a vítima se beneficiará do as-PATH se ele não preceder), i.e. O invasor precisa se conectar ao maior número possível de uplinks com seu AS-SET para maximizar a eficácia de seu ataque.
O atacante também deve se conectar ao número máximo de IX' S, porque geralmente deadlocked ASS define o maior local-pref para IX ' S, e se o prefixo da vítima não participar de IX, ele perderá o anúncio do atacante nas tabelas de roteamento de deadlocked AS.
Em teoria, este é um ataque bastante forte, mas felizmente, na prática, surgirão as seguintes limitações.
Você precisa registrar uma pessoa jurídica, pelo menos uma, mas na verdade, muito provavelmente, elas serão exigidas em diferentes países.
É necessário celebrar contratos com operadoras, IX ' S, e quase sempre efetuar pagamento de conexão com LIR/RIR.
Alguns operadores ainda não constroem listas de prefixos usando AS-SET automaticamente, eles precisam escrever letras para isso. Um administrador experiente suspeitará de algo se um AS conhecido aparecer repentinamente no AS-SET de uma empresa desconhecida.
Após o ataque, o equipamento utilizado (se estiver localizado em algum data center) provavelmente será apreendido em caso de processo criminal.
As listas de prefixos para diferentes operadores / IX são atualizadas em momentos diferentes, então você precisará analisar quem atualiza quando, o que também não é o trabalho mais fácil.
Possíveis medidas de proteção.
Teoricamente, para se proteger de tal ataque, você precisa ter o maior número possível de conexões com operadores (melhores que os clientes, porque eles têm um local-pref mais alto) e IX. ou seja, fazer a mesma coisa que um invasor faria. Claro, isso é extremamente difícil de implementar na prática e exigirá recursos significativos. Este método é relevante apenas para serviços que fornecem serviços de segurança da informação em uma base profissional.
Se você tiver um site, use um registro CAA com a atribuição de conta (se o seu provedor de certificado SSL suportar; letsencrypt suporta) (consulte RFC6844). Nesse caso, o invasor não poderá emitir o certificado (a menos que possa alterar o registro CAA).
Teoricamente, a implementação generalizada do BGPsec deve eliminar tal ataque, mas seu destino ainda não está claro (na prática, ainda não foi aplicado ou é muito raramente usado).
Implementação de uma verificação as_path alternativa (sem BGPsec) (até agora, este é um rascunho que resolve o problema descrito no caso de sua implementação generalizada).
Proibir a adição descontrolada do AS de outra pessoa ao seu AS-SET (sem a permissão do proprietário do AS) poderia reduzir a possibilidade de tais ataques nas regiões onde os AS-SETS são usados para filtragem nas junções. Não existe essa proibição agora.
Na verdade, para a maioria dos leitores, o único conselho que se aplica a eles é o número 2 (em relação ao uso da conta em um registro CAA) e, em parte, o número 1 no contexto da escolha de um hoster com boa conectividade. Ao mesmo tempo, você precisa ter em mente possíveis ataques ao serviço DNS onde você hospeda seus registros (mas este é um problema separado, e há muitos materiais sobre ele).
É difícil capturar torproject.org .
O atacante precisa resolver duas tarefas:
redirecionar o tráfego para o público-alvo (público-alvo-que receberá o site falso);
gere um certificado.
Notas introdutórias:
$ 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 do letsencrypt, não há link para a conta no registro CAA, o que significa que o problema pode teoricamente ser resolvido por um invasor. Endereços IP do domínio torproject.org eles pertencem ao bastante conhecido hezner hosting.
Digamos que o público-alvo do invasor sejam os clientes de alguma operadora russa. A Hezner não é cliente das operadoras russas (mas tem relações peer–to-peer com as grandes, seja diretamente ou através das IX). Para que um invasor redirecione o tráfego da CA para si mesmo, a maneira mais fácil é se tornar um cliente desse operador e simplesmente ganhar devido a um pref local mais alto. Tudo é relativamente simples e claro aqui.
Para obter um certificado no letsencrypt, você precisa que o provedor que hospeda o letsencrypt direcione o tráfego para o invasor, e não para o Hezner (AS24940). letsencrypt resolve para endereços diferentes para endereços IP americanos e europeus, mas vamos ver como será difícil influenciar o tráfego de acme-v02.api.letsencrypt.org/2.19.125.202 foi até o anfitrião do atacante. Aqui nos deparamos com o fato de que o letsencrypt está hospedado no Akamai CDN, que tem uma conectividade muito boa em todo o mundo (está presente na maioria das principais plataformas, tem conexões diretas com um grande número de grandes players). A Akamai não tem um LG público, em princípio, existe uma API para clientes que pode ser usada para fazer traceroute/ping, mas mesmo sem um LG público, você pode olhar o banco de dados de peering para avaliar a escala de sua presença. Você pode olhar para hezner de maneira semelhante. É fácil ver que ambos AS têm presença no mesmo IX, daí pode-se concluir que com uma probabilidade próxima da unidade, 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 os prefixos de Hezner através de qualquer IX, ele perderá os anúncios reais de Hezner de acordo com AS_PATH (já que o AS do invasor estará em AS_PATH). Uma possível solução pode ser organizar o peering "direto" entre o invasor e a Akamai (se a Akamai concordar com isso e se o local-pref for maior do que nas junções com o IX).
Para resumir, ao adicionar 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 adquira um certificado SSL torproject.org no letsencrypt, ele provavelmente falhará devido à boa conectividade entre o originador real (Hezner) e o CDN usado pelo letsencrypt (Akamai). Entretanto, em outros casos, quando há trânsito como entre a hospedagem do site vítima e a autoridade certificadora e eles estão presentes no AS_PATH, o risco de obtenção de um certificado utilizando o método descrito aumenta significativamente.
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
