Vulnerabilidade do Wordpress - CRITICO

[Jorge Marcelino]

27 minutos atrás, Thiago Santos disse:

Eu notei que nos sites com CloudFlare ativado, essa sobrecarga não acontece, com sucuri deve resolver também.

Isso porque possuem WAF, além disso sites que utilizam diretamente o Cloudflare não são detectados pela "varredura" do botnet.

Mas aqui o problema até o momento foi resolvido com WAF e ajustes no servidor.

[Fernando Ferenz]

28 minutos atrás, Thiago Santos disse:

Eu notei que nos sites com CloudFlare ativado, essa sobrecarga não acontece, com sucuri deve resolver também.

Sucuri resolve sim, ambos tem WAF, o problema disso tudo é que sem WAF + Cache o php processa tudo dnv ocasionando o load, mas o próprio WordPress n pode fazer nada é apenas um bruteforce acontece em qualquer sistema... Escolheram WP desta vez...

[RevendaHost]

Essa questão de ataque realmente tá enchendo o saco, hoje mais um servidor de cliente com o mesmo problema.

O fato de implementar o que foi sugerido pelo colega @LucianoZ e uma configuração antiga, eu mesmo implemento em todos os servidores que configuro para worpdress, porém é necessário dar permissão ao IP do cliente, se não for IP fixo vai acontecer o que o @Jorge Marcelino falou.

A um tempo atrás eu outro usuário abriu um post sobre algo do tipo, e eu recomendei fazer o que eu faço; mudar a url de login do wordpress, dessa forma eu não tenho problemas.

Já em relação a esse ataque que está sendo falado desde ontem, a primeira coisa que reparei é que quando o load do servidor sobe absurdamente, eu listo os processos em execução no servidor e são retornardos processos de varios sites ao mesmo tempo, apontando para wp-login.php, xmlrpc.php, admin-ajax.php e, inclusive, o index.php do wordpress. Não é apenas no wp-login, pelo menos aqui não foi.

Então rodei um script para verificar de quais IPs vem as tentativas de login no wordpress e para minha supresa a grande maioria vieram de dentro do próprio servidor. Procurando mais um pouco no servidor do cliente, vi que quando começa o load a subir e os processos apontando para os arquivos mencionados acima, existe um processo aberto por um arquivo chamdo bfe43c.php, encontrei ele em wp-includes/images/media/, seu codigo esta criptografado, deletei e parou o problema de "ataque". Depois voltou e encontrei outro arquivo com o mesmo código /wp-content/themes/twentyseventeen/mykrhzlf.php.

O problema é que nenhum antimalware ou antivirus encontrou esses arquivos, praticamente tiver que ficar esperando o load subir para só assim achar os processos rodando.

[chuvadenovembro]

12 horas atrás, brasilwebhost disse:

Pessoal quem não tem NGINX tenta usar esta regra no ModSecurity.

 

Editar o arquivo:
/etc/apache2/conf.d/modsec/modsec2.user.conf

Inserir:
SecRule REQUEST_HEADERS:User-Agent "python-requests" "id:3000001,phase:1,deny,status:402,log,t:lowercase,chain,msg:'blocked python-requests'"
SecRule REQUEST_FILENAME "wp-login.php"

Reiniciar serviço:
service httpd restart

 

Resolveu aqui.

 

Testei também, tem filtrado umas par de acessos, mas ainda está sobrecarregando o servidor.

[DELTA SERVERS]

Boa noite senhores,

Essa semana toda recebemos esses ataques visando acessos ao WordPress de nossos clientes e de clientes de servidores que gerenciamos, ataques do Brasil e exterior, veja um relatório básico..

Set 04 16:19:59 XXXXXXXXXXXX mod_evasive[860449]: Blacklisting address 40.77.167.126: possible DoS attack.
Set 04 16:20:17 XXXXXXXXXXXX mod_evasive[860449]: Blacklisting address 201.6.226.36: possible DoS attack.
Set 04 16:20:35 XXXXXXXXXXXX mod_evasive[860452]: Blacklisting address 187.180.95.121: possible DoS attack.
Set 04 16:20:59 XXXXXXXXXXXX mod_evasive[1315571]: Blacklisting address 179.217.66.217: possible DoS attack.

Estava sendo um grande número de endereços IP conectando-se constantemente ao wp-login.php de diversos clientes do seguimento WordPress. Eu notei que o agente do usuário é tipicamente "python-requests/2.18.4" implementei o bloqueio do agente.

Agora os ataques estão recebendo um retorno 403, acesso negado, em vez de serem passados para o WordPress. 

O ataque ainda está em andamento, mas como os pedidos devem ser negados muito mais rapidamente do que eram antes (já que eles não chegam ao WordPress), ele deve ter um impacto menor no apache por enquanto.

Infelizmente, é uma gama muito ampla de conexões de IP. Eu tenho visto 2239 endereços IP exclusivos participando deste ataque aos servidores. 

