Vulnerabilidades da Wikipedia: lições aprendidas

No mês passado, pesquisadores do Vulnerability Research Group encontraram uma vulnerabilidade crítica na MediaWiki, a plataforma web de código aberto utilizada para criar e manter sites wiki, incluindo Wikipedia.org, o sexto site mais visitado no mundo.

Essa vulnerabilidade crítica deixou a plataforma MediaWiki (versão 1.8 em diante) exposta a ataques de execução de código remota (da sigla RCE, em inglês). Um invasor poderia ter usado essa vulnerabilidade para obter controle completo dos servidores web da Wikipedia,  expondo potencialmente 94 milhões de visitantes mensais com malware ou divulgação massiva de informação.

Assim que uma atualização e um patch foram emitidos para o software MediaWiki, a vulnerabilidade foi resolvida (desde que todos os usuários do MediaWiki instalassem o patch). No entanto, podemos tirar algumas lições úteis dessa falha.

Lição nº1: conheça a sua estrutura

A vulnerabilidade RCE foi apenas a terceira de seu tipo encontrada na plataforma open-source e de ampla utilização MediaWiki desde 2006. Isso é um bom histórico, mas demonstra a facilidade com que as organizações podem ser conduzidas a uma falsa sensação de segurança só porque uma vulnerabilidade ainda não foi detectada em meses ou até anos nas plataformas que utilizam.

Camadas de servidores de aplicativos da web expõem uma ampla superfície de software para um invasor em busca de uma vulnerabilidade. Mesmo as configurações mais mínimas, que normalmente sobrepõem um framework da web (por exemplo, o WordPress) com base em uma linguagem de plataforma (PHP) usando um banco de dados (MySQL) em um servidor web (Apache) ao longo de uma estrutura de sistema operacional. Qualquer um desses componentes pode ser um candidato ao ataque – e sequer  mencionamos a lógica do aplicativo personalizado de negócios, bibliotecas JS importadas, plugins, mods e outros. As oportunidades são abundantes.

Além de manter o radar ligado constanem busca de vulnerabilidades no lado do desenvolvimento, é mais importante do que nunca manter seu software atualizado. Verifique se você está executando as versões recentes do framework e serviços, rodando em cima de um sistema operacional moderno com técnicas de mitigação de explorações embutidas e outras proteções nativas habilitadas, ou olhando para a tecnologia de prevenção de ameaças. Melhores práticas recomendariam seguir os três passos, além das instruções do fornecedor.

Lição n º 2: a navalha de Occam ainda corta de verdade

Uma versão um pouco mais moderna do princípio lógico da Navalha de Occam é a expressão KISS (keep it simple, stupid). Ambos os axiomas são verdadeiros neste caso: a resposta mais simples é geralmente o caminho certo. Embora tenhamos visto um aumento constante de vetores de ameaça sofisticada, ameaças persistentes avançadas, violações de dispositivo móvel, ataques DDoS e até roubos online a bancos internacionais, os ataques relativamente simples, feitos através de vulnerabilidades como as descobertas na plataforma WikiMedia, ainda são muito uma ameaça real e comum.

E pior, algumas vulnerabilidades de validação de entrada tendem a passar despercebidas, pois as técnicas de exploração não são particularmente novas ou tecnicamente avançadas. Isto representa um alvo atraente, já que os agressores estão sempre procurando o caminho de menor resistência. É semelhante a colocar uma placa “Cuidado com o cão”, manter um cachorro grande no quintal, armar seu sofisticado sistema de proteção para casa com alertas móveis, trancar a porta da frente, fechar a porta traseira e, depois, deixar uma das janelas da frente aberta. Às vezes, esses pontos de entrada simples, óbvios, são os mais lucrativo para os criminosos – e os mais negligenciados por desenvolvedores e proprietários do site.

Lição n º 3: Não há nada como fortalecer a segurança

Até mesmo os sites mais confiáveis ??são suscetíveis a ataques de vulnerabilidade como este de RCE. Mas se você colocar proteções apropriadas no lugar, pode detectar e bloquear a infecção do código antes que ela se espalhe para os seus clientes e servidores. Não é prático bloquear o acesso dos funcionários da rede a todos os sites e, como este caso mostra, até mesmo os sites mais úteis e benevolentes podem hospedar códigos maliciosos.