Wikipédia Em Alerta Um Gusano Que Se Replica Al Modificar Scripts De Utilizador

Esta manhã, a comunidade Wikimedia e milhares de usuários ao redor do mundo despertaram-se com uma notícia inquietante: um programa malicioso que se autorreplicaba chegou a ser executado dentro da infraestrutura dos projetos e começou a inserir código oculto e a modificar scripts de usuários em múltiplos wikis. Os primeiros avisos vieram do Village Pump Na Wikipédia, onde editores detectaram uma onda de edições automáticas que adicionaram fragmentos de JavaScript invisível e vandalismo em páginas aleatórias.

O que aconteceu, explicado em termos simples: MediaWiki — o software que move a Wikipédia e centenas de wikis relacionadas — permite que tanto os administradores como os editores registrados carreguem pequenos arquivos JavaScript para personalizar a experiência do site. Estes ficheiros podem ser globais (por exemplo,MediaWiki:Common.js) ou específicos de cada utilizador (por exemplo,User:Nome/common.js). O problema é que, se um ator malicioso conseguir que um código seja executado com privilégios de edição, você pode alterar esses arquivos e provocar que o código seja executado nos navegadores de outros usuários, propagando assim a infecção.

Segundo o registro público de seguimento do incidente no sistema de incidências da Wikimedia Foundation ( Phabricator), a cadeia de eventos parece ter sido iniciada quando um programa hospedado na Wikipédia em russo foi invocado e, daí, um programa global com código prejudicial foi modificado. Uma cópia arquivada do programa problemático está disponível na memória web: ficheiro do teste.js.

Mecanismo de propagação: o programa malicioso trabalhava em três frentes simultâneas. Primeiro tentava adicionar um “loader” no arquivo de JavaScript pessoal do usuário que o teria executado, de modo que a próxima vez que esse usuário navegaria conectado, carregaria o código prejudicial do seu espaço pessoal. Segundo, se esse usuário dispunha das permissões adequadas, o script tratava de modificar oMediaWiki:Common.jsglobal para que o código seja executado para todos aqueles que usem esse programa partilhado. E terceiro, o worm incluía uma rotina de vandalismo que escolhia páginas aleatórias (através de Special:Random) para inserir uma imagem e um bloco oculto que carregava o código externo de um URL maliciosa.

A combinação destes três vectores é o que torna o incidente particularmente perigoso: um único navegador afetado pode se tornar semente para uma infecção que se replica em outros usuários e, se atingir o programa global, em todo o projeto.

As primeiras análises públicas replicadas pela mídia de segurança indicam que o verme chegou a modificar milhares de páginas e dezenas de scripts do usuário. A contagem provisória que circulou situa as edições em torno de 3.996 páginas afetadas e cerca de 85 usuários que viram seucommon.jsSobreescrito. Durante a resposta imediata, a equipe técnica da Fundação limitou temporariamente a possibilidade de editar em vários projetos para parar a propagação enquanto revertiam mudanças e limpavam referências ao código injetado.

Durante a fase de contenção, o pessoal da Fundação também realizou restaurações massivas docommon.jsde vários usuários e “suprimiu” as páginas modificadas para que as mudanças maliciosos não ficassem visíveis nas histórias públicas. No momento em que isto é escrito, o código injectado foi removido e a edição foi restabelecida, mas subsistem dúvidas fundamentais: a Fundação ainda não publicou um relatório post incidente detalhado que clarifique como o script foi executado exatamente e se a execução foi acidental, fruto de um teste, ou resultado de uma conta comprometida.

Por que este incidente nos deveria preocupar: além do vândalismo, um verme desse tipo tem implicações de segurança sérias. Pode servir como vetor para roubar tokens de sessão, realizar ações em nome dos usuários afetados, introduzir links ou scripts que redirecionam servidores externos para fins de rastreamento ou carga de malware, e minar a confiança no conteúdo dos projetos. Além disso, a natureza distribuída e aberta da Wikipédia complica as medidas automáticas de defesa: muitas proteções são construídas sobre a confiança entre editores e controles manuais que requerem horas de trabalho humano.

Também é relevante o fato de que o script abrigava código que o vinculava com campanhas anteriores, o que sugere que não se tratou de um experimento inofensivo, mas de um padrão que foi visto antes no ecossistema wiki, segundo relatos que têm rastreado scripts similares em outros incidentes.

O que os usuários podem fazer agora: se você tiver editado wikis da Wikimedia recentemente e corre o risco de ter carregado o script, verifique sua página de usuário (especialmenteUser:Nome/common.js), elimina qualquer código suspeito e restabelece scripts oficiais desde cópias de confiança. Considera mudar as senhas e activar a autenticação de dois fatores quando estiver disponível. A documentação técnica do MediaWiki sobre JavaScript do usuário é um bom ponto de partida para entender quais arquivos podem ser executados no seu navegador: Manual: JavaScript (MediaWiki).

Para a comunidade e os mantenedores do software, o episódio deve impulsionar uma reflexão profunda sobre a necessidade de controles adicionais em torno das páginas que executam código nos navegadores dos editores: revisão obrigatória de mudanças em scripts globais, melhor telemetria para detectar cargas invulgares, e processos mais rigorosos para executar e testar scripts em ambientes isolados antes de os ativar ao vivo.

Transparência e lições pendentes: a resposta técnica imediata deteve a propagação, mas a ausência de um relatório técnico completo dificulta saber se houve acesso não autorizado a contas de pessoal, se falta melhorar as permissões e processos de teste interno, ou se há vulnerabilidades em ferramentas de edição que devem ser corrigidas. A comunidade merece uma investigação pública e documentada que explique as causas raiz e as medidas correctivas propostas. Entretanto, ferramentas de terceiros e meios especializados e BleepingComputer publicaram análises preliminares que ajudam a contextualizar o ataque, e o registro de incidências em Phabricator serve como fonte primária para o seguimento por técnicos e voluntários.

Este incidente lembra que, em projetos abertos e colaborativos de grande escala, a segurança não é apenas responsabilidade dos administradores, mas sim um esforço coletivo: protocolos claros para testes internos, auditorias de código, procedimentos de resposta e comunicação transparente são componentes imprescindíveis. A comunidade, os desenvolvedores e a Fundação devem trabalhar juntos para fechar as lacunas e restaurar a confiança.

Se você participa como editor em qualquer wiki da Wikimedia e detectar comportamentos estranhos – redesseções inesperadas, scripts escondidos em suas páginas de usuário, edições massivas não autorizadas –, não hesite imediatamente nos canais de suporte técnico da comunidade (por exemplo, Village Pump) e segue as diretrizes oficiais que publica a Fundação. Para acompanhar a pesquisa e os anúncios oficiais, consulte o acompanhamento em Phabricator e a página de estado da Wikimedia status.wikimedia.org.

A história não termina com a eliminação do código: fica a ver o relatório pós- incidente, as medidas concretas que adotar a Fundação e como evoluirão as práticas de segurança em uma das plataformas colaborativas mais visitadas do planeta. Entretanto, a lição é clara: na web aberta, a confiança deve ser acompanhada de controles técnicos e processos que minimizem o impacto de falhas e maus atores.