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

[RaiSe]

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

On Fri, 21 Sep 2001, |Zan wrote:

Joer macho, vaya rollo q me has soltao jeje ;).

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

Bueno, lo primero decir q yo no sabia nada de programacion de shellcodes
ni de asm en windows 9x/NT hasta 1 mes antes de realizar la shellcode, asi
q en algunas cuestiones tecnicas no te podre rebatir, te ruego me perdones
;).

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

Eso no era problema de la shellcode, sino que con las prisas al pasar el
codigo de asm a un array de C, le meti 13 bytes de basura que estaban
antes de la shellcode. Un error humano, pero la shellcode no tenia ningun
bug.

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

Vamos a ver, que quieres q te diga?.. Tu shellcode tendra ventajas y
desventajas, igual que la mia, pero yo prefiero que funcione en cuantos
mas sistemas operativos mejor, tu no?.

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

Estoy de acuerdo, pero aqui volvemos a lo mismo, la shellcode se supone
que esta hecha para realizar exploits con ella. Esos exploits se supone
que en algunos casos se usaran como sistema de testeo y otras veces no.
Resumiendo, solo se realizan exploits para testear/hackear empresas
"serias"?. Los exploits para windows9x son factibles, asi que xq no una
shellcode para ese sistema operativo?.

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

Yo cuando me puse a hacer la shellcode inicialmente iba a hacer eso, pero
un colega me comento que el tema de bindear 'shells' en windows 9x esta
muy complicado, por eso elegi el metodo de bajar/ejecutar un programa de
algun server web.

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

No estoy de acuerdo con esa politica, segun tu solo se deberin realizar
exploits para los sistemas operativos de la nasa o la casa blanca?. Te
olvidas que Windows 98 y ME es el sistema operativo mas difundido del
mundo.

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

Mm.. sino me equivoco lo que haces es referencias las direcciones GPA y
LLA desde el propio Import Table (IT) del binario?. Si es asi, que pasa si
no estan pq no fueron importadas?. Segun mis conocimientos la unica
segura que esta es GetModuleHandleA. LLA a menudo sino carga ninguna dll
no es importada. Lo siento si me equivoco y estoy interpretando mal tus
palabras.

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

Repito, que pasa si las direcciones no estan en el binario?. Tendrias que
sacar de alguna manera la direccion de KERNEL32 en memoria y recorrer su
Export Table (ET) para encontrar las direcciones correctas (lo que hago
yo).

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

Idem de idem :) (repito que espero no estar entendiendolo mal).

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

Perdona pero no estoy de acuerdo, yo creo que si un codigo ha de
optimizarse para reducir su tamaño ese es una shellcode. Muchas veces a la
hora de explotar un programa vulnerable se anda muy escaso de memoria, asi
que cuanto menos espacio ocupe la shellcode mejor.

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

Ya, pero con mi metodo te puedes hasta hacer (siempre que se pueda grabar
en disco y ejecutar) un programa para dar shell por icmp's. Lo bueno es
que puedes programar lo que quieras porque luego se va a ejecutar. Tienes
posibilidades ilimitadas para hacer lo que quieras, mientras que bindeando
una shell solo podras eso, dar una shell.

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

Joer.. ejemplos de esos te puedo poner yo tambien unos cuantos para que
fallara tu shellcode jeje. Tampoco hay que ser drasticos, en la
mayoria de los casos (programas que corran con privilegios de administrador)
funcionara ;).

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

Sip, pero yo creo que mi tecnica es mejor jeje.

> 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

Mm.. no comparto esa opinion. Explotar un overflow en windows 9x es
perfectamente posible. Yo te invito a que leas NetSearch Ezine #7
(http://www.netsearch-ezine.com), y a lo mejor te llevas una sorpresa en
este tema ;).

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

Lo anterior por la experiencia que tengo en windows9x, y por que vi
exploits remotos para ese sistema operativo, no se cumple.

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

Perdona pero te equivocas otra vez. Es mas, las posibilidades de encontrar
overflows en programas (servidores, etc.) diseñados exclusivamente para
windows9x, es mas alta que los que estan diseñados para Windows NT. O al
menos eso pienso.

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

No usa una reverse-connection. El programa se lo baja de una URL, que
puede ser cualquier servidor de internet. De todas formas para exploits
locales tengo otra shellcode, que ejecuta system("cmd.exe"). Ocupa unos
450 bytes (sin optimizar) y usa la misma tecnica, recorrer la IT del
binario y luego la ET de KERNEL32. Funciona en Windows 9x y Windows NT,
pero claro, en el primero tiene poco sentido.

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

Ahap. Sip, se que no es nada nuevo. Es mas, me base en documentos de
programacion de virus para hacer la shellcode. Lo que no habia visto en
ningun sitio es aplicar esa tecnica a una shellcode. La tecnica SEH no la
conozco :/.

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

La direccion base es la misma para todos los programas con una posibilidad
de error del 98% / 99%. Las posibilidades de elegir dos direccion de 32
bits y acertar con las de GPA y LLA te aseguro que son bastante mas
elevadas :).

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

Dicho de otro modo, mi shellcode ocupa la mitad de la tuya y sin tocar
nada las probabilidades de que funcione son del 99% :). Aunque entrar en
un debate de cual tiene mas probabilidades de funcionar me parece
un poco infantil. Las dos examinando el binario funcionaran, pero
sinceramente creo que la mia tiene mas ventajas (es una opinion).

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

Sinceramente creo que no es comparable. Como ya he dicho el 99% de las
veces la direccion base siempre es la misma para todos los programas, y si
en vez de 00400000h es 00300000h pues se cambia un byte y punto. Pero
comparar eso a tener que meter dos valores de 32 bits aleatorios para cada
binario.. Con mi metodo sin conocer el binario hay muchas posibilidades de
que funcione, mientras q con el tuyo las posibilidades son nulas. No niego
que las posibilidades de que el metodo no sea 100% seguro, pero se
aproxima. Reitero que conociendo el binario cualquier shellcode
funcionara.

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

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

iD8DBQE7sOU6SP4h0VxUtqMRAl4WAJ9LPgZw/u1aE+TbkN74swNJr/J7gACfT1pq
I4IBT+htSnKTkAh5WWBHK/Q=
=SdK1
-----END PGP SIGNATURE-----