0% acharam este documento útil (0 voto)

4 visualizações116 páginas

Código Shell Windows: Guia Prático

Enviado por

uvm8455

Direitos autorais

Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.

Formatos disponíveis

Baixe no formato PDF, TXT ou leia on-line no Scribd

0% acharam este documento útil (0 voto)

4 visualizações116 páginas

Código Shell Windows: Guia Prático

Enviado por

uvm8455

Direitos autorais

Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.

Formatos disponíveis

Baixe no formato PDF, TXT ou leia on-line no Scribd

Machine Translated by Google

Código Shell do Windows

Seção 0 2 | M ódulo 0 5
© Caendra Inc. 2019
Todos os direitos reservados
Machine Translated by Google

Índice

MÓDULO 05 | CÓDIGO DE SHELL DO WINDOWS

5.1 Shellcode básico do Windows

5.2 Shellcode universal

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.2

Machine Translated by Google

objetivos de aprendizado

Ao final deste módulo, você deverá ter uma melhor

compreensão de:

ÿ Por que o shellcode é

importante ÿ Como criar diferentes tipos de shellcode

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.3

Machine Translated by Google

5.1

Janelas Básicas
Código Shell

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.4

Machine Translated by Google

5.1 Shellcode básico do Windows

Shellcode é a parte mais importante de cada exploração. No

fundo, ele nos permite executar certas tarefas que a
exploração pretende realizar. Quando você usa o Metasploit
contra qualquer software, a opção PAYLOAD é na verdade
o shellcode com o qual o exploit será armado.

A maneira mais fácil de obter um shellcode para seu exploit é

procurá-lo na web (por exemplo, shellstorm ou cut se for de
exploits existentes) ou simplesmente gerá-lo com msfvenom.
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.5
Machine Translated by Google

5.1 Shellcode básico do Windows

Essas opções são bastante autoexplicativas e não requerem

nenhum conhecimento avançado para utilizá-las.

No entanto, pode haver casos em que algumas explorações

não funcionem devido ao comportamento inadequado do
shellcode ou casos em que você precise realizar uma tarefa
incomum por meio do seu shellcode. Para tais casos, você
deve ser capaz de escrever e depurar shellcode manualmente.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.6

Machine Translated by Google

5.1 Shellcode básico do Windows

O próprio Shellcode consiste em opcodes brutos do processador. Não

é nem assembly – são bytes brutos responsáveis pela execução
de certas tarefas. É por isso que ele pode ser colocado em um
buffer do usuário e ao transferir a execução para ele, certas coisas
podem ser realizadas (por exemplo, gerar um cálculo).

Como a linguagem Assembly é a coisa mais próxima da linguagem

de máquina, é a melhor escolha para escrever shellcode. Como
traduzimos assembly em opcodes?
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.7
Machine Translated by Google

5.1 Shellcode básico do Windows

Precisamos de um compilador Assembly. Por exemplo, NASM se

encaixará perfeitamente nessa função. Você pode baixá-lo no link
abaixo: [Link]

Basta escolher a versão adequada ao seu sistema operacional.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.8

Machine Translated by Google

5.1.1 Linguagem de Máquina

Compilar um arquivo Assembly em um arquivo binário que contém

opcodes em linguagem de máquina é fácil e pode ser feito com:

[Link] [Link] -o [Link]

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.9

Machine Translated by Google

5.1.1 Linguagem de Máquina

A próxima etapa é traduzir o arquivo .bin, que é um arquivo binário, em uma

representação hexadecimal dos bytes contidos.
Dessa forma, podemos incorporar convenientemente os opcodes
desejados em uma exploração.

Isso pode ser feito usando uma ferramenta automática.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.10

Machine Translated by Google

5.1.1 Linguagem de Máquina

Felizmente, existe uma variedade dessas ferramentas na

Internet; por
exemplo: [Link]

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.11

Machine Translated by Google

5.1.1 Linguagem de Máquina

Vamos agora compilar um programa Assembly simples (que

não faz nada significativo) apenas com o propósito
de mostrar o processo.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.12

Machine Translated by Google

5.1.1 Linguagem de Máquina

Usando este método, criaremos o shellcode, mas ainda há

algumas coisas a fazer até que esteja realmente funcional.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.13

Machine Translated by Google

5.1.2 Chamando funções do Windows

No Linux, o shellcode pode ser escrito usando certas chamadas de

sistema. Basicamente, precisamos apenas preencher os registros com
determinados valores e chamar um syscall do Linux; syscalls
nos permitem comunicar com as funções integradas do sistema
operacional (chamadas) como read(), write(), system(). No Windows,
escrever shellcode é um pouco mais complicado.

O sistema operacional Windows usa WinAPI para permitir que os

usuários utilizem determinadas funcionalidades. WinAPI é um conjunto
de funções armazenadas em DLLs padrão do sistema.
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.14
Machine Translated by Google

5.1.2 Chamando funções do Windows

DLLs (Dynamic-Link Libraries) são arquivos em formato

executável do Windows que contêm funções. Para fazer uso das funções
que uma DLL contém, um aplicativo precisa carregar essa DLL em
seu próprio espaço de endereço.

Da mesma forma que importa o tempo em Python para usar [Link],

você precisa carregar uma DLL para usar as funções que ela contém.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.15

Machine Translated by Google

[Link] Bibliotecas de links dinâmicos

Tecnicamente falando, se uma DLL contém algumas funções que podem ser
utilizadas após o carregamento da biblioteca, dizemos que esta DLL exporta
essas funções.

