HEAP Overflows Desmitificados

1
HEAP Overflows Desmitificados
2
1 Introducción

• Este texto no cubre nuevas técnicas
  super-complejas de explotación de heap overflows
  y tampoco cubre técnicas para evitar sistemas
  super-seguros (y que casi nadie usa) para
  protegerse de los exploits basados en buffer
  overflows. (No pretendo aburrir en exceso al
  personal)

3
1 Introducción

• Este texto simplemente recoge una técnica
  genérica de explotación de heap overflows (Aunque
  es extensible incluso a la explotación de stack
  overflows o de bugs de formato).

4
1 Introducción

• Esta técnica esta basada en mi experiencia en la
  programación de buffer overflows y se desliga de
  la mayoría de textos escritos sobre el tema.
  Además en su concepción es relativamente simple,
  aunque su aplicación alcance en la mayoría de
  casos mayor complejidad.

5
1.1 Olvidar todo lo leído

• Si habéis leído algún articulo sobre explotación
  de heap overflow, olvidarlo, o mejor que
  olvidarlo, guardarlo en un rincón y compararlo
  con lo que voy a explicar. Comprobareis que el
  enfoque de esta técnica en su concepción es
  totalmente diferente a las publicadas aunque al
  fin y al cabo todas acaban siendo lo mismo.

6
1.2 Aplicación de esta técnica

• Una de las mayores ventajas de esta técnica es
  que es muy genérica, ya que es aplicable casi en
  cualquier plataforma y casi en cualquier tipo de
  overflow. Esto otorga gran flexibilidad al
  programador de exploits para emplear su
  experiencia o para elegir distintas formas de
  explotación que le permitan obtener mayor
  eficiencia en su código.

7
1.2 Aplicación de esta técnica

• Sin embargo no olvidemos que cada SO introduce
  una serie de particularidades que no deben ser
  ignoradas a la hora de emplear esta técnica.
• Ejemplo de particularidades
• Desplazamiento de la pila
• Little-endian / big-endian
• Error handlers
• Compiladores

8
1.3 Stack overflows

• Pequeño repaso...
• (Recordemos la presentación Exploits Basados en
  Stack Overflows Para x86 de la Undercon III)

9
2 Introducción a la Teoría de punteros

• Cual es el principal indicador de que existe un
  fallo de seguridad en un programa?
• Un error de segmentación.
• Porque se produce un error de segmentación?
• El software intenta acceder a una zona de memoria
  no mapeada. Normalmente a causa de un buffer
  overflow que sobrescribe un valor de memoria.

10
2 Introducción a la Teoría de punteros

• Es decir, el programa intenta leer, escribir o
  ejecutar código, en una zona de memoria no
  mapeada. Y intenta hacer esto porque un overflow
  ha alterado el flujo normal del programa,
  modificando algún puntero con un valor de memoria
  no valido.
• Por tanto, Tipos de punteros
• Punteros de lectura
• Punteros de escritura
• Punteros de ejecución

11
2 Introducción a la Teoría de punteros

• Situaciones tras un buffer overflow
• Controlamos directa o indirectamente el valor del
  puntero que produce el error.
• No controlamos el valor del puntero -gt Solo DoS

12
2.1 Herramientas de trabajo

• La idea de la técnica por tanto es trabajar
  "solo" con punteros y olvidarnos del resto. Para
  explotar un bug de este tipo no es necesario
  contar con su código fuente ni conocer su flujo
  de funcionamiento, todo este tipo de información
  no es mas que árboles que nos impiden ver el
  bosque.

13
2.1 Herramientas de trabajo

• Esto aporta grandes ventajas sobre otras técnicas
  y aunque parezca mentira, en la mayoría de casos
  simplifica la labor del exploiter.
• La única herramienta necesaria para explotar este
  tipo de fallos será nuestro debugger
  (preferiblemente el GDB)
• En Win32 ollydbg o MS debugging tools

14
3 Técnica de los punteros

• Así se llama la técnica
• Técnica de los punteros Se basa en el análisis
  de la explotabilidad de un buffer overflow, según
  el impacto que tenga sobre distintos punteros (u
  otros objetos abstraibles como punteros)
  almacenados en memoria.

15
3.1 Punteros de lectura

• No son explotables para ejecutar código. En algún
  caso extremo, en el que los datos leídos sean
  mostrados por pantalla tal vez se puede intentar
  leer información interna del proceso.
• Única opción en Bugs de formato cuando no es
  posible n
• Porcentaje de aparición aprox 30

16
3.2 Punteros de ejecución

• Es nuestro día de suerte, si podemos modificar un
  puntero de ejecución, solo tenemos que hacer que
  apunte a nuestro shellcode y listo. (Aunque
  normalmente siempre aparecen problemas...)
• Posibles punteros de ejecución
• Saved IP
• Saved EBP (o similares)
• Punteros a funciones
• Error Handlers (Win32)
• Estructuras FILE
• Etc...
• Porcentaje de aparición aprox 20

17
3.3 Punteros de escritura

• Es el caso mas típico. El puntero modificado es
  uno de escritura, dependiendo del caso
• Controlamos el valor DONDE se escribe.
• Controlamos el valor QUE se escribe.
• Controlamos ambos.
• Porcentaje de aparición aprox 40

