Syr LexPlus 10

Mit einer Härte von 14 dH ist das Wasser in Hövelhof schon ziemlich kalkhaltig und Chromarmaturen setzen sehr schnell Ränder an. Also habe ich einige Zeit nach Wasserenthärtungsanlagen gesucht. Am Schluss wurde es eine Syr LexPlus Anlage, die zufällig auch mein Hausinstallateur vorgeschlagen hatte. ich war natürlich auch gespannt darauf, wie der Ethernet-Anschluss sich nutzen kann, z.B. für einen Einbindung in mein Monitoring mit PRTG. Ich habe in weiser Voraussicht schon CAT5-Anschlüsse in den Hausanschlussraum gelegt. Dort kommt ja auch DSL an. Einen passenden PRTG-Sensor habe ich auf PRTG und Syr LexPlus 10 beschrieben.

Einstecken und Browser

Schon direkt nach dem Einstecken hat das Gerät eine IPv4-Adresse bezogen und über das Touch-Menü konnte ich die Daten ermitteln. Also schnell mal in einem Browser eingegeben und schon sehe ich das gleiche Bild, welches das Display anzeigt:

Soweit was das erst mal unspektakulär. Leider ist es auch wirklich nur eine "Ausgabe" der aktuellen Anzeige. Keine der Flächen kann angeklickt werden. Auf dem Gerät selbst kann ich genau den Wasserverbrauch, Regenerationsdaten, Wasserdruck etc. auslesen. Das System erfasst also schon eine Menge an Daten. Es gibt sogar eine "App" für IOS und Android. Da das Gerät aber im privaten LAN nicht erreichbar ist, sendet es die Daten natürlich in eine "Cloud". Also muss man doch erst mal genauer hinschauen, was das passiert.

Ein Portscan auf das Gerät ergab zumindest keinen direkt sichtbaren offenen Port. Leider liefert auch jede andere URL nur einen Fehler. Anscheinend liefert der Webserver wirklich nur das Bild aus, obwohl es doch sehr einfach wäre einfach die Werte auch als Text, XML, JSON-Ausgabe zusätzlich zu liefern.

Schaut man sich die Kommunikation mit Fiddler an, dann sieht man, dass es sich um einen "Server: MQX HTTPSRV/2.0 - Freescale Embedded Web Server v2.0" handelt, der eine kleine Default-Seite ausliefert, die nur das Bild per <img src="/sd/screenshot.bmp"> einbindet.

Diese einfache erlaubt ja schon mal die Einbindung in ein eigenes Anzeigeportal als Image. An die Daten kommt man so aber nicht ran.

Kommunikation Lex-Plus zur Cloud

Natürlich lasse ich ein Gerät an meiner Trinkwasserversorgung erst mal nicht ungefiltert ins Internet. Ich habe auch gar nicht den Wunsch, per App von unterwegs diese Daten zu nutzen und schon gar nicht diese zu Servern zu senden, zu denen ich kein Vertragsverhältnis habe. Datenschutz, Sicherheit und Dauerhaftigkeit sind meine Überlegungen, die Daten lokal abzufragen. Also habe ich den Switch-Port des Syr erst mal auf einem PC mit Wireshark gespiegelt und meine Befürchtungen haben sich bestätigt. Schön lesbare Kommunikation ohne HTTPS-Absicherung. Zumindest ist die Analyse damit natürlich auch sehr einfach und ich muss nicht mal die Kommunikation "knacken". Kaum hat die Anlage per DHCP eine IP-Adresse bekommen, sendet sie schon den ersten HTTP-Post.

Ich habe hier nicht alle Posts beschrieben, sondern nur eine Auswahl.

Als nächstes sendet er einen weiteren Post an einen Server in Polen, in dem die MAC-Adresse eine Seriennummer u.a. Daten gesendet werden

Etwas später hat er noch eine ausführlichere Liste gesendet, in der noch viel mehr Daten hinterlegt waren. Eine komplette Wertemenge, die auf dem Gerät selbst als Grafik abrufbar ist, habe ich noch nicht gesehen. Vermutlich muss ich dazu die App installieren und deren indirekte Kommunikation über den Cloud-Proxy analysieren. Soweit wollte ich dann aber erst mal nicht gehen. Den ein oder anderen Fehler scheint es aber auch auf der Serverseite noch zu geben.

Die Anfragen mit ca. 250 Bytes und die Rückantworten mit ca. 670 Bytes und alle 10 Sekunden ergeben schon ein Download von 5 Megabyte/Tag oder 170 Megabyte/Monat. Auf der Seite des Clients wohl eher zu verschmerzen, so sie nicht gerade per GSM-Modem im Ferienhaus online sind. Aber auf der Provider-Seite wäre es mal interessant zu wissen, wie viel Bandbreite dort bereitgestellt werden muss.

