Auditando la red wifi de mi universidad

Dentro de este pequeño mundo de la seguridad informática he tenido la suerte de conocer a grandes personas, con las cuales he compartido más de un año de trabajo dentro del equipo de SVT y a los que estoy más que agradecido por el buen hacer que han tenido conmigo. Así que, queridos lectores, permitidme dedicar el post de hoy a esta familia, que se lo merecen en toda regla.

Hoy, como veremos, tenemos por delante un artículo un poco diferente de los que estamos acostumbrados, ya que el contenido relevante es un vídeo que grabé para la defensa de mi trabajo de final de grado. Éste, tiene por objetivo demostrar como era posible extraer las credenciales de los usuarios (alumnos y profesores) de la red eduroam de la Universidad de Lleida, mi antigua universidad.

En este caso, se trata de un hecho muy importante en referencia a los términos de seguridad, ya que la misma contraseña que se emplea para acceder a la red inalámbrica también se utiliza para acceder al correo, al campus virtual y a todo lo que deriva de éste, como puede ser el expediente o todo lo relacionado con las asignaturas, la entrega de prácticas y las notas e incluso, permite iniciar sesión en nombre de la víctima en cualquier máquina puesta a disposición del público. En breves palabras, la misma contraseña no simplemente permite acceder a los datos privados del usuario sino que también permite robar la identidad de la persona afectada, en todos los ámbitos.

Desde el punto de vista técnico, la red eduroam en cuestión, está configurada con cifrado CCMP (WPA2) y con una autenticación 802.1x, conocida coloquialmente como Enterprise, que en este caso emplea la propia autenticación a través del protocolo PAP dentro de un túnel TLS (TTLS/PAP).

Los puntos principales que se tratan en el vídeo son los siguientes:

  • Configuración del terminal Android para dicha red.
  • Motivo por el cual podemos realizar la suplantación de un punto de acceso legítimo.
  • Herramientas que podría utilizar un atacante y su correspondiente aplicación.
  • Análisis del entorno real.

Aquí tenéis el enlace del video:

Una vez publicado el vídeo, significa que el Departamento de Sistemas de la universidad me ha dado autorización para hacerlo. Esto es debido a que ya ha tomado las medidas oportunas para solventar la inconveniencia.

Sin más, espero que haya sido de vuestro agrado. Y recordad, averiguar la contraseña es simplemente un daño colateral. ¿Qué pasaría si nuestro punto de acceso falso diera por válida la autenticación del usuario, le ofreciera servicio DHCP y acceso a Internet? El usuario no lo notaría, ya que creería que está en la red legítima, pero nosotros tendríamos comunicación directa con su dispositivo, sin ningún tipo restricción, y además, sobre un escenario man in the middle (MitM). ¿Lo dejamos para otro vídeo? 😉

¡Saludos!

Ferran Verdés

Enlace del vídeo: https://youtu.be/XmKokmOYdV0

Copycat

Cuando estamos realizando un ataque tipo phishing a una determinada web, lo habitual es que clonemos la interfaz de la misma, haciendo creer a la víctima que está en la web real. Normalmente, esta web creada carece de funcionalidad, con lo que es posible que ésta se de cuenta de alguna manera, que algo “raro” está pasando.

Hoy voy a hablaros de una herramienta muy potente, que pretende resolver este problema. Su funcionamiento es sencillo: utilizamos un mapeo de los subdominios a suplantar, de manera que necesitamos que la víctima visite la web con la DNS suplantada. La herramienta realizará el cambio de DNS, y realizará la conexión con la web real, de manera que se mantiene la funcionalidad del sitio original.

Vamos a probar cómo funciona. Necesitamos node.js v6 o superior así que, en este caso, utilizaremos ArchLinux. Primero, instalamos npm, el gestor de paquetes de node.js:

sudo pacman -Syu npm

Read more

Ransomware en MongoDB

Introducción

En las últimas semanas se han producido varios ataques de ransomware contra servidores de bases de datos MongoDB, concretamente se calculan que más de 20.000 bases de datos se han visto afectadas en todo el mundo dando lugar a cerca de 680 TB de fuga de información.

El problema está en la gran cantidad de servidores publicados y en este caso que vamos a comentar, indexados por Shodan. Vale con una simple búsqueda utilizando ciertos filtros de Shodan para descubrir los servidores de MongoDB publicados en Internet.

Shodan en acción

Podemos usar el filtro “product” como vemos a continuación.

product:mongodb

Donde obtenemos 38.845 resultados tal y como se puede ver en la imagen.

Ransomware en MongoDB

Otra opción es usando el filtro “port” indicando el número de puerto correspondiente por defecto a las instancias de MongoDB, el 27017.

port:27017

Obteniendo aproximadamente unos 500 resultados más, 39.311, posiblemente como consecuencia de haber aplicado “seguridad por oscuridad“, ocultando nombre de producto, versiones, etc.

Read more

¡Lleno, por favor! Gasolineras.

Recientemente, auditando la red de un cliente se detectó un router Huawei de Vodafone, el cual estuve echando un ojo a conciencia porque es de sobra conocida la calidad de los routers con la que los ISP (todos) pretenden que te conectes a la ADSL o Fibra, vi que algo no funcionaba como debiera.

Logueandome con password por defecto (no la tenía cambiada) intenté lo típico, loguearme, y desloguearme metiendo el burpsuite por medio para ver si las peticiones previas que había hecho, las validaba o se las saltaba a la torera.

Efectivamente, se las saltaba a la torera. Se me ocurrió que sería posible escanear “internet” para localizar router similares y poder crear un script que recopilara la información. Obviamente no lo iba a hacer pero la idea parecía buena hasta que buscando info del equipo vi que ya se me adelantaron y hace bastante tiempo.

Ya existía un script que creó Vicen Domínguez ( https://github.com/vicendominguez/http-enum-vodafone-hua253s/blob/master/README.md ) a raíz del descubrimiento, del mismo autor, del fallo de seguridad de estos routers (gracias por las referencias en twitter chicos!!) que podemos leer en https://packetstormsecurity.com/files/134522/Huawei-HG253s-V2-Information-Disclosure.html), por lo que llegué bastante tarde a este caso.

Pero el post no va sobre este tema, el cual es muy interesante y extendido (yo tengo un router de pruebas de este tipo y es bastante divertido darle caña).

Read more

Convirtiendo un Proxy en Transparent Proxy

En algunas ocasiones queremos utilizar de manera transparente un servidor proxy, ya sea para saltar un firewall o, simplemente, para enrutar por él determinadas conexiones o las conexiones de determinados usuarios o grupos. Pero no siempre es posible, porque no todos contemplan la posibilidad de Transparent Proxy.

Si utilizamos Privoxy con la opción accept-intercepted-requests, nos sirve para redirigir el tráfico vía firewall. Sin embargo, no podremos redirigir el tráfico https. Además, una vez que activemos la opción accept-intercepted-requests, no podremos utilizarlo manualmente desde la aplicación deseada.

También se puede utilizar un proxy Socks5 creado con ssh. A él no podremos redirigir el tráfico directamente vía firewall.

Si queremos redirigir el tráfico con nuestro firewall a un proxy como los anteriores, podemos utilizar RedSocks. Esta herramienta nos permite crear un proxy transparente http, http-connect, socks4 o socks5 y actuará de túnel con el proxy real. De esta manera, podremos “convertir” un proxy que no es Trasnparent Proxy, en uno, y dirigir a él el tráfico que necesitemos.

Una ventaja adicional es que puede enrutar también el tráfico DNS. Si disponemos un proxy Socks5, que no sea creado con ssh, también podremos redirigir por él el tráfico UDP.

Vamos a ver un ejemplo de uso. Para ello, vamos a enviar todo el tráfico http y https a Privoxy.

Privoxy, en principio, enrutará todo el tráfico a través de TOR. La ventaja de pasar previamente por Privoxy es poder aprovechar los filtrados que proporciona, como publicidad, etc., además de poder decidir desde él qué hacer con cada URL. El resto del tráfico, lo enrutaremos por TOR. Todo esto se realizará siempre que la aplicación/herramienta se haya lanzado con un grupo de usuarios concreto.

Nos va a permitir utilizar estos proxys sólo cuando la aplicación se lance con un determinado grupo, de manera que no vamos a “Torificar” todas las salidas, solo aquellas que nos interesan.

La instalación la vamos a realizar sobre Kali. En el resto de distribuciones basadas en Debian será similar. En ArchLinux, podemos encontrar Redsocks en el AUR o, si hemos añadido a los repositorios BlackArch, lo tendremos ya disponible, dado que forma parte de esta distribución.

Empezamos instalando:

apt-get update && apt-get install redsocks privoxy tor

Una vez instalados los paquetes, vamos a configurarlos. Primero, editamos el fichero /etc/tor/torrc. Necesitaremos mapear los dominios onion, activar el servicio de DNS de TOR y el TProxy. Para ello, al final del archivo añadimos:

VirtualAddrNetwork 10.192.0.0/10
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion

DNSPort 53
TransPort 9040
SocksPort 9050

Con esto tenemos que, el servidor de DNS estará escuchado en localhost:53, los dominios onion los mapeará con una ip aleatoria del rango 10.192.0.0/10 y tendremos el TProxy en el 9040, además del proxy socks habitual en el 9050.

Ahora vamos a editar la configuración de Privoxy y añadir al final de la misma:

forward-socks5 / 127.0.0.1:9050 .
forward localhost/ .
forward 127.*.*.*/ .
forward 192.168.*.*/ .

Bien, ya tenemos Tor y Privoxy configurados, pasemos a RedSocks. Primero sacamos un backup del fichero /etc/redsocks.conf. En él tenemos todas las opciones disponibles, con sus respectivos comentarios. Hecho esto, lo editamos y le añadimos el siguiente contenido:

base {
 log_debug = off;
 log_info = on;
 log = "syslog:daemon";
 daemon = on;
 user = redsocks;
 group = redsocks;
 redirector = iptables;
}

redsocks {
 local_ip = 127.0.0.1;
 local_port = 8218;

ip = 127.0.0.1;
 port = 8118;


 // known types: socks4, socks5, http-connect, http-relay
 type = http-relay;
}

redsocks {
 local_ip = 127.0.0.1;
 local_port = 8318;

ip = 127.0.0.1;
 port = 8118;

type = http-connect;
}

Básicamente, hemos creado un TProxy en el puerto 8218 que apunta al 8118 (Privoxy), de tipo http-relay y otro en el 8312, de tipo http-connect (https), que también apunta a Privoxy.

Ya tenemos la configuración inicial, vamos a arrancar los servicios:

systemctl start tor privoxy redsocks

Ahora vamos a añadir un grupo. Será el que utilicemos para enrutar de manera transparente sus conexiones:

groupadd socksified

Hecho esto, añadimos los usuarios que necesitemos al grupo:

usermod --append --groups socksified USUARIO

Con esto ya tenemos casi todo lo necesario. Toca configurar el firewall. Editamos/creamos el fichero /etc/network/iptables.rules y añadimos lo siguiente:

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:REDSOCKS - [0:0]

# Los DNS se los dejamos a TOR
-A OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 53
-A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53

# El grupo socksified se redirige a REDSOCKS
-A OUTPUT -p tcp -m owner --gid-owner "socksified" -j REDSOCKS

## Redes internas
-A REDSOCKS -d 0.0.0.0/8 -j RETURN

# Usamos parte de 10.0.0.0/8 para onion, entonces:
-A REDSOCKS -d 10.0.0.0/9 -j RETURN
-A REDSOCKS -d 10.128.0.0/10 -j RETURN

-A REDSOCKS -d 127.0.0.0/8 -j RETURN
-A REDSOCKS -d 169.254.0.0/16 -j RETURN
-A REDSOCKS -d 172.16.0.0/12 -j RETURN
-A REDSOCKS -d 192.168.0.0/16 -j RETURN
-A REDSOCKS -d 224.0.0.0/4 -j RETURN
-A REDSOCKS -d 240.0.0.0/4 -j RETURN

## Redirecciones
# Privoxy, peticiones http
-A REDSOCKS -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8218

#Privoxy, peticiones "Connect" (https)
-A REDSOCKS -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8318

#Direcciones onion
-A REDSOCKS -d 10.192.0.0/10 -p tcp -j REDIRECT --to-ports 9040

COMMIT

Una vez tenemos las reglas, ejecutamos:

iptables-restore < /etc/network/iptables.rules

Y ya solo nos queda probar si todo es correcto:

# No sale por privoxy
curl https://check.torproject.org | grep -i congra
#ahora, como lanzamos curl con el grupo socksified, sí que lo hace
 sg socksified 'curl https://check.torproject.org |grep -i congratulation'

Como puede observarse, este mecanismo nos puede ser muy útil para dirigir el tráfico a uno u otro proxy, dependiendo, por ejemplo, del grupo con el que se lance la aplicación. También podría hacerse por usuarios. Además, podemos añadir tantas secciones Redsocks como necesitemos, permitiéndonos “jugar” bastante con nuestro sistema, para adecuarlo correctamente a nuestras necesidades.

¡¡Espero que os haya gustado !!

OWASP Mobile Security Project

Introducción

OWASP (Open Web Application Security Project) nos provee de una serie de recursos basados sobre todo en guías y herramientas para que nuestros proyectos web sean lo más seguros posibles, tanto desde el punto de vista de desarrollo seguro como de la evaluación de la seguridad de éstos.

Para los desarrolladores ofrece una gran cantidad de recursos para ayudar a llevar a cabo un ciclo de vida de desarrollo de software seguro (S-SDLC, Secure Software Development Life Cycle).

Para los auditores de seguridad ofrece una gran cantidad de recursos como guías y herramientas para evaluar la seguridad de las aplicaciones móviles.

OWASP Objetivos

OWASP Mobile Security Project

Pues bien, tanto los desarrolladores de aplicaciones móviles como los auditores de éstas, pueden aprovecharse también de recursos de este tipo para poder alcanzar el objetivo de la máxima seguridad posible. Para ello OWASP nos propone su Mobile Security Project.

owasp-msp-logo

La imagen anterior es el logotipo oficial del proyecto OWASP Mobile Security Project.

OWASP ProcesosAl igual que en las aplicaciones web, para conseguir el nivel máximo de seguridad posible es imprescindible que todos los factores se alineen; personas, procesos y tecnología.

Recursos OWASP Mobile Security Project

A continuación nombraremos algunos de los recursos disponibles en este proyecto.

Top 10 Mobile Risks: Tal y como podemos encontrar con el Top 10 de riesgos en aplicaciones web, también tenemos este recurso disponible en el proyecto MSP.

Developer Cheat Sheet: Una “chuleta” con consejos para el desarrollador para evitar errores que puedan dar lugar a vulnerabilidades en su aplicación.

App Security Testing Cheat Sheet: Una “chuleta” para el auditor con información interesante para llevar a cabo la evaluación de la seguridad de la aplicación.

Secure Mobile Development: Recurso para el desarrollador que le ayudará durante el ciclo de desarrollo de software seguro (S-SDLC).

Security Tesing Guide: Similar a la Testing Guide para aplicaciones web, también podemos encontrar una guía de test para ayudar al auditor durante sus tareas de evaluación de los controles de seguridad de la aplicación.

Tools: OWASP nos propone un arsenal de herramientas que nos ayudarán tanto para el desarrollo seguro así como para testear los distintos controles de seguridad. Disponibles para las diferentes plataformas (Android, iOS o Windows Phone).

Top 10 Mobile Controls: Definidos conjuntamente por la ENISA y OWASP, nos indica el top 10 de los controles de seguridad a evaluar.

owasp-msp-resources

En próximos artículos en el blog hablaremos de los distintos recursos que acabamos de comentar. Como siempre, esperamos que sean de vuestros interés y esperamos vuestro feedback.

¡Saludos!

@miguel_arroyo76

 

 

Anonimizando la Kali con anonym8

En determinadas ocasiones, necesitamos utilizar nuestra máquina de auditorías de manera anónima. La mayor parte de herramientas cuentan con una opción para configurar un proxy, ya sea http o sock, con lo que puede configurarse para utilizar TOR.

Sin embargo, no todas tienen esta característica, con lo que nos vemos obligados a utilizar herramientas adicionales como proxychains. Además, en muchas ocasiones queremos también comprobar el tráfico UDP, y esto no es posible hacerlo con TOR.

También es posible que queramos suplantar la MAC de la tarjeta de red, cambiar el nombre del host, no tener fugas de DNSs y, una vez terminada la auditoría, dejar todo como estaba, eliminando, por supuesto, los rastros que hayamos dejado en SWAP, cachés, etc.

privacy

Bien, para hacer todo esto, disponemos de un script que nos va a facilitar todo el trabajo. Lo podéis encontrar en https://github.com/HiroshiManRise/anonym8, y es válido para distribuciones basadas en Debian, por ejemplo, Kali.

Read more

Bypasseando firewalls con Shadowsocks

En shaalgunas ocasiones queremos ocultar nuestro tráfico en la red en la que nos encontramos.

Por ejemplo cuando nos conectamos a redes wifi públicas o no fiables. En otras ocasiones, simplemente, queremos eludir un firewall.

Para esto hay diferentes opciones. Una muy utilizada es usar TOR. Sin embargo, es posible que no queramos utilizarla. Sencillamente queremos usar una conexión a Internet y usar nuestro propia red para navegar. Para ello es para lo que nos sirven los proxys.

En nuestra red segura, levantamos el servidor proxy. En los dispositivos cliente, sencillamente nos conectamos a ella. En el caso de los proxys socks5, podemos, además enrutar tráfico UDP (en el caso de TOR, aunque sea un proxy socks5, y el los túneles ssh, no se puede usar el tráfico UDP ).

Read more

Desactivando ASLR en una app iOS con Radare2 – Parte 2

Introducción

Continuamos con la segunda y última parte de este artículo acerca de cómo desactivar ASLR en una aplicación iOS con Radare2. En la primera parte, que podéis consultar aquí, vimos cómo comprobar si un binario de tipo Mach-O tiene activado o no la protección PIE (Position-Independent Executable). PIE permite el uso de Exec Shield o PAX que utilizan técnicas de direccionamiento aleatorio como ASLR (Address Space Layout Randomization).

También vimos que dependiendo de la arquitectura, ARMv7 o ARM64 tendríamos que buscar una cadena u otra. Además vimos que esa cadena a buscar en nuestro binario estaría cerca de la cadena _PAGEZERO, que nos puede servir de referencia.

Manos a la obra

Vamos a “parchear” nuestro binario para modificar unos bytes que nos permitirán desactivar el PIE. Para ello abriremos el binario en modo escritura con Radare2. Para abrir un binario en modo escritura utilizaremos el parámetro -w (write).

Radare2 - Write modeEn la imagen anterior podemos ver que hemos abierto ya no está cifrado (aplicado Clutch en la primera parte), y que tiene habilitado PIE.

Localizamos la cadena a buscar, tal y como hemos visto en la primera parte de este artículo, y pasaremos a explorar el binario para hacer el “parcheo“.

Con la tecla v (visual mode) de Radare2 podemos entrar en modo visual, lo que nos va a permitir a ver las distintas direcciones relativas y sus contenidos. Con la tecla c (cursor mode) activamos el cursor y podremos desplazarnos por los contenidos mostrados.

Una vez localizados los bytes a modificar, 850020 (recordad que varía según la arquitectura), procedemos a activar el modo insertar, para lo que pulsaremos la tecla i en Radare2.

Radare2 - Insert modeEn este modo de inserción, podremos modificar los bytes, dejándolos como vemos en la siguiente imagen.

Radare2 - Insert mode

Salimos de Radare2, los cambios se guardarán automáticamente porque hemos “escrito” directamente en el binario.

Comprobación

Comprobamos nuevamente con la herramienta otool si PIE sigue activado o no.

otool - iOS PIE

Podemos comprobar como efectivamente en el binario cuyo nombre acaba en _NoPIE hemos conseguido deshabilitar PIE.

Para finalizar, con otra herramienta del framework de Radare2, como es radiff2, podemos buscar diferencias entre dos binarios. Si lo aplicamos a los dos binarios con los que hemos estado trabajando, uno con PIE activado y el otro con el PIE desactivado con Radare2, podemos ver la diferencia en el byte modificado.

A continuación se puede ver un ejemplo de radiff2 con estos archivos.

Radiff2 - PIE

Hasta aquí este artículo que, como siempre, esperemos haya sido de vuestro interés. Todos los comentarios y sugerencias serán bienvenidos. Gracias de antemano.

¡Hasta pronto!

Miguel A. Arroyo – @miguel_arroyo76

Introducción al SDR – Radar pasivo de Aviones

Hace ya un tiempo, en Mayo de este año, publiqué un artículo de iniciación al mundo SDR. Con un simple TDT y un chip adecuado podíamos escanear nuestro espectro radioeléctrico y observar-escuchar infinidad de señales. Recuerdo que en mis primeras pruebas, sin apenas saber que hacía, pude “navegar” en unas frecuencias bastante comunes (30-33mhz creo que era) y escuchar una conversación telefónica. Debido al sitio en el que me encontraba y la “enorme potencia” de mi SDR USB, solo podía ser un familiar mío. El otro lado de la comunicación igualmente era también familiar de un servidor.

Esto podría ser la historia de cualquier persona que esté en el momento preciso en el sitio adecuado con un receptor SDR (recordar que esto no emite, solo recibe por tanto no es intrusivo), y no una Poc que realicé con unos viejos teléfonos inalámbricos analógicos sin DECT(tecnología digital que usan los no tan actuales teléfonos inalámbricos, para que nos entendamos). La idea es sencilla: un receptor TDT con chip RTL, sdr-sharp y zadig y a situarte en frecuencias comunes y ya tienes un mini-kit para husmear el espectro radioeléctrico.

Como ya comenté en el artículo inicial, Introducción al SDR, podemos seguir las instrucciones que refiero en el artículo para jugar con esta herramienta, que si la evolucionamos (construirnos una antena más sensible, por ejemplo) podemos obtener resultados muy interesantes.

logosdr

Read more