Saludos a todos. Comenzaré con la historia de fondo que me llevó a realizar esta investigación, pero antes advertiré: todas las acciones prácticas se llevaron a cabo con el consentimiento de las estructuras de gestión. Cualquier intento de utilizar este material para infiltrarse en un área restringida sin el derecho a estar allí es un delito penal.
Todo comenzó cuando, al limpiar el escritorio, accidentalmente coloqué la llave RFID de la entrada sobre el lector NFC ACR122; mi sorpresa fue grande cuando Windows reprodujo el sonido de detección de un nuevo dispositivo y el LED se encendió en verde. Hasta ese momento, pensaba que estas llaves solo funcionaban con el estándar Proximity.
Pero si el lector lo detectó, significa que la llave responde a uno de los protocolos sobre el estándar ISO 14443 (también conocido como Near Field Communication, 13.56 MHz). Olvidé por completo la limpieza, ya que vi la oportunidad de deshacerme completamente del llavero y guardar la llave de la entrada en el teléfono (el apartamento ya estaba equipado con una cerradura electrónica). Sumergido en el estudio, descubrí que bajo el plástico se escondía una etiqueta NFC Mifare 1k, el mismo modelo que se usa en los pases de identificación de empresas, tarjetas de transporte, etc. Las primeras intentos de acceder al contenido de los sectores no tuvieron éxito, y cuando finalmente logré hackear la llave, descubrí que solo se utiliza el sector 3, y en él se duplicaba el UID del propio chip. Todo parecía demasiado sencillo, y resultó ser así; no habría artículo si todo hubiera salido tal como estaba planeado. Entonces, tenía los entresijos de la llave, y no había problemas para copiar la llave en otra igual. Pero la tarea era trasladar la llave a un dispositivo móvil, en lo que ocupé mi tiempo. Aquí es donde comenzó la diversión: tengo un teléfono — iPhone SE con la iOS 13.4.5 Beta build 17F5044d y algunos componentes personalizados para el funcionamiento libre de NFC; no me detendré en esto por ciertas razones objetivas. Si se desea, todo lo que se dice a continuación es aplicable también para el sistema Android, pero con algunas simplificaciones.
Lista de tareas a resolver:
- Acceder al contenido de la llave.
- Implementar la capacidad de emular la llave con el dispositivo.
Si al principio todo fue relativamente sencillo, con el segundo surgieron problemas. La primera versión del emulador no funcionó. El problema fue detectado bastante rápido: en los dispositivos móviles (tanto iOS como Android) en modo emulación, el UID es dinámico y, independientemente de lo que esté configurado en la imagen, varía. La segunda versión (que se ejecutaba con privilegios de superusuario) fijaba de forma rígida el número de serie en el seleccionado — la puerta se abría. Sin embargo, quería hacerlo todo a la perfección, y al final ensamblé una versión final del emulador que podía abrir volcado Mifare y emularlos. Impulsado por un impulso repentino, cambié las claves de sectores a aleatorias y traté de abrir la puerta. Y ella… ¡SE ABRIÓ! Después de un tiempo entendí que se abren cualquier puerta con esta cerradura, incluso aquellas para las que la clave original no era válida. Por ello, formulé una nueva lista de tareas a realizar:
- Determinar qué controlador es responsable de la gestión de las claves.
- Entender si hay conexión a la red y una base de datos común.
- Descubrir por qué una clave que es prácticamente ilegible se convierte en universal.
Después de hablar con el ingeniero de la empresa de gestión, supe que se utilizan controladores simples Iron Logic z5r sin conexión a una red externa.
Lector CP-Z2 MF y controlador IronLogic z5r.
Me proporcionaron un conjunto de equipos para experimentar:
Como se entiende aquí, el sistema es completamente autónomo y extremadamente primitivo. Al principio pensé que el controlador estaba en modo de aprendizaje — la idea es que lee la clave, la almacena en su memoria y abre la puerta — este modo se utiliza cuando es necesario grabar todas las claves, por ejemplo, al cambiar la cerradura en un edificio de apartamentos. Pero esta teoría no se confirmó: este modo está programáticamente desactivado, el puente está en posición de trabajo — y, sin embargo, al acercar el dispositivo, vemos lo siguiente:
Captura de pantalla del proceso de emulación en el dispositivo.
… y el controlador signaliza que se ha concedido acceso.
Entonces, el problema radica en el software del controlador o del lector. Vamos a comprobar el lector — funciona en modo iButton, así que conectaremos la placa de seguridad Bolid — tendremos la oportunidad de observar los datos de salida del lector.
La placa, más tarde se conectará a través de RS232.
A través del método de múltiples pruebas, descubrimos que el lector transmite el mismo código en caso de fallar la autorización: 1219191919
La situación comienza a aclararse, sin embargo, en este momento no entiendo por qué el controlador responde positivamente a este código. Hay una suposición: que cuando llenaron la base, accidental o intencionadamente, acercaron una tarjeta con otras claves de sector; el lector envió este código y el controlador lo guardó. Desafortunadamente, no dispongo del programador original de IronLogic para revisar la base de claves del controlador, pero espero haber logrado llamar la atención sobre el hecho de que existe un problema. Se encuentra disponible una demostración en vídeo de cómo funciona esta vulnerabilidad. .
P.D. La teoría del añadido accidental se ve contradicha por el hecho de que en un centro de negocios de Krasnoyarsk también logré abrir la puerta usando el mismo método.
Fuente: habr.com
