Bueno, después de la bluepill,la redpill y la purplepill llega la bacalaoalpilPill. Esta noche tenemos a John Wuaichachi and Maik forever para presentárnosla.

JW: ¡ Fantástico Maik !, nos encontramos otra noche aquí para presentar a nuestra distinguida audiencia un producto que revolucionará lo que tenga que revolucionar si es que revoluciona algo.

MF: ¿Y de qué se trata John?

JW: ¡Me alegra que me hagas esta pregunta Maik!,¡DEPUTAMADRE MAIK! tenemos en nuestras manos la bacalaoalpilPill, un exploit que usa un driver que está firmado, y por lo tanto puede ser cargado en Vista x64, como pasarela para ejecutar código no firmado en el contexto del Kernel.

MF: ¡Estoy aluciflipando John! ¿Y como se ha conseguido?
(más…)

Buenos dias, nunca escribi una entrada para el blog asi que pienso que es buen momento para empezar. Hace un par de dias salio una vulnerabilidad en el kernel para x86_64. Al parecer mucha gente no tiene muy claro de que va el tema así que voy a intentar explicar en que consiste.

En la descripción del advisory de Wojciech Purczynski esta perfectamente claro donde están los puntos vulnerables del codigo, pero no se explica exactamente en que condiciones pueden ser explotados. Luego esta el exploit que hace uso de ptrace() para la explotacion. Mucha gente piensa que el problema esta en ptrace pero en realidad ptrace es un vector al problema (el único diria yo).
Ahora vamos a analizar algo del codigo en x86_64/ia32/ia32entry.S para ver como influye ptrace en la vulnerabilidad. Como se comenta en el advisory el codigo vulnerable es el siguiente:

—8<—
sysenter_do_call:
cmpl $(IA32_NR_syscalls-1),%eax
ja ia32_badsys
IA32_ARG_FIXUP 1
call *ia32_sys_call_table(,%rax,8)
—8<—
cstar_do_call:
cmpl $IA32_NR_syscalls-1,%eax
ja ia32_badsys
IA32_ARG_FIXUP 1
call *ia32_sys_call_table(,%rax,8)
—8<—
ia32_do_syscall:
cmpl $(IA32_NR_syscalls-1),%eax
ja ia32_badsys
IA32_ARG_FIXUP
call *ia32_sys_call_table(,%rax,8) # xxx: rip relative
—8<—

(más…)

Hola,

Para aquellos que sintaís curiosidad sobre como eran el tipo de pruebas en el CTF, os dejo el siguiente paper, en el que se explica como conseguimos explotar uno de los servicios que se encontraba en las máquinas de kenshoto, el HFD.

Ha sido redactado por nuestro capitán, creemos que de alguna manera está intentando «ganar puntos» para que el año que viene, si concursaramos de nuevo, le dejemos ir a alguna que otra fiesta, o no!? ;-D . Aunque no creo que le vaya a servir de mucho, felicidades!, el intento ha sido bueno, en mi humilde opinión te ha quedado bastante bien 🙂

Bueno aquí os dejo el enlace,

Un saludo!

P.D: Hay que ir preparando el SPEF 😉

Buenas noches a todos y todas…

Hace ya algun tiempo que haciendo el tonto descubri dos pequeños errores en el codigo que gestionaba las IOCTL’s de uno de los drivers del Norman. Uno de ellos es un simple despiste a la hora de reservar un buffer para almacenar una cadena de texto. Y el otro un error a la hora de chequear adecuadamente los parametros que que un usuario puede mandar al dispositivo, y que en ultima instancia lleva a tener el control absoluto sobre un parametro en una llamada a una funcion del Kernel.

Dos pequeños despistes que sobre todo nos demuestran lo importante que es ir con pies de plomo en elementos tan sensibles como drivers, servicios, etc. donde un pequeño error puede suponer dejar el sistema en manos de cualquiera.
Y bueno, despues de mucho tiempo, al fin he conseguido sacar un poco de tiempo libre, poner por escrito algo parecido a un advisory, y añadir unos comentarios al exploit que hice a modo de prueba de concepto, todo lo cual os podeis bajar pinchando AQUI

Espero que disfruteis con la lectura, y en cuando al codigo que añado a modo de prueba de concepto, a pesar de estar muy lejos de ser una maravilla, creo que es un ejemplo original.

Sin mas, un saludo
Y por aqui estare esperando vuestro feedback ;o)