Tag Archive for wireshark

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

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

Introducción

¿Cuantas veces hemos conectado y desconectado un dispositivo USB de un ordenador? ¿Te has preguntado alguna vez qué ocurre en nuestro equipo cuando conectamos un pendrive, webcam o teclado USB? En este nuevo artículo vamos a hacer un análisis de un dispositivo USB con Wireshark, la herramienta por excelencia para la captura y análisis de tráfico.

¿Cuál es la motivación? Quizás la postura más cómoda sería obviar y asumir como simple magia el hecho de que conectemos un pendrive, y el sistema automáticamente lo reconozca, sepa el fabricante, producto, protocolo de comunicación, particiones que tiene y la capacidad de éstas. Pero los hackers van más allá, les gusta saber cómo funcionan las cosas. Además creemos firmemente en esta filosofía; Learn, Hack and Share. Aprende, hackea y comparte.

Nota: Si a estas alturas cuando decimos “hackea” lo entiendes como “comete un delito”, definitivamente, este no es tu blog.

Entorno de trabajo – Herramienta y comandos

¿Por qué Wireshark? ¿Por qué un sniffer? Porque precisamente vamos a analizar el tráfico que se genera entre nuestro dispositivo USB y el host, es decir, nuestro ordenador.  ¿Cómo sabe el host de qué tipo de USB se trata? ¿Trata igual a un pendrive que a un dispositivo HID (Human Interface Device)? Estas y otras cuestiones intentaremos resolverlas en este post y futuros posts.

Como sistema operativo, utilizaremos Linux. Y la razón es muy sencilla, este SO nos aporta muchísima más información a la hora de conectar o desconectar un USB, que por ejemplo Windows. Y aunque recientemente se ha publicado USBPcap para realizar esto mismo en Windows, Linux lleva ya años haciéndolo, por lo tanto nos centraremos en este SO.

Antes de empezar, una breve reseña histórica a las versiones y velocidades en USB, conceptos que nos vendrán bien más adelante durante nuestro análisis:

1996 – USB 1.0 – Velocidad 1,5 Mbps (Low Speed) y 12 Mbps (Full Speed)
1998 – USB 1.1 – Sin cambio en velocidades
2000 – USB 2.0 – Se añade velocidad 480 Mbps (High Speed)
2008 – USB 3.0 – Se añade velocidad 5 Gbps (Super Speed)

Es importante tener esto en cuenta a la hora de ver los controladores USB que tenemos en nuestro equipo, ya que por ejemplo, un controlador USB 3.0 incluye a su vez uno de 2.0, de ahí que pueda llevar a confusión por la duplicidad de buses de conexión. Esta información la podemos extraer en Linux con dos comando básicos del SO; lspci y lsusb.

lspci | grep USB

USB Forensic - lspci

En este caso podemos ver que tengo dos controladores, generados por VMWare (estoy trabajando con máquina virtual), uno de la versión 1.1 y otro de la versión 2.0. La abreviatura que aparece a continuación indica también el tipo de controlador:

UHCI – Universal Hub Controller Interface (1.0 / 1.1)
EHCI – Enhanced Hub Controller Interface (2.0)
XHCI – Extensible Hub Controller Interface (3.0)

Read more

Analizar malware con Anubis

En la última semana hemos recibido en nuestro laboratorio unos binarios provenientes de campañas de phishing y envío de malware, que hemos procedido a analizar de una forma muy práctica y bastante efectiva por el resultado de dicho análisis, que nos permite rápidamente extraer unas primeras contramedidas por si ha habido alguna infección. Vamos a analizar malware con Anubis.

El último de los ficheros lo hemos recibido esta misma mañana y es el que usaremos en este artículo.

Concretamente se trata de un fichero adjunto en este mensaje que “generosamente” Bobby nos envía y que se le había olvidado adjuntar en un correo anterior. Todo un detalle.

Analizar malware con Anubis

Un primer paso era analizar el fichero con el antivirus instalado en uno de los equipos usados como sandbox, con antivirus Avira actualizado hasta el día. En ese primer análisis no salió ninguna detección. Acto seguido, decidimos probar con los 57 motores de análisis de VirusTotal (donde pudimos comprobar que el motor de Avira no lo detectaba), obteniendo en un primer análisis sólo 7 detecciones de los 57 motores, y al cabo de 2 horas un resultado de 12 detecciones.

