Skipfish, Escaner Web

Hoy en día existen infinidad de aplicaciones, scripts, frameworks, etcétera para auditar sistemas, ya sean de infraestructura de red, Web, Web basado en OWASP, Wireless, etc… Suelen aparecer software con versiones gratuitas, gratuitas con limitaciones y versiones de pago con diferentes de modalidades.

Las de pago las vamos a obviar porque evidentemente, se necesita una inversión bastante potente en muchas de ellas y para algo “casero” pues no es demasiado lógico gastarse miles de euros.

Las versiones libres o scripts subidos a la red (GitHub por ejemplo), suelen tener la ventaja que son personalizables y puedes editarlos a tu gusto, que es lo que se estila para adaptar los resultados a gusto o necesidad de auditores o meros curiosos.

Hoy nos vamos a centrar en mostrar un escaner Web bastante potente que tiene sus pros y contras pero que es otra herramienta más que puede ayudarnos enormemente en labores de buscar agujeros de seguridad en plataformas Web ya sean en pre-producción o producción. Hablamos de Skipfish

skipfish2

Read more

Curso Hacking Android – ¡Novedad!

Hoy traemos una novedad que seguramente os guste a la mayoría. Se trata de un nuevo curso de hacking ético. Esta vez le ha tocado el turno a Android.

Pese a la grandísima aceptación que han tenido y están teniendo nuestros cursos de Hacking Web, Wifi y de Sistemas y Redes (Básico y Avanzado) queremos, con este nuevo curso, dar un extra más de valor a nuestra CyberAcademy de Hacking Ético.

Para ello hemos contado con todo un profesional y experto Android como es Eduardo Sánchez, el cual, será el Tutor del curso, que comenzará el próximo 6 de Junio.

Curso Hacking Android

Los objetivos de este curso, de nivel medio-avanzado, son que el alumno conozca las técnicas de hacking ético en Android con el fin de poder aplicarlas a la hora de detectar posibles fallos de seguridad en nuestros dispositivos y aplicaciones, lo que le permitirá saber qué contramedidas se deberán implementar para solucionar y mitigar los posibles riesgos.

  • El alumno aprenderá de manera práctica:
  • Conceptos básicos sobre la arquitectura Android.
  • Uso de herramientas para interactuar con el sistema operativo Android.
  • Acceso al dispositivo por medio de diferentes protocolos.
  • Reversing de código fuente.
  • Análisis de aplicaciones maliciosas.
  • Análisis forense de aplicaciones y del dispositivo Android.
  • Pentesting de aplicaciones Android con Drozer.
  • Vulnerabilidades más conocidas en Android.
  • Uso de Metasploit con Android.

Os dejamos la ficha técnica para que os informéis más detalladamente de como va a ser el curso y que materia se impartirá, así como las fechas de esta primera edición, que llamaremos “Apple Pie” en honor a la primera versión Android aunque es importante aclarar, que solo es un nombre simbólico, ya que se trabajarán con las últimas versiones Android. Por si acaso, lo aclaramos 😉

Si queréis proceder al inicio de la inscripción, solo tenéis que clicar aquí o en la sección Cursos de Seguridad Informática de nuestro blog y al final, veréis un formulario de contacto (poned datos reales, será para todos más rápido el registro).

Happy Hacking!

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

Patito Hunter – Detectar y bloquear un USB Rubber Ducky con Python

“Cazando al patito”

Introducción a USB Rubber Ducky

A estas alturas seguro que ya todos habéis visto (o padecido) o habéis escuchado hablar sobre USB Rubber Ducky, conocido familiarmente como el “patito“. Para los que no, simplemente decir que se trata de un dispositivo USB con apariencia similar a un pendrive o flashdrive de toda la vida pero que en realidad es un dispositivo HID (Human Interface Device). En este caso se trata de un teclado que almacena una serie de comandos que son ejecutados cuando el dispositivo se conecta a un ordenador, portátil, tablet o smartphone. Los comercializan los chicos de Hak5, pero en España también tenemos representación de la empresa Phoenix Intelligence & Security que también fabrican dispositivos similares. Como os podéis imaginar las posibilidades son infinitas.

Aquí tenéis dos artículos en nuestro blog mostrando sus posibilidades:

Cuando el pato teclea Cuack Cuack – Parte 1

Cuando el pato teclea Cuack Cuack – Parte 2

Cabe destacar además que a día de hoy, muy pocos fabricantes de malware detectan y bloquean este tipo de dispositivos, solo G-Data con su USB Keyboard Guard. Eso sí, de momento solo para Windows.

USB Rubber Ducky - Ninja

Objetivos

En este caso no he venido aquí para escribir cómo funciona el USB Rubber Ducky y sus posibilidades, que como ya he dicho antes, son muchas desde el punto de vista ofensivo. Los objetivos de este artículo son:

  1. Explicar en qué he basado mi investigación
  2. Presentar la herramienta “Patito Hunter
  3. Aprender, hackear y compartir.

Ya en este blog he ido publicando artículos sobre análisis de dispositivos USB con Wireshark, concretamente los artículos los podéis encontrar en estos enlaces:

Análisis de un dispositivo USB con Wireshark – Parte 1

Análisis de un dispositivo USB con Wireshark – Parte 2

En estos artículos se explica cómo capturar tráfico USB con Wireshark para a continuación analizar la información obtenida y saber cómo funcionan los dispositivos USB; desde que lo conectamos al equipo, se intercambia información del dispositivo, sus configuraciones o interfaces. Desde la publicación del primer artículo, en octubre de 2015, he ido analizando con Wireshark la información de distintos dispositivos USB, y de distintas clases (Mass Storage, Printer, HID, etc).

Esta misma información puede ser usada para analizar otros dispositivos de tipo Bad USB, como puede ser el propio USB Rubber Ducky o LAN Turtle (la famosa tortuga). Como he comentado en la introducción, un “patito” emula el funcionamiento de un dispositivo HID, concretamente un teclado, pero con sus diferencias. Y son precisamente estas diferencias las que me han llevado a desarrollar una pequeña herramienta, a la que he llamado cariñosamente “Patito Hunter” para detectar y bloquear los USB Rubber Ducky, basándome precisamente en esas diferencias. Read more

Análisis de un dispositivo USB con Wireshark – Parte 2

En la primera parte de esta serie de artículos sobre análisis de dispositivos USB con Wireshark, que podéis encontrar aquí, hicimos una primera aproximación a la investigación acerca del funcionamiento de un dispositivo USB. Si no recordáis cómo hacer una captura de tráfico con Wireshark de un USB, os recomiendo leer la primera parte de esta serie.

El primer artículo terminaba con una referencia a los conceptos que vamos a tratar aquí; clases, descriptores, interfaces, endpoints… Estos conceptos son fundamentales tenerlos claros para poder analizar y conocer cómo funcionan, y para ello seguiremos con nuestro análisis USB con Wireshark, cuando conectamos un dispositivo de este tipo a nuestro equipo.

En primer lugar tenemos que tener claro que existen muchos tipos de clases de USB, no solo aquellos con los que estamos más acostumbrados a trabajar, como pueden ser los dispositivos de almacenamiento, o los dispositivos de interfaz humana (HID, Human Interface Device).

Class: Una clase nos permite definer funcionalidades del dispositivo USB. Algunos ejemplos son:

  • Class 1 – Audio
  • Class 3 – HID (Human Interface Device)
  • Class 6 – Image
  • Class 7 – Printers
  • Class 8 – Mass Storage

Los pendrives que utilizamos para almacenar y transportar nuestros ficheros pertenecen a la clase 8 (Mass Storage), mientras que los ratones o teclados USB, pertenecen a la clase 3 (HID).

En las primeras capturas que realizamos con Wireshark ya pudimos observar en algunos de los paquetes cómo los dispositivos y el host utilizaban descriptores para solicitar e intercambiar información. Esta información, como su nombre indica, sirve para describir características y funcionalidades del dispositivo.

Wireshark - Descriptores USB

En la imagen anterior podemos observar en la columna Info que enter el host y el dispositivo (con dirección 7) se intercambian una serie de solicitudes y respuestas. El host solicita información que le describa el dispositivo, la configuración y otras cadenas con información de interés para que el host pueda proponer la configuración más idónea. Read more

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

Auditando Aplicaciones en Android

Vamos a ver algunos ejemplos de controles que se llevan a cabo en un Pentesting de Aplicaciones en Android. Lo más importante en un proceso de auditoría será el hacer uso de una metodología, de tal forma que podamos llevar a cabo una serie de pasos de manera ordenada.

Os propongo que hagamos uso de la metodología OWASP, concretamente en su apartado de OWASP Mobile Security Project podemos encontrarnos con muchos recursos: herramientas, guía de desarrollo seguro, plantilla de controles, guía de testing de Apps… Centrándonos en esta última podemos dividir nuestra auditoría en tres partes: recopilar información, análisis estático y análisis dinámico. Read more

Spyware en Android

En el día de hoy os traigo un artículo generado a raíz de una pequeña investigación que realicé al móvil android chino (chino, re-chino, vamos que ni la marca es pronunciable) de un familiar el cual, al utilizarlo yo mismo para realizar una llamada (hay que ahorrar xD), noté, por intuición más bien, que algo en el teléfono no andaba bien.

Llevo usando android hace bastante tiempo, “tuneando” ROMs en mis terminales, haciendole mods y otros “enrreos” así como en el último año, he estado más centrado en probar herramientas de pentesting de Android aunque no haya publicado ni expuesto nada sobre esto.

Bueno pues tras pelearme unos instantes con él detecté que ¡estaba roteado! A partir de ahí os podéis imaginar un poco que posibilidades se puede abrir en el caso de ser infectado por algún malware.

Por lo pronto detecté que, al desbloquearlo, siempre salía una pantallita con un anuncio. Oh Shit! Siempre. Desinstalé alguna APP de estas famosillas de programas de la TV y algún Widgets del tiempo un poco cutre pero el problema seguía. El teléfono mostraba publicidad.

androchina_logo

Read more