Dois passos a seguir se você for atacado por um hack eval(base64

Para minha mais completa infelicidade, encontrei esta semana indícios de que eu — e este humilde blog —continuamos a ser vítimas de ataques de uma página de bloqueio do Google, informando que o site é inseguro. Daí precisei tomar uma série de medidas, entre as quais estas que estão descritas aqui, para recuperar tudo. Para que isso não aconteça com você, é importante examinar seu site periodicamente, tal como quando executamos anti-vírus em nossos computadores. Dois plugins que podem ser úteis neste caso são o Exploit Scanner e o Antivirus, sendo que confesso que prefiro o primeiro, por sua riqueza de informações. Também pode ser uma boa ideia utilizar o Sucuri Site Check, que informa a situação atual do seu site sob o ponto de vista de diversos sites especializados (há um plugin para WordPress que traz esta varredura para dentro do painel de administração, também).

Bom… se você, assim como eu, se deparar com alguma evidência de ataque, ou, no mínimo, com algum sintoma suspeito, pode seguir dois passos simples. Mas aviso que será necessário se munir de toda a paciência possível e fazer aquilo que eu acredito que seja a única opção plausível em uma situação destas: Executar alguns comandos diretamente no servidor via Putty. Para continuar a escrever este texto, assumirei que você já possui o Putty, ou outra ferramenta similar para o processo, e usarei minha própria experiência aqui no site como base.

Primeiro passo: Acabe com os arquivos world-writable

Antes de qualquer coisa, dado que fazia um boooooom tempo que eu não acessava minha conta e meus arquivos hospedados, resolvi dar uma olhada para ver se alguma de minhas pastas era, digamos, world-writable — ou seja, será que alguém do mundo exterior conseguiria alterar meus arquivos? Isto seria um enorme pecado. Para descobrir isso, já conectado ao servidor, executei a seguinte instrução:

find . -type d -perm -o=w

E, não é que, infelizmente, encontrei find . -type d -perm -o=w -print -exec chmod 770 {} \;

Segundo passo: Detecte quais são as infecções e as elimine

Dado que já suspeitava de que haviam arquivos vitimados com script injection, resolvi que seria importante saber quais eram os infectados. Arquivos infectados com script injection possuem linhas em seu conteúdo — geralmente no topo do arquivo, no final do arquivo, ou logo após a abertura da tag <html> — que se assemelham ao seguinte:

<!--?php /**/ //eval(base64_decode("aWYoZnVuY3Rpb25fZ....

Um comando útil para listar que arquivos são os que contém o script injection é o seguinte:

grep -lr --include=*.php "eval(base64_decode" /caminho/do/seu/servidor

Se o output deste comando for diferente de nulo, como foi no meu caso, com mais de mil arquivos listados, pode ter certeza de que há script injection na parada. Mas não há problema, você pode se livrar desses arquivos facilmente. Basta executar um pequeno script de uma linha em perl — através da própria sessão aberta via telnet:

for f in `find . -name "*.php"`; do perl -p -i.bak -e 's/<\?php \/\*\*\/ eval\(base64_decode\(\"[^\"]+"\)\);\?>//' $f; done

O resultado deste script será a eliminação de todas as linhas, em todos os arquivos com extensão php, do trecho de código inserido através do script injection. O processo gerará arquivos de backup como resultado — vários arquivos com a extensão bak. Isso porquê, se algo der errado e você find . -type f -name "*.bak" -exec rm -f {} \;

Finalmente… uma faxina!

A etapa final, como eu a fiz, consistiu de passar um bom tempo dando uma olhada nos diretórios hospedados em cada um dos meus sites. Arquivos muito antigos foram para o beleléu — acreditem ou não, o que ocorreu no meu caso foi uma vulnerabilidade causada por um plugin de galeria de fotos esquecido há anos dentro do meu servidor — e tudo aquilo que eu julgava não saber do que se tratava, também (CUIDADO). Além disso, sempre vale dizer que é imporante resetar suas senhas. Todas. Agora.