Analizar malware con Anubis

Aunque nuestro antivirus Avira no lo había detectado, gracias a VirusTotal pudimos comprobar que efectivamente se trata de malware, concretamente el troyano Trojan.Upatre.Gen.3.

Como desconocemos lo que este troyano es capaz de hacer, y queremos saber posibles contramedidas por si ha habido alguna infección, procedemos a subir el archivo a Anubis, donde además de un análisis del binario, lo desplegará y ejecutará en una máquina Windows propia, nos indicará las modificaciones en el sistema de ficheros, posibles entradas de registro y lo que es muy interesante también, nos facilitará una captura del tráfico generado por este malware tras su ejecución.

Analizar malware con Anubis

Como podemos ver en la imagen anterior, tras subir el fichero a Anubis y ser analizado, tenemos a nuestra disposición el informe del análisis en varios formatos, y en la parte inferior un enlace al fichero pcap resultante de la captura de tráfico realizada.

Veamos qué tiene ese fichero si lo abrimos con Wireshark:

Analizar malware con Anubis

Si filtramos los paquetes por tráfico http podemos ver algunas cosas interesantes. Por ejemplo que hace una petición a la IP 91.198.22.70. ¿Qué habrá en ese recurso?

Analizar malware con Anubis

¡Anda qué curioso! Es para saber desde qué IP pública nos hemos infectado. Sigamos. Podemos ver también varias peticiones para descarga de supuestos ficheros PDF, que seguro que no lo son y a su vez realizarán otro tipo de acciones maliciosas como descarga de otros binarios necesarios para lanzar su ataque, que tiene toda la pinta de CryptoLocker.

Como podéis ver, haciendo uso de servicios online totalmente gratuitos podemos de forma rápida y sencilla hacer un análisis del malware y sacar unas primeras conclusiones, y lo que es más importante, aplicar unas contramedidas que mitiguen o reduzcan el riesgo que esta amenaza pueda suponer para los sistemas de información de cualquier organización.

¿Contramedidas? Obviamente en primer lugar realizar un análisis de los posibles equipos infectados, concienciar al usuario de no abrir archivos adjuntos en correos de remitentes desconocidos y aplicar algunas reglas en la seguridad perimetral, por ejemplo, denegar el tráfico desde / hacia las direcciones IP observadas en la captura de tráfico. Se ha comprobado que están reportadas como servidores maliciosos.

Por cierto, en una de esas direcciones IP nos espera un bonito RouterOS de MikroTik. 😉

Analizar malware con AnubisComo siempre, espero que sea de vuestro interés, y nos leemos en siguientes artículos.

¡Saludos!

Parando Metasploit con Snort

Hoy vamos a ver como podemos detectar cualquier tipo de ataque a una aplicación vulnerable de nuestro servidor, simplemente analizando aquellos posibles exploit que puedan ser lanzados contra este y añadiendo una regla en nuestro IDS para detectarlos y pararlos, en nuestro caso utilizaremos Snort. El escenario sería el siguiente:

escenarioPC-Metasplit

La idea es identificar una característica única del exploit a detectar con el IDS y crear una regla con Snort para detectarlo. Para ello previamente lo que hacemos es lanzar el exploit para explotar la vulnerabilidad y capturar el tráfico para analizarlo.

meterpreter

En este momento tenemos que identificar una característica única/particular de este exploit. Debemos ser capaces de obtener la máxima información de como funciona el exploit, para ello podemos analizar el código del propio exploit así como examinar su documentación.

Exploit –> http://www.exploit-db.com/exploits/28681/

Concretamente hemos usado un exploit bajo metasploit para explotar el puerto 21 de un FreeFTPd con una vulnerabilidad que lleva a cabo un PASS Command Buffer Overflow, es decir, introducir una contraseña no esperada para provocar un desbordamiento de buffer. Lanzamos el exploit varias veces y obtenemos varios ficheros .pcap que nos disponemos a analizar exhaustivamente:

wireshark1

wireshark2

Una vez que somos capaces de sacar información que identifique al exploit unívocamente nos disponemos a generar una regla en Snort. Las reglas en Snort constan de dos partes: la cabecera y las opciones. El objetivo de este artículo no es explicar el funcionamiento de Snort, ni tampoco el de como crear una regla, para ello podéis consultar su manual en http://manual.snort.org/.

Si analizamos cada uno de los paquetes que lanza el exploit veremos que se están inyectando operaciones tipo NOPs (No-Operation, instrucciones que no hacen nada, como por ejemplo sumarle 0 a un registro) para rellenar instrucciones además del Payload inyectado. Esto se suele hacer por muchos tipos de malware para reconducir la ejecución del programa, caso de caer en una posición de memoria donde haya una NOP, se ejecutarán todas las instrucciones que no hacen nada hasta llegar al trozo de código malicioso que realmente quiere ejecutar el atacante. Vemos con Wireshark las NOPs y lo que realmente inyecta el Payload.

nops

user_pass

Con toda esta información ya podemos crear un regla en nuestro IDS Snort para detectar este exploit. A continuación mostramos la regla creada según las peculiaridades encontradas en el exploit:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;

Hemos visto que el exploit va dirigido al puerto 21, que hace uso del usuario anónimo y que introduce varios caracteres raros en la parte de la PASS, por tanto esas serán nuestras características concretas para nuestra regla.

Analicemos pues la parte de la cabecera:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21

Se aplicará la regla de eliminación de paquete (drop) a todos aquellos paquetes que vengan vía tcp desde una red exterior ($EXTERNAL_NET es una variable que identifica cualquier IP externa) desde cualquier puerto de comunicación en el origen (any); y cuya petición vaya destinada a una IP interna ($HOME_NET idem IP interna) sobre el puerto 21.

 Dentro de la parte de las opciones:

(msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;

En este apartado determinaremos que características tienen los paquetes que deben ser eliminados. Dejaremos constancia del bloqueo de paquetes en el log de Snort con el mensaje que aparece en msg.

El paquete debe ser una petición de usuario anónimo y que la clave contenga alguno de los datos contenidos en la expresión regular (pcre). Dicha expresión regular debe estar escrita en perl, podéis encontrar diferentes expresiones regulares y reglas en el fichero policy.rules de Snort. El resto de las opciones determinan la clase de paquete (classtype), el identificador de la regla local (sid) y revisión (rev); y por último añadimos la palabra nocase para indicar al motor de Snort que la aplicación de la regla no sea “case-sentitive“.

La regla se añadirá al final del fichero de configuración de snort (snort.conf). Una vez añadida se comprueba su funcionamiento con los .pcap capturados del ataque para ver si es efectiva en caso de producirse nuevo ataque.

snort -A fast -c /ruta/snort.conf –pcap-dir=”/ruta/pcaps/” -l .

-A modo de la alerta, rápida en este caso (fast)

-c fichero de reglas, en este caso el snort.conf que hace referencia a todos los ficheros de reglas de que se encuentra en la carpeta de snort (/rutaSnort/rules) y además contiene al final nuestra regla. Debe ponerse todo en una sola línea.

–pcap-dir indicamos la carpeta donde están los pcap para comprobar.

-l indicamos la carpeta de salida del log (se creará un fichero llamado alert)

Una vez comprobado el funcionamiento de las reglas con los pcaps que contienen la captura del exploit, obtenemos el siguiente resultado:

alert

 Vemos como además de nuestra regla, hay otras reglas dentro de snort que detectan el uso del usuario anonymous o el overflow en la PASS. Ahora sólo tendremos que coger un exploit de un 0day y analizarlo para crear una regla de Snort y que no afecte a nuestro servidor hasta que podamos parchear la vulnerabilidad en cuestión. También se suele analizar el tráfico que genera ciertos malware y crear reglas en función de las peticiones que realicen.

Bueno ahora sólo queda que os pongáis a jugar con algunos exploits y los analicéis para poder detectarlos.

Un handshake

@eduSatoe

“Si caminas solo andarás más rápido, si caminas acompañado llegarás más lejos”