CVE-2018-6389 PoC node js multisite with proxy

Este script é baseado no CVE-2018-6389, um problema bastante traiçoeiro do WordPress que, infelizmente, provavelmente não será corrigido pela equipe que desenvolve a plataforma, apesar de ser conhecido há bastante tempo.

!!! IMPORTANTE ANTES DE CONTINUAR !!! Todo o repositório e as informações compartilhadas aqui são livres para uso sob qualquer forma - copiar, aprimorar, modificar com o objetivo de aprimorar ou para outros fins, bem como compartilhar. O uso das informações compartilhadas para fins que não sejam educacionais, para experimentos e/ou para proteger a sua própria plataforma baseada em WordPress provavelmente está em conflito com várias leis que desconheço. Não use o script para atacar sites! Não me responsabilizo pelas suas ações. Ao usá-lo, você concorda com estes termos. Um ataque DDoS (negação de serviço) direcionado a um site que não é seu pode ser considerado um ataque terrorista. !!! CERTIFIQUE-SE DE QUE ESTÁ ABSOLUTAMENTE SEGURO DE SUAS AÇÕES E PENSE BEM ANTES DE CONTINUAR !!!

Escrevi este script há muito tempo, mas como sei que você é muito legal, decidi compartilhá-lo com você. Use-o para o que ele foi feito! Sério...

Do que se trata

Na internet há muita informação sobre o assunto, assim como vários scripts prontos, na maioria escritos em Python, como o Shiva e este, dos quais tirei bastante inspiração para escrevê-lo, e com os quais você também pode testar essa "fraqueza" em um ambiente isolado, mas como eu sou um "curioso", decidi acrescentar alguns "mimos".

Aqui pode ler um blog interessante sobre o tema.

Em resumo, se você carregar https://your-wordpress-site.com/wp-admin/load-scripts.php?c=1&load=editor,common,user-profile,media-widgets,media-gallery (mudando, claro, o link para que aponte para a sua instância) e o que aparecer na tela for "um js qualquer, cara", o site tem problema. Cada parâmetro listado na query string é um nome de arquivo que não está em cache. Ou seja, faz uma operação de I/O para cada arquivo do disco, junta-os todos em um e devolve ao cliente. Mas os arquivos são muitos. Muitos mais do que os recursos necessários para solicitá-los algumas vezes. Digamos que, com um laptop e um link de download de uns 50 Mb, uns 30 sites com hospedagem de qualidade mediana aguentam de 20 a 30 segundos antes de finalmente caírem de vez.

Outros requisitos

• NodeJS 8.11.2
• Instância(s) WordPress em funcionamento.
• É necessário que você faça uma verificação bem simples de cada proxy em uma máquina acessível pela Internet. Uma requisição GET em que é retornado, como string, o endereço IP a partir do qual o seu servidor enxerga a requisição. Nem todos os servidores proxy são "anônimos"! Além disso, esse procedimento valida que o proxy está funcionando antes de o ataque em si começar.

Estrutura:

• O arquivo websites.js contém uma lista de sites - "vítimas" - da qual, sem querer, esqueci de remover alguns que sobraram, dos quais sei com certeza que são vulneráveis ao contato com o script. Juro que nunca testei, é apenas o que acho.

• O arquivo userAgents.js contém uma lista de user-agents que são selecionados aleatoriamente em cada requisição individual às vítimas.

• O fileList.js contém a lista dos arquivos individuais que devem ser carregados da "vítima", para que, ao atualizar o WordPress, seja fácil adicioná-los ou corrigi-los.

• No index.js está o próprio script de execução.

Parâmetros

• countries é um array de países de onde os proxies devem ser procurados. (de quais países os ataques virão, através dos proxies)
• wanCheckUrl é o endereço completo que o script vai consultar e "olhar" se está atrás de um proxy transparente.
• requestTimeout é o tempo em milissegundos após o qual um proxy será considerado não funcional se não tiver se conectado.
• maxRequests é o limite de requisições da máquina para as "vítimas". Um número grande demais pode sobrecarregar significativamente também a sua máquina. Cerca de 30 requisições paralelas são necessárias para um site em hospedagem de nível médio.

Procedimento:

• O script consulta a verificação automática de proxy e grava o endereço IP pelo qual é visível publicamente.
• Começa a procurar proxies gratuitos em todo tipo de listas públicas.
• Quando cada um aparece, é feita uma requisição à verificação automática de proxy e, se o endereço com o qual o nosso serviço respondeu for diferente da primeira vez, o proxy é gravado em um array e a execução do ataque começa.
• Mais ou menos, o script rotaciona as vítimas por cada proxy usando round-robin e não há nada de especial na lógica; ele simplesmente faz o maior número possível de requisições, através do maior número possível de proxies diferentes e funcionais.

O console exibe em cores informações sobre cada "vítima" separadamente, e as que estão sob DDoS são coloridas de vermelho.

npm install
//редактирай webstites.js
node index.js

Google Dork para "vítimas"

inurl: “wp-admin/load-scripts.php”

Decidi dedicar este script à minha emissora de TV favorita, a tvsz, porque sei que são grandes "fãs" meus e, principalmente, porque vão encontrar o link do site deles na minha lista. Ou seja, vou aumentar um pouco o rating deles, para retribuir um velho "favor". Aproveito também para cumprimentar o pai, que ontem celebrou o dia do seu nome, mas não tive tempo de ligar para ele.