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

[|Zan]

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

Hola Raise,

>> Nuevas caracteristicas ...
>>
>> * Soporte para Java añadido.
>>
>> * Shellcodes automaticamente generados trabajando debajo de NT/2k y
ahora,
>> oficialmente, en Windows XP.
>>
>> * Algunos ejemplos de exploits remotos con privilegios de autoridad local
>> (SYSTEM) incluidos.
>
> Nass, la shellcode no se q hace pq no la he probado (q hace? :?),

Lo unico que tenias que hacer era leer por encima cualquiera de los dos
links que envie y al instante lo sabrias pero yo te lo cuento :)

El codigo, en cuestion, bindea una consola a un socket a traves de pipes
(binding technique) en el puerto 8008. El primer ejemplo publico conocido de
esta tecnica en el mundo Win32 lo hizo Jack Barnaby para IIS4.0 (ya todos lo
conocemos) y fue presentado en phrack 55 como la tecnica mas "interesante e
ideal" para explotar desbordamientos de pila debajo de tecnologia NT.

> pero le
> veo un par de defectillos q en mi shellcode (http://www.undersec.com)
> estan solucionados.

Conozco tu codigo. Hace una semana lo enviaste a vuln-dev y fue sometido a
debate por un salto con un error de 7 o 9 bytes en un call que fue arreglado
en una sucesiva version. Tambien lei las apreciaciones que comento Ryan
(eeye.com) y demas observaciones que realizasteis. Estoy seguro que esos
"defectillos" de los que hablas desapareceran con este e-mail :)


> El primero q no soporta ni windows 98/me ni windows 95.

A ver, estoy seguro que cuando leas la informacion complementaria del
generador observaras que el codigo tiene un fin muy claro y el compromiso
seguido en su elaboracion no permite soporte para el kernel 9x.

El generador es una herramienta para desarrolladores de exploits y
pen-testers debajo del kernel NT (2k, XP ...), esto es asi por diversos
motivos:

1 -. Servidores.

El kernel 9x no es un kernel adecuado para prestar servicios a terceros
siguiendo una arquitectura cliente-servidor. Quizas en una LAN o en la
intranet de un domicilio sea una solucion economica pero la realidad es que
ninguna empresa "seria" prestaria servicios con un "juguete" asi.

2 -. Arquitectura.

En lo unico que se parecen el kernel 9x y el kernel NT (y sucesivos) es en
el interfaz y en un % elevado de compatibilidad a nivel de API. Esto supone
que ajustar una consola a traves de pipes en un 9x lanzando un "command.com"
tendria unos resultados desastrosos (prueba a hacerlo con netcat). En el
momento en que el objetivo es lanzar una consola remota pensar en hacerlo en
9x no es muy adecuado.

La verdad es que no hemos buscado la compatibilidad para Win9x porque no es
interesante desde la perspectiva de un *ataque real* por un potencial
intruso. Si lo que buscas es lanzar una consola (como es el caso) el no
soporte de Win9x no es ninguna limitacion. Me sorprenderia ver un servidor
de la casa blanca sirviendo con Windows 95 y Personal Web Server ...

> El segundo que las
> direcciones de GetProcAddress y LoadLibrary vienen hardcodeadas, es decir,
> una shellcode funcionara en Windows NT y en XP o 2k la misma shellcode no
> funcionara sino que habra que generar otra.

X)

Esto no es asi en absoluto. El shellcode utiliza GetProcAddress (GPA) y
LoadLibraryA (LLA) para reconstruir las direcciones correctas en el stack
pero las direcciones de estas no se consiguen con un valor hardcodeado en
absoluto. Esto significa que un exploit para el mismo binario funcionara en
todas las versiones corriendo el kernel NT/2k/XP y futuras.

La idea aqui es utilizar el mismo principio que un virus infectando
"per-process". Esta tecnica fue conocida a traves de Jacky Qwerty (ex-29A) y
consiste en hookear (sin entrar en muchos detalles) un array sosteniendo
punteros a las direcciones base de las API importadas. Que significa esto ?
pues sencillamente que hardcodeas un par de punteros en una imagen binaria y
a traves de un salto indirecto consigues la direccion correcta funcionando
perfectamente para cada version de todos los operativos.

Por ejemplo, si conoces que la API GPA tiene la direccion 'Y' en NT, la
direccion 'J' en 2k y la direccion 'Z' en XP no hardcodees en absoluto estas
direcciones cuando puedes saltar contra la direccion "I" indirectamente; que
conoces de antemano que siempre apuntara a la direccion correcta.

call Y en NT = call J en 2k = call Z en XP = call dword ptr [I] en todas

Esto es posible porque se cumplen dos premisas. SIEMPRE estas explotando la
misma version del binario y NT trabaja con el formato PE.

Como ves es una cuestion de compromiso.

> Y el tercero que ocupa 1200 y
> pico bytes.

Estamos hablando de un hack completo. No se trata de hacer un ejercicio de
programacion ni de optimizar. Se ha elegido una tecnica con sus ventajas y
sus desventajas. Imaginate el siguiente escenario.

Un servidor WWW IIS 5.0 sp0 corriendo en el puerto 80, Statistics Server 5.x
corriendo en el puerto 8008 (de esta manera la configuracion por defecto
valdria y no tendrias que cambiar el puerto remoto) y un router permitiendo
solo conexiones entrantes. Sabes que ss5.x tiene un desbordamiento, lo
aprovechas y anulas el servicio. Explotas IIS5.0 y lanzas la consola en el
8008. Te conectas al 8008 y tienes la maquina sin realizar ninguna conexion
saliente.

En este escenario tu tecnica  no valdria. Por otro lado, tu tecnica intenta
grabar a disco un fichero ... imaginate que no puede ... imaginate que el
servidor esta leyendo los discos a traves de un share por red ...
sencillamente fallaria porque el proceso servidor aunque corra con
privilegios de SYSTEM no puede escribir a ese share de solo lectura.

Como ves es una cuestion de compromiso. Eliges una tecnica y la explotas.


>
> En la mia el primer problema se soluciona, esta testeada en todos los
> windows desde el 95 (incluyendo XP).

El kernel 9x debido a su manejador de procesos hace muy complicada la
explotacion de un desbordamiento remoto. Si buscas desbordamientos remotos
en 9x veras que no existe ninguno conocido. Esto es debido a que el kernel
9x deslinka los procesos de su lista ante un b0f. Basicamente el problema
que existe es que cuando intentas saltar de vuelta a la imagen del proceso
esta ya no esta alli. Te invito a que le eches un vistazo al desbordamiento
de "Statistics Server 5.x" descubierto por Nemo y explotado en DeepZone por
mi. - http://www.deepzone.org

A lo anterior sumale la idea original de que (casi) nadie sirve en 9x de
forma seria (el caso de la NASA y el Win95).

Nota que he dicho "complicada" y no "imposible"; pero esos pocos casos que
servirian de contraejemplo habria que encontrarlos en el software real
comercial. Practicamente imposible.

Tu tecnica es una reverse-connection para bajar y ejecutar. Como ves, si
tienes acceso fisico (que seria la otra situacion complementaria a la
anterior), utilizar una reverse-connection a traves del interfaz local
(127.0.0.1) cuando estas tratando de elevar privilegios (y quizas no puedas
instalar un servidor para bajarte el troyano) es absurdo cuando puedes
utilizar memoria compartida.


> El segundo tambien pq saca las
> direcciones recorriendo el propio PE Header de la imagen en memoria del
> ejecutable, es decir, la misma shellcode SI funcionara en cualquier

Se que funciona, porque es la misma tecnica que utiliza mi virus
Win32.h0rtiga (primer release de hace un año aproximadamente). Tambien
decirte que no es nada nuevo, esta tecnica "vio la luz" de la mano de DDT
(creo que fue este grupo) a traves del ezine de 29A. Esta tecnica tiene sus
desventajas tambien como es asumir una direccion base o trabajar con SEH.

Asumir una direccion base es, sencillamente, hardcodear. Pierdes la
independencia y con ella todas sus ventajas. Es igual que tu exploit dependa
de 1 byte como de 600. O es portable o no lo es :)

Trabajar con SEH es otra posibilidad pero no siempre puedes establecer un
frame adecuado en la pila e iterar en una situacion inestable de explotacion
real. Como siempre habra casos en que funcione y habra casos en que no
funcione. Recuerda lo que os comentaba Ryan (eeye.com) acerca de la
corrupcion de la pila (es mas que probable encontrar este tipo de
situaciones).

> windows sin necesidad de cambiar nada. Y el tercero tengo dos shellcodes,
> la primera que necesita que LoadLibraryA este en la import table del
> ejecutable ocupa 710 bytes, y la segunda que necesita GetModuleHandleA (x
> si LoadLibraryA no esta) ocupa 790 bytes.

Es decir, tienes dos versiones que ocupan mas de la mitad de esos 1200 bytes
que te parecian exagerados y tienes mas posibilidades de no acabar en exito.

Yo creo que estas olvidando que conoces la imagen binaria a explotar de
antemano y eso es vital. Si el servidor tiene en memoria la imagen a
explotar entonces siempre tendras exito con mi ataque mientras que sino la
tiene es indeferente que tenga exito o no puesto que ya no se trata de la
imagen que tiene esa vulnerabilidad.

> Las dos shellcodes tienen un
> string modificable que es una URL que debe estar apuntando a un exe
> (ejecutable). La shellcode se lo baja x protocolo http, lo guarda y lo
> ejecuta, ideal para troyanos :).

Esta situacion fue ampliamente discutida por Greg Hoglund proporcionando un
stub de ataque alla por el IIS 4.0 sp4 o 5. Tienes mas informacion en
http://www.rootkit.com

> El unico requerimiento para que funcione
> es que la imagen base del ejecutable sea 00400000h (el 99% de los
> programas), y en caso de que varie seria cambiar 1 byte en la shellcode.

Como ya te he dicho si supones que la imagen es 4....h estas hardcodeando.
Funcionara en la mayoria de los servidores por ahi adelante pero (por
ejemplo) en los servidores de DeepZone ya no funcionaria ;)

He incluido en el subject una referencia a material viral por si GriYo o
cualquier persona relacionada con el mundo virico quiere confirmar el apunte
de DDT. Desconozco en estos momentos la direccion de 29A, de ahi que no haya
enviado el link correspondiente.

Me ha encantado debatir con otro grupo colega en España. Parece que la scene
Española estaba un poco muerta o (por lo menos) escondida y me ha agradado
ver que no es asi ;)


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/AwUBO6t1kUaVob5q1uFzEQJaKwCfTxDLxu0Bd9brl/+ngf88+sd2VgwAn21W
O/PNgbyIvCmwhqtZmQ90sxoN
=SXQL
-----END PGP SIGNATURE-----