Viel wichtiger ist die Frage, wie lange Syr diesen "Cloud Service" aufrecht erhalten kann, wenn der Kunde quasi nur einmalig über den Kaufpreis dafür bezahlt. Es gibt nämlich bei der Einrichtung keinen Hinweis auf Datenschutz, sie schließen keinen "Vertrag" ab und die App kostet auch nichts. Nicht dass es auch hier ein Abruptes Ende gibt oder die Daten anderweitige "verwertet" werden.

Web und App

Die Anbindung an das Internet hat natürlich für den Kunden erst einmal den werblichen Aspekt, auch auf einem Smartphone (IOS und Android) den Status von überall abfragen zu können. Auf der Webseite sind neben dem Salzverbrauch auch folgende Stammdaten ersichtlich. Wer genau dazu den HTTP-Post betrachtet, kann Übereinstimmungen vieler Felder sehen, die vom LexPlus zur Cloud gesendet werden.

Im Web und der App gibt es noch ein Diagramm zum Satzverbrauch, welches aber wohl auf Daten in der Cloud basiert. Ich habe nicht gesehen, dass historische Daten übertragen wurden. Die hat aber z.B. der LexPlus lokal in seinem Speicher, z.B. Informationen zum Druckerverlauf und den Entnahme-Mengen. Ich bin mal gespannt, ob die Webseite bei Fehlern und Problemen mir eine Mail an die hinterlegte Adresse sendet.

Das Connect Modul ist ziemlich "gesprächig". da es keinen beständigen Rückkanal aufbaut, muss es "pollen", d.h. ca. alle 10 Sekunden fordert es Daten alternierend von zwei Webseiten an und bekommt Antworten zurück, die es auswertet.

Eine Änderung auf der App oder im Web wird dann wohl auf dem Cloud-Service hinterlegt und beim nächsten Connect in der Antwort mit geliefert.

Kommunikation App zur Cloud

Die Abfrage und Anzeige der Daten kann wahlweise über eine IOS oder Android-App erfolgen. Hier kommen mehr Daten an als "nur" ein BMP-Bild. Also habe ich auch hier mich zwischen die App und die Cloud gesetzt um mal zu sehen, was hier passiert. Fiddler als HTTP-Proxy leistet hier sehr gute Dienste und wir sehen auf den ersten Blick schon, dass die APP auch nur HTTP nutzt und neben ein paar Daten als WebServices noch viele Bilder nachlädt.

Die eigentliche "Anmeldung" erfolgt hier bei Paket 32 mit dem Zugriff auf den SyrApiService.Svc. Allerdings fällt auch auf, dass alle Anfragen direkt mit einem "200 OK" beantwortet werden. Stattdessen wird die App wohl direkt die Anmeldedaten abfragen und "blind" mit senden. Im Request sieht man dies aber nicht als Authentication-Header im HTTP-Kopf sondern als Daten eines Form-POST:

POST http://syrconnect.de/WebServices/Api/SyrApiService.svc/REST/GetProjects HTTP/1.1
Host: syrconnect.de
Content-Type: text/xml
Connection: keep-alive
Connection: keep-alive
Accept: */*
User-Agent: SYR/29 CFNetwork/808.0.2 Darwin/16.0.0
Content-Length: 288
Accept-Language: de-de
Accept-Encoding: gzip, deflate

<?xml version="1.0" encoding="utf-8"?>
<sc>
   <api version="1.0">xxxxxxxxxxxxxxxxxxxxxxxxxxxxx</api>
</sc>

Ich habe den Code natürlich durch "xxx" ersetzt. Die richtigen Daten sind durch die App wohl zusätzlich "unkenntlich" gemacht, denn der Base64-String wird nach der Decodierung nicht als Benutzer/Kennwort sichtbar. Das kann aber auch einfach nur ein Salt mit einem in der App statisch hinterlegten Information sein. Sicher ist das vermutlich nicht. Dazu müsste eher vom Server eine Information zum Verschlüsseln kommen. Die Antwort liefert dann eben so einen langen Base64 Code:

HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Sun, 09 Oct 2016 11:03:38 GMT
Content-Length: 771

<?xml version="1.0" encoding="utf-8"?>
<sc>
   <api version="1.0">xxxxxxxxxxxxxxxxxxxxxxxxxxxxx=</api>
   <suc v="true"/>
</sc>

Ich habe den Code natürlich durch "xxx" ersetzt

POST http://syrconnect.de/WebServices/SyrControlWebServiceTest2.asmx/GetDeviceCollectionStatus HTTP/1.1
Host: syrconnect.de
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Connection: keep-alive
Accept: */*
User-Agent: SYR/29 CFNetwork/808.0.2 Darwin/16.0.0
Content-Length: 243
Accept-Language: de-de
Accept-Encoding: gzip, deflate

