Sete das oito vulnerabilidades corrigidas nesta versão são vulnerabilidades de script de site cruzado (XSS). O Wordfence inclui proteção XSS robusta em nossas versões gratuita e Premium, que impedirão a exploração dessas vulnerabilidades. A oitava é uma vulnerabilidade de redirecionamento aberto que nossa equipe está monitorando para determinar o impacto.

Atualizações de segurança do WordPress 5.2.3 pelos números

Esta versão contém oito correções de segurança que incluem sete vulnerabilidades XSS e um redirecionamento aberto. Como lembrete, uma vulnerabilidade XSS é um código que permite que um invasor envie uma saída maliciosa a uma vítima quando visitar um site. Isso pode acontecer porque um invasor fez com que o site armazenasse dados maliciosos que são exibidos posteriormente para um visitante vítima (um XSS armazenado) ou quando um invasor cria um link que exibe código malicioso quando uma vítima visita esse URL em um site ( um XSS refletido).

Se você deseja aprofundar-se no XSS (cross site scripting), visite o artigo do centro de aprendizado, que explica exatamente como as vulnerabilidades de script entre sites são criadas no código PHP .

Este lançamento chegou ontem à noite, portanto, esperamos que os detalhes completos de cada uma dessas vulnerabilidades sejam divulgados pelos pesquisadores algum tempo após o lançamento principal. Isso segue a política de divulgação padrão e dá aos usuários do WordPress tempo para atualizar. Enquanto isso, descreveremos o que sabemos sobre cada vulnerabilidade.

1. Script entre sites nas pré-visualizações de colaboradores

Este é um XSS armazenado. Ao examinar um diff das alterações de código, parece que havia um XSS armazenado no campo pós-status. Ou seja, o campo que armazena o status atual de uma postagem do WordPress. Esse campo não usa uma lista fixa de valores possíveis, como um tipo de dados ‘enum’ do MySQL, mas lê o valor do texto da lista suspensa e o usa.

Isso permite que um invasor crie seu próprio valor para o pós-status e o use em um ataque de script entre sites.

É assim que o diff de código se parece no post.js, onde a correção foi implementada:

O vetor de ataque, nesse caso, é que um colaborador pode injetar código malicioso no status pós, que seria visualizado por um administrador do site com privilégios muito mais altos. Esse código seria executado pelo administrador com seus privilégios e o colaborador, que na verdade é um invasor, obteria privilégios de administrador usando as permissões do administrador para executar várias ações.

Nossa equipe também especula que isso possa ser explorado por pacotes de idiomas mal-intencionados, embora não tenhamos verificado esse vetor de ataque.

Esta vulnerabilidade foi descoberta por Simon Scannell, da RIPS Tech .

2. Vulnerabilidade de script entre sites em comentários armazenados

Parece ser um XSS armazenado e o anúncio não fornece nenhuma advertência com relação às permissões do usuário. Isso é preocupante porque sugere que há um XSS armazenado que afeta o sistema de comentários do WordPress. Isso por si só deve incentivar fortemente os usuários a atualizar o mais rápido possível.

O vetor de ataque aqui seria um invasor postando um comentário em um site WordPress e, em seguida, alguém com privilégios mais altos, como um administrador, visualizando ou moderando os comentários e tendo o código executado no navegador, o que poderia criar um novo usuário administrador para o invasor.

Isso também foi relatado por Simon Scannell, do RIPS.

3. Validação e higienização de um URL levam ao redirecionamento aberto

Uma vulnerabilidade de redirecionamento aberto é aquela frequentemente usada em campanhas de phishing. A vulnerabilidade ocorre quando um site oferece aos usuários externos a capacidade de criar URLs que redirecionam um visitante do site vulnerável para qualquer outro URL.

Nos ataques de phishing, o invasor envia um e-mail à vítima com o objetivo de fazê-la clicar em um link. O link é para um site confiável que a vítima reconhece. O invasor clica no link e um dos vários cenários ocorre.

Em um primeiro cenário, a vítima é levada diretamente para um site malicioso, onde uma vulnerabilidade no navegador pode ser explorada.

Em um segundo cenário, a vítima pode ser solicitada a entrar no site legítimo e, em seguida, é direcionada para um site mal-intencionado, onde pode ser solicitada a reinserção de suas credenciais. Eles podem, por exemplo, ver uma tela de login com falha e não perceber que foram redirecionados. Nesse ponto, suas credenciais são roubadas.

Em um terceiro cenário, uma vítima pode ser redirecionada para um site de spam depois de clicar em um link que era um URL para um site confiável com um redirecionamento aberto.

Existem várias maneiras de os invasores explorarem um redirecionamento aberto e a gravidade desse tipo de vulnerabilidade não deve ser subestimada.

Esta vulnerabilidade foi divulgada por Tim Coen .

4. Script entre sites refletido durante uploads de mídia

Esse é outro XSS que ocorre durante o upload de mídia. Nesse caso, um usuário com privilégios mais baixos fará upload de mídia para o site WordPress, que inclui código malicioso. Esse código seria executado no contexto do navegador de outro usuário – e esse usuário teria privilégios mais altos.

Ao examinar a diferença de código, parece que até agora, se você pudesse congestionar uma carga XSS em um nome de arquivo de upload de mídia, isso resultaria em um XSS. O WordPress 5.2.3 não permite mais esse vetor de ataque.

Esta vulnerabilidade foi divulgada por Anshul Jain.

5. XSS nas visualizações de código curto

Outro XSS foi corrigido no sistema de visualização de códigos curtos. Essa vulnerabilidade permite que um usuário mal-intencionado com privilégios mais baixos injete código em um código de acesso que, quando visualizado, seria executado no navegador de outro usuário. Se esse usuário tiver privilégios mais altos, o invasor poderá executar ações como esse usuário.

Esta vulnerabilidade foi descoberta por Zhouyuan Yang.

6. XSS no painel do WordPress

Ian Dunn, da equipe de segurança do WordPress Core, descobriu uma vulnerabilidade XSS no painel do WordPress. Essa vulnerabilidade é um XSS refletido, o que significa que os dados não são armazenados, mas são refletidos de volta à vítima por um invasor. Um exemplo disso é se um invasor cria um link malicioso para o painel do WordPress, o que faz com que o código de ataque seja executado no contexto do navegador da vítima.

Os detalhes completos dessa vulnerabilidade ainda não estão disponíveis, mas o que pode ser possível aqui é que um invasor forneça à vítima um link para o próprio painel do site WordPress. Quando a vítima clica no link, eles visitam o painel do próprio site e executam código mal-intencionado, concedendo assim ao invasor acesso ao site. O código malicioso pode criar uma conta de administrador, modificar o conteúdo do site ou executar outras ações nefastas.

7. URL Sanitization XSS

Soroush Dalili, do NCC Group, revelou uma vulnerabilidade XSS causada por URLs que não estavam sendo higienizados corretamente.

8. jQuery atualizado em versões mais antigas do WP para corrigir um XSS

O jQuery é uma biblioteca javascript usada extensivamente pelo núcleo do WordPress, plugins e temas. Uma vulnerabilidade de script entre sites foi descoberta no jQuery.extend e corrigida no jQuery 3.4.0 .

O WordPress usa sua própria versão específica do jQuery para WP. Essa correção no jQuery 3.4.0, que é detalhada no site jQuery no changelog, foi portada para a versão WordPress do jQuery. Essa versão está listada como jQuery v1.12.4 nos comentários do código-fonte. E eles atualizaram o código jQuery do WordPress sem aumentar o número da versão.

Notas Adicionais

Mudança em edit-form-blocks.php

Também notamos uma alteração no /wp-admin/edit-form-blocks.php, que passou de usar file_exists () para is_file () em uma declaração condicional. Aqui está o diff:

Quando o PHP é configurado com “allow_url_fopen = On”, certas versões do PHP permitem que a função file_exists () busque uma URL. Portanto, isso também pode fazer parte de uma correção ou melhoria de segurança.

Alteração no wp-sanitize.js

Percebemos que essa rotina de higienização agora inclui recursão que continuará a higienizar o texto até que o texto não seja mais alterado. Ele também usa textarea.textContent em vez de textarea.innerHTML na nova versão. Aqui está o diff:

O que fazer a seguir

Correndo o risco de afirmar o óbvio, atualize o mais rápido possível. Esta é uma versão secundária do WordPress, o que significa que a maioria dos sites será atualizada automaticamente.

Se você estiver executando um site de produção de alto tráfego com um fluxo de trabalho de desenvolvimento / preparação / produção envolvendo uma equipe de controle de qualidade, provavelmente precisará executar o 5.2.3 no preparo, deixe sua equipe de controle de qualidade se interessar por ele e depois que eles resolverem os problemas , empurre para produção. Isso leva tempo, mas, considerando essas vulnerabilidades, eu recomendaria priorizar esta versão em relação a outros projetos.

Os pesquisadores que contribuíram com essas vulnerabilidades para a equipe de desenvolvimento principal provavelmente estarão divulgando detalhes completos de cada vulnerabilidade em breve, agora que a versão principal estiver lançada. Meu palpite é que os pesquisadores mais profissionais divulgarão detalhes em uma semana ou duas e outros poderão divulgar mais cedo. Depois que os detalhes são divulgados, essas vulnerabilidades são totalmente exploráveis ​​por qualquer pessoa.

No entanto, vale a pena notar que essas vulnerabilidades podem se tornar exploráveis ​​antes que os detalhes sejam divulgados. Os dados divulgados até o momento representam um alvo em várias áreas do código no núcleo do WordPress e, observando uma diferença de código, os invasores podem fazer engenharia reversa dessas vulnerabilidades e desenvolver eles mesmos o código de exploração. Por esse motivo, recomendo que você atualize para a 5.2.3 o mais rápido possível, se não for atualizado automaticamente.

Em Fechamento

Gostaríamos de parabenizar os pesquisadores que contribuíram com correções para o núcleo do WordPress e agradecer a eles por seguirem as diretrizes de divulgação responsáveis. Agradeço também à equipe principal do WP por implementar essas correções e ajudar a manter a comunidade WordPress segura.

Você pode encontrar o anúncio oficial do lançamento do WP 5.2.3 nesta página.  Se você tiver alguma dúvida ou comentário, não hesite em publicá-las abaixo e faremos o possível para respondê-las em tempo hábil. Se você é um dos pesquisadores cujo trabalho está incluído acima e gostaria de fornecer detalhes ou correções adicionais, agradecemos seus comentários.

Mark Maunder.