Imagen: Sascha Kohlmann , CC BY-SA 2.0Hay sistemas a los que los simples mortales no tienen acceso por defecto. Y los desarrolladores de tales sistemas creen ingenuamente que están protegidos de la penetración y los ojos agudos de los investigadores.
Tome al menos cajeros automáticos (ATM). Hay casos frecuentes cuando personas desconocidas acuden al cajero automático, conectan una computadora portátil, toman dinero y se van sin dejar ningún registro en el sistema. Y las historias recientes con "
chuletas " (malware llamado
Cutlet Maker ) confirman que no hay sistemas invulnerables, hay sistemas poco explorados.
Inicio del estudio
Existe la opinión de que la única forma de robar dinero de un cajero automático es conducir en un camión volquete, levantar un gancho del cajero automático y arrancarlo, y luego usar una amoladora, una palanca y una máquina de soldadura de gas. Pero hay otro método.
Después de una breve búsqueda en
Ebay , tenía un
dispensador NCR USB S1 con un firmware en mi escritorio. Los objetivos fueron los siguientes:
- encuentre un bypass para encriptar los comandos que la computadora envía a través del USB al dispensador, en particular para emitir billetes;
- Aprenda cómo evitar la necesidad de acceso físico a la caja fuerte para autenticación (intercambio de cassettes) para generar claves de cifrado para los comandos del párrafo anterior.
Firmware
El firmware es un archivo
ELF para el
procesador NXP ColdFire (
Motorola 68040 , mi procesador favorito), que se ejecuta en
VxWorks v5.5.1 .
En el archivo
ELF , dos secciones principales son de interés:
.text y
.data :
- Uno de ellos contiene un código que gira todo el tiempo (llamémoslo firmware principal) cuando el dispensador está conectado a la unidad del sistema en la parte superior del cajero automático.
- El segundo es el código del cargador de arranque empaquetado con zlib (su nombre local es USB Secure Bootloader ), que es responsable de cargar el firmware y lanzar el código principal.
Y la mejor parte es que los símbolos permanecen sin cortar en el archivo: tómalo y busca algo interesante.
Dispositivo interno del firmware principal
Si divide el código en componentes principales, obtendrá el siguiente esquema (en el orden de envío):
- Una transmisión que se ocupa de recibir paquetes USB y distribuirlos entre los servicios.
- Los servicios son las principales unidades ejecutoras, cada uno de ellos tiene su propio rol y cada uno tiene sus propias tareas (clases).
- Clases : aquí se trata de tareas que un servicio en particular puede realizar con la ayuda de los controladores.
- Los controladores son en realidad " trabajadores " ( trabajadores ) que participan en la validación de las tareas que se les envían, su implementación, así como la formación de paquetes de respuesta.
Como hay mucho código en el firmware, se decidió comenzar buscando todos los servicios posibles y luego buscar dónde se transfieren las tareas.
Como resultado, se encontraron los siguientes servicios que deberían hacer lo que estoy buscando:
1)
DispTranService (Dispenser Transaction Service) : funciona con comandos cifrados, la formación de paquetes de billetes, autenticación. Puedes decir que lo más interesante está aquí.
2)
securityService : después de la autenticación, se genera una clave de sesión en el lado del dispensador, que, a solicitud de la computadora, se le envía en forma cifrada. Esta clave cifrará todos los comandos importantes, emitiendo, formando un paquete de billetes.
Posteriormente, otro servicio me llamó la atención:
UsbDownloadService . Su tarea es, cuando el dispensador está conectado a la computadora y la versión del firmware del dispensador no coincide con la almacenada en la computadora del cajero automático, cambiar al
gestor de
arranque para cargar el firmware con el que debería funcionar el sistema operativo (se encuentra en la carpeta con el software del proveedor en la computadora). Este servicio también sabe cómo proporcionar información sobre la versión de firmware.
Autenticación física
La autenticación física se implementa al más alto nivel y protege al cajero automático de simplemente enviar comandos a través de USB para emitir sin autorización. En este caso, consiste en el hecho de que solo con una caja fuerte abierta con dinero debe hacer uno de los siguientes:
- retire e inserte el cassette inferior,
- cambie el interruptor de palanca en la parte posterior del estante con el dispensador.
Pero todo esto es necesario solo si el nivel de acceso se establece al máximo, es decir, físico. Hay tres de ellos:
USB (0),
lógico (1) y
físico (2). Los proveedores de servicios y desarrolladores utilizan los dos restantes para depurar y probar el firmware. Bueno, el proveedor recomienda encarecidamente el físico para su uso predeterminado.
Vulnerabilidad
A continuación se describe la vulnerabilidad crítica (ya arreglada por el proveedor al momento de la publicación del artículo), que hizo posible ejecutar cualquier comando del dispensador, incluido el retiro de efectivo, si había acceso al área de servicio, pero sin acceso a la caja fuerte (por ejemplo, a través del orificio hecho en el panel frontal del cajero automático).
Al final resultó que,
UsbDownloadService acepta comandos que no requieren cifrado. Suena tentador Pero, de repente, todo está más protegido, y el nombre
Secure Bootloader dará sus frutos.
(Spoiler: no justificado!)Necesitamos profundizar
Como ya se mencionó, en la sección
.data hay un código de cargador empaquetado, que durante mucho tiempo no me interesó, y mis colegas no le prestaron atención cuando examinaron el firmware.
Si bien el gestor de arranque era un misterio, la pregunta seguía abierta: ¿cómo el software de la computadora inunda el firmware? De hecho, en el firmware principal, no se encontró nada por el estilo.
Entonces, el
gestor de arranque está desempaquetado, cargado en la
IDA en el desplazamiento
0x100000 - ahora puedes investigar ... ¡Solo que no hay caracteres!
No importa: comparar el firmware principal con el código del gestor de arranque, leer la hoja de datos del controlador, y una cierta imagen comienza a surgir.
Resultó que cargar el firmware, aunque parece protegido, no es realmente así. Todo lo que necesita saber es cómo completarlo correctamente.
Se dedicó mucho esfuerzo y tiempo a una comprensión completa de este proceso (para más detalles, vea el informe "
Blackbox está muerto - ¡Viva Blackbox! " En la conferencia Black Hat 2018 en Las Vegas). ¿Por qué vale la pena soldar la memoria NVRAM, cargando una copia de seguridad con el objetivo de "raspar" todo el controlador ...
Gracias al colega Alexei por su paciencia!
Como resultado, obtuvimos el siguiente algoritmo para cargar firmware al dispensador:
1) Genere un par de claves RSA y complete la clave pública en el controlador.
2) Escriba secuencialmente
.data y
.text secciones de
ELF a sus direcciones físicas desde los encabezados de sección.
3) Calcule SHA-1 a partir de los datos grabados, cifre el hash con una clave privada y envíelo al controlador.
4) Calcular y enviar la suma de todas las palabras grabadas del firmware.
Después de lo cual, si todo se cuenta y registra con éxito, se cargará el firmware principal.
Resultó que al escribir el firmware solo hay una limitación: la versión del firmware no debe ser inferior a la actual. Pero nadie nos impide cambiar la versión del firmware en sus propios datos.
Como resultado, mi firmware especial con correcciones de
seguridad se cargó y se lanzó con éxito.
En este punto, el código de firmware principal estaba bien estudiado, se encontraron comandos para emitir billetes. Ahora se pueden enviar sin cifrar, y el dispensador los ejecutará con gusto.
Problema
Después de todo lo experimentado durante el estudio (por ejemplo, un cajero automático real "
tapiado "), el resultado fue tan agradable y compensó los esfuerzos que quise repetir el algoritmo con otro gran vendedor.
El cajero automático más real comenzó a zumbar de manera tensa y ansiosamente compartido con nosotros billetes crujientes frescos (en este caso, "envoltorios de caramelos" del vendedor). No se aplicó magia: solo una computadora portátil, un cerebro y un cable USB.
Conclusiones
Una vez más, estábamos convencidos de que, guiados por el principio de
seguridad a través de la oscuridad , es imposible proporcionar una protección adecuada. La propiedad del código o firmware no significa en absoluto que en un punto fino un atacante no tendrá acceso a él y no aprovechará las vulnerabilidades encontradas. Todo lo necesario para la implementación de objetivos egoístas se puede adquirir en presencia de una cierta cantidad de dinero.
Los desarrolladores deben manejar el código y los guardias de seguridad deben protegerlo. Es por eso que el enfoque más productivo parece ser la cooperación con compañías de seguridad de la información con suficiente experiencia para garantizar la seguridad de varios sistemas que ayudarán a construir una protección adecuada en cada caso.
PS Vendor confirmó la vulnerabilidad (también se encontró una brecha en otro modelo:
S2 ), que se declaró corregido en la corrección de febrero de 2018.
Lista de CVE:
Agradecimientos
Antes que yo, mis colegas,
Dima Sklyarov y
Misha Tsvetkov , ya habían trabajado en firmware (aunque sin una placa dispensadora). Sus logros me ayudaron mucho en el estudio, por lo que muchas gracias a ellos. En cuanto al hardware,
Aleksei Stennikov me ayudó mucho.