miércoles, 20 de junio de 2018

Tu servidor OpenVPN en Raspberry PI


Afortunadamente o no, me toca hacer muchos viajes al año. Lograr conectarse a internet suele ser un gran desafío, en especial cuando somos paranoicos sobre la red a la cual nos vamos a conectar. En mi caso se torna "de vida o muerte" avisar de inmediato a mi familia que llegué sana y salva al país a donde viajaba... y el tema de conectarse a las redes WiFi del aeropuerto... uhmm..

La cuestión es que como no hay demasiadas alternativas a las redes WiFi que vamos encontrando por ahí, se torna indispensable contar con un servicio VPN. Tampoco nos vamos a confiar de esos servicios que se ofrecen gratuitamente, así que para solventar este problema vamos a levantar nuestro propio servidor VPN utilizando una Raspberry PI.

Partiré de la base de que ya tienen una RPI, con Raspbian instalado y actualizado. Por si alguno no lo ha hecho, aquí dejo la guía oficial de la página de Raspbian para que puedan realizar su instalación.

CONFIGURACIÓN DE IP ESTÁTICA EN LAN
Dentro de nuestra red LAN, cada dispositivo tiene asignada una IP de tipo privada. Lo primero que haremos será configurar una IP privada estática para la Raspberry PI, de manera que la misma pueda ser identificada siempre por la misma dirección. Para ello editaremos la configuración del archivo /etc/network/interfaces.

pi@vpn:~ $ sudo nano /etc/network/interfaces


En la configuración que vemos en la imagen, estamos utilizando la interfaz wlan0 para conectarnos a internet. La IP estática será la 192.168.0.30 y luego tenemos los parámetros acordes a la configuración de red, en mi caso esos son los parámetros correctos, podrían variar en tu red.

Al final vemos una línea "pre-up /home/pi/openvpn-fw-rules.sh" de la cual hablaremos más adelante.

Guardando esa configuración, nuestra RPI siempre tendrá la misma IP privada, aunque podemos opcionalmente "avisarlo" en el router también, especificando la dirección MAC de la RPI.


CONFIGURACIÓN DE NO-IP (opcional)
Ya hemos configurado una IP privada estática para nuestra RPI, un paso necesario para algo que veremos posteriormente. Sin embargo, nuestra IP pública podría ser dinámica y eso significa un problema.

Si nuestro I.S.P nos ha otorgado una IP pública estática, este paso no es necesario. Si en cambio, nuestra IP pública cambia cada cierto tiempo, o cuando el router se reinicia, tendremos que solventar el problema utilizando un DNS.

Una opción para esto es el servicio de no-ip.com, que nos ofrece lo que necesitamos de forma gratuita por 30 días, si lo queremos extender en el tiempo tendremos que pagar, pero el precio es aceptable.


Una vez que nos registramos en no-ip.com, nos dirigimos a Dynamic DNS -> Create Hostname y nos inventamos un nombre de dominio que nos guste y esté disponible.

Tras ello, vamos a instalar en nuestra RPI el software de NO-IP que se encargará de actualizar en el servicio la nueva IP pública que tengamos.

Ejecutamos en la RPI los siguientes comandos:
cd /usr/local/src
wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz
tar xzf noip-duc-linux.tar.gz
cd no-ip-2.1.9
sudo make
sudo make install


Finalmente, añadiremos al final del archivo /etc/rc.local la siguiente línea:

/usr/local/bin/noip2 & 

Eso es para que cuando iniciemos la RPI, se inicie el programa de NO-IP.


CONFIGURACIÓN DE OPENVPN CON PIVPN
Continuaremos configurando OpenVPN en nuestra RPI. Para ello haremos uso de PIVPN, un proyecto que facilita en gran manera este proceso.

Abrimos una terminal en nuestro Raspbian y ejecutamos:
curl -L https://install.pivpn.io | sudo bash


Inmediatamente nos aparecerá una pantalla de configuración sobre la que iremos avanzando paso a paso indicando los pertinentes parámetros para nuestro servidor VPN.


Lo primero que nos dice es que necesita una IP privada estática, en la próxima pantalla nos mostrará la configuración de red actual, la cual es la que hemos hecho en el primer paso de esta guía. Le diremos que utilice esa misma y continuamos.

En el siguiente paso nos listará los usuarios diponibles en nuestra RPI preguntándonos sobre cual queremos que se configure OpenVPN.


Continuará preguntándo si deseamos que las actualizaciones de seguridad se hagan automáticamente, le indicaremos que si. Luego tendremos que especificar el protocolo y el puerto en que funcionará nuestro servidor VPN.




