Archive for Redes

La seguridad actual de la autenticación inalámbrica PSK (III)

En esta tercera entrega, llega el momento de extraer nuestras propias conclusiones sobre la seguridad actual de la autenticación PSK. Resulta que con la ejecución de Pyrit en una instancia g2.8xlarge del Cloud de Amazon, se obtiene un rendimiento interesante en el cómputo de claves:

011 - pyrit benchmark AMAZON

Tal y como se puede observar en la ilustración anterior, se cuenta con un cálculo de 115.265 claves/segundo, un incremento más que considerable en referencia a las 836 claves/s iniciales de mi máquina virtual.

Pero esto no termina aquí. Aún podemos mejorar la capcidad de cómputo y de una forma más que considerable. Existen dos opciones:

  • Ejecución de Pyrit en modo distribuido.
  • Utilizar tablas PMK precomputadas.

Una vez más, debido a la magnitud que debe respetar el artículo, es necesario focalizar nuestros esfuerzos en una de las opciones anteriores y, en este caso, se ha optado por mostrar la velocidad extrema que se consigue con las tablas PMK precomputadas.

Read more

La seguridad actual de la autenticación inalámbrica PSK (II)

Este segundo artículo, de carácter más práctico, define el conjunto de herramientas a utilizar y además, se ha esquematizado para que sea un pequeño tutorial que nos permita efectuar la instalación de las mismas en las máquinas del Cloud.

Para los lectores que no desean conocer en profundidad los detalles técnicos, se recomienda obviar esta parte y saltar directamente a la tercera.

Empecemos.

Primeramente, necesitamos localizar un herramienta que sea capaz de utilizar toda la potencia de cómputo de nuestro hardware con el fin de cumplir con nuestro objetivo, que es calcular el mayor número posible de claves PSK por segundo, tal y como hemos comentado en la primera entrega. Para lograr la tarea, se propone la utilización de Pyrit.

Pyrit

Es una herramienta muy potente que permite realizar ataques a la autenticación WPA/WPA2-PSK. Destaca por tener la propiedad, a diferencia de otras herramientas, de utilizar la potencia extra de las GPUs para acelerar de forma extraordinaria el proceso de cómputo de las claves PSK. Se encuentra escrita mayormente en Python, pero también cuenta con algunos módulos escritos en C (cpyrit-cuda, cpyrit-opencl) que se encargan de permitir el uso de las tarjetas gráficas. Además, entre otras funcionalidades, nos brinda la posibilidad de crear tablas de claves PSK precomputadas.

Por otro lado, necesitamos un software intermediario que permita la interacción con las tarjetas gráficas. En este caso, se trabajará con CUDA Toolkit.

CUDA

CUDA son las siglas de Compute Unified Device Architecture (en Castellano, Arquitectura Unificada de Dispositivos de Cómputo) y hace referencia a un framework desarrollado por NVIDIA que permite a los programadores de C y C++ aprovechar la potencia del procesamiento paralelo de sus tarjetas gráficas, con el fin de proporcionar un incremento del rendimiento del sistema.

Con las dos herramientas anteriores y conjuntamente con el Cloud, ya tenemos todos los componentes necesarios. Sólo nos queda realizar la instalación de este software a una máquina remota y en el caso del panel de NIMBIX, la secuencia de pasos a realizar es la siguiente:

Read more

La seguridad actual de la autenticación inalámbrica PSK (I)

Han pasado ya algunos años desde que el estándar 802.11i fue ratificado en Junio de 2004, y algunas cosas han cambiado desde aquel entonces, dando énfasis en la capacidad de computación de las máquinas. No obstante, sobre la misma línea, nada nuevo está presente en la autenticación WPA, que como ya sabemos se encuentra dividida en dos bloques:

  • WPA Enterprise Authentication: donde se utiliza el estándar 802.1x y normalmente un servidor Radius para efectuar Authentication, Authorization y Accounting (AAA).
  • WPA Personal Authentication: donde se emplea una passphrase precompartida por todos los integrantes de la red (similar a WEP).

En esta secuencia de artículos, primeramente veremos los fundamentos del ataque sobre la autenticación PSK (Pre Shared Key), también conocida como autenticación “Personal”, y posteriormente lo pondremos en práctica sobre el Cloud de NIMBIX y de Amazon para extraer nuestras propias conclusiones.

Partiendo de la base de tener en posesión un handshake, sólo nos queda por dar una pequeña pincelada a la generación de la PTK (Pairwise Transient Key):

Diagrama generación PTK

Como podemos ver, la clave precompartida, denominada passphrase, se pasa a una función conocida como PBKDF2, utilizada en PKCS#5, conjuntamente con los siguientes parámetros:

  • El SSID y su longitud.
  • El número de iteraciones a realizar, 4096.
  • La longitud de la clave resultante, 256.

Read more

Hacking vía Satélite

Vamos a jugar un poco con decodificadores de televisión vía satélite con el objetivo de ver algunos fallos de seguridad, pero antes de nada vamos a dar varias nociones para aquellas personas que no conozcan el tema.

Normalmente la persona que quiere ver la televisión de pago vía satélite necesita una antena parabólica (por la cual recibimos la señal de datos), un decodificador de satélite (capaz de decodificar la señales del satélite) y una tarjeta de abonado (que contiene las claves para descifrar la señal de datos cifrada). Hasta aquí todo correcto, verdad? pero antes de nada vamos a añadir una:

NOTA LEGAL

  • El objetivo de este artículo es conocer la seguridad de los receptores de comunicación vía satélite.
  • Rechazamos el uso de cualquier técnica ilegal como Card Sharing o IKS.
  • Ningún sistema sufrió daño alguno mientras se realizaron las pruebas de concepto.
  • No me hago responsable del mal uso que podáis dar a la información aquí mostrada.

Read more

Seguridad en las impresoras

Introducción

Cuando hablamos de seguridad en las empresas y qué activos proteger, enseguida se nos vienen a la cabeza los distintos vectores de ataque de nuestros sistemas de información y cómo protegernos de esos posibles ataques. Pero, ¿qué ocurre con la seguridad en las impresoras?

Seguridad perimetral, seguridad en las comunicaciones, seguridad en el puesto de trabajo, seguridad en los dispositivos móviles… son algunos de los ejemplos de protección de activos de la empresa.

Pero estamos pasando por alto un tema importante de seguridad en este planteamiento, y se trata de las impresoras. ¿Existen posibles vectores de ataque a este tipo de dispositivos? Si es así, ¿cuáles podrían ser? Quizás el problema radique en que vemos a la impresora como una “simple” máquina cuya función es imprimir lo que desde un ordenador enviamos.

Si nos detenemos en qué es una impresora, enseguida entenderemos que, además de la electrónica y mecánica pura de una impresora, está dotada de una serie de puertos, interfaz de red, controladores, disco duro y un pequeño ordenador, con su BIOS y con su sistema operativo, que maneja estos recursos.

OK, ahora más o menos nos hacemos una idea, pero ¿qué riesgos hay realmente? Vamos a dividirlos en varios apartados:

Vectores de ataque

Confidencialidad del documento impreso

En entornos corporativos es muy normal que se utilicen impresoras de red que está ubicadas en un lugar remoto de la oficina. ¿Qué ocurre si mandamos a imprimir un documento con información sensible? Desde que nos levantamos del puesto de trabajo hasta que recogemos el documento de la bandeja de la impresora, ¿quién ha podido ver o fotocopiar ese documento?

Las impresoras suelen incluir una funcionalidad llamada impresión privada, que permite proteger con un PIN la impresión del documento. Éste queda en cola hasta que el usuario, después de enviar el documento a imprimir, introduce su PIN de seguridad en la impresora para que ésta imprima el documento.

Vulnerabilidades

La impresora ejecuta una serie de servicios que se publican en unos puertos, por ejemplo para su administración. Hoy en día es bastante habitual que las impresoras puedan ser gestionadas vía Web, por lo tanto disponen de su propio servidor Web que permite esta administración.

