Francisco Jr

Saudações,

2019 começou agitado! Em menos de dois meses eu peguei dois clientes e suas instalações de WordPress invadido.

E algo me diz que mais sites aparecerão infectados, pois, até a data deste post, 33.4% dos sites são feitos em WordPress.

Entretanto, não desanime. Me permita fazer uma "acho analogia": empresas como a Sony, Forbes... a Casa Branca... usam e não reclamam do WordPress. O que tem acontecido nos últimos dias, acho eu, que seja algo parecido com o Windows, Linux, MacOS... um programa OpenSource ou Proprietário está com falhas, este permite a invasão e quem leva a "fama" é o Sistema Operacional.

Desinfectando sites WordPress invadidos

Este post não tem a menor intenção de ser um guia definitivo. Use-o apenas como um "ponta pé" inicial para sanar o seu problema. Este foi o caminho que eu escolhi; exitem  outros.

Primeiro, via FTP, eu baixei o site, e pelo phpMyAdmin o seu banco de dados. Depois, com o usuário shell em mãos, eu ascendi à pasta web do site, neste caso a public_html, e executei os seguintes comandos:

Corrigindo os permissões dos arquivos e pasta...

$find ./ -type f -exec chmod 644 {} \;
$find ./ -type d -exec chmod 755 {} \;

Abra o arquivo .htaccess para edição...

$vi .htaccess

Dentro dele coloque as seguintes diretivas...

# DESATIVA LISTAGEM DE DIRETORIO
Options -Indexes

# https://kb.sucuri.net/warnings/hardening/http-trace
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{REQUEST_METHOD} ^TRACE
 RewriteRule .* - [F]
</IfModule>

<IfModule mod_headers.c>
 # https://kb.sucuri.net/warnings/hardening/headers-x-content-type
 Header set X-Content-Type-Options nosniff
 # https://kb.sucuri.net/warnings/hardening/headers-x-frame-clickjacking
 Header always append X-Frame-Options SAMEORIGIN
 # https://kb.sucuri.net/warnings/hardening/headers-x-xss-protection
 Header set X-XSS-Protection "1; mode=block"
</IfModule>

# https://codex.wordpress.org/Hardening_WordPress
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /
 # DEIXE COMENTADO QUANDO USAR O DUPLICATOR
 RewriteRule ^wp-snapshots/ - [F,L]
 RewriteRule ^wp-admin/includes/ - [F,L]
 RewriteRule !^wp-includes/ - [S=3]
 RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
 RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
 RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

# NEGA ACESSO DIRETO AO...
<FilesMatch "(wp-config|xmlrpc)\.php$">
 order allow,deny
 deny from all
</FilesMatch>

# NEGA ACESSO SE INICIADO COM PONTO
<files ~ "^\..*">
 order allow,deny
 deny from all
</files>

Proteja o diretório upload criando um .htaccess...

$vi wp-content/uploads/.htaccess

Com o conteúdo...

# https://codex.wordpress.org/Hardening_WordPress
<Files ~ "\.ph(?:p[345]?|t|tml)$">
 deny from all
</Files>

Isto foi apenas a preparação. eheheh Agora vamos para a "brincadeira".

Com o comando egrep procure por alguns padrões...

$egrep -r '@include "\\' ./

Você deve ver uma saída do tipo...


Remova, de cada arquivo localizado, a linha que casa com o padrão pesquisado!

Execute...

$egrep -r "\\\$[a-z]+ = .*;\\\$[a-z]+ = Array" ./

Exemplo da saída...


Aqui eu peguei o caso dos arquivos de nomes aleatórios. Usando a opção -l no egrep podemos pegar apenas os nomes dos arquivos; no meu caso foram:

./wp-includes/js/tinymce/langs/xhwvkpvd.php
./wp-includes/ID3/brfoxngy.php
./wp-content/endurance-page-cache/-/-/mjoiuhex.php
./wp-content/uploads/2018/xbcycrbw.php
./wp-content/plugins/members/templates/xgwvimjf.php
./wp-content/plugins/admin-menu-editor/lajpjcjr.php

Apague todos os aquivos de nomes aleatórios que o comando retornou para você.

Você pode usar o comando xargs para agilizar a tarefa de remoção!

