Seguridad de Código basada en Tecnología Vírica. No cON Name 2006

Seguridad de CódigoBasada en tecnología vírica

Jesús Olmos GonzálezDepartamento de Auditorí[email protected]

Esquema

1. Inseguridad de código y medidas actuales.2. Análisis de la raíz del problema.3. Regeneración del código máquina.4. Infecciones y cold-patching.5. Prueba de concepto.

1. Inseguridad de código y medias

Inseguridad de código y

medidas actuales

(las medidas actuales no solucionan el problema de raíz)

● En el cyberespacio todo es código y datos.● Todo es automatizable.● El código también es usuario de internet:

– Puede navegar.– Puede chatear.– Puede cometer intrusiones.– Pueden entrar de máquina en máquina en busca

de una persona o documento concreto.– Son pequeños y rápidos, cambian de forma, se

esconden en otros procesos y en otros ficheros, evolucionan.

1. Inseguridad de código y medidas

1. Inseguridad de código y medidas● El atacante siempre es código.● Puede ser código controlado por una persona:

– Necesita conexión entre el código y la persona.– Es más detectable.– Tiene la inteligencia de una persona.– Es lento.

● Puede ser código vírico:– Se mueve rápido.– Es directo.– Difícil de detectar.– No es inteligente.

1. Inseguridad de código y medidas● La computadora es una máquina de ejecutar

código.● Ni el procesador ni el sistema operativo

distinguen si es código bueno, o malo o si ha sido introducido por el usuario o por un atacante.

● Las computadoras se relacionan entre ellas.● Muchos datos de unas máquinas son

introducidos en la memoria RAM de otras.● El procesador ejecuta el código que hay en la

RAM.




char busca[MAXIMA_BUSQUEDA];char log_busquedas[LOG_NAME_SIZE];

● El orden no determina la seguridad, el compilador puede variarlo, además se pueden dar overflows en sentido inverso.

● ¿Se puede asaltar otra variable?● Atacante:

– Controlas el código, o el código te controla?● Where + What = Dentro!


char busca[MAXIMA_BUSQUEDA];void (*fptr)(void);

● Redirección de la ejecución.● Where + What = Dentro!● Defensor:

– ¿El código controla al usuario o el usuario controla al código?

1. Inseguridad de código y medidas¿Porqué se puede

saltar de una variable a otra?

PAX-GR etc...

ADMIN

GCC

Pues porque no hay variables.Si se piensa en C, no se ve la

realidad se necesita pensar en asm.

Habría que cambiar la estructura ELF / PE y cambiar los compiladores :( AUDITOR

Podemos tapar un poco el problema poniendo trampas

y dificultades por la memoria :)

Tapar el problema puede evitar muchos ataques, pero

siempre deja brechas. Mientras los compiladores no

lo hagan mejor sugiero... REGENERAR EL REGENERAR EL CÓDIGO BINARIOCÓDIGO BINARIO


● El firewall tapa el problema:– Suelen ser efectivos en su labor de tapa.– Más código que interactua con los paquetes.– Más vulnerabilidades.– Si cae el firewall, o se encuentra otra vía, la

vulnerabilidad queda expuesta.

1. Inseguridad de código y medidas● El firewall determina quien tiene acceso a que

servicio


● El firewall de aplicación web tapa los fallos de código:– Siempre hay fallos de código, pues se necesita una

barrera extra.– El protocolo HTTP da mucho juego, hay muchas

evasiones posibles.– Más código, más vulnerabilidades.– Sería más efectivo diseñar un buen corrector de

código web.– Puede haber vías de ataque que no pasen por el

firewall.


● El sistema antivirus, frena lo que ya ha entrado:– Puede dificultar la subida de herramientas por parte

de los atacantes.– No corrige la vulnerabilidad, por donde entra el

código.– El código ya esta dentro!– Analizar el contenido de los ficheros es lento, hay

ventanas de tiempo.– Hookeando syscalls, puede ser detectado después

de que haya realizado un payload malévolo.– Puede mutar para evadir ficheros cebo.


● El sistema IDS no corrige el problema:– Es importante la detección.– Si se detecta, ya nos ha entrado el código.– Los logs muchas veces no se miran.– Sobreinformación.


● El sistema IPS puede tapar las vulnerabilidades:– Puede impedir el ataque, tomando medidas como

parar servicio o máquina, banear IP atacante etc..– El servicio sigue siendo vulnerable.– Se puede evadir las firmas del IPS.


● La teoría X^W no impide el bof:– Es lógico y necesario.– Dificulta la explotación en algunos casos.– El Buffer Overflow se sigue produciendo.– Se continua teniendo control del retorno de pila.– Se continua teniendo control de la cabecera del

siguiente chunk en heap.– Se puede saltar a librerias mapeadas.– ¡Se pueden invadir otras variables!


● Direcciones aleatorias:– Afecta al rendimiento.– Dificulta la explotación en algunos casos.– El Buffer Overflow se sigue produciendo.– Se continua teniendo control del retorno de pila.– Se continua teniendo control de la cabecera del

siguiente chunk en heap.– No es viable averiguar la dirección de librerías

donde saltar.– ¡¡Se pueden invadir otras variables!!


● Canary values:– Afectan al rendimiento.– Normalmente no es viable realizar bruteforce del

canary.– El nivel de entropía puede ser insuficiente.– Pueden impedir tomar control del retorno de pila.– Pueden impedir tomar control de la cabecera del

chunk siguiente en heap.– ¡¡Se pueden invadir otras variables!!!


● Correctores de código fuente:– Analizan la raíz del problema.– El código fuente tiene la información suficiente

como para solucionar los problemas.– Con el código cerrado no se puede hacer nada.– El corrector de código se debería usar más incluso

que el corrector ortográfico.– El compilador puede introducir bugs.– Lo ideal sería un corrector de código máquina.

2. Anaísis de la raíz del problema

Análisis de la raízdel

problema

(que sucede tras la compilación)

2. Análisis de la raíz del problema● Antes de la compilación se tiene mucha

información.

tipo descripcion[cantidad];

sizeof(descripcion) = tipo * cantidad;

● Los sizeof() se calculan en tiempo de compilación ya que despues es imposible saber los tamaños ni los tipos.

2. Análisis de la raíz del problema● Después de la compilación no tenemos

cantidades, ni tipos, ni mucho menos descripciones.

● Todo son bytes.● Hay bytes que indican como interpretar los

bytes.

2. Análisis de la raíz del problema

● No hay límites.● El código dicta como utilizar los datos.● ¿Cómo diferenciar si el código lo hace mal?● Se deberían poder marcar límites

inquebrantables entre variables.– No se darían los bofs.– No se permitiría escribir en memoria un carácter

utilizado para marcar límites.● ¿¿Pero, cómo identificar los límites en un

precompilado???

2. Análisis de la raíz del problema● Imaginemos la pila en tiempo de ejecución.● ¿Como podemos ver que el strcpy puede

invadir otras variables?


● La pila tendrá 3 estados:– Inicial.– Tras ejecutarse fptr = (void(*)(void))main; – Tras ejecutarse el strcpy.

● Intentemos localizar los límites.


2. Análisis de la raíz del problema● Mirando los datos no se pueden ver los límites.● Es posible imaginarlos con técnicas de

reversing. ● Se necesita ver como el código interactua con

los datos para aproximar los límites.● Las protecciones de pila, heap, randomización,

etc. dan rodeos.● Es posible realizar un algoritmo que aproxime

los límites y corrija el binario para que no los cruce.



CONOCIDO APROXIMADO

0xffffffec(%ebp) <=0xec bytes(%esp) 4bytes

● Las tablas varían según se va ejecutando el código.

0x04(%esp) 4bytes

2. Análisis de la raíz del problema● Para corregir una línea de código se tiene en

cuenta el estado de las tablas en ese momento.● No sólo se pueden sacar las aproximaciones

de las llamadas externas, también de lecturas, escrituras, posicionamiento (lea) ...