18
4 Explotación

• Esta es la parte mas interesante. Aquí veremos
  una serie de técnicas o trucos que ayudaran a la
  explotación de este tipo de vulnerabilidades.

19
4.1 Técnica genérica

• Comprobamos que se produce el overflow -gt
  SIGFAULT
• Empezamos con el overflow mas pequeño
• Comprobamos que tipo de puntero se ha pisado
• Si no nos vale intentamos introducir un valor que
  no produzca SIGFAULT
• Vamos incrementando...

20
4.2 Punteros de lectura

• Como se ha comentado. Explotación posible en
  pocos casos. Simplemente se le pasa un valor de
  memoria valido y se intenta que continué el flujo
  de ejecución.

21
4.3 Punteros de ejecución

• A priori los mas sencillos de explotar.
• Tipos
• Ejecución directa
• Ej. Pisamos el saved EIP directamente
• Ejecución indirecta
• Ej. Pisamos el saved EBP (Usamos el comando de
  gdb BT)

22
4.3 Punteros de ejecución

• Ej. AIX 4.3 lscfg (local)
• /usr/sbin/lscfg -l perl -e 'print "a" x 10000'
• Pisamos r11
• 0xd015ead0 lt_ptrglgt lwz r0,0(r11) gt
  carga 0(r11) en r0
• 0xd015ead4 lt_ptrgl4gt stw r2,20(r1)
• 0xd015ead8 lt_ptrgl8gt mtctr r0 gt
  mover r0,ctr
• 0xd015eadc lt_ptrgl12gt lwz r2,4(r11)
• 0xd015eae0 lt_ptrgl16gt lwz r11,8(r11)
• 0xd015eae4 lt_ptrgl20gt bctr gt Branch a ctr

23
4.3 Punteros de ejecución

• /------------------
  --\
• r11
  v
• 111111111111111111111222222222222222222222222NNNNN
  NNNNNNNNNSSSSSSSSSSS
  
• \--------------------/
• r11 gt Registro que almacena el puntero
  sobre-escrito
• 1 r11 gt r11 toma el valor de esta zona 1
• 2 1LEN(r11) gt La sección 2 es apuntada por
  r11
• N NOPS gt Los OFFSETS en 2 apuntan al campo
  de NOPS
• S SHELLCODE

24
4.3 Punteros de ejecución

• Ej. iPlanet Chunked Encoding overflow Solaris
  (remoto)
• Pisamos o0
• Dump of assembler code for function PR_Recv
• 0xef36bf34 ltPR_Recvgt ld o0 , g1
• 0xef36bf38 ltPR_Recv4gt ld g1 0x44 , g1
• 0xef36bf3c ltPR_Recv8gt jmp g1

25
4.3 Punteros de ejecución

• Ej. Exception Handler en Win32 (Apache Chunked
  encoding)
• Demo en vivo

26
4.4 Punteros de escritura

• Como se ha comentado
• Controlamos el valor DONDE se escribe
  Dependiendo de lo que se escriba, aunque no es
  posible la ejecución de código, tal vez sea
  posible la explotación por otras vías. En caso de
  no explotabilidad se tratan igual que los
  punteros de lectura.
• Ej. Solaris Login Enviroment overflow

27
4.4 Punteros de escritura

• Controlamos el valor QUE se escribe No tienen
  porque producir SIGFAULT. Generalmente no tienen
  utilidad de cara a la explotación.
• Controlamos ambos Caso ideal para su
  explotación. Debemos escribir en una zona de
  memoria que produzca que el flujo del programa se
  dirija a nuestro código
• Win32 - Error handlers (Unhandled Exception
  Hanlder)
• Unix - GOT de alguna función que se use

28
4.4 Punteros de escritura

• Win32
• Como localizar el Undhandled Exception Hanlder
• Unix
• GOT
• objdump -R /bin/ls grep free
• 08053a90 R_386_JUMP_SLOT free

29
4.4 Punteros de escritura

• Ej. ASP Chunked encoding overflow
• Demo en vivo

30
Conclusiones

• Ya esta? Tanto revuelo para algo tan simple?
• Pues si, aunque no sea aplicable en todos los
  casos nuestro amigo Ockham parece que tenia
  razón
• "Con igualdad de factores la solución mas simple
  tiende a ser la correcta"
• "Si puedo explicar cualquier cosa con pocos
  elementos, por que introducir elementos
  superfluos"

31
Conclusiones

• Normalmente durante la programación de un exploit
  aparecen múltiples factores que dificultan o
  hacen menos eficiente la explotación de la
  vulnerabilidad atacada. En la mayoría de casos,
  analizar la vulnerabilidad sobre lenguajes de
  alto nivel donde existe mayor nivel de
  abstracción dificulta el trabajo del exploiter y
  le obliga a realizar análisis superfluos que no
  aportan nada al resultado final de su trabajo.

32
Conclusiones

• Entonces porque no aparecen mas exploits para
  este tipo de vulnerabilidades?
• Los exploiters son vagos por naturaleza. Hay
  cosas mejores que hacer que perder el tiempo
  programando exploits. (Por ejemplo las mujeres )

33
Dudas, preguntas

• The Dark Raver - Murcia lt28/11/2003gt
• darkraver_at_t0s.org