PageTableInjection

Inyección de código, inyecta payload malicioso a través de las tablas de páginas PML4.

Introducción

Esto es solo una prueba de concepto de la técnica de inyección de tablas de páginas para inyectar código malicioso en procesos de usuario arbitrarios.
En Windows (y algunos sistemas operativos modernos), cada proceso tiene su PML4, también conocido como Directory Table Base. Por lo tanto, el proceso A no puede acceder al proceso B sin APIs. Pero, ¿qué tal si pudiéramos inyectar una entrada PML4 arbitraria? Por supuesto, la entrada PML4 apuntará a la dirección física correspondiente de las entradas PDP, PD y PT exactamente igual que en el proceso de respaldo.

Para inyectar una entrada PML4 maliciosa en el proceso objetivo, necesitamos tener una página real (memoria física) que respalde la entrada PML4 maliciosa. Por lo tanto, literalmente la página residente debe ser residente; de lo contrario, el sistema se bloqueará o se volverá inestable, porque durante la traducción MMU a la dirección física, no hay nada que la MMU espere, así como tampoco hay nada que el administrador de memoria de Windows espere.

Analicemos los buffers tanto del proceso de respaldo como del proceso objetivo. En este caso, los buffers son:

• VA del proceso de respaldo: 0x1A45F810000
• VA inyectada en el proceso de despliegue: 0x6EA45F810000

Antes de pasar al siguiente paso, algunos pensarán que la segunda dirección (0x6EA45F810000) parece extraña; normalmente, cuando asignamos un buffer mediante malloc o VirtualAlloc, la dirección virtual debería verse como 0x17C7CAC0000, 0x23BE9D80000, 0x19FE76F0000 o algo similar. Esto se debe a que la entrada PML4 maliciosa no está involucrada en el administrador de memoria de Windows y tampoco es gestionada. Por supuesto, cualquier dirección virtual en un proceso de Windows de 64 bits podría tener cualquier valor dentro del rango de memoria de usuario.

Así que si observamos ambas direcciones...

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.

Ambas direcciones corresponden exactamente a las mismas entradas de la tabla de páginas: PDP, PD, PT y una dirección física. Por lo tanto, si modificamos el buffer del proceso de respaldo, el cambio también se reflejará en el proceso objetivo. Esto es muy similar a la memoria compartida en Windows, pero la diferencia es que la región de memoria en el proceso objetivo nunca se mostrará en ninguna entrada VAD de su proceso. Sin embargo, por otro lado, si el buffer del proceso de respaldo se libera, también se liberará en el proceso objetivo, pero sin limpiar las entradas de la tabla de páginas del proceso objetivo, lo que significa que el administrador de memoria provocará un bugcheck MEMORY_MANAGEMENT o desencadenará un fallo triple peor en la CPU.

El problema

Esta técnica tiene problemas masivos de estabilidad, como dije, la entrada PML4 maliciosa inyectada no está involucrada en el administrador de memoria de Windows ni en el kernel. Además, no hay garantía de que el proceso de respaldo siga vivo hasta que el proceso objetivo termine, ni el proceso objetivo tiene nada que ver con la limpieza de la entrada PML4 maliciosa cuando el proceso de respaldo termina.

Licencia

MIT copyright Kento Oki [email protected]

Los códigos fuente pueden contener contenido externo; dicho contenido pertenece a su titular de derechos de autor.