● Las aproximaciones son límites reales hasta que se identifiquen mejor.

● En heap se pueden localizar los inicios y tamaños de variables al 100% pudiendo así erradicar el heap overflow/underflow.

●



CONOCIDO APROXIMADO

0xfffffffc(%ebp) 4 bytes

● Las tablas varían según se va ejecutando el código.

0xfffffff8(%ebp) 4 bytes0xfffffff4(%ebp) 4 bytes

[0xfffffffc(%ebp) ] 0x3e8 bytes

[0xfffffff8(%ebp) ] 0xa bytes[0xfffffff4(%ebp) ] 0x29a bytes

2. Análisis de la raíz del problema● Hay que tener en cuenta que el código puede ir

reservando más memoria o destruyendo las variables

● Hay que ir actualizando la tabla de variables conocidas.

● No sólo se puede alvergar memoria dinámica con mallocs, también existen otras maneras como mmap.

● Se puede utilizar la memoria dinámica directamente sin utilizar implementaciones que lo hagan por ti.

●

2. Análisis de la raíz del problema● Las aproximaciones también son de gran

ayuda.

3. Regeneración del código máquina

Regeneracióndel códigomáquina.

(como corregir el código, conociendo los límites reales y aproximados)


3. Regeneración del código máquina● El salto que realiza el parche es relativo.● Sin optimización habría realizado un strcpy, el

cual se debería regenerar a strncpy● Para mayor seguridad el registro utilizado por el

parche podría guardarse en pila y al final restaurarse (push / pop).

● Normalmente el número de interaciones se debe a una condición. El parcheo es similar al anterior.

● En muchos casos una variable marca el número de iteraciones. El parche aquí es simple, basta con modificar el valor.

●

3. Regeneración del código máquina● ¿Cómo distinguir que es cada llamada externa?●

strcpy

_start PLT (XR)

GOT (RW)

main

strcpy libc


3. Regeneración del código máquina● En win32 se puede buscar directamente el

nombre de la api en la AddressOfNames de la import table, y conseguir en la AddressOfOrdinals la dirección.

● Se podría buscar en las export-tables de las dlls cargadas e indexar las direcciones externas.

● Las principal diferencia es el formato del ejecutable, el cual afecta al apartado 4.


3. Regeneración del código máquina● Los únicos límites detectados serían los de la

pila (esp y ebp) en este caso son 100% correctos.

● Se podría modificar simplemente el número de loops a realizar para sanear este código, lo cual no requiere relocatación.

● Las tablas que guardan los límites, debería de haber una por función de forma enlazada.

● Veamos un caso curioso de overflow.

3. Regeneración del código máquina● El regenerador,

detectaría inc e i de manera que el primer bof no se podría dar.

3. Regeneración del código máquina● El analizador de código podría debugar:

– En linux PTRACE_SINGLESTEP– No se necesitan estructuras de opcodes para

entender el código.– En windows también hay API para realizarlo.– El flujo de código no entraría en todos los casos (se

puede forzar)– El código puede necesitar inputs del usuario,

ficheros no existentes, etc.

3. Regeneración del código máquina● El analizador de código podría NO debugar:

– Se podría recorrer el código desde el mapa.– Se podrían aprovechar rutinas de las bin-utils.– Se podrían aprovechar estructuras de opcodes

intel.– Se analizaría función por función sin ejecutarla.– Mayor maniobrabilidad.

4. Infecciones y cold-patching

Infecciones y

cold-patching

(Podemos aprender de los virus)

4. Infecciones y cold-patching● Según como se regenere el código, este puede

acabar ocupando más.● Si el código crece, todos los saltos, llamadas y

accesos se desplazan.● Es necesario volver relocatar todo para que siga

funcionando.● Los virus utilizan la infección para inyectar código

extra en el código-victima.

4. Infecciones y cold-patching● Infección de memoria (hot-patch)

– Hay que desproteger el area de código.– El cambio no es persistente.– Se pueden haber ejecutado ya instrucciónes

vulnerables.– Es sencillo de realizar.– Linux: ptrace– Win32: CreateRemoteThread WriteProcessMemory

4. Infecciones y cold-patching● Infección de disco (cold-patch)

– Hay que mantener los alineamientos y distancias relativas.

– Es persistente.– El fichero puede estar bloqueado, en este caso se

puede realizar el parcheo en un fichero nuevo.– Se puede realizar en un mapa de memoria, para

ahorrar accesos continuos a disco.– Los procesos que se esten ejecutando siguen

vulnerables hasta que se vuelvan a reiniciar.

4. Infecciones y cold-patching● O se combina cold-patch con hot-patch o sólo se

realiza cold-patch.● Se ha de poder regenerar también las librerias.● Se puede infectar el algoritmo corrector a los

ficheros, de forma que se vayan contagiando, hasta que acabe siendo todo seguro de bofs.

● Por ahora la idea es tener una herramienta tal que:– regen.exe -dll user32.dll – ./regen /usr/bin/exim

4. Infecciones y cold-patching● Infección mediante overlay:

– Sencilla y efectiva aunque drástica.– Copia todo el código al final del fichero e inserta su

motor en su lugar.– El motor carga el código corregido del final del fichero

a memoria, le da permisos y lo ejecuta.– No es un sistema muy fino.– Necesita abrirse a si mismo.

4. Infecciones y cold-patching● Infección mediante alargamiento de .text

– Se necesita relocatar definiciones de secciones y segmentos.

– Se necesita relocatar los saltos indirectos de la plt.– Se necesita relocatar todo salto y llamada relativa

que cruce el parche.– Se necesita relocatar todo salto y llamada absoluta.– Se necesita relocatar accesos a variables.– El parche es irreversible, se debe crear backup.– No es mala solución aunque la que sigue es mejor.

4. Infecciones y cold-patching● Infección mediante creación de .patch

– Se crea sección nueva y se registra en shstrtab.– Toda función vulnerable se copia corregida a .patch– Toda llamada a funcion vulnerable se reapunta a

.patch– Se necesita relocatar definiciones de secciones y

segmentos.– Se necesita relocatar los saltos indirectos de la plt.– Se necesita relocatar todo salto y llamada absoluta.– Se necesita relocatar accesos a variables.

4. Infecciones y cold-patching● La creación de un segundo segmento de código

no es viable:– Se controla desde kernel.– Las definiciones de segmento no se rigen al 100%

por lo que diga el Elf32_Phdr.– Se ha de reubicar todo igualmente.– Se debe crear sección dentro del segmento.– La creación de una nueva seccion .patch dentro del

segmento de código es más directo.

4. Infecciones y cold-patching● Procedimiento de creación de .patch

1.Remapear con el tamaño del fichero+parche+1 registro de sección.

2.Desplazamiento lógico de offset y virtual de las secciones inferiores a la tabla de secciones.

3.Desplazamiento físico de secciones inferiores.4.Añadir nueva sección (copiar la .text) y aumentar la

e_shnum.5.Agrandamiento lógico de segmento de texto en el

tamaño del parche.6.Desplazamiento lógico de los segmentos inferiores al

de texto (offset y virtual).

4. Infecciones y cold-patching7. Desplazamiento lógico de las secciones inferiores a

.patch (offset y virtual)8. Desplazar físicamente lo que haya por debajo del

inicio de .patch para que quede espacio para patch.9. Actualizar e_shoff ya que se ha desplazado

fisicamente la tabla de secciones (esta abajo).10. Parchear :)


Registro elf header

Tabla de segmentos

CODE

DATA

Tabla de secciones

.text

.plt

.got

.patch

5. Prueba de comcepto

Pruebade

Concepto

(POC)


¿ Preguntas ?¿ Preguntas ?

Autopresentación

Jesús Olmos GonzálezInternet Security Auditors

Departamento de Auditoría

[email protected]@7a69ezine.org

mailto:[email protected]

mailto:[email protected]

Technology

Seguridad de Código basada en Tecnología Vírica. No cON Name 2006