En mi elección funcionará sobre TCP en el puerto 3128. Los motivos de esa configuración es porque suele ser útil para evadir algunos portales cautivos :o. Sin embargo, ustedes pueden elegir el protocolo y el puerto que deseen.

Continuamos indicando la fortaleza del cifrado, pueden elegir entre 2048 y 4096.


Luego nos preguntará si queremos usar las mejoras de la versión de OpenVPN 2.4, le indicaremos que si.

El siguiente es un paso fundamental, nos preguntará si utilizaremos la IP pública que tenemos o un DNS. Como ya he mencionado antes, si la IP pública que tenemos es estática, dejaremos esa configuración. Si por el contrario hemos utilizado un DNS e instalado NO-IP, seleccionaremos la opción DNS Entry y escribiremos allí el hostname que hayamos creado en no-ip.com


We finished!


Nuestro servidor OpenVPN ya está configurado!.

CONFIGURAR ROUTER Y REGLAS DEL FIREWALL
Nos falta un detalle más que es fundamental para que todo funcione: abrir los puertos y redireccionar el tráfico que recibe nuestro router al puerto 3128 hacia nuestra RPI.

Recuerdan la línea "pre-up /home/pi/openvpn-fw-rules.sh" en la configuración de /etc/network/interfaces? El archivo openvpn-fw-rules.sh tiene las reglas de iptables necesarias para poder recibir correctamente las conexiones en nuestro servidor VPN. Su contenido es el siguiente:


#!/bin/sh
iptables -A INPUT -i wlan0 -m state --state NEW -p tcp --dport 3128 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o wlan0 -j MASQUERADE



Tengan en cuenta modificar las interfaces si están utilizando eth0 en lugar de wlan0.

Por otro lado, entraremos a la configuración de nuestro router y en la pestaña de port forwarding haremos la redirección del tráfico del puerto 3128.


Ya tenemos todo listo! :).

CONECTARSE AL SERVIDOR OPENVPN
Ahora que ya tenemos el servidor configurado y andando, veamos cómo conectarnos.
Primero debemos crear en la RPI un perfil para el cliente, en realidad, debemos crear tantos perfiles como dispositivos vayamos a conectar a nuestro servidor VPN. Para ello utilizaremos el comando "pivpn add"





Tal como se observa al finalizar el proceso, el archivo de configuración (.ovpn) para el perfil que hemos creado se ha copiado a /home/pi/ovpns/.



Ese archivo debemos copiarlo al dispositivo que se conectará al servidor VPN.
Por supuesto, el dispositivo debe tener instalado el cliente de OpenVPN, en el sitio web los tenemos disponibles para descargar: https://openvpn.net/.

En mi caso he copiado el perfil android-home.ovpn a mi teléfono Android. En la aplicación de OpenVPN importamos el archivo .ovpn y nos conectamos simplemente haciendo click sobre el nombre del mismo.


Eso es todo! espero que les sea de utilidad :)
Hasta la próxima!

Author: Sheila A. Berta
Twitter: @UnaPibaGeek.
Web: www.semecayounexploit.com.

domingo, 6 de mayo de 2018

NVIDIA drivers + CUDA 9 en Ubuntu 17.10


Sea que te encuentres trabajando en proyectos de deep learning, te hayas armado un rig para minería o te guste tener tu cluster para crackear hashes de contraseñas, necesitarás el poder de procesamiento de 1 ó varias GPU's.

Si optaste por utilizar una GPU NVIDIA la instalación de los drivers/CUDA en Linux tiene fama de no ser amigable. De hecho, en distros antiguas, no lo es.  Como punto a favor, en la última release de Ubuntu a la fecha (17.10) hay una manera muy sencilla de lograr tener todo correctamente instalado en pocos minutos.

Antes de comenzar, asegurate que tu GPU está correctamente conectada a nivel de hardware. Si no está correctamente alimentada, no importa cuanto intentes que los drivers se instalen, solo lograrás que tu Ubuntu se rompa una y otra vez.... (si, hablo con conocimiento de causa :-).

INSTALACIÓN DE DRIVERS NVIDIA
La gente que me conoce sabe muy bien que odio usar la shell gráfica en linux, siempre hago todo por línea de comandos, pero esta vez, para evitar inconvenientes al desactivar por consola algunos módulos de los drivers por defecto para los gráficos, haré una excepción.

Nos dirigimos al menú "Activities" o "Actividades" (si instalaron el Ubuntu en español), y en el campo de búsqueda escribimos "Software & Updates". De los tres programas que aparecen, elegimos el primero, aquel que tiene como ícono una caja y el mundo.

Nos encontraremos con la siguiente ventana:



Las primeras 4 casillas de la pestaña "Ubuntu Software" deben estar marcadas, tal como se ve en la imagen superior.

Luego nos dirigimos a la pestaña "Additional Drivers" en la cual podremos notar que, si bien nuestra GPU NVIDIA es detectada (en este caso es una GTX 1080), se está utilizando otro driver por defecto: Nouveau.



Vamos a cambiar eso seleccionando la primera opción: "Using NVIDIA binary driver - version 384.111 from nvidia-384 (proprietary, tested)" y presionamos el botón "Apply" para aplicar los cambios. Tomará unos minutos...


Una vez que termine, veremos el ícono verde al costado de la versión de nuestra GPU, y en la parte inferior un mensaje que indica que estamos utilizando un driver propietario.


 Momento de Reiniciar el equipo.


DESCARGA E INSTALACIÓN DE CUDA 9
Descargamos el paquete de instalación dirigiéndonos a la siguiente página: https://developer.nvidia.com/cuda-90-download-archive.

Allí seleccionaremos las opciones: Linux -> x86_64 -> Ubuntu -> 17.04 (si, ya sé que instalamos la 17.10 pero utilizaremos este paquete) -> deb [local].


Descargamos el "Base installer" de 1.2GB. 



Una vez que terminó la descarga, ahora sí abrimos una terminal de comandos, nos movemos a la carpeta donde descargamos el archivo y ejecutamos los siguientes comandos:

sudo dpkg -i cuda-repo-ubuntu1704-9-0-local_9.0.176-1_amd64.deb
sudo apt-key add /var/cuda-repo-9-0-local/7fa2af80.pub
sudo apt-get update
sudo apt-get install cuda  

Tomará unos minutos, una vez que termine reiniciamos nuevamente el equipo.
Finalmente podemos ejecutar - por ejemplo - el comando de hashcat -I para ver si hemos instalado todo correctamente:


 

Sé que este fue un paso a paso extremadamente sencillo, pero la realidad es que no hay mucha documentación online de como hacer funcionar los drivers NVIDIA/CUDA en Linux, mucho menos en la última versión, es por eso que lo escribí. Espero que les sea de utilidad! Hasta la próxima...

Author: Sheila A. Berta
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.

lunes, 16 de abril de 2018

Plugins MITMf - Explotando los ataques de capa 2

Hace algunas semanas estuvimos viendo diversas técnicas que nos facilita Bettercap para ataques en capa 2 y también uno de los plugins de MITMf para realizar un screenshot remoto del navegador de otro usuario en la red LAN.

Si bien, desde el comienzo de este tipo de ataques, es sabido que estas cosas se pueden realizar, tanto bettercap como MITMf hacen que sea mucho fácil que antes y nos permiten sacar el máximo provecho a los ataques de Sniffing & MITM que conocemos desde hace tantos años.

Bettercap ahora hizo un importante upgrade y lo encontraremos como bettercap-ng, cuenta con la posibilidad de ejecutarse en un modo de consola interactiva y tiene un repositorio con muchos "caplets" los cuales son un conjunto de comandos para bettercap que nos ayudan a ejecutar rápidamente un gran abanico de ataques muy útiles.

Por su parte, MITMf tiene una gran cantidad de plugins, tal como ya hemos mencionado en el post donde hicimos foco en aquel que permite tomar screenshots remotos del navegador del usuario. Hoy vamos a ver algunos más, aquellos que en la práctica me han resultado los más útiles.

ENUMERAR Y EXPLOTAR PLUGINS DEL NAVEGADOR
Para esta práctica tenemos dos plugins "browserprofiler" y "browsersniper".
En principio, browserprofiler realiza una enumeración poco intrusiva, sin intentar nada más. Para utilizar este plugin, debemos ejecutar MITMf invocándolo de la siguiente forma:

mitmf.py --spoof --arp --browserprofiler --gateway <gateway_ip> --targets <target_ip> -i wlp1s0

El JavaScript que enumera los plugins se inyectará en cualquier requerimiento HTTP y nos devolverá la información.



Si quisiéramos algo más "agresivo" podemos combinar esos resultados con Metasploit e intentar aprovechar directamente con un exploit si hay un plugin con vulnerabilidades conocidas. Para ello, en lugar de browserprofiler utilizaremos browsersniper, pero antes debemos comunicar MITMf con Metasploit:



La contraseña indicada por metasploit debemos especificarla en el archivo mitmf.conf ubicado en la carpeta config del source de MITMf.



Una vez guardado ese archivo ya podemos correr mitmf cargando el plugin de browsersniper.

mitmf.py --spoof --arp --browsersniper --gateway <gateway_ip> --targets <target_ip> -i wlp1s0



En este ejemplo, el navegador atacado no posee plugins con vulnerabilidades, pero si fuera el caso contrario nos lo indicará. 

REEMPLAZAR IMAGENES
Un plugin muy divertido es imgrand, este se ocupa de reemplazar todas las imágenes que intercepte, por alguna aleatoria tomada de una carpeta que le indiquemos. Para utilizarlo debemos invocarlo de la siguiente forma:

mitmf.py --spoof --arp --hsts --imgrand --img-dir /home/shei/Pictures/ --targets <target_ip> --gateway <gateway_ip> -i wlp1s0

Por supuesto que en el navegador del usuario los efectos serán bien visibles... (y divertidos!)




PORTAL CAUTIVO
Otro plugin que me resultó muy útil es captive, el fin es convertirnos en un portal cautivo y forzar al usuario a ver o ejecutar determinada acción para poder seguir navegando con normalidad.



El comando para cargar el plugin de captive es el siguiente:

mitmf.py --spoof --arp --hsts --captive --portaldir ./config/captive/ --targets <target_ip> --gateway <gateway_ip> -i wlp1s0

Dentro de la carpeta config/captive del source de MITMf encontramos el archivo portal.html que podemos editar para "customizar" lo que el usuario verá en dicho portal. Es necesario renombrarlo a "index.html" una vez que terminemos de editarlo. Si lo dejamos como viene por defecto, se intenta engañar al usuario para que descargue un archivo llamado CaptiveClient.exe.

Nosotros debemos ocuparnos de generar ese .exe y ubicarlo en la carpeta junto al archivo html del portal. Para ello podemos, por ejemplo, utilizar msfvenom y generar un payload de metasploit en formato ejecutable.

Por supuesto podemos optar por no intentar que el usuario descargue un ejecutable, sino que sea redireccionado a una pagina fake de algún servicio que tengamos como objetivo capturar las credenciales del usuario, o cualquier otra cosa, el límite de lo que puede ser ese portal cautivo pasa por nuestra imaginación.

Finalmente, otro plugin muy interesante que tiene MITMf es Responder, pero al mismo le dedicaremos una nota aparte :).

Hasta la próxima!

Author: Sheila A. Berta.
Twitter: @UnaPibaGeek.
Web: www.semecayounexploit.com.

jueves, 29 de marzo de 2018

WomenInTechFund - Por más mujeres en los eventos de Infosec

Esta semana nos despertamos con una iniciativa nueva: WomenInTechFund, busca ayudar a la inclusión de mujeres en eventos de tech e infosec, facilitando entradas para los mismos. Por supuesto que para ello se solicita la colaboración de quienes organizan estos eventos, brindando entradas que luego serán repartidas por la fundación.
 
Nos pone muy contentas este tipo de iniciativas, conocemos perfectamente los obstáculos que pueden pasar por nuestra mente al momento de decidir si asistir o no a un evento de tech o infosec, estamos seguras de que una invitación con ticket en mano puede ser un hermoso empujón para dar el primer paso. Así que agradecemos a los fundadores de esta iniciativa y también a las organizaciones, empresas e individuos que están colaborando con los tickets.

Sin embargo, quien escribe (UnaPibaGeek) quisiera hablar un poco más sobre este asunto, ya que sabemos que conseguir una entrada no es el único obstáculo al que se enfrenta una chica que quiere asistir a un evento de este tipo, o más aún, que quiere ser oradora allí. Por mi parte estuve en ambas posiciones, desde la chica que le dieron un ticket y fue sin poder encontrarse con ni una sola mujer más en aquel evento, hasta la que a pesar de eso quiso subirse al escenario y contar lo que le gusta hacer. Los obstáculos en el camino fueron muchos y siguen siendo muchos, pero si no los contamos, si no salen a la luz, nadie podrá hacer nada para combatirlos. Es por eso que me puse a escribir éstas líneas, para contar cuáles son esos obstáculos y cómo pueden ayudar a combatirlos tanto las propias mujeres como los hombres en esta área y los mismos organizadores de estos eventos.

Porque después de recibir el ticket, lo primero que una chica se pregunta es con qué se va a encontrar si finalmente decide ir. Sabe que lo último en abundancia serán otras mujeres, se alegra porque cuando vaya al baño no tendrá que esperar, pero también piensa si no tendrá que estar sola durante toda la jornada... a nadie le gusta pensar en que eso podría pasar, a nadie le gustaba quedarse sólo en el recreo ¿no? los 10 minutos hasta la vuelta a clase se vuelven eternos.   

Sé que esos pensamientos ocurren, por eso el año pasado cuando ofrecieron entradas a chicas para ir a la Ekoparty, escribí públicamente que aquellas que fueran a ir por primera vez me contactaran. Alrededor de 5 chicas me escribieron e intercambiamos números para encontrarnos antes del ingreso el primer día.

Como mencioné al principio, la entrada no es el único obstáculo, obtener una es sólo el primer paso. Hacer que las mujeres se sientan cómodas durante todo el evento es el segundo gran paso. Evitar que una chica se sienta sola al llegar, es sumamente importante, porque sino, así como llegó se irá.
Sin dudas, si le regalás una entrada a una chica, la invitás o simplemente sabés que va a ir por su cuenta, ponerla en contacto con otras mujeres que conozcas del área y que vayan a ir, es una gran manera de colaborar con esa segunda etapa 😊.

Y hasta acá, las cosas parecen bastante simples, porque para un evento puede no traer mayores complicaciones regalar algunas entradas (incluso muchos eventos son gratuitos) y porque para una persona puede ser muy fácil poner en contacto a otras dos… pero si seguimos avanzando en el camino de la chica que se empieza a asomar (y acá me estoy basando mucho en el camino que transité yo) empiezan a aparecer otras cosas mucho más complejas de cambiar. 

Porque lo tercero que una chica va a notar, es que las charlas que va a ver, son dadas casi todas por hombres, y digo casi, sólo por las pequeñas excepciones. En mi caso, el primer evento al que asistí hace algunos años, fueron 3 días de charlas dadas únicamente por hombres, al igual que los workshops, al igual que los trainnings… entonces me pregunté por qué ninguna mujer se animaba a estar en el escenario, fue así que empecé a prestar atención a los CFP y armar propuestas de lo que fuera que estuviera investigando. Pero me encontré con otra realidad…

Porque cuando envías una propuesta de charla, ¿Quién la recibe del otro lado? Un panel, el “review board” donde, al menos en los eventos de Latinoamérica, no vas a encontrar una mujer ni por casualidad!. Así que todo va a depender mucho del nivel de sexismo que haya en ese panel, habrá paneles en los que considerarán tu propuesta de igual a igual con el resto, y otros en los que digan “ah no pero la dá una chica” y otros en los que un integrante del review board te mande directamente un mail para denigrarte la propuesta y así… me han tocado todos esos casos y también me tocó otro muy particular, donde ocurría lo contrario: se me pedía dar una charla por el simple hecho de ser mujer, sin importar el material que iba a presentar. Esto último me ocurrió en dos oportunidades, en ambas rechacé la participación ¿motivo? Algo súper importante para todas las mujeres que quieran ser expositoras: si te van a aceptar tu conferencia que sea por la calidad técnica de tu investigación y no por tu figura, sino estamos en la misma de siempre.   

Bueno, ¿Qué se puede hacer sobre este tercer punto de la cuestión? En principio, los organizadores de eventos deberían mirar un poco puertas adentro y ver quiénes son los miembros de su review board, asegurarse que tienen el profesionalismo suficiente para considerar todas las propuestas de igual a igual independientemente del género de quien la envió. También, considerar la posibilidad de incluir al menos una mujer en el panel, que sea mixto, será de gran ayuda.

Y para las chicas que se animen a dar ese enorme paso: nunca dejes que alguien que te diga “para qué mandaste esa propuesta” o algún otro comentario similar, te frene. Lo que estás investigando está bueno, compartirlo hace crecer la comunidad, que otras chicas te vean en el escenario va a sumar a otras más, los frutos son muchos aunque a veces haya consecuencias. Si te rechazan en un evento por ser mujer, contalo a las colegas para que podamos hacer algo al respecto, pero por tu parte buscá otros más y seguí proponiendo.  

Hay mucho para mejorar, pero para empezar a cambiar las cosas es necesario que se conozca lo que está mal. Es por eso que, aunque muchas veces cuesta, hablar sobre lo que te ha ocurrido es necesario para hacer esas mejoras. Por ejemplo, si al llegar a un evento sufriste algún hostigamiento por ser mujer, contactate de inmediato con los organizadores o con alguna colega, si no te animás a hacerlo público escribile por privado a otras mujeres u organizaciones que están atentos a estas cosas. Haz lo mismo si no te quieren dejar ir a un evento, si te discriminan una propuesta que enviaste, etc. Todas esas cosas deben salir a la luz para que puedan ser removidas. Así como existe WomenInTechFund hay muchas organizaciones y mujeres combatiendo esas cosas para que haya una mejor inclusión en eventos de tecnología e infosec, en eso me incluyo.

Pero como ya dije antes, todos debemos colaborar a eso, no solo las mujeres mismas y las organizaciones que las ayudan. Los eventos también, que esas buenas intenciones que se ven desde afuera al regalar entradas a las mujeres, se transmita puertas adentro y se refleje durante todo el evento. Brindar una entrada es sólo el comienzo, se necesita que el ambiente no sea hostil para las mujeres, que si algo malo ocurre se tomen las medidas necesarias, que las chicas que se animan a ir sientan que tienen el apoyo de los que están en el lugar y principalmente de los que organizan ese evento, que la estadía sea grata para tod@s por igual! :) ¿Cómo lograr todo eso? Escuchar las situaciones por las que pasan las mujeres en esta área es una buena manera de comenzar, es el punto de partida para cambiar las cosas. Espero que estas líneas donde relaté algunos de los obstáculos que tuve yo, sirvan para tomar noción de ello y abran un abanico de ideas para combatirlos.

Gracias por leer,

Sheila A. Berta (UnaPibaGeek).

jueves, 1 de febrero de 2018

Almacenamiento Inseguro de Claves en Software SCADA (Rockwell y GE)

Todos sabemos que en los ambientes SCADA se suele utilizar sofware antiguo, obsoleto, y muchas veces sin parches, ya que si las cosas funcionan bien en un ambiente industrial no se suelen tocar mas (no muchos se animan a actualizar sistemas de control, con el riesgo que conlleva para el ambiente productivo).

Haciendo un análisis en un cliente, me encontré con un software de Rockwell Automation denominado Desklock. Es un software que se utiliza, básicamente, para restringir a los operadores de los sistemas industriales de forma que solo puedan acceder a la aplicación SCADA y bloquear todo el resto (aplicaciones de windows, barra de tareas, escritorio, apagado de la maquina). También tiene la funcionalidad de autologon, para iniciar sesión automáticamente con el usuario local o de dominio que indiquemos en la configuración.

Autologon...me trae recuerdos =D imagino que las credenciales las debe estar guardando en algún lado para para poder iniciar sesión en el equipo, ya sea en un archivo o en la registry, dado que el host es un Windows 7. En conclusión, que es lo primero que voy a mirar? El archivo de configuracion DESKLOCK2000.CFG


Abriendo el archivo de configuración nos encontramos con lo siguiente:


Con el objeto de realizar pruebas, le había puesto como contraseña para poder abrir el Desklock y modificar su configuración "abcdefg". Analizando la contraseña "encriptada" claramente se esta utilizando un cifrado cesar o cifrado monoalfabetico por desplazamiento, en este caso "la clave" o el numero de espacios a desplazar es -4 que convierte por ejemplo una letra "e" en una letra "a" y una letra "a" en el símbolo "]" según la tabla de caracteres ascii imprimibles. En base a esto la clave original "abcdefg" se convierte en "]^_`abc"


Y la contraseña del usuario utilizado para el autologon? También esta guardada en el archivo de configuración, cifrada de la misma manera que la clave de desklock:


Esta clave no la puedo mostrar porque ya estaba configurada y no la había elegido yo, pero fíjense que sigue el mismo esquema que la clave anterior, la ultima coma de la clave cifrada corresponde a un 0 en la clave original.

Igualmente decidí revisar la registry a ver si la clave también se guardaba ahí, y resulta que en la key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon el autoadminlogon estaba activado y se encontraba en texto plano el nombre de usuario en DefaultUserName y su correspondiente contraseña también en texto plano en DefaultPassword. 

Entiendo que Rockwell soluciono el almacenamiento inseguro de la clave, ya que hubo un advisory con respecto a este tema en el software Rsview32 (del cual DeskLock es parte, es una de las herramientas incluidas en las tools):

En un test de intrusión interno en otro cliente nos había pasado algo parecido con el sofware de GE Proficy Ifix.

El tema es este, Ifix guarda las credenciales en un archivo de configuración denominado xtcompat.utl, aparentemente cifrado, pero la realidad es que Ifix solo realiza una operación matemática de XOR entre el valor de los campos descripción, usuario y password y tres claves estáticas predefinidas:



A continuación se puede ver en hexadecimal el archivo xtcompat.utl, los campos que nos interesan son los marcados en colores, el resto es relleno (ahora se los cuento así ligeramente, pero la verdad es que estuve un buen rato mirando los archivos hexa hasta descubrir bien donde estaba cada campo y cual era el relleno). 


