Vulnerabilidade no WordPress permitia execução remota de código

Autoria: Compilado do Código Fonte TV [OFICIAL] · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: português

Vídeo original: Vulnerabilidade no WordPress permitia execução remota de código · Canal: Compilado do Código Fonte TV [OFICIAL] · 04:10 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Engenharia de software com IA

Resumo

Uma vulnerabilidade crítica no núcleo do WordPress permitia que atacantes sem conta carregassem arquivos PHP fora da pasta padrão dos temas e, em determinadas configurações, executassem código remotamente. A falha afetava versões da ramificação 4.7.0 até a 7.1.1 e foi corrigida na versão 7.1.2, com correções retroportadas para versões mantidas. O risco dependia de condições específicas relacionadas ao tema ativo e à configuração do PHP. A recomendação é atualizar o WordPress e limitar os privilégios do usuário que o executa.

Pontos-chave

A vulnerabilidade no núcleo do WordPress recebeu nota 9.2 no CVSS.
Atacantes remotos não precisavam de uma conta para tentar explorar a falha.
A falha envolvia o seletor de template de página e a ausência de validação contra directory traversal.
Em determinadas configurações, era possível executar código arbitrário com os privilégios do usuário do servidor web.
A correção chegou na versão 7.1.2, com backport para versões mantidas até a 4.7.37.
O risco dependia, entre outros fatores, de diretórios de tema com o prefixo page- e da diretiva register_argc_argv ativa no PHP.
Não havia registro de incidente no catálogo de ameaças da CISA mencionado no vídeo.
Além de atualizar, é recomendado evitar que o usuário do WordPress tenha privilégios de root ou de administrador.

Capítulos

Início	Capítulo	Resumo
00:02	A vulnerabilidade no núcleo do WordPress	O vídeo apresenta a falha crítica, sua pontuação e o impacto possível do carregamento de arquivos PHP.
01:06	Correção e condições de exploração	São explicadas as versões corrigidas, as condições de configuração relevantes e a descoberta da falha.
02:08	Como a exploração poderia afetar o servidor	Os participantes discutem como a manipulação de caminhos poderia permitir a execução de arquivos PHP e o acesso a dados.
03:10	Atualização e redução de privilégios	O vídeo recomenda aplicar o patch e limitar os privilégios do usuário que executa o WordPress.
03:40	Isolamento e encerramento	A conversa aborda containers e hospedagem compartilhada antes de encerrar com a divulgação do canal.

Citações

Permitindo execução remota de código. — 00:02

A correção oficial chegou na versão 7.1.2. — 01:06

Não há registro de incidente no catálogo de ameaças da CISA. — 01:38

É atualizando, obviamente, nesse patch. — 03:10

É sempre bom olhar quais são os privilégios e a versão que você está usando do WordPress. — 03:40

Conceitos e entidades

WordPress (ferramenta): Plataforma cujo núcleo foi afetado pela vulnerabilidade discutida no vídeo.
CVSS (conceito): Sistema de pontuação de severidade usado para classificar a falha como 9.2.
PHP (conceito): Linguagem e ambiente de execução relacionados às condições necessárias para explorar a vulnerabilidade.
Patchstack (empresa): Empresa de segurança citada como fonte sobre as condições que influenciam o risco de exploração.
HackerOne (empresa): Plataforma por meio da qual o pesquisador relatou ter descoberto a falha.
Robert Ressel (pessoa): Pesquisador que descobriu a vulnerabilidade e publicou uma prova de conceito em ambiente isolado.
CISA (empresa): Agência cujo catálogo de ameaças, segundo o vídeo, não registrava incidentes relacionados à falha.

Tradução completa (pt-BR)

00:02 E bora falar de mais uma vulnerabilidade, dessa vez no WordPress, que permitia execução remota de código. >> Eles disponibilizaram uma correção de segurança urgente para eliminar uma vulnerabilidade crítica no núcleo da plataforma, ou seja, lá no WP includes. Catalogada com nota 9,2 no índice CVSS. A brecha afeta todas as versões do software da ramificação 4.7.0 até a 7.1.1. >> Ferrou. >> É treta isso aqui, hein? Permitindo que

