(kein) echtes Sicherheitsbewusstsein von eQ-3 zu Homematic CCU Sicherheitslücken?

Ob eQ-3 als Hersteller der Homematic CCU das Thema Sicherheit wirklich ernst nimmt oder nur pressewirksam in einer Eigendarstellung darüber berichtet, wie zuletzt am 18.03.2019 die eQ-3 Pressemitteilung aka CVE-2019-10119 CVE-2019-10120 CVE-2019-10121 CVE-2019-10122, ich weiß es nicht ich glaube es durch meine bisherigen Erfahrungen nicht mehr.
Ich als Melder von potentiellen Sicherheitslücken fühle mich jedenfalls zum Ende hin nicht ernst genommen.
Auch die bisher schon bekannten 6 CVEs aus dem Jahr 2018, davon 3 schwere Sicherheitslücken, siehe Übersicht auf www.cvedetails.com, sind teilweise heute noch nicht behoben worden oder erst “frisch” nach einem Jahr.
Leider teils nur oberflächlich geflickt….

Chronologie der Kommunikation mit eQ-3

In Summe hatte ich anfänglich 16 Punkte an eQ-3 gemeldet. Die ersten am 29.01.2019, der Rest verteilt bis zum 08.05.2019.

Am 19.03. habe ich zum aktuellen Stand der bisherigen Funde nachgefragt.

Am 19.03. habe ich auch an die BSI CERTBUND E-Mailadresse alle bisherigen Punkte und die passenden Exploits geschickt, mit der Hoffnung das es dann mehr Gewichtung beim Hersteller bekommt. eQ-3 hatte ja selber von einer “engen Zusammenarbeit mit dem BSI” geschrieben.
Am 05.04. vom BSI final die Info erhalten, das auch ich eine Antwort von eQ-3 bis zum 08.04. erhalten soll.
Am 08.04. wurde ich vom BSI gefragt, ob ich denn wie erwartet von eQ-3 kontaktiert wurde.
Am 11.04. über das BSI noch mal nachgehakt, der 08. war ja ereignislos verstrichen.

Am 11.04. Abends von eQ-3 eine erste Antwort erhalten.
Am 27.04. von eQ-3 einen “streng vertraulichen” Releaseplan erhalten, mit der Info dass dies eher eine große Ausnahme ist und der Hersteller eher kein Feedback gibt.

Am 16.05. warnte das BSI über den CertBund Twitter Account Mehrere tausend HomeMatic SmartHome-Systeme in Deutschland sind offen aus dem Internet erreichbar.
Die Zahlen decken sich mit dem was ich über die Wochen hinweg kommuniziert habe.
Dank meines Vorschlags die einfache Erkennung der Systeme zu verschleiern, indem der HTTP Header “Server:” abgeschaltet wird, sind Homematic Systeme mit aktueller 2.47.10/3.47.10 und RaspberryMatic Firmeware nicht mehr so leicht auffindbar. Am 16.07. listet shodan 5388 offene Systeme und censys nur 1576. Es waren mal weit über 8000 bei shodan.
Am 25.06. wurden die Releases CCU3 3.47.10 und CCU2 2.47.10 veröffentlicht (für die CCU2 somit sogar 2 Wochen früher als geplant).

Ende Gut, alles Gut?

Nein, leider nicht. Ein erstes Antesten hat gezeigt, das teilweise noch die selben Sicherheitslücken vorhanden sind und nun auch mindestens eine neue hinzugekommen ist ;-).
Ich bereite nun die Veröffentlichung der bisherigen CVEs vor und zeige auf, wie man die Schwachstellen auch teilweise sehr gut kombinieren kann.
Dem Hersteller werde ich die neue Schwachstelle melden und die unvollständig gefixte aufzeigen. Ich hoffe weiterhin, das es positiv und vor allem professioneller weitergehen wird.
Wenn ich schon als Hobby Pentester das hinbekomme, weil die CCU ein gutes Übungsobjekt ist, um eine Schwachstelle mit einer anderen zu verbinden, was macht dann der professionelle digitale Einbrecher mit diesem Wissen?

Am 15.07. habe ich meine Zusammenfassung für die mittlerweile 17 Punkte an eQ-3 und dem BSI verschickt.
Und die Reise ging noch weiter…

Update am 17.09.2019:

Weitere Chronologie der Kommunikation mit eQ-3

Ab dem 24.07. habe ich die CVEs nach und nach veröffentlicht