179.221.56.55 - [04/Set/2018: 16:21:18 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4" 
187.113.243.91 - [04/Set/2018: 16:21:20 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4" 
187.10.243.6 - [04/Set/2018: 16:21:54 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4"
177.158.0.84 - [04/Set/2018: 16:22:18 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4" 
170.254.208.27 - [04/Set/2018: 16:22:19 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4" 

O que foi feito?

Implementei o bloqueio do agente python-requests/2.18.4:

# Mitigação temporária de força bruta
SetEnvIfNoCase User-Agent "python-requests" bad_user
Deny from env=bad_user

Para reforçar, aplicamos o Pyxsoft Anti Malware e alguns clientes e outros configuramos o CSF com algumas regras.

Espero que esta informação tenha sido útil. 

[sabenada]

2 hours ago, JOSUEL ALVES said:

Boa noite senhores,

Essa semana toda recebemos esses ataques visando acessos ao WordPress de nossos clientes e de clientes de servidores que gerenciamos, ataques do Brasil e exterior, veja um relatório básico..

Set 04 16:19:59 XXXXXXXXXXXX mod_evasive[860449]: Blacklisting address 40.77.167.126: possible DoS attack.
Set 04 16:20:17 XXXXXXXXXXXX mod_evasive[860449]: Blacklisting address 201.6.226.36: possible DoS attack.
Set 04 16:20:35 XXXXXXXXXXXX mod_evasive[860452]: Blacklisting address 187.180.95.121: possible DoS attack.
Set 04 16:20:59 XXXXXXXXXXXX mod_evasive[1315571]: Blacklisting address 179.217.66.217: possible DoS attack.

Estava sendo um grande número de endereços IP conectando-se constantemente ao wp-login.php de diversos clientes do seguimento WordPress. Eu notei que o agente do usuário é tipicamente "python-requests/2.18.4" implementei o bloqueio do agente.

Agora os ataques estão recebendo um retorno 403, acesso negado, em vez de serem passados para o WordPress. 

O ataque ainda está em andamento, mas como os pedidos devem ser negados muito mais rapidamente do que eram antes (já que eles não chegam ao WordPress), ele deve ter um impacto menor no apache por enquanto.

Infelizmente, é uma gama muito ampla de conexões de IP. Eu tenho visto 2239 endereços IP exclusivos participando deste ataque aos servidores. 

179.221.56.55 - [04/Set/2018: 16:21:18 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4" 
187.113.243.91 - [04/Set/2018: 16:21:20 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4" 
187.10.243.6 - [04/Set/2018: 16:21:54 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4"
177.158.0.84 - [04/Set/2018: 16:22:18 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4" 
170.254.208.27 - [04/Set/2018: 16:22:19 -0300] "GET /wp-login.php HTTP / 1.1" 403 - "-" "python-requests/2.18.4" 

O que foi feito?

Implementei o bloqueio do agente python-requests/2.18.4:

# Mitigação temporária de força bruta
SetEnvIfNoCase User-Agent "python-requests" bad_user
Deny from env=bad_user

Para reforçar, aplicamos o Pyxsoft Anti Malware e alguns clientes e outros configuramos o CSF com algumas regras.

Espero que esta informação tenha sido útil. 

 

Josuel, é verdade, o agent é sempre o python-requests/2.18.4

foi o que bloqueamos via mod_security e com isso não dá retorno a botnet.

e sim, são muitos IP's, chego a pensar se o desocupado não achou uma forma de fazer spoof dos IP's de origem, usando vários ranges brasileiros. 

[LucianoZ]

Recentemente até mesmo gringos pelo mundo a fora estão reclamando do problema do wp-login, achei um link interessante de modsegurity
https://www.liquidweb.com/kb/wordpress-modsecurity-rules/

Espero que seja útil a quem esta com muitos problemas ainda.

[caiocaz]

9 horas atrás, sabenada disse:

 

Josuel, é verdade, o agent é sempre o python-requests/2.18.4

foi o que bloqueamos via mod_security e com isso não dá retorno a botnet.

e sim, são muitos IP's, chego a pensar se o desocupado não achou uma forma de fazer spoof dos IP's de origem, usando vários ranges brasileiros. 

Como fez seu bloqueio? compartilha conosco, estou tendo o mesmo problema.

[Jorge Marcelino]

24 minutos atrás, brasilwebhost disse:

Como fez seu bloqueio? compartilha conosco, estou tendo o mesmo problema.

Você só irá amenizar o problema com WAF e ajustes diretamente no servidor. Não há mágica, ontem foram mais de 8 mil IPs bloqueados em nossa proteção na nuvem. Os IPs que estão atacando (agents python) são detectados e descartados a conexão, então é capturado os IPs e enviados para a nuvem, assim o WAF já bloqueia antes mesmo de chegar no servidor e não ocorre sobrecarga alguma.

Editado Setembro 6, 2018 por Jorge Marcelino

[sabenada]

7 hours ago, LucianoZ said:

Recentemente até mesmo gringos pelo mundo a fora estão reclamando do problema do wp-login, achei um link interessante de modsegurity
https://www.liquidweb.com/kb/wordpress-modsecurity-rules/

Espero que seja útil a quem esta com muitos problemas ainda.

Bom dia.

O problema de ataque a brute-force no wordpress já tem muitos anos. Este tipo de ataque é comum, lidamos com ele diariamente.

A diferença agora, é que existe uma botnet brasileira, fazendo ataques diários e com muitos IP's de origem.

A técnica é a mesma de anos atrás.

34 minutes ago, brasilwebhost said:

Como fez seu bloqueio? compartilha conosco, estou tendo o mesmo problema.

Como fiz:

WHM como root -> mod_security tools -> RULES LIST -> ADD RULE

no campo RULE TEXT

 

SecRule REQUEST_HEADERS:User-Agent "(python-requests)" \
    "id:123457,phase:1,t:none,t:lowercase,block,tag:BOT,msg:'botnetBR blocked'"

 

Abaixo marque as duas caixas "Enable Rule"  e "Deploy and Restart Apache"

A partir disso o mod_security vai impedir que esta botnet acesse arquivos no servidor.  Mas isso não bloqueia o acesso da botnet ao servidor, a carga vai continuar alta. Porém ajuda a proteger seus clientes e desestimula a botnet.