Este documento describe una técnica llamada "Shellcode ELF loader" para ejecutar programas de forma encubierta en un sistema comprometido sin dejar evidencias. La técnica utiliza un objeto llamado "lxobject" que contiene el código binario a ejecutar, el contexto de la pila y un cargador de shellcode. Una herramienta llamada "Builder" ensambla el lxobject y la shellcode "Jumper" lo transfiere y activa en la máquina remota simulando un "userland execve". Esto permite ej

1. Evasión de técnicas forense
(Shellcode ELF loader)
Albert Puigsech Galicia ripe@7a69ezine.org
Rubén Jiménez García pluf@7a69ezine.org
FIST BCN 2005

2. Introducción

3. Introducción
 Sistema de explotación común:
 Localización de maquina vulnerable
 Generación de programa exploit
 Utilización de shellcode especifica
 Se inicia el proceso de post-explotación

4. Introducción
 La shellcode es nuestra amiga:
 Codigos pequeños y faciles de programar
 Se pueden adaptar a cualquier exploit
 Pueden incorporar tecnicas de antidetección
 Generalmente se ejecuta una shell via execve()
 Pero nos puede trainicionar:
 Imposibilidad de utilizar execve()!!

5. Introducción
 Y si disponemos de execve()?
 Ejecución de comandos y aplicaciones locales
 Descarga/compilación de programas
 Estamos muertos..
 Que ha ocurrido?
 for(;;) printf(“evidencias!!”);

6. Introducción
 Para poder solucionar estos problemas tendremos
que optar por un sistema que nos facilite la
ejecución de programas y al mismo tiempo genere
el menor numero posible de evidencias:
Userland execve()

7. Userland execve

8. Userland execve
 El procedimiento que permite la ejecución local de
un programa sin utilizar la llamada al sistema
‘execve’ recibe el nombre de ‘userland execve’.
 Mecanismo que simula de forma correcta y
ordenada las tareas que realiza el núcleo:
 Carga de las secciones necesarias del binario
 Inicialización del contexto de la pila.
 Salto al punto de entrada.

9. Userland execve
 El uso de ‘userland execve’ nos soluciona los
problemas planteados anteriormente.
 No es necesario el uso de la syscall, por lo que no es
preocupante que esté denegada.
 La implementación es nuestra por lo que es posible
cambiar el origen del ejecutable y obtenerlo de la red, en
lugar del disco duro. Así podemos ejecutar una shell pese
a que no exista en el disco.
 La ejecución remota nos permitirá ejecutar herramientas
que no estan en el host atacado sin alterar el disco.

10. Userland execve
 Primera versión publica de userland execve:
grugq
 Problemas:
 poco portable
 exceso de código inútil
 orientado a la ejecución local
 Solución:
 Shellcode ELF Loader

11. Shellcode ELF loader

12. Shellcode ELF loader
 La shellcode ELF loader es una nueva y sofisticada
técnica post-explotación basada en el ‘userland
execve’.
 Diseñada para ser utilizada en exploits
 Reduce la generación de evidencias
 Posibilita la ejecución en entornos ostiles
 Es fácil de programar y utilizar

13. Diseño e implementación
 SELF esta formado por tres elementos:
 Lxobject (1)
 Builder (2)
 Jumper (3)
 Cada uno realiza una tarea especifica dentro del
proceso de post-explotación

14. Lxobject (1)
 Es un objeto ejecutable y auto-cargable utilizado
para sustituir por completo un proceso original por
otro.
 Es la parte más compleja e importante de todo el
sistema.
 Se construye por el ‘builder’ en el host del atacante.

15. Lxobject (1)
 Un lxobject esta constituido por tres partes:
 Binario ELF estático
 Contexto inicial de la pila
 Shellcode cargadora

16. Binario ELF estático (1.a)
 Es el binario que queremos cargar y ejecutar en la
maquina remota.
 El sistema sólo funciona con binarios estáticos, se
ha optado por ello por varios motivos.
 Facilita el diseño y la implementación
 No nos preocupamos por las librerías
 Reduce la complejidad de SELF
 El binario lo genera el atacante. (uso de armerías)

17. Contexto de pila (1.b)
 Todo proceso dispone de una zona de memoria
llamada pila o stack usada para varios cometidos.
 Variables locales.
 Control del flujo de ejecución.
 Copias temporales de registros.
 Parámetros pasados a la aplicación por el proceso padre.
 Variables de entorno.

18. Contexto de pila (1.b)
 La pila debe tener un contexto inicial para que el
proceso funcione correctamente.
 Para facilitar la portabilidad y estabilidad se ha
optado por pre-construir el contexto de la pila en
el host atacante e incluirlo en el lxobject como de
un program header más se tratara.
 No es necesario incluir los vectores auxiliares
utilizados para tratar con binarios dinámicos.

19. Shellcode cargadora (1.c)
 Se trata de la parte más importante y delicada del
lxobject.
 Es una shellcode que simula el userland execve()
 Código pequeño y fácil de entender
 Se puede adaptar a cada sistema/plataforma
 No construye el contexto de pila

20. Builder (2)
 Es la aplicación encargada de ensamblar las
piezas que construyen el lxobject.

21. Builder (2)
 Su funcionamiento es sencillo:
bash ~$ ./builder <host> <port> <exec> <argv> <envp>
host, port: dirección y puerto de la máquina atacada donde el jumper
está ejecutándose y esperando.
exec: Fichero binario ELF que queremos ejecutar
argv, envp: Argumentos y variables de entorno pasadas al programa.

22. Builder (2)
 Elemplo de ejecución:
bash ~$ ./builder 172.26.0.1 2002 nmap-static “-P0;-p;23;172.26.0.30” “PATH=/bin”

23. Proceso de construcción
 Se crea una zona de memoria lo suficientemente
grande para almacenar el fichero ejecutable
estátido y se copia el binario.
elf_new = (void*)malloc(elf_new_size);
 Se limpian aquellos campos referentes a las
secciones pues no seran usadas por nuestro
binario.
ehdr_new->e_shentsize = 0;
ehdr_new->e_shoff =0;
ehdr_new->e_shnum = 0;
ehdr_new->e_shstrndx = 0;

24. Proceso de construcción
 Se introduce el shellcode ELF loader y se guarda
su offset en el campo e_ident de la cabecera del
ejecutable.
memcpy(elf_new + elf_new_size - PG_SIZE + LOADER_CODESZ, loader,
LOADER_CODESZ);
ldr_ptr = (unsigned long *)&ehdr_new->e_ident[9];
*ldr_ptr = elf_new_size - PG_SIZE + LOADER_CODESZ;
 El lxobject está perfectamente ensamblado y listo
para ser enviado.
connect(sfd, (struct sockaddr *)&srv, sizeof(struct sockaddr));
write(sfd, elf_new, elf_new_size);

25. Jumper (3)
 El jumper es la shellcode que deberá ser usada
por el exploit en el proceso de explotación.
 Su misión es activar el lxobject y para ello debe
realizar, por lo menos, las siguientes acciones:
 Obtener el lxobject.
 Almacenarlo en la memoria.
 Activarlo saltando al loader.

26. Obtener el lxobject
 El lxobjet puede obtenerse de muchas fuentes.
 Disco duro
 Socket de red
 ...
 Es recomendable usar un socket de red para
reducir el riesgo de dejar evidencias.

27. Almacenarlo en memoria
 Es necesario almacenar el lxobject en la memoria
de proceso. Se plantean entonces tres
posibilidades.
 Almacenarlo en la heap
 Almacenarlo en la pila del proceso
 Almacenarlo en una nueva zona de memoria (mmap).

28. Almacenarlo en la heap
 Para almacenar el lxobject en la heap es necesario
localizar la vaddr del proceso usando brk().
 Ventajas:
 Es sencillo de implementar.No suele haber restricciones
de copia de datos.
 Desventajas:
 Se puede desmapear el propio lxobject durante el
proceso de carga

29. Almacenarlo en el stack
 Si se conoce la situación de la pila es posible
almacenar ahí el lxobject.
 Ventajas:
 Es sencillo de implementar.
 No suele haber restricciones de copia de datos.
 Desventajas:
 Se puede desmapear el propio lxobject durante el
proceso de carga.
 Pueden existir restricciones de ejecución en la pila, es
bastante común en sistemas hostiles.

30. Almacenar en una nueva
zona
 Es posible mapear (usando la llamada al sistema
mmap) una nueva zona de memoria destinada
almacenar el lxobject.
 Ventajas:
 No existen restricciones para la copia o ejecución de
datos.
 No existe peligro de que el lxobject se desmapee durante
el proceso de carga.

31. Demostración
Simple stack overflow + SELF = envio y ejecución de nmap

32. Demostración
Simple stack overflow + SELF = envio y ejecución de elfsh

33. Referencias
[+] The Design and Implementation of ul_exec - the grugq
http://securityfocus.com/archive/1/348638/2003-12-29/2004-01-04/0
[+] Remote Exec - the grugq
http://www.phrack.org/show.php?p=62&a=8
[+] Advanced antiforensics - Ripe & Pluf
http://www.phrack.org/show.php?p=63&a=11
[+] Forensic Shell. FSH – Parki
[+] API Proxy – ilo
http://www.reversing.org

34. Alguna preguntita?
?

35. Muchas gracias
A los organizadores de FIST BARCELONA


36. FIN
http://www.7a69ezine.org
Albert Puigsech Galicia
Rubén Jiménez García