Resumindo, o ELF Header do crackme.03.32 foi feito com base no Teensy ELF Header do Brian Raiter, ou seja, totalmente à mão, e não pelos assembler e linker (este último que nem foi necessário). Por isso a "mágica" do entrypoint estar na área que pertenceria somente ao Header. ;) Para conseguir isso, utilizei fields do header que são desprezados na inicialização do binário, aglutinando-os e brincando com eles para atingir o "mal necessário".
Outro aspecto do binário é o desofuscamento dinâmico da string 'Omedetou' por meio do algoritmo uzumaki.
Há, também, dois checksums: um do header (com chave criptografada) e o outro do binário inteiro (com chave simples).
Mas tudo isso foi implementado apenas para desviar o cracker do caminho mais simples que é o "patch the jump".
- Criar um crypter customizado.
- Utilizar qualquer esquema de criptografia existente.
- Usar qualquer linguagem de programação.
Criptografia!
O vídeo sobre o assunto demonstra um encrypter e um decrypter, construídos em C, que usam o algoritmo de fluxo RC4 para processar o shellcode. De início eu não contemplei a que fim serviria um shellcode critptografado que não conteria seu decrypter embutido, portanto, agradeço ao Pedro Fausto pela objetiva explanação que me deixou inteirado das possíveis finalidades: uso na comunicação entre dois pontos já comprometidos; uso entre um bastião e seus zumbis...Em suma, para qualquer uso evasivo entre pontos!
Encontrei um algoritmo candidato para a implementação do crypter: TEA - Tiny Encryption Algorithm. Entretanto, vi que ele não seria viável por conta do tamanho que ele teria em assembly; haja vista não ter aberto mão de criar o built-in decrypter.
Só tinha uma maneira, criar meu próprio tiny cipher.
Uzumaki Cipher (Swirling Everything)
Usei os moldes da Stream Cipher para criar o Uzumaki (うずまき) Cipher; a cifra consiste no processo de um XOR com um valor estático, seguido de mais um XOR com um valor pseudorandom (keystream), terminando com o ADD de um valor estático.
O uzumaki cipher é um algoritmo simples que pode ser utilizado com sucesso em shellcodes quando o assunto é evasão. Devo ressaltar que um dado criptografado, para sua própria segurança, não deve conter informações que possam levar à desencriptação; assim, o built-in decrypter do fluxograma acima (no git com código comentado) foi criado apenas como uma PoC. Contudo, nada obsta seu uso.
Uso
# ./uzumaki_crypter.py -a 01 -x 5d -s $'\x31\xc9\xf7\xe1\xb0\x0b\x51\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\xcd\x80'
É isso aí pessoal! Essa foi a última missão do curso SLAE! E até que foi simples, porque no decorrer dos posts, aprendemos muitas formas de utilizar a linguagem assembly para a criação de vários tipos de shellcodes.
Com este post prosseguiremos as missões do curso SLAE.
Gostaria de ressaltar que, no último vídeo do treinamento, Vivek determinou que o aluno que reduzir os shellcodes e/ou tê-los aceitos em repositórios receberá pontuação extra para a certificação.
Eu venho tentando, além de reduzir o tamanho, criar versões dos shellcodes com propriedades singulares; exemplos são o Shell Bind TCP (GetPC) e o Shell Bind TCP (com REUSE), este que acabou originando o Tiny Shell Bind TCP Random Port (57 bytes).
Porém, nesta missão, Vivek foi claro quanto à originalidade do shellcode. Ou seja, neste payload, o que importará realmente é o engendramento de um método de inserção divergente do que ele demonstrou em aula.
Insertion Decoder
Um Shellcode Insertion Decoder realiza o realinhamento de um shellcode devidamente encodado com inserção de garbage bytes. Sua utilização é voltada para a tentativa de bypass de ferramentas que detectam injeção de shellcode.
Na respectiva aula ele cria um decoder sequencial que substitui gargabe bytes ao copiar o byte verdadeiro na sequencia correta. Inicialmente, pensei em apenas remodelar o padrão de inserção da versão dele para, em vez de fazer o decoding de apenas um garbage byte (x_x_x_), fazer de dois (x__x__x__). Mas nem cheguei a amadurecer a ideia, desisti ao realizar que tal modificação não seria nem original muito menos útil num caso concreto.
Cachola para que te quero?!
Após alguns dias da resignação à ideia anterior, eis que me acendeu uma luz acima da cabeça! Por que não criar um decoder com análise para qualquer padrão? Deixando nas mãos do usuário a possibilidade de inserir o lixo no shellcode da forma que melhor lhe aprouver? Isso sim seria original!
Why not?!
Assembly e C (perfect couple)
O shellcode exigido na missão era o do execve_stack já corretamente encodado. Como um plus, reduzi o tamanho dele engendrando o Tiny Execve Sh (21 bytes), cujos código e shellcode podem ser visualizados no github.
Inseri o garbage byte em posições aleatórias dentro desse shellcode e, após um estudo algorítmico concretizei o decoder em asm como podem ver abaixo.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
O que ele faz é percorrer a área da memória na qual o shellcode está inserido, comparando o byte lido com o byte lixo, e reordenando-os quando resolvidas as condições. Dúvidas? Leia o código fonte, está bem comentado.
Pronto para publicar!
Logo após ter feito push no git, já me preparando para escrever este post, tweetei para o Vivek!
Wow!
Ele não só apenas gostou do decoder, pediu também que eu fizesse um extra:
Nunca tinha programado em python, a não ser modificado algum pedaço de código ou lido rapidamente. Entretanto, sempre ouvi falar que é uma ótima linguagem para aprender, assim como para diversos outros fins.
The campaign begins...
Um obstáculo:
- Uso de argumentos para receber o shellcode e demais parâmetros.
Não estava conseguindo preencher a variável shellcode da forma correta... descobri, após garimpar os pergaminhos do python, que era por conta da necessidade do uso de encoding. Mas mesmo usando o encode(), este baggins não conseguia fazer com que a string shellcode ficasse como bytearray. Até que o wizard sigsegv empunhou o seu cajado proclamando: error handler surrogateescape. Valeu, sig!
Outro obstáculo:
- Bytes, Strings...
Continuando na campanha, precisei comparar, em alguns casos, string a byte... como era meu primeiro contato com a linguagem quase fui cozido por alguns trolls até me lembrar de umas dicas dadas pelo Pedro Fausto, um Dwarf que guerreia distante do Reino perdido de Erebor. hex() e int() foram suas armas. Valeu, Pedro!
Epílogo
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Gandalf: Saruman believes it is only great power that can hold evil in check, but that is not what I have found. I found it is the small everyday deeds of ordinary folk that keep the darkness at bay... small acts of kindness and love. Why Bilbo Baggins? That's because I am afraid and it gives me courage.