00:33 atacantes remotos, sem conta no sistema, façam o sistema carregar arquivos PHP que estejam fora da pasta padrão dos temas. >> Ferrou. >> Esse é um problemão, cara. Em infraestruturas com configurações específicas, a falha pode ser explorada para executar código arbitrário com os mesmos privilégios do usuário do servidor web. O problema está no seletor de template de página, no qual a aplicação monta nomes de arquivos a partir da URL sem validar sequências de directory traversal, abrindo caminho

01:06 para manipulação direta de caminhos locais. >> A correção oficial chegou na versão 7.1.2 e teve backport aplicado a todas as versões mantidas pelo projeto, até a edição 4.7.37, exigindo atualização imediata por não existirem soluções alternativas. Segundo a empresa de segurança Patchstack, o risco de execução remota depende de fatores como o tema ativo conter diretórios iniciados pelo prefixo page- e um hífen, e de um

01:38 ambiente PHP rodar com a diretiva register_argc_argv ativa, viu? Um padrão comum antes do PHP 8.5. O pesquisador Robert Ressel descobriu a falha via HackerOne e publicou uma prova de conceito demonstrando o ataque em ambiente isolado. Não há registro de incidente no catálogo de ameaças da CISA, mas a equipe alerta que quem atualizou o sistema há poucos dias ainda precisa aplicar o patch. >> Não, quem atualizou há poucos dias, olha

02:08 de quando até quando são? >> Não, então, mas mesmo que você tenha atualizado há 15 dias, não adianta, você tem que atualizar de novo agora, né? >> Não, então, pois é. Então, esse é um problema, porque você não precisa ser um usuário, não. Você nem precisa ter acesso ao admin, nada disso. Se você tem um tema especificado e ele tem justamente o prefixo page-, que eu acho que a maioria dos temas usa >> Uhum. >> para funcionar. Isso quer dizer que você pode meio que ludibriar o caminho onde o tema é executado. Você pode

02:40 trocar isso e colocar um arquivo para ser executado em outro lugar. Aí você joga um PHP ali. Obviamente não é tão trivial assim, mas, se você tem um PHP que possa executar coisas remotamente, por exemplo, digo isso porque já vi ataque de PHP em que você simplesmente coloca um arquivo PHP dentro de um servidor, e esse arquivo PHP, na verdade, simula um explorador de arquivos. E aí, no fim, ele tem acesso aos arquivos que você consegue acessar, inclusive arquivos de configuração; você vê login,

03:10 senha de banco e etc. Obviamente, você precisa ter algo que consiga colocar esse arquivo lá dentro do servidor e acessar esses privilégios. Então, como se proteger? Atualizando, obviamente, com esse patch. Mas você também precisa ter certeza de que o usuário que executa o WordPress não é um root da vida, não tem privilégios de admin e está configurado para executar o WordPress somente naquela pasta específica. Aí sim, você garante menos problemas. >> Verdade,

03:40 é, de qualquer forma ele vai conseguir executar tudo e estragar de vez o seu WordPress, mas pelo menos não vai conseguir sair dali, né? >> Pois é, mesmo que você esteja em algum container, acho que container protege um pouco mais, tá? Mas, se você estiver em uma hospedagem compartilhada ou algo do tipo, isso pode afetar o funcionamento do próprio servidor. Então, é sempre bom conferir quais são os privilégios e qual versão do WordPress você está usando, né? >> E esse aqui é um corte de uma notícia do compilado do Código Fonte TV.

04:10 >> Onde toda semana tem episódio novo falando de programação, tecnologia, inteligência artificial e cibersegurança. >> Então, já se inscreve aqui no canal do compilado e acompanha os episódios completos. >> [música] [música] [música]

Transcrição original

[00:02] E bora falar de mais vulnerabilidade, dessa vez no WordPress, que permitia execução remota de código. >> Eles disponibilizaram uma correção de segurança urgente para eliminar uma vulnerabilidade crítica no núcleo da plataforma, ou seja, lá na WP includes. Catalogada como nota 9.2 no índice CVSS. A brecha afeta todas as versões do software da ramificação 4.7.0 até a 7.1.1. >> Ferrou. >> É treta isso aqui, hein? Permitindo que

