jueves, 15 de enero de 2009

Del parche al exploit con BinDiff e ImmunityDebugger

Con motivo del apartado 4 del concurso 11 de 2008 de CrackSLatinoS, Ricardo propuso analizar 2 versiones consecutivas de WinRAR, para detectar que vulnerabilidad corregía la versión mas nueva.

En este caso de trata de las versiones WinRAR 3.10 y 3.11. La versión 3.10 de WinRAR no comprueba la longitud de las extensiones de los ficheros contenidos un fichero comprimido y procede a copiar su totalidad en una variable local alojada en la pila. Al desbordar esta variable sobreescribe la dirección de retorno guardada en la pila, pudiendo manipular esta dirección, es posible ejecutar código arbitrario.

En el tutorial se explica en detalle como utilizar BinDiff 2 y como analizar los datos que ofrece, para detectar el bloque vulnerable lo mas rápido y eficazmente posible.

Además se procede a elaborar un script que genera un fichero comprimido que provoca el Buffer Overflow y sirve de PoC (Prueba de concepto)

El tutorial finaliza mostrando los detalles necesarios para convertir la PoC en un exploit totalmente funcional, con el que se puede ejecutar código arbitrario en cualquier víctima que abra el fichero comprimido con la versión de WinRAR 3.10 y anteriores.

Espero que os guste y disfrutéis leyéndolo.
Podéis descargar el tutorial pinchando aquí.

9 comentarios:

Nico Waisman dijo...

Muy lindo tutorial.
Cuanto tiempo te llego el desafio?

Ahora el proximo paso es realizarlo Martes de Microsoft, ni bien sale un parche ;)

Cuando encuentro bugs así, me gusta escribir un scriptcito para que automaticamente detecte el bug, por ejemplo en este caso chequear los sprintf y ver si stackvars te puede ayudar a descubrir si el tamaño del primer argumento es una variable en la stack.
Te animas?

Nico Waisman dijo...

Por otro lado, un tutorial de como explotar Winrar en formato "rar", no creo que muchos se hayan animado a abrir ;)

Boken dijo...

La verdad es que ver este tipo de fallos a uno le animan a buscar mas, y para serte sincero, en eso estoy ahora mismo ;D

Estoy haciendome los scripts necesarios, pero aun no tengo del todo claro como atacarlo. Hay bastante faena y me gustaria hacer un trabajo completito.

Si, lo de que este en .rar no lo habia pensado, jejeje bueno el que no arriesga... jejeje

Saludos Nico!!

yibam dijo...

Hola Boken

He encontrado tu blog. Enhorabuena !!!

Ya he explotado el format string manualmente ...

Me voy a poner con el BinDiff a ver que tal y te cuento ...

Un cordial saludo.

Boken dijo...

Enhorabuena!! Me alegro de que lo hayas explotado.

Animo con BinDiff es muy potente y bien utilizado te ahorra mucho tiempo localizando bugs.

Saludos.

yibam dijo...

Hola Boken, Te escribo aqui porque no se como pillarte, je je je.

Tengo una duda conceptual, a ver si me la puedes aclarar, asi como si este no es el mejor medio para comunicarnos dime como lo podemos hacer. (sin ninguna obligacion, je je).

Bueno ya tengo el IDA y el Bindiff y las dos versiones de VLC a comparar, la 0.8.6b y 0.8.6c, ademas se perfectamente donde esta la vulnerabilidad ...

Bueno, he seguido tu tute (te vuelvo a repetir que es excelente la idea de seleccion de los unmatched, plas plas (aplausos)), y me encuentro que evidentemente en el exe no hay apenas funciones modifiadas ya que la funcion vulnerable se encuentra en un modulo que se carga cuando cargas un fichero, por lo que entiendo que ese modulo no se esta comparando ya que no me sale ...

Aunque no puede ser, ya que cuando se carga el ejecutable se cargan en memoria todas sus dlls, arrgg pues hay algo mal, ya que solo me sale una funcion a comparar y no es la vulnerable ...

Se que casca en _vsnprintf() y su wrapper es vasprintf pero no me sale ...

No se, te cuento los pasos:

1. Intsale el VLC vulnerable lo abri con IDA y creo su idb.
2. Lo desinstale e instale el "posible" no vulnerable.
3. La carge con IDA ejecute el plugging Bindiff y ...

La verdad es que el orden es el contrario al tuyo yo tengo como primary el no vulnerable y secundary el vulnerable seguro. (Esto tan solo me cambia en el signo de los vectores de sign).

Lo mas curioso es que me da una unica funcion ...

Bueno, killoo, a ver si me das una pista, aunque lo voy a repetir con el orden contrario.

Un cordial saludo.

Yibam desde Madrid.

yibam dijo...

Bueno Boken, creo ue el problema es que la funcion vulnerable se encuentra en una dll, y estas mo las comprueba a no ser que carge la dll y no el ejecutable.

Me lo puedes confirmar?

+NCR/CRC! [ReVeRsEr] dijo...

Muy bueno el laburo que venis haciendo relacionado con los exploits!, me gusta mucho!. Felicitaciones!.

Anónimo dijo...

te felicito, podrias revisar el enlace que no puedo descargarlo.

gracias.