Sequestro de tráfego da Google paralisa serviços na internet . O Google perdeu o controle de vários milhões de endereços IP por mais de uma hora na segunda-feira em um evento que indisponibilizou sua busca e outros serviços para muitos usuários e também causou problemas para o Spotify e outros clientes do Google na nuvem. Embora o Google tenha dito que não acredita que o acidente tenha sido uma tentativa maliciosa de sequestro, o vazamento pareceu suspeito para muitos, em parte porque desviou o tráfego para a China Telecom, o provedor chinês que recentemente foi flagrado roteando incorretamente tráfego pertencente a carries ocidentais através da China continental.
O vazamento começou às 21:13 UTC quando MainOne Cable Company, um pequeno ISP em Lagos, Nigéria, repentinamente atualizou tabelas no sistema de roteamento global da Internet para declarar indevidamente que seu sistema autônomo 37282 era o caminho correto para atingir 212 prefixos IP pertencentes ao Google . Em poucos minutos, a China Telecom aceitou a rota de maneira inadequada e anunciasse isto mundialmente. A iniciativa da China Telecom, também conhecida como AS4809, por sua vez, fez com que a russa Transtelecom, também conhecida como AS20485, e outros grandes provedores de serviços também seguissem a rota.
De acordo com o BGPmon no Twitter (figura acima), os redirecionamentos vieram em cinco ondas distintas ao longo de um período de 74 minutos. Os intervalos de IP redirecionados transmitiram algumas das comunicações mais confidenciais do Google, incluindo a infraestrutura de WAN corporativa da empresa e a VPN do Google. Este gráfico do registro regional da Internet, RIPE NCC, mostra como o efeito dominó se estendeu por um período de duas horas. A imagem abaixo mostra uma versão abreviada desses eventos.
“Quase certamente um erro”
O BGPmon disse que a MainOne fez um segundo anúncio na segunda-feira, 12/11, que fez com que o tráfego enviado para os endereços IP da Cloudflare seguisse um caminho quase idêntico. Como foi o caso com os endereços IP do Google, a China Telecom aceitou indevidamente a rota Cloudflare e a anunciou aos seus pares. A Transtelecom aceitou a rota, e outros provedores de serviços de grande porte logo a seguiram, fazendo com que a rota se propagasse em todo o mundo.
A má orientação dos endereços IP da Cloudflare aumentou as suspeitas de ações maliciosas, mesmo quando o CEO Matthew Prince disse a Ars Technica que o evento de roteamento de segunda-feira “era quase certamente um erro“, em vez de uma tentativa deliberada de sequestrar tráfego potencialmente sensível na Internet. Em um email, Prince explicou:
“Alguns antecedentes circunstanciais para confirmar isso: houve uma grande reunião de rede na Nigéria há algumas semanas (NgNOG). Essas reuniões sempre estimulam mais peering – interconectando redes que anteriormente não estavam diretamente conectadas. Ao estabelecer uma nova interconexão, o ISP nigeriano quase certamente vazou inadvertidamente as informações de roteamento para a China Telecom, que então vazou para o resto do mundo. Se houvesse algo nefasto em andamento, haveria maneiras muito mais diretas e potencialmente menos perturbadoras / detectáveis de redirecionar o tráfego.”
E completou: ” Porque o Google e o Cloudflare? Porque nós dois estamos presentes no Internet Exchange da Nigéria e, acredito, observamos esse ISP. A maioria dos outros grandes provedores ainda não está na Nigéria. Nós só ativamos nossa presença na Nigéria algumas semanas atrás. Eu acredito que o Google está lá há algum tempo. Martin Levy, da nossa equipe e cc:ed aqui, estava no NgNOG e pode adicionar mais cor e corrigir qualquer coisa que eu tenha errado.
Em uma declaração, representantes do Google escreveram: “Estamos cientes de que uma parte do tráfego da Internet foi afetada pelo roteamento incorreto de endereços IP, e o acesso a alguns serviços do Google foi afetado. A causa principal do problema era externa ao Google e não havia comprometimento dos serviços do Google. ”
Um representante do Google disse a Ars Technica que os funcionários da empresa também acreditam que o evento de roteamento foi um vazamento inadvertido do prefixo causado pela MainOne, que erroneamente anunciava um intervalo de endereços IP que não possuía. O representante do Google disse que as autoridades suspeitam que o vazamento foi acidental e não um desvio malicioso. O representante disse também que todo o tráfego afetado foi criptografado, uma medida que limita os danos que podem resultar de sequestros maliciosos.
Em um tweet feito cinco horas depois da Ars Technica publicar o ocorrido, autoridades da MainOne disseram que o anúncio do Google foi um erro administrativo.
“Investigamos o anúncio dos prefixos do @Google por meio de um de nossos parceiros no upstream“, escreveu um funcionário da MainOne. “Isso foi um erro durante uma atualização planejada da rede devido a uma configuração incorreta em nossos filtros BGP. O erro foi corrigido em 74 minutos e processos implementados para evitar a recorrência “.
Cyber Guerra ?
Segundo o jornal Independent o Google não revelou quantos usuários foram afetados, apesar de pesquisadores da empresa de inteligência de rede ThousandEyes terem relatado casos de tráfego da web sendo redirecionado do Reino Unido, França e Estados Unidos.
O incidente foi particularmente suspeito porque o tráfego da Internet estava sendo enviado para o provedor de internet do governo chinês, a China Telecom, que anteriormente foi acusado de roteamento indevido de tráfego pela China.
Segundo o Independet a suspeita reforça-se ainda devido a um relatório no início deste ano, realizado por pesquisadores da Escola de Guerra Naval dos EUA e da Universidade de Tel Aviv, descobriu que a China Telecom vem sequestrando o tráfego da Internet nos Estados Unidos e Canadá regularmente.
“Convenientemente, a China Telecom tem dez pontos de presença (PoPs), estrategicamente posicionados na Internet, controlados China , no backbone de internet da América do Norte“, afirmou o relatório.
“Vastas recompensas podem ser obtidas do sequestro, desvio e, em seguida, cópia de tráfego rico em informações entrando ou atravessando os Estados Unidos e o Canadá – muitas vezes despercebidos e entregues apenas com pequenos atrasos.“
Um porta-voz do Google disse ao The Independent: “Estamos cientes de que uma parte do tráfego da Internet foi afetada pelo roteamento incorreto de endereços IP, e o acesso a alguns serviços do Google foi afetado. A causa principal do problema era externa ao Google e não havia comprometimento dos serviços do Google. ”
Em uma atualização do Google Cloud Status Dashboard, o Google informou que estava conduzindo uma investigação interna na esperança de fazer “melhorias apropriadas” para ajudar a evitar uma recorrência futura do problema.
Grande Firewall da China
Os pesquisadores disseram que o tráfego mal direcionado era particularmente preocupante, dada a lista de países através dos quais grandes quantidades de dados sensíveis estavam passando.
O incidente “colocou o valioso tráfego do Google nas mãos de ISPs em países com uma longa história de vigilância na internet”, escreveu o pesquisador do ThousandEyes, Ameet Naik, em um post no blog.
Diferentemente do evento de 30 meses atrás, que roteava o tráfego da Internet em uma rota indireta pela China, o tráfego no incidente de segunda-feira envolvendo o Google nunca chegou ao destino pretendido. Em vez disso, como mostra o traceroute a seguir, o tráfego terminou em um roteador de borda dentro da China Telecom.
O tráfego reduzido apoiou ainda mais a narrativa de que o evento de roteamento foi um erro. Os sequestros de BGP são mais eficazes quando não são detectados pelos usuários finais, em vez de causar uma interrupção óbvia. Ainda assim, não havia dúvida de que, mesmo que o acidente fosse inadvertido, isso representava uma grande desordem. Um post de blog publicado pela empresa de inteligência de rede ThousandEyes observou:
“Este incidente, no mínimo, causou uma negação massiva de serviço ao GSuite e à Pesquisa do Google. No entanto, isso também coloca o valioso tráfego do Google nas mãos de provedores em países com um longo histórico de vigilância da Internet. No geral, ThousandEyes detectou mais de 180 prefixos afetados por esse vazamento de rota, que abrange um vasto escopo dos serviços do Google. Nossa análise indica que a origem desse vazamento foi a relação de peering do BGP entre a MainOne, o provedor nigeriano, e a China Telecom. A MainOne tem uma relação de peering com o Google via IXPN em Lagos e tem rotas diretas para o Google, que vazaram para a China Telecom. Embora não saibamos se isso foi um erro de configuração ou um ato mal-intencionado, essas rotas vazadas se propagaram da China Telecom, via TransTelecom para a NTT e outros ISPs de trânsito. Também notamos que esse vazamento foi propagado principalmente por provedores de trânsito de nível corporativo e não impactou tanto as redes de ISP do consumidor.”
O IXPN refere-se ao Internet Excahnge Point da Nigéria, onde os ISPs regionais com acordos de peering se encontram para trocar o tráfego gratuitamente. A existência de acordos de peering entre o Google e MainOne e Cloudflare e MainOne ainda suporta as garantias de que o acidente de roteamento não foi intencional.
A Ars Technica lembra de que o protocolo de gateway de borda que roteia o tráfego de Internet do sistema autônomo para o sistema autônomo em todo o mundo é tão frágil quanto intrincado. Embora sua base de confiança nunca tenha sido projetada para resistir aos atores hostis que tantas vezes preenchem a Internet de hoje, as complexidades do BGP são suficientes para tornar os principais erros um fato da vida. Embora seja muito cedo para declarar este acidente de roteamento como um acidente, as indicações neste momento não apoiam as suspeitas de que isso foi um delito deliberado.
De qualquer forma, o evento e sua capacidade de não ser detectado até que os usuários finais começaram a relatar o tráfego interrompido ressalta a incapacidade contínua dos principais provedores em lidar com as limitações de desempenho e segurança do BGP.
“Por meio de um pequeno ISP nigeriano, os prefixos do Google vazaram para as operadoras de primeiro nível em todo o mundo, interrompendo o tráfego”, disse Kris Slevens, engenheiro de contas técnico especializado em segurança de redes da Continuous Networks. “Isso ainda mostra que a China Telecom não refreou sua infraestrutura para qualquer tipo de filtragem, e como o BGP inerentemente frágil está sendo baseado na confiança. Também com um artigo publicado na semana passada sobre o passado da China Telecom vemos que o problema de redirecionamento do tráfego, não é novo. E, o mais importante, as trocas de peering precisam de limites ou filtros de prefixo mais restritos. Isso é altamente negligenciado. “
O RIPE NCC, uma organização sem fins lucrativos que aloca e registra números IP a ISPs, também investigou o evento de segunda-feira e concluiu que não era malicioso.
“Uma olhada em nossos dados do RIPE Atlas sugere que o ISP em questão estava reconfigurando sua rede em vez de algo malicioso“, disse Emile Aben, engenheiro sênior de pesquisa do RIPE NCC, em um comunicado enviado por email para Ars Technica. “Essas reconfigurações acontecem todos os dias no roteamento global e erros podem acontecer, especialmente porque a configuração dos roteadores é propensa a erros e muitas vezes ainda requer entrada manual que é propensa a erros de digitação. O projeto MANRS, que ganhou muita tração recentemente , contém diretrizes para que os ISPs apliquem melhor filtragem a seus roteadores. Os ISPs que seguirem essas diretrizes provavelmente reduzirão o impacto desses eventos no futuro “.
Fonte: Ars Technica & Independent
Veja também:
- CrowdStrike solução AV sem Assinatura!
- Nova LGPD: direito à portabilidade
- Falha no Portal Steam dava acesso à CD Keys de jogos
- Fórum da Lei de Proteção de Dados e GDPR
- Contas do Internet Banking do HSBC-US são violadas por hackers
- Vulnerabilidade na Libssh é muito fácil de ser explorada
- Falha permite escalada de privilégio afeta a maioria das distribuições Linux
- Hackers exploram vulnerabilidade de zero day da Cisco ASA e FTD
- Como nível C contribui para uma postura de segurança mais forte
- LGPD-SP – A proteção estadual de dados pessoais e o PL 598/2018
- IBM adquire distribuidor Linux Red Hat por US $ 33,4 bilhões
- 10 maneiras de manter-se seguro online
Deixe sua opinião!