O artigo está dividido em três partes. O primeiro contém informações gerais sobre o que é o seqüestro de BGP e sua versão tradicional. Para aqueles que estão familiarizados com esse fenômeno, é recomendável ir diretamente para a segunda parte. A segunda parte descreverá o método de anunciar prefixos estrangeiros adicionando um AS estrangeiro ao seu AS-SET. Na terceira parte, será feita uma avaliação da complexidade do uso do método descrito na segunda parte para capturar o endereço IP do recurso torproject.org e emitir um certificado para ele. Supõe-se que o leitor esteja familiarizado com os princípios do BGPv4.
Seqüestro simples de BGP
Em poucas palavras, o seqüestro de BGP está capturando os endereços IP de outra pessoa (aleatória ou intencional).
Normalmente, o seqüestro de BGP se parece com isso: um AS que não possui um prefixo começa a anunciar (prefixo de outra pessoa), uplinks / pares aceitam e começa a se espalhar pela Internet. Eles o aceitam pelo motivo de que não há filtragem de prefixos na junção (isso é um erro de configuração ou foi concebido (uma vez que é muito difícil criar um filtro de prefixo na junção com operadores muito grandes devido a vários motivos, isso não é importante para este artigo)) ) Um dos exemplos mais destacados dos últimos tempos em que 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). Você pode ver como esses anúncios pareciam no histórico do bgplay (
visualizando via web ,
json (
arquivo morto)). Aqui está um deles em um dos coletores RIPE (o prefixo 216.119.216.0/24 pertence ao Mastercard (AS26380)):
"source_id": "05-193.203.0.185", "path": [ 6939, 12389 ], "community": [], "target_prefix": 216.119.216.0/24
E aqui está a aparência do anúncio 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
I.e. nesse caso, a Rostelecom anunciou um prefixo diretamente do seu AS (o último AS no AS-PATH é 12389). Os problemas poderiam ser evitados se os uplinks e as festas dos prefixos Rostelecom filtrassem o Rostelecom
criando listas de prefixos de acordo com o AS-SET e / ou
validando prefixos de acordo com o ROA RPKI . A construção de listas de prefixos entre grandes operadores geralmente não é concluída e nem todos implementaram o RPKI (mas há
progresso ). Tal seqüestro, teoricamente, pode ser feito por qualquer pessoa, mas apenas se o prefixo anunciado "vazar" por pelo menos um uplink / banquete. Geralmente, grandes operadores russos configuram filtros de prefixo na direção de seus clientes e, portanto, pequenos AS (operadores de pequeno / médio porte, alguns de hospedagem e algumas empresas), quase sempre, não podem realizar esse ataque (mas, novamente, tudo depende da região / país / operador específico).
No entanto, os invasores ainda encontram lugares (uplinks) em que a filtragem não está configurada (em 2017, o Brasil era o
líder em seqüestros ) e realizam um ataque pegando endereços IP (geralmente, esses eventos caem em feeds de notícias), para um ataque mais eficaz, Anuncie prefixos mais específicos (com uma máscara mais longa) do que um originador real. Agora vamos para a versão de ataque, onde nem a validação ROA RPKI nem as listas de prefixos AS-SET são salvas.
Seqüestro de BGP com a adição de vítima de AS em seu AS-SET
Considere o seguinte cenário:
- Um invasor obtém endereços de IP e AS (de fato, tecnicamente, ele não precisa de endereços IP, é mais provável que eles não causem perguntas).
- O invasor se conecta a vários operadores grandes e IXs (pelo menos um operador ou IX), especificando não apenas seu AS, mas seu AS-SET como fonte de dados sobre os prefixos anunciados (essa é uma prática normal para a interação entre operadores (incluindo incluindo quando em um relacionamento cliente-ligação ascendente) ou para inclusão em IX-ah)). No caso normal, o AS-SET é especificado, e não apenas o AS, quando se supõe que o cliente não é um beco sem saída, mas que ele próprio possui (ou terá) clientes com bgp e suas próprias redes.
- Após algum tempo, o atacante adiciona o AS da vítima ao seu AS-SET e começa a anunciar seu prefixo por si mesmo, ou seja, o AS-PATH anunciado tem a seguinte aparência: "AS_ atacante AS_ vítimas". 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, portanto, 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 que ele ganha e entra na tabela de roteamento, em algum lugar que ele perde e não (o anúncio da vítima permanece lá). Depende de quantos uplinks e de quantos IXs um invasor usa. Quando um invasor se conecta a algum AS como cliente, dentro dele (na maioria das vezes) ele vence a vítima devido a um prefixo local maior (se a vítima não for cliente do mesmo uplink, a vítima vencerá pelo AS-PATH se não o fizer pré-anexado), ou seja, um invasor precisa se conectar ao maior número possível de uplinks com seu AS-SET para maximizar a eficácia de seu ataque.
Além disso, o invasor deve se conectar ao número máximo de IXs, conforme normalmente, os ASs de deadlock definem o prefixo local mais alto como IXs e se o prefixo da vítima não estiver envolvido no IX, ele perderá o anúncio do atacante nas tabelas de roteamento dos ASs de deadlock.
Em teoria, este é um ataque bastante forte, mas, felizmente, na prática, as seguintes limitações surgirão:
- Você precisa criar uma entidade legal, pelo menos uma, mas, na verdade, provavelmente será necessária em diferentes países.
- É necessário concluir acordos com operadores, IXs, quase sempre fazer uma taxa de conexão, com LIR / RIR.
- Alguns operadores ainda não criam listas de prefixos AS-SET automaticamente, eles precisam escrever letras para isso. Um administrador experiente suspeitará de algo se o AS-ka de uma empresa conhecida aparecer de repente no AS-SET de uma empresa desconhecida.
- Após o ataque, o equipamento usado (se estiver localizado em algum tipo de datacenter) provavelmente será apreendido no caso de um processo criminal ser aberto.
- As listas de prefixos para diferentes operadores / IX são atualizadas em momentos diferentes; portanto, você precisará analisar quem atualiza quando esse também não é o trabalho mais fácil.
Possíveis medidas de proteção:
- Teoricamente, para se defender de um ataque desse tipo, você precisa ter o maior número possível de interfaces com os operadores (melhor, os clientes, porque eles têm prefixo local superior) e IXs. I.e. faça a mesma coisa que um invasor fará. Obviamente, na prática, isso é extremamente difícil de implementar 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 tarefa da conta (se o seu provedor de certificados SSL oferecer suporte. O Letsencrypt suporta) (consulte RFC6844 ). Nesse caso, o invasor não poderá emitir um certificado (a menos que ele possa alterar o registro CAA)
- Teoricamente, a ampla implementação do BGPsec deve eliminar esse ataque, mas seu destino ainda não está claro (na prática, ainda não é aplicado ou muito raramente).
- Implementação da verificação alternativa AS_PATH (sem BGPsec) (até agora, este é um rascunho que resolve o problema descrito no caso de sua ampla implementação).
- A proibição da adição descontrolada de um AS estrangeiro ao seu AS-SET (sem a permissão do proprietário do AS) pode reduzir a possibilidade de realizar esses ataques nas regiões onde os AS-SETs são usados para filtrar em junções. Agora não existe essa proibição.
De fato, 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 o número 1 parcialmente no contexto de escolha de um host com boa conectividade. Ao mesmo tempo, é necessário lembrar-se de possíveis ataques ao serviço DNS no qual você hospeda seus registros (mas esse é um problema separado e há muitos materiais nele)
É difícil capturar torproject.org
Um invasor precisa resolver dois problemas:
- Redirecionar o tráfego para o público-alvo (público-alvo - quem receberá o site falso)
- Gerar certificado
Introdutório:
$ 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 de letsencrypt, não há ligação à conta no registro CAA, o que significa que o problema é teoricamente resolvido pelo invasor. Os endereços IP do torproject.org são de propriedade da conhecida hospedagem Hezner.
Suponha que o público-alvo de um invasor seja o cliente de algum operador russo. Hezner não é um cliente de operadores russos (mas tem pares com grandes - diretamente ou através de IX-s). A maneira mais fácil de um invasor redirecionar o tráfego da CA para si mesmo é se tornar um cliente desse operador e simplesmente vencer às custas de um prefixo local mais alto. Tudo aqui é especialmente relativamente simples e claro.
Para obter um certificado no letsencrypt, você precisa do provedor no qual o letsencrypt está hospedando para direcionar o tráfego ao invasor, e não ao Hezner (AS24940). letsencrypt resolve para endereços diferentes para IP americano e europeu, mas vamos ver como será difícil influenciar esse tráfego de acme-v02.api.letsencrypt.org/2.19.125.202 para o host do invasor. Aqui nos deparamos com o fato de o letsencrypt estar hospedado no Akamai CDN, que tem muito boa conectividade em todo o mundo (está presente nos principais IXs, possui articulações diretas com um grande número de players grandes). A Akamai não possui um LG público; em princípio, existe uma
API para clientes com os quais você pode fazer traceroute / ping, mas mesmo sem um LG público, você pode dar uma olhada no
db em
peering para avaliar a escala de sua presença. Da mesma forma, você pode olhar para
Hezner . É fácil ver que os dois ASs têm a presença dos mesmos IXs; portanto, podemos concluir que, com uma probabilidade próxima à unidade, os prefixos AS Hezner (AS24940) na tabela Akamai (AS20940) são visíveis no AS_PATH 24940. Isso significa que se um invasor Se tentar anunciar os prefixos de Hezner por meio de um IX, eles perderão, de acordo com AS_PATH, os anúncios reais de Hezner (já que AS_PATH conterá o AS do invasor). Uma solução possível seria organizar um peering "direto" entre o atacante e a Akamai (se a Akamai concordar com isso e se for local-pref) mais alto do que nas junções com IXs).
Para resumir, 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 obter o certificado SSL do torproject.org em letsencrypt, provavelmente, não funcionará devido à boa conectividade entre o originador real (Hezner) e a CDN usada pelo letsencrypt (Akamai). No entanto, em outros casos, quando existem ASs de trânsito 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 usando o método descrito aumenta significativamente.