Hallo,
vor ein paar Tagen hat die US-Amerikanische CISA (Staatliche Cyber Defense Agency) eine öffentliche Sicherheitswarnung (Security Advisory) zur Vitogate 300 veröffentlicht. Die Schwere der Auswirkungen einer Sicherheitslücke wird mit einer standardisierten Kennzahl (CVSS-Score) von 0 bis 10 angegeben. Wobei 0 "kein Risiko" entspricht und 10 einem IT-Security Super-GAU (quasi eine nukleare Kernschmelze). Je nach Berechnungsverfahren ist für diese Lücke der CVSS-Score 9,3 bzw. 9,8 (salopp: hier also quasi nur knapp an einer nuklearen Kernschmelze entlanggeschraddelt).
Hier der Link: https://www.cisa.gov/news-events/ics-advisories/icsa-24-254-01
Üblich ist, dass die Hersteller zuerst informiert werden, damit sie die Möglichkeit eines Bugfixes haben um die Lücken zu schließen bevor jedes Script-Kiddy sie dann auch ausnutzen will, und erst wenn der Bugfix zu den Kunden "ausgerollt" wurde, wird es dann veröffentlicht. So auch hier, mit der Software 3.x wurden die Lücken geschlossen.
Worum es mir aber eigentlich geht: Wenn ich mir die im Report genannten Lücken durchlese steht da u.a.
Ein Programmierer hat also ein Passwort oder einen Schlüssel fest in den Programmcode eingebaut und jeder der das kennt, kann darüber bei allen Geräten mit der betreffenden Softwareversion zugreifen.
Seit 1988 (als durch einen solchen Fehler bei Internet-Routern das damalige Internet praktisch lahmgelegt wurde, ja ich bin etwas älter und kann mich noch gut daran erinnern, es war ein prägendes Erlebnis) weiß man, dass fest einkodierte Passwörter/Zugangsdaten eine ganz, ganz schlechte Idee sind und spätestens seit 30 Jahren weiß man auch in DE, dass das nicht mehr Stand der Technik ist.
Nun zeigt mir meine langjährige Berufserfahrung in vielen Firmen, bei denen IT/OT-Sicherheit nicht zum traditionellen Kerngeschäft gehört (dazu zähle ich jetzt mal Heizungshersteller wie Viessmann, auch wenn ich keine internen Einblicke bei Viessmann habe), dass dort Programmierer von IT/OT-Sicherheit maximal nur Halbwissen haben und nie nur bei einer Komponente schlampen (oder keine Ahnung haben), sondern bei allen Projekten an denen sie beteiligt sind. Und wenn es in einer Firma keinen internen IT-Security-Review gibt (bei dem solche Dinge auffallen müssten), dieses auch immer die gesamte Softwarepalette betrifft.
Ich finde dazu leider keine Infos bei Viessmann (oder hier im Forum). Wie ist das bei Viessmann geregelt? Wo finde ich eine verbindliche Info der Sicherheitslücken und der Firmwareversionen, mit denen diese gefixt wurden?
Die Frage, ob es unentdeckte Sicherheitslücken gibt, ist ja Grund falsch. Weil es sie immer gibt. Die wesentlich wichtigere Frage ist: Wie wird Transparenz hergestellt? Oder wird sowas aus Arroganz oder Eitelkeit verschwiegen? Auf welche Art und Weise werden die davon betroffenen Kunden informiert und die Software gefixt?
Viessmann möchte ja anscheinend alle Kunden in die Viessmann-Cloud "zwingen" (weil lokale Steuerungsmöglichkeiten anscheinend vernagelt wurden/werden).
Ich habe eine im Mai 2024 neu installierte Vitocal 250-A, die bisher nicht in der Viessmann-Cloud hängt. Weil mir bisher niemand erklären konnte, welche technischen Sicherheitsmaßnahmen und welches Change-Management es in der Viessmann-Cloud gibt, so dass z.B. eine Heizungsfirma (der ich den Zugriff möglicherweise erlauben würde) zwar alles ansehen kann, aber ohne meine Zustimmung nichts ändern kann. Oder, dass es z.B. ein für mich einsehbares, lückenloses Protokoll "Wer hat über die Cloud bei meiner Anlage wann welche Änderung gemacht" gibt.
Gibt es dazu eine "echte" Dokumentation der TOMs (technische und organisatorische Maßnahmen) der Sicherheit der Viessmann-Cloud? Außer "vertrauen sie uns, wir können das" habe ich bisher nichts gefunden/gehört.
Und gibt es irgendwo eine für mich einsehbare Stelle, in der im Rahmen des Change-Management die veröffentlichten Firmware-Versionen mit den darin enthaltenen Änderungen und Bug-Fixes konkret aufgeführt sind?
Bisher habe ich dazu nichts gefunden. Hat jemand vielleicht dazu konkrete Infos?
Danke (auch für die Geduld, bis hierhin gelesen zu haben)
Hallo,
>>die bisher nicht in der Viessmann-Cloud hängt.
hoffentlich hat du zusätzlich den UMTS Servicelink irgendwie still gelegt 🙂
VM ist was Software angeht extrem intransparent, es gibt keinerlei Releasenotes oder sonst etwas.
Genau zum Zeitpunkt von log4j war die ganze Vicare Backend-Infrastruktur für mehrere Tage offline.
Hier im Forum hat ein VM MA gepostet, das sei zeitlich nur ein Zufall und VM ist von log4j nicht betroffen.
Was sollt man sagen...Transparenz ist etwas anderes.
Vielleicht ändert sich das mit Carrier jetzt.
VG
>>>die bisher nicht in der Viessmann-Cloud hängt.
>hoffentlich hat du zusätzlich den UMTS Servicelink irgendwie still gelegt
Ich habe WLAN, Access Point und "Low Power Funk" im Menü ausgeschaltet. Gibt es noch etwas anderes?
> VM ist was Software angeht extrem intransparent, es gibt keinerlei Releasenotes oder sonst etwas.
Warum? Vor 20-30 Jahren war solch eine Geheimniskrämerei ja quasi üblich. Aber heutzutage ist das doch längst nicht mehr zeitgemäß (und ein inhärentes Sicherheitsproblem)
> Was sollt man sagen...Transparenz ist etwas anderes.
> Vielleicht ändert sich das mit Carrier jetzt.
Vielleicht. Mehr Transparenz wäre notwendig und wichtig. Aber Carrier scheint sich ja eher nur um den Internationalen bzw. US-Markt zu kümmern.
> Ja ein LTE Modul ist auch eingebaut.
Ich finde dazu leider nichts konkretes, außer dass über Service-Link 5 Jahre lang Daten an Viessmann gesandt werden. Und in einem Prospekt auf einer Drittwebsite steht: "Kommunikationsfähig über (...) und Service Link (Low-Power-Funk)."
Demnach wäre Service-Link = LTE Kommunikation = "Low Power Funk" (der bei mir abgeschaltet ist).
nein LTE ungleich Low Power Funk!
Ich habe geschaut ob man das per CAN abschalten kann,. Anscheinend nicht..
Dann hilft nur Alufolie um die Antenne zu machen 🙂
Interessanterweise gibt es dort einen DP für die MobilFunkt cell Information.
Wenn die WP gestohlen wurde, kann sie VM an Hand der Mobilfunkzellen relativ genau lokalisieren,
2375 : RawCodec(7, "NarrowBandInternetOfThingsConfiguration"),#+++
2376 : RawCodec(132, "NarrowBandInternetOfThingsRadio"),#+++
2377 : RawCodec(45, "EvolvedUniversalTerrestrialRadioAccessDataLinkInfo"),#+++
2378 : RawCodec(48, "EvolvedUniversalTerrestrialRadioAccessNeighborCells"),#+++
2379 : RawCodec(22, "EvolvedUniversalTerrestrialRadioAccessServingCellInfo"),#+++
2380 : RawCodec(17, "EvolvedUniversalTerrestrialRadioAccessServingCellMeasurements"),#+++
VG