Agora execute...

$egrep -r "\\\$_[a-z0-9]+ = basename\/" ./

Minha saída foi...


Como você pode ver, temos um arquivo PHP disfarçado de .ico, e com o seu nome iniciando com ".", ou seja, para um sistema Unix Like não basta apenas um ls para listar os arquivos, mas, um ls -a para que o mesmo liste também os arquivos ocultos.

Nas instalações de WordPress que eu peguei, havia mais de um arquivo deste tipo! Se for este o seu caso, apague todos o arquivos .ico que contem comandos PHP.

Execute...

$egrep -r "eval\/\*[a-z]+\*\/\([a-z]+\(\\\$" ./

Saída...


Aqui em encontrei e apaguei apenas o arquivo kptgwxby.php; este de nome aleatório.

Como penúltimo comando, execute...

$egrep -r "\[\\\$[a-z]+ % strlen\(\\\$[a-z]+\)\]" ./

Saída do comando...


Mais um arquivo de nome aleatório que pode, e vede ser apagado.

E para finalizar com o uso do egrep, execute...

$egrep -r 'dgreusdi' ./

Saída que eu obtive...


Arquivos de nomes aleatórios? Apague!

WordFence e o Quttera

Pergunta: Por que você não usou um plugin de segurança como o WordFence e o Quttera para iniciar a limpeza?

Resposta: Porque depois de instalado ambos os plugins, nem um deles iniciava a checagem do sistema. O infecção impedia a execução de ambos.

Para ser mais exato, em uma das instalações, o wp-load.php estava infectado. Com isto o WordFence, por exemplo, retornava uma mensagem que o Scan tinha recebido um comando stop. Já o Quttera aparentemente iniciava o processo de verificação, contudo ficava "eternamente" procurando e não mostrava nada nos logs.

Depois de limpar o wp-load.php, eu reinstalei manualmente ambos os plugins, e este funcionaram corretamente.

Bem, se você chegou até aqui, eu acredito que agora você, assim como eu, já pode terminar a limpeza com a excelente ajuda do WordFence e do Quttera.

Verificação online

Use o inspetor de elementos do seu navegador e também use os links abaixo para ver exatamente o que o seu site está carregando quando é acessado.

• hackertarget.com/wordpress-security-scan
• urlquery.net
• webpagetest.org

Use o comando diff

Como um desencargo de consciência, eu baixei do wordpress.org a mesma versão do WordPress instalada, e usei o comando diff para comparar os arquivos; por exemplo:

$diff --brief -r /tmp/wordpress/ public_html/

Only in public_html/: favicon.ico
Only in public_html/: .htaccess
Only in public_html/: .htaccess.bkp
Files /tmp/wordpress/license.txt and public_html/license.txt differ
Only in public_html/: robots.txt
...

Uma conferida aqui e outra ali... tudo certo... site limpo!

Ah! Eu também modifiquei as permissões de alguns arquivos para 444, atualizei alguns plugins e desativei outros que não estavam em uso, desativei o acesso ao /wp-json para usuários não autenticados e ativei um captcha no /wp-admin. Usei algumas RegExp na consulta ao banco de dados para localizar alguma infecção, mas não encontrei nada de errado.

Caso você mesmo queira fazer uma auditoria no seu site WordPress, use a ferramenta WPScan. Esta pode ser baixada no site wpscan.org. Se você usa  o Kali Linux, este já traz a ferramenta instalada e pronta para o uso; confira youtube.com/results?search_query=kali+linux+wpscan.

Bibliografia

1. stopbadware.org/webmaster-help
2. aw-snap.info
3. aw-snap.info/articles/spam-hack-wordpress.php
4. wordpress.org/support/article/changing-file-permissions
5. codex.wordpress.org/FAQ_My_site_was_hacked
6. codex.wordpress.org/Hardening_WordPress
7. sucuri.net/guides/how-to-clean-hacked-wordpress
8. etalented.co.uk/recover-hacked-wordpress-website
9. blog.laserphile.com/2018/11/removing-persistent-backdoor-on.html ( Brother, what incredible post! )
10. secure.wphackedhelp.com/blog/wordpress-malware-redirect-hack-cleanup