Echando un vistazo al subversion de metasploit, me di cuenta de que después las ultimas actualizaciones que han hecho en su exploit para el servidor DNS del que tanto hemos hablado estos días este es compatible con DEP/NX !!, a primera vista pensé .. «WTF???», total que me puse a mirar como lo habían conseguido, descubriendo algo muy interesante que no conocía … 🙂

Si echamos un ojo al código fuente del exploit en los targets vemos las siguientes líneas:

# ATL.DLL (bypass DEP/NX, IB -> Image Base of ATL.dll)
[ ‘Windows 2003 Server SP1-SP2 English’, { ‘OS’ => ‘2003SP12’, ‘Off’ => 1633, ‘IB’ => 0x76a80000 } ],
[ ‘Windows 2003 Server SP1-SP2 French’, { ‘OS’ => ‘2003SP12’, ‘Off’ => 1633, ‘IB’ => 0x76a30000 } ],

Lo primero que pensé es que estaban de alguna manera explotando un exception handler registrado en la ATL.DLL, total que pillo la imagen de VMWare y lanzo el exploit con el debugger attacheado al servidor DNS, la técnica que utiliza el exploit es la de sobreescribir el exception handler con una direccion dentro de ATL, seguir escribiendo para provocar la excepcion cuando se llegue al límite de la pila, y de esta manera se salta «/GS», hasta aquí todo normal …
Cual fue mi sorpresa al comprobar que en la ATL.DLL que estaba cargada permitía ejecutar código en cualquier posición, vamos que DEP no estaba funcionando en ese módulo !!, el exploit lo que hace realmente es aprovechar esto, junto con la técnica comentada por skape y Skywing , buscando un poco de informacion por internet sobre este misterioso hecho (por lo menos para mi), me he encontrado con el resumen del libro «Writing secure code for windows vista», donde se dice textualmente:

«About Data Execution Prevention, already spoken about in third chapter, it’s enabled for most of Windows Vista system processes; compatibility checks are performed through Internet Explorer Compatibility Test Tool, also included in ACT 5.0. A known incompatibility is that applications using older versions of Active Template Library (ATL) will fail and run correctly when DEP is enabled; developers will use ATL 8.0 or higher, enforcing this with assert(AtlGetVersion(NULL) >= 0X0800);»

Si echamos un vistazo a los modulos cargados en el DNS nos encontramos con lo siguiente

Interesante, parece que los programadores van a tener que andarse con cuidado cuando utilicen ATL en sus proyectos … 🙂

Un saludo !

Bueno, pues hemos actualizado algunas cosillas en el exploit :

– Se utiliza un offset universal para 2k3, tanto en local como en remoto, este offset pertenece a unicode.nls y no lo habíamos puesto antes porque no nos dimos cuenta de que se podían usar direcciones con bytes nulos aprovechando las features de extractQuotedChar(), notese que no nos saltamos DEP, solamente /GS, lo cual no es muy util, pero bueno, viene bien como ejercicio de programación 🙂

– Se resuelve dinámicamente el puerto dns rpc, aunque se puede especificar el que se desee.

– Se ha cambiado la shellcode, solo funcionaba en 2k3 si no recuerdo mal.. y parece que la que está puesta ahora, también cortesía de metasploit, funciona bien con los dos sistemas operativos.

– Se han añadido offsets para más sistemas operativos, y la posibilidad de búsqueda de offset universal en local para 2k.

– Algun bug … seguro 🙂
Por otro lado nos hemos estado comiendo un poco el tarro para ver si se podía saltar DEP, aunque fuera en local, pero no lo hemos conseguido, los tiros han ido por:

– Revision de la rutina afectada: Se puede explotar alguna variable afectada por el overflow?, por lo que yo he visto.. no, la idea ver si se podía controlar algún puntero loco por ahí e intentar sobreescribir la variable que contiene el directorio de Windows en KERNEL32.DLL (todo esto es idea de David Litchfield.. ) , de tal manera que pisando la security_cookie, al ser llamado el UnHandledExceptionFilter pudieramos inyectar remotamente nuestra faultrep.dll, ¿si no me equivoco LoadLibrary es capaz de cargar DLL´s en rutas UNC no?, ¿alguien ha visto algún exploit que haga uso de esto?? 🙂
– Inyeccion local mediante WLSI, tecnica documentada por Cesar Cerrudo, por lo que hemos visto no puede ser usada para saltarse DEP ya que los permisos de la seccion inyectada no tienen el flag de ejecución :-(.

– Saltar DEP apilando llamadas a funciones en el stack, esto se puede hacer, pero el problema principal que hay es que esto es facil de hacer cuando no está activado /GS, porque provocando una excepcion al ser llamado el handler, tendríamos que apuntar a una secuencia válida tal que la siguiente:
pop reg; por reg, mov esp, [esp]; ret

Y no sé si existirá…
Bueno el tema está interesante, si alguien quiere discutir sobre estas cosillas,
que me mande un mail 🙂 !

El exploit lo teneís aquí, un saludo!
P.D: Un saludo para Andrés, que se lo ha currado!!

Hola,

Aquí os dejo el análisis de la vulnerabilidad y un exploit que hemos programado Andrés Tarasco y yo, el exploit está programado como bender manda, usando el API de RPC de Windows y funciona a través del puerto 445 tcp el cual Microsoft en un principio no había tenido en cuenta, ahora han actualizado el advisory 😉

Un saludo!

Hace algunos días, cayó en las manos de Victor un DVD con el MacOSX para instalar en maquinas intel «normales», Victor andaba rondando la idea de comprarse el flamante Mac que tiene hoy y decidimos probar el sistema operativo que para nosotros era un gran desconocido. Procedimos a instalar el susodicho DVD en dos máquinas diferentes y cuando acabó la instalación, apareció la bonita interfaz del MacOSX, despues de pelearnos un rato con algunos conceptos de manejo del sistema, seguramente heredados de nuestras manías windowseras, vimos que lo único que no funcionaba era la red. La máquina al no ser un Mac nativo no venía con el correspondiente driver para la tarjeta de red, mirando un poco por internet, acabamos en la web del proyecto osx86, en los foros habían colgado un driver, que se ve que era de otra tarjeta con un chipset parecido, y en el cual habían modificado entre otras cosas el «Device ID» y habían insertado algun parchecillo por problemas que daba leyendo la NVRam de la tarjeta. Bueno, procedimos a instalar el driver en una de las máquinas y funcionó, pero cuando lo instalamos en la otra nos dimos cuenta de que la MAC estaba hardcodeada en el driver!, con lo cual nuestras dos máquinas no podían compartir la misma red 🙁 . Buscamos por el mismo foro y encontramos que había gente que ya se había dado cuenta del problemilla y comentaban como arreglarlo con un editor hexadecimal, bueno pues manos a la obra con nuestro hiew (queremos un port para macosx!) fuimos y parcheamos a ciegas donde la gente comentaba, nuestro intento acabó frustrado por un kernel panic … despues de un rato mirando posts, llegamos a la conclusión de que lo mejor era pasar a abrir el driver con el IDA y aquí es donde empieza la verdadera historia de depurar manzanas a ciegas …

(más…)

Con este post inauguramos la nueva seccion en 48bits de arte: