[HACK] Re: (Cerrando THREAD) [DeepZone black tool] NT/2k/XP portable shellcode generator updated! (Win32 viral stuff add-on!)

[|Zan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Nass. Voy a pasar de contestar todo el mail porque esto se haria eterno
> :), contesto un par de cosillas y luego te comento otras de tu shellcode
> que estuve probando y me llamaron la atencion. Intente localizarte por irc
> para comentartelas, pero no lo conseguir, asi que aprovecho y te las digo
> por aqui.

Si, me parece que esto ya se esta haciendo eterno, permiteme por lo tanto y
siguiendo los turnos de critica/defensa cerrar a mi el thread respondiendote
a estas ultimas dudas que te surgen.

>> En el mail anterior te comente que el generador es para explotar
tecnologia
>> NT y fue desarrollado con esta premisa en mente. Esto permite utilizar y
asumir
>> ciertos criterios que no podrian asumirse de realizar un diseño mas
general.
>
> Ok, queda claro que tu intencion no era hacer una shellcode que funcionara
> en Windows 9x.

Queda claro entonces que has entendido lo de las precondiciones y premisas
de entorno que son aplicables para generar un shellcode con la herramienta.


>> ok. Has elegido una tecnica y la has explotado.
>
> Sip. Por cierto, me llamo la atencion que en el anterior mail te metias
> con mi metodo de bajar un archivo de una URL, grabarlo y ejecutarlo, y no
> parabas de referenciar a eEye. Cual es mi sorpresa al descubrir que en su
> 'tool' para explotar el IIS usan exactamente ese metodo (lo digo a modo de
> anecdota ;)

Te contesto brevemente. eEye ha liberado en su ya dilatada explotacion de
IIS (4, 5 ...) varias 'tools' y 'proof of concept codes'. Encontraras en su
pagina frases que hacen referencia a la demostracion rapida de dichas
vulnerabilidades a traves de sencillos y minimalistas shellcodes expandiendo
cajas de dialogo, bajando y ejecutando una imagen binaria, lanzando el
wordpad ... para finalizar advisories y parrafos con la posibilidad de
shellcodes mas elaboradas. Recordaras, por ejemplo, que con el .ida b0f no
han liberado su codigo de consola y si un 'pequeño juguete' inocuo. Por otro
lado tambien podras leer en varias paginas del site que en caso de no poder
inocular codigo conteniendo un hack final siempre puedes utilizar la tecnica
de bajar y ejecutar por su tamaño (esto solo lo añado como complemento a tu
anecdota para dar una vision objetiva a nuestros lectores ;)

>> A ver, exactamente donde he dicho que solamente se deberian realizar
>> exploits para los OS de la NASA o la Casa Blanca ?
>
> Queria decir que segun tus opiniones solo se deberian realizar para
> sistemas operativos servidores.

No, lo que queria decirte es que desbordamientos en clientes siguen sin
parecerme interesantes.

>> un binario vulnerable que conozco de antemano. Siempre conoces la imagen
>> vulnerable de antemano puesto que estas realizando el exploit para un bug
>> concreto.
>
> No siempre, imaginate que un programa es vulnerable en sus versiones 2.1,
> 2.2, 2.3 y 2.4, y tu quieres desarrollar un exploit. Q haces?, le metes
> una shellcode para cada version pudiendo usar una que sirve para los
> cuatro?.

Tendria que buscar una IT de su ejecutable o de sus modulos .dll's que
permanezca constante en todas las versiones, tan solo eso.

> Te pones a mirar cada OFFSET de cada binario?, un poco pesado,

Ni mas pesado ni menos pesado que buscar un salto intermedio de retorno.
Vamos, añadir dos DWORDs mas supone un esfuerzo :?

> no? :). Lo mismo digo para la version koreana, ingles y española.. una
> shellcode para cada binario?. De donde sacas el binario de la version
> koreana, entras al canal #korea a pedirlo? (eso ultimo era una broma
> para referenciar que a veces no es tan facil conseguir el binario ;) ).

ufff!!! en la IT se linkan las APIs en un determinado orden y no tiene nada
que ver con el lenguaje. Una shellcode generada para un programa koreano
solo tendra el incoveniente en el punto de retorno y no en la IT. No se si
es casualidad o si al final acabaste leyendo la documentacion del generador
pero tienes un exploit para IIS5 koreano por Mat que funciona igual de bien
en la version española.

>> Yo prefiero basar la explotacion en el binario conocido y no en la
version
>> de operativo desconocido que pueda estar corriendo el servidor a atacar.
>
> Yo no me baso en nada, como mucho en la direccion base del programa
> vulnerable, que no varia con los cambios de version de la aplicacion /
> programa vulnerable..

La anterior es una frase un poco confusa "Yo no me baso en nada, como mucho
en ...".

