Buen día a todos. Comenzaré con los antecedentes de lo que me impulsó a realizar esta investigación, pero primero les advertiré: todas las acciones prácticas se llevaron a cabo con el consentimiento de las estructuras de gobierno. Cualquier intento de utilizar este material para ingresar a un área restringida sin el derecho a estar allí constituye un delito penal.
Todo comenzó cuando, mientras limpiaba la mesa, coloqué accidentalmente la llave de entrada RFID en el lector NFC ACR122; imaginen mi sorpresa cuando Windows reprodujo el sonido de detección de un nuevo dispositivo y el LED se puso verde. Hasta este momento creía que estas claves funcionan exclusivamente en el estándar Proximity.
Pero como el lector lo vio, significa que la clave cumple con uno de los protocolos además del estándar ISO 14443 (también conocido como Near Field Communication, 13,56 MHz). Inmediatamente me olvidé de la limpieza, ya que vi la oportunidad de deshacerme por completo del juego de llaves y guardar la llave de la entrada en mi teléfono (el apartamento lleva mucho tiempo equipado con una cerradura electrónica). Después de empezar a estudiar, descubrí que debajo del plástico se esconde una etiqueta NFC Mifare 1k, el mismo modelo que en las tarjetas de empresa, tarjetas de transporte, etc. Los intentos de acceder al contenido de los sectores al principio no tuvieron éxito, y cuando finalmente se descifró la clave, resultó que solo se usaba el tercer sector y en él estaba duplicado el UID del chip. Parecía demasiado simple y resultó serlo, y no habría ningún artículo si todo saliera exactamente según lo planeado. Así que recibí las menudencias de la llave y no hay problemas si necesitas copiar la llave a otra del mismo tipo. Pero la tarea consistía en transferir la clave a un dispositivo móvil, que fue lo que hice. Aquí empezó la diversión: tenemos un teléfono. iPhone SE con instalado iOS 13.4.5 versión beta 17F5044d y algunos componentes personalizados para el funcionamiento gratuito de NFC; no me detendré en esto en detalle por algunas razones objetivas. Si lo deseas, todo lo dicho a continuación también se aplica al sistema Android, pero con algunas simplificaciones.
Lista de tareas a resolver:
- Accede al contenido de la clave.
- Implementar la capacidad de emular una clave por parte del dispositivo.
Si con el primero todo fue relativamente sencillo, entonces con el segundo hubo problemas. La primera versión del emulador no funcionó. El problema se descubrió bastante rápido: en los dispositivos móviles (ya sea iOS o Android) en modo de emulación, el UID es dinámico y, independientemente de lo que esté cableado en la imagen, flota. La segunda versión (ejecutada con derechos de superusuario) fijó rígidamente el número de serie en el seleccionado: la puerta se abrió. Sin embargo, quería hacer todo a la perfección y terminé armando una versión completa del emulador que podía abrir volcados de Mifare y emularlos. Cediendo a un impulso repentino, cambié las llaves del sector por otras arbitrarias e intenté abrir la puerta. Y ella… ¡ABRIÓ! Después de un rato me di cuenta de que estaban abriendo cualquier puertas con esta cerradura, incluso aquellas en las que no encajaba la llave original. En este sentido, creé una nueva lista de tareas a completar:
- Descubra qué tipo de controlador es responsable de trabajar con las claves
- Comprender si existe una conexión de red y una base común.
- Descubra por qué una clave prácticamente ilegible se vuelve universal
Después de hablar con un ingeniero de la empresa gestora, descubrí que los controladores Iron Logic z5r simples se utilizan sin conectarse a una red externa.
Lector CP-Z2 MF y controlador IronLogic z5r
Me entregaron un conjunto de equipos para los experimentos:
Como se desprende de aquí, el sistema es completamente autónomo y extremadamente primitivo. Al principio pensé que el controlador estaba en modo de aprendizaje - lo que significa que lee la llave, la almacena en la memoria y abre la puerta - este modo se usa cuando es necesario registrar todas las llaves, por ejemplo, al reemplazar la encerrar en un edificio de apartamentos. Pero esta teoría no fue confirmada: este modo está desactivado en el software, el puente está en la posición de trabajo y, sin embargo, cuando levantamos el dispositivo, vemos lo siguiente:
Captura de pantalla del proceso de emulación en el dispositivo.
... y el responsable del tratamiento indica que se ha concedido el acceso.
Esto significa que el problema radica en el software del controlador o del lector. Comprobemos el lector: funciona en modo iButton, así que conectemos la placa de seguridad Bolid; podremos ver los datos de salida del lector.
La placa se conectará posteriormente mediante RS232.
Utilizando el método de pruebas múltiples, descubrimos que el lector transmite el mismo código en caso de falla de autorización: 1219191919
La situación empieza a aclararse, pero por el momento no me queda claro por qué el controlador responde positivamente a este código. Se supone que cuando se llenó la base de datos (por accidente o intencionalmente se presentó una tarjeta con otras claves de sector), el lector envió este código y el controlador lo guardó. Desafortunadamente, no tengo un programador propietario de IronLogic para examinar la base de datos de claves del controlador, pero espero haber podido llamar la atención sobre el hecho de que el problema existe. Hay disponible un vídeo de demostración sobre cómo trabajar con esta vulnerabilidad. .
PD: A la teoría de la suma aleatoria se opone el hecho de que en un centro de negocios en Krasnoyarsk también logré abrir la puerta con el mismo método.
Fuente: habr.com