Am 01.08. eQ-3 nochmalig kontaktiert, weil keinerlei Reaktion kam und dabei auch neue Schwachstellen gemeldet
Am 05.08. hat mich das BSI gefragt, wie der Stand der Dinge ist, da die CVEs gesichtet wurden
Am 16.08. hat das BSI bei eQ-3 ein weiteres mal nachgehakt
Am 21.08. hat eQ-3 eine kurze Entschuldigungs E-Mail geschrieben mit der Aussicht einer neuen finalen Stellungnahme
Am 26.08. kam die neue Stellungnahme und ein neuer Zeitplan
Am 17.09. wurden die Releases CCU3 3.47.18 und CCU2 2.47.18 veröffentlicht und diese beheben die schlimmsten Punkte aus der Liste.

Jetzt kann ich es ja verraten. Es hätte einen November Release geben sollen mit den nun vorliegenden Korrekturen, aber interessanterweise wurden diese ReGa Korrekturen allesamt vom Opensource RaspberryMatic Entwickler gefixt und auch meine Anregung das Accesslevel in der system.fn und programs.fn zu checken hat er umgesetzt, wodurch der Punkt 19 aka CVE-2019-14473 entschärft wurde. Diese Arbeit hätte ich eindeutig von eQ-3 erwartet, aber sei’s drum.

Und Jetzt? Ende Gut, alles Gut?

Hmm…
Der neue Zeitplan hat noch ein paar Punkte offen, wir werden also sehen. Ich kenne die angestrebten Zeiträume und teste dann nach.
Aus Software Sicht wird sich also hoffentlich alles erledigen.

Aber um es Spannend zu belassen, da kommt noch was ganz anderes.
Bis dahin, abwarten….

Update 10.10.2019:
Die Qualität der Releases hat leider immer mal zu wünschen übrig. Der Release 2.47.18 mit den ganzen Sicherheitsupdates wurde am 19.09. sang und klanglos zurückgezogen, weil im HM-IP Java Prozess ein neuer Fehler vorhanden war, der die HM-IP Geräte Kommunikation gestört hat. Erst 5 Tage später gab es dann am 24.09. den 2.47.20 Release.
Das selbe ist nun am 09.10. mit dem Release 3.47.18 passiert. Die korrigierte 3.47.22 kam erst am 23.10. raus.
Ich kann es für die HM-IP Welt verstehen, aber Nutzer ohne HM-IP Geräte sind nicht betroffen.
Funktionalität geht immer vor Sicherheit ?!? Ich wüsste auch nicht wie ich mich entschieden hätte, wenn das meine Software wäre. Aktuell konnte man jedenfalls kein CCU3 Update mit den Sicherheitsupdates für ganze 2 Wochen bekommen.

Update 10.12.2019:
Die Firmware 2.49.17 & 3.49.17 wurde released
Nach vermehrten Problemmeldungen wurde für die CCU2 ein Tag später die 2.49.18 rausgebracht.
ABER! Nun endlich hat die CCU2 einen neuen Linux Unterbau bekommen und ist in Teilen sogar deutlich neuer als die CCU3.

Aber Jetzt?!? Ende Gut, alles Gut?

Ich denke leider nein.
Im September hatte ich eine E-Mail bekommen mit folgender Abschlussinformation:

Nach dem nächsten Release-Paket melden wir uns wieder gesammelt
zu den bis dahin gemeldeten Findings mit einer weiteren inhaltlichen und zeitlichen Einschätzung.

Heute ist der 3. Januar und seit dem Release am 10. Dezember hat sich eQ-3 leider nicht wie versprochen zurückgemeldet.
Es sind nur noch fünf der Punkte (2, 4, 5, 7 & 15) aus der Liste unten offen, wobei nur Punkt Nr. 5 als sehr kritischer Fehler wichtig wäre zu korrigieren. Es sind nun mehr als 22 Monate vergangen und nichts ist passiert!

Außerdem glaube ich, dass sich die Einstellung von eQ-3 nicht ändern wird, da ich vor Monaten eine Begegnung der ganz anderen Art hatte. Ich war auf der IFA und wollte mich bei der Gelegenheit mal persönlich vorstellen. Ich wollte nicht der unbekannte „böse Hacker“ sein und habe mit Herrn Grohmann, Vorstand der eQ-3 AG, das Gespräch gesucht. Ich habe ihn wohl auf dem falschen Fuß erwischt, anders kann ich mir das „ungeschminkte“ Gespräch nicht erklären. Von Einsicht keine Spur, eher die Gegenfrage warum ich auf dem „Marktführer“ rumhacke, die anderen Anbieter seine noch viel schlimmer. Die vielen Sicherheitsprobleme im ReGa Prozesse kennt er doch schon alle. Was ich machen will, wenn diese gefixt wurden, weil ich ja dann nichts mehr zum Auffinden habe. Das Gespräch dauerte sogar recht lange, war für mich in Summe aber absolut frustrierend. Ich würde mich nicht wundern, wenn diese Einstellung auf die untere Belegschaft „runter strahlt“.

eQ-3 hat zum zukünftigen neuen „Connected Home over IP“ („CHIP“) Standard seinen Standpunkt veröffentlicht <Ironie=on> und natürlich gibt es nur einen Hersteller, der es richtig macht <Ironie=off>.

[...]Homematic IP ist bis heute das einzige System, dessen Protokoll-, IT- und Datensicherheit vom VDE zertifiziert ist.

Aber bei den Aussagen bitte auch mal an die eigene Nase fassen!

[...]Bislang ist Security eher eine deutliche Schwäche der sogenannten Smart Home „Standards“. 
[...]Die meisten heutigen Smart Home Systeme haben massive Sicherheitslücken. Wie soll ein neues System sicher sein, wenn es unsichere Produkte früherer Technologien einbindet?

Und Jetzt?!? Fertig mit den Problemen?

Update 14.05.2020:

Für die seit 2018 bekannte Schwachstelle CVE-2018-7297 hatte eQ-3 im August 2019 diese Antwort gegeben:

Die Schwachstellen in der CCU3 sind bereist behoben. 
Der gleiche Ansatz wie bei der CCU3 führte bei der CCU2 dazu , dass die Partnererweiterungen (z.B. Penzler-App) nicht mehr funktionierten.
Daher ist die Behebung evtl. nicht wirtschaftlich sinnvoll lösbar, dies muss für das Release im 1. Quartal 2020 geprüft werden.

Naja…
Q1/2020 ist jetzt im Mai 2020 schon länger vorbei.
Aber Zeit = Geld wurde wegen CVE-2019-9582 aufgewendet um ein großes Update der CCU2 auf eine deutlich neuer Build Root und BusyBox Version durchzuführen. Dabei wurde auch gleich curl mitgebracht, was viele freut aber auch zu Problemen führte.
Und der Kernel wurde erneuert, natürlich ohne “Absprache”/Test mit den AddOn Projekten und schwupps liefen in CUxD die FTDI USB Sticks nicht mehr.

Die Liste der gemeldeten Punkte

Punkt Tag der Meldung Problem CCU2/CCU3? Resultat bei einem Angriff Ergebnis oder Lösung am 08.08. Ergebnis oder Lösung am 17.09. Ergebnis oder Lösung am 10.12.
Punkt Tag der Meldung Problem CCU2/CCU3? Resultat bei einem Angriff Ergebnis oder Lösung am 08.08. Ergebnis oder Lösung am 17.09. Ergebnis oder Lösung am 10.12.
129.01.2019veralteter lighttpd Webservernur CCU2Denial of ServiceLeider noch kein Update. Mittlerweile als CVE-2019-9582 veröffentlichtN.A.mit 2.49.17 gefixt
229.01.2019veraltetes Oracle Java 8u121nur CCU2noch kein konkretesmit Release 2.47.10 Update auf letztes freies Oracle Java 8u201. Nach dem Update ist vor dem Update, somit wieder veraltetN.A.N.A.
329.01.2019stark veraltetes Embedded Linux Build Root und BusyBoxnur CCU2noch kein konkretesTeil der mittlerweile als CVE-2019-9582 veröffentlichen SchwachstelleN.A.mit 2.49.17 gefixt
413.02.2019Keine generelle Login SessionID Absicherung von CGI und HTML Seitenbeide* Denial of Service
* Uncontrolled Resource Consumption
* File Modification / Deletion
* eQ-3 ist nicht für die AddOns verantwortlich, liefert jedoch den Unterbau und der enthält derzeit noch eine veraltete Node.js Version
* eQ-3 eigene Seiten bleiben ungeschützt
Ist es eine CCU2 oder CCU3? http://myip/upnp/basic_dev.cgi
Installierte Firmware abfragen für weitere Angriffe: http://myip/api/backup/version.cgi
* Mediola NEO Server v2.4.5 ist nur teilweise gelöst, alle Details als veröffentlicht
* Cloudmatic noch nicht in der Firmware, jedoch schon vom AddOn Hersteller seit Ende Mai mit einem Hotfix vorbereitet, siehe Github Issue #8, Details als CVE-2019-9584 veröffentlicht
N.A.N.A.
528.02.2019ReGaHss nicht dokumentierter interner Befehl system.Exec()beideRemote Code ExecutionKeine befriedigende Lösung. Bei Recherchen im Nachgang sogar schon seit Feb. 2018 bekannt als CVE-2018-7297 veröffentlichte SchwachstelleN.A.N.A.
628.02.2019Aufruf der /index.htm Seite erzeugt SessionIDbeideDenial of ServiceGelöst mit Release 2.41.8 und 3.43.15.
Wurde schon vorher durch anderen Pentester gefunden und unter den CVEs CVE-2019-10119, CVE-2019-10120 und CVE-2019-10121 veröffentlicht. Wurde am 18.03. Pressewirksam ausgerollt
schon gefixtschon gefixt
728.02.2019Process Fuzzing auf die URI /xml-apibeidenoch kein konkretessoll eventuell in kommenden Versionen behoben werdenN.A.N.A.
813.03.2019JSON API User.getUserPWD ohne gültige SessionIDbeidePasswort Hash auslesenWurde parallel schon von anderem Pentester gefunden und als CVE-2019-9727 veröffentlicht.
Mit Release 2.41.9 und 3.43.16 nur vom LEVEL NONE auf LEVEL USER gehoben und somit konnte zumindest ein Account mit Level User das Admin Passwort weiterhin auslesen.
Erst seit Release 2.47.10 / 3.47.10 wurde User.getUserPWD durch User.hasUserPWD ersetzt und somit final gefixt.
schon gefixtschon gefixt
912.04.2019expliziter Hinweis auf schon bekannte CVEsbeide* Directory Traversal
* Arbitrary File Write
* Remote Code Execution
Alte Lücken wie CVE-2018-7297 und auch neue Lücken wie CVE-2019-9726 sind weiterhin nicht gefixtCVE-2019-9726 ist mit 2.47.18 & 3.47.18 gefixtschon gefixt
1012.04.2019JSON API Interface.getMetadata / Interface.setMetadata und Interface.removeMetadata ohne gültige SessionIDbeideMeta Daten auslesen, (korrupt) verändern, löschenSeit Release 2.47.10 und 3.47.10 gefixed. Als CVE-2019-9585 veröffentlichtschon gefixtschon gefixt
1107.05.2019Erzeugung einer SessionID ohne gültigen Loginbeide* Escalation of Privileges
* Denial of Service
* Information Disclosure
Mit Release 2.47.10 und 3.47.10 nur für wenige Seitenaufrufe gefixed, der große Rest ist noch angreifbar. Als CVE-2019-9583 veröffentlichtmit 2.47.18 & 3.47.18 gefixtschon gefixt
1207.05.2019Ohne gültigen Login kann man die Systemprotokoll Einträge löschenbeide* Escalation of PrivilegesNoch ungelöst. Als Teilpunkt des CVE-2019-14475 veröffentlichtmit 2.47.18 & 3.47.18 gefixtschon gefixt
1307.05.2019Ohne gültigen Login kann man die Servicemeldungen lesenbeide* Escalation of PrivilegesNoch ungelöst. Als Teilpunkt des CVE-2019-14475 veröffentlichtmit 2.47.18 & 3.47.18 gefixtschon gefixt
1407.05.2019Ohne gültigen Login kann man User teilweise einrichtenbeide* Escalation of PrivilegesNoch ungelöst. Als Teilpunkt des CVE-2019-14475 veröffentlichtmit 2.47.18 & 3.47.18 gefixtschon gefixt
1508.05.2019Prozess Fuzzing im ReGaHss Process für Call() ExecEnum() Methodenbeidenoch kein konkreteszumindest im Logfile entstehen Einträge wegen fehlerhafter AufrufeN.A.N.A.
1608.05.2019ReGaHss Prozess Absturz bei einem POST Request mit einem leeren Call("")nur CCU3Denial of ServiceNoch ungelöst. Als CVE-2019-14474 veröffentlichtmit 2.47.18 & 3.47.18 gefixtschon gefixt
1715.07.2019Keine Session Invalidierung/Löschung beim Abmleden im Release 2.47.10/12 und 3.47.10beidemit CVE-2019-9726 die SessionID auslesen und WebUI betretenIch habe keine Lust dafür einen CVE zu erstellen, zumal die Lücke mit dem Release 2.47.15 und 3.47.15 sogar schon wieder gefixt wurdemit 2.47.18 & 3.47.18 gefixtschon gefixt
1801.08.2019Ohne gültigen Login kann man interne HM Scripte/Programme deaktivieren, manipulieren und löschenbeide* Escalation of PrivilegesNoch ungelöst. Als Teilpunkt des CVE-2019-14475 veröffentlichtmit 2.47.18 & 3.47.18 gefixtschon gefixt
1901.08.2019Das Rechte Konzept der CCU besitzt keine echte Mandantenfähigkeit. Ein Gast und User Account kann viele Admin Operationen durchführenbeidemit CVE-2019-9726 die SessionID auslesen und WebUI betretenNoch ungelöst. Als CVE-2019-14473 veröffentlichtmit 2.47.18 & 3.47.18 gefixtschon gefixt
2026.08.2019Neue Variante einer Remote Code Execution bei bestimmten HTTP POST RequestsbeideRemote Code Execution-----Als CVE-2019-16199 veröffentlicht, gefixt mit 2.47.18 & 3.47.18schon gefixt
2112.05.2020Nächste Variante einer Remote Code Execution durch AutoLogin Funktion nach Ersteinrichtung, als CVE-2020-12834 veröffentlichtbeideRemote Code Execution---------------

