IoT-Solar-Wechselrichter and Trickle-Down-Schwachstellen

Nur auf Englisch verfügbar

3 September 2019, von Jos Wetzels, Leitender Sicherheitsberater bei Bureau Veritas Cybersecurity

Omniksol

Omnik ist ein chinesisch-deutscher Hersteller von Photovoltaik-Wechselrichtern (PV) und Zubehör, der in den Niederlanden, Deutschland und Belgien sehr beliebt ist.

Die Omnik-Wechselrichter verfügen über zwei RJ-45-Anschlüsse, über die bis zu 50 Wechselrichter in Reihe geschaltet werden können, um die Konfiguration und Datenübertragung über RS-485 zu ermöglichen. Darüber hinaus sind Wi-Fi- und GPRS-Konnektivitätsmodule entweder als interne Karten oder als externe Kits (die über RS-485 mit dem Wechselrichter verbunden sind) für die Fernüberwachung des Status, die Datenerfassung und die Konfiguration einer gesamten Wechselrichterkaskade erhältlich.

Beachten Sie, dass dies nur die öffentlichen Konten sind und nur die, die im Omnik-Portal sichtbar sind. Andere Marken, die die SolarMAN-Lösung weiterverkaufen, verwenden möglicherweise ihre eigenen Portale.

Zusätzlich zu der obigen Karte der Wi-Fi Kit-Nutzer können wir Dutzende von ihnen öffentlich im Internet finden, indem wir die Suchmaschinen Shodan und Censys verwenden:

Das SolarMAN / iGEN Wi-Fi Kit

Schauen wir uns das Wi-Fi Kit einmal genauer an. Als erstes fällt auf, dass der offene AP die Standardoption ist. Bei der Einrichtung können Sie zwar den AP "verstecken", die WEP- / WPAPSK- / WPA2PSK-Verschlüsselung einstellen und den Benutzernamen und das Kennwort des Webservers ändern, aber der Endbenutzer muss dies nicht tun, so dass das Gerät typischerweise unsicher eingesetzt wird. Wenn der offene AP nur für die Ersteinrichtung des Geräts verwendet wird, wird er danach nicht deaktiviert, so dass er bei vielen Geräten zum Einrichten und Vergessen" offen bleibt.

Was können wir also mit dem Zugriff auf den AP hier tun? Nun, zunächst einmal ermöglicht er uns die Interaktion mit den PV-Wechselrichtern über verschiedene Schnittstellen, über die wir später mehr erfahren. Zweitens muss das Wi-Fi-Kit in der Lage sein, sich mit dem Internet zu verbinden, um mit dem SolarMAN-Cloud-Backend zu kommunizieren, das die Wechselrichterdaten aufnimmt und sie Ihnen über eine mobile App zur Verfügung stellt. Daher wird das Kit entweder über ein Ethernet-Kabel oder einen Wi-Fi AP (für den die SSID und die Zugangsdaten in der Web-Konfigurationsoberfläche eingegeben werden müssen) mit einem internen Netzwerk verbunden. Abgesehen davon, dass dies bedeutet, dass Sie dem Cloud-Backend sowohl Ihre PV-Wechselrichterdaten als auch möglicherweise Ihre persönlichen Wi-Fi-Anmeldedaten anvertrauen, bedeutet es auch, dass der AP des Kits nun als Einstiegspunkt in Ihr privates Netzwerk dient. Ein Risiko, das viele IoT-Geräte betrifft.

Um eine bessere Vorstellung von der Sicherheitslage des Kits zu bekommen, habe ich beschlossen, einen Blick auf die verschiedenen Dienste zu werfen. Ein schneller nmap-Scan zeigt, dass die MAC-Adresse dem in Shenzhen ansässigen Unternehmen Drogoo Technology Co. entspricht und die folgenden Dienste offengelegt werden:

* 53/UDP, DNS
* 80/TCP, HTTP
* 8899/TCP, Datenlogger-Informationen
* 48899/UDP, HF AT-Schnittstelle

Webschnittstelle (80/TCP)
Auf Port 80 befindet sich ein Webserver, der nach einer HTTP-Basisauthentifizierungsabfrage eine Konfigurationsschnittstelle bereitstellt, die typische Konfigurationsoptionen unterstützt (Einstellungen für Drahtlos- und Kabelnetzwerke, Datenlogger, Cloud Server, serielle Kommunikation) sowie die Möglichkeit, den Benutzernamen und das Passwort der Webschnittstelle zu ändern und die Firmware des Wi-Fi-Kits und des Wechselrichters zu aktualisieren.

Datenlogger-Info (8899/TCP)
Der Dienst an diesem Port wird für die Datenlogger-Kommunikation verwendet, für die es mehrere Open-Source-Community-Skripte gibt(http://www.mb200d.nl/wordpress/2015/11/omniksol-4k-tl-wifi-kit/, https://github.com/Woutrrr/Omnik-Data-Logger, https://github.com/XtheOne/Inverter-Data-Logger), aber aus der Sicherheitsperspektive ist dieser Dienst nicht sonderlich interessant, so dass ich beschlossen habe, ihn nicht weiter zu untersuchen.

HF AT-Schnittstelle (48899/UDP)
Nehmen wir also an, dass der Endbenutzer ein sicheres Passwort für die Weboberfläche konfiguriert hat und wir nicht den Weg der Ausnutzung von Speicherfehlern in einem der exponierten Dienste gehen wollen. In diesem Fall scheint diese Schnittstelle, die ich 'HF AT-Schnittstelle' genannt habe (aus Gründen, die später klar werden), unsere beste Chance zu sein.

Die Schnittstelle wird für die Netzwerkerkennung verwendet, indem sie mit identifizierenden Informationen auf bestimmte UDP-Broadcast-Nachrichten antwortet, die die Zeichenfolge "WIFIKIT-214028-READ" enthalten, wie Sie beim Reverse Engineering der SolarMAN Mobile App sehen können:

Die FCC-ID scheint zu dem von Shanghai Hi-Flying Technology hergestellten HF-A11 Embedded Wi-Fi Modul zu gehören. Das Vorhandensein dieses Moduls, das auf der MIPS-Architektur basiert und auf dem das eCos RTOS läuft, kann nach dem Öffnen des Gehäuses auf der Platine des Kits festgestellt werden:

Außerdem bestätigt eine schnelle Analyse der Firmware des Kits, dass es mit eCos auf MIPS läuft und Hi-Flying und HF-A11 Strings anzeigt:

Hi-Flying

Shanghai High-Flying Electronics Technology Co., Ltd ist ein Hersteller von drahtlosen Kommunikationsprodukten und Anbieter von Cloud-Diensten, der verschiedene IoT-Module und -Geräte herstellt. Diese Module und Geräte werden auch von anderen Anbietern wie USR IOT verkauft und von verschiedenen kostengünstigen IoT-ODMs und OEMs in einer Vielzahl von Produkten eingesetzt, die von intelligenten Glühbirnen wie der bekannten MiLight, intelligenten Steckdosen, Webcams, Kaffeemaschinen und Sicherheitsalarmen bis hin zu industriellen RTUs, Seriell-zu-Ethernet-Konvertern, Gateways und Datenloggern für Solarwechselrichter reichen, die alle wiederum von einem weit verzweigten Netz von Firmennamen umbenannt werden.

Eine Folie aus einer Präsentation des Hi-Flying Unternehmensprofils zeigt einige prominente internationale Kunden (darunter Omnik) und ein breites Portfolio an Modulen:

Diese Module bestehen in der Regel aus einem handelsüblichen drahtlosen Kommunikationschip (z.B. dem MediaTek MT5931), der mit einem RTOS (z.B. eCos, FreeRTOS, Contiki, ARM mbed) oder Linux, verschiedenen Kommunikations- und Netzwerkbibliotheken, eingebetteten Web-, FTP- und Telnet-Servern sowie proprietären Funktionen für die Netzwerkerkennung, Fernkonfiguration und OTA-Firmware-Updates kombiniert ist. Die Module können als Access Point (AP) und/oder Station (STA) fungieren und können über eine UART-AT-Befehlsschnittstelle angesprochen werden.

Es scheint zwei verschiedene Konfigurations-/OTA-Protokolle zu geben, die beide über eine Schnittstelle an Port 48899/UDP verfügen:

* HF AT Interface (alternativ als SmartConfigure Smart Link bezeichnet), das von den Modulen der Serien HF-A, HF-LPT, HF-LPB, etc. verwendet wird
* IOTService / IOTManager, verwendet von den Modulen der Serien Eport und Wport.

Darüber hinaus unterstützen einige Module (z.B. HF-LPB125 und HF-LPT330) WeChat AirKiss , bei dem es sich, wie im Espressif ESP-TOUCH Leitfaden beschrieben, im Wesentlichen um eine verdeckte Kanalschnittstelle zur Konfiguration von Wi-Fi-Einstellungen auf eingebetteten Geräten handelt, die keine anderen Schnittstellen haben. Dazu startet das Gerät im Paketaufnahmemodus und lässt die AirKiss-App eine Reihe von UDP-Paketen an den Wi-Fi-AP senden, wobei die SSID und das Passwort in den Längenfeldern der Pakete verschlüsselt werden. Da das Längenfeld nicht verschlüsselt ist, kann der zuhörende Knoten die SSID und das Passwort auslesen und dem Wi-Fi-Netzwerk beitreten, woraufhin die Konfiguration beginnen kann. Obwohl AirKiss in der Regel nur während der Erstkonfiguration aktiv ist, stellt dieser Ansatz grundsätzlich ein Sicherheitsrisiko dar.

HF AT-Schnittstelle / SmartConfigure Smart Link

Dieser Dienst dient nicht nur der Netzwerkerkennung, sondern stellt die AT-Schnittstelle des Moduls über UDP zur Verfügung und funktioniert folgendermaßen:

* Netzwerk mit UDP-Broadcast-String auf Port 48899 scannen
* Knoten antworten mit IP,MAC,MID
* Antwortet mit "+ok", Knoten geht in den AT-Modus
* Wir können nun beliebige AT-Befehle ausführen.
* Halten Sie einen Knoten im Kommandomodus, indem Sie AT+W in Abständen von 1 Minute senden, der Knoten akzeptiert dann 1 Minute lang keine anderen Verbindungsanfragen.
* Senden Sie AT+Q, um den AT-Befehlsmodus zu verlassen.

Die AT-Schnittstelle ermöglicht den Zugriff auf verschiedene sensible Funktionen, wie z.B.:

* Aktualisieren der Firmware
* Abrufen/Einstellen von Wi-Fi-Konfigurationsdaten (einschließlich Schlüssel)
* Abrufen/Einstellen von Dienstanmeldedaten (z. B. Webserver)
* Abrufen / Einstellen der 'Benutzer'-Konfiguration (gerätespezifische Informationen)
* GPIO-Pin-Status einstellen
* Navigieren zu URLs in einer Proxy-ähnlichen Weise

Darüber hinaus können OEMs gerätespezifische Befehle hinzufügen (z.B. die Aktualisierung der Firmware für Module oder Geräte, die mit dem Wi-Fi-Modul verbunden sind, wie der PV-Wechselrichter im Falle des SolarMAN-Kits).

Der einzige Schutz für diesen Dienst ist ein 'Passwort', das gleichzeitig als Netzwerkerkennungsstring dient. Das Passwort ist in der Firmware fest einprogrammiert und kann nicht geändert werden. Da es Teil des Erkennungsprotokolls ist, kann es nicht als vertraulich betrachtet werden. Standardmäßig lautet dieses Passwort 'HF-A11ASSISTHREAD'.

In einigen Fällen (z.B. bei den Omniksol WiFi Kits und Karten) haben die OEMs dieses Kennwort geändert, aber das bringt nur wenig zusätzliche Sicherheit, da ein Angreifer lediglich ein Firmware-Image des Geräts, eine mobile App oder ein Integrationsgateway erhalten und das Kennwort extrahieren muss. OEMs können das Passwort in neuen Firmware-Versionen ändern, aber das würde die Kompatibilität mit bestimmten Apps und Tools, die die Schnittstelle für die Geräteerkennung verwenden, unterbrechen und der Angreifer kann den Trick einfach wiederholen.

Das Extrahieren des AT-Passworts für ein HF-basiertes Geräte-Firmware-Image ist einfach und beinhaltet das Entpacken der Firmware (Extrahieren des LZMA-komprimierten Blob aus dem U-Boot-Image) und das Abrufen des hartkodierten Passworts aus dem dekomprimierten Image. Dies kann auf 'clevere' Weise geschehen (Laden in IDA, Identifizierung der AT-Schnittstellen-Authentifizierungsfunktion mit einer FLIRT-Signatur und Auffinden des Verweises auf das Kennwort) oder auf einfache Weise, indem man die Tatsache nutzt, dass das Kennwort bei den eCos-basierten Images immer zwischen denselben zwei Zeichenfolgen liegt:

Daher reicht der folgende Oneliner aus, um das AT-Passwort aus einem HF eCos-basierten Firmware-Image zu erhalten:

Bei Images, die auf FreeRTOS, Contiki oder mbed basieren, scheint das folgende Muster nach dem Passwort zu kommen:

Damit haben wir den Oneliner:

Wie sich herausstellte, wurden die Probleme mit dieser Schnittstelle in den letzten Jahren unabhängig voneinander von mehreren Parteien entdeckt, die sich mit verschiedenen IoT-Produkten befassten, z. B. mit den intelligenten Steckdosen von CSL und Orvibo S20 sowie mit den Wi-Fi-Glühbirnen von Flux, LimitlessLED und Zengge. Einige frühere Arbeiten haben gezeigt, wie man SSIDs und Schlüssel von internetfähigen Hi-Flying-basierten Geräten auslesen und dann die betreffenden Netzwerke geolokalisieren kann.

IOTService / IOTManager

Das IOTService-Protokoll wird von dem IOTService-Tool und der App verwendet, um Hi-Flying Eport- und Wport-basierte Geräte zu erkennen und zu konfigurieren. Es ist der AT-Schnittstelle sehr ähnlich und stellt im Wesentlichen die HF CLI zur Verfügung, die auch über Telnet verfügbar gemacht werden kann, verpackt in JSON auf Port 48899/UDP ohne Authentifizierung. Die Kommunikation wird von einem Client initiiert, der eine Broadcast-Discovery-Nachricht sendet, woraufhin die Knoten mit ihren Geräteinformationen antworten und der Client beginnen kann, JSON-verpackte CLI-Befehle zu senden. Die angebotenen Funktionen ähneln denen der AT-Schnittstelle und ermöglichen das Abrufen und Ändern von Wi-Fi- und Service-Anmeldeinformationen, das Ändern der Firmware usw.

Um zu veranschaulichen, wie dieses Protokoll missbraucht werden kann, habe ich den Hi-Flying HF2211 Serial Converter / Gateway als Ziel gewählt.

Serielle Konverter / Gateways werden in einer Vielzahl von Umgebungen (z.B. in der Industrie- und Gebäudeautomatisierung) als Schnittstelle zwischen verschiedenen seriellen (z.B. Feldbusse über RS-232 oder RS-485) und Ethernet-Protokollen eingesetzt und sind in der Regel an Automatisierungsgeräte (wie SPS) oder Feldgeräte angeschlossen. Solche Konverter waren in der Vergangenheit sehr unsicher und die Produkte von Hi-Flying bilden in dieser Hinsicht keine Ausnahme.

Der HF2211 basiert auf der Wport-Modulserie und richtet wie andere Hi-Flying-Geräte standardmäßig einen offenen AP mit dem Namen 'HF2211_XXXX' ein, wobei XXXX die letzten 2 Bytes der MAC sind. Auf dem HF2211 läuft eCos auf einem Ralink RT5350f MIPS SoC und stellt die folgenden Dienste zur Verfügung:

* 23/TCP, Telnet (Eport/Wport CLI)
* 53/UDP, DNS
* 80/TCP, HTTP
* 8899/TCP, Serieller Konverterdienst
* 48899/UDP, IOTService

Durch die Verwendung des IOTService-Verwaltungstools und das Abfangen des (unauthentifizierten, Klartext-) Datenverkehrs können wir das Protokoll analysieren und unsere eigenen Skripte erstellen, um WiFi-Anmeldeinformationen auszuspionieren oder die Firmware des Konverters zu modifizieren, um effiziente MITM-Angriffe auf den verarbeiteten seriellen Datenverkehr auszuführen (und so die industriellen Prozesse, die von ihm gesteuert werden, zu beeinträchtigen).

Über diese Wechselrichter

Nun gut, zurück zu den Solar-Wechselrichtern, mit denen diese Untersuchung begann. Wie wir gesehen haben, kann ein Angreifer mit Zugriff auf eine der WiFi-Kit-Verwaltungsschnittstellen über die serielle Verbindung ein neues Firmware-Image auf die angeschlossenen Wechselrichter herunterladen. Und da es keinen Authentifizierungsmechanismus für die Firmware des Wechselrichters gibt, können wir beliebige Änderungen vornehmen, die von der Zerstörung bis hin zu anspruchsvolleren Aktionen reichen.

Beeinflussung der Stabilität des Stromnetzes

Solarwechselrichter dienen dazu, den variablen Gleichstrom (DC) von Photovoltaikanlagen in Wechselstrom (AC) mit Netzfrequenz umzuwandeln, der in ein kommerzielles Stromnetz oder ein lokales, netzunabhängiges Stromnetz eingespeist werden kann. Der so erzeugte Strom kann entweder direkt in das Stromnetz eingespeist werden, wie es bei einem kommerziellen Solarpark der Fall wäre, oder er kann zur Deckung des Stromverbrauchs der Haushalte verwendet werden, entweder direkt, indem nur der überschüssige Strom in das Netz eingespeist wird, oder indirekt, indem Net-Metering-Geräte zur Begleichung der Rechnung herangezogen werden.

Ein Gleichgewicht zwischen Stromangebot und -nachfrage ist für das ordnungsgemäße Funktionieren des Netzes entscheidend, um Instabilität zu vermeiden. Photovoltaikanlagen beeinflussen das Gleichgewicht des Netzes in Form einer Verringerung der Nachfrage und einer Erhöhung des Angebots, indem sie in der Regel direkt den lokalen Bedarf decken und überschüssigen Strom in das Netz einspeisen. Solarwechselrichter sind hier von zentraler Bedeutung, um das Gleichgewicht zwischen der Gleichstromerzeugung der Solaranlage(n) und der Wechselstromlast des Haushalts und des Versorgungsnetzes aufrechtzuerhalten. Spitzen oder Einbrüche, die z.B. durch Sonnenfinsternisse, Bewölkung, vorübergehende Störungen oder Produktionsspitzen (z.B. zur Mittagszeit) entstehen, werden durch eine Kombination aus vorausschauender Planung der Versorgungsunternehmen, Puffer- und Eingriffsmöglichkeiten und Wechselrichtern ausgeglichen , die sicherstellen, dass sie Spannung, Frequenz und Phase der Sinuswelle des Netzes genau entsprechen, Schwankungen glätten und eine Anti-Insellösung bieten, indem sie sich vom Netz trennen, wenn dieses ausfällt, um die Sicherheit der Versorgungsmitarbeiter zu gewährleisten.

Wie in früheren Arbeiten zu diesem Thema(https://www.mdpi.com/1996-1073/12/4/725/pdf),(https://horusscenario.com/) dargelegt, könnte ein Angreifer mit ausreichender Kontrolle über die Funktionen eines Wechselrichters (z.B. durch das Herunterladen modifizierter Firmware) diesen manipulieren, um möglicherweise die Netzstabilität zu beeinträchtigen. Ein Angreifer könnte versuchen, die Leistungsabgabe des Wechselrichters (und möglicherweise das Batteriemanagementsystem) zu manipulieren, um einen Rückgang der Gesamtversorgung zu bewirken und die individuelle(n) finanzielle(n) Entschädigung(en) für die in das Netz eingespeiste Energie negativ zu beeinflussen, oder versuchen, übermäßige Leistung einzuspeisen und/oder die Spannung zu manipulieren, um unerwünschte Netzzustände zu verstärken.

Die Komplexität solcher Angriffe darf natürlich nicht unterschätzt werden. Neben der defensiven Präsenz von Netzschutzsystemen und dem Eingreifen des Netzbetreibers würde ein solcher Angriff auch ein hohes Maß an Koordination erfordern. Diese Faktoren werden wiederum durch den Grad der solaren Durchdringung der Stromerzeugungsquellen des Gesamtnetzes und die Kontrolle des Angreifers über einen beträchtlichen Anteil der PV-Wechselrichter beeinflusst, wobei letzteres wiederum durch die Heterogenität und Gefährdung der Wechselrichterlösungen beeinflusst wird.

Unabhängig davon ist die Absicherung der angeschlossenen Systeme, die verschiedene dezentrale Energieressourcen (Distributed Energy Resources, DER) wie Sonne, Wind, Biomasse und kleine Wasserkraftwerke unterstützen, von entscheidender Bedeutung für die Absicherung des Gesamtnetzes, selbst wenn es keine realen Machbarkeitsnachweise auf repräsentativen Testsystemen gibt.

Beeinträchtigung der Wechselrichtersicherheit

Ein weiteres potenziell bösartiges Szenario wäre, dass ein Angreifer die Firmware des Wechselrichters modifiziert, um die Sicherheit zu beeinträchtigen, z. B. indem er einen Brand verursacht. Ob es möglich ist, einen Brand in einem Wechselrichter zuverlässig mit Hilfe von Software auszulösen, muss erst noch bewiesen werden. Daher ist bei der Beurteilung der Realitätsnähe dieses Szenarios Vorsicht geboten, aber angesichts des typischen Ausmaßes der Kontrolle der Wechselrichter-Firmware über die internen Lüfter, die Spannungsanpassung, die Temperaturüberwachung usw. liegt ein solches Szenario nicht außerhalb des Bereichs des Möglichen.

Die häufigsten Ursachen für Brände in Wechselrichtern sind Lichtbögen und Widerstandserhitzung (entweder als Vorstufe zu Lichtbögen oder als solche ), die in der Regel auf mangelhafte Herstellung und/oder Installation, Umgebungsbedingungen und alternde Komponenten zurückzuführen sind. Um die Sicherheit von Wechselrichtern zu beeinträchtigen, müsste ein Angreifer künstlich einen Materialzusammenbruch herbeiführen (z.B. durch Widerstandserwärmung und hohe Umgebungstemperaturen), der als Vorstufe eines Lichtbogens oder als direkte Ursache für eine Entzündung gilt, und außerdem Sicherheitsmechanismen wie Lichtbogendetektoren und Temperaturüberwachung überwinden.

Omnik Wechselrichter Firmware Interna

Es gibt verschiedene Linien von Omnik-Wechselrichtern, aber im Allgemeinen verfügen sie alle über eine Firmware für ein Master-CPU-Modul, ein Slave-CPU-Modul und ein Display-Modul. Zur Veranschaulichung der Firmware-Interna werfen wir einen Blick auf den dreiphasigen transformatorlosen Wechselrichter Omniksol-13k/17k/20k-TL.

Die Master- und Slave-Module basieren auf dem TMS320F2802x , auf dem das Micrium µC/OS-II RTOS läuft. Strings in der Firmware deuten auf eine Toolchain-Beziehung zum TMS320C2000 Single Frequency Power Line Communication (SFPLC) Modem hin. Das Displaymodul basiert auf dem AT91SAM9261 Mikrocontroller mit Windows CE.

Wie wir aus den obigen Disassemblierungsausschnitten ersehen können, verfügt die Firmware über eine granulare Kontrolle über eine Vielzahl von Funktionen, vom Lüfter, der Wechselrichterleistung und verschiedenen Aspekten der Netzsynchronisation bis hin zum Maximum Power Point Tracking (MPPT) , so dass ein Angreifer, der in der Lage ist, die Firmware zu modifizieren, den Betrieb des Wechselrichters auf böswillige Weise sehr präzise anpassen kann. Ob dies wirklich ausreicht, um die gewünschten Ergebnisse zu erzielen, müsste weiter untersucht werden.

Schlussfolgerung

Die potenziellen Auswirkungen der besprochenen Schwachstellen auf angeschlossene Solarwechselrichter und serielle Wandler sind zwar besorgniserregend, aber sie sind nicht das eigentliche Problem in dieser Geschichte. Es ist allgemein bekannt (oder sollte es sein), dass die meisten vernetzten eingebetteten Systeme (egal ob Verbraucher oder industrielles IoT) in der Regel erschreckend unsicher sind, und in den letzten zehn Jahren hat auch das Bewusstsein für "cyber-physische Angriffe" zugenommen, bei denen sich Sicherheitsprobleme in der digitalen Welt direkt auf die physische Welt auswirken.

Meiner Meinung nach ist der beunruhigendste Aspekt hier die Veranschaulichung der nachteiligen Auswirkungen der Undurchsichtigkeit der Lieferkette auf das Schwachstellenmanagement. An den komplizierten Lieferketten für vernetzte eingebettete Systeme sind viele Akteure auf vielen Ebenen beteiligt, die verschiedene Hardware- und Softwarekomponenten liefern und integrieren - von SoCs und Bibliotheken bis hin zu ein und demselben Produkt, das schließlich bei mehreren verschiedenen OEMs landet, die es nur minimal anpassen, bevor sie es an eine weitere Ebene von Wiederverkäufern weitergeben, die es im Grunde nur mit einem neuen Logo versehen. Eine Schwachstelle in einer beliebigen Komponente auf einer beliebigen Ebene kann in einer zunehmend undurchsichtigen Lieferkette "durchsickern" und in ICS-Geräten, POS-Terminals und mit dem Internet verbundenen Puppen landen. Je weiter oben in der Lieferkette Schwachstellen entstehen, desto breiter ist die Palette der Produkte, in denen sie landen, und desto schwieriger ist es, sie ohne die aktive Mitarbeit aller beteiligten Parteien zu verfolgen und zu beheben. Ein Beispiel: Wenn Sie glauben, dass Schwachstellen wie Broadpwn, Blueborne, Devil's Ivy, Shellshock oder Heartbleed nicht mehr in freier Wildbahn gefunden werden können, weil die für den verwundbaren Code direkt verantwortlichen Parteien einen Patch herausgegeben haben, dann werden Sie eine böse Überraschung erleben.

Da keine einzelne Instanz den gesamten Lebenszyklus der Softwareentwicklung und -wartung überwacht, gibt es oft keine einheitliche, kohärente Reihe von Sicherheitsanforderungen. Je weiter man in der Kette nach oben geht (z.B. SoC- oder RTOS-Anbieter), desto breiter ist der Kundenstamm, dem man gerecht werden muss, und das bedeutet in der Regel, dass man sich auf den kleinsten gemeinsamen Nenner in Bezug auf Fähigkeiten, Overhead und Kostenbeschränkungen einstellen muss. Hinzu kommt, dass es keine einzige Instanz gibt, die in der Lage ist, direkt und zentral Patches für eine bestimmte Schwachstelle im Endprodukt herauszugeben. Stattdessen müssen OEMs darauf warten, dass ihre Zulieferer (oder die Zulieferer ihrer Zulieferer) ihre eigenen Patches herausgeben und diese in neue Firmware-Versionen integrieren, die sie dann an ihre Kunden weitergeben können. Diese müssen die Patches dann oft manuell auf alle betroffenen Produkte anwenden (oder sich auf einen kleinen IoT-Anbieter verlassen, der willkürlich Firmware-Updates für eine Reihe von Geräten in ihren Netzwerken durchführen kann, was noch schlimmer sein könnte).

Zusammenfassend lässt sich sagen, dass ein ganzheitlicherer Ansatz für die IoT-Sicherheit erforderlich ist, der alle relevanten Aspekte des Produktlebenszyklus abdeckt und sicherstellt, dass die Produkte einen gemeinsamen Mindeststandard erfüllen.

Zeitplan für die Offenlegung von Schwachstellen:

* 6. Oktober 2018 - Erster Bericht an Hi-Flying
* 26. Mai 2019 - Berichte an SolarMAN und Omnik sowie an NCSC-NL
* 26. Mai bis 22. Juli 2019 - NCSC-NL versucht, die Hersteller zu kontaktieren, aber keine Reaktion, Eskalation an CNCERT/CC
* 15. August 2019 - Immer noch keine Antwort von einem Hersteller, Entscheidung zur Veröffentlichung

Vielen Dank an Peter-Jan Pinxteren, der die ursprünglichen offenen APs entdeckt und die Verbindung zu den Omnik Connectivity Kits hergestellt hat.