Node inspector/CEF debug abuse
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Dos docs: Quando iniciado com o switch --inspect
, um processo Node.js escuta por um cliente de depuração. Por padrão, ele escutará no host e porta 127.0.0.1:9229
. Cada processo também é atribuído um UUID único.
Os clientes do Inspector devem conhecer e especificar o endereço do host, a porta e o UUID para se conectar. Uma URL completa se parecerá com ws://127.0.0.1:9229/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e
.
Como o debugger tem acesso total ao ambiente de execução do Node.js, um ator malicioso capaz de se conectar a esta porta pode ser capaz de executar código arbitrário em nome do processo Node.js (potencial escalonamento de privilégios).
Existem várias maneiras de iniciar um inspector:
Quando você inicia um processo inspecionado, algo assim aparecerá:
Processos baseados em CEF (Chromium Embedded Framework) precisam usar o parâmetro: --remote-debugging-port=9222
para abrir o debugger (as proteções SSRF permanecem muito semelhantes). No entanto, eles em vez disso de conceder uma sessão de debug do NodeJS se comunicarão com o navegador usando o Chrome DevTools Protocol, esta é uma interface para controlar o navegador, mas não há um RCE direto.
Quando você inicia um navegador em modo de depuração, algo assim aparecerá:
Sites abertos em um navegador da web podem fazer solicitações WebSocket e HTTP sob o modelo de segurança do navegador. Uma conexão HTTP inicial é necessária para obter um id de sessão de depuração exclusivo. A política de mesma origem impede que sites consigam fazer essa conexão HTTP. Para segurança adicional contra ataques de reatribuição de DNS, o Node.js verifica se os 'Host' headers para a conexão especificam um endereço IP ou localhost
ou localhost6
precisamente.
Essas medidas de segurança impedem a exploração do inspetor para executar código apenas enviando uma solicitação HTTP (o que poderia ser feito explorando uma vulnerabilidade SSRF).
Você pode enviar o sinal SIGUSR1 para um processo nodejs em execução para fazer com que ele inicie o inspetor na porta padrão. No entanto, observe que você precisa ter privilégios suficientes, então isso pode lhe conceder acesso privilegiado a informações dentro do processo, mas não uma escalada de privilégio direta.
Isso é útil em contêineres porque encerrar o processo e iniciar um novo com --inspect
não é uma opção porque o contêiner será finalizado com o processo.
Para conectar a um navegador baseado em Chromium, as URLs chrome://inspect
ou edge://inspect
podem ser acessadas para Chrome ou Edge, respectivamente. Ao clicar no botão Configurar, deve-se garantir que o host e a porta de destino estejam listados corretamente. A imagem mostra um exemplo de Execução Remota de Código (RCE):
Usando a linha de comando, você pode se conectar a um debugger/inspetor com:
A ferramenta https://github.com/taviso/cefdebug permite encontrar inspetores em execução localmente e injetar código neles.
Note que explorações RCE do NodeJS não funcionarão se conectadas a um navegador via Chrome DevTools Protocol (você precisa verificar a API para encontrar coisas interessantes para fazer com isso).
Se você veio aqui procurando como obter RCE de um XSS no Electron, por favor, verifique esta página.
Algumas maneiras comuns de obter RCE quando você pode conectar a um inspector do Node é usar algo como (parece que isso não funcionará em uma conexão com o protocolo Chrome DevTools):
Você pode verificar a API aqui: https://chromedevtools.github.io/devtools-protocol/ Nesta seção, vou apenas listar coisas interessantes que encontrei que as pessoas usaram para explorar este protocolo.
No CVE-2021-38112, a segurança da Rhino descobriu que um aplicativo baseado em CEF registrou um URI personalizado no sistema (workspaces://) que recebia o URI completo e então lançava o aplicativo baseado em CEF com uma configuração que estava parcialmente construída a partir desse URI.
Foi descoberto que os parâmetros do URI eram decodificados em URL e usados para lançar o aplicativo básico CEF, permitindo que um usuário injetasse a flag --gpu-launcher
na linha de comando e executasse coisas arbitrárias.
Então, um payload como:
Executará um calc.exe.
Altere a pasta onde os arquivos baixados serão salvos e baixe um arquivo para substituir o código fonte frequentemente usado da aplicação pelo seu código malicioso.
De acordo com este post: https://medium.com/@knownsec404team/counter-webdriver-from-bot-to-rce-b5bfb309d148 é possível obter RCE e exfiltrar páginas internas do theriver.
Em um ambiente real e após comprometer um PC de usuário que utiliza um navegador baseado em Chrome/Chromium, você poderia iniciar um processo do Chrome com a depuração ativada e redirecionar a porta de depuração para que você possa acessá-la. Dessa forma, você será capaz de inspecionar tudo o que a vítima faz com o Chrome e roubar informações sensíveis.
A maneira furtiva é terminar todos os processos do Chrome e então chamar algo como
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)