Hackear el transporte público: la investigación que comprometió los buses de una ciudad argentina

Imagina subir al colectivo, aburrirte en el viaje y descubrir que la plataforma que controla las cámaras, el ticketing y el tracking de todo un sistema de transporte está expuesta en internet. Eso fue exactamente lo que hizo Ignacio Navarro, un investigador de seguridad argentino especializado en application security y pentesting, y lo contó en su charla "Every ride you take - Hacking a City's Public Transportation" en la DragonJAR Security Conference. Hackear el transporte público no requirió exploits sofisticados ni herramientas exóticas: hizo falta leer código, encadenar vulnerabilidades pequeñas y un poco de curiosidad. El resultado fue acceso completo a sistemas de 10 provincias argentinas, con más de 1.400 dispositivos bajo control.

El origen: la curiosidad en un viaje en bus

Todo empezó en diciembre de 2025, durante un viaje en colectivo de regreso a su casa en Córdoba. Aburrido, Ignacio comenzó a revisar el sistema de venta de pasajes que corría en la unidad y notó un par de cámaras conectadas. Al rastrear la marca del software y el hardware, llegó a la página del proveedor: una empresa que se jactaba de trabajar con más de 170 empresas y más de 6.000 consolas diferentes.

El nombre le sonaba. Al revisar su correo descubrió que en 2018 ya le había reportado a esa misma compañía una vulnerabilidad de SQL injection. La pregunta natural fue inmediata: ¿habrán mejorado su seguridad desde entonces? Spoiler: no.

Primeros hallazgos: un .git expuesto y credenciales hardcodeadas

Después de descartar credenciales por defecto en el login, un barrido de directorios reveló algo mucho más interesante: el sitio exponía su carpeta .git, lo que permite descargar prácticamente todo el código fuente de la aplicación. Entre los archivos encontró también un config.php con credenciales hardcodeadas, aunque apuntaban a servidores de una red interna inaccesible desde internet.

Al auditar el código notó que todas las consultas usaban PDO, la capa de acceso a datos de PHP que previene SQL injection de forma nativa. Pero una sola consulta usaba concatenación de strings. Ese único descuido era la puerta de entrada: una vulnerabilidad de SQL injection que, si bien no permitía filtrar datos directamente, abrió el camino para entender la infraestructura. Y en el archivo de configuración de git apareció la URL de un servidor de GitLab expuesto.

La lección del .git expuesto

Un directorio .git accesible desde internet es una fuga silenciosa pero enorme: contiene el historial completo del código, ramas antiguas, comentarios y archivos de configuración que nadie debería ver. Para el atacante, es como recibir el plano del edificio antes de intentar entrar.

El portal de cámaras: credenciales de prueba y LFI

La investigación saltó entonces al portal de videovigilancia, expuesto en el puerto 8080. El software de cámaras y DVR era de 2021, tenía dos CVE publicados para otras versiones y presumía en su marketing de estar "supersegurizado". Tras probar combinaciones de credenciales, una funcionó: usuario "prueba" y contraseña "prueba".

Con ese acceso se podían tomar capturas de las cámaras, grabar video y, lo más inquietante, escuchar el audio del interior del bus e incluso enviar mensajes de voz al conductor. Pero el detalle crítico llegó al observar cómo se guardaban esas capturas: la aplicación construía la ruta del archivo directamente con un parámetro manipulable. Cambiando ese valor, el sistema entregaba archivos locales arbitrarios: un Local File Inclusion (LFI) que permitía leer archivos del servidor.

El backup que regaló la base de datos

La documentación pública del fabricante, una empresa china, incluía manuales con capturas de pantalla subidas por usuarios en foros. Ahí estaban la ruta y el nombre de los respaldos. Al solicitar el backup, el sistema entregó un ZIP de 2022 con cerca de 100 usuarios cuyas contraseñas se almacenaban como hashes MD5. Combinando el LFI con los archivos de estructura de la base de datos en caliente, fue posible reconstruir el esquema completo en un contenedor MySQL local y verificar los datos reales del sistema.

La demo: una clave 000000 y el acceso a todo el país

En la demo en vivo de la charla, Ignacio mostró el paso decisivo: calcular el hash MD5 de la contraseña "000000" y consultar cuántas cuentas activas la seguían usando. La respuesta fue siete. Una de ellas resultó ser una cuenta con privilegios elevados.

Con ese login, hackear el transporte público dejó de ser un ejercicio local: el acceso se multiplicó de golpe, con visibilidad sobre 10 provincias argentinas, más de 1.400 dispositivos entre buses urbanos, buses regionales y flotas privadas, y la capacidad de ver todas las cámaras, escuchar todos los micrófonos, hablar por ellos y crear o modificar usuarios del sistema. Cuando presentó la charla por primera vez, Shodan mostraba unos 1.700 dispositivos del mismo fabricante expuestos; meses después la cifra rondaba los 1.000.

La cadena de explotación: del FTP gubernamental al RCE

El GitLab expuesto mostraba cuatro proyectos públicos sin necesidad de autenticación. Entre ellos había cron jobs, archivos de configuración de las tarjetas y más credenciales hardcodeadas, incluida la de un servidor FTP del gobierno usado para telemetría, compartido con otras entidades públicas y privadas de Argentina.

El hallazgo técnico más elegante de la investigación llegó ahí. Un script PHP sincronizaba archivos entre el FTP y el servidor interno: si un archivo existía en el FTP pero no en el servidor, este lo descargaba automáticamente. El cron corría una vez al día. Ignacio subió un pequeño archivo PHP al FTP, esperó, y al día siguiente el propio sistema lo había copiado y desplegado: ejecución remota de código (RCE) sin atacar directamente ningún servidor. A veces el mejor exploit es dejar que la infraestructura trabaje para uno.

El impacto real: datos masivos y control de buses

Ya dentro de la red, sin segmentación alguna, el alcance se volvió abrumador. La base de datos del sistema contenía más de 6.000 administradores y más de 5 millones de tarjetas de transporte, porque el alcance era nacional. Había credenciales bancarias con tokens válidos para consultar y mover balances, configuraciones de VPN y certificados PEM expuestos en el servidor.

20.000 documentos de identidad

En una carpeta descubierta por azar había 20.000 documentos de personas: fotos de los DNI por delante y por detrás, recibos de sueldo y certificados de domicilio. Eran los trámites de quienes solicitaban la tarifa reducida de estudiantes y trabajadores. Toda esa información sensible descansaba accesible en una red pública.

Remote management: apagar buses por internet

El panel administrativo permitía cambiar tarifas, aplicar descuentos del 100%, crear tarjetas duplicadas tipo "master", ver qué conductor manejaba cada unidad y leer sus mensajes. Pero la función que marcó el límite ético de la investigación fue el remote management: enviar órdenes a una unidad para encender o apagar las luces, activar una alarma, llamar a la policía o a los bomberos... o cortar el combustible y apagar el bus en movimiento. Y como el comando se enviaba por ID de dispositivo, podía broadcastearse a los 1.400 dispositivos de la flota.

Taxis, bicicletas y el APK

El ecosistema incluía más subsistemas comprometidos: una aplicación de taxis con control total de tarifas, balances, tracking en tiempo real e historial de viajes; el sistema de alquiler de bicicletas con sus 115.000 usuarios y sus sanciones; y portales gubernamentales con licencias de conductores, verificaciones técnicas y seguros. Incluso la APK oficial de Android exponía semillas, claves de encriptación, credenciales SMTP y IPs internas al decompilarse, y existían tarjetas de administrador que validaban solo una parte del bloque de datos, facilitando su clonación para viajar gratis.

¿Qué pasó después? El disclosure responsable

Con ese nivel de acceso, la pregunta ya no era técnica sino ética. Ignacio envió tres correos a la empresa privada. Ninguno obtuvo respuesta. Entonces acudió al CERT nacional, que en pocos días gestionó el reporte y confirmó que las vulnerabilidades fueron corregidas. Para él la historia terminó ahí, en febrero, como un caso más de investigación responsable.

Lo que vino después lo cambió todo: presentó la charla en B-Sides Las Vegas y Defcon, un artículo del diario Clarín reseñó el caso y la historia se viralizó. Cuando tus vecinos y tu abuela leen sobre el hackeo en el diario, dice Ignacio, uno empieza a preocuparse. Al día siguiente lo contactó un municipio de Córdoba interesado en un pentest, que luego desapareció tras recibir el presupuesto... y tras descubrir que Ignacio, mientras armaba el reporte, encontró de regalo un IDOR en su propia aplicación que exponía los archivos de los ciudadanos.

Lecciones de seguridad de este caso

Más allá del caso concreto, la charla deja conclusiones aplicables a cualquier organización:

• No subestimar las fallas pequeñas. Un .git expuesto, una consulta sin PDO y una clave 000000 se encadenaron hasta comprometer la movilidad de un país.
• Leer código sigue siendo una superpotestad. Las herramientas automáticas ayudan, pero el hallazgo decisivo vino de leer el código fuente con atención.
• Las credenciales de prueba y los backups viejos son puertas abiertas. "Prueba/prueba" en producción y un ZIP de 2022 sin protección no deberían existir.
• Sin segmentación de red, un solo fallo lo compromete todo. Cámaras, ticketing, banca y documentos personales compartían el mismo entorno.
• El disclosure responsable necesita respuestas. Sin programas de recompensa ni canales efectivos, el investigador asume todo el riesgo legal y la empresa pierde la oportunidad de corregir a tiempo.

Como cerró Ignacio: esto no va de plata, va de cuidar la data, porque es la data de todos los que usamos el transporte público cada día.

Preguntas frecuentes

¿Es legal hackear el transporte público?

No, en general no lo es. Como explicó Ignacio, no hay un programa de recompensas ni un alcance definido: quien investiga estos sistemas lo hace sin invitación y asumiendo riesgo legal real, incluida la posibilidad de denuncias. Su recomendación es explorar con ética y, ante cualquier hallazgo, reportarlo responsablemente a la empresa o al CERT.

¿Qué es un .git expuesto y por qué es peligroso?

Es la carpeta de control de versiones de un proyecto web accesible desde internet. Permite reconstruir el código fuente completo, incluidas credenciales, rutas internas y lógica de negocio, dando al atacante el mapa exacto de dónde buscar vulnerabilidades.

¿Qué es un LFI y cómo se usó en este caso?

Local File Inclusion es una vulnerabilidad que permite leer archivos locales del servidor manipulando la ruta que la aplicación usa para incluir o servir un archivo. Aquí se explotó desde la función de capturas del portal de cámaras para leer configuraciones, backups y archivos de la base de datos.

¿Cuánto tiempo tomó la investigación completa?

Según contó en la charla, el punto más lento fue llegar al FTP del gobierno: unas dos semanas. La explotación completa tomó algunas semanas más, concentrada entre enero y febrero, y el CERT corrigió las vulnerabilidades días después del reporte.

¿Qué pasó con la empresa después del reporte?

La empresa nunca respondió los tres correos iniciales. La corrección llegó por la vía del CERT nacional. Después de que el caso se hiciera público con la charla en B-Sides Las Vegas y Defcon y la nota en Clarín, un municipio de Córdoba se acercó interesado en servicios de pentesting.

Conclusión: pequeñas fallas, ciudades enteras

La historia de Ignacio Navarro demuestra que hackear el transporte público de una ciudad no exige recursos de película: exige método, paciencia y la voluntad de mirar donde nadie mira. Cada eslabón de la cadena, del .git expuesto a la clave 000000, era individualmente manejable; el desastre nació de encadenarlos en un sistema sin segmentación ni cultura de parcheo. Para quienes construyen y operan infraestructura crítica, es un recordatorio de que la seguridad no es un producto sino un proceso constante.

Si quieres ver casos como este contados por sus protagonistas, con toda la evidencia técnica y las historias detrás, revive las charlas de la DragonJAR Security Conference y regístrate en el sitio oficial para recibir las grabaciones y contenido exclusivo en https://www.dragonjarcon.org. Y si tu organización necesita este mismo nivel de escrutinio, en DragonJAR también hacemos servicios de seguridad ofensiva: https://www.dragonjar.org/servicios-de-seguridad-informatica.

Mira la Charla Completa Sobre hackear el transporte público

Todo el recorrido técnico —del .git expuesto al control de 1.400 dispositivos— está en la charla completa de Ignacio Navarro: