Nach der Veröffentlichung unserer Ergebnisse im vergangenen Jahr, die Datenlecks einschließlich WLAN-Zugangsdaten, Standort- und Energiedaten bei Solarwechselrichtern von Sunways und APsystems aufdeckten, präsentieren wir nun eine kritische Schwachstelle in APsystems-Wechselrichtern: eine Remote-Firmware-Injektion, die eine vollständige Kompromittierung des Systems ermöglicht.

APsystems Mikrowechselrichter

APsystems bietet eine breite Palette von Mikrowechselrichtern sowie Batteriespeicherlösungen für Privathaushalte und Gewerbe/Industrie (C&I) und Überwachungswerkzeuge an. Der EZ1-M ist einer der beliebtesten Mikrowechselrichter und wird nach wie vor über Händler vertrieben. APsystems lieferte den EZ1-M auch als White-Label-Produkt an Anker, bekannt unter dem Namen Anker Solix Mi80.

EZ1-M Hardware-Analyse

Während der Ausarbeitung unseres ersten Berichts im vergangenen Jahr kontaktierten wir Valentin Conrad von der TU Darmstadt, der die Firmware des EZ1-M für seine Masterarbeit über die Sicherheit von Mikrowechselrichtern ausgelesen hatte. Er stellte uns den geöffneten Wechselrichter und die Firmware für die Analyse zur Verfügung.

Die Vorderansicht hebt den ESP32C2-Mikrocontroller hervor. Seine Hauptfunktion besteht darin, Energiedaten zu erfassen und über MQTT an die Cloud zu übertragen. Er steuert außerdem, ob der Wechselrichter Strom in das Netz einspeist.

Die Rückansicht zeigt einen TI C2000-Mikrocontroller, der mit dem ESP32C2 verbunden ist und die Gate-Treiber steuert. Diese sind für den Umwandlungsprozess von Gleichstrom in Wechselstrom verantwortlich. Unter dem APsystems-Logo ist der Schriftzug „DS3“ zu sehen, was darauf hindeutet, dass der EZ1-M dieselbe Hardware wie die DS3-Wechselrichterserie verwendet.

EZ1-M Firmware-Analyse

Bei der Analyse der Firmware mit Ghidra stellten wir fest, dass die verwendete MQTT-Broker-URI data.mqtt.apsystemsema.com:9005 lautete. In der Funktion, in der auf diese Zeichenfolge verwiesen wurde, fanden wir außerdem zwei zufällige Zeichenfolgen: uh345IeTf)(&*rrr und CCPUsadQQi!@&#$p. Ursprünglich dachten wir, dies seien die MQTT-Zugangsdaten, aber die Verbindungsversuche blieben erfolglos.

Das Reverse Engineering dieses Firmware-Images war ziemlich anspruchsvoll, weshalb wir einen neuartigen Ansatz versuchten: Wir extrahierten den disassemblierten C-Code der MQTT-Funktion und nutzten Gemini Pro zur Interpretation. Dies funktionierte überraschend gut und ermöglichte es uns, den Verbindungsprozess zu verstehen. Der Authentifizierungsmechanismus lässt sich wie folgt zusammenfassen:

Zuerst wird die Seriennummer des Geräts mit den oben genannten Zeichenfolgen verschlüsselt. Einmal für den Benutzernamen und ein zweites Mal (unter Verwendung der zweiten Zeichenfolge) für das Passwort. Anschließend werden die verschlüsselten Blobs mit Base64 codiert und als MQTT-Zugangsdaten verwendet. 

Da keine Schlüsselvereinbarung stattfindet und der Broker nur die Base64-Zeichenfolgen empfängt, gehen wir davon aus, dass die Schlüssel statisch und auf allen Geräten identisch sind. Das bedeutet, dass ein Angreifer lediglich die Seriennummer des Geräts kennen muss, um sich am Server zu authentifizieren. Dies allein wäre zwar kein schwerwiegendes Problem, wenn die Seriennummern zufällig wären, aber sie sind leider vorhersehbar und funktionieren im Wesentlichen wie ein fortlaufender Zähler (z. B. E17000032722, E17000032723 usw.).

EZ1-M MQTT-Analyse

Vor dem Verbinden mit dem MQTT-Server versuchten wir, Topic-Zeichenfolgen innerhalb der Firmware ausfindig zu machen, aber die Zeichenfolgen waren verkettet und in der disassemblierten Ansicht schwer zu verfolgen.

Da wir sahen, dass die Topics regelmäßig über UART ausgegeben wurden, kauften wir ein ESP32C2-Entwicklungsboard und flashten die Firmware darauf. Dies lieferte uns die Topics, darunter einige sehr interessante, insbesondere die OTA-Topics, was auf eine Funktion zur Remote-Firmware-Aktualisierung hindeutet.

Nach dem Verbinden mit dem MQTT-Server prüften wir, ob wir beliebige Topics abonnieren und darin veröffentlichen können. Dies war nicht möglich; der Zugriff war auf Topics beschränkt, die mit der authentifizierten Seriennummer des Geräts verknüpft waren. Es war uns nicht möglich, beliebige Seriennummern zu abonnieren. Zudem erzwingt der Server eine Richtlinie von nur einer Verbindung pro Seriennummer. Wenn ein Gerät bereits verbunden ist, trennt ein Angreifer, der sich mit derselben Seriennummer verbindet, automatisch das legitime Gerät, was die Durchführbarkeit unseres ursprünglichen Angriffs-Szenarios stark einschränkt.

Umgehen der Einschränkungen

Glücklicherweise ermöglicht uns eine MQTT-Funktion, beide Einschränkungen gleichzeitig zu umgehen: Retained Messages (gespeicherte Nachrichten). Eine Nachricht, bei der das Retained-Flag auf True gesetzt ist, wird jedem Client bei der Verbindung sofort und dauerhaft zugestellt. Diese Funktion kann wie folgt ausgenutzt werden:

1. Verbindung zum MQTT-Broker herstellen, wodurch die Verbindung des Ziel-Wechselrichters getrennt wird.

2. Eine gespeicherte OTA-Update-Nachricht (für unsere eigene Seriennummer) veröffentlichen.

3. Die Verbindung trennen, sodass sich der Wechselrichter automatisch wieder verbindet.

Der Wechselrichter verarbeitet die gespeicherte Nachricht und leitet das OTA-Update ein.

Erstellen eines OTA-Payloads

Die Analyse des UART-Protokolls zeigt die folgende Struktur für eine OTA-Update-Nachricht:

Für eine erfolgreiche Ausnutzung müssen wir die URL und die Geräte-ID anpassen. Die URL muss auf ein gültiges ESP32C2-Firmware-Image verweisen, das einfach lokal erstellt werden kann und über HTTP bereitgestellt werden muss.

Wir haben einen Proof-of-Concept-Payload entwickelt, der die in der Verwaltungs-App sichtbare Firmware-Version in „pwned by jakkaru“ ändert und zukünftige OTA-Updates verhindert, indem das OTA-Topic gepatcht wird.

Proof-of-Concept-Ausnutzung

Um alles zusammenzuführen, wurde das folgende Proof-of-Concept-Video erstellt. Oben links wird das Exploit-Skript angezeigt, unten links die UART-Ausgabe und auf der rechten Seite ist eine Echtzeit-Aufnahme der AP EasyPower-App zu sehen, die die Geräteinformationen anzeigt.

C2000-Patching

Anfangs konnten wir nur die ESP32C2-Firmware patchen. Beim Testen und Überwachen des UART-Protokolls stellten wir jedoch fest, dass ein weiterer OTA-Payload mit einer anderen Konfiguration an das Entwicklungsboard übertragen wurde. Die verlinkte Firmware war deutlich kleiner, und der Modulwert in der OTA-Struktur war auf „dsp“ statt „dcm“ gesetzt. Die Analyse dieser Binärdatei ergab, dass es sich um die C2000-Firmware handelte, die zum Patchen gesendet wurde. Dies bedeutet, dass ein Angreifer den C2000-Chip patchen könnte, um die Gate-Treiber zu steuern, was weitaus schwerwiegendere Angriffs-Szenarien ermöglicht.

Angriffs-Szenarien

Obwohl viele Angriffs-Szenarien denkbar sind, listet die folgende Übersicht die am ehesten realisierbaren Angriffe auf:

• Ausnutzung des Wechselrichters als Proxy, um in das verbundene Netzwerk einzudringen.
  
  

• Organisation einer synchronisierten Abschaltung einer riesigen Flotte von Wechselrichtern, um die Stabilität des lokalen Stromnetzes zu stören.
  
  

• Einbindung kompromittierter Geräte in ein Netzwerk für DDoS-Angriffe.
  
  

• Absichtliche Beschädigung der Firmware oder Hardware-Logik, um das Gerät zu zerstören.
  
  

• Diebstahl von WLAN-Zugangsdaten und anderen auf dem Gerät gespeicherten Informationen.

Unser Telemetrie-Scan identifizierte etwa 100.000 zugängliche und verwundbare EZ1-M-Einheiten. Die gesamte Angriffsfläche ist wahrscheinlich deutlich größer, wenn man andere Produktlinien berücksichtigt, die denselben MQTT-Broker nutzen. Wir haben weitere Seriennummernformate getestet und vermuten stark, dass auch andere Wechselrichter und sogar die Batteriespeicherlösungen für Privathaushalte betroffen sind. Laut apsystemsema.com gibt es insgesamt etwa 600.000 Installationen.

Zeitplan der verantwortungsvollen Offenlegung (Responsible Disclosure)

14. November 2025 - APsystems über die Schwachstelle mit einer 90-Tage-Frist informiert.
21. November 2025 - APsystems veranschlagte 3 Monate für die Behebung, da eine vollständige Überarbeitung der Infrastruktur erforderlich war. 
16. Januar 2026 - APsystems an das Offenlegungsdatum Mitte Februar erinnert. 
18. Januar 2026 - APsystems bat aufgrund von Rollout-Tests um eine Offenlegung Ende Februar.
4. März 2026 - Offenlegung der Schwachstellen.