kkent030315/pagetableinjectionInjeção de código, injetar payload malicioso por meio de tabelas de páginas pml4.
Injeção de Código, injete payload malicioso através de tabelas de páginas pml4.
Este é apenas uma prova de conceito da técnica de injeção de tabela de páginas para injetar código malicioso em processos de usuário arbitrários.
No Windows (e alguns SOs modernos), cada processo tem seu próprio PML4, também conhecido como Base da Tabela de Diretório. Portanto, o processo A não pode acessar o processo B sem APIs. Mas e se pudermos injetar uma entrada PML4 arbitrária? Claro que a entrada PML4 apontará para o endereço físico correspondente das entradas, PDP, PD e PT, exatamente iguais aos do processo de apoio.
Para injetar uma entrada PML4 maliciosa no processo alvo, precisamos ter uma página residente real (memória física) que suporte a entrada PML4 maliciosa. Portanto, literalmente, a página residente deve ser residente, caso contrário o sistema irá travar ou se tornar instável, porque durante a tradução da MMU para o endereço físico, não há nada que a MMU espera, assim como não há nada que o gerenciador de memória do Windows espera.
Vejamos os buffers do processo de apoio e do processo alvo. Neste caso, os buffers são:
0x1A45F8100000x6EA45F810000Antes de prosseguir, alguns podem pensar que o segundo endereço (0x6EA45F810000) parece estranho, pois geralmente alocamos buffer via malloc ou VirtualAlloc, o endereço virtual deveria ser algo como 0x17C7CAC0000 0x23BE9D80000 0x19FE76F0000 ou algo do tipo. Isso ocorre porque a entrada PML4 maliciosa não está envolvida com o gerenciador de memória do Windows e também não é gerenciada. É claro que todo endereço virtual em um processo Windows 64 bits pode possivelmente ter qualquer valor dentro do intervalo de memória do usuário.
Então, se olharmos para ambos os endereços...
0: kd> .process ffff9803d8037080
Implicit process is now ffff9803`d8037080
0: kd> db 0x6EA45F810000 l2
00006ea4`5f810000 4d 5a MZ
0: kd> !vtop 7968b000 0x6EA45F810000
Amd64VtoP: Virt 00006ea45f810000, pagedir 000000007968b000
Amd64VtoP: PML4E 000000007968b6e8
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 6ea45f810000 translates to physical address 14306000.
0: kd> .process ffff9803d9f6b080
Implicit process is now ffff9803`d9f6b080
0: kd> db 0x1A45F810000 l2
000001a4`5f810000 4d 5a MZ
0: kd> !vtop 564f6000 0x1A45F810000
Amd64VtoP: Virt 000001a45f810000, pagedir 00000000564f6000
Amd64VtoP: PML4E 00000000564f6018
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 1a45f810000 translates to physical address 14306000.
Ambos os endereços correspondem exatamente às mesmas entradas da tabela de páginas, PDP, PD, PT e um endereço físico. Portanto, se modificarmos o buffer do processo de apoio, a alteração também ocorre no processo alvo. Isso é muito semelhante à memória compartilhada no Windows, mas a diferença é que a região de memória no processo alvo nunca será mostrada em nenhuma entrada VAD do seu processo. Por outro lado, se o buffer do processo de apoio for liberado, isso também ocorre no processo alvo, mas sem limpar as entradas da tabela de páginas do processo alvo, o que significa que o gerenciador de memória causará um bugcheck MEMORY_MANAGEMENT, ou desencadeará uma falha tripla ainda pior na CPU.
Esta técnica tem enormes problemas de estabilidade, como eu disse, a entrada PML4 maliciosa injetada não está envolvida com o gerenciador de memória do Windows nem com os kernels. E não há garantia de que o processo de apoio permanecerá ativo até que o processo alvo seja encerrado, ou que o processo alvo tenha alguma ação para limpar a entrada PML4 maliciosa quando o processo de apoio for encerrado.
MIT copyright Kento Oki <[email protected]>
Os códigos-fonte podem conter conteúdos externos, tais conteúdos pertencem aos seus respectivos detentores de direitos autorais.