(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.2019 habe ich zum aktuellen Stand der bisherigen Funde nachgefragt.
Am 19.03.2019 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.2019 vom BSI final die Info erhalten, das auch ich eine Antwort von eQ-3 bis zum 08.04.2019 erhalten soll.
Am 08.04.2019 wurde ich vom BSI gefragt, ob ich denn wie erwartet von eQ-3 kontaktiert wurde.
Am 11.04.2019 über das BSI noch mal nachgehakt, der 08. war ja ereignislos verstrichen.
Am 11.04.2019 Abends von eQ-3 eine erste Antwort erhalten.
Am 27.04.2019 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.2019 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.2019 listet shodan 5388 offene Systeme und censys nur 1576. Es waren mal weit über 8000 bei shodan.
Am 25.06.2019 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.2019 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.2019 habe ich die CVEs nach und nach veröffentlicht
Am 01.08.2019 eQ-3 nochmalig kontaktiert, weil keinerlei Reaktion kam und dabei auch neue Schwachstellen gemeldet
Am 05.08.2019 hat mich das BSI gefragt, wie der Stand der Dinge ist, da die CVEs gesichtet wurden
Am 16.08.2019 hat das BSI bei eQ-3 ein weiteres mal nachgehakt
Am 21.08.2019 hat eQ-3 eine kurze Entschuldigungs E-Mail geschrieben mit der Aussicht einer neuen finalen Stellungnahme
Am 26.08.2019 kam die neue Stellungnahme und ein neuer Zeitplan
Am 17.09.2019 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.2019 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.2019 den 2.47.20 Release.
Das selbe ist nun am 09.10.2019 mit dem Release 3.47.18 passiert. Die korrigierte 3.47.22 kam erst am 23.10.2019 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?
Update 03.01.2020:
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.
Und ?!?
Update 09.02.2021:
Wir haben aktuell die CCU2 Firmware 2.55.10
eQ-3 bleibt sich treu und die nun seit 2018 öffentlich bekannte Schwachstelle in der CCU2 CVE-2018-7297 ist auch 3 Jahre später weiterhin vorhanden.
Auch entgegen dieser Behauptung im Homematic Forum –> Nein diese Lücke ist nicht seit der Firmware 2.47.18 gefixt!
Der Forenbeitrag zeigt auch gleich ein weiteres mal, das die theoretische Bedrohung tatsächlich vorhanden ist. Der Benutzer wurde scheinbar von seiner eigenen CCU ausgeschlossen.
Es wäre SO EINFACH in der lighttpd proxy.conf wie auf der CCU3 den Port 80 und 443 mit einem url.access-deny abzusichern.
$HTTP["url"] =~ "^/.*\.(exe|oxml|hssml).*" {
$HTTP["remoteip"] !~ "........" {
url.access-deny = ( "" )
}
}
Na ?!?
Update 08.02.2022:
Wieder ist ein Jahr vergangen und wir haben seit Jan. 2022 die CCU2 Firmware 2.61.7
Die Schwachstelle CVE-2018-7297 in der CCU2 ist weiterhin vorhanden.
Diese Seite mag ich gar nicht mehr weiter pflegen!
Die Liste der gemeldeten Punkte
| Punkt | Tag der Meldung | Problem | CCU2/CCU3? | Resultat bei einem Angriff | Ergebnis oder Lösung am 08.08.2019 | Ergebnis oder Lösung am 17.09.2019 | Ergebnis oder Lösung am 10.12.2019 |
|---|---|---|---|---|---|---|---|
| Punkt | Tag der Meldung | Problem | CCU2/CCU3? | Resultat bei einem Angriff | Ergebnis oder Lösung am 08.08.2019 | Ergebnis oder Lösung am 17.09.2019 | Ergebnis oder Lösung am 10.12.2019 |
| 1 | 29.01.2019 | veralteter lighttpd Webserver | nur CCU2 | Denial of Service | Leider noch kein Update. Mittlerweile als CVE-2019-9582 veröffentlicht | N.A. | mit 2.49.17 gefixt |
| 2 | 29.01.2019 | veraltetes Oracle Java 8u121 | nur CCU2 | noch kein konkretes | mit Release 2.47.10 Update auf letztes freies Oracle Java 8u201. Nach dem Update ist vor dem Update, somit wieder veraltet | N.A. | N.A. |
| 3 | 29.01.2019 | stark veraltetes Embedded Linux Build Root und BusyBox | nur CCU2 | noch kein konkretes | Teil der mittlerweile als CVE-2019-9582 veröffentlichen Schwachstelle | N.A. | mit 2.49.17 gefixt |
| 4 | 13.02.2019 | Keine generelle Login SessionID Absicherung von CGI und HTML Seiten | beide | * 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. |
| 5 | 28.02.2019 | ReGaHss nicht dokumentierter interner Befehl system.Exec() | beide | Remote Code Execution | Keine befriedigende Lösung. Bei Recherchen im Nachgang sogar schon seit Feb. 2018 bekannt als CVE-2018-7297 veröffentlichte Schwachstelle | N.A. | N.A. |
| 6 | 28.02.2019 | Aufruf der /index.htm Seite erzeugt SessionID | beide | Denial of Service | Gelö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.2019 Pressewirksam ausgerollt | schon gefixt | schon gefixt |
| 7 | 28.02.2019 | Process Fuzzing auf die URI /xml-api | beide | noch kein konkretes | soll eventuell in kommenden Versionen behoben werden | N.A. | N.A. |
| 8 | 13.03.2019 | JSON API User.getUserPWD ohne gültige SessionID | beide | Passwort Hash auslesen | Wurde 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 gefixt | schon gefixt |
| 9 | 12.04.2019 | expliziter Hinweis auf schon bekannte CVEs | beide | * 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 gefixt | CVE-2019-9726 ist mit 2.47.18 & 3.47.18 gefixt | schon gefixt |
| 10 | 12.04.2019 | JSON API Interface.getMetadata / Interface.setMetadata und Interface.removeMetadata ohne gültige SessionID | beide | Meta Daten auslesen, (korrupt) verändern, löschen | Seit Release 2.47.10 und 3.47.10 gefixed. Als CVE-2019-9585 veröffentlicht | schon gefixt | schon gefixt |
| 11 | 07.05.2019 | Erzeugung einer SessionID ohne gültigen Login | beide | * 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öffentlicht | mit 2.47.18 & 3.47.18 gefixt | schon gefixt |
| 12 | 07.05.2019 | Ohne gültigen Login kann man die Systemprotokoll Einträge löschen | beide | * Escalation of Privileges | Noch ungelöst. Als Teilpunkt des CVE-2019-14475 veröffentlicht | mit 2.47.18 & 3.47.18 gefixt | schon gefixt |
| 13 | 07.05.2019 | Ohne gültigen Login kann man die Servicemeldungen lesen | beide | * Escalation of Privileges | Noch ungelöst. Als Teilpunkt des CVE-2019-14475 veröffentlicht | mit 2.47.18 & 3.47.18 gefixt | schon gefixt |
| 14 | 07.05.2019 | Ohne gültigen Login kann man User teilweise einrichten | beide | * Escalation of Privileges | Noch ungelöst. Als Teilpunkt des CVE-2019-14475 veröffentlicht | mit 2.47.18 & 3.47.18 gefixt | schon gefixt |
| 15 | 08.05.2019 | Prozess Fuzzing im ReGaHss Process für Call() ExecEnum() Methoden | beide | noch kein konkretes | zumindest im Logfile entstehen Einträge wegen fehlerhafter Aufrufe | N.A. | N.A. |
| 16 | 08.05.2019 | ReGaHss Prozess Absturz bei einem POST Request mit einem leeren Call("") | nur CCU3 | Denial of Service | Noch ungelöst. Als CVE-2019-14474 veröffentlicht | mit 2.47.18 & 3.47.18 gefixt | schon gefixt |
| 17 | 15.07.2019 | Keine Session Invalidierung/Löschung beim Abmleden im Release 2.47.10/12 und 3.47.10 | beide | mit CVE-2019-9726 die SessionID auslesen und WebUI betreten | Ich 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 wurde | mit 2.47.18 & 3.47.18 gefixt | schon gefixt |
| 18 | 01.08.2019 | Ohne gültigen Login kann man interne HM Scripte/Programme deaktivieren, manipulieren und löschen | beide | * Escalation of Privileges | Noch ungelöst. Als Teilpunkt des CVE-2019-14475 veröffentlicht | mit 2.47.18 & 3.47.18 gefixt | schon gefixt |
| 19 | 01.08.2019 | Das Rechte Konzept der CCU besitzt keine echte Mandantenfähigkeit. Ein Gast und User Account kann viele Admin Operationen durchführen | beide | mit CVE-2019-9726 die SessionID auslesen und WebUI betreten | Noch ungelöst. Als CVE-2019-14473 veröffentlicht | mit 2.47.18 & 3.47.18 gefixt | schon gefixt |
| 20 | 26.08.2019 | Neue Variante einer Remote Code Execution bei bestimmten HTTP POST Requests | beide | Remote Code Execution | ----- | Als CVE-2019-16199 veröffentlicht, gefixt mit 2.47.18 & 3.47.18 | schon gefixt |
| 21 | 12.05.2020 | Nächste Variante einer Remote Code Execution durch AutoLogin Funktion nach Ersteinrichtung, als CVE-2020-12834 veröffentlicht | beide | Remote 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.