Quand le piratage devient une protestation (et un dommage énorme) 😈🚲📱
Été 2023, Bologne. Plus de 1 600 vélos disparus en quelques mois.
La cause ? Une application pirate : Ride’n Godi.
Quelqu’un a cracké l’authentification BLE, créé une nouvelle application et publié le code + les identifiants de déverrouillage. Tout était accessible. Tout était réplicable.
Un cas d’école de rétro-ingénierie, mais aussi une réflexion sur la frontière entre hacktivisme et illégalité.
🔒 La sécurité n’est jamais une option.
🔁 Chaque objet connecté peut devenir un vecteur de risque.
Qu’en pensez-vous ? Est-ce juste du vandalisme numérique ou une manière (maladroite) de se faire entendre ? 💬
#hacking #ble #bikesharing #security #vulnerability #IoT #cybercrime #technologie #privacy #bluetooth
Analyse technique de l’attaque “Ride’n Godi” contre le service de vélos en libre-service RideMovi
Introduction
Au cours de l’année 2023, une attaque particulièrement sophistiquée et bien documentée a été menée contre le système de vélos en libre-service RideMovi, avec un impact réel : plus de 1 600 vélos dérobés dans la ville de Bologne. Ce document retrace, avec un regard d’analyste en sécurité, les phases techniques de l’attaque, les vulnérabilités exploitées, les outils utilisés et les implications systémiques. L’objectif n’est pas seulement de décrire ce qui s’est passé, mais surtout d’expliquer comment cela s’est produit, étape par étape.
Les sources publiques qui soutiennent cette analyse incluent :
- Dépôt de code : 0xacab.org/Hen/ridegodi
- Annonces et communications : mastodon.bida.im/@RideGodi
- Contexte idéologique et guide technique : honey.noblogs.org
1. Compréhension de l’architecture du système
Le système RideMovi repose sur une architecture classique pour les véhicules partagés :
VÉLO <—— BLE ——> APP (smartphone) <—— HTTPS ——> SERVEURDans certains cas plus avancés :
VÉLO <—— BLE ——> APP
\———— HTTP ————/
Les vélos sont équipés de modules BLE (Bluetooth Low Energy) pour recevoir des commandes depuis l’application. L’application mobile sert de pont entre l’utilisateur et les serveurs centraux, mais elle constitue également le point le plus vulnérable du système.
2. Phase initiale : collecte d’informations
La première étape a consisté à obtenir l’accès aux données critiques : ID des vélos, adresses MAC et clés de déverrouillage. Cela a probablement été réalisé via :
- Rétro-ingénierie de l’application Android officielle
- Accès aux appels API via un proxy HTTPS (ex. mitmproxy)
- Exfiltration de fichiers de configuration ou de bases de données contenant les identifiants
Le format des données collectées était :
bike_ID MAC_address cléExemple réel :
IE12H12508 E6D03CAEB73F 6e036ccfddea27384e939283b9fc405cLa clé est une chaîne hexadécimale de 32 caractères (128 bits), sans protection et vraisemblablement utilisée directement dans le protocole BLE.
3. Décodage et analyse du protocole BLE
En utilisant des outils comme bleak (Python) et les logs HCI snoop d’Android (analysables avec Wireshark), les attaquants ont tracé la communication BLE entre l’application originale et les vélos.
Éléments observés :
- Commandes BLE envoyées en clair
- Aucune authentification mutuelle
- Possibilité de rejeu (replay)
Le protocole BLE était si simple qu’il a permis la reconstruction complète du mécanisme de déverrouillage.
4. Construction d’une application alternative : Ride’n Godi
Les attaquants ont ensuite créé une application personnalisée :
- Développée en Python/Kivy
- Utilise
bleakpour l’interaction BLE - Inclut du code Java (via JNI) pour la gestion BLE sur Android
L’application charge un fichier texte contenant la liste des véhicules et leurs clés respectives, puis permet de sélectionner et déverrouiller un vélo en un clic.
L’interface est minimale, mais extrêmement efficace. Aucune vérification côté serveur n’est nécessaire : l’opération se déroule entièrement entre le smartphone et le vélo.
5. Faiblesses systémiques
BLE :
- Clés statiques : aucune rotation, régénération ou défi (challenge)
- Acceptation aveugle : le vélo accepte des commandes valides provenant de n’importe quel appareil BLE
- Absence de chiffrement au niveau BLE
API :
Le côté serveur présentait également des faiblesses :
- Possibilité de sniffer et manipuler les requêtes HTTPS (post-patching avec Frida/Apktool)
- Les techniques mentionnées dans le blog incluent :
- Verrouillage immédiat après déverrouillage pour minimiser le tarif
- Usurpation de position (spoofing)
- Envoi d’erreurs fictives pour déclarer le vélo en panne
- Détournement de sessions actives
6. Impact concret
- Vélos dérobés : plus de 1 600 à Bologne durant l’été 2023
- Dommages économiques directs : non récupérables
- Risque élevé de réplicabilité : code disponible publiquement
Il ne s’agissait pas d’une simple preuve de concept. C’était une opération généralisée, avec un impact réel et traçable.
7. Considérations finales
Cette attaque démontre l’importance de considérer l’ensemble de la pile de sécurité : il ne suffit pas de protéger le serveur si le BLE est totalement exposé. Les systèmes de mobilité intelligente, s’ils ne sont pas correctement protégés, peuvent être désactivés, manipulés ou répliqués par des acteurs dotés de compétences techniques intermédiaires.
Recommandations pour les fournisseurs :
- Utilisation du BLE avec authentification mutuelle (ex. ECDH)
- Génération dynamique de clés
- Vérification côté serveur des commandes BLE
- Durcissement de l’application : obfuscation, vérification d’intégrité, TLS pinning
Ce cas d’étude doit être considéré comme un exemple emblématique d’« insécurité par conception » (insecurity by design). La transparence de l’attaque, combinée à la motivation politique explicitée par les auteurs, en fait un document à la fois technique et social.
Analyse rédigée par des experts en cybersécurité à des fins d’étude, d’audit et de formation.
Leave a Reply