Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
mellon — Herramienta de ataque OSDP (y la palabra élfica para amigo) | Kitploit
Herramientas/GitHubGitHub/bishopfox/mellon
Análisis de VulnerabilidadesExplotaciónCriptografíaPruebas de PenetraciónSeguridad de Hardware
GitHubbishopfox/mellon

mellon

Herramienta de ataque OSDP (y la palabra élfica para amigo)

Ver Repositorio
1149hace 3 añosRevisado por Kitploit

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

Vulnerabilidades de OSDP que esto explota

Herramienta de ataque OSDP (y la palabra élfica para amigo)

Ataque #1: El cifrado es opcional

OSDP admite, pero no exige estrictamente el cifrado. Por lo tanto, su conexión podría no estar cifrada en absoluto. El ataque #1 consiste simplemente en escuchar pasivamente y ver si se pueden leer los números de tarjeta en el cable.

Ataque #2: Ataque de degradación

El hecho de que el controlador y el lector admitan cifrado no significa que estén configurados para exigir su uso. Un atacante puede modificar el mensaje de respuesta de capacidad del lector (osdp_PDCAP) para anunciar que no admite cifrado. Cuando esto sucede, algunos controladores continúan sin cifrado.

Ataque #3: Ataque en modo de instalación

OSDP tiene un 'modo de instalación' cuasi oficial que se aplica tanto a lectores como a controladores. Como su nombre indica, se supone que se utiliza al configurar un lector por primera vez. Lo que hace es esencialmente permitir que los lectores pregunten al controlador cuál es la clave de cifrado base (el SCBK). Si el controlador está configurado para permanecer persistentemente en modo de instalación, entonces un atacante puede aparecer en el cable y solicitar el SCBK.

Ataque #4: Claves débiles

El código de muestra de OSDP a menudo viene con claves de cifrado hardcodeadas. Claramente están pensadas como ejemplos, donde se supone que el usuario genere claves de forma segura por su cuenta. Pero esto no se explica ni se simplifica para el usuario. Y cualquiera que haya estado en seguridad el tiempo suficiente sabe que lo que sea por defecto probablemente esté presente en producción. Así que como vector de ataque, cuando el enlace entre el lector y el controlador está cifrado, vale la pena intentar enumerar algunas claves débiles comunes. Estas son claves AES de 128 bits, por lo que no podremos enumerarlas todas. Ni siquiera una porción significativa de ellas. Pero lo que podemos hacer es atacar algunos patrones comunes que se ven cuando alguien hardcodea una clave:

  • Todos los valores de un solo byte. [0x04, 0x04, 0x04, 0x04 …]
  • Todos los valores de byte monótonamente crecientes. [0x01, 0x02, 0x03, 0x04, …]
  • Todos los valores de byte monótonamente decrecientes. [0x0A, 0x09, 0x08, 0x07, …]

Ataque #5: Captura de conjunto de claves

OSDP no tiene un mecanismo dentro de la banda para el intercambio de claves. Lo que esto significa es que un atacante puede:

  • Insertar un dispositivo de escucha encubierto en el cable.
  • Romper / restablecer de fábrica / deshabilitar el lector.
  • Esperar a que alguien de TI venga y reemplace el lector.
  • Capturar el mensaje de conjunto de claves (osdp_KEYSET) cuando el lector se configura por primera vez.
  • Descifrar todos los mensajes futuros.

Configuración de un banco de pruebas (Linux/MacOS)

Encontrarás código de prueba de concepto para cada uno de estos ataques en attack_osdp.py. Consulta el comando --help para obtener más detalles sobre el uso. Este es un script de Python, diseñado para ejecutarse desde una laptop con adaptadores USB<-->RS485 como estos. Así que probablemente quieras conseguir algunos de esos. No tiene que ser ese modelo, sin embargo.

Si tienes un controlador que quieras probar, genial. Úsalo. Si no, tenemos un controlador OSDP intencionalmente vulnerable que puedes usar aquí: vulnserver.py.

Algunos de los ataques en attack_osdp.py esperarán estar como un MitM completo entre un lector y un controlador funcionales. Para probarlos, es posible que necesites tres adaptadores USB<-->RS485, conectados con una placa de pruebas.

Problemas de riesgo medio/bajo adicionales

Estos problemas no son explotables de forma aislada, pero sin embargo representan un debilitamiento del protocolo, la implementación o el sistema en general.

  • Los MAC se truncan a 32 bits "para reducir la sobrecarga". Esto está muy cerca (aunque no exactamente en nuestro cálculo) del rango práctico explotable.
  • Los IV (que se derivan de los MAC) se reducen de manera similar a 32 bits de entropía. Esto causará reutilización de IV, lo cual es una gran señal de alerta para un protocolo.
  • Las claves de sesión se generan utilizando solo 48 bits de entropía del nonce RNG del controlador. Sin embargo, parece que un atacante observador no podría enumerarlas fuera de línea. (A menos que nos falte algo, en cuyo caso esto se convertiría en un problema crítico.)
  • Los números de secuencia consisten solo en 2 bits, sin proporcionar suficiente actualidad.
  • Se utiliza cifrado en modo CBC. GCM sería un modo de cifrado de bloque más moderno y adecuado para protocolos de red.
  • Los modos SCS 15 y 16 son esencialmente "cifrados nulos" y no deberían existir. No cifran datos.
  • El byte de comando de OSDP siempre está sin cifrar, incluso en medio de una sesión de Canal Seguro. Esto es una gran ventaja para los atacantes, haciendo que las herramientas de ataque sean mucho más fáciles de escribir. Significa que un atacante siempre puede ver qué "tipo" de paquete se está enviando, aunque esté cifrado de otro modo. Los atacantes pueden saber cuándo las personas pasan su tarjeta, cuándo se enciende el LED, etc... Esta no es información que debería estar en texto plano.
  • SCBK-D (una clave de cifrado "por defecto" hardcodeada) no proporciona seguridad y debería eliminarse. Solo sirve para ofuscar y proporcionar una falsa sensación de seguridad.
Descargar herramienta