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

[RaiSe]

-----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.

> 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.

> En DeepZone si. Todo tiene su justo valor; personalmente no creo que un b0f
> sea la forma mas adecuada de atacar un kernel 9x por su inestabilidad. Para
> el creo que existen formas mas adecuadas, mas portables y con mayor
> probabilidad de exito. Esto es opinable por supuesto, no entrare por lo
> tanto
> a refutar opiniones.

Es cierto que al explotar un overflow en Windows 9x hay muchas
posibilidades de que te cargues el sistema, pero MUCHAS veces no hay otra
forma. Y sino ya me diras una manera de atacar un servicio que contiene un
overflow sino es explotandolo.

> 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 ;) ).

> 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.

> Algo asi. Referencio las direcciones de las API con dos saltos indirectos en
> la IT de
> 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?. Te pones a mirar cada OFFSET de cada binario?, un poco pesado,
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 ;) ).

> 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..

> En NT esto no es asi. Sino tienes espacio los exploits mas recientes han
> demostrado que sobreescribir
> pasada la direccion de retorno no es un problema.

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.

> 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..

> Servicios lanzados en 9x son deslinkados frecuentemente cuando el exploit
> quiere retomar el control y
> es a esta clase de b0fs a los que me referia como b0fs remotos.

El ejemplo que te puse es de un overflow remoto (para ser exactos un
servidor de ftp), y el exploit funciona perfectamente, asi que no se a que
te refieres.

> Dices que me equivoco "otra vez" X) Esta claro que este punto es totalmente
> opinable. No creo que
> saquemos nada en limpio dandole vueltas. Yo creo que ya te he comentado en
> lineas anteriores todo
> lo que te tenia que decir sobre este tema.

Si, te equivocas :). Como ya digo, tengo por aqui un exploit remoto para
un servidor ftp que corre en Windows 9x, y no se produce nada de
deslinkeamiento. Por lo tanto la logica me dice que te equivocas.

> SEH son las siglas de "Structured Exception Handling". En virus las
> utilizamos para romper virtualizaciones,
> chequeos, cambios de flujo ... La idea es proteger un fragmento de codigo
> que puede lanzar una excepcion
> estableciendo en la pila el frame adecuado.

Sip, sabia lo que era pero no lo reconocia por las siglas ;P.

> Aun asi y sin animo de ofenderte (sino no estaria debatiendo contigo) tienes
> una facilidad alucinante de hacer
> predicciones, juicios de valor y enunciados basados en la Fe que me han
> llegado a sorprender X)

Gracias, lo tomare como un cumplido ;).

> Me has dicho que me he "equivocado varias veces", que mi "codigo no era
> portable", que "tu tecnica es mejor",
> has basado la eficiencia de tu codigo en 9x cuando la implementacion de una
> consola remota en NT es (casi) imposible,

Me imagino que ahi querias decir en Windows 9x casi imposible.

> has incluido la "presencia de defectillos" en el codigo cuando no es asi y
> ahora enuncias una probabilidad con la
> que tengo que estar de acuerdo (supongo ... cualquiera te dice algo ;).

Ejem, espera a la ultima parte del mail (es broma).

> > bits y acertar con las de GPA y LLA te aseguro que son bastante mas
> > elevadas :)
>
> Estas seguro ?

Me referia a usar valores aleatorios en caso de no disponer del binario. Y
si, estoy seguro :).

> 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.

> 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.. :).

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.

Al empezar la ejecucion para conseguir el registro %eip usas un mecanismo
que usa la pila. Eso no es nada conveniente, porque al hacer el overflow
no sabes el valor de %esp, con lo cual yo en mi caso sobreescribia la
propia shellcode, y luego obviamente petaba. En la mia no ocurre porque me
aseguro que al 'pushear' nunca se sobreescriba la shellcode (en la tuya me
imagino que tambien).

Y nada, despues de setear yo manualmente %esp para que no sobreescribiera
nada, la shellcode se ejecutaba, pero simplemente terminaba el proceso
(con un ExitProcess me imagino), y no daba ninguna shell.. :?. Me fue
imposible seguir todo el codigo por su complejidad y porque no disponia
del fuente, asi que no se exactamente porque no rulaba. Se me ocurrio
pensar que quizas fallaba al cargar alguna libreria con LoadLibraryA,
porque yo tuve ese problema y era que si en el momento de cargar otra
libreria %esp no era divisible por cuatro siempre devolvia NULL. En mi
shellcode %esp siempre tendra un valor valido, en la tuya no se asi que no
se si sera por eso o no porque pero no me iba.. a mi se me ocurrio pensar
eso. Como no sabia porque era intente contactar contigo pero sin exito, te
iba a mandar un mail hoy. Si quieres escribeme al mail para no saturar la
lista, o como veas.

Pues nada mas, voy pirando que llego tarde XD.
Nos vemos, un saludo.


==============-----------------------------==============
RaiSe
UNDERSEC Security Team / http://www.undersec.com
NetSearch Ezine Staff  / http://www.netsearch-ezine.com
ysfk>2{5~~2s~eska2~}dw2k}g<<< XOR 18
==============-----------------------------==============

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQE7ujW5SP4h0VxUtqMRAhpTAJ4ivCBC17ed3He7Vz3bg3eQIiHl7ACfYKwS
iLOqR3vSj77ue5+SNQRZGUU=
=89Gk
-----END PGP SIGNATURE-----