Para usar as funções exportadas de uma DLL, um programa que deseja

utilizá-las deve:
• Incluir uma biblioteca dll em seu espaço de endereço (carregá-la)
• Chame determinada função pelo seu nome

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.16

Machine Translated by Google

[Link] Bibliotecas de links dinâmicos

Por exemplo, se quisermos chamar o messageBox de um

programa, precisamos que ele:
• Carregar a biblioteca [Link]
• Chame MessageBoxA com argumentos adequados

De uma perspectiva de baixo nível do Assembly – primeiro

algumas instruções devem ser executadas para colocar
os argumentos da função na pilha. Então a função pode ser
chamada, mas é necessário saber seu endereço.
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.17
Machine Translated by Google

[Link] Bibliotecas de links dinâmicos

Quando um aplicativo carrega uma biblioteca DLL, ela é mapeada

na memória do aplicativo. Isso significa que ele recebe um determinado
endereço dentro do espaço de endereço desse aplicativo.

Antes do Vista, o Windows não utilizava ASLR, e esse endereço

era sempre o mesmo para determinadas DLLs entre os sistemas
operacionais das mesmas versões de service pack.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.18

Machine Translated by Google

5.1.3 Dentro do Espaço de Endereço do Processo

Cada DLL contém um mapa da função que utiliza. Cada função

está disponível em um determinado deslocamento estático do
endereço base da biblioteca.

O endereço da função em uma DLL é chamado RVA (Relative Virtual

Address). É relativo ao endereço base no qual a DLL pai da função
foi mapeada.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.19

Machine Translated by Google

5.1.3 Dentro do Espaço de Endereço do Processo

Para visualizar o endereço para o qual uma determinada função está

mapeada, podemos usar o depurador de imunidade durante o tempo de
execução do aplicativo. O depurador precisa ser anexado a ele.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.20

Machine Translated by Google

5.1.3 Dentro do Espaço de Endereço do Processo

Selecione “Exibir -> Módulos executáveis” e clique com o botão direito

em uma biblioteca e escolha “Exibir nomes”.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.21

Machine Translated by Google

5.1.3 Dentro do Espaço de Endereço do Processo

Na janela você pode ver todas as

funções que o módulo contém,
junto com seus endereços.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.22

Machine Translated by Google

5.1.3 Dentro do Espaço de Endereço do Processo

Para verificações estáticas, sem iniciar um depurador, você pode usar

a ferramenta Arwin.

Arwin é um software simples que utiliza funções do Windows para localizar

uma biblioteca, carregá-la e obter o endereço da função desejada que
ela contém.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.23

Machine Translated by Google

5.1.3 Dentro do Espaço de Endereço do Processo

Você pode baixá-lo aqui: https://

[Link]/tutorials/expDev/tools/[Link]

Você também pode multar o código-fonte aqui:

[Link]

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.24

Machine Translated by Google

5.1.3 Dentro do Espaço de Endereço do Processo

Podemos usar a ferramenta pré-compilada do primeiro URL.

Veja um exemplo de como o Arwin pode ser usado abaixo.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.25

Machine Translated by Google

5.1.4 Ordem dos Argumentos

Quando uma função é chamada em uma aplicação, podemos

ver no depurador que antes da chamada da função seus
argumentos são colocados na pilha junto com o endereço de retorno.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.26

Machine Translated by Google

5.1.4 Ordem dos Argumentos

Se quisermos chamar uma função do sistema da perspectiva do

Assembly, precisamos emular esta situação usando instruções push.

Por exemplo, a pilha deve ficar assim:

[ESP +] [ENDEREÇO DE RETORNO]

[ESP + 4] [PRIMEIRO ARGUMENTO]
[ESP + 8] [SEGUNDO ARGUMENTO]

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.27

Machine Translated by Google

5.1.4 Ordem dos Argumentos

Quando os argumentos estão na pilha, o EIP deve apontar para

a função de destino. Então a função será chamada com os
parâmetros adequados.

Do ponto de vista do shellcode, deve ser semelhante a:

push Second_ARG push

First_ARG push

Return_address
função de chamada

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.28

Machine Translated by Google

[Link] O problema com strings

Assembly nos permite colocar um certo número na pilha, mas

não strings. A maioria das funções requer ponteiros para strings
como parâmetro.

Para obter um ponteiro para uma string podemos:

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.29

Machine Translated by Google

[Link] O problema com strings

1. Encontre uma ocorrência da string desejada na memória e lembre-se

de seu endereço.

2. Coloque a string na pilha e salve um ponteiro nela.

O segundo método é muito mais confiável e será preferido durante

o desenvolvimento do shellcode.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.30

Machine Translated by Google

[Link] O problema com strings

Por exemplo, vamos considerar a seguinte montagem:

XOR EBX, EBX; EBX agora é igual a 0

PRESSIONE EBX; empurre 0 para a pilha.
PRESSIONE \x2e\x65\x78\x65; “.exe” - devido ao endianismo, empurramos primeiro o final da string.

PRESSIONE \x63\x61\x6c\x63; “calc”, o início da string.

MOV ECX, ESP; Salve o valor atual do ESP no ECX. O valor atual de ESP é o endereço
do início da string terminada em nulo “[Link]”. Como não diminuiremos a pilha entre o
shellcode, este endereço permanecerá o mesmo

para que possamos salvá-lo no ECX.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.31

Machine Translated by Google

