AMD leva quatro meses para corrigir falha de MITM em atualizador e frustra pesquisador de segurança
Uma falha grave no atualizador de software da AMD deixou milhões de usuários vulneráveis a ataques do tipo “homem-no-meio” (MITM) durante pelo menos quatro meses. O problema estava na forma como o aplicativo de atualização da fabricante baixava arquivos: em vez de utilizar uma conexão criptografada segura, o programa recorria ao protocolo HTTP simples, abrindo espaço para que invasores interceptassem e alterassem o conteúdo transferido.
A vulnerabilidade foi identificada por um programador neozelandês, que se apresenta sob o pseudônimo de MrBruh. Ele descobriu, em fevereiro, que o software oficial da AMD fazia download de componentes de atualização sem qualquer proteção criptográfica na camada de transporte. Em 6 de fevereiro, o pesquisador reportou o caso na plataforma de bug bounty utilizada pela empresa, esperando que o problema fosse tratado como uma falha de segurança séria.
A resposta foi decepcionante: no mesmo dia, a plataforma comunicou que vulnerabilidades envolvendo ataques MITM não estavam cobertas pelo programa de recompensas da AMD e encerrou o relatório. Em outras palavras, a fabricante não apenas recusou pagar qualquer recompensa, como também, naquele momento, não sinalizou urgência ou gravidade na correção.
Do ponto de vista técnico, a falha era relativamente simples, mas com potencial de impacto enorme. Como os arquivos de atualização eram transferidos em HTTP, um invasor na mesma rede local – por exemplo, em um Wi-Fi público, corporativo mal segmentado ou até mesmo em uma rede doméstica comprometida – poderia interceptar o tráfego, modificar os arquivos em trânsito e injetar malware no lugar dos componentes legítimos. O mesmo valia para alguém com acesso a infraestrutura de provedor de internet.
Segundo o próprio pesquisador, um ataque MITM nesse contexto seria trivial de executar para qualquer pessoa com conhecimento intermediário em redes. Bastaria manipular o tráfego de saída do atualizador da AMD, apontando o download para um servidor controlado pelo atacante, que devolveria um arquivo malicioso com o mesmo nome esperado pelo programa. Sem checagens criptográficas adequadas, o software aceitaria o pacote comprometido como válido e o executaria, potencialmente permitindo a tomada de controle do sistema.
Inconformado com a forma como o caso foi tratado, MrBruh decidiu publicar um artigo técnico em seu blog, detalhando a vulnerabilidade. O texto rapidamente chamou atenção, gerando forte repercussão em fóruns especializados em segurança da informação. No dia seguinte à publicação, a AMD entrou em contato com o pesquisador, afirmando que estava investigando o problema e solicitando a remoção do conteúdo.
O programador atendeu ao pedido da empresa e retirou a postagem do ar. Hoje, porém, ele admite que considera essa decisão um erro em retrospectiva. Na avaliação dele, a retirada do texto reduziu a pressão pública para que a correção fosse aplicada com rapidez e transparência. Enquanto isso, usuários continuaram expostos, sem saber que o próprio mecanismo de atualização do fabricante poderia ser explorado como vetor de ataque.
De acordo com o relato do pesquisador, a AMD foi clara ao afirmar que não haveria qualquer tipo de compensação financeira pelo achado, mesmo após reconhecer a necessidade de correção. A companhia prometeu lançar uma atualização do software e creditar formalmente a descoberta ao pseudônimo de MrBruh. Para a comunidade de segurança, o episódio reacende o debate sobre o equilíbrio entre programas de bug bounty, valorização do trabalho de pesquisadores independentes e responsabilidade das empresas em corrigir falhas críticas de forma célere.
Em comunicação posterior, a AMD declarou que passaria a verificar a assinatura digital das atualizações, reforçando o processo de validação dos arquivos baixados. No entanto, ao analisar a nova versão do atualizador, o pesquisador diz ter constatado que a realidade era bem diferente do discurso. Em vez de uma verificação criptográfica robusta, o software realizava apenas um cálculo de CRC-32 sobre o arquivo baixado.
O CRC-32, apesar de útil como checagem de integridade para detecção de erros acidentais de transmissão, não é um mecanismo de segurança. Ele não oferece proteção contra modificações intencionais: um invasor com controle sobre o arquivo pode facilmente recalcular o CRC e fornecer um valor correspondente, enganando a verificação. Para segurança de atualizações, o padrão mínimo aceitável envolve o uso de assinaturas digitais baseadas em criptografia assimétrica, como RSA ou ECC, com verificação de certificados confiáveis e, idealmente, comunicação por HTTPS com validação rigorosa do servidor.
É justamente nesse ponto que a crítica de MrBruh ganha força. Para ele, simplesmente migrar o download para HTTPS, sem implementar validação criptográfica robusta e sem proteger adequadamente toda a cadeia de atualização, é uma resposta incompleta. Em cenários mais sofisticados, em que a infraestrutura de rede ou de certificado possa ser comprometida, somente a combinação de transporte seguro com assinaturas digitais fortes garante que o usuário esteja recebendo, de fato, código legítimo da AMD.
O caso também evidencia como componentes aparentemente simples, como “apenas” um atualizador, podem se tornar uma superfície de ataque valiosa. Atualizadores têm privilégios elevados no sistema e são confiados pelo usuário e pelo próprio sistema operacional. Quando um atacante consegue se infiltrar nesse mecanismo, o caminho para instalar rootkits, ransomwares ou outras pragas complexas se torna muito mais fácil. É por isso que as grandes fabricantes normalmente investem tanto em cadeias de atualização assinadas, com chaves bem protegidas e verificações múltiplas.
Do lado do usuário final, situações como essa levantam a pergunta inevitável: o que fazer para se proteger quando até o software oficial do fabricante se mostra vulnerável? Algumas práticas ajudam a reduzir riscos. Uma delas é evitar, sempre que possível, o uso de conexões Wi-Fi públicas para tarefas sensíveis, incluindo instalação de drivers e atualizações de firmware. Outra é manter um bom antivírus e soluções de proteção em tempo real ativas, capazes de inspecionar arquivos baixados, mesmo que venham de fontes consideradas confiáveis.
Além disso, é recomendável que empresas e usuários mais avançados controlem de perto quais atualizadores automáticos estão rodando nas máquinas. Em ambientes corporativos, muitas organizações preferem centralizar o processo de atualização de drivers e sistemas em servidores internos, validando os pacotes previamente, em vez de permitir downloads diretos pela estação de trabalho. Esse tipo de abordagem, ainda que mais complexa de administrar, reduz a superfície de ataque aberta por mecanismos automáticos mal protegidos.
O episódio com a AMD também serve de alerta para o próprio setor de tecnologia. Fabricantes de hardware e software, especialmente aqueles que fornecem drivers, BIOS, firmware e outros componentes de baixo nível, precisam tratar sua infraestrutura de atualização como um ativo crítico de segurança. Isso implica, entre outros pontos, adotar padrões modernos de criptografia, realizar auditorias recorrentes em seus protocolos, desenvolver programas de bug bounty transparentes e, principalmente, responder com agilidade e clareza quando uma vulnerabilidade é reportada.
Outro aspecto sensível é a relação com pesquisadores independentes. A experiência de MrBruh mostra como uma comunicação falha e a recusa em reconhecer o valor de uma descoberta podem gerar desgaste de imagem e desconfiança. Ao desestimular quem aponta falhas de boa-fé, as empresas correm o risco de afastar justamente aqueles que ajudam a tornar seus produtos mais seguros. Uma política de disclosure responsável, com prazos claros, reconhecimento público e, quando cabível, recompensas financeiras justas, não é apenas uma questão de “boa vontade”, mas de estratégia de segurança.
Para o público em geral, a lição que fica é a de que a segurança digital é um processo contínuo, e não um estado estático. Mesmo grandes marcas, com enorme presença no mercado, estão sujeitas a cometer erros básicos, como usar HTTP em pleno 2024 para distribuir atualizações críticas. Por isso, acompanhar notícias de segurança, aplicar atualizações assim que forem disponibilizadas e adotar uma postura desconfiada – mesmo em relação a softwares “oficiais” – são atitudes essenciais em um cenário de ameaças cada vez mais sofisticadas.
Em última análise, o caso da falha de MITM no atualizador da AMD expõe uma combinação perigosa: demora na correção, comunicação pouco transparente e soluções técnicas aquém do esperado. Para uma indústria que depende da confiança do usuário para operar em larga escala, episódios assim são um lembrete contundente de que segurança não pode ser tratada como um detalhe de implementação, mas como parte central do projeto de qualquer produto ou serviço digital.