XSS Armazenado no Core do WordPress

Tweet

Risco de Segurança: Baixo
Nível de Exploração: Difícil / Requer ao menos privilégio de contribuinte
DREAD Score: 4/10
Vulnerabilidade: XSS Armazenado
Versão com Patch: 4.7.3

Como você deve se lembrar, recentemente escrevemos sobre uma Vulnerabilidade de Injeção de Conteúdo no WordPress que permitia aos hackers descaracterizar sites vulneráveis por meio de ataques conhecidos como defacement ou pichação web. Embora nossa divulgação original apenas descrevesse uma vulnerabilidade, nós relatamos duas vulnerabilidades para a equipe do WordPress. Como se vê, foi possível usar o problema de injeção de conteúdo para conseguir fazer um ataque de scripts cruzado entre sites armazenados.

Corro Risco?

Essa vulnerabilidade já existia no WordPress há algum tempo, bem antes da atualização 4.7.

Combinada com a recente vulnerabilidade de injeção de conteúdo que encontramos, é possível que um invasor remoto descaracterize um post aleatório no site e armazene código JavaScript malicioso nele. Esse código seria executado quando um visitante visse o post e quando alguém editasse o post do painel do WordPress. Como resultado, um administrador tentaria corrigir o post desfigurado, o que inadvertidamente desencadearia o script mal-intencionado, que poderia ser usado para colocar um backdoor no site e criar novos usuários admin.

A vulnerabilidade de injeção de conteúdo foi corrigida na versão 4.7.2 e, como tal, o risco representado por essa vulnerabilidade XSS é muito menos grave. Além disso, somente os usuários com certos privilégios, como contribuintes, podem atualmente explorar o problema.

Detalhes Técnicos

Ter a possibilidade de editar qualquer postagem em um site é uma vulnerabilidade séria por si só, mas há uma desvantagem notável para os invasores. Graças às limitações da função wp_kses() no WordPress, um ator mal-intencionado estava muito limitado em termos das tags HTML que poderiam ser inseridas na postagem.

Por exemplo, se um atacante injetou um post contendo um script de alerta simples como:

<script>alert(1);</script>

Resultaria em um post contendo somente o texto “alert(1)”.

Sentimos que era nosso dever como profissionais de segurança aprofundar nossa pesquisa e ver o quão longe um hacker poderia ir com essa vulnerabilidade. No processo, descobrimos que o código (shortcode) embed poderia produzir um cenário mais perigoso.

Em poucas palavras, o shortcode embed leva um atributo src (source link) e tenta várias expressões regulares para descobrir qual método handler o script deve usar para que o link de origem possa ser incorporado corretamente. O que chamou nossa atenção foi o youtube_embed_url

O único detalhe importante aqui é que o último grupo de captura vai pegar qualquer coisa que não seja um caractere “slash” (barra diagonal), o que pode incluir caracteres menores e maiores também. Verificamos o que a função callback wp_embed_handler_youtube fez com esse pedaço de texto. O que descobrimos é que ela basicamente gerava ums URL do Youtube e concatenava o último grupo de captura – https://youtube.com/watch?v={$LASTCAPTUREGROUP}.

Depois, enviava o link gerado para o wp_embed e seu método autoembed().

É aí que as coisas ficam realmente interessantes. Se $content (a URL incorporada) contém algo como:

https://youtube[.]com/watch?v=abc<svg onload=alert(1)>

…nenhuma dessas expressões regulares combinarão, então o autoembed() simplesmente retorna a URL $content.

Em um cenário de ataque, a história terminaria aqui, mas as coisas ficaram um pouco mais complexas quando nos lembramos de que tudo o que enviamos ao nosso post seria sanitizado pela função de sanitização HTML wp_kses().

Mesmo se tentássemos enviar um shortcode como este:

Ele seria reduzido para:

No entanto, também analisamos a função shortcode_parse_atts , responsável pela análise de parâmetros de shortcode.

Em suma, ela usa uma expressão regular que coincide com todos os pares de chaves e valores em um shortcode e, em seguida, cria uma matriz associativa fora dela enquanto assegura que cada um dos valores dos atributos sejam passado através da função stripcslashes. Isso nos permite enviar sequências de escape como \x41 (A), ou \x3c (<)

Tudo o que foi faltava para fazer o XSS funcionar estava combinando todos os avanços anteriores em um shortcode simples:

Com isso, teríamos um exploit de XSS armazenado.

Conclusão

Se você desabilitou atualizações automáticas em seu site, atualize para o WordPress 4.7.3 o mais rápido possível!

Se você não pode fazer isso, recomendamos usar o Firewall Sucuri ou tecnologia equivalente para corrigir virtualmente a vulnerabilidade.