Obtienen una shell root en una terminal de tarjetas de crédito
(stefan-gloor.ch)- Se intentó hacer ingeniería inversa de la terminal de tarjetas de crédito Worldline Yomani XR con fines de investigación de seguridad
- Durante el desensamblaje interno, se descubrió que, aunque la función de detección de intrusión física está bien implementada, existe un problema de software: una shell root queda expuesta en un puerto serial externo
- Mediante volcado de memoria, extracción y análisis del firmware, se confirmó una arquitectura basada en un sistema con kernel Linux 3.6 y componentes muy antiguos
- Se demostró que, a través del puerto de consola serial, es posible obtener privilegios de root e instalar malware fácilmente sin desarmar el dispositivo
- Todas las tareas críticas relacionadas con pagos y autenticación se realizan en un procesador de seguridad independiente, por lo que el riesgo real de exposición de datos sensibles no es alto
Resumen del proyecto
- Este proyecto se centra en el proceso de análisis inverso del modelo Worldline Yomani XR con fines de investigación de seguridad de una terminal de pago
- Este modelo, ampliamente usado en toda Suiza, está descontinuado actualmente, pero todavía sigue en uso en varias grandes tiendas y pequeños comercios
Primeras observaciones y desmontaje del hardware
- Después de una investigación básica como exploración de la UI y escaneo de puertos, se inició el desmontaje del hardware
- Se observó una seguridad de hardware considerable, incluyendo varias PCB, una carcasa bien construida con buenos materiales y un procesador Arm de doble núcleo basado en un ASIC personalizado
- El SoC principal es un ASIC dedicado con nombre en clave Samoa II, con memoria flash y RAM externas
Detección de intrusión y protección contra manipulación
- Incluso sin abrir la carcasa, se detectan eventos de intrusión con solo una falla en la conexión de placa por presión (Zebra strip) o al aflojar tornillos
- La detección se mantiene incluso en situaciones de corte de energía gracias a la batería
- En la PCB principal, las trazas en zigzag y la PCB flexible que envuelve el lector de tarjetas permiten detectar intrusiones si se dañan
- Tras un desmontaje breve y reensamblaje, debido a la detección de intrusión, el dispositivo solo muestra una pantalla roja con "TAMPER DETECTED" y no responde a entradas externas
Extracción de firmware mediante chip-off
- Se desoldó la flash integrada y se extrajo el firmware conectándola directamente
- Los datos no estaban cifrados, pero se identificó una estructura ECC particular y la disposición de metadatos del sistema de archivos YAFFS2
- Se implementó un lector del sistema de archivos para obtener la lista completa de archivos
- El sistema usa un kernel 3.6 basado en Buildroot versión 2010, además de uClibc, busybox y muchas bibliotecas antiguas
Cómo se encontró accidentalmente la shell root
- Tras analizar el firmware, se volvió a conectar la flash y se localizaron las líneas de la consola serial, capturando la señal con un analizador lógico
- Junto con el log de arranque, quedó expuesto un prompt de inicio de sesión
- Al escribir "root", era posible entrar de inmediato a una shell root sin contraseña
- De hecho, a este puerto serial se puede acceder directamente desde el exterior con solo abrir la tapa
- Un atacante puede conectarse rápidamente e inyectar malware sin desarmar la terminal
¿Qué tan grave es el problema?
- El análisis del arranque y la configuración del sistema mostró que Linux solo se encarga de la red, las actualizaciones y parte de la lógica de negocio
- Todas las funciones relacionadas con la seguridad, como pagos con tarjeta, ingreso de PIN y pantalla, son gestionadas por un procesador mp1 independiente
- Linux (mp2) siempre arranca, y luego una imagen firmada y cifrada es cargada al núcleo seguro por el bootloader seguro
- Internamente, la protección del núcleo seguro funciona correctamente, y los datos críticos de seguridad no se filtran por la exposición de la shell root
Cronograma de divulgación y reporte
- 14 de noviembre de 2024: descubrimiento de la shell root
- 15 de noviembre de 2024: notificación al fabricante junto con un aviso de divulgación a 90 días
- 18 de noviembre de 2024: respuesta del fabricante confirmando la recepción del reporte
- 1 de junio de 2025: publicación del proyecto
Conclusión
- La exposición de una shell root a través de un puerto serial externo es claramente una superficie de ataque innecesaria y un error de ingeniería
- Aun así, gracias al diseño con procesador de seguridad separado, el riesgo real de exposición de información de pago es bajo
- Es posible que el inicio de sesión root se haya habilitado por error en el firmware de producción, o que varíe según la versión
- Durante la investigación también se encontraron algunos dispositivos en los que la función de inicio de sesión root estaba completamente deshabilitada
- Es posible que internamente este problema ya haya sido reconocido y corregido
Este proyecto dejó varios resultados interesantes y volvió a mostrar el valor de explorar el firmware en profundidad
1 comentarios
Comentarios en Hacker News
Un comentario para los desarrolladores jóvenes: esto es precisamente lo que significa el “hacker” de “Hacker News”. Recomiendan este post como un ejemplo clásico de una travesía hacker, desglosada paso a paso de forma fácil de seguir. Si quieres ver casos parecidos, Hack-a-day vale la pena. También opinan que la persona autora parece muy curiosa y con bases técnicas muy sólidas. En esencia, fue una combinación de investigar datasheets del chip, desoldar sin dañar, volver a cablear si se trata de memoria, improvisación y prueba y error. Como consejo para la próxima, sugieren considerar una cámara pinhole al perforar orificios poco profundos para evitar rastros de manipulación. También comentan que habría sido realmente interesante si el autor además hubiera logrado saltarse las comprobaciones anti-manipulación y hacer que siguiera funcionando normalmente.
Explican que el término hacker no se limita a la seguridad informática, sino que tiene un significado mucho más amplio y una definición casi filosófica. Citan el Jargon File recopilado por Guy Steele y otros para presentar varias definiciones de hacker, como “alguien que disfruta aprender los detalles de los sistemas de programación y ampliar sus límites”, “alguien que disfruta programar con entusiasmo”, e incluso “un experto hábil en un programa en particular”. Resumen que el término se usa con varios sentidos, y especulan que probablemente PG, fundador de Hacker News, eligió el nombre pensando en esa definición amplia. Añaden que en la historia del vocabulario hacker también hay que mencionar The UNIX-HATERS Handbook.
Totalmente de acuerdo con la primera frase: si sale otro wrapper de LLM más hoy, ya sería demasiado.
Opinan que, aunque este sitio venga de una incubadora de startups de VC, no necesariamente debe interpretarse en el sentido de hacking de seguridad. Más bien, creen que se acerca a la idea startup de “move fast and break things”: hackear en el sentido de avanzar rápido, sacar código a toda velocidad y abrirse paso entre los problemas.
Alguien comenta que pasó mucho tiempo solo leyendo y recién hace poco creó una cuenta para empezar a comentar, y que publicaciones como esta, llenas de información y ejecución práctica, son justamente las que representan el espíritu “hacker” de Hacker News.
Otra persona confiesa que le dio upvote al post por primera vez porque esta vez sí trataba de hacking de verdad. Normalmente solo vota comentarios, pero aquí hizo una excepción.
Presentan que con un lector USB de tarjetas de $2 es posible simular transacciones falsas de crédito/débito. Explican que todas las especificaciones y protocolos son enormes, pero públicos, así que en teoría basta con leer la documentación para implementarlo. Sin embargo, advierten que para lograr que una transacción real sea aprobada hay que enviar datos al banco por internet, y que hacerlo probablemente haría que las autoridades, por ejemplo el FBI, aparecieran enseguida. Añaden que el lector de tarjetas en sí casi no tiene protecciones —la mayoría usa Linux y contraseñas débiles—, y que la seguridad proviene más bien de los contratos y regulaciones entre el comercio y el banco.
Rebaten la afirmación de que el lector de tarjetas “no tiene protecciones”. Dicen que en realidad solo puede ejecutar binarios firmados, que el sistema de archivos ejecutable es de solo lectura, que el sistema de archivos de datos tiene la bandera
noexec, que el login de root está desactivado, quebusyboxviene recortado, que las llaves se cargan desde un área segura durante el arranque, que la inserción de la master key solo es posible en fábrica, que el propio proceso de boot es muy seguro y que, si se detecta manipulación, el chip se borra a sí mismo. Admiten que los terminales baratos y no certificados pueden tener muy poca seguridad, pero comparten que, por su experiencia desarrollando EMV, los terminales reales vienen prácticamente cerrados por completo.Reconocen que sí es correcto decir que la “única seguridad” son las regulaciones entre el comercio y el banco. Por eso consideran que las teorías conspirativas sobre gente robando dinero de tarjetas contactless con lectores portátiles son difíciles de llevar a la práctica. Incluso si alguien logra generar una transacción, sacar el dinero de forma segura es casi imposible por los pasos previos y posteriores necesarios. Además, especulan que hoy en día las notificaciones push de transacciones hacen todavía más probable que cualquier intento delictivo quede expuesto.
Les preocupa más el escenario en que el lector sea hackeado en sitio para leer información de CC en caché o para instalar malware de intercepción, y opinan que por eso este tipo de investigación es importante.
Explican que no es cierto que la transacción tenga que enviarse al banco por internet para ser aprobada, y señalan que los bancos no tienen una Open API en internet para procesar transacciones de tarjeta.
Tampoco están de acuerdo con la idea de que la seguridad del lector sea débil, y explican que los terminales de comercio incluyen hardware seguro para almacenar las claves del banco y de la red de pagos. Añaden que, si esas llaves se filtraran, sería posible falsificar transacciones legítimas.
Alguien cuenta que compró 36 lectores Stripe M2 y 7 fallaron: 2 ya no cargan batería, 1 no puede escanear NFC y 4 murieron mostrando error de “manipulado”. A simple vista la tasa de fallas parece gravísima, pero comentan que también hay que considerar el contexto, como los días de uso y la antigüedad. Lo que más les molesta es que, aun habiéndose usado solo 9 días en total y teniendo entre 1 y 3 años de edad, aun así fallaron 7. Aclaran que durante el transporte los cuidan rigurosamente, cada uno con estuche rígido y foam insert, así que no parece ser un problema de almacenamiento. Aun así, explican que el Stripe M2 sigue siendo la opción más usable, así que no les queda otra que seguir con él. Como contexto adicional, su empresa procesa pagos en festivales, por lo que usan grandes cantidades durante períodos cortos.
Alguien imagina que, si la protección anti-manipulación física se activa, quizá podría abrirse un root shell: o bien el sistema entra a un modo seguro con todas las claves criptográficas necesarias, o bien expone un root shell para depuración/análisis de fallas. Eso sí, esperan que en ese momento las claves privadas importantes se borren automáticamente.
Citando la frase del post original de que “aunque se abra un root shell, la información de las tarjetas no corre peligro”, recomiendan la lectura como material que cualquier diseñador de seguridad debería revisar.
Alguien opina que el Linux “comprometido” decide si cargar el código de “compromised mode” o el sistema de seguridad
mp1, y señala que, aunque el bootloader en sí sea seguro, el significado cambia según el entorno en que realmente se ejecute. Añaden que un co-processor podría hacer el papel de Secure Enclave, pero que si Linux puede cargar un bootloader aparte, sería un problema de seguridad serio.loadercodeymp1.img, sin importar el estado de tamper, y que la bifurcación según el estado de manipulación ocurre dentro deloadercode, que está protegido por integridad.Recomiendan a los principiantes probar primero con terminales modernos de tarjeta de crédito basados en Android. Como el PIN se ingresa en pantalla táctil, dicen que hasta suena más divertido.
Explican que el touch controller normalmente está conectado a un MUX controlado por el procesador seguro, y que cuando se ingresa información sensible, la entrada táctil va directo al procesador seguro sin que intervenga el sistema operativo tipo Android.
Añaden que, aunque el PIN se vea en el touchpad, los datos del PIN los maneja firmware ejecutado en una trust zone y van cifrados, así que las apps intermedias no pueden verlos.
También opinan que, incluso hackeando este tipo de terminal Android, si el diseño de seguridad es el mismo, la propia tarjeta realiza criptografía compleja y en la práctica no quedaría información útil. Creen que este tipo de ataque solo funcionaría cuando ya no quede más que el lector de tarjeta, y que un terminal así ya sería para el usuario una señal de alerta de posible skimmer.
Mencionan brevemente, con curiosidad, que los terminales Android usados en India todavía corren Android Oreo, cuyo soporte terminó en enero de 2021.
A alguien le resulta extraño que, al empezar a analizar el interior del terminal, lo primero haya sido abrirlo y activar el modo de manipulación. Se preguntan si el autor no sabía que la mayoría de los lectores detecta tampering. Creen que probar cosas en modo tamper puede restarle valor al experimento, y se preguntan si tal vez ese modo no existe justamente para abrir un shell de inicialización. Finalmente, sugieren volver a pensar si de verdad era tan natural abrirlo desde el principio.
Elogian que, a pesar de una protección anti-manipulación tan estricta, todavía quedaran muchas cosas interesantes por desviar y muchas huellas por investigar. Evalúan que, en la parte de seguridad, el diseño correcto es que falle de forma segura.
Se enfatiza que el procesador reforzado (
mp1) sigue sin poder ser comprometido. Explican que en realidad solo se le pasan cadenas de texto al binariodisplay_tool, que se encarga de intercambiar mensajes con el otro procesador. Linux no puede acceder directamente al lector de tarjetas ni al teclado numérico; un procesadormp1completamente separado se encarga de todo lo “seguro”, como la tarjeta, el ingreso del PIN y la visualización en pantalla, mientras que el Linuxmp2solo maneja red, actualizaciones y lógica de negocio.Otra hipótesis plantea que el lado Linux podría ser el que detecta el manejo del evento de tamper, pero si las llaves seguras solo pueden borrarse una vez que el tamper ha sido completamente detectado, entonces sería peligroso porque permitiría un flujo donde primero se obtiene root shell y luego se esquiva el tamper.
A alguien le llama la atención que este tipo de terminales esté tan extendido por toda Europa. No está seguro sobre Suiza, pero dice que en muchas partes de Europa que conoce es raro ver tarjetas de crédito como tal. En cambio, como los terminales POS pueden leer toda clase de tarjetas, cree que “sistema POS” sería un nombre más adecuado. De todos modos, comenta que disfrutó mucho la publicación.