xml=<?xml version="1.0" encoding="utf-8"?>
   <sc>
      <si v="App-2.23.0-de-DE-iOS-iPhone-10.0.2-de.consoft.syr.connect" />
      <us ug="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" />
      <col>
         <dcl dclg="yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" />
      </col>
   <cs v="36AA"/>
</sc>

Der Mitschnitt zeigt die Verbindung einer bereits eingerichtet App. Es kommt also gar kein "404 Access Denied" mit einer nachfolgenden Authentifizierung. Die Anmeldung wird von der App schon beim ersten Request mitgeliefert.

Die ersten vier Anfragen scheinen Informationen von Syr zu laden mit Produkten, News, Hinweisen samt Bilder etc. ehe dann bei Frame 32 die Liste der Projekte geladen wird. Im Request gibt es keine HTTP-Authentifizierung. Stattdessen wird eine XML-Anfrage mit einem BASE64-codierten Binärstring gesendet. Im Frame 45 kommen Details zu den Projekten und für eine Auswertung sind natürlich dann die ab Frame 48 wiederkehrenden Anfragen relevant. Hier erfolgt ein POST auf eine Url mit Anmeldeinformationen im Request und einer umfangreichen Antwort. Hier ein Auszug:

Ich dokumentiere hier natürlich nicht den Request mit meine Anmeldedaten und habe mir auch nicht die Mühe gemacht, die Generierung dieser Informationen zu knacken. Aber jeder Request ist anscheinend "gleich", d.h. es gibt keine laufende oder variable Komponente. Das eröffnet zumindest einen Weg diese Daten per PRTG indirekt über die Cloud abzufragen.

Ein Post auf die URL mit den Daten im Payload liefert eine XML-Datei. Diese kann ich per PRTG:Custom Sensor abfordern, konvertieren und die Werte an PRTG übergeben.

Ich wollte "freundlich" sein und als UserAgent meine Mailadresse hinterlegen aber anscheinend hat der WebService ein "Whitelisting" gültiger Agenten und liefert dann nur eine leere XML. Also muss mein PowerShell-Script sich als IOS App ausgeben.

Eher ich aber nun mit dem PRTG-Sensor anfange, kommt noch eine dritte Kommunikation ins Blickfeld

Firmware

Ich wollte ja sicher sein, dass ich mit der aktuellsten Version arbeite. Und tatsächlich gab es für mein frisch installiertes Gerät schon ein Firmware Updates. Das Update durfte natürlich nur mit Überwachung durchgeführt werden. Die Überprüfung auf eine neu Firmware geht über einen dritten Provider (www.husty.pl):

Alles natürlich weiter unverschlüsselt und ohne Authentifizierung o.ä. Ich kann nur hoffen, dass die beiden Dateien mit 649kB und 2971kB intern irgendwie signiert sind. Ich habe aber nicht gesehen, dass der LexPlus10 das Update alleine durchgeführt hat. Die größere Datei ist ein ZIP-Archiv mit Audio-Dateien und Fonts. die kleinere Firmware errät zumindest auf den ersten Blick keine weiteren interessanten URLs des eingebauten Webservers. Nur damit eine "App" funktioniert, sollte man es möglichen Angreifern nicht so einfach machen.

"Wenn heizungstechnische Geräte mit dem Internet verbunden sein sollen, dann kommt es nicht nur auf die hohe Qualität der Elektronik an, sondern auch auf die Sicherheit der Daten und die Bedienbarkeit"
Quelle: https://www.consoft.de/

Für Geräte der Wasserversorgung würde ich das aber genau so sehen.

Offen und Wünsche