En tu codigo aparece hardcodeada la direccion 400000h como direccion de
carga de los procesos por el loader del OS. Direccion que coincide en todos
los OS que ha sacado Msoft hasta la fecha y que en cualquier momento puede
cambiar (aunque existen pocas probabilidades) por lo tanto yo creo que lo
que hay que ser es serio y no decir que no te basas en nada.

>En UNIX tampoco hay problema.. De todas formas en Windows NT/2000 si que
>hay un problema. Y es que si tu quieres saltar a la propia imagen del
>binario en memoria (a un call *%ebx por ejemplo), para desde ahi saltar a
>la shellcode si es importante. Por cierto que saltando a la propia imagen
>del binario las posibilidades de que funcione el overflow es del 100%, ya
>que como bien sabras no varia de un sistema operativo a otro.
>
>Pues bien, como las direcciones base empiezan con 00, necesitas el null de
>final de cadena del tipico 'strcpy' para sobreescribir en la direccion de
>retorno algo como: 004001235ah. Y eso si la shellcode es demasiado
>grande no sirve, ya que no podrias usar el null. Por eso y por bastantes
>cosas mas, la longitud de la shellcode SI es importante.

No lo creo. Ya me ha aparecido ese problema y lo he solventado sin ningun
quebradero de cabeza.


>> Por otro lado estamos hablando de una diferencia de 700 a 1200 bytes. Me
>> inclino a pensar que si
>> es explotable con 700 bytes no habra ningun problema para hacerlo con
1200.
>> Si esto no fuera posible
>> un ataque multi-disparo (tienes algun ejemplo en BugTraq de algun exploit
>> hecho por mi hara un año)
>> puede ser apropiada.
>
> Hay muchas veces que no se puede. Por el metodo que te expuse antes del
> null por ejemplo, siendo muchisimas variables tipicas de 1024 bytes,
> tu shellcode ya no serviria. Lo del metodo multi-disparo voy a ver si lo
> miro porque no se a que te refieres..

Lo del null no es un problema. Una variable tipica son 255 bytes no 1024.
Puedes buscar en los includes de cualquier compilador para Windows por 1024
y ver cuantas variables "tipicas" aparecen y que no sean constantes ;)

>> Imaginate que el siguiente programa es el que estas interesado en
explotar.
>> Conoce la direccion de ExitProcess
>> en la IT y la utilizas de forma indirecta. Es decir, he hardcodeado la
>> direccion de ExitProcess a la IT. Ahora,
>> pruebalo en cualquier sistema operativo que quieras y veras como funciona
>> sin problemas.
>
> Ya, pero por ejemplo para cada version/lenguaje del binario tendrias que
> generar una shellcode, cuando la mia serviria para todos. Es decir, hacer
> un exploit por ejemplo para X aplicacion <= version tal, seria imposible.
> La unica solucion seria incluir varias shellcodes, o cambiar la shellcode
> y recompilar, pero si te vas a poner a defender eso apaga y vamonos.

Lo del lenguaje da problemas en tiempo de ejecucion, la IT se crea al linkar
por lo tanto el lenguaje no es un problema. Acerca de la version se puede
dar el caso que la IT haya cambiado (mas frecuente y con mas posibilidades
que te cambien la direccion de carga desde luego) pero es un precio que
tienes que pagar.

>> Como que sin conocer el binario. Tienes que conocer de cuanto es el
>> desbordamiento, estudiar
>> un punto de vuelta al codigo y observar en el proceso dos punteros mas no
es
>> que sea un
>> trabajo excesivamente cansino. Vamos, esto ultimo me ha sonado a broma ;)
>
>No, si me vas a convencer.. Ahora pienso porque estuve yo programando una
>shellcode en la que no hiciera falta, si total, son 5 minutos.. :). Y
>bueno, si alguien no tiene npi de como hacerlo, o no dispone del binario,
>pues ajo y agua.. :).

Hombre, es un poco ligero por tu parte decir lo anterior cuando el generador
se ha creado para desarrollar multiples shellcodes cuando una no funciona
orientado a gente no-tecnica y tecnica. No creo que la despreocupacion por
el desconocimiento de un posible explotador exista por nuestra parte.

>Bueno, por fin he llegado al final jeje. Veras, me he bajado tu shellcode
>(cuyo codigo fuente por cierto no esta disponible, mientras que el mio
>si), y me ha sido imposible hacerla funcionar.
>La probe en Windows 2000
>Server, con un programa de prueba que genere y con los offsets correctos.
>La shellcode en si se ejecutaba, pero tuve varios problemillas.

Siento que no fueras capaz de hacerla funcionar.


Saludos!
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: http://www.deepzone.org/contact/izan.asc

iQA/AwUBO8HcNkaVob5q1uFzEQKiNACgkelmnJ0bNDYPoK9LoX7viG5gEPcAoI9t
PMsCdEbrs1cwtACjWWTPQxlC
=A8kv
-----END PGP SIGNATURE-----