ISGroup Consultoría de Ciberseguridad

Ride’n Godi: el caso que puso de rodillas al sistema de bicicletas compartidas en Bolonia

Cuando el hackeo se convierte en protesta (y en un daño enorme) 😈🚲📱

Verano de 2023, Bolonia. Más de 1.600 bicicletas desaparecidas en pocos meses.

¿La causa? Una aplicación pirata: Ride’n Godi.

Alguien hackeó la autenticación BLE, creó una nueva aplicación y publicó código + credenciales de desbloqueo. Todo accesible. Todo replicable.

Un caso de manual de ingeniería inversa, pero también una reflexión sobre el límite entre el hacktivismo y la ilegalidad.

🔒 La seguridad nunca es un extra.
🔁 Cualquier objeto conectado puede convertirse en un vector de riesgo.

¿Qué opinas? ¿Es solo vandalismo digital o una forma (equivocada) de hacerse escuchar? 💬

#hacking #ble #bikesharing #security #vulnerability #IoT #cybercrime #tecnologia #privacy #bluetooth

Análisis técnico del ataque “Ride’n Godi” al servicio de bike sharing RideMovi

Introducción

Durante 2023 se llevó a cabo un ataque particularmente sofisticado y bien documentado contra el sistema de bike sharing RideMovi, con un impacto real: más de 1.600 bicicletas sustraídas en la ciudad de Bolonia. Este documento recorre, con un enfoque de analista de seguridad, las fases técnicas del ataque, las vulnerabilidades explotadas, las herramientas empleadas y las implicaciones sistémicas. El objetivo no es solo describir qué sucedió, sino sobre todo explicar cómo sucedió, paso a paso.

Las fuentes públicas que respaldan este análisis incluyen:

1. Comprensión de la arquitectura del sistema

El sistema RideMovi se basa en una arquitectura clásica para vehículos compartidos:

BICICLETA <—— BLE ——> APP (smartphone) <—— HTTPS ——> SERVIDOR

En algunos casos más avanzados:

BICICLETA <—— BLE ——> APP
  \———— HTTP ————/

Las bicicletas están equipadas con módulos BLE (Bluetooth Low Energy) para recibir comandos desde la aplicación. La aplicación móvil actúa como puente entre el usuario y los servidores centrales, pero también es el punto más vulnerable del sistema.

2. Fase inicial: recopilación de información

El primer paso fue obtener acceso a los datos críticos: ID de las bicicletas, direcciones MAC y claves de desbloqueo. Esto probablemente se logró mediante:

  • Ingeniería inversa de la aplicación oficial de Android
  • Acceso a las llamadas API mediante proxy HTTPS (ej. mitmproxy)
  • Exfiltración de archivos de configuración o bases de datos que contenían las credenciales

El formato de los datos recopilados era:

bike_ID MAC_address clave

Ejemplo real:

IE12H12508 E6D03CAEB73F 6e036ccfddea27384e939283b9fc405c

La clave es una cadena hexadecimal de 32 caracteres (128 bits), sin protección y presumiblemente utilizada directamente en el protocolo BLE.

3. Decodificación y análisis del protocolo BLE

Utilizando herramientas como bleak (Python) y el registro HCI snoop de Android (analizable con Wireshark), los atacantes rastrearon la comunicación BLE entre la aplicación original y las bicicletas.

Elementos observados:

  • Comandos BLE enviados en texto plano
  • Sin autenticación mutua
  • Posibilidad de ataques de repetición (replay)

El protocolo BLE era tan simple que permitía la reconstrucción completa del mecanismo de desbloqueo.

4. Construcción de una aplicación alternativa: Ride’n Godi

Los atacantes crearon luego una aplicación personalizada:

  • Desarrollada en Python/Kivy
  • Utiliza bleak para la interacción BLE
  • Incluye código Java (vía JNI) para la gestión de BLE en Android

La aplicación carga un archivo de texto con la lista de vehículos y sus respectivas claves, luego permite seleccionar y desbloquear una bicicleta con un clic.

La interfaz es minimalista, pero extremadamente eficaz. No es necesaria ninguna verificación del lado del servidor: la operación ocurre enteramente entre el smartphone y la bicicleta.

5. Debilidades sistémicas

BLE:

  • Claves estáticas: sin rotación, regeneración o desafíos (challenges)
  • Aceptación ciega: la bicicleta acepta comandos válidos de cualquier dispositivo BLE
  • Ausencia de cifrado a nivel BLE

API:

El lado del servidor también mostraba debilidades:

  • Posibilidad de interceptar y manipular las solicitudes HTTPS (post-patching con Frida/Apktool)
  • Técnicas mencionadas en el blog incluyen:
    • Bloqueo inmediato después del desbloqueo para minimizar la tarifa
    • Spoofing de la ubicación
    • Envío de errores ficticios para declarar la bicicleta averiada
    • Secuestro (hijacking) de sesiones activas

6. Impacto concreto

  • Bicicletas sustraídas: más de 1.600 en Bolonia en el verano de 2023
  • Daños económicos directos: no recuperables
  • Alto riesgo de replicabilidad: código disponible públicamente

Esto no fue una simple prueba de concepto. Fue una operación extendida, con un impacto real y rastreable.

7. Consideraciones finales

Este ataque demuestra la importancia de considerar toda la pila de seguridad: no basta con proteger el servidor si el BLE está completamente expuesto. Los sistemas de movilidad inteligente, si no están adecuadamente protegidos, pueden ser desactivados, manipulados o replicados por actores con competencias técnicas intermedias.

Recomendaciones para los proveedores:

  • Uso de BLE con autenticación mutua (ej. ECDH)
  • Generación dinámica de claves
  • Verificación del lado del servidor de los comandos BLE
  • Endurecimiento (hardening) de la aplicación: ofuscación, verificación de integridad, fijación de TLS (TLS pinning)

Este caso de estudio debe considerarse como un ejemplo emblemático de “inseguridad por diseño”. La transparencia del ataque, unida a la motivación política explicitada por los autores, lo convierte en un documento técnico y social al mismo tiempo.

Análisis redactado por expertos en ciberseguridad con fines de estudio, auditoría y formación.

In