Ripple20: Internet quebrou novamente

Nesse caso, descobrimos que o Ripple20 afeta a implementação da pilha TCP de bilhões de dispositivos IoT. Fala-se em ataques do dia 0, mas eles não são (não há evidências de que tenham sido aproveitados pelos atacantes) e também uma parte deles já foi corrigida antes de ser anunciada. Mas essas vulnerabilidades não são menos graves. Diante de um número tão grande de dispositivos expostos, a Internet quebrou novamente?

Foi anunciado pelo Departamento de Segurança Interna e pelo CISA ICS-CERT . Esses são 19 problemas de todos os tipos na implementação da pilha TCP / IP da empresa Treck. Como essa implementação fornece ou licencia inúmeras marcas (quase 80 identificadas) e dispositivos de IoT, os afetados são, efetivamente, bilhões. E por sua própria natureza, muitos deles nunca serão remendados.

O que aconteceu?

A empresa JSOF fez uma análise completa da pilha e encontrou problemas de todos os tipos. Uma auditoria escrupulosa que encontrou inevitavelmente quatro vulnerabilidades críticas, muitas sérias e outras menores. Eles poderiam permitir tudo, desde o controle completo do dispositivo até envenenamento no trânsito, incluindo negação de serviço. A razão do otimismo é que eles criaram um logotipo e um nome atraente para os bugs e relataram as vulnerabilidades em particular, muitos deles já foram corrigidos pela Treck e outras empresas que usam sua implementação. As razões para o pessimismo são que outros não foram resolvidos e que é difícil rastrear as marcas e modelos afetados (66 marcas estão com confirmação pendente). De qualquer forma, outro fato importante a destacar é que esses dispositivos geralmente são encontrados precisamente em plantas industriais, hospitais e outras infraestruturas críticas nas quais uma séria vulnerabilidade pode ter conseqüências horríveis.

Portanto, resta apenas auditar, entender e atenuar o problema caso a caso para saber se um sistema está realmente em perigo. Algo que já deveria ser feito sob um plano de segurança maduro (do qual os ambientes do AT não deveriam ser isentos), mas que, em qualquer caso, poderia servir como um estímulo para alcançá-lo. Porque são falhas graves, públicas e nas entranhas de dispositivos usados ​​para operações críticas … Uma verdadeira espada de Dâmocles.

De qualquer forma, eles já são conhecidos e, portanto, é possível proteger ou atenuar o problema, como já aconteceu no passado contra outros problemas graves que afetaram milhões de dispositivos conectados. Com eles, parecia que a Internet estava quebrando, mas, apesar de tudo, continuamos. E não porque não fossem sérios (ou mesmo, provavelmente, aproveitados por terceiros), mas porque sabiam como responder a eles em tempo hábil. Não é necessário diminuir sua importância, mas precisamente continuar concedendo-a para que não a percam, mas sempre fugindo de manchetes catastróficas. Vamos revisar alguns casos históricos.

Outros «apocalipses» de cibersegurança

Já houve outros casos de catástrofes que afetariam a rede como a conhecemos e sobre os quais várias manchetes pessimistas foram escritas. Vamos ver alguns exemplos:

• O primeiro a chegar às massas foi o «Effect 2000» , que apesar de não ter um logotipo oficial desde o início, tinha uma marca própria (Y2K). Aqueles eram outros tempos e, no final, ele ficou em uma espécie de decepção apocalíptica que estava satisfeita com muita literatura e alguns telefilmes.
• Apocalipse criptográfico do Debian em 2008: Uma linha de código foi removida em 2006 no pacote OpenSSL que ajudou a gerar entropia calculando o par de chaves pública e privada. As chaves geradas com ele não eram mais realmente confiáveis ​​ou realmente seguras. 
• Kaminsky e DNS em 2008 : foi uma falha inerente ao protocolo, não um problema de implementação. Dan Kaminsky descobriu sem oferecer detalhes. Thomas Dullien aventurou-se semanas depois para  publicar em seu blog  sua visão particular de qual poderia ser o problema e ele estava certo: era possível falsificar (através do envio contínuo de determinado tráfego) as respostas dos servidores autorizados de um domínio. Doze anos depois, mesmo após essa catástrofe, o DNSSEC permanece «uma raridade».
• Espionagem «em larga escala» com o BGP: Em agosto de 2008, houve uma conversa sobre a maior vulnerabilidade conhecida na Internet novamente.  Tony Kapela e Alex Pilosov demonstraram uma nova técnica (considerada teórica) que permitia interceptar o tráfego da Internet em escala global. Era uma falha de design no protocolo BGP (Border Gateway Protocol) que permitia interceptar e até modificar todo o tráfego da Internet não criptografado.
• Heartbleed em 2014: novamente deu a possibilidade de conhecer as chaves privadas nos servidores expostos. Além disso, inaugurou as vulnerabilidades da «marca»,  porque o apocalipse também deve saber como vendê-lo. Um logotipo e uma página exclusiva foram projetados com um modelo que se tornaria o padrão de fato, um domínio foi reservado, uma espécie de campanha de comunicação foi orquestrada, exageros foram lançados para fornecer embalagens, o tempo foi resolvidoetc. Ele abriu caminho para uma nova maneira de relatar, relatar e espalhar violações de segurança, embora , curiosamente, o curto efeito técnico fosse diferente: o sistema de revogação de certificados foi testado e, de fato, não se ajustou.
• Spectre / Meltdown em 2017 (e desde então muitas outras falhas nos processadores): esse tipo de falha tinha alguns elementos muito interessantes para supor uma inovação importante.  Essas eram falhas de design de hardware , não menos que no processador. Raramente testemunhamos uma observação no CERT.org, onde foi proposto abertamente a troca de hardware para corrigir um bug.

No entanto, se olharmos para ela com perspectiva, até agora parece que nenhuma dessas vulnerabilidades já foi usada como um método de ataque maciço que derruba a Internet e a «quebra». Felizmente, a responsabilidade de todos os atores do setor serviu para que não nos colocássemos nos piores cenários.

Infelizmente, sim, sofremos sérios problemas na rede, mas eles foram causados ​​por outras falhas muito menos espetaculares, baseadas em «worms tradicionais» como o WannaCry. Talvez isso mostre uma perspectiva interessante sobre, por um lado, a maturidade da indústria e, por outro, sobre o tremendo trabalho que ainda precisa ser concluído em alguns aspectos ainda mais simples.