El software que gestiona dicho servicio puede estar afectado por algún tipo de error que pueda dar lugar a una vulnerabilidad que podría ser aprovechada por un posible atacante y explotada para, por ejemplo, provocar una denegación del servicio.

Modificación de firmware

Las impresoras para mejorar sus funcionalidades o corregir posibles errores de sus software, permite la actualización de su firmware. Este firmware normalmente está disponible en la Web del fabricante. Un posible ataque podría ser la alteración de este firmware para tomar el control de la impresora de forma remota, capturar tráfico o para lanzar ataques a otros dispositivos de la red.

Robo de información

Ya existen muchas impresoras que incluyen un disco duro para el almacenamiento de información, como pueden ser trabajos, históricos de impresiones, documentos escaneados, etc. Al final ese disco duro podría ser extraído de la impresora, y si no hay un cifrado en la información de éste, se podría consultar sin ningún problema información sensible de los trabajos realizados en la impresora.

Indexación de impresoras en Internet

Muchas impresoras, por razones extrañas, son publicadas directamente en Internet. Esta publicación da lugar a que motores de indexación de dispositivos como Shodan acaben añadiendo a su base de datos información de la impresora como puede ser su banner del servidor Web, dirección IP pública, servicios publicados, localización… Si además, la administración Web no ha sido protegida de forma adecuada, se podría dar el caso de que algún atacante tuviera fácilmente acceso a ella.

Instalación de aplicaciones maliciosas

Por último, y no menos importante, es la mención a la posibilidad de instalar aplicaciones en las impresoras. Aplicaciones que pueden ser potencialmente peligrosas y pueden ser usadas de forma maliciosa para controlar la impresora con fines fraudulentos, como puede ser la captura de tráfico de la red o acceder a trabajos de ésta. Se han dado casos muy curiosos como la instalación del juego Doom en una impresora. Otro vector de ataque a tener muy en cuenta.

Conclusión

Con los posibles vectores de ataque que acabamos de comentar, creemos que son lo suficientemente relevantes para que a dispositivos como impresoras le demos la importancia que realmente tienen, y se apliquen una serie de políticas de seguridad para mitigar o reducir los posibles riesgos que estos vectores puedan suponer para la empresa. Resumiendo, no nos podemos olvidar de la seguridad en las impresoras.

Sockets SSL en Python

Recientemente un lector del blog me contactó para pedirme, muy amablemente, si podía ayudarle a comprender los conceptos de implementación de sockets SSL en Python. ¡Por supuesto! Y como siempre, fiel a la humilde ideología de este blog, quedará aquí todo expuesto con el fin de compartirlo con todos vosotros e intentar ayudar a alguien más.

En primer lugar, vamos a ver un breve resumen del concepto de socket.

Dentro del ámbito de la programación, se utiliza el término socket para hacer referencia, principalmente, a las siguientes definiciones:

  • Socket (def. [1]): concepto abstracto por el cual dos programas, normalmente situados en computadoras diferentes, pueden intercambiar un flujo de datos a través de un canal de comunicación.
  • Sockets (def. [2]): en muchos casos la Network Application Programming Interface (NAPI) denominada BSD Berkeley Sockets se abrevia a Sockets. Se trata de una interfaz de trabajo que se utiliza para relacionar la capa de aplicación con la capa de transporte. Normalmente, este tipo de interfaces las proporciona el sistema operativo. A continuación, siguen otras NAPIs conocidas:
    • TLI, XTI (de AT&T UNIX System V)
    • Winsock (de Microsoft)
    • MacTCP (de Apple Computer)

Veamos una imagen representativa de estas:

NAPI en el Modelo TCP-IP Read more

Mejorando BSSID Finder

Siguiendo el hilo tratado en el post de hace algunos días, BSSID Finder, vamos a ver cómo podemos ampliar nuestro pequeño script, sin salir del ámbito de scapy, para que no sea meramente una aplicación informativa. En esta ocasión, he subido el código fuente en un repositorio de Github, disponible en este enlace.

¿Qué va a hacer el programa?

  1. Buscará los distintos BSSIDs para un ESSID determinado.
  2. Mostrará por pantalla los resultados encontrados, permitiendo seleccionar un BSSID específico o todos a la vez, con el objetivo de desautenticar sus correspondientes clientes inalámbricos.
  3. Finalmente, lanzará automáticamente los paquetes de desautenticación.

Veamos un ejemplo de su ejecución:

exec

Efectivamente, una vez seleccionada la opción All, realiza el envío de los correspondientes paquetes de desautenticación para todos los BSSIDs encontrados. Una vez más, Wireshark nos ayuda a corroborarlo:

wireshark

Podemos ver en la imagen que se ha aplicado un filtro para mostrar únicamente los paquetes del tipo gestión (0) y el subtipo deauthentication (12), el cual nos permite observar un paquete que tiene como Destination Address (DA) el valor broadcast y como Source Address (SA) y BSSID la dirección MAC del punto de acceso. No es casualidad, ya que la definición de estos valores se ha indicado explícitamente en el código. Veamos:

deauth_clients

En este caso, lo que tenemos es que a partir del objeto iterable bssids, vamos a enviar un número determinado de paquetes para cada bssid que contenga, definido por count, y en un intervalo de 0.2 segundos, definido por inter.

Cada paquete constará de tres capas, todas proporcionadas por scapy:

  • RadioTap(): se trata de una capa que proporciona información adicional sobre el paquete, como puede ser el canal por el que se transmite o la intensidad de señal de la fuente emisora una vez se ha recibido. Es una capa gestionada por el driver del adaptador inalámbrico y no es parte del estándar IEEE 802.11, con lo cual algunos drivers pueden simplemente ignorarla. En el código no se ha introducido información adicional al respecto.
  • Dot11(): representa propiamente el formato 802.11 y en este caso se le indica que encapsulará un paquete de desautenticación mediante las especificaciones de type=0 y subtype=12. Además, también define las direcciones MAC y su correspondiente ordenación según la especificación To DS=0 y From DS=0:

ToDS

FromDS Addr 1 Addr 2 Addr 3

Addr 4

0

0 DA SA

BSSID

0

1 DA BSSID

SA

1

0 BSSID SA

DA

1

1 RA TA DA

SA

Las siglas de la tabla hacen referencia a:

  • DA: dirección destinación.
  • SA: dirección origen.
  • RA: dirección del receptor.
  • TA: dirección del transmisor.
  • BSSID: dirección del AP.

Caso 00: la trama es parte de una red Ad-Hoc (IBSS), en que dos o más estaciones se comunican entre sí, o bien no está destinada a salir del entorno inalámbrico. Los beacon frames mantienen esta estructura y de hecho, cualquier trama de control o gestión.

Caso 01: la trama está entrando al entorno inalámbrico y proviene de un sistema de distribución (del Inglés, Distribution System (DS)). Un ejemplo puede ser una trama procedente del DS que va dirigida a la estación cliente y que será reenviada por el punto de acceso.

Caso 10: la trama abandona el entorno inalámbrico y es destinada a un nodo de la red del sistema de distribución. Un ejemplo es cuando una estación solicita una dirección IP (DHCP Request) y la solicitud es reenviada por el punto de acceso al servidor DHCP que reside en la red del sistema de distribución.

Caso 11: la trama está involucrada en una red del sistema de distribución inalámbrico (del Inglés, Wireless Distribution System (WDS)). Un ejemplo es cuando un punto de acceso se comunica con otro.

  • Dot11Deauth(): es la capa correspondiente a los paquetes de desautenticación y en la que sólo se puede especificar el motivo por el cual se solicita el proceso. Esta vez, se ha indicado “Unspecified reason” mediante el valor 1.

Podemos comprobar que, si durante la ejecución del script tenemos en correcta ejecución Airodump-ng, éste nos notificará de la captura de un handshake. Y no se acaba aquí, ya que también existe la posibilidad de efectuar un ataque DoS a las estaciones clientes si se introduce una cantidad suficientemente grande de paquetes a enviar, en lugar de 5 como se ha especificado en el ejemplo.

Finalmente, a modo conclusión, queda por destacar, una vez más, la potencialidad que nos brinda scapy y de la cual hemos sido testigos en este post.

¡Os animo a que lo probéis!

¡Saludos!

 Ferran Verdés

Instalación de Snorby

En los artículos anteriores hemos configurado Snort para que nos escribiera las alertas en un fichero Unified2 y con Barnyard2 conseguimos pasar estas alertas a nuestra Base de Datos de Mysql. Para nuestra gestión de alertas que genere nuestro Snort vamos a instalar la aplicación Web SNORBY en un sistema operativo Debian 8.

Aquí os dejamos una captura del dashboard así como del login de este framework muy interesante e intuitivo.

snrb1

Login de acceso a nuestro framework

Read more

BSSID Finder

En este post veremos que sólo 20 líneas de python son las necesarias para complementar el comportamiento de un sniffer y lograr que éste cumpla con nuestras necesidades. No obstante, el objetivo principal es proporcionar una introducción práctica a la librería scapy.

Este script resulta útil cuando en las auditorías wifi se requiere el conocimiento de los distintos AP de la organización que están a nuestro alcance. Un objetivo claro puede ser, por ejemplo, suplantar la identidad de los puntos de acceso para el envío de paquetes de desautenticación a las estaciones clientes.

Evidentemente esta tarea se puede realizar de forma manual, simplemente lanzado airodump-ng y anotando los bssid de interés, y cruzando los dedos para que no existan demasiados puntos de acceso. No obstante, contemplar las posibilidades del script resulta interesante, ya que son muy extensas. Por ejemplo, con pocas líneas es posible automatizar el envío de los paquetes de desautenticación y al final, todo se reducirá en un cd y un enter.

Para hacer uso del script, como siempre, debemos disponer de nuestra tarjeta en modo monitor:

monitor_mode

La sentencia “airmon-ng check kill” nos permite matar los procesos que pueden interferir con nuestro modo monitor de la tarjeta. Es muy recomendable usar esta sentencia, ya que nos podemos ahorrar la posibilidad de obtener un comportamiento no deseado de la misma, y en consecuencia, una situación de confusión.

Read more

Instalación de un IDS con Snort. Parte II

Continuando con la instalación de un IDS con Snort (Parte I), vamos a ver como actualizar las reglas de VRT o EmergingThreats para SNORT.

snort_large

Existen varios programas para dicho cometido, pero nosotros vamos a utilizar “PulledPork”.

Lo primero que tenemos que hacer es instalar los pre-requisitos necesarios para su instalación, Para ello ejecutamos:

            apt-get install libcrypt-ssleay-perl libwww-perl

A continuación procedemos a la instalación de PulledPork:

cd /usr/src

wget http://pulledpork.googlecode.com/files/pulledpork-0.7.0.tar.gz

tar -zxvf pulledpork-0.7.0.tar.gz

cd pulledpork-0.7.0

cp pulledpork.pl /usr/local/bin

cd etc/

cp *.conf /etc/snort

El siguiente paso a realizar, es la configuración de Pulledpork.

1.Editamos el fichero de configuración:

      nano –c /etc/snort/pulledpork.conf

**Nota: Necesitarás darte de alta en la página http://www.snort.org y después de activar tu cuenta deberás solicitar tu Oinkcode.

snort

2. Modificamos las siguientes líneas:

Comentamos las líneas 19, 21 y 26. Para ello ponemos a principio de la línea el carácter “#”.

A continuación de la línea 26 añadimos las siguientes líneas

rule_url=https://www.snort.org/rules/|snortrules-snapshot-2976.tar.gz|aquí hay que poner tu Oinkcode

rule_url=https://rules.emergingthreatspro.com/|emerging.rules.tar.gz|open

Y modificamos las siguientes líneas

Línea #74 – cambiar por: rule_path=/etc/snort/rules/snort.rules

Línea #81 – des-comentar y cambiar por: out_path=/etc/snort/rules/

Línea #89 – cambiar por: local_rules =/etc/snort/rules/local.rules

Línea #92 – cambiar por: sid_msg=/etc/snort/sid-msg.map

Línea #119 – cambiar por: config_path=/etc/snort/snort.conf

Línea #121 – cambiar por: sostub_path=/etc/snort/rules/so_rules.rules

Línea #133 – cambiar por: distro=Debian-Lenny

Linea #141 – cambiar por: black_list=/etc/snort/rules/black_list.rules

Línea #192 – des-comentar y cambiar por: snort_version=2.9.7.6

Línea #196 – des-comentar y cambiar por: enablesid=/etc/snort/enablesid.conf

Línea #198 – des-comentar y cambiar por: disablesid=/etc/snort/disablesid.conf

Línea #199 – des-comentar y cambiar por: modifysid=/etc/snort/modifysid.conf

A continuación ejecutamos el siguiente comando para deshabilitar todo el bloque de reglas fwsam.

echo pcre:fwsam >> /etc/snort/disablesid.conf

Si queremos guardar todas las reglas en un solo fichero, tenemos que ejecutar el siguiente comando.

      /usr/local/bin/pulledpork.pl -c /etc/snort/pulledpork.conf -T -l

Para guardar las reglas en ficheros diferentes

     /usr/local/bin/pulledpork.pl -c /etc/snort/pulledpork.conf -k -l

Una vez actualizadas nuestras reglas para Snort procedemos a la instalación y configuración de BARNYARD2.

Para ello realizamos los siguientes pasos.

1.Instalación de pre-requisitos

      apt-get install libpcre3 libpcre3-dbg libpcre3-dev build-essential autoconf automake libtool libpcap-dev libnet1-dev mysql-client libmysqlclient-dev

2.Instalación de barnyard2

cd /usr/src/

wget http://www.securixlive.com/download/barnyard2/barnyard2-1.9.tar.gz

Si no funciona podemos utilizar el siguiente enlace

wget ftp://ftp.tw.freebsd.org/pub/ports/distfiles/barnyard2-1.9.tar.gz

tar xvfz barnyard2-1.9.tar.gz

cd barnyard2-1.9

./configure –with-mysql

Si durante la instalación se produce el siguiente error es que no encuentra la librería libmysqlclient.*. Para saber en qué directorio se encuentra podemos ejecutar el siguiente comando

      find / -name libmysql*

snort

snort

Como vemos en la imagen anterior (lo he marcado en rojo) ya sabemos la ruta donde se encuentra la librería y reanudamos la instalación.

./configure –with-mysql –with-mysql-libraries=/usr/lib/i386-linux-gnu

make

make install

cp /usr/src/barnyard2-1.9/etc/barnyard2.conf /etc/snort/

 3.Configuración del fichero barnyard2.conf.

nano –c /etc/snort/barnyard2.conf

Comprobamos las siguientes líneas.

Linea 29     config reference_file:     /etc/snort/reference.config

Linea 30     config classification_file: /etc/snort/classification.config

Linea 31     config gen_file:           /etc/snort/gen-msg.map

Linea 32     config sid_file:           /etc/snort/sid-msg.map

Y añadimos al final del fichero

output database: log, mysql, user=<usuario base de datos> password=<pasword usuario> dbname=<base de datos> host=<indicamos ip del servidor sql> sensor_name=<nombre de sensor>

           Un ejemplo de configuración para añadir las alertas a la base de datos de Snorby,

output database: log, mysql, user=snorbyuser password=PASSWORD123 dbname=snorby host=192.168.1.111 sensor_name=sensor1

Para terminar comprobamos que funcione correctamente Snort y Barnyard2

/usr/local/bin/snort -q -u snort -g snort -c /etc/snort/snort.conf -i eth0 &

/usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.log –w /etc/snort/bylog.waldo &

Con esto finalizamos el artículo de hoy, en el siguiente veremos cómo instalar y configurar Snorby para complementar nuestro IDS.

Saludos.

Juanjo Martínez