Informe aqui

Desarmando exploits: chega de “militarizar” a cibernética

Jeffrey Tang*

Em todos os lugares que olho, sou constantemente cercado por notícias usando termos como “exploits armados” e “malware armado” para descrever o mais recente surto de malware. A narrativa que resulta dessa linguagem pitoresca é prejudicial à proteção de nossas redes de computadores, porque procura aplicar categoricamente a metáfora do conflito militar à segurança cibernética – e nem todo incidente cibernético se qualifica como um “ataque militar”.

Eu gostaria de argumentar que as palavras que usamos nesse setor são importantes e definem o tom e o contexto de nossa discussão pública sobre cibersegurança. O problema de aplicar terminologia imprecisa é que isso restringe nosso pensamento: se tudo é uma arma, então seu uso é um ataque, portanto devemos detectar o ataque iminente e responder a ele.

É o Ciclo OODA (observar, orientar, decidir, agir) em ação. Uma má escolha de linguagem leva a uma estrutura ruim para a discussão e, em última análise, resultará em decisões inadequadas, como pensar que é apropriado responder a uma intromissão da rede de computadores com uma arma cinética.

Tudo o que nos resta é a prevenção, que observadores como Peter Singer notam que não tem sido eficaz e, ao contrário, criou incentivos para que outros países invadam redes privadas e roubem informações confidenciais.

Para um homem com um martelo…
Descrever consistentemente todos os exploits e malwares como “armas” contribui para o pensamento equivocado de que apenas agentes apoiados por países são capazes de desenvolver armas cibernéticas. Já sabemos que esse não é o caso.

O botnet Mirai, por exemplo, que causou enorme problemas com ataques de negação de serviço (DDoS) em número recorde, foi inicialmente tratado como sendo o trabalho de um país. Mas, eventualmente, revelou-se que era o trabalho de alguns universitários. Em outras palavras, um botnet com a capacidade de derrubar grandes provedores e websites foi construído devido a uma disputa por servidores de um videogame popular, o Minecraft.

Ficou mais fácil fazer travessuras e causar confusão porque estamos conectando cada vez mais coisas às nossas redes e, pior ainda, à Internet pública. O ritmo exponencial em que códigos são escritos e produtos são lançados no mercado (agora com mais câmeras, microfones, GPS e outros sensores) só pode significar que estamos ficando cada vez mais vulneráveis. Os criminosos não precisam melhorar seus métodos porque continuamos facilitando o trabalho deles, bombardeando nossas redes com dispositivos inseguros e softwares criados apressadamente.

Uma questão secundária é que a indústria da segurança da informação e a mídia têm fetiche pela ideia de “exploits armados.”. No mínimo, o termo certamente rende uma manchete sexy que serve como excelente clickbait.

Essa obsessão resulta em uma informação preguiçosa, na qual todo incidente de segurança ou problema é descrito como um “ataque cibernético”. O uso excessivo e indevido do termo “ataque cibernético” resultou em uma nova orientação do AP Stylebook 2017, que o define como “uma operação de computador realizada em um dispositivo ou uma rede que cause dano físico ou perturbação significativa e abrangente.”

Da mesma forma, James Lewis, do Centro de Estudos Estratégicos e Internacionais, define um ataque em seu relatório Repensando a Segurança Cibernética como uma ferramenta “para violência ou coerção a fim de obter efeito político”, talvez em uma tentativa de adicionar alguma precisão à maneira como discutimos segurança.

Quebrando a Cyber Kill Chain
A fixação em aplicar categoricamente uma visão militarista sobre a cibernética leva a uma indústria dominada pela terminologia de guerra. O cenário cibernético é agora “um domínio” (o domínio de combate, não um TLD aprovado pela ICANN) com direito a um Comando cibernético, “forças cibernéticas” e “cyber kill chains”.

Esse tipo de pensamento nos leva a metáforas bombásticas como “Pearl Harbor cibernético” ou “11 de setembro cibernético”. (Na minha opinião, o uso desses termos desrespeita as memórias daqueles que pereceram nesses eventos trágicos.) Da mesma forma, essa visão leva a ideias hilariantemente simplistas de que podemos apenas “isolar malware” e “reformulá-lo e prepará-lo para usá-lo contra o mesmo adversário” – como se um código executável fosse equivalente a um fuzil inimigo retirado do campo de batalha.

É incompreensível comparar a inconveniência de não conseguir acessar suas mídias sociais ou transações bancárias online com um ataque no mundo real que causa mortes em massa. A comparação fica mais fraca à medida que nossa sociedade começa a confiar cada vez mais na tecnologia da informação, levando a consequências como não poder acessar seus registros eletrônicos de saúde no hospital quando você está no pronto socorro.

Então, o que significa realmente um exploit armado? Não é como se pudéssemos arrancar um exploit de um projeto Metasploit e amarrá-lo em um míssil intercontinental, chamando-o de “armado”.

Exploits não fazem estrondos e tentar rotulá-los como armas é uma piada. A maneira como falamos sobre segurança cibernética em termos de armas e defesas soa como um filme ruim de ficção científica: “Cybernado”, a história de um ransomware devastando a Terra que só pode ser parado com resgate pago com dinheiro de mineração de Bitcoin.

No mundo real, as vulnerabilidades de software são bugs ou artefatos computacionais não-intencionais que permitem a um invasor enganar o computador fazendo com que execute um código fornecido por esse invasor ou vaze inadvertidamente informações como senhas, nomes de usuário ou endereços de memória. Exploits são programas de computador que aproveitam as vulnerabilidades em outros programas de computador. Atualizações de software e patches corrigem a vulnerabilidade e criam imunidade ao exploit.

O dano real pode ser feito pelo payload entregue pelo exploit. O payload pode ilicitamente instalar um backdoor na máquina, permitindo que o agente da ameaça retorne mais tarde ou adote uma ação destrutiva imediata, criptografando todos os seus arquivos e exigindo um resgate.

Nem especialistas concordam sobre a definição “exploit armado”. Alguns consideram que é uma validação de conceito, da mesma forma que a primeira arma de fogo impressa em 3D foi capaz de disparar uma única vez antes de se destruir. Enquanto isso, outros especialistas consideram a “militarização” de exploits como sendo o refinamento de um exploit de tal forma que sempre funcione: pressione , pegue a shell. O primeiro é meramente a versão de segurança dos “trabalhos na minha máquina” de um programador, enquanto o segundo é apenas um software trabalhando de forma confiável como pretendido do ponto de vista do criador do exploit.

Na mesma linha, as “armas” do mundo real têm a intenção de uso ofensivo ou de defesa; embora algumas possam ser categorizadas como “ferramentas”, provar a intenção é algo complicado. Por exemplo, uma faca de chef pode ser usada para cortar um bife ou cometer um homicídio, mas, embora ambas as ações possam ser cometidas intencionalmente pelo usuário da faca, apenas o primeiro uso foi intencionado pelo fabricante / varejista da faca.

Da mesma forma, é difícil determinar a intenção apenas lendo o código. O software excluiu todos os seus arquivos maliciosamente ou foi apenas um bug no código? Quando o seu antivírus exclui um arquivo crítico, é um ataque? Eu não acho que alguém argumentaria que os vendedores desses softwares tinham intenções maliciosas.

Construindo Exploits Confiáveis
Um software é complexo e, com a complexidade, vem os bugs. Em algum momento, atores sofisticados vão tirar vantagem disso e operar disfarçados de software bugados que podem introduzir um backdoor ou excluir acidentalmente seus arquivos. Se um número suficiente de dispositivos conectados à Internet forem imunizados, poderemos evitar novos ataques, mas no clima de faroeste causado pela atual saturação do mercado de dispositivos não seguros (todos lançados com a mesma senha), ninguém sabe o que o futuro da IoT pode trazer.

Enquanto isso, o processo de validar o conceito de uma vulnerabilidade como um “exploit armado” requer uma quantidade enorme de pesquisa, desenvolvimento e teste. As minúcias de níveis de patch, configurações de tempo de execução, pacotes de idiomas, plug-ins e software de terceiros são importantes no mundo do desenvolvimento de exploits e devem ser levados em conta ao se desenvolver um exploit de corrupção de memória.

