Neste post colocarei pequenos desafios de engenharia reversa que serão enviados ao longo do tempo. Por isso esse post será fixado e atualizado constantemente.
Esse é um guia prático sobre como montar pequenos snippets PIC (position independent code) e que sejam cross-platform: x86/x64 de autoria da pesquisadora e desenvolvedora de exploits hh86.
Snippets para conseguir o base address do PEB e kernel32.dll
A trick está em usar o prefixo DEC EAX/REX e CMOVcc para conseguir os dados que precisamos de forma condicional: em x86 conseguimos o endereço do struct PEB em EBX, enquanto em x64 isso não tem efeito algum.
Em x86 CMOVS move ESP para EDX, mas não em x64, RDX continua 60h. GS:DEC EAX e CMOVNS não tem efeito também, enquanto em x64 conseguimos o endereço do PEB em RBX.
Em x64 SETZ seta CL = 1. Usamos IMUL para ajustar dinamicamente os offsets para ler Ldr e InLoadOrderModuleList.
PUSH/POP não precisam do prefixo REX, compatível para ambos os modos e é uma ótima trick de otimização. A mesma coisa acontece com SETZ/IMUL que pode ser usado para fazer o parse do PE quando estamos procurando endereços de APIs numa DLL.
Como chamar APIs
W64 se utiliza das chamadas FASTCALL, então algumas APIs vão precisar de slots de 4 QWORD para preencher os registradores, o que chamamos de “shadow space”. Montaremos esses slots utilizando PUSH que em uma STDCALL em W32 tem o efeito de fazer push de um parâmetro. Ficaria assim em W64:
quando encontramos os endereços das APIs que precisamos, damos um push na stack, porém para pegarmos o endereço da API da stack precisamos novamente calcular o offset correto.
A ideia aqui é utilizar o offset da arquitetura x86 e multiplicar por 2 em um código trampoline nomeado no exemplo como jump2api. Então EAX = offset da API, ESI é um ponteiro para os endereços da API na stack:
Esse is64bit é uma espécie de “detection gem” desenvolvido pelo qkumba para uma base de código para malwares autorreplicadores conhecida como beautifulsky (codebase disponível no github):
Aqui XOR define ZF = 1 em ambos os modos. ARPL define ZF = 0 em x86 mas aqui está a pegadinha: em x64, o opcode ARPL é reatribuído como MOVSXD que não altera nenhuma flag.
Bônus: exception handling
Utilizando Vectored Exception Handling é possível criar um handler compatível para ambos os modos. Vejamos como começa nosso handler:
Aqui usamos a trick do prefixo REX/CMOVNS para obter o ponteiro em EXCEPTION_POINTERS em EBX/RBX, onde em x64 é passado para o handler via RCX, e em x86 pela stack.
Usamos CALL para fazer o push na stack para o endereço que usamos para prosseguir a execução substituindo EIP/RIP em CONTEXT, do contrário a execução continuaria onde a exceção aconteceu.
Então, set_newIP representa esse trecho de código:
Aqui obtemos o ponteiro para CONTEXT e calculamos o offset para EIP/RIP e com o POP substituímos o ponteiro com o endereço que foi dado push, então retornamos EXCEPTION_CONTINUE_EXECUTION e a execução prossegue após “call set_newIP”
Hoje (27/10/2023) entrei no YouTube para deixar um vídeo tocando ao fundo enquanto faço minhas coisas e me deparei com o anúncio que não iria tocar o vídeo porque eu estava usando AdBlocker.
Livros e artigos que tratam de pentest no WordPress sempre falam de upload de webshell e obtenção dos usuários que estão na tabela wp_users. Algumas ferramentas usadas na exploração deste CMS como Metasploit e WPScan realizam ambos quase automaticamente. Porém as senhas dos usuários que estão nessa tabela são criptografas com hash e salt. Dependendo da complexidade da senha, é impossível quebrá-la. Então o que fazer?
Em janeiro de 2020 o Python2 deixou de ser mantido pelos desenvolvedores oficiais da linguagem. Mesmo antes, em dezembro de 2019, os desenvolvedores do Kali anunciaram que o Debian (distribuição na qual o Kali é baseado) retiraria o Python2 de seus repositórios, todos os códigos que não fossem atualizados, seriam retirados dos repositórios também e o Kali faria o mesmo. Aí estava marcado o “Fim da Vida” (End-of-Life ou EOL) do Python2.
Um executável do Windows é quase um arquivo compactado. Dentro dele tem código executável, tem imagens, tem certificado digital (as vezes) e podem ter várias outras coisas mais! Mas mesmo com tanta coisa, tudo fica bastante organizado porque segue um formato específico: o formato PE.
Quando conseguimos um shell reverso, geralmente faltam várias coisas que dificultam bastante a interação. Pela falta de um tty, não conseguimos verificar as permissões com “sudo -l”, não conseguimos usar o “vi” e várias outras dificuldades. Então a primeira coisa que costumamos fazer é obter (spawnar) um tty. Porém mesmo após este passo, ainda faltam algumas coisas:
Do “man” do Linux, lemos que “para o propósito de verificação de permissões, tradicionalmente a implementação do UNIX distinguiu duas categorias de processos: privilegiado ( da qual o usuário ID efetivo é 0, referenciado como superusuário ou root), e não-privilegiados (da qual o UID efetivo é diferente de zero). Processos privilegiados contornam todas as verificações do Kernel, enquanto processos não-privilegiados estão sujeitos a verificação total de permissão baseada na credencial do processo (usualmente: UID efetivo, GID efetivo e lista suplementar de grupos)”.