Si llegan a encontrar un Ifix por ahi, ya no van a tener que hacer el análisis manualmente como hice yo en un principio, pueden utilizar la herramienta que desarrollo mi amigo lbrug que directamente lee el archivo xtcompat.utl, realiza la operacion de XOR con las claves estaticas correspondientes y muestra el usuario, password y descripción:

Entiendo que también hubo un advisory al respecto y GE soluciono este tema, pero como les dije al principio no es raro encontrar software desactualizado en entornos SCADA en el cual estas vulnerabilidades sigan presentes:

Saludos y espero que les haya gustado!

martes, 16 de enero de 2018

Screenshot remoto sobre la página que visita un usuario, a través de un MITM


La semana pasada estuvimos hablando de Bettercap y cómo usar sus características avanzadas tales como la customización de parsers y la inyección de código en peticiones HTTP interceptadas. Ahora comenzaremos a ver MITMf, otra herramienta para realizar ataques de Sniffing/MITM.

Si bien mi herramienta preferida para esto es Bettercap por diversos motivos, MITMf tiene algunos plugins extremadamente interesantes, iremos viendo algunos de ellos. Hoy trataremos “ScreenShotter”.

Como es la primera nota sobre MITMf, a continuación explicaremos cómo descargarla y ejecutarla correctamente. 

DESCARGA Y EJECUCIÓN
Hacemos un git clone del siguiente repositorio: https://github.com/byt3bl33d3r/MITMf.
Instalamos las dependencias con el siguiente comando:
sudo apt-get install python-dev python-setuptools libpcap0.8-dev libnetfilter-queue-dev libssl-dev libjpeg-dev libxml2-dev libxslt1-dev libcapstone3 libcapstone-dev libffi-dev file
Finalmente instalamos las dependencias propias de python, si tenemos pip, nos movemos a la carpeta descargada de MITMf y ejecutamos: sudo pip install -r requirements.txt
Si todo salió bien ya podemos hacer sudo python mitmf.py --help


Como podemos observar, si ejecutamos el comando, la ayuda es bastante larga. MITMf posee muchos plugins. Si buscamos entre ellos, encontraremos ScreenShotter.


Pero antes de poner manos a la obra con este plugin, debemos conocer los parámetros básicos requeridos por MITMf.

Para empezar, MITMf nos pide que sí o sí especifiquemos la IP del gateway, la/s IP de los targets y la interfaz que estamos utilizando. Estos parámetros son: --gateway <ip_gateway>, --targets <ip_targets> y -i <interfaz>.

Luego, como mínimo necesitamos ejecutar un ataque de MITM, para ello le sumaremos a los anteriores, los siguientes dos parámetros: --spoof y --arp.

Dicho esto, un ataque de MITM básico hecho con MITMf nos quedaría así:

sudo python mitmf.py --spoof --arp --gateway 192.168.43.1 --targets 192.168.43.209 -i wlp1s0


Con ello, podremos ver las peticiones HTTP realizadas por el usuario, el contenido POST de las mismas, así como también la información de otros protocolos.
Tal como he mencionado, ahora haremos foco sobre el plugin ScreenShotter, para utilizarlo, simplemente debemos añadir al comando anterior el siguiente parámetro: --screen.


Como vemos, cuando el usuario ingresa a un sitio web vía HTTP, el payload del plugin es inyectado en la respuesta dirigida al usuario. De esta manera se carga en su navegador, permitiéndole al atacante ver la página que está visitando (esto incluye ver lo que está tipeando en los formularios si aplicara el caso).

Por defecto ScreenShotter toma capturas cada 10 segundos.


Podemos alterar este tiempo utilizando el parámetro --interval <segundos> si así lo quisiéramos.
Todas las capturas de pantalla son almacenadas en la carpeta “Logs” dentro de la carpeta de MITMf. Así que nos dirigimos allí y abrimos las capturas con cualquier visor de imágenes.



¿Interesante verdad? Espero que les sea de utilidad!
Hasta el próximo plugin! 😉.

Author: Sheila A. Berta.
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.

sábado, 13 de enero de 2018

Bettercap parte II: Inyección de código en requerimientos HTTP y DNS Spoofing


Hace unos días publiqué la parte I de esta nota, donde expliqué la descarga e instalación de bettercap y cómo utilizar parsers custom para visualizar fácilmente lo que nos interesa en un ataque de MITM. Si se la perdieron pueden comenzar leyendo por allí.

En esta segunda y última parte veremos los módulos para inyectar código en el cuerpo de los requerimientos HTTP interceptados. Además, aprenderemos a hacer un DNS spoofing con esta herramienta.

