Solarinverter: Sicherheit auf dem Prüfstand

Seite 7: Die Analyse in Wireshark

Inhaltsverzeichnis

Egal auf welche Weise wir nun die Paketdatei erhalten haben, wird es Zeit, sich an die Analyse zu machen. Das Tool der Wahl ist Wireshark. Es ist für fast alle Übertragungsprotokolle, nicht nur IP-basierte, geeignet und bietet zahlreiche Funktionen. Wireshark steht zum Großteil unter der GPL2-Lizenz und lässt sich kostenlos herunterladen.

Hat man Wireshark installiert, lädt man nun die erstellte ETH-Datei und wird von sehr vielen bunten Zeilen, mit zunächst kryptische wirkendem Inhalt, begrüßt.

Bild 9: Beispiel eines Capture-Files, das mit Wireshark geöffnet wurde. Hier sieht man (unten rechts), wie der Hersteller den Backend-Server per AT-Kommando auf "5406.devicaccess.host:1000" ändert.

Hat man bereits in der Fritzbox die Vorfilterung, z. B. mit "ip host 10.2.2.11", aktiviert, sollten nur Pakete im Log enthalten sein, die von dem festgelegten Gerät ausgehen, oder eingehen. War das nicht möglich, sieht man vermutlich auch eine Menge Traffic von Geräten, die einen gar nicht interessieren. Um hier effizient weiterzukommen, ein paar sinnvolle Schritte:

Schritt 1: Filtern der interessanten Netzwerkpartner

Weiß man, dass der interessante Filter nur ein Gerät/eine IP betrifft, empfiehlt sich zuerst der Filter nach der IP. In der Filterzeile kann man dazu den Filterausdruck "ip.host == 10.2.2.11" angeben, was allen ein- und ausgehenden Traffic auf diese IP anzeigt. Mit "ip.dst" oder "ip.src" kann man zusätzlich nur auf ein- oder ausgehende Pakete schauen.

Schritt 2: Filtern der interessanten Protokolle

Man kann die Pakete auch auf ein Protokoll beschränken (TCP, UDP, usw.) und mit anderen Filtern (z. B. "ip.host", "ip.dst", "ip.src") kombinieren. Auch das Filtern nach bestimmten Ports ist möglich (etwa "tcp.port == 80").

Bild 10: Hier wird jeglicher TCP-Traffic gefiltert, der als Ziel unser Gerät hat – also nur eingehender Traffic.

Schritt 3: Metadaten-Analyse

Ohne die eigentlichen Daten im Detail ansehen zu müssen, kann man mit der Metadaten-Analyse auch schon einiges herausfinden, z. B.:

  • Wo stehen die Server, die das Gerät kontaktiert?
  • Wird in beide Richtungen kommuniziert?
  • Wie häufig wird kommuniziert?
  • Gibt es Muster?

Helfer bei diesen Aufgaben findet man im Statistik-Menü von Wireshark. Unter "Endpunkte" im Reiter "IPV4" sieht man alle beteiligten IP-Adressen und wie viel Traffic ausgetauscht wurde.

Bild 11: Statistiken/Endpunkte

Während der Analyse sieht man zunächst meist nur IP-Adressen. Man kann die Adressen auch mit aufgelösten Domain-Namen anzeigen lassen. Ein Mapping der Daten findet man hier.

Bild 12: Statistiken/Aufgelöste IP-Adressen

Wenn man wissen will, wo eigentlich die externen Server verortet sind, kann man das z. B. einzeln bei dem Anbieter Maxmind herausfinden (Bild 13). Eine deutlich komfortablere Option ist es, sich die (nicht ganz präzisen) GeoIP-Lookup-Tabellen direkt herunterzuladen, um sie in Wireshark auszuwerten. Dafür muss man sich bei Maxmind allerdings kostenlos registrieren.

Die Datenbanken fügt man anschließend in Wireshark ein. Nach einem Neustart des Programms sind weitere Spalten in der Ansicht "Statistiken/Endpunkte" mit Geodaten befüllt. Auf diese Weise sieht man schnell, mit wem das Gerät kommuniziert.

Standorte von extrernen Servern ermitteln (3 Bilder)

Bild 13: Einzelne Geo-IPs lassen mit Maxmind schnell ermitteln.​

Unter "Statistiken/Verbindungen" kann man einzelne Verbindungen sehen. Jegliche Hin- und Her-Kommunikation mit vielen Paketen wird hier zu einer "Verbindung" zusammengefasst, was die Übersichtlichkeit deutlich steigert. Hier kann man schnell sehen, ob es Muster gibt, etwa Pakete mit immer gleicher Größe und auch, in welchem Zeitabstand diese gesendet werden.

Bild 16: Statistiken/Verbindungen

Schritt 4: Detail-Analyse

Nun ist es Zeit, sich einzelne Pakete etwas näher im Detail anzusehen. Wie eingangs schon erwähnt, hatte ich keine große Hoffnung, auf etwas Interessantes zu stoßen – doch ich wurde positiv überrascht. Zwar war das meiste, das man im Payload-Feld der TCP-Pakete finden konnte, nicht direkt hilfreich, aber es fiel sofort auf, dass in manchen Paketen meine WLAN-SSID, die IP des Inverters und dessen Seriennummer enthalten und im Klartext lesbar waren!

Das ist alles andere als selbstverständlich: Wenn die Entwickler den Traffic auf Datensparsamkeit optimiert oder gar verschlüsselt hätten, wäre auf die Schnelle nichts zu holen gewesen.

Offen einsehbar (2 Bilder)

Bild 17: Da der Datenverkehr nicht verschlüsselt ist ...​

Schritt 5: Dissektion

Hat man ein unbekanntes Protokoll vor sich, kann man Stück für Stück versuchen, Sinn in den einzelnen Bits und Bytes zu erkennen. Wenn man weiß, dass Seriennummer, Leistungswerte etc. enthalten sein müssen, kann man etwa mit Korrelationen einzelne Bereiche im Payload einer Funktion zuzuordnen.

Ich konnte schnell herausfinden, dass es sich bei der Kommunikation um ein proprietäres Protokoll von Solarman (einem Solar-Backend-Provider) handelt. Nach und nach entdeckte ich mehr. Dabei stieß ich auf das Projekt PySolarman. Dort gibt es einige Informationen zum Protokoll und ich konnte die Daten, die ich aufgezeichnet hatte, damit interpretieren.

Bild 19: Aufbau der Solarman Datenpakete.

(Bild: [Link auf https://pysolarmanv5.readthedocs.io/en/stable/solarmanv5_protocol.html])

Daraus galt es nun, ein Plug-in für Wireshark zu schreiben, das den Inhalt direkt anzeigen konnte: etwa die Leistung des Inverters etc.

Gerade als ich startete, nun aber auch eher wusste, wonach ich suchen musste, fand ich einen Mitstreiter, der das schon erledigt und veröffentlicht hatte. Die Quelle konnte ich leider beim Schreiben des Artikels nicht wiederfinden, ich habe den Dissector-Code aber in meinem Repository abgelegt. Hinweis: Es fehlen auch noch einige Bytes, deren Zuordnung ergänzt werden könnte.