- Tras desarmar y analizar el firmware de la terminal de pago Worldline Yomani XR usada en Suiza, se pudo entrar a una shell root escribiendo solo
rooten una consola serial accesible desde una compuerta trasera - La terminal contaba con protección contra manipulación que detectaba la apertura de la carcasa, la desconexión de contactos del PCB, el corte de pistas en zigzag y daños en el PCB flexible alrededor del lector de tarjetas, pero el puerto de depuración expuesto se convirtió en una vía de ataque separada
- El firmware extraído de la flash integrada incluía un sistema de archivos sin cifrar, y funcionaba sobre un kernel Linux 3.6, Buildroot 2010.02, BusyBox, uClibc y un bootloader personalizado Booter v1.7
- Las funciones de seguridad como tarjeta, PIN, pantalla y teclado parecen estar a cargo de un procesador separado
mp1y demp1.img, cifrado y firmado; no se encontró evidencia de que se pudiera acceder a ellas directamente desde Linuxmp2 - No se confirmó qué versión de firmware era vulnerable y también había dispositivos con el login root deshabilitado, pero en entornos donde alguien puede tener control físico exclusivo de la terminal por un momento queda una superficie de ataque innecesariamente grande
Objeto de análisis: Worldline Yomani XR
- El objeto de análisis fue la terminal de pago Worldline Yomani XR, ampliamente usada en Suiza
- Tras el arranque, la revisión de la UI y un escaneo de puertos no arrojaron resultados destacables, por lo que se procedió a desarmar el hardware
- El interior está compuesto por varios PCB
- Una placa pequeña para conectores externos
- La placa principal
- Una placa vertical con la ranura para tarjetas
- El SoC principal parece ser un ASIC personalizado basado en Arm de doble núcleo, que en el firmware aparece con el nombre en clave “Samoa II”
- Según la documentación de Worldline, este chip no es un chip comercial reetiquetado, sino un ASIC personalizado
- Junto al SoC hay una flash externa pequeña y RAM
Estructura de protección contra manipulación del hardware
- No se encontró un interruptor típico para detectar la apertura de la carcasa; en su lugar, el propio interconector placa a placa se usaba como medio de detección de apertura
- Entre las placas hay una Zebra strip sensible a la presión, por lo que las placas deben estar firmemente atornilladas para mantener el contacto
- Con solo aflojar algunos tornillos se puede perder el contacto y generar un evento de manipulación
- Como la detección debe funcionar incluso sin alimentación, se usa una batería tipo moneda
- Las áreas vulnerables del PCB están cubiertas con pistas de detección de manipulación en forma de zigzag
- Si una intrusión física corta apenas una pista de cobre, puede activarse la detección de manipulación
- La ranura para tarjetas está dentro de una carcasa interna separada, y un PCB flexible que la rodea cumple la función de protección contra manipulación
- Después de volver a ensamblarla, la terminal solo mostraba una gran pantalla roja con “TAMPER DETECTED”, y en ese modo parecía no responder a entradas externas
Extracción de la flash y recuperación del sistema de archivos
- Como la exploración en tiempo de ejecución estaba bloqueada, se retiró el chip flash integrado y se conectaron cables para volcar su contenido
- A diferencia de lo esperado, el contenido volcado no estaba cifrado en su totalidad
- La flash usaba una disposición de ECC poco común
- No era la configuración estándar de payload de 2048 bytes + 64 bytes de ECC/spare
- Tenía 3 chunks de datos de 694 bytes, y detrás de cada chunk venían 10 bytes de ECC
- Los últimos 16 bytes del área spare parecían ser metadata del sistema de archivos YAFFS2
- Como el área de metadata era más pequeña que en YAFFS2 habitual, fue necesario parchear el sistema de archivos para que manejara una estructura de metadata más pequeña
- Después de implementar un reader de sistema de archivos compatible, se logró extraer correctamente el contenido del sistema de archivos
Sistema antiguo basado en Linux
- A partir del sistema de archivos extraído se confirmó que la terminal ejecuta Linux
- El sistema incluye componentes antiguos
- Linux kernel 3.6
- Buildroot 2010.02
- Build de febrero de 2023
- Bootloader personalizado
Booter v1.7 - scripts init, BusyBox, uClibc
libcrypt0.9.26
- No se pudo confirmar qué tan reciente era la versión de firmware volcada, pero debía tratarse de un firmware lanzado después de febrero de 2023
Shell root sin contraseña
- Al reconectar el chip flash con cables, la terminal volvió a arrancar aunque mostraba el mensaje de manipulación
- Para ver el log de arranque de Linux, se revisó con un analizador lógico la zona alrededor del conector de depuración, y se encontró actividad en un pad de un conector de depuración sin poblar
- En la consola serial apareció un prompt de login junto con el log de arranque de Linux
- En el boot log aparecía “Reset reason: Tamper”
- También se veían logs como
dropbear is not present, comprobación de actualización de firmware e inicio del daemon de monitoreo de la aplicación - Al final aparecía el prompt
samoa login:
- Al ingresar
rootcomo login, apareció el prompt de shell~ #sin contraseña - Este acceso no requirió una cadena de exploits ni cracking de contraseñas por fuerza bruta
Puerto de depuración accesible desde el exterior
- El acceso a la shell root no se limitaba a los casos en los que se abría el interior de la terminal
- El puerto serial era accesible desde el exterior a través de una pequeña compuerta en la parte trasera de la terminal
- Era posible conectarse al conector de depuración sin abrir la terminal ni activar la protección contra manipulación
- Se consideró posible un escenario en el que alguien con control exclusivo de la terminal por un breve momento se conecte al puerto serial, inicie sesión, instale malware y se vaya
Separación de roles entre el procesador de seguridad y Linux
- La shell root expuesta no implica por sí sola acceso a datos de tarjetas o PIN
- El sistema Linux es solo una parte de la arquitectura completa, y no se encontró evidencia de que desde Linux se pudiera acceder directamente a la pantalla, el teclado o el lector de tarjetas
- La salida en pantalla tampoco parecía estar manejada directamente por un driver de framebuffer, sino pasando cadenas al binario
display_tool, que luego enviaba un mensaje entre procesadores - Las funciones relacionadas con seguridad, como tarjetas, ingreso de PIN y visualización en pantalla, parecen ser manejadas por un procesador separado
mp1 - Linux, que se ejecuta en un segundo procesador
mp2, se encarga de networking, actualizaciones y lógica de negocio
Flujo de arranque e imagen segura
- El core Linux parece arrancar siempre, independientemente del estado de manipulación
- Luego Linux carga en memoria
loadercode, el bootloader seguro loadercodeverifica si se activó la protección contra manipulación- Si se detecta manipulación, muestra una pantalla roja
- Si no hay problemas, arranca la imagen segura real,
mp1.img
mp1.imgestá dentro del sistema de archivos de Linux, pero parece estar cifrada y firmada por dos entidades- La imagen segura que maneja la tarjeta, la pantalla y el teclado estaba correctamente cifrada y firmada
Cronograma de divulgación e incertidumbres pendientes
- El cronograma de divulgación quedó registrado así
- 14 de noviembre de 2024: descubrimiento de la shell root
- 15 de noviembre de 2024: reporte al fabricante y aviso de publicación prevista después de 90 días
- 18 de noviembre de 2024: el fabricante confirma la recepción del reporte
- 1 de junio de 2025: publicación
- La shell root expuesta representa una superficie de ataque innecesariamente grande, pero no se encontró evidencia de que datos sensibles como información de tarjetas puedan verse comprometidos por esta vía
- No se confirmó qué versiones de firmware son vulnerables
- Durante la investigación también se encontraron dispositivos con el login root deshabilitado
- No se pudo confirmar en qué momento la función de depuración entró al firmware de producción, ni si el fabricante ya la había descubierto y corregido internamente
1 comentarios
Opiniones en Hacker News
Con un lector de tarjetas USB de 2 dólares sí se pueden crear transacciones falsas de débito/crédito.
Las especificaciones son todas públicas y el protocolo está documentado. Si no recuerdo mal, el PDF tenía unas 5000 páginas, así que leerlo era bastante doloroso.
Pero para validar esa transacción hay que enviarla por internet al banco, y entonces podrían aparecer agencias federales/el FBI o similares.
El lector de tarjetas en sí casi no tiene protecciones reales; en la mayoría de los casos es un Linux pequeño con contraseñas pésimas. La protección viene de los contratos y las regulaciones entre la tienda y el banco.
noexecconfigurado.El inicio de sesión como root está deshabilitado, se usa un busybox con muchas funciones recortadas, y las claves se cargan desde el área segura durante el arranque. La inyección de la clave maestra solo es posible durante la carga en fábrica, el arranque en sí también es seguro hasta cierto punto, y si se detecta manipulación se vacía el chip.
Claro que, si se trata de una terminal Android barata sin certificación EMV importada de Asia, es muy probable que tenga un Linux estándar con sistema de archivos raíz de lectura/escritura, inicio de sesión como root e incluso sudo habilitado para el usuario que ejecuta la app. Puede que tampoco tenga detección de manipulación, que el casting de pantalla no esté bloqueado, que se puedan abrir puertos y que busybox esté casi completo.
Como alguien que durante años desarrolló aplicaciones EMV para adquisición de tarjetas, y que todavía lo hace ocasionalmente, incluso el modo de desarrollo requiere que el proveedor entregue un ID de desarrollador y está bastante bloqueado.
Por eso también son falsas las teorías conspirativas de que alguien puede ir por ahí con un lector portátil robando dinero de tarjetas sin contacto. Ese tipo de transacción sí se puede crear, pero el problema es lo que pasa después y la configuración necesaria de antemano.
Ni siquiera está claro que puedas retirar el dinero antes de que te detecten y te bloqueen. Hoy mucha gente tiene activadas las notificaciones push de transacciones, así que creo que es aún más difícil.
Si esas claves se filtran, alguien podría hacerse pasar por una transacción legítima.
En este caso concreto parece difícil o imposible, pero por eso la investigación en esta área tiene sentido.
No sé qué debería estar mirando, pero he tenido la tentación de abrir uno de los lectores Stripe M2 que tengo para ver su interior.
El problema es que, de los 36 lectores que compré, 7 “murieron”. 2 no mantienen la carga, 1 no puede escanear NFC y 4 muestran “tampered”. A simple vista, la tasa de pérdida es mala, pero habría que ver la frecuencia de uso y la antigüedad para tener el panorama completo.
Pero esa respuesta es todavía peor. Los dispositivos tienen entre 1 y 3 años, y el total de días de uso es como máximo 9. Es decir, con 9 días totales de uso, 7 de 36 fallaron de alguna forma. Incluso al transportarlos, todos van guardados en un estuche rígido con inserto de espuma y una ranura separada para cada lector.
Por eso no me encantan los lectores M2, pero siguen siendo la mejor opción para mí.
[0] Para dar contexto, nuestra empresa procesa pagos en festivales. Vamos al lugar del evento y procesamos pagos presenciales con iPads y lectores M2, mientras que la mayoría de los pagos ocurren en la web/app. Por eso los “días de uso” son tan pocos en 3 años.
Y es muy probable que la detección de manipulación también necesite una batería que funcione correctamente.
Puede que la estructura sea que, cuando se activa el sello antimanipulación, se abra una shell de root.
Es decir, el sistema podría estar en un modo seguro con las claves criptográficas necesarias para operar, o en un modo no seguro con una shell de root abierta para depuración y análisis de fallas, pero en el proceso de transición se borrarían claves privadas importantes.
Me dio curiosidad saber si se puede conseguir una terminal real. Si las están reemplazando y sacando de circulación, quizá no sea tan difícil encontrar una usada.
Para quienes se entusiasman fácilmente, el texto dice: “la shell de root expuesta no parece ser un riesgo tan grande como se temía al principio. No encontramos evidencia de que datos sensibles como información de tarjetas puedan verse comprometidos de esta manera”.
Aun así, para un arquitecto de seguridad es una buena lectura.
En seguridad, el acceso físico —y, aunque en menor medida, también el acceso root— prácticamente equivale a un hackeo exitoso.
Si el Linux comprometido es el que decide si cargar el código de “modo comprometido” o el sistema seguro mp1, parece una ruta que vale la pena explorar.
Se dice que el bootloader en sí es seguro, pero si se carga dentro del entorno comprometido dependiendo de dónde se ejecute realmente, puede que eso no signifique mucho.
Se podría ver el coprocesador como una especie de Secure Enclave, pero preocupa que Linux pueda cargar y ejecutar un bootloader separado.
loadercode, pero no arrancó.Por eso supongo que un tercero, probablemente la ROM de arranque, lo verifica.
Además, parece que Linux siempre carga
loadercodeymp1.imgsin importar el estado de manipulación. La ruta de código distinta según el estado de manipulación parece seleccionarse dentro deloadercode, que está protegido con integridad.Si quieren el modo fácil, basta con mirar las terminales de tarjetas basadas en Android que salen hoy en día
En especial, como el PIN se ingresa directamente en la pantalla, es muy probable que sea mucho más satisfactorio
Al ingresar datos sensibles como un PIN o un PAN, la salida del controlador táctil evita el sistema operativo tipo Android encargado de la GUI y se enruta directamente al procesador de seguridad
Por eso, las aplicaciones intermedias accesibles en ataques de este tipo no pueden ver el PIN
Las tarjetas modernas realizan muchas operaciones criptográficas dentro de la propia tarjeta para evitar ataques así
Este ataque solo funcionaría en terminales donde la única opción de pago que siga viva sea el lector de banda magnética; en una terminal así, las alarmas de skimmer deberían encenderse antes siquiera de ver el prompt del PIN
Excelente. Me encanta pensar en formas de eludir y explotar restricciones de hardware como esta protección contra manipulaciones tan amplia, pero siempre pensé que, una vez que se activaba, se acababa el juego
Pero no necesariamente es así, y todavía quedaban muchas partes interesantes por investigar. Eso sí, es lógico que la parte de seguridad se desactive correctamente. Si no, habría perdido toda confianza en quienes la diseñaron
Solo se pasan cadenas de texto a un binario llamado
display_tool, y ese binario parece enviar mensajes entre procesadores. Lo mismo ocurre con el teclado y el lector de tarjetas. No encontré evidencia de que esos periféricos sean accesibles directamente desde LinuxEn cambio, parece que un procesador completamente separado llamado
mp1se encarga de las tareas “seguras”, como el procesamiento de tarjetas, la entrada del PIN y la visualización de información en pantalla. El Linux “no seguro” que corre en un segundo procesador,mp2, solo maneja redes, actualizaciones y lógica de negocioAun así, espero que sea una arquitectura donde solo pueda ver que ocurrió una manipulación. De lo contrario, tras obtener primero una shell root, podría existir la oportunidad de impedir que el evento de manipulación provoque el borrado de las claves de seguridad
Al leer sobre todos los sistemas de detección de manipulación del dispositivo, me dio curiosidad cuál sería la forma más fácil de activar el modo de manipulación
Al final, si pudieras hacerles eso aunque sea a unos cuantos de estos dispositivos, sería un ataque de denegación de servicio bastante efectivo contra tiendas donde la mayoría o todos los pagos pasan por estas terminales
Es interesante investigar estos dispositivos, pero no entiendo por qué lo abrió de inmediato y activó el estado de manipulación. ¿No sabía que la mayoría de los lectores tienen algo así?
Las pruebas reales hechas en estado de manipulación quizá no tengan sentido. Es posible que, al entrar en ese estado por inicialización, se abra una shell
A simple vista, abrir el dispositivo parece algo que se debería intentar al final
De lo contrario estaba demasiado a ciegas. Claro, viéndolo en retrospectiva, podría haber simplemente conectado al conector de depuración y listo
Además, también obtuve una shell en un segundo dispositivo que no había sido manipulado
Estos dispositivos están por todas partes en Europa. No sé en Suiza, pero en buena parte de Europa que conozco la gente no tiene ni usa mucho tarjetas de crédito
Yo lo llamaría POS, es decir, sistema de punto de venta. Estos dispositivos pueden leer todo tipo de tarjetas. En fin, buen artículo
Tampoco le veo el atractivo a meter más cosas en el teléfono o en un smartwatch. Prefiero un reloj mecánico, y perder el teléfono ya sería un desastre suficiente desde el punto de vista de la privacidad. Claro, ese es mi caso