INYECCIÓN DE CÓDIGO EN PETICIONES HTTP INTERCEPTADAS
Si consultamos la ayuda de bettercap, ejecutando bettercap --help, podemos ver una característica muy interesante bajo el parámetro --proxy-module.



Los módulos disponibles son: redirect, injectjs, injectcss e injecthtml.
Cuando utilizamos alguno de estos módulos, las respuestas de requerimientos HTTP realizados por el usuario se ven alteradas, al estar el atacante en medio (MITM) inyectando código en ellas. El código inyectado dependerá del módulo que utilicemos, por ejemplo, si utilizamos redirect, simplemente se inyectará una redirección hacia otro sitio. Si utilizamos injectcss u injecthtml podremos alterar el contenido visual del sitio, y si utilizamos injectjs (inyección de JavaScript) el abanico de ataques se amplifica bastante.

Haremos foco en este último: injectjs.

Como se mencionó, nos permite inyectar código JavaScript. El mismo lo pondremos en un archivo .js y le pasaremos la ruta como valor al parámetro --js-file, que va acompañado de --proxy-module injectjs.

El comando completo quedará de la siguiente forma:

sudo bettercap --proxy --proxy-module injectjs --js-file /home/shei/inyectar.js -T <ip_del_target>

Hagamos una simple prueba, creando el archivo inyectar.js con el siguiente contenido:
<script>alert(“Texto inyectado a través de un MITM”);</script>
Lo guardamos y ejecutamos bettercap:



Cuando el usuario ingrese a un sitio HTTP, se inyectará el código JavaScript



Y será lo primero que verá



¿Qué usos prácticos podemos darle a este módulo? A través de JavaScript podemos hacer redirecciones, robo de cookies, denegación de servicio y un largo etcétera. Incluso podemos usar el conocido framework BeEF e inyectar el hook.js a través de este MITM.

En mi caso, utilice esté módulo cuando programé el pequeño JavaScript que ayuda a sobreescribir la base de datos HSTS de Firefox.




Si gustan más información sobre este ataque pueden ver los slides de la presentación en Black Hat:
https://www.blackhat.com/docs/eu-17/materials/eu-17-Berta-Breaking-Out-HSTS-And-HPKP-On-Firefox-IE-Edge-And-Possibly-Chrome.pdf.

DNS SPOOFING
En sencillas palabras, la idea tras esta técnica es, que cuando el usuario consulte por la IP de un dominio, el atacante le responda con otra IP (diferente a la real) perteneciente a un equipo bajo su control. De esta manera, si el usuario ingresa -por ejemplo- a www.instagram.com y se realiza la resolución DNS para obtener la IP del sitio, el atacante será quien le dé la repuesta, logrando que el usuario finalmente ingrese a un servidor bajo su control.

Habitualmente está técnica se utiliza para hostear una página exactamente igual a la que el usuario intenta ingresar originalmente, con el pequeño detalle de que las credenciales o la información que el usuario provea allí, será capturado por el atacante.

El principal inconveniente de esta técnica es el caché, ya que, si el usuario tiene en su cache DNS la IP del sitio al cual está tratando de ingresar, la consulta no saldrá del entorno local y el atacante no será capaz de interceptarla a través del MITM y alterar la respuesta.
Veámoslo en la práctica.

En primer lugar, crearemos un archivo llamado fakedns con el siguiente contenido:

Ip_lan_atacante    instagram.com

Por ejemplo:

192.168.43.109        instagram.com

En este caso, hay un servidor web Apache en la máquina del atacante, el cual está accesible a través de la dirección IP del equipo.
Guardamos el archivo como “fakedns” y lo utilizaremos en bettercap de la siguiente manera:

sudo bettercap -T <ip_del_target> --dns /home/shei/fakedns


Cuando el usuario ingrese a instagram.com a través de su navegador, si el sitio no está cacheado, el usuario terminará accediendo al servidor web en la máquina del atacante, donde puede haber lo que sea.



En la máquina del usuario:



Si en lugar del index de Apache, se encontrara una copia de instagram.com (algo que podemos hacer muy fácilmente con SET o cualquier otra herramienta) y en tal copia se encontrara alterado el formulario de autenticación, de manera que los datos queden almacenados para el atacante, el usuario finalmente perdería la confidencialidad de los datos de su cuenta.

Hasta aquí con Bettercap, espero que puedan sacarle provecho a la herramienta! 😊
Nos leemos en la próxima!.

Author: Sheila A. Berta
Tw: @UnaPibaGeek.
Web: www.semecayounexploit.com.