Múltiplas vulnerabilidades corrigidas no Orbit Fox pelo plugin ThemeIsle

Em 19 de novembro de 2020, nossa equipe de Threat Intelligence revelou de forma responsável duas vulnerabilidades em Orbit Fox por ThemeIsle , um plugin WordPress usado por mais de 400.000 sites. Uma dessas falhas possibilitou que invasores com nível de acesso de colaborador ou superior escalassem seus privilégios para os de um administrador e potencialmente assumissem o controle de um site WordPress. A outra falha possibilitou que invasores com acesso de contribuidor ou autor injetassem JavaScript potencialmente malicioso nas postagens. Esses tipos de scripts maliciosos podem ser usados ​​para redirecionar visitantes para sites de malvertising ou criar novos usuários administrativos, entre muitas outras ações.

Inicialmente, entramos em contato com o desenvolvedor do plug-in em 19 de novembro de 2020. Depois de estabelecer um canal de comunicação apropriado, fornecemos todos os detalhes de divulgação em 24 de novembro de 2020. Após alguns acompanhamentos, o desenvolvedor do plug-in lançou uma versão corrigida do Orbit Fox por ThemeIsle na versão 2.10.3, em 17 de dezembro de 2020.

Essas são vulnerabilidades críticas e de gravidade média. Portanto, é altamente recomendável atualizar para a versão corrigida, 2.10.3, imediatamente.

Os usuários do Wordfence Premium receberam uma regra de firewall para proteção contra qualquer exploração que vise essas vulnerabilidades em 19 de novembro de 2020. Sites que ainda usam a versão gratuita do Wordfence receberam a mesma proteção em 19 de dezembro de 2020.

Orbit Fox da ThemeIsle é um plugin desenvolvido para aprimorar os editores Elementor, Beaver Builder e Gutenberg com recursos adicionais, como formulários de registro, bem como outros blocos e widgets que podem ser usados ​​durante a edição de postagens e páginas.

Como parte do plug-in, há um widget de registro que pode ser usado para criar um formulário de registro com campos personalizáveis ​​ao usar os plug-ins de construtor de páginas Elementor e Beaver Builder. Durante a criação do formulário de registro, o plug-in fornece a capacidade de definir uma função padrão a ser usada sempre que um usuário se registrar usando o formulário.

widget Orbit Fox Registration.

Os usuários de nível inferior, como colaboradores, autores e editores, não tiveram a opção de definir a função de usuário padrão no editor. No entanto, descobrimos que eles ainda podem modificar a função do usuário padrão elaborando uma solicitação com o parâmetro apropriado. O plug-in fornece proteção do lado do cliente para evitar que o seletor de função seja mostrado para usuários de nível inferior ao adicionar um formulário de registro. Infelizmente, não havia nenhuma proteção ou validação do lado do servidor para verificar se um usuário autorizado estava realmente definindo a função de usuário padrão em uma solicitação.

{"save_builder": {"action":"save_builder","data": {"status":"publish","elements": [{"id":"be9a476","elType":"section","isInner": false,"settings": {},"elements": [{"id":"7ea305d","elType":"column","isInner": false,"settings": {"_column_size": 100,"_ inline_size": null},"elements": [{"id":"6edacb5","elType":"widget","isInner": false,"settings": {"form_fields [...] ,"submit_label":"Registrar", "user_role":"administrador"} ,"elementos": [],"widgetType":"content_form_registration"}]}]}],"settings": {"post_title":"BadPost","post_status":"pendente"}}}}',

A falta de validação do lado do servidor significava que um usuário de nível inferior com acesso ao editor de página/postagem, como contribuidores, autores e editores, poderia criar um formulário de registro e definir a função do usuário como administrador após o registro bem-sucedido. Depois que o formulário de registro foi criado, o usuário pode simplesmente registrar um novo usuário e esse usuário receberá privilégios de administrador, mesmo enquanto ainda estiver autenticado na instância do WordPress.

Para explorar essa falha, o registro do usuário precisaria estar habilitado e o site precisaria estar executando os plug-ins Elementor ou Beaver Builder. Um site com registro de usuário desabilitado ou nenhum desses plug-ins instalados não seria afetado por esta vulnerabilidade.

Além da vulnerabilidade de escalonamento de privilégios que descobrimos, também descobrimos que colaboradores e autores podem adicionar scripts a postagens, apesar de não terem o recurso unfiltered_html devido ao recurso de script de cabeçalho e rodapé no Orbit Fox.

Cabeçalho do Orbit Fox e área de script de rodapé.

Essa falha permitia que usuários de nível inferior adicionassem JavaScript malicioso a postagens que seriam executadas no navegador sempre que um usuário navegasse para aquela página.

Como sempre acontece com as vulnerabilidades XSS, isso possibilitaria aos invasores criar novos usuários administrativos, injetar redirecionamentos e backdoors mal-intencionados ou alterar outro conteúdo do site por meio do uso de JavaScript mal-intencionado.

A importância da validação do lado do servidor sobre a validação do lado do cliente

Existem duas maneiras principais pelas quais os desenvolvedores podem validar a entrada do usuário no WordPress, seja no lado do cliente em um navegador após o envio de dados, ou no servidor após os dados serem enviados pelo usuário. Garantir que a entrada do usuário seja válida é uma parte importante da integridade e segurança dos dados de um aplicativo, portanto, entender a diferença entre a validação do lado do cliente e do lado do servidor é importante para os desenvolvedores.

A validação do lado do cliente ocorre quando a entrada é validada por scripts no navegador antes de ser enviada ao servidor. Por exemplo, ao preencher um formulário, a entrada pode ser verificada e removida para caracteres Cross-Site Scripting como <> no navegador após o envio, antes que os dados sejam enviados por meio de uma solicitação ao servidor. Normalmente, isso será feito usando uma linguagem de programação do lado do cliente, como JavaScript.

A validação do lado do servidor ocorre quando os dados chegam ao servidor e é feita em um ambiente controlado. Por exemplo, ao preencher um formulário, a entrada será enviada ao servidor à medida que o usuário a inseriu, sem qualquer validação, edição ou modificação. Assim que o servidor receber a solicitação, ele verificará se há problemas de segurança, garantirá que os dados estejam formatados corretamente e preparará o envio para inserção ou atualização em uma fonte de dados. Isso é feito com código executado no lado do servidor e, no caso do WordPress, seria o PHP.

Nunca dependa exclusivamente da validação do lado do cliente. A validação do lado do cliente não é infalível. Como a validação do lado do cliente é realizada no computador de um usuário dentro de seu navegador, as solicitações podem ser interceptadas assim que saem do navegador do usuário antes de serem processadas pelo servidor. Um script baseado em navegador pode retirar as tags de script entre sites da solicitação enviada do navegador; no entanto, um invasor pode interceptar a solicitação e adicionar novamente as tags de script. Se não houver validação do lado do servidor, esses scripts as tags serão aceitas e usadas apesar das proteções do lado do cliente em vigor. Os invasores familiarizados com um aplicativo também podem gerar solicitações e entradas de formulários de maneira programática, ignorando as proteções do lado do cliente para interagir com um site.

Por esse motivo, recomendamos sempre o uso de validação do lado do servidor nas solicitações. A validação do lado do cliente deve ser usada como um suplemento quando necessário. Isso impedirá que as solicitações sejam alteradas em trânsito do navegador para o servidor e inibirá quaisquer desvios para proteções do lado do cliente que estejam em vigor.

Cronograma de divulgação

19 de novembro de 2020 -Conclusão da análise do plugin que levou à descoberta de duas vulnerabilidades no plugin Orbit Fox by ThemeIsle.
19 de novembro de 2020 -Desenvolvemos regras de firewall para proteger os clientes do Wordfence e liberá-los para usuários do Wordfence Premium. Iniciamos o contato com o desenvolvedor do plugin.
23 de novembro de 2020 -O desenvolvedor do plug-in confirma a caixa de entrada para lidar com a discussão.
24 de novembro de 2020 -Enviamos a divulgação completa.
8 de dezembro de 2020 -Fazemos o acompanhamento, pois ainda não recebemos uma resposta de nossa divulgação.
15 de dezembro de 2020 -Enviamos nosso acompanhamento final indicando que precisaremos escalar o processo de acordo com nossas diretrizes de divulgação se nenhuma resposta for recebida até 18 de dezembro.
17 de dezembro de 2020 -Recebemos uma resposta e uma versão corrigida do plug-in é lançada como versão 2.10.3. Verificamos se as vulnerabilidades foram corrigidas.
19 de dezembro de 2020 -usuários gratuitos do Wordfence recebem regra de firewall.

Conclusão

Na postagem de hoje, detalhamos duas falhas no Orbit Fox da ThemeIsle que concediam aos invasores a capacidade de escalar privilégios e injetar JavaScript potencialmente malicioso nas postagens. Essas falhas foram totalmente corrigidas na versão 2.10.3. Recomendamos que os usuários atualizem imediatamente para a versão mais recente disponível, que é a versão 2.10.3 no momento desta publicação.

Wordfence Premium os usuários receberam regras de firewall protegendo contra essas vulnerabilidades em 19 de novembro de 2020, enquanto aqueles que ainda usam a versão gratuita do Wordfence receberam a mesma proteção em 19 de dezembro de 2020.

Se você conhece um amigo ou colega que está usando esse plug-in em seu site, é altamente recomendável encaminhar este aviso a ele para ajudar a manter seus sites protegidos, pois essas são vulnerabilidades críticas e de alta gravidade que podem levar ao controle total do site.