Cada pequeno desvio do sistema de teste do desenvolvedor perturba o layout da memória, o que exige um esforço extra de desenvolvimento para lidar com esses casos. O exploit deve ser robusto, apesar das variações no layout da memória. Em outras palavras, é apenas engenharia de software padrão em que o objetivo é criar um produto confiável que possa dar conta de condições erradas e lidar com elas de maneira elegante.

Nas palavras de @halvarflake, “um exploit é ‘apenas’ um programa para a máquina estranha que leva a uma violação das propriedades de segurança”. Construir exploits confiáveis não é diferente de construir um software confiável. Mas se for o caso, talvez devêssemos “armar” softwares comuns (sistemas operacionais e navegadores). Esse esforço existe, mas é conhecido por um nome que não é tão sexy: hardening.

Há muito trabalho sendo feito por aí (prevenção de execução de dados, integridade de fluxo de controle, randomização de layout de espaço de endereçamento, tecnologia para reforçar controle de flow, filtragem de endereço de exportação) focado na eliminação de classes inteiras de vulnerabilidades, mas não tem sido alardeado ou recebido cobertura da imprensa, porque os detalhes técnicos são difíceis de digerir e não é tão interessante se a história não envolver algo explodindo. Esses recursos são normalmente opt-in e exigem fornecedores independentes de software (ISVs) para atualizar sua infraestrutura de compiladores e habilitar essas proteções.

Para dar um exemplo, podemos ver a taxa de segurança opt-in de vários sistemas operacionais graças ao pessoal da Cyber ITL. Em um mundo perfeito, os fornecedores poderiam apenas adquirir novos compiladores e apertar alguns botões, e tudo estaria protegido pelas melhores e mais recentes e tecnologias anti-exploits. A má notícia é que existem incompatibilidades de software e habilitar esses recursos exige uma quantidade significativa de testes para garantir que o software funcione – e voltamos à questão da adequada engenharia de software novamente.

Quando as atualizações atacam
Em uma recente conferência de segurança, a INFILTRATE 2018, Matt Tait (@pwnallthethings) discutiu a ideia de engenharia de software para facilitar as atualizações. A capacidade de promover uma atualização que tenha ampla adoção destrói vulnerabilidades antes que os agentes de ameaças tenham a chance de alterar suas ferramentas e usá-las na janela normalmente aberta entre a vulnerabilidade e a adoção do patch.

Infelizmente, essa capacidade de atualização é um convite a um problema diferente: a própria infraestrutura de atualização do software se torna um alvo para hacking, como vimos nos casos de NotPetya e MeDoc. Eu diria que é mais fácil defender esse grupo muito menor de máquinas do que defender as centenas de milhões de dispositivos que elas atendem, mas isso leva a uma pergunta interessante: os servidores de atualização de software devem ser considerados “infraestrutura crítica”?

Só porque os computadores funcionam em um mundo de binários não significa que nosso pensamento sobre eles também tenha que ser binário. É hora de nos afastarmos desses termos militares ao discutir segurança cibernética – ou enfrentar as consequências do mundo real.

Jeffrey Tang é pesquisador sênior de segurança na Cylance, focado em sistemas operacionais e pesquisa de vulnerabilidade. Ele iniciou sua carreira como Analista de Exploração e Vulnerabilidade de Redes Globais na Agência de Segurança Nacional dos EUA (NSA), onde conduziu operações de exploração de redes de computadores em apoio a requisitos de segurança nacional. Jeff completou seu Bacharelado em Ciências em Engenharia Elétrica e Ciência da Computação na Universidade da Califórnia, Berkeley e um Mestrado em Segurança de Computadores Offensive na Eastern Michigan University.

Comentar

Clique aqui para comentar

As opiniões dos artigos/colunistas aqui publicados refletem exclusivamente a posição de seu autor, não caracterizando endosso, recomendação ou favorecimento por parte da Infor Channel ou quaisquer outros envolvidos na publicação. Todos os direitos reservados. É proibida qualquer forma de reutilização, distribuição, reprodução ou publicação parcial ou total deste conteúdo sem prévia autorização da Infor Channel.