Punto de fallo: Hacking de un dispositivo POS con WHIDBOARD

DE LA COLA DE LA CAJA A UN SHELL DE ROOT

Hace algún tiempo estaba de compras por la ciudad cuando me topé con un interesante POS (punto de venta). Mientras el cajero preparaba la bolsa de la compra, saqué rápidamente mi teléfono y tomé un par de fotos para referencia futura…

Una vez en casa, empecé a examinar más de cerca las etiquetas situadas debajo del TPV y enseguida me di cuenta de algo interesante… se veía claramente un ID de la FCC (es decir, SEKMA512)! 😎

¡Reconocimiento pasivo – ¡Hora de OSINT!

Con esa información, pude obtener rápidamente más detalles sobre este nuevo DUT (dispositivo bajo prueba) incluso sin tener uno (todavía).

En la base de datos de la FCC pude obtener más detalles sobre las placas de circuito impreso internas, cómo funciona el dispositivo y si cuenta con alguna función antimanipulación que impida los intentos de hacking del hardware.

En concreto, al revisar su manual, pude confirmar que, efectivamente, este TPV (al igual que cualquier otro dispositivo similar que maneje datos de tarjetas de crédito) cuenta con algunas medidas de seguridad para impedir que los actores maliciosos manipulen físicamente la placa de circuito impreso, tal y como se muestra en las imágenes anteriores.

Sin embargo, no me rendí y seguí examinando los documentos de la base de datos de la FCC para comprender mejor el conjunto del DUT y completar mi modelo de amenazas inicial, buscando posibles puntos de entrada.

Como puede observarse en la imagen anterior, la placa principal cuenta con varios puntos de prueba. Algunos de ellos despertaron mi interés, especialmente porque parecían ser accesibles desde el exterior sin necesidad de abrir la carcasa del TPV, lo que significa que podían explorarse sin activar los mecanismos antisabotaje que borrarían la memoria del dispositivo.

Ahora que tenía algunos posibles puntos de acceso, era el momento de comprar algunas unidades de muestra por Internet…

RECON activo: enumeración de pines con WHIDBOARD

Unos días más tarde, llegaron las muestras del dispositivo bajo prueba (DUT), y el primer paso fue sondear los puntos de prueba con un multímetro para identificar cuáles eran eléctricamente relevantes. Una vez que los había reducido, utilicé la función de analizador lógico integrada en WHIDBOARD para comprobar si el TPV estaba emitiendo algún dato.

Tras probar diferentes pines, como puede verse en la captura de pantalla siguiente, finalmente encontré la línea TX de una interfaz de depuración UART. 😎

¡Ahora es el momento de poner en marcha la función Pin Enumerator de WHIDBOARD para encontrar también el pin RX!

Dejar que el DUT completara el proceso de arranque condujo a algo verdaderamente inesperado…

Este punto de venta no solo expuso una interfaz UART totalmente funcional fuera de su perímetro de seguridad antimanipulación —lo que indica un fallo tanto en el modelado de amenazas durante la I+D como en la validación de seguridad previa a la producción—, sino que esta interfaz de depuración condujo directamente a un shell de root. 💥🤯

Manos a la obra: interactuando con el DUT como root

En este punto, las cosas se complicaron rápidamente. Utilizando WHIDBOARD, había identificado un UART expuesto que conducía a un ACCESO ROOT COMPLETO Y SIN AUTENTIFICAR…

Lo que vino a continuación fue que exploré el sistema de archivos del dispositivo, inspeccioné los procesos en ejecución y comprendí la arquitectura interna del DUT.

Finalmente, extraje todo el firmware a través de una unidad flash USB utilizando los siguientes comandos…

Y para demostrar que no solo era capaz de leer el sistema de archivos, sino también de manipularlo… realicé algunos cambios… 😎

RECON activo – Escaneo de red

En este punto, por curiosidad, también comprobé si había servicios de red abiertos en la interfaz Ethernet del dispositivo bajo prueba (DUT). Los resultados fueron alarmantes: el puerto Telnet 23/TCP estaba ABIERTO… 🤯💥

Y sí… ¡se podía iniciar sesión (como root) SIN contraseña!

En ese momento decidí comprobar en Shodan si alguno de estos TPV estaba conectado a Internet. El resultado: al menos 61 de ellos estaban expuestos en Internet… 🙊🙉🙈

Conclusiones

Este dispositivo bajo prueba (DUT) fue toda una sorpresa: en más de una década de investigación sobre seguridad de TPV, nunca me había encontrado con un dispositivo con tantos fallos acumulados. Analicemos qué falló y por qué es importante.

Fallo en múltiples capas de defensa en profundidad. Este dispositivo presentaba al menos cuatro vulnerabilidades distintas y explotables de forma independiente:

1. Puntos de prueba de depuración accesibles desde el exterior que eluden las protecciones físicas contra la manipulación;
2. Una consola UART activa y sin autenticación que permite el acceso al shell de root;
3. Telnet en el puerto 23/TCP con inicio de sesión de root sin contraseña en la interfaz de red;
4. Al menos 61 instancias detectables a través de Shodan, expuestas directamente a Internet.

Cada uno de ellos por sí solo constituiría un hallazgo crítico. En conjunto, representan un fallo sistémico en el ciclo de vida de la seguridad del producto, desde el modelado de amenazas y el diseño seguro, pasando por la implementación y las pruebas previas a la producción.

Implicaciones para la infraestructura de pagos. Un terminal de punto de venta con acceso de nivel root de lectura/escritura al sistema de archivos —accesible tanto físicamente como a través de la red— abre la puerta a la instalación de puertas traseras en el firmware, la interceptación de datos de pago y la implementación de implantes persistentes. En entornos en los que se espera el cumplimiento de la norma PCI DSS, este tipo de vulnerabilidad no es una deficiencia marginal: socava todo el modelo de confianza. El hecho de que estos dispositivos estuvieran conectados a Internet amplía el riesgo, pasando de un ataque físico local a uno con escalabilidad remota.

El contexto normativo: la CRA y más allá. Con la entrada en vigor de la Ley de Ciberresiliencia de la UE (CRA), los productos con elementos digitales comercializados en el mercado europeo deberán cumplir requisitos esenciales de ciberseguridad a lo largo de todo su ciclo de vida, incluyendo una configuración segura por defecto, superficies de ataque minimizadas y obligaciones en materia de gestión de vulnerabilidades. Un dispositivo que se comercialice con acceso de root sin autenticación tanto a través de UART como de Telnet constituiría un caso de incumplimiento de libro. Los fabricantes e importadores deben considerar hallazgos como estos como un anticipo de lo que buscarán los reguladores.

Conclusiones clave para los profesionales. Nunca subestime la información de inteligencia de fuentes abiertas (OSINT) disponible públicamente. La base de datos de la FCC por sí sola proporcionó información suficiente para construir un modelo de amenazas preliminar, identificar límites antimanipulación y localizar posibles puntos de entrada, todo ello antes de adquirir una sola unidad. Para los miembros de equipos rojos y los investigadores de seguridad, esto supone un recordatorio de que el reconocimiento pasivo de los documentos presentados ante las autoridades reguladoras puede acelerar drásticamente las evaluaciones de hardware. Para los fabricantes y los miembros del equipo azul, es un recordatorio de que sus presentaciones ante la FCC, desmontajes y manuales de servicio forman parte de su superficie de ataque.