playboisk8/poc-cve-2017-8464-opencalculatorExplorando a vulnerabilidade .lnk e os mecanismos de manipulação do sistema operacional em relação ao explorer.exe e unidades USB.
Crie 1 Atalho + 1 .DLL contendo payload malicioso => Coloque no USB e envie para a vítima => vítima abre o USB => Payload é ativado automaticamente!
Primeiro, precisamos saber exatamente de onde vem essa falha! Isso se deve ao recurso chamado Plug-and-Play (Conectar e Usar). O SO detecta automaticamente o dispositivo, aloca recursos e carrega o driver apropriado para que ele funcione imediatamente, sem precisar reiniciar a máquina. Quando você conecta um USB e abre a pasta pelo Windows Explorer explorer.exe, o sistema operacional escaneia os arquivos para exibir as imagens de ícones correspondentes ao usuário!
Desde versões antigas do Windows, a Microsoft queria que os atalhos (.lnk) que apontam para recursos do Painel de Controle (que na prática são arquivos .cpl ou .dll) pudessem exibir ícones dinâmicos de forma flexível. Por isso, a biblioteca central de gerenciamento de interface do Windows, shell32.dll, foi projetada com uma função chamada
Usando LoadLibrary cegamente: Para obter o ícone de um arquivo de estrutura Control Panel Applet, o sistema operacional não lê um simples arquivo de imagem estática; ele usa a função LoadLibraryW para carregar diretamente toda essa biblioteca de vínculo dinâmico no espaço de memória do processo explorer.exe. Após carregar, ele chama uma função de exportação padrão, CPlApplet, para obter o ícone desenhado na tela
Para provar que LoadLibraryW está realmente envolvido na cadeia de exploração acima:
1/ Abra o
x64dbg với quyền admin2/ Anexe ao
explorer.exe3/ Digite o comando
bp LoadLibraryW4/ Pressione F9 para o
explorer.execontinuar rodando5/ Conecte o USB e ele atingirá o
hit breakpointimediatamente!
Eu enfrentei o problema de que a cadeia de exploit permanecia completamente silenciosa; mesmo tentando verificar e depurar várias coisas, não consegui encontrar uma forma de corrigir! Depois, tentei procurar PoCs de outras pessoas para executar, mas também falharam!
Porém, quando fui almoçar e voltei, recuperei o foco e a calma. Comecei a me perguntar por que o PoC desse cara funcionava, mas no meu computador não funcionava. Ok, comecei a fazer uma engenharia reversa leve no .lnk e .dll dele e descobri 2 coisas!
1 / A minha .dll era mais longa que a dele! Mas tudo bem, esse não era o problema!
2 / Quando joguei o .lnk no HxD para ler as strings, descobri que esse cara não usava caminho relativo, mas sim absoluto!
Relativo : ../example.dll
Absoluto : O:/example.dll
Ok, agora a correção será a seguinte: precisamos saber qual letra de unidade o USB receberá automaticamente quando for conectado à máquina da vítima; a partir daí, atribuímos o caminho absoluto e teremos sucesso. Como no meu Windows 7, quando conecto o USB, ele sempre aparece como unidade F, a sintaxe de build que usei foi:
python Make_PoC.py FakeGoogleChrome F:\Pwned.dll
Como esta é uma falha de concepção de arquitetura de sistema (Logic/Architecture Flaw) e não um estouro de memória, a Microsoft teve que mudar completamente a forma como o Painel de Controle é processado:
.cpl ou .dll carregados por processos do sistema tenham uma assinatura digital válida da Microsoft ou estejam em pastas de sistema rigidamente protegidas (como System32) para evitar a falha de "Binary Planting" a partir de USB.explorer.exe [cite: 1058], as novas versões do Windows executam os applets do Painel de Controle por meio de um processo intermediário isolado (como dllhost.exe ou rundll32.exe). Se a DLL travar ou contiver malware, ela apenas derruba o processo intermediário, sem conseguir controlar todo o sistema de interface do usuário.Pesquisa VN
PoC
Ferramenta para criar o .lnk vulnerável