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.

Bases de la investigación

Los dispositivos USB pueden tener varias configuraciones, y éstas a su vez pueden tener varios interfaces. Imaginaros una Webcam USB. Tendrá una configuración y un interfaz para la cámara, y tendrá otra configuración e interfaz para controlar la memoria flash donde almacenará las fotos y vídeos.

Un dispositivo HID como por ejemplo un teclado, dispone de varios interfaces (si se desconoce el concepto de interfaz de una USB, recomiendo leer los artículos anteriores de análisis de un dispositivo USB), concretamente son dos interfaces:

  • Boot Protocol
  • Report Mode

El primer de ellos es el que permite que podamos usar un teclado USB antes de que cargue el sistema operativo, por ejemplo para entrar y trabajar con la BIOS del ordenador. No requiere de la carga de un controlador ya que no hay sistema operativo cargado todavía para realizar esa tarea. Por lo tanto este modo de trabajar es muy simple.

Para trabajar con el teclado en un modo más complejo necesitamos el Report Mode, que precisamente es el que se utiliza cuando ya si tenemos un sistema operativo ejecutándose y el controlador del dispositivo cargado correctamente.

Por lo tanto, un teclado tendrá como mínimo dos interfaces; Boot Protocol y Report Mode.

Es más, si se trata de un teclado con un touchpad integrado, tendrá mínimo tres interfaces; las dos del propio teclado y una interfaz para el touchpad. Y así sucesivamente.

Y es aquí donde precisamente está la diferencia entre un teclado de verdad y un USB Rubber Ducky. Estos dispositivos, a diferencia de los teclados, utiliza una sola interfaz, la de Boot Protocol. Por lo tanto, si analizando un dispositivo USB, que supuestamente es un teclado, encontramos que solo dispone de una interfaz y que esta además es de tipo Boot Protocol, es muy probable que lo que hayamos conectado a nuestro equipo sea un “patito“.

Recursos utilizados

Toda mi investigación ha estado basada en GNU Linux, concretamente con una distribución Debian 8, aunque sería fácilmente extrapolar estos conceptos y aplicarlos a otros sistemas operativos como Windows.

Para el desarrollo de la herramienta “Patito Hunter” he utilizado el lenguaje de programación Python y una serie de librerías, donde caben destacar dos:

  • pyusb
  • pyudev

La primera de ellas me permite con Python interactuar con los dispositivos USB conectados al ordenador y consultar tipo de dispositivo ID Vendor, ID Product, etc. Y lo que es más importante, me permite consultar el número de interfaces y tipo de interfaces de un dispositivos, fundamental en la detección del “patito”.

La segunda de ellas, pyudev, me solucionaba un importante problema y era el de controlar cuándo se había conectado o desconectado un dispositivo USB al ordenador. Por lo tanto ya lo tenía todo para desarrollar esta simple herramienta.

¿Cuál es la idea? Muy simple, monitorizar continuamente cuándo se conecta un dispositivo USB. Cuando se conecte un dispositivo, descargar del kernel el controlador del dispositivo (para que no levante el dispositivo y pueda ejecutar nada), analizar su información, centrándome en la información de sus interfaces y en función del resultado dejar o no que el dispositivo se levante. Si se trata de un USB Rubber Ducky, se informa al usuario y el controlador no es recargado en el kernel del equipo.

Patito Hunter

Como uno de mis objetivos es, además de lo aprendido, compartirlo con vosotros, acabo de crear una cuenta en GitHub y un repositorio para “Patito Hunter”, que podéis encontrar aquí.

https://github.com/curiozity/patitohunter

El funcionamiento es bien sencillo, eso sí, necesitaréis hacerlo con permisos de root porque la librería pyudev así lo requiere para tener acceso al kernel (control de conexión y desconexión de dispositivos).

python patitohunter.py

Es la primera versión y hay muchas cosas que mejorar y optimizar (como por ejemplo multihilo para analizar varios dispositivos a la vez o comprobar número de pulsaciones del teclado — Gracias Goldrak –), pero creo que puede servir como buena aproximación a la defensa de este tipo de dispositivos.

Obviamente no es una bala de plata contra el USB Rubber Ducky, ya que a través de modificación de firmware se podría intentar alterar la información de las interfaces por ejemplo, pero al menos cubrimos uno de los objetivos más importantes de la seguridad defensiva, y es que si no puedo conseguir el 100% de seguridad, al menos ponérselo lo más difícil posible a los atacantes.

Para próximas versiones quiero incorporar una pequeña base de firmas de dispositivos USB para tener más información con la que comparar y añadir algunas características de comportamiento, para que no esté basado solo en firmas.

Por supuesto, estaré encantado de leer vuestras opiniones, críticas, sugerencias e ideas.

NOTA: Ojo, incluye la reproducción del “cuack cuack” de un pato en mp3 cuando conectáis un “patito“. Simplemente comentar las líneas si no queréis que se reproduzca 😉

¡Hasta pronto!

Miguel A. Arroyo
@miguel_arroyo76