Bitmessage : 2º Parte

En el post anterior os hablé sobre Bitmessage. En éste, vamos a ver qué nos ofrece esta aplicación de correo electrónico distribuido.

En primer lugar, instalamos el cliente. Desde la web oficial, vemos que está disponible para Windows, Mac OS y, en el caso de Linux, tenemos el código fuente. Está escrito en Python. De hecho, el protocolo se llama Bitmessage y, el cliente, pybitmessage.

Una vez iniciamos la aplicación, nos pide si necesitamos configurar la red, o no es necesario. Esto es por si necesitamos indicar un proxy o similar.

Una vez iniciado, se conectará con la red y empezará a descargar la lista de mensajes, claves públicas, etc. Hay que recordar que su funcionamiento está inspirado en el protocolo de Bitcoin. Todos los mensajes pasan por todos los nodos y, la forma de saber si es nuestro o no, se basa en si tenemos la clave privada para descifrarlo.

Read more

Bitmessage

Una alternativa al correo electrónico tradicional, es Bitmessage. Es un protocolo inspirado en BitCoin, que pretende resolver el problema de la utilización de un servidor de correo por un lado y, por otro, la privacidad en la comunicación entre dos usuarios.

Nació en noviembre del 2012, con licencia MIT. Tras las denuncias de espionaje masivo efectuadas por Edward Snowden, en junio del 2013, su utilización se disparó, multiplicándose por cinco las descargas de este software.

La idea es la siguiente:

  • Creamos una red P2P anónima, que los usuarios van a utilizar para enviar sus mensajes.
  • Los usuarios van a poder crear diferentes identidades (desaparece el concepto de cuenta), que constará de una clave pública, con la que se cifrará el mensaje, y su correspondiente clave privada, para poder descifrarlo. Estas claves son compatibles con las utilizadas por BitCoin.
  • Los mensajes cifrados completamente (en el correo tradicional solo se cifra el mensaje y los archivos adjuntos), incluyendo emisor, receptor, asunto y, por supuesto, el mensaje, se copia a la red P2P, junto con los mensajes del resto de usuarios. Todos los mensajes pasarán por todos los clientes (nodos). El mecanismo para saber si un mensaje es nuestro o no, es sencillo: Si podemos descifrarlo, el mensaje es nuestro.
  • Los mensajes se almacenan cifrados en los nodos que componen la red P2P.

Read more

Recuperando datos de un Disco Duro Seagate 7200.11 SD81

Vuelvo con este artículo que si bien no tiene mucho de “hacking” propiamente dicho, si que tiene su parte “forense”, que también tiene su encanto. Debido a la suma importancia personal de los datos que contenía el HDD, el poder recuperarlos fue todo un éxito porque además, no se perdió ni un solo documento y es por ello que os lo traslado aquí.

La historia.

Hace pocas semanas un familiar cercano me comunicó que su HDD donde tenía todas las fotos, vídeos y demás “timeline” de su familia tanto actual como los no presentes ya, no lo reconocía su equipo. Tras indicarle lo típico “¿has apagado y encendido el disco duro?, ¿has conectado el disco duro a otro ordenador?, ¿has pintado de verde el disco y tirado al río?, etc…” pude diagnosticarle, atrevidamente por teléfono, que había “cascao”.

Cuando coincidimos en una reunión típica familiar (dichos familiares viven bastante lejos de dónde yo) me dieron el regalito del Disco Duro Seagate 7200.11 con firmware SD81 de 500Gb, con 499Gb ocupados de información valiosa.

Mi idea era la que suelo seguir en caso de que me traigan discos duros que suenan a castañuelas y limitado a los cuatro aparatitos que tengo: o intentar dejar el disco duro en una posición donde la mecánica del mismo permita temporalmente acceso (muchas veces he recuperado así algunos datos) o congelando el disco duro (y también he tenido éxito algunas veces).

Pero una simple navegación por San Google (Duck Duck Go más bien) buscando el modelo por si acaso había algún hilo sobre este disco y bingo!, este modelo con algunos firmware distintos al que calza nuestro disco duro a reparar, contiene un fallo de serie que consiste en que el log se corrompe debido a una serie de eventos que registra el propio HDD.

Read more

Las principales vulnerabilidades web

Cuando se va a atacar un sistema, lo último que se quiere es que salten todas las alarmas. Es por eso que usar fuentes online son una buena herramienta. Se puede utilizar hacking de buscadores para localizar URLs con paso de parámetros, para comprobar si éstos están correctamente validados, para buscar correos electrónicos u otra información que pueda extraerse de un determinado sitio: ficheros de backup o de configuración que hayan quedado indexados, etc.

Un buscador muy utilizado es Shodan. Este buscador almacena toda la información pública que puede obtener de aquellos dispositivos que están expuestos a Internet. Entre otras cosas, podemos encontrar dispositivos con sus claves por defecto (routers, cámaras ip, etc), direcciones IP con los puertos que tienen abiertos, servicio y versión del mismo que corre en cada uno, certificados SSL, con sus respectivas suites de cifrado, etc. Una vez indexada una determinada IP en Shodan, evita tener que hacer una comprobación directa sobre el sistema, de manera que permite a un atacante conocer si un sitio web está correctamente actualizado, sin necesidad de lanzar un escaneo de puertos, que pueda delatarle a él.

Read more

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