[00:33] atacantes remotos, sem conta no sistema, façam o sistema carregar arquivos PHP que estejam fora da pasta padrão dos temas. >> Ferrou. >> Esse é um problemasso, cara. Em infraestruturas com configurações específicas, a falha pode ser explorada para executar código arbitrário com os mesmos privilégios do usuário do servidor web. O problema reside aí no seletor de template de página, no qual a aplicação monta nomes de arquivos a partir da URL sem validar sequências de directory traversal, abrindo aí caminho

[01:06] para manipulação direta de caminhos locais. >> A correção oficial chegou na versão 7.1.2 e teve o backport aplicado a todas as versões mantidas pelo projeto, até a edição 4.7.37, exigindo atualização imediata por não existirem soluções de contorno alternativas. Segundo a empresa de segurança Patchstack, o risco de execução remota depende de fatores como o tema ativo conter diretórios iniciados pelo prefixo page- e tracinho e de um

[01:38] ambiente PHP rodar com a diretiva register_argc_argv ativa, viu? Padrão comum antes do PHP 8.5. O pesquisador Robert Ressel, ele descobriu a falha via HackerOne e publicou uma prova de conceito demonstrando o ataque em ambiente isolado. Não há registro de incidente no catálogo de ameaças da CISA, mas a equipe alerta que quem atualizou o sistema há poucos dias ainda precisa aplicar o patch. >> Não, quem atualizou há poucos dias, olha

[02:08] de de quando até quando são >> Não, então, mas mesmo que você atualizou aí há 15 dias, não adianta, você tem que atualizar de novo agora, né? >> Não, então, pois é. Então, esse é um problema, porque você não precisa ser um usuário, não, você você não precisa nem ter acesso a ao admin, nada disso. Se você tem um tema especificado e aí ele é é justamente tem o prefixo paid, que eu acho que a maioria dos temas usam isso >> Uhum. >> para para funcionar. Isso quer dizer que você pode meio que ludibriar o caminho onde o tema é executado. Você pode

[02:40] trocar isso e aí você pode colocar um para ser executado em um outra um outro lugar. Aí você joga um um PHP ali. Obviamente não é tão trivial assim, mas se você tem um PHP que possa possa executar coisas remotas, por exemplo, eu digo porque eu eu já vi ataque de PHP que é simplesmente você jogar um arquivo PHP dentro de um servidor e esse arquivo PHP na verdade simula um explorador de arquivos. E aí no fim ele tem acesso aos arquivos que você consegue acessar, arquivos de configuração inclusive, você vê login,

[03:10] senha de banco e etc. Obviamente você tem que ter um algo que você consiga colocar esse arquivo lá dentro do servidor e consiga acessar esses privilégios. Então, como se proteger? É atualizando, obviamente, nesse patch, mas você tem que ter certeza também que o usuário que executa o WordPress, ele não é um root da vida ou ele não tem privilégio admin ou ele só está configurado para aquela pasta específica para executar o WordPress. Aí sim, você garante menos problemas. >> Verdade,

[03:40] é, de qualquer forma ele vai conseguir executar tudo e estragar de vez o seu WordPress, mas pelo menos ele não vai conseguir sair dali, né? >> Pois é, mesmo que você esteja em algum container, acho que container protege um pouco mais, tá? Mas se você tiver dentro de uma hospedagem compartilhada ou outro tipo de coisa, isso pode afetar o funcionamento do próprio servidor em si. Então, é sempre bom olhar quais são os privilégios e a versão aí que você tá usando do WordPress, né? >> E esse aqui é um corte de uma notícia do compilado do Código Fonte TV.

[04:10] >> Onde toda semana tem episódio novo falando de programação, tecnologia, inteligência artificial e cibersegurança. >> Então, já se inscreve aqui no canal do compilado e acompanha os episódios completos. >> [música] [música] [música]