Infizierte Drohnen

Angriffsvektoren, Schwachstellen und Exploits von Drohne zu Bodenkontrollstation

Drohnenflotten bestehen heute aus einem Operator, der Dutzende oder Hunderte von Drohnen von einer einzigen Bodenstation aus fliegt. Dadurch wird die Bodenkontrollstation zu einem wertvollen Ziel für Angreifer. Dort befindet sich üblicherweise der Pilot, dort werden oft Missionsdaten gespeichert, und sie ist ein erstklassiger Vektor für laterale Bewegung über UxS-Netzwerke und andere Drohnen in einer Flotte.

Der Großteil der Drohnensicherheitsforschung hat sich auf die Drohne als Ziel konzentriert. Die Infected Drone-Forschung wählt einen alternativen Ansatz und zeigt, wie eine einzelne kompromittierte Drohne Bodenstationen angreifen kann, die sich mit ihr verbinden. Da die meiste Bodenkontrollsoftware allem vertraut, was die Drohne sendet, fehlen Authentifizierung, Validierung und Sanitisierung, wodurch Daten von einer kompromittierten Drohne zu Datei-CRUD, Codeausführung oder einem Absturz auf dem Rechner des Operators führen können.

---

Verantwortungsvolle Nutzung

Dieses Repository dokumentiert Schwachstellen in Bodenkontrollstationssoftware und liefert funktionierenden Proof-of-Concept-Code dafür. Es wird ausschließlich zu Bildungszwecken veröffentlicht und damit Operatoren ihre Exposition verstehen und Maintainer diese Probleme reproduzieren und beheben können.

Führe die PoCs nur gegen Systeme aus, die dir gehören oder für die du eine schriftliche Testgenehmigung hast. Jeder einzelne davon ist für einen Prüfstand geschrieben: Die Payloads sind harmlose Marker, und nichts hier ist für den Einsatz gegen die Luftfahrzeuge oder Bodenstationen anderer Personen paketiert. Die Verwendung dieses Materials gegen Systeme, die du nicht kontrollierst, ist wahrscheinlich illegal, wo auch immer du dich befindest.

Der Abschnitt „Reproduction" jedes Findings gibt an, was es benötigt und was es tut. Lies ihn, bevor du irgendetwas ausführst.

---

Findings

Legende:

• ✅ zuverlässig mit diesem Vektor
• ⚠️ möglich, aber bedingt, racy oder erfordert zusätzliche Schritte
• ❌ nicht anwendbar für dieses Finding über diesen Vektor

Die Delivery-Klasse beschreibt, was der Angreifer auf der Verbindung tun muss, und sie entscheidet, welche Vektoren funktionieren. Push-Findings benötigen lediglich ein Frame, das an der GCS ankommt, sodass jeder injektionsfähige Vektor ausreicht. Handshake- und Request/Response-Findings erfordern, dass der Angreifer der kommunizierende Peer ist oder diesen vollständig kontrolliert, was ein On-Bus-Peripheriegerät, einen kompromittierten Companion, die Lieferkette oder einen vollständigen MITM begünstigt.

Die Spalte Fix verlinkt den Upstream-Pull-Request, sofern einer eingereicht wurde. Zehn der fünfzehn Findings werden mit einem Patch ausgeliefert, der gegen das Repository des Herstellers selbst eingereicht wurde.

---

Delivery-Vektoren

Die Matrix bewertet sieben Spalten pro Finding: die fünf untenstehenden Vektoren plus die beiden SiK-Funk- (RF-Telemetrie-)Modi, die angesichts der Injektion-vs-MITM-Nuance unten einen eigenen Abschnitt erhalten.

1. Infizierter Flight Controller, serielle Verbindung oder Lieferkette. Ein lokaler Angreifer oder ein bösartiger Flight Controller wird physisch mit dem GCS-Host oder dem Funkgerät verbunden. Das Luftfahrzeug oder die Firmware ist etwas, das der Operator nicht gebaut hat: eine Demo-Einheit, ein Mietgerät, ein beschlagnahmtes Luftfahrzeug oder ein gebrauchtes Fluggerät, dessen Firmware implantiert wurde, um feindseliges MAVLink zu senden, sobald sich eine GCS verbindet. Die eigene GCS des Operators ist das Opfer; das „Luftfahrzeug" war feindselig, bevor es überhaupt eingeschaltet wurde. Gilt für jedes Finding und ist der sauberste Weg, um Connect-Time-Handshake-Exploits zu liefern. Dies erstreckt sich auf Forensik-Analysten, die sich möglicherweise direkt mit einem infizierten Luftfahrzeug verbinden oder Daten daraus extrahieren. Diese Artefakte könnten, wenn sie nicht ordnungsgemäß behandelt werden, den Computer und das Netzwerk des Analysten infizieren oder sich darauf ausbreiten.

2. Bösartiges / gefälschtes MAVLink-Peripheriegerät am eigenen Bus des Luftfahrzeugs. Eine Drittanbieter-Kamera, ein Gimbal, ADSB-in, ein Entfernungsmesser oder jedes Gerät, das MAVLink spricht und selbst der Angreifer ist. Es ist ein legitimer Teilnehmer auf der Verbindung, der feindselige Frames sendet. Eine gefälschte „Smart Camera", die vergiftete Nachrichten ankündigt, tut genau das, was eine echte tut, nur mit feindseligen Werten.

3. Kompromittierter Companion-Computer an Bord (Raspberry Pi / Jetson mit mavlink-router / MAVProxy). Einmal kompromittiert, wird er zum Luftfahrzeug-Endpunkt, mit vollem bidirektionalem Zugriff auf die Verbindung und Sichtbarkeit ihres Live-Zustands. Er kann jeden Handshake beantworten und jedes Push-Frame senden, was ihn für jedes Finding in diesem Set nutzbar macht.

4. WiFi-/UDP-Telemetrie-Bridge (ESP8266 / ESP32 „Wifi-Telemetrie"). Jeder im Access Point oder LAN kann MAVLink-Daten injizieren. Dies senkt die Kosten der Injektionsvektoren auf nahezu null und ermöglicht für einen Angreifer, der auch abfangen kann (ARP/AP-MITM), zusätzlich volle Handshake-Kontrolle.

5. TCP-/Cloud-Relay (SITL, mavlink-router TCP, mavp2p, 4G/LTE-Cloud-GCS wie kommerzielle UAV-Cloud-Dienste). MITM am Relay oder jeder, der den exponierten TCP-Port erreichen kann, kann den Stream umschreiben. Cloud-/4G-Verbindungen vergrößern den geografischen Wirkungsradius enorm und entbehren häufig gegenseitiger Authentifizierung.

SiK-Funk (RF-Telemetrie-Verbindung)

Der dominierende echte RF-Telemetriepfad für ArduPilot/PX4-Hobby- und Prosumer-Fluggeräte ist ein SiK-Funkgerätepaar, eine transparente serielle Bridge, die MAVLink weder parst noch validiert, sodass sie der GCS keinerlei Schutz gegen feindselige Inhalte bietet. Ein bösartiges SiK-Modul tritt einer bestehenden Verbindung bei oder überbrückt sie mit sikw00f. Zwei Angriffsmodi mit sehr unterschiedlicher Zuverlässigkeit:

• Injektion (ein bösartiges Funkgerät). sikw00f kann feindselige Frames auf den gemeinsamen Kanal senden, sobald es mit der Verbindung synchronisiert ist. Zuverlässig für One-Shot-Push-/Stream-Nachrichten (STATUSTEXT, PARAM_VALUE, CAMERA_INFORMATION usw.), keine Antwort nötig. Unzuverlässig für Handshake- Protokolle (MAVFTP, Parameter-/Log-Download), da der Injector ein Airtime- Race gewinnen und eine Session/Sequenz treffen muss, die er nicht kontrolliert.
• Full-MITM (bösartiges Paar). Zwei sikw00f- Funkgeräte, eines zur GCS, eines zum Luftfahrzeug, um Frames im Flug zu überbrücken und umzuschreiben (optional nach Jamming, um eine Neu-Assoziierung zu erzwingen). Dies besitzt die gesamte Konversation und erfüllt daher auch zuverlässig Handshakes.

Hinweis: SiK-Verschlüsselung (AES-128, wo unterstützt) ist standardmäßig deaktiviert und verwendet einen statischen gemeinsamen Schlüssel.