5.1.5 Escrevendo Shellcode

Vamos agora tentar criar um shellcode simples usando os

exemplos mencionados acima. O shellcode será baseado
em WinExec().

Winexec() é uma função popular entre os desenvolvedores de shellcode.

Funciona de maneira semelhante a system() no Linux. Ele executa
programas do Windows fornecidos em seus argumentos da
mesma forma que você os digitaria em uma linha cmd.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.32

Machine Translated by Google

5.1.5 Escrevendo Shellcode

Você pode ler mais sobre esta função no site da Microsoft.

[Link]
windows/win32/api/winbase/nf-winbase-winexec

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.33

Machine Translated by Google

[Link] Testando Shellcode

A última coisa que precisamos para escrever um shellcode funcional

é emular um estouro de pilha.

Durante a exploração de estouro de pilha, escrevemos diretamente

na memória do programa. Podemos obter o mesmo efeito usando C/C+
+ no Windows.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.34

Machine Translated by Google

[Link] Testando Shellcode

Considere o seguinte código.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.35

Machine Translated by Google

[Link] Testando Shellcode

Tudo o que esse código faz é alocar uma parte da memória, torná-la
executável, copiar o shellcode naquele local e então começar a
executá-lo.

Vale a pena ter esse aplicativo com a finalidade de testar o

shellcode antes de ser implementado em explorações. É útil ao
depurar um exploit, quando você precisa ter certeza de que seu
shellcode funciona conforme o esperado.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.36

Machine Translated by Google

[Link] Testando Shellcode

Vamos tentar colar um shellcode gerado pelo msfvenom no referido

programa e compilá-lo em Dev-c++. Você pode usar qualquer compilador
de sua preferência, embora neste caso usaremos Dev-c++.

Precisamos excluir zeros, pois isso encerrará nossa string, portanto,

marcaremos instantaneamente como um caractere inválido na geração.

msfvenom -p windows/exec cmd=[Link] exitfunc=thread -fc -b "\x00"

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.37

Machine Translated by Google

[Link] Testando Shellcode

Vamos executar o programa compilado:

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.38

Machine Translated by Google

[Link] Testando Shellcode

Ótimo! Parece que o shellcode

funciona conforme o esperado.

Como agora temos todas as

ferramentas necessárias, vamos escrever o

shellcode do zero.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.39

Machine Translated by Google

[Link] Shellcode básico

Primeiro, precisamos descobrir o endereço Winexec(). Isso pode

ser feito usando o Arwin, como segue.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.40

Machine Translated by Google

[Link] Shellcode básico

Outra coisa a lembrar é que quando colocamos strings na pilha,

precisamos colocá-las na ordem inversa devido ao endianismo. Então,
quando quisermos pressionar “[Link]\0”, na verdade deveríamos :

• Pressione 0

• Pressione “exe”.

• Pressione “clac”

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.41

Machine Translated by Google

[Link] Shellcode básico

O código Assembly que executa calc por meio de Winexec()

pode ser escrito da seguinte maneira.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.42

Machine Translated by Google

[Link] Shellcode básico

Depois de executar calc, ele sai suavemente usando

a função ExitProcess(). Agora vamos compilá-lo usando Nasm.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.43

Machine Translated by Google

[Link] Shellcode básico

Em seguida, extrairemos os opcodes usando bin2sc, como segue.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.44

Machine Translated by Google

[Link] Shellcode básico

Agora, vamos copiar os opcodes para o testador de shellcode e

compilá-los.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.45

Machine Translated by Google

[Link] Shellcode básico

A execução do programa compilado fornece o seguinte resultado.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.46

Machine Translated by Google

[Link] Uma saída elegante

Estamos quase terminando. A última coisa que precisa ser

feita é fazer com que o shellcode saia normalmente, em vez de
causar uma falha de segmentação confusa.

Adicionaremos outra parte do shellcode após a execução do

cálculo. Primeiro, vamos encontrar o endereço de ExitProcess()
usando Arwin, como segue.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.47

Machine Translated by Google

[Link] Uma saída elegante

Queremos que o processo retorne 0, então precisamos

colocar 0 na pilha antes de chamar ExitProcess().

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.48

Machine Translated by Google

[Link] Uma saída elegante

Vamos compilá-lo e extrair os opcodes.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.49

Machine Translated by Google

[Link] Uma saída elegante

Em seguida, iremos adicioná-lo ao “testador de shellcode” e executar

o programa compilado.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.50

Machine Translated by Google

[Link] Uma saída elegante

Agora o aplicativo não exibe

nenhum erro – vemos apenas
calc sendo executado.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.51

Machine Translated by Google

5.2

Shellcode universal

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.52

Machine Translated by Google

5.2 Shellcode universal

O shellcode que acabamos de introduzir é pequeno e não produz corrupção
de memória ao sair. No entanto, também tem algumas desvantagens.

O principal problema é que esse shellcode contém endereços

codificados, o que significa que ele só pode ser usado em uma
determinada versão do sistema – neste caso, o Windows XP SP1.

Conforme mencionado anteriormente, todas as DLLs do sistema são

carregadas em endereços estáticos no mesmo nível de service pack.
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.53
Machine Translated by Google

5.2 Shellcode Universal

Devido a isso, o shellcode que funciona no XP SP1 não pode ser

usado no SP2 ou SP3.

Nosso próximo passo será criar um shellcode universal que será

executado em qualquer service pack sem endereços codificados.
Como isso pode ser feito?

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.54

Machine Translated by Google

5.2.1 Sistema Estruturado

O Windows é um sistema muito bem organizado. Cada processo, além

dos dados do programa, também contém alguns elementos de controle do
Sistema Operacional.

Esses elementos são dados organizados em estruturas.

Estruturas são tipos de dados C/C++, semelhantes a arrays.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.55

Machine Translated by Google

5.2.1 Sistema Estruturado

Algumas das estruturas são documentadas pela Microsoft em seu

site oficial.

Outra parte deles foi revertida por outras pessoas e organizações e

disponibilizada publicamente. Essas estruturas são chamadas de
“não documentadas” porque oficialmente não há documentação
disponível para elas.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.56

Machine Translated by Google

5.2.1 Sistema Estruturado

As estruturas armazenam os dados de maneira organizada – são como

tabelas em um banco de dados. Cada campo de uma estrutura
pode ser de um tipo diferente, mas devem ser predefinidos.

Como você já sabe, cada tipo de dados possui um tamanho específico

em bytes que não pode ser excedido. Saber quais tipos de dados são
membros (campos) de uma estrutura fornece informações sobre
quando um determinado campo começa e termina, e indo além –
em qual deslocamento do início da estrutura um determinado campo pode
ser encontrado.
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.57
Machine Translated by Google

5.2.1 Sistema Estruturado

Ao contrário de um banco de dados onde todos os tipos de dados são

conhecidos como varchar, timestamp, int, etc., os tipos de dados nas
estruturas do Windows são, na maioria dos casos, personalizados.

Eles foram criados pela Microsoft, portanto é perfeitamente normal que uma
estrutura consista em tipos de dados que possam ser novos para você. A única
maneira de saber qual quantidade de memória é necessária para armazenar
um determinado tipo de dados é ler a documentação ou, se não
estiver presente, tentar fazer engenharia reversa da estrutura.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.58

Machine Translated by Google

5.2.1 Sistema Estruturado

Felizmente, neste módulo, contaremos com estruturas já revertidas

ou documentadas.

O tamanho ou nome específico de cada um deles pode ser diferente dos

tipos de dados C/C++ usuais, mas se você quiser se sentir
confortável com a depuração e exploração de um ambiente
Windows, você deve se acostumar com eles.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.59

Machine Translated by Google

5.2.1 Sistema Estruturado

Muitas estruturas estão aninhadas umas nas outras – na verdade, o

Windows é construído sobre elas.

Você verá nos próximos slides que existem estruturas que contêm estruturas
que contêm outras estruturas... e todas elas são usadas para construir
uma base funcional e bem organizada para executar um processo
no ambiente Windows.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.60

Machine Translated by Google

5.2.2 Percorrendo os metadados

Da mesma forma que as informações do manipulador de exceções, que

costumavam ser armazenadas em FS:[0], existem outras informações
interessantes armazenadas na memória do processo.

Uma dessas estruturas interessantes é o Process Environment Block (PEB).

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.61

Machine Translated by Google

5.2.2 Percorrendo os metadados

Sua estrutura pode ser

definida da seguinte forma.

[Link] XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.62

Machine Translated by Google

5.2.2 Percorrendo os Metadados

Os campos denominados “Reservados” não estão documentados.

No entanto, a única coisa interessante aqui por enquanto são os

deslocamentos e os tamanhos dos tipos de dados. Se conseguirmos encontrar
o início de uma estrutura e conhecermos os deslocamentos, poderemos navegar
para qualquer campo que ela contenha - mesmo que esteja aninhado bem no fundo.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.63

Machine Translated by Google

5.2.2 Percorrendo os metadados

A ideia por trás de todas essas informações detalhadas sobre

estruturas é que se conseguirmos acessar o PEB, descobriu- se que é
possível obter o endereço de algumas bibliotecas e funções nelas contidas.
Assim, será possível emular o Arwin durante o tempo de execução
e recuperar o endereço atual de certas funções em vez de codificá-
las.

Então, eles podem ser usados posteriormente dentro do shellcode.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.64

Machine Translated by Google

5.2.2 Percorrendo os Metadados

A desvantagem é que o shellcode aumentará de tamanho.

A vantagem é que ele se tornará universal e poderá ser usado em todos
os service packs de determinados sistemas operacionais Windows.

Apresentaremos em breve onde estão alguns dados interessantes a partir

do endereço do PEB. Em seguida, prosseguiremos para transformá-lo em
shellcode real.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.65

Machine Translated by Google

5.2.2 Percorrendo os metadados

As estruturas do Windows podem ser percorridas da seguinte maneira:

• O endereço PEB é mantido no Thread Environment Block, 0x30
bytes desde o início. O endereço do TEB é mantido no
registrador do segmento FS e pode ser codificado em shell
(para sabermos o ponto de partida).
• PEB + 0xC Bytes contém o ponteiro para PEB_LDR_DATA, que
contém informações sobre DLLs carregadas, na forma de uma
lista duplamente vinculada.

[Link] XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.66

Machine Translated by Google

5.2.2 Percorrendo os metadados

• Em PEB_LDR_DATA, 0x14 bytes desde seu início existe um

ponteiro para a primeira DLL carregada na memória em
uma lista chamada InMemoryOrderModuleList.
• No Windows XP (todos os service packs), [Link] e
[Link] reside na segunda e terceira entradas,
respectivamente. Lembra da ferramenta Arwin que utilizava
funções [Link] para obter dados sobre o endereço
de uma função? Podemos fazer o mesmo na Assembleia.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.67