Sollte irgendwann in der Zukunft nach nun schon mehr als 22 Monaten die öffentlich als CVE-2018-7297 bekannte RCE Angriffsmöglichkeit in der CCU2 gefixt werden, sind User mit bestimmten zusätzlichen AddOns weiterhin angreifbar.
CVE-2018-7297 macht sich hier zu nutze, dass der nicht dokumentierte interne Befehl system.Exec() im ReGaHss Prozess auf dem Port 80 ungeschützt nutzbar ist. Die Funktion ist unter Homematic Besitzers schon seit Jahren bekannt und wird in lokalen Skripten genutzt. Leider kann dies auch ein Angreifer Remote ausnutzen.

eQ-3 ist zwar nicht für die AddOn Hersteller verantwortlich. Da es aber keine grundlegende Absicherung in der CCU gibt, existieren out-of-the-box zusätzliche Angriffsvektoren und somit z.B. weitere simple RCE Angriffsmöglichkeiten.
Auf meinen Hinweis zur Remote Code Execution durch Addon Installationen kam im August 2019 die Antwort: Eine Behebung ist derzeit noch nicht eingeplant.
Speziell zum CUxD AddOn kam im August 2019 diese Antwort: Die CuxD ist ein Addon, dies wird mit CuxD abgestimmt, da die Behebung der Schwachstelle von deren Seite ausgeführt werden muss.

Die ersten fünf Einträge in der nachfolgenden Tabelle kann man für RCE Angriffe ausnutzen, ohne Login:

AddOn CVE
‘CUxD’ version 2.3.4 CVE-2019-14985
‘XML-API’ version 1.2.0 CVE-2019-14984
‘ScriptParser’ version 1.8 CVE-2019-18937
‘E-Mail’ version 1.6.8.c CVE-2019-18938
‘HM-Print’ version 1.2a CVE-2019-18939
‘Mediola NEO Server’ version 2.4.5 CVE-2019-13030
‘CloudMatic’ CVE-2019-9584

Kein zusätzliches AddOn, aber eine weitere RCE Möglichkeit ohne Logindaten eingeben zu müssen:
Inspiriert durch CVE-2019-15850, wo die JSON API Methode ReGa.runScript nach dem manuellen Login genutzt wird ist der weitere Angriffsvektor in CVE-2020-12834 entstanden. Denn es wird die AutoLogin Funktion in der Ersteinrichung aktiviert. Durch dieses AutoLogin wird beim Aufruf der WebUI automatisch eine gültige SessionID erzeugt, die wir in der JSON API Methode ReGa.runScript nutzen. Natürlich kann man dann noch ganz andere Dinge anstellen in der WebUI.

Disclaimer

The information provided is released “as is” without warranty of any kind. The publisher disclaims all warranties, either express or implied, including all warranties of merchantability. No responsibility is taken for the correctness of this information. In no event shall the publisher be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if the publisher has been advised of the possibility of such damages.

The contents of this advisory are copyright (c) 2019, 2020 by psytester and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

Written on May 14, 2020