Wenn Hacking zum Protest (und zu einem enormen Schaden) wird 😈🚲📱
Sommer 2023, Bologna. Mehr als 1.600 Fahrräder verschwanden innerhalb weniger Monate.
Die Ursache? Eine Piraten-App: Ride’n Godi.
Jemand hat die BLE-Authentifizierung geknackt, eine neue App erstellt und den Code sowie Entsperr-Zugangsdaten veröffentlicht. Alles zugänglich. Alles reproduzierbar.
Ein Lehrbuchbeispiel für Reverse Engineering, aber auch eine Reflexion über die Grenze zwischen Hacktivismus und Illegalität.
🔒 Sicherheit ist niemals ein Extra.
🔁 Jedes vernetzte Objekt kann zu einem Risikovektor werden.
Was denkst du? Ist das nur digitaler Vandalismus oder ein (falscher) Weg, um sich Gehör zu verschaffen? 💬
#hacking #ble #bikesharing #security #vulnerability #IoT #cybercrime #technologie #privacy #bluetooth
Technische Analyse des „Ride’n Godi“-Angriffs auf den Bike-Sharing-Dienst RideMovi
Einführung
Im Laufe des Jahres 2023 wurde ein besonders raffinierter und gut dokumentierter Angriff auf das Bike-Sharing-System RideMovi durchgeführt, der reale Auswirkungen hatte: Mehr als 1.600 Fahrräder wurden in der Stadt Bologna entwendet. Dieses Dokument beleuchtet aus der Sicht eines Sicherheitsanalysten die technischen Phasen des Angriffs, die ausgenutzten Schwachstellen, die eingesetzten Werkzeuge und die systemischen Auswirkungen. Ziel ist es nicht nur zu beschreiben, was passiert ist, sondern vor allem zu erklären, wie es Schritt für Schritt geschehen ist.
Die öffentlichen Quellen, die diese Analyse stützen, umfassen:
- Code-Repository: 0xacab.org/Hen/ridegodi
- Ankündigungen und Kommunikation: mastodon.bida.im/@RideGodi
- Ideologischer Kontext und technische Anleitung: honey.noblogs.org
1. Verständnis der Systemarchitektur
Das RideMovi-System basiert auf einer klassischen Architektur für geteilte Fahrzeuge:
FAHRRAD <—— BLE ——> APP (Smartphone) <—— HTTPS ——> SERVERIn einigen fortgeschritteneren Fällen:
FAHRRAD <—— BLE ——> APP
\———— HTTP ————/
Die Fahrräder sind mit BLE-Modulen (Bluetooth Low Energy) ausgestattet, um Befehle von der App zu empfangen. Die mobile Anwendung fungiert als Brücke zwischen dem Benutzer und den zentralen Servern, ist aber auch der verwundbarste Punkt des Systems.
2. Anfangsphase: Informationsbeschaffung
Der erste Schritt bestand darin, Zugriff auf kritische Daten zu erhalten: Fahrrad-IDs, MAC-Adressen und Entsperrschlüssel. Dies wurde wahrscheinlich durch Folgendes erreicht:
- Reverse Engineering der offiziellen Android-App
- Zugriff auf API-Aufrufe über einen HTTPS-Proxy (z. B. mitmproxy)
- Exfiltration von Konfigurationsdateien oder Datenbanken, die die Zugangsdaten enthielten
Das Format der gesammelten Daten war:
Fahrrad_ID MAC_Adresse SchlüsselReales Beispiel:
IE12H12508 E6D03CAEB73F 6e036ccfddea27384e939283b9fc405cDer Schlüssel ist eine 32-stellige hexadezimale Zeichenfolge (128 Bit), ohne Schutz und wird vermutlich direkt im BLE-Protokoll verwendet.
3. Dekodierung und Analyse des BLE-Protokolls
Unter Verwendung von Tools wie bleak (Python) und Android HCI Snoop Logs (analysierbar mit Wireshark) haben die Angreifer die BLE-Kommunikation zwischen der Original-App und den Fahrrädern nachverfolgt.
Beobachtete Elemente:
- BLE-Befehle werden im Klartext gesendet
- Keine gegenseitige Authentifizierung
- Möglichkeit von Replay-Angriffen
Das BLE-Protokoll war so einfach, dass eine vollständige Rekonstruktion des Entsperrmechanismus möglich war.
4. Erstellung einer alternativen App: Ride’n Godi
Die Angreifer erstellten daraufhin eine eigene App:
- Entwickelt in Python/Kivy
- Verwendet
bleakfür die BLE-Interaktion - Enthält Java-Code (via JNI) für die BLE-Verwaltung unter Android
Die App lädt eine Textdatei mit der Liste der Fahrzeuge und der jeweiligen Schlüssel und ermöglicht es dann, ein Fahrrad mit einem Klick auszuwählen und zu entsperren.
Die Oberfläche ist minimal, aber extrem effektiv. Es ist keine serverseitige Überprüfung erforderlich: Der Vorgang findet vollständig zwischen Smartphone und Fahrrad statt.
5. Systemische Schwächen
BLE:
- Statische Schlüssel: keine Rotation, Neugenerierung oder Challenge-Response
- Blindes Akzeptieren: das Fahrrad akzeptiert gültige Befehle von jedem BLE-Gerät
- Fehlende Verschlüsselung auf BLE-Ebene
API:
Auch die Serverseite wies Schwächen auf:
- Möglichkeit, HTTPS-Anfragen zu sniffen und zu manipulieren (nach Patching mit Frida/Apktool)
- Im Blog erwähnte Techniken umfassen:
- Sofortige Sperrung nach dem Entsperren, um die Gebühr zu minimieren
- Standort-Spoofing
- Senden von fiktiven Fehlern, um das Fahrrad als defekt zu melden
- Hijacking aktiver Sitzungen
6. Konkrete Auswirkungen
- Entwendete Fahrräder: über 1.600 in Bologna im Sommer 2023
- Direkte wirtschaftliche Schäden: nicht wiederherstellbar
- Hohes Risiko der Reproduzierbarkeit: Code ist öffentlich verfügbar
Dies war kein einfacher Proof-of-Concept. Es war eine weit verbreitete Operation mit realen und nachvollziehbaren Auswirkungen.
7. Abschließende Überlegungen
Dieser Angriff zeigt, wie wichtig es ist, den gesamten Sicherheits-Stack zu betrachten: Es reicht nicht aus, den Server zu schützen, wenn das BLE vollständig exponiert ist. Smart-Mobility-Systeme können, wenn sie nicht angemessen geschützt sind, von Akteuren mit mittleren technischen Fähigkeiten deaktiviert, manipuliert oder repliziert werden.
Empfehlungen für Anbieter:
- Verwendung von BLE mit gegenseitiger Authentifizierung (z. B. ECDH)
- Dynamische Schlüsselgenerierung
- Serverseitige Überprüfung von BLE-Befehlen
- Härtung der App: Verschleierung (Obfuscation), Integritätsprüfung, TLS-Pinning
Dieser Fall sollte als emblematisches Beispiel für „Insecurity by Design“ betrachtet werden. Die Transparenz des Angriffs, gepaart mit der von den Autoren explizit gemachten politischen Motivation, macht ihn zu einem gleichermaßen technischen wie sozialen Dokument.
Analyse erstellt von IT-Sicherheitsexperten zu Studien-, Audit- und Schulungszwecken.
Leave a Reply