Die Installation durch den Handwerker war relativ problemlos und das weichere Wasser macht sich beim Duschen, Waschen aber auch Putzen (keine Kalkschlieren, freie Perlatoren) bemerkbar und ich bin langfristig gespannt, wie sich entsprechend der Waschmittelverbrauch reduziert. Bezüglich der "Wassertechnik" habe ich nichts auszusetzen, zumal diese Funktionen auch alle ohne Cloud funktionieren. Aber technologisch wäre noch viel mehr drin oder müsste auf jeden Fall etwas sein:

  • Lokaler Service
    Der LexPlus hat einen kleinen WebServer, der aktuell nur das angezeigte Bild liefert. Es kann doch nicht so schwer sein, über eigene URLs auch die Daten zu liefert, die der Lex so an die Cloud sendet. Für Anwender könnte es auch reichen, denn die Buttons "klickbar" wären und damit das Display quasi "fernsteuerbar" sind. Mit einem 70€ Tablet könnte man sich eine "Fernkonsole" bauen. Für eine Abfrage der Daten aus dem lokalen LAN ist natürlich eine XML, SOAP, JSON-Antwort eleganter zur Einbindung in eigene Projekte. Die Diagramme könnte man einfach als CSV-Dateien abrufbar machen.
    Für den Anfang würde es mir schon mal reichen, die Gesamtanzahl der enthärteten Liter Wasser als Counter zu haben. Ähnlich einem LAN-Port könnte PRTG oder eine andere Lösung schon einfach die Differenz zur vorherigen Messung erstellen und damit einen Momentanverbrauch ermitteln.
  • Leckage-Schutz
    Weder über die Webseite noch die Cloud Services sind die Daten erreichbar, die direkt am Gerät auszulesen sind. Dabei erfasst das System schon neben dem Wasserdruck auch die Verbrauchswerte inklusive aktuellem Verbrauch. Syr stellt mit dem Safe-T Connect auch einen Leckage-System her. Genaugenommen könnte dies aber auch der LexPlus selbst und z.B. per Schaltausgang ein Magnetventil schließen, wenn zu lange kontinuierlich das Wasser läuft (Thema Schlauch geplatzt). Laut Anzeige hat er eine sehr genaue Momentanverbrauchsmessung.
    Mit einem Magnetventil im Zulauf und etwas Software wäre beides in einem Gerät möglich und sogar bei Salzmangel könnte das Wasser abgestellt werden.
  • App-Anmeldung
    Es ist mir nicht gelungen in der App ein Syr-Connect Konto anzulegen. Fehler ist hier, dass die App nur ein Kennwort mit 5 oder mehr Buchstaben erzwingt, die Webseite mittlerweile aber 8 Zeichen erwartet. Das ist aber eher ein kosmetischer Fehler, der einfach abzustellen wäre.
  • Portal:/App: Vertrags- und Datenschutz-Fragen
    Die Anmeldung im Portal geht schnell aber ohne jeglichen sichtbaren Hinweis einher, welche Leistungen Syr hier zusichert. Insbesondere wie lange der Service mit welchen Randbedingungen bereit gestellt wird. Wer hat z.B. Zugriff auf die Daten, wo werden die Daten gelagert etc. Eine ganz profane Datenschutzerklärung habe ich nicht gesehen.
  • Portal Adressdaten
    Bei der Registrierung kann man auch die Adresse angeben. Diese wird aber nicht mit bei der ersten Anlage übernommen. Ich kann verstehen, dass die "Kontodaten" von der "Anlage" getrennt sind, aber bei den meisten Anwendern wird es ja wohl die gleiche Information sein.
  • Web Portal: Abmeldung
    Ich habe auf der Webseite keinen Button zum "Abmelden" gefunden. Und wir nicht anders zu erwarten konnte ich das Fenster im Browser schließen und auch wieder öffnen und war wieder drin. Erst ein komplettes Schließen aller Browserfenster hat die erneute Anmeldung erforderlich gemacht.
  • Steuerung per Internet ohne Verschlüsselung ?
    Die Fernsteuerung erfolgt derart, dass der Client Änderungen auf einem Server hinterlegt, die der LexPlus beim nächsten Polling (20Sek) abholt und umsetzt. All das erfolgt ohne weitere Authentifizierung zwischen App/Browser und Gerät. Jeder, der also auf eine Abfrage eine Antwort sendet, könnte z.B. die Rohwasserhärte, den Salzvorat und die Regenerationszeit umstellen.

Das sind mir schon sehr viele "offene Punkte", die mich wirklich daran zweifeln lassen, dass eine Internet-Anbindung eines Wasser-Enthärters wirklich eine gut Idee sein soll. Würde Syr auf den Computer eine kleine minimalistische Webseite aufsetzen, die auch aus dem internen LAN abfragbar ist und in andere Haus-Automatisierungssysteme integriert werden könnte, wäre das was anderes. So aber verzichte ich lieber auf die "App-Anbindung" und laufe ab und an in den Keller. Denn ohne Internet kann die Box keine Mail senden und einen Schaltkontakt für "Salzmangel" oder "Überlauf" oder andere Störungen gibt es leider nicht.

Ich kann nur hoffen, dass eine zukünftige Firmware hier mehr Sicherheit und lokale Zugriffe erlaubt. Ansonsten bleibt der Netzwerkstecker abgezogen.

Nur gut dass die eigentlich Enthärterfunktion des Geräts auch komplett ohne Cloud funktioniert.

Weitere Links