Resolvendo o problema de segurança do “TimThumb” do WordPress

Buenas pessoal,

Nos últimos dias vim acompanhando as estatísticas de acesso do meu blog percebi que o relatório do plugin WP-Statistics não batia com o relatório do Google Analytics, havia uma grande diferença e havia um ar de ‘existe algo podre nesta podridão’ e começei a investigar melhor o que poderia ser. Depois de alguns dias tentando verificar diversas possibilidades sem sucesso recebo um e-mail da Locaweb falando sobre a carga de memória usada na VM, era o ponto final para descobrir logo o que estava rolando com a instalação do WordPress ou qualquer outro site que está hospedado lá.

Antes de tudo fiz um backup completo para que no caso de qualquer B.O eu pudesse retornar ao estado original : ), assim fui indo removendo e desativando todos os plugins que eu havia instalado, embora que nenhum dos que instalei tivessem aviso de não homologação pela WordPress. Depois de feito isto, lembro que tive um pico de acessos com aproximadamente 14.000 visitas em dois dias, isto em um sábado e domingo, dias onde geralmente o tráfego do site é praticamente inexistente.

Na última quarta-feira (26/09/2012) percebi que o layout da página quebrou, achei inicialmente que fosse algum CSS ou Javascript com problemas, logo vendo pelo console do Google Chrome vi que era um JS com problema. Foi aí que tive uma surpresa, ao olhar o código da página percebi que havia uma tag ‘iframe’ no início da página, e que ao inspecionar o seu conteúdo, ela era a origem do erro que bugava o visual do meu site.

Foi claro o problema de que algum script malicioso fez alguma injeção de código e ‘implantou’ aquele iframe no(s) arquivo(s) ‘.php’ do blog. Ao procurar a origem do problema, usei o próprio editor interno do WordPress para arquivos CSS e PHP, e para surpresa achei este hash de criptografia base_64:

Este cara ao ser passado para a função eval do PHP se tornava este mosntrinho aqui:

Não cheguei a ver a execução deste script, mas pelo monitoramento que fiz, o mesmo era executado diariamente as 08:26 horas da manhã e o seu resultado era um arquivo com um hash como nome, algo como ‘9cah3j1930f0cm4n4‘ contendo diversos endereços de IPs iniciados em 186.x.x.x. Nenhum deles estava ativo nos testes, acredito que poderiam ser IPs de máquinas zumbis ou coisa do tipo.

O problema

Depois de algumas pesquisas sobre este script e a URL do iframe, descobri que o problema é causado por um script bem conhecido de quem utiliza o WordPress, o “TimThumb.php” ou apenas TimThumb. Este cara é uma implementação para o tratamento de imagens feito em PHP muito usado em templates para WordPress, e, logo, no entanto, toda via, o template (Aggregate) do meu site também usava este cara.

O TimThumb.php por é funcional, faz o que tem que fazer, mas possui falhas de segurança graves em algumas versões, como no caso da 1.18 que era a utilizada pelo template quando eu instalei o mesmo.

A solução

Primeiramente analisei todos os arquivos referentes aos uploads feitos em busca de arquivos provenientes de hashs aleatórios, em seguida fiz a reinstalação do WordPress através da opção existente na própria administração do CMS. E por último achei o plugin Vulnerability Scanner que busca por arquivos problemáticos com base em um catalogo de problemas relatados.

Este plugin acabou salvando o meu template, logo porque o mesmo aponta os scripts problemáticos e propõe a instalação de versões mais recentes e/ou a aplicação das correções necessárias aos mesmos. Isso eu até registrei na imagem abaixo ; )

Timthumb Vulnerability Scanner in action.

Timthumb Vulnerability Scanner in action.

Só pra me assegurar eu fechei a escrita dos arquivos pelo Apache exceto na pasta de upload dele:

Beleza, acho que por enquanto tudo está na calmaria por aqui novamente.

Abraços e até a próxima.

Blog Linux