Machine Translated by Google

5.2.2 Percorrendo os metadados

Isso pode ser conseguido usando o seguinte código Assembly.

mov ebx, fs:0x30 ; Obter ponteiro para PEB

mov ebx, [ebx + 0x0C] ; Obtenha o ponteiro para PEB_LDR_DATA
mov ebx, [ebx + 0x14] ; Obtenha o ponteiro para a primeira entrada em InMemoryOrderModuleList
mov ebx, [ebx] ; Obtenha o ponteiro para a segunda entrada ([Link]) em InMemoryOrderModuleList
mov ebx, [ebx] ; Obtenha o ponteiro para a terceira entrada ([Link]) em InMemoryOrderModuleList
mov ebx, [ebx + 0x10] ; Obtenha o endereço base [Link]

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.68

Machine Translated by Google

5.2.2 Percorrendo os metadados

O código do slide anterior, quando compilado, tem uma grande

desvantagem – contém bytes nulos.

Portanto, não pode ser colocado em nenhum buffer de exploração.

Para nos livrarmos deles, precisamos refatorar um pouco o código.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.69

Machine Translated by Google

5.2.2 Percorrendo os metadados

Felizmente, não é tão complicado.

xor esi, esi ; esi = 0
mov ebx, [fs:30h + esi] ; escrito desta forma para evitar bytes nulos
mov ebx, [ebx + 0x0C]
mov ebx, [ebx + 0x14]
mov ebx, [ebx]
mov ebx, [ebx]
mov ebx, [ebx + 0x10] ; ebx contém endereço base [Link]
mov [ebp-8], ebx ; var8 = endereço base [Link]

O resultado do shellcode acima é o endereço de [Link]

sendo armazenado no registro ebx. Vamos agora
descobrir como podemos encontrar o endereço WinExec() usando-o
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.70
Machine Translated by Google

5.2.3 Endereço Base da Função

Um arquivo DLL, uma biblioteca de vínculo dinâmico, é um arquivo no

formato PE (Portable Executable). Novamente, este formato de
arquivo possui alguns metadados estruturados que podem ser percorridos
para obter informações interessantes.

Ao falar sobre uma imagem de arquivo executável PE, podemos usar o

termo RVA (Relative Virtual Address). RVA é o endereço relativo ao
início da imagem do arquivo, portanto , essencialmente, o
deslocamento do endereço base. Além disso, ao falar sobre DLLs, o
termo “Exportar” será frequentemente usado.
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.71
Machine Translated by Google

5.2.3 Endereço Base da Função

Resumindo, as funções de exportação de DLL são as funções que ela

contém, que podem ser utilizadas ao carregar a biblioteca na memória do
processo.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.72

Machine Translated by Google

[Link] Percorrendo mais metadados

No formato PE existem as seguintes estruturas:

• No RVA 0x78 (offset do início da imagem do arquivo) a Tabela de
Exportação é armazenada. A Tabela de Exportação contém
informações sobre todas as funções contidas na DLL.
• Exportar tabela + 0x14 contém diversas funções que a DLL
exporta.
• Tabela de exportação + 0x1C é a tabela de endereços que contém
todos os endereços das funções exportadas.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.73

Machine Translated by Google

[Link] Percorrendo mais metadados

• Export Table + 0x20 é a Name Pointer Table, onde são armazenados

ponteiros para os nomes das funções exportadas .

• Export Table + 0x24 é a Tabela Ordinal, onde são armazenadas as

posições das funções na Tabela de Endereços.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.74

Machine Translated by Google

[Link] Percorrendo mais metadados

Vamos tentar descobrir o que exatamente é necessário para obter o endereço
de uma determinada função.
• Primeiro, encontramos o deslocamento da assinatura PE (RVA) (endereço
base + 0x3c).
• Encontramos então o endereço da assinatura PE (endereço base +
RVA).
• A seguir encontramos o RVA da Tabela de Exportação (assinatura PE +
0x78).
• Com base no RVA, encontramos o endereço da Tabela de Exportação
(endereço base + RVA da tabela de exportação).
• Em seguida encontramos o RVA da tabela de endereços (tabela de exportação +
0x1C).
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.75
Machine Translated by Google

[Link] Percorrendo mais metadados

• A seguir, encontramos o endereço da Tabela de Endereços (endereço base + RVA da
tabela de endereços).

• Em seguida, encontre o RVA da Name Pointer Table (tabela de exportação +

0x20).

• Em seguida, encontre o Endereço da Tabela de Ponteiros de Nomes ( endereço

base + RVA da Tabela de Ponteiros de Nomes).

• As duas últimas etapas serão encontrar o RVA da Tabela Ordinal

(Tabela de Exportação + 0x24).

• Depois calcularemos o endereço da Tabela Ordinal (usando

endereço base + RVA da tabela ordinal).
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.76
Machine Translated by Google

[Link] Percorrendo mais metadados

Em seguida, precisamos criar um loop. O loop passará pela tabela

de ponteiros de nomes (já que temos seu endereço) e comparará
cada entrada com a string “WinExec” enquanto lembra o índice
na tabela do item atualmente verificado.

Quando terminar, precisamos encontrar um índice da

função WinExec na Tabela Ordinal (Endereço do Ordinal +
(índice *2)) – pois cada registro na tabela tem 2 bytes de tamanho.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.77

Machine Translated by Google

[Link] Percorrendo mais metadados

Usando o número ordinal, vamos da Tabela de Endereços para a

posição Tabela de Endereços + (Número Ordinal * 4), pois cada
entrada da Tabela Ordinal tem 4 bytes de tamanho.

Conhecendo o RVA, podemos encontrar o endereço da função

adicionando o RVA ao endereço base da DLL.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.78

Machine Translated by Google

[Link] Mitigando bytes nulos únicos

Vamos começar colocando a string “WinExec” na pilha.

Precisaremos lembrar sua localização e usá-la como referência para um
nome que deverá ser encontrado na DLL.

Se você tentar simplesmente xor esi e, em seguida, pressionar esi que

contém 0 após a operação xor e, em seguida, pressionar
a string “WinExec”, você acabará lidando com bytes nulos. Como a pilha
está alinhada em 4 bytes, não podemos simplesmente enviar Winexec,
que tem 7 bytes.
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.79
Machine Translated by Google

[Link] Mitigando bytes nulos únicos

Se você fizer xor de um registrador consigo mesmo e então pressioná-lo, um registrador

de tamanho inteiro será enviado (0x00000000), enquanto precisamos apenas de
um “00”.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.80

Machine Translated by Google

[Link] Mitigando bytes nulos únicos

Assim, usaremos um truque para colocar a string WinExec\00 na pilha.

Devido ao endianness, podemos realmente enviar push:

\x00cex primeiro e depois pressione

EniW

Portanto, só precisamos nos preocupar com o primeiro empurrão. Não

podemos pressionar 0 diretamente, mas como ASCII é uma das maneiras
pelas quais os bytes brutos são interpretados, podemos simplesmente enviar
alguns números que representam caracteres ASCII.
XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.81
Machine Translated by Google

[Link] Mitigando bytes nulos únicos

Se tentarmos enviar 0x00636578 (\x00cex), lidaremos com bytes

nulos novamente.

Mas podemos enviar um número que é incrementado por um valor

de escolha (que não contém bytes nulos).

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.82

Machine Translated by Google

[Link] Mitigando bytes nulos únicos

Por exemplo, podemos escolher 0x01010101. Vamos adicioná-

lo ao valor acima, o que resulta em:

0x00636578 (\x00cex) +
0x01010101
--------------------
0x01646679

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.83

Machine Translated by Google

[Link] Mitigando bytes nulos únicos

Então, agora
precisamos: • mov reg,
0x01646679 • sub reg,
0x01010101 • push reg

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.84

Machine Translated by Google

[Link] Mitigando bytes nulos únicos

Usando este método, podemos colocar bytes nulos únicos na

pilha, contrabandeando-os dentro da aritmética simples.

Dessa forma, muitas restrições de caracteres inválidos podem

ser evitadas colocando valores “seguros” em um registro,
modificando-os usando aritmética para que reflitam os valores
ASCII desejados e, no final, colocando-os na pilha.

XDSv1: Seção 2, Módulo 5 - Caendra Inc. © 2019 | pág.85

Machine Translated by Google

[Link] Mitigando bytes nulos únicos

O código para enviar winexec será semelhante ao abaixo.

xor esi, esi

mov esi, 0x01646679 sub esi,
0x01010101 push esi; truque
de byte nulo push 456e6957h

mov [ebp-4], esp ; var4 = "WinExec\x00"

Machine Translated by Google

[Link] Buscando a Função

Vamos voltar nossa atenção para a rotina de busca de

funções; precisamos refletir o algoritmo de passagem de
estrutura que acabamos de descrever.

O name push do Winexec também será implementado nele.

Machine Translated by Google

[Link] Buscando a Função

mov eax, [ebx + 3Ch] ; RVA de assinatura PE

adicione eax, ; Endereço da assinatura PE = base
endereço ebx + RVA da assinatura PE
mov eax, [eax + 78h] ; RVA da Tabela de Exportação
adicione eax, ebx ; Endereço da Tabela de Exportação

mov ecx, [eax + 24h] ; RVA da Tabela Ordinal

adicionar ecx, ebx ; Endereço da Tabela Ordinal
mov [ebp-0Ch], ecx ; var12 = Endereço da Tabela Ordinal

mov edi, [eax + 20h] ; RVA da tabela de ponteiros de nomes

adicione edi, ebx ; Endereço da tabela de ponteiros de nomes

mov [ebp-10h], edi ; var16 = Endereço da tabela de ponteiros de nomes

Machine Translated by Google

[Link] Buscando a Função

mov edi, [eax + 20h] ; RVA da tabela de ponteiros de nomes

adicione edi, ebx ; Endereço da tabela de ponteiros de nomes

mov [ebp-10h], edição ; var16 = Endereço do ponteiro do nome

Mesa

mov edx, [eax + 1Ch] ; RVA da Tabela de Endereços

adicionar edx, ebx ; Endereço da tabela de endereços

mov [ebp-14h], edx ; var20 = Endereço da Tabela de Endereços

mov edx, [eax + 14h] ; Número de funções exportadas

xor eax, eax ; contador = 0

Machine Translated by Google

[Link] Buscando a Função

.laço:
mov edi, [ebp-10h] ; edi = var16 = Endereço da tabela de ponteiros de nomes
mov esi, [ebp-4] ; esi = var4 = "WinExec\x00"
xor ecx, ecx

cld ; definir DF = 0 => processar strings da esquerda para a direita

mov edi, [edi + eax*4] ; As entradas na tabela de ponteiros de nomes têm 4 bytes de comprimento
; edi = RVA Enésima entrada = Endereço da Tabela de Nomes * 4
adicione edi, ebx ; edi = endereço da string = endereço base + RVA enésima entrada
adicione cx, 8 ; Comprimento das strings para comparar (len('WinExec') = 8)
repe cmpsb ; Compare os primeiros 8 bytes de strings em ; registros esi e edi. ZF=1
se for igual, ZF=0 se não
jz [Link]

aumento eax ; contador++

cmp eax, edx jb ; verifique se a última função foi alcançada
[Link] ; se não for o último -> loop

adicionar esp, 26h

jmp iní[Link] ; se a função não for encontrada, pule para o final

Machine Translated by Google

[Link] Buscando a Função

.encontrado:

; o contador (eax) agora ocupa a posição de WinExec

mov ecx, [ebp-0Ch] mov edx, ; ecx = var12 = Endereço da tabela ordinal
[ebp-14h] ; edx = var20 = Endereço da Tabela de Endereços

mov machado, [ecx + eax2] ; machado = número ordinal = var12 + (contador 2)

mov eax, [edx + eax*4] ; eax = RVA da função = var20 + (ordinal * 4)
adicione eax, ebx ; eax = endereço do WinExec =
; = endereço base [Link] + RVA do WinExec

Machine Translated by Google

[Link] Buscando a Função

Ao final do shellcode resultante, o endereço do WinExec será

mantido em EAX. A última coisa que precisamos fazer é colocar o
argumento do WinExec (o binário que queremos executar) na pilha.

Também usaremos o segundo argumento, estado da janela neste caso, e

usaremos seu valor padrão SW_SHOWDEFAULT, que também pode ser
passado como o número “10”.

Machine Translated by Google

[Link] Finalizando o Shellcode

Enviaremos todo o caminho para o binário. Como ele está perfeitamente
alinhado com 4 bytes, não precisaremos fazer o truque push – podemos
enviar com segurança um registro com valor zero e então enviar todo o
caminho em porções de 4 bytes.

xor edx, edx

empurrar edx ; rescisão nula
empurre 6578652eh
empurre 636c6163h
empurre 5c32336dh
empurre 65747379h
empurre 535c7377h
empurre 6f646e69h
empurre 575c3a43h
mov esi, esp ; esi -> "C:\Windows\System32\[Link]"

pressione 10; estado da janela SW_SHOWDEFAULT push

esi ; "C:\Windows\System32\[Link]"
chame eax; WinExec

Machine Translated by Google

[Link] Finalizando o Shellcode

No final, equiparemos o shellcode com seu próprio stack frame, pois

não queremos bagunçar o programa – o shellcode é bem grande,
então é uma boa prática manter a pilha limpa após terminar.

Machine Translated by Google

[Link] Finalizando o Shellcode

Construiremos um quadro de pilha no início, salvaremos todos

os estados de registro antes de fazer qualquer coisa e, no final, os
registros serão restaurados e o quadro de pilha será removido.

Vamos adicioná-lo ao código e juntar todas as peças para obter

um shellcode funcional baseado em peb.

Machine Translated by Google

5.2.4 Código Fonte

[BITS 32]

começar:

empurre eax; Salvar todos os registros push

ebx push
ecx push
edx push esi
push edi

empurrar ebp

; Estabeleça um novo quadro de pilha

push ebp mov

ebp, esp sub esp, 18h

variáveis locais ; Alocar memória na pilha para

Machine Translated by Google

5.2.4 Código Fonte

xor esi, esi

mov esi, 0x01646679
subesi, 0x01010101
empurre esi
empurre 456e6957h; coloque o nome da função na pilha; var4 = "WinExec\x00" mov
[ebp-4], esp

Machine Translated by Google

5.2.4 Código Fonte

; Encontre o endereço base [Link]

Machine Translated by Google

5.2.4 Código Fonte

; Encontre o endereço WinExec

mov eax, [ebx + 3Ch] ; RVA de assinatura PE
adicione eax, ebx ; Endereço da assinatura PE = endereço base + RVA do PE
assinatura
mov eax, [eax + 78h] ; RVA da Tabela de Exportação
adicione eax, ebx ; Endereço da Tabela de Exportação

mov ecx, [eax + 24h] ; RVA da Tabela Ordinal

adicionar ecx, ebx ; Endereço da Tabela Ordinal

mov [ebp-0Ch], ecx ; var12 = Endereço da Tabela Ordinal

mov edi, [eax + 20h] adicionar edi, ; RVA da tabela de ponteiros de nomes
ebx ; Endereço da tabela de ponteiros de nomes

mov [ebp-10h], edição ; var16 = Endereço da tabela de ponteiros de nomes

mov edx, [eax + 1Ch] ; RVA da Tabela de Endereços

adicionar edx, ebx ; Endereço da tabela de endereços

mov [ebp-14h], edx ; var20 = Endereço da Tabela de Endereços

mov edx, [eax + 14h] ; Número de funções exportadas

xor eax, eax ; contador = 0

Machine Translated by Google

5.2.4 Código Fonte

.laço:
mov edi, [ebp-10h] ; edi = var16 = Endereço da tabela de ponteiros de nomes
mov esi, [ebp-4] ; esi = var4 = "WinExec\x00"
xor ecx, ecx

cld ; definir DF = 0 => processar strings da esquerda para a direita

aumento eax ; contador++

cmp eax, edx jb ; verifique se a última função foi alcançada
[Link] ; se não for o último -> loop

adicionar esp, 26h

jmp iní[Link] ; se a função não for encontrada, pule para o final

Machine Translated by Google

5.2.4 Código Fonte

.encontrado:

; o contador (eax) agora ocupa a posição de WinExec

mov ecx, [ebp-0Ch] ; ecx = var12 = Endereço da tabela ordinal
mov edx, [ebp-14h] ; edx = var20 = Endereço da Tabela de Endereços

mov machado, [ecx + eax2] ; machado = número ordinal = var12 + (contador 2)

mov eax, [edx + eax*4] ; eax = RVA da função = var20 + (ordinal * 4)
adicione eax, ebx ; eax = endereço do WinExec =
; = endereço base [Link] + RVA do WinExec

Machine Translated by Google

5.2.4 Código Fonte

xor edx, edx

empurrar ; rescisão nula
edx empurrar 6578652eh
empurre 636c6163h
empurre 5c32336dh
empurre 65747379h
empurre 535c7377h
empurre 6f646e69h
empurre 575c3a43h
mov esi, esp ; esi -> "C:\Windows\System32\[Link]"

empurre ; estado da janela SW_SHOWDEFAULT

10 empurre esi ; "C:\Windows\System32\[Link]"
ligue para eax ; WinExec

adicionar esp, 46h ; limpar a pilha

Machine Translated by Google

5.2.4 Código Fonte

.fim:

pop ebp ; restaure todos os registros e saia

pop edi
pop esi
pop edx
pop ecx
pop ebx
pop eax
ret

Machine Translated by Google

5.2.4 Código Fonte

Ao terminar, é hora de compilar o shellcode usando

nasm, conforme segue.

nasm [Link] –o [Link]

Também extrairemos os opcodes para colá-los no programa

testador de shellcode, como segue.

python [Link] [Link]

Machine Translated by Google

5.2.4 Código Fonte

Veremos que o cálculo aparece! No entanto, temos que lidar com a

saída feia, pois não temos um retorno claro do shellcode.

Você pode criar lógica ausente?

Machine Translated by Google

Você tem estudado bastante .

Recomendamos fazer uma pausa
rápida e voltar revigorado. Existem
vários vídeos e laboratórios
interessantes a seguir! ÿ

Machine Translated by Google

Vídeo nº 1

Backdoor de arquivos PE -
Parte 1
Neste vídeo, a primeira parte da
série, abordaremos os fundamentos do
contrabando de um código backdoor
dentro de um aplicativo
legítimo sem alterar seu comportamento,
para que qualquer usuário deste
aplicativo não saiba que o aplicativo que
ele executa contém um código malicioso
oculto. código.

*Os vídeos estão disponíveis apenas nas edições Full ou Elite do curso. Para acessar, acesse o curso em sua área de membros
e clique no menu suspenso de recursos na linha do módulo apropriado. Para atualizar, clique em LINK.

Machine Translated by Google

Vídeo nº 2

Backdoor de arquivos PE -
Parte 2

Tentaremos identificar
áreas não utilizadas no
aplicativo para que
possamos colocar o código
do backdoor lá também.

Machine Translated by Google

Vídeo nº 3

Backdoor de arquivos PE -
Parte 3

Neste vídeo, criptografaremos

o shellcode e implementaremos uma
lógica de descriptografia em
tempo de execução.

Machine Translated by Google

Laboratório Hera

Código Shell do Windows

Neste laboratório,
você praticará a escrita
e execução de shellcode
do Windows.

*Os laboratórios estão disponíveis apenas nas edições Full ou Elite do curso. Para acessar, acesse o curso em sua área de membros
e clique no menu suspenso de laboratórios na linha do módulo apropriado ou nas guias de laboratórios virtuais na navegação
esquerda. Para atualizar, clique em LINK.

Machine Translated by Google

Referências

Machine Translated by Google

Referências
Index of /pub/nasm/releasebuilds
[Link]

[Link]
[Link]

Arwin

[Link]

windows-exploits/arwin.c
[Link]

Machine Translated by Google

Referências
Função WinExec

[Link]

Segurança Fuzzy - Parte 6: Escrevendo shellcode W32

[Link]

Noções básicas de escrita de shellcode do Windows

[Link]

Machine Translated by Google

Vídeos
Backdoor de arquivos PE - Parte 1
Neste vídeo, a primeira parte da série, abordaremos os fundamentos do contrabando
de um código backdoor dentro de um aplicativo legítimo sem alterar seu comportamento, para que
qualquer usuário deste aplicativo não saiba que o aplicativo que ele executa contém
um código malicioso oculto. código.

Backdoor de arquivos PE - Parte 2

Tentaremos identificar áreas não utilizadas no aplicativo para que possamos colocar o código do
backdoor lá também.

Machine Translated by Google

Vídeos

Backdoor de arquivos PE - Parte 3

Neste vídeo, criptografaremos o shellcode e implementaremos uma lógica de descriptografia em tempo de
execução.

Machine Translated by Google

Laboratórios

Código Shell do Windows

Neste laboratório, você praticará a escrita e execução de shellcode do Windows.

*Os laboratórios estão disponíveis apenas nas edições Full ou Elite do curso. Para acessar, acesse o curso em
sua área de membros e clique no menu suspenso de laboratórios na linha do módulo apropriado ou nas guias
de laboratórios virtuais na navegação esquerda. Para atualizar, clique em LINK.