Zu Lande, zu Wasser und in der Luft

Embedded Systems: Angriffe auf Autos, Flugzeuge & Co.
Kommentare

Das Internet of Things und speziell eingebettete Systeme erobern immer mehr Bereiche oder besser Geräte unseres Lebens. Neben Autos sind vernetzte IoT-Devices auch in immer mehr Schiffen und Flugzeugen anzutreffen. Das Problem: Auch potenzielle Angreifer machen mobil. Wie sieht es also mit Attacken auf Embedded Systems und der Sicherheit von Autos, Schiffen und Flugzeugen aus?

Fangen wir gleich mit etwas Praktischem an: Theoretischen Angriffen hängt ja immer der Hauch des „Ach, das ist nur Schwarzmalerei, das wird ja nie passieren“ an. Bis es dann doch irgendwann passiert. Und mal wieder niemand damit gerechnet hat. Oder alle ja schon immer davor gewarnt haben. Also, los geht es.

Ein Drittel Autodiebstähle mittels IT

Ein Drittel der Autodiebstähle in London sind laut dem britischen Innenministerium inzwischen IT-basiert. Die Diebe nutzen dafür unter anderem spezielle Geräte, mit denen sie den Code des Autoschlüssels ausspähen, während der vom Fahrer benutzt wird. Die Daily Mail hat die britische Innenministerin Theresa May am 3. September dazu mit der Aussage zitiert: „Car thieves might break into a car and programme a new electronic key. They might use sophisticated devices to ‘grab’ the security coding when the owner uses the key so they can use it themselves.“

Erste Berichte über entsprechende Diebstähle gab es schon sehr früh. Bereits im Dezember 2005 hatte die US-amerikanische Fachzeitschrift Consumer Reports vor Angriffen auf RFID-basierte Zugangssysteme und Wegfahrsperren für Autos gewarnt. Auslöser war eine Untersuchung der Sicherheit solcher Systeme auf Basis des weit verbreiteten DST-RFID-Tags von Texas Instruments durch Forscher der Johns Hopkins University in Baltimore und von RSA Security. Da die Tags einen nur 40 Byte langen Schlüssel verwenden, sind Brute-Force-Angriffe möglich. Ein Teil der Sicherheitssysteme von Autos konnte von den Forschern ausgehebelt werden.

2006 gab es Berichte über tatsächliche Diebstähle. Damals sollen zum Beispiel David Beckham zwei BMW X5 mit „software programs on a laptop to wirelessly break into the car’s computer, open the doors, and start the engine“ gestohlen worden sein. Kontroverse Diskussionen der Meldung gibt es zum Beispiel auf Slashdot und in Bruce Schneiers Blog. Ob die Diebe 2005 wirklich die kompletten Schutzmaßnahmen mittels Software umgangen haben oder ob nicht vielleicht doch noch andere, herkömmliche Mittel zum Einsatz kamen, wurde wohl nie geklärt. 2012 wurden jedenfalls komplette Kits zum Stehlen von Fahrzeugen für 30 Dollar im Internet verkauft.

Von der Praxis zur Theorie

Zumindest ein Teil der möglichen Angriffe hat also bereits den Weg in die Realität gefunden. Meist machen die Autohersteller es den Angreifern auch leicht, denn das Thema „Sicherheit“ wird ziemlich klein geschrieben. Nehmen wir zum Beispiel den Tesla Model S – ein Auto, das sich über eine iOS-App (Abb. 1) unter anderem lokalisieren und aufschließen lässt (und inzwischen auch starten, aber das war bei Bekanntwerden der folgenden Schwachstelle noch nicht möglich).

Abb. 1: Mithilfe der passenden iOS-App lässt sich der Tesla Model S unter anderem aufschließen (© 2002-2010 Tesla Motors, Inc. Alle Rechte vorbehalten)

Abb. 1: Mithilfe der passenden iOS-App lässt sich der Tesla Model S unter anderem aufschließen (© 2002-2010 Tesla Motors, Inc. Alle Rechte vorbehalten)

Ein Luxusauto ohne den Luxus der IT-Sicherheit

Das einzige, was man dafür wissen muss, ist das passende Passwort – und das muss nur sechs Stellen haben, darunter mindestens eine Zahl und ein Buchstabe. Das ist nur eine von mehreren Schwachstellen, die Nitesh Dhanjani im März 2014 veröffentlicht hat. Das Passwort wird auch auf der Tesla-Website verwendet (Abb. 2), auf der es keinen Schutz vor Brute-Force-Angriffen gibt. Und sechs Stellen lassen sich mittels Brute Force durchaus noch knacken. Außerdem sind natürlich Phishing- und Schädlingsangriffe möglich, um das Passwort auszuspähen.

Abb. 2: Auf der Tesla-Website wird das gleiche Passwort verwendet wie in der iOS-App (Screenshot: https://www.teslamotors.com/de_DE/user/login)

Abb. 2: Auf der Tesla-Website wird das gleiche Passwort verwendet wie in der iOS-App (Screenshot: https://www.teslamotors.com/de_DE/user/login)

Die iOS-App verwendet für die Kommunikation ein REST-API, dass zwar eigentlich nicht für die Benutzung durch Drittanbieter vorgesehen ist, aber trotzdem bereits von anderen Apps genutzt wird. Die dann natürlich auch die Tesla-Zugangsdaten des Benutzers kennen müssen. Weitere potenzielle Schwachstellen sind die WiFi-Verbindung des Autos und ein Anschluss im Fahrzeug, über den auf das lokale Netzwerk zugegriffen werden kann. Letzteres ist natürlich nur gefährlich, wenn ein Angreifer in das Fahrzeug gelangt. Aber das ist ja durch das kurze Passwort kein unüberwindbares Problem. Und wo das Fahrzeug sich gerade befindet, lässt sich über die iOS-App ebenfalls herausfinden.

Nach der Veröffentlichung der Schwachstellen hat Tesla zumindest schon mal die Anforderungen an das Passwort erhöht, nun müssen es acht Zeichen sein, darunter weiterhin mindestens eine Zahl und ein Buchstabe. Außerdem werden die Benutzer nun nach fünf Fehlversuchen ausgeloggt. Was hoffentlich nur ungünstig ausgedrückt oder falsch übermittelt wurde, denn der Angreifer ist ja hoffentlich nie eingeloggt gewesen.

CAN und ECU im Auto

Die Embedded-Systeme, die für die Steuerung und Überwachung aller möglichen Funktionen des Fahrzeugs zuständig sind, werden Electronical Control Units (ECU) genannt. Da viele Features die Zusammenarbeit mehrerer ECUs oder von ECUs und Sensoren nötig machen, müssen diese miteinander gekoppelt werden. Dazu dient das Controller Area Network (CAN). Meist enthalten die Autos sogar mehr als einen Bus auf Basis des CAN. So kann zum Beispiel ein Highspeed-Bus für die Übertragung von Echtzeittelemetriedaten zuständig sein und ein langsamerer für die Steuerung von Beleuchtung und Türschlössern. Diese Busse müssen auch untereinander Daten austauschen und daher miteinander verbunden sein. Zum Beispiel muss die Zentralverriegelung die physikalischen Türschlösser und die drahtlosen Daten eines entfernten Schlüssels überwachen, aber auch mit sicherheitskritischen Komponenten wie den Airbags verknüpft sein, um nach dem Auslösen der Airbags bei einem Unfall die Türschlösser zu öffnen.

Dabei verwendet jeder Hersteller eigene Befehle, die sich sogar von Modell zu Modell unterscheiden können. Es gibt also keine universellen Befehle, mit denen sich eine Aktion in jedem beliebigen Auto steuern lässt. Außerdem werden die Daten nach den Vorgaben der einzelnen Hersteller formatiert, die sich wiederum von Fahrzeug zu Fahrzeug unterscheiden können. Es ist also nicht mal möglich, die Daten identisch zu parsen – alles muss immer ans jeweilige Fahrzeug angepasst werden.

CAN kann Schwachstellen haben (und hat welche)

Vom Center for Automotive Embedded Systems Security (CAESS), in dem Forscher der University of California San Diego und der University of Washington zusammenarbeiten, wurde 2010 die Kommunikation auf dem CAN-Bus eines nicht genannten Autos analysiert und auf mögliche Schwachstellen untersucht. Dazu verwendeten sie einen selbst entwickelten CAN-Bus-Analyzer samt Packet-Injection-Tool, genannt CarShark. Bei den Untersuchungen wurden verschiedene Möglichkeiten für einen Angriff entdeckt.

Wer kontrolliert den CAN-Bus?

Alberto Garcia Illera und Javier Vazquez Vidal haben Ende März auf der Black Hat Asia 2014 das CAN Hack Tool (CHT) vorgestellt, mit dem sich die Daten auf dem CAN-Bus aufzeichnen und eigene Daten einschleusen lassen. Die Hardware basiert auf einem Arduino Mini Pro, die Gesamtkosten dafür belaufen sich auf unter 30 US-Dollar. Mittels Statistical Analysis lassen sich die Daten auswerten und die verfügbaren Befehle ermitteln. Als möglicher Angriff wird das Übernehmen einer ID beschrieben, dadurch kann sich der Angreifer als die entsprechende ECU ausgeben. Zusätzlich haben Alberto Garcia Illera und Javier Vazquez Vidal beschrieben, wie sich die bei einem Unfall gespeicherten Daten auslesen und analysieren lassen.

Wer den CAN-Bus kontrolliert, kontrolliert die Bremsen (und mehr)

Bereits im August 2013 haben Charlie Miller und Chris Valasek auf der DefCon 21 (und davor) andere Angriffe auf und über den CAN-Bus demonstriert. So ist es (sofern entsprechende Hardware an den CAN-Bus angeschlossen wird) zum Beispiel möglich, die Bremsen ein- oder auszuschalten, die Lenkung zu manipulieren, die Geschwindigkeitsanzeige beliebige Werte anzeigen zu lassen oder zu hupen.

Das Ganze haben die beiden Forscher dem Reporter Andy Greenberg von Forbes demonstriert. Greenberg fuhr einen Ford Escape, auf dessen Rücksitz die beiden Forscher saßen. Mithilfe ihrer mit den Autonetzen verbundenen Macbooks manipulierten sie die ECUs über den CAN-Bus. Beim Tritt auf die Bremse passierte daraufhin gar nichts, und die Fahrt endete in einigen Büschen am Rande des leeren Parkplatzes, auf dem die Demonstration stattfand. Ebenso kann die Lenkung manipuliert werden – statt den Fahrer beim Einparken zu unterstützen, lenkt die Einparkhilfe dann den Wagen womöglich bei hohem Tempo in den Gegenverkehr oder Graben.

Mit Autosystemen experimentieren muss nicht teuer sein

Auf der SySCan Singapore im April 2014 haben Charlie Miller und Chris Valasek beschrieben, wie man Autos hacken kann, ohne dafür die teuren Autos kaufen zu müssen: Man experimentiert einfach mit den einzeln gekauften ECUs. Dafür müssen natürlich auch entsprechende Sensoren angeschlossen oder emuliert werden. Mit etwas Bastelei lässt sich so aber quasi ein Auto emulieren, das dann gehackt werden kann. Um den Hack zu testen, kann man solche Vorrichtungen zum Beispiel in ein Kart einbauen.

Drahtlos ist schlimmer, und schlimmer geht immer

Schon als kleine Kinder lernen wir, dass Funkfernsteuerungen viel mehr Spaß machen als Kabelgebundene, bei denen man immer dem Auto hinterherrennen muss. Das gilt natürlich auch bei den „Großen“: Die oben beschriebenen Angriffe über den CAN-Bus sind ja recht eindrucksvoll, erfordern aber auch den Anschluss entsprechender Hardware. Die gleichen Angriffe sind aber auch drahtlos möglich. Vom bereits erwähnten CAESS wurden schon 2011 entsprechende Forschungsergebnisse veröffentlicht.

Ziel der Untersuchungen war die Ermittlung möglicher Angriffe ohne direkten Zugriff auf die internen Netzwerke. Und die sind über eine Vielzahl von Angriffsvektoren möglich: mit indirektem physikalischen Zugriff auf die Bordnetze über On-Board Diagnostics (OBD2) und die Entertainmentsysteme des Autos (CD, USB, iPod). Die OBD2 hat selbst vollständigen Zugriff auf den CAN-Bus und wird über Windows-Rechner konfiguriert. Darauf eingeschleuste Schadsoftware kann über die OBD2 die ECUs im Auto manipulieren (Abb. 3). Die Entertainmentsysteme können über präparierte Medien kompromittiert werden, und wenn sie an den CAN-Bus angeschlossen sind, können durch den eingeschleusten Schadcode auch die ECUs manipuliert werden. Drahtlos sind über Kurzstrecken (fünf bis 300 Meter Reichweite) Angriffe über Bluetooth, das Remote-Keyless-Entry-System, die Reifendrucksensoren, und RFID-Schlüssel möglich. Über längere Strecken kann der Angriff zum Beispiel über GPS, Radio (Radio Data System oder kurz RDS) und Traffic Message Channel (TMC) und die Telematikkanäle der Autos erfolgen. Für alle Angriffsvektoren wurden funktionsfähige Angriffe entwickelt, bei denen jeweils die vollständige Kontrolle über den CAN-Bus erlangt wurde.

Abb. 3: Die verschiedenen Bordnetze eines modernen Autos im Überblick. Die Farben zeigen eine grobe Gruppierung der diversen ECUs nach Funktion (© USENIX Security 2011: „Comprehensive Experimental Analyses of Automotive Attack Surfaces“)

Abb. 3: Die verschiedenen Bordnetze eines modernen Autos im Überblick. Die Farben zeigen eine grobe Gruppierung der diversen ECUs nach Funktion (© USENIX Security 2011: „Comprehensive Experimental Analyses of Automotive Attack Surfaces“)

Das Kabel kappen

Auf der Black Hat USA im August 2014 haben Charlie Miller und Chris Valasek ihre schon 2013 gezeigten Angriffe um die drahtlose Durchführung erweitert. Die Angriffe sind die gleichen geblieben – nur dass sie nun nicht mehr über ein Kabel, sondern zum Beispiel per Bluetooth erfolgen. Indem sie Schwachstellen in den jeweiligen Implementierungen ausnutzen, verschaffen sie sich Zugriff auf die Bordnetze und schleusen darüber ihre Exploits für die ECUs und Ähnliches ein.

In einem Paper zum Vortrag geben die beiden Forscher einen Überblick über die Angriffsfläche einer Vielzahl von Automodellen. Besonders gefährlich wird es, wenn Webbrowser und ähnliche Programme Einzug in die Autos halten. Die sind den Cyberkriminellen gut bekannt, sie wissen genau, wie sie Schwachstellen darin ausnutzen können. Und wenn sie erst mal über den Exploit für den Browser den virtuellen Fuß in der Tür haben, können sie von da aus weiter zum CAN-Bus und den ECUs vorstoßen. Wir wissen ja alle, wie oft Schwachstellen im Browser gefunden und behoben werden. Passiert das dann auch im Auto? Oder fahren die dann etliche Jahre mit uralten Schwachstellen herum?

Schutz ist möglich, zum Beispiel per IPS…

Charlie Miller und Chris Valasek schlagen auch Schutzmaßnahmen gegen Angriffe vor. Im Grunde muss man ja nur die bewährten Schutzmaßnahmen der IT entsprechend angepasst auf die Netze und Computer der Autos übertragen.

Außerdem haben die beiden ein Anti-Hacking-Device auf Basis eines mbed-NXP-Microcontrollers entwickelt, das knapp 150 US-Dollar kostet und über den OBD2-Port mit dem Netzwerk des Autos verbunden wird. Das Device funktioniert wie ein Intrusion-Prevention-System: Erst werden für ca. eine Minute die üblichen Datenmuster des Fahrzeugs erfasst, danach Angriffe durch auffällige Änderungen erkannt. Wird ein Angriff festgestellt, wird das Fahrzeug bis zu einem Neustart in einen reduzierten „Limp Mode“ versetzt, in dem im Wesentlichen das Netzwerk heruntergefahren wird und potenziell gefährliche Funktionen wie die Manipulation der Lenkung deaktiviert werden. Charlie Miller und Chris Valasek werden das Device jedoch nicht verkaufen, es soll nur zeigen, dass eine Abwehr der Angriffe möglich ist. Wenn die beiden so eine Sicherheitsmaßnahme für 150 US-Dollar realisieren können, sollten die Autohersteller es noch deutlich billiger hinbekommen.

…oder Firewall

Eine Firewall als Schutz vor Angriffen wurde im Juni 2014 von Pk001 (Kai Peng) und Wayne Yan auf der SyScan360 vorgeschlagen. In ihrem Vortrag haben sie zuvor einen Überblick über Aufgaben und Funktionsweise von OBD2, ECU und CAN-Bus gegeben sowie mögliche Angriffe vorgestellt. Kommen wir von den Autos zu den Schiffen. Zur Sicherheit von Schiffen gibt es nur relativ wenig Untersuchungen. Zumindest bisher. Dafür sind die möglichen Angriffe nicht zu verachten. Vor allem, da sie teilweise auch aus der Ferne möglich sind.

Vertraue nie dem GPS

Im Juni 2013 kam eine Yacht im Mittelmeer vom gewünschten Kurs ab, ohne dass ein Alarm ausgelöst wurde. Das Steuersystem war der Meinung, auf dem richtigen Kurs zu sein, und richtete sich dabei nach den Positionsdaten, die von der GPS-Ausrüstung des Schiffs geliefert wurden. Die waren aber gefälscht und stammten von einigen Forschern der Cockrell School of Engineering der University of Texas Austin, die an Bord waren, um die Auswirkungen der gefälschten GPS-Signale zu untersuchen. Nachdem die Yacht etwas vom Kurs abgebracht worden war, erkannte das Navigationssystem den Fehler, der von der Crew korrigiert wurde. Nur dass diese sich ebenfalls auf die gefälschten GPS-Signale verließ, sodass der Kurs eben doch nicht stimmte. So zeigte zum Beispiel das Navigationssystem einen geraden Kurs an, während das Schiff tatsächlich eine Kurve fuhr.

Dieser Angriff ist nur aus der Nähe oder mit größerem Aufwand möglich, da die falschen GPS-Signale die echten überlagern müssen. Aber auch aus der Ferne und sogar über das Internet sind Angriffe auf Schiffe möglich.

Angriffsziel Automatic Identification System (AIS)

Im Oktober 2013 haben Marco Balduzzi, Kyle Wihoit und Alessandro Pasta auf der Hack in the Box Malaysia unter dem schönen Titel „Hey Captain, Where’s Your Ship? Attacking Vessel Tracking Systems for Fun and Profit“ einen Vortrag über Schwachstellen in und Angriffe auf das Automatic Identification System (AIS) gehalten. Das System ist für internationale Frachtschiffe ab einer Tonnage von 300 Tonnen und alle Passagierschiffe Pflicht.

AIS verwendet GPS-Koordinaten und tauscht mit Schiffen in der Nähe, Stationen an Land (Häfen und Verkehrsüberwachungsstellen) sowie Internetdienstleistern für Tracking und Visualisierung von Schiffsbewegungen die Schiffsposition, den aktuellen Kurs und weitere Informationen aus. Die Übertragung erfolgt über Funk und online. Die Online-AIS-Provider kommunizieren über Mobile-Apps, E-Mail, Software und regional über Funk-Gateways. Schwachstellen wurden sowohl in den Implementierungen der Onlineprovider als auch im Protokoll selbst gefunden. Fehlende Authentifizierung, fehlende Integritätsprüfungen sowie fehlende Prüfungen von Zeit (gegen Replay-Angriffe) und Gültigkeit der Daten erlauben es, falsche Positions- und Kursinformationen, Warnungen, Alarmmeldungen und Wetterdaten einzuschleusen, auf die das Schiff dann ggf. automatisch reagiert.

Fortsetzungen des Vortrags mit neuen Schwachstellen und Angriffen gab es auf der Black Hat Asia im März 2014 sowie der Hack in the Box Amsterdam im Mai 2014. Sie kennen vielleicht den alten Witz, in dem der Navigator die Positionsberechnungen seines Schülers prüft und ihn dann auffordert, den Hut abzunehmen, weil man gerade in den Petersdom, den Kölner Dom oder welche Kirche auch immer einlaufen würde. Schiffe können zwar immer noch nicht über Land fahren, über einen Angriff auf das AIS ist es aber möglich, zumindest die Positionsmeldung entsprechend zu verfälschen (Abb. 4). In den Fortsetzungsvorträgen wurde gezeigt, wie ein Schlepper sich statt im Golf von Mexiko plötzlich anscheinend mitten in Dallas befand. Es ist auch möglich, ein Schiff völlig aus der Wahrnehmung des AIS verschwinden zu lassen. Damit lässt sich sicher Schindluder treiben.

Kommen wir von den Schiffen zu den Flugzeugen. Angriffe darauf sind vor allem durch Hugo Tesos Vorträge bekannt geworden, mit denen ich daher auch beginne.

Abb. 4: Mario Balduzzi und Allessandro Pasta demonstrierten auf dem Hack in the Box Amsterdam im Mai 2014, wie für ein Schiff ein neuer Kurs gesetzt wird (© Mario Balduzzi)

Abb. 4: Mario Balduzzi und Allessandro Pasta demonstrierten auf dem Hack in the Box Amsterdam im Mai 2014, wie für ein Schiff ein neuer Kurs gesetzt wird (© Mario Balduzzi)

2013: Panik – Flugzeuge können gehackt werden!

Den ersten Vortrag zum Thema hat jener Hugo Teso, ein Security Consultant und Berufspilot, im April 2013 auf der Hack in the Box Amsterdam gehalten. Er hat das Aircraft Communications Addressing and Report System (ACARS) und die Flight Management Systems (FMS) verschiedener Hersteller auf mögliche Schwachstellen untersucht. Das ACARS dient dazu, das FMS im Cockpit mit Informationen über das aktuelle Wetter, Änderungen am Flugplan und Ähnlichem zu versorgen. Sowohl ACARS als auch FMS enthalten Schwachstellen. Da das FMS die Daten für den Autopiloten liefert, lässt der sich darüber mit falschen Daten manipulieren. Mögliche Ziele können über den so genannten Automatic Dependent Surveillance Broadcast (ADS-B) ermittelt werden, der laufend Informationen über die Identität des Flugzeugs, seine aktuelle Position und Höhe sowie andere Daten ausstrahlt, die von Bodenstationen empfangen werden. Flugzeuge in der Nähe können darüber außerdem Flug-, Verkehrs- und Wetterinformationen austauschen.

Für seine Untersuchungen hat Hugo Teso aus Hardware (teilweise echter, gebraucht gekaufter Flugzeugsysteme) und Software ein System zusammengestellt, mit dem er die Kommunikation zwischen Flugzeugen und Bodenkontrollsystemen simulieren und Angriffe auf die gefundenen Schwachstellen testen kann. Für die Angriffe entwickelte er ein Exploit Framework (SIMON) und eine Android-App (PlaneSploit). Die unter diesen Laborbedingungen erfolgreichen Angriffe lassen sich zumindest theoretisch auch auf echte Flugzeuge übertragen, für die ACARS-Kommunikation mit dem Flugzeug kann zum Beispiel ein Software-Defined-Radio verwendet werden. Eine praktische Überprüfung war Hugo Teso natürlich nicht möglich.

Die zuständigen Behörden wie European Aviation Safety Agency (EASA) und Federal Aviation Administration (FAA) haben sich beeilt und versichert, dass die Angriffe auf echte Flugzeuge natürlich nicht möglich sind. Das hat Hugo Teso allerdings nicht davon abgehalten, im Oktober 2013 auf der Hack in the Box Malaysia weitere Schwachstellen und Angriffe vorzustellen. Darüber hinaus waren Hugo Tesos Vorträge nicht die ersten Berichte über mögliche Angriffe auf Flugzeuge. Bereits im Juni 2012 hat Brad „RenderMan“ Haines Angriffe auf Flugzeuge beschrieben. Im Gegensatz zu Hugo Teso hat er keine Verbindung zur Fliegerei, sondern ist über die Angebote zum Tracken von Flugzeugen angelockt worden. Das Tracking erfolgt mit den über ADS-B übertragenen Informationen, die auch von Hugo Teso genutzt wurden. Die Tracking-Angebote hatten Brad Haines Forschergeist geweckt. Allerdings hat auch er nur theoretisch geforscht.

Da ADS-B ohne Verschlüsselung und Autorisierung arbeitet, kann jeder die übertragenen Daten empfangen und auswerten. Ein Beispiel für die freie Auswertungen ist die Webseite http://flightradar24.com, deren Informationen auf den ADS-B-Daten basieren (Abb. 5). Aufgrund der fehlenden Verschlüsselung können falsche Daten eingeschleust werden und zum Beispiel „Geisterflugzeuge“ (oder -flüge) generiert oder verwirrende Daten im Cockpit angezeigt werden. Über GPS-Spoofing lassen sich auch falsche Positionsdaten einschleusen. Und weil ich gerade beim GPS-Spoofing bin: Die gleichen Forscher, die 2013 über gefälschte GPS-Daten die Yacht vom Kurs abbrachten, brachten 2012 mit der gleichen Methode eine Drone vom Kurs ab.

Im August 2014 hat Ruben Santamarta auf der Black Hat USA dann Angriffe auf SATCOM-Terminals zur Satellitenkommunikation beschrieben. Ein erstes Whitepaper zum Thema hatte er bereits im April 2014 veröffentlicht. Die untersuchten Systeme enthalten alle Schwachstellen, über die sie vollständig kompromittiert werden können. Da sie auch in Flugzeugen eingesetzt werden, können auch diese darüber angegriffen werden. Theoretisch kann ein Angreifer über die Entertainmentsysteme oder On-Board-Wifi auf die Satellitenkommunikation und damit eventuell auch auf die Steuerung des Flugzeugs zugreifen.

Abb. 5: Die Webseite flightradar24.com nutzt ADS-B als Datenquelle. Hier der Himmel über Frankfurt am Main, wie flightradar24 ihn sieht (Quelle: Screenshot http://flightradar24.com)

Abb. 5: Die Webseite flightradar24.com nutzt ADS-B als Datenquelle. Hier der Himmel über Frankfurt am Main, wie flightradar24 ihn sieht (Quelle: Screenshot http://flightradar24.com)

2014: Kein Grund zur Panik, Flugzeuge können nicht gehackt werden

Auf der DefCon 22 im August 2014 haben Dr. Phil Polstra und Captain Polly Kadolph dann das genaue Gegenteil der anderen Forscher behauptet, nämlich dass die ganzen Angriffe nicht möglich sind. Phil Polstra ist Hardware- und Flugexperte mit zwölf Fluglizenzen, Captain Polly Kadolph ehemalige Pilotin von Passagiermaschinen und jetzige Professorin für Luftfahrt. Im Grunde läuft alles darauf hinaus, dass der Pilot immer das letzte Wort hat und es im Ernstfall für jedes IT-gesteuerte System mechanische Backup-Systeme gibt. Ein Angreifer könnte also vielleicht den Autopiloten manipulieren, der Pilot diese Manipulation aber auf verschiedenen Wegen rückgängig machen. Oder eben das Flugzeug selbst fliegen. Außerdem sind die verschiedenen Systeme und Netze im Flugzeug weitestgehend voneinander isoliert und Übergänge oft nur in eine Richtung möglich. Zum Beispiel werden die Positionsdaten von der Positionsbestimmung zur Anzeige in der Kabine gesendet, es gibt aber keine Verbindung in die Gegenrichtung.

Was die Angriffe über die Satellitenkommunikation betrifft, reicht die alleinige Manipulation dieser Daten für einen Angriff kaum aus, da die Flugzeuge auch normale Funkverbindungen nutzen und der Pilot im Zweifelsfall bei merkwürdigen Anweisungen nachfragen würde. Womit natürlich nicht geklärt wäre, wie es mit über die kompromittierte Satellitenkommunikation eingeschleustem Schadcode aussieht. Die Bordcomputer werden ja wohl kaum über Funk bei den Bodenstationen nachfragen, ob sie den erhaltenen Exploit ausführen sollen.

Fazit

Erinnern Sie sich noch an die Sprüche, die früher immer in den Lizenzbedingungen und ähnlichen Texten standen? Dass die Software ja von Menschen programmiert wurde und daher Fehler enthält? Steht das eigentlich immer noch drin? Ich habe diese Bedingungen schon ewig nicht mehr gelesen. Worauf ich hinaus will, ist auch etwas anderes: Jedes Programm enthält Fehler, und einige dieser Fehler lassen sich für Angriffe ausnutzen. Das nennt man dann Schwachstelle oder Verwundbarkeit (Vulnerabilitiy). Das gilt im „Großen“ auf Desktop und Server ebenso wie im „Kleinen“ auf Smartphone und Tablet. Es gilt natürlich auch für die Software im IoT – und zwar in jedem Geräte, egal ob in Autos, in Schiffen oder in Flugzeugen. Die erste Frage ist, ob ein Angreifer genau die Schwachstelle findet, die er ausnutzen will? Die zweite Frage ist: Findet er dann einen Weg, sie wirklich auszunutzen? Zum Beispiel nutzt eine Pufferüberlaufschwachstelle in der Wegfahrsperre eines Autos einem Dieb überhaupt nichts, wenn es für ihn keine Möglichkeit gibt, den Puffer zum Überlaufen zu bringen.

Daher ist es wichtig, auch die Systeme in Autos, Schiffen und Flugzeugen (wie sieht es eigentlich mit Raumschiffen aus? Oder Zügen? Oder …) abzusichern. Zum einen, indem durch einen sicheren Entwicklungsprozess die Anzahl der Schwachstellen möglichst weit reduziert wird. Zum anderen, indem entsprechende Schutzmaßnahmen implementiert werden. Zum Beispiel in Form eines Intrusion Prevention Systems, wie es von Charlie Miller und Chris Valasek vorgeschlagen wurde, oder durch die Trennung sicherheitsrelevanter und nicht sicherheitsrelevanter Netze. Viele weitere Ansätze sind denkbar. Aber das ist die Aufgabe der jeweiligen Hersteller. Für uns Benutzer bleibt nur zu hoffen, dass was passiert, bevor etwas passiert.

Aufmacherbild: Silhouette of a hacker use command of virus attack on graphic user interface von Shutterstock / Urheberrecht: GlebStock

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -