XT2 - Firmwareupdates

[bastelheini]

(20-01-2020 18:26)peteralarm schrieb:  Eine professionelle EMA als Teil eines Bot Netzwerkes? Na, das mach mir mal vor...
Wenn eine alte Telenot, UTC, Honeywell läuft und an der Peripherie der Anlage nichts geändert wird, braucht es kein Firmwareupdate. Die Anlage läuft und ist von außen nicht angreifbar. Da gibt es keine Browserlücken, welche ein Sicherheitsrisiko darstellen, ebensowenig Risiken im Betriebssystem. Du könntest mal versuchen auf eine ATS Master Zentrale zuzugreifen, welche mit dem Internet verbunden ist, du wirst dir die Zähne daran ausbeißen
Es ist somit in keinster Weise ein Risiko für den Kunden, wenn keine Updates eingespielt werden. Das ist erst mit dem Smart Home Gedöns relevant geworden.
Ich hätte da keine Bauchschmerzen irgendwie in die Haftung genommen zu werden.

Sicher, wirklich sicher erachte ich nur eine Kiste, die alles per Kabel gebunden hat (d.h. kein Funk) und alle Schnittstellen des Kastens physisch abgeschlossen sind und es keine LAN-Anbindung o.ä. gibt. Ein autarkes System. Nur wie administrierst du das heute....

Ich weiß nicht genau, welche "alten" Anlagen du damit meinst, aber halbwegs aktuelle haben doch immer ein Browser-Interface und hängen im Netzwerk. Das hat auch nichts mit Platinen (ihr seid mE zu sehr auf der Hardwareseite, die Musik spielt in der Software, vorausgesetzt die Hardware ist ~100% safe) usw zu tun. Lücken in den verwendeten Webservern/Application-Servern (die eben die Oberfläche auf den Browsern zaubern), Lücken in der SSL-Schicht (s. https://www.cvedetails.com/product/383/O...dor_id=217 allein für das meist verwendete OpenSSL - 12 Codeexecution Lücken seit 2002 - eine reicht u.U., um reinzukommen und die Kiste zu übernehmen) und in der weiteren Software, z.B. Upload- und Entpack-Module z.B. für die FW, Anbindung an die Außenwelt (Push-Dienste, Rückanbindung der App, Update-Checker) usw usf.

Welche "zugekaufte" Software in welcher Version da benutzt wird, sagt dir keiner (oder hast du eine komplette Liste? Wohl kaum...), aber normalerweise müssten sie die je nach Ursprungs-Lizenz rausrücken. Schaut mal ins Handbuch. Im Lupusec Handbuch findet sich da auch der Verweis, sucht nach GPL und ähnlichen OS-Lizenzarten.

Viel läuft unter dem Deckmantel "Security by obscurity". Geht auch oft gut. Aber nicht immer, je nach Lücke. Und bei den komplexeren braucht das Zielgerät eine gewissen Markdurchdringung, bis da mal wer öffentlich(!) dran Hand anlegt. Schaut euch mal an, was Tenable & Co mit verbreiteten(!) IoT Geräten machen, um die Lücken aufzudecken. Die, die nicht offensichtlich sind. Aufmachen, und hart per UART-Pins dran gehen und analysieren. Hat man mit den Dingern wohl kaum bislang gemacht. Schaut doch mal in eure Anlage rein bzgl. der Pins oder es gibt gleich einen seriellen Port.

Die Anbieter haben auch Smartphone Apps, z.B. für Android. Nicht erst seit gestern. Also Web-Anbindung, inkl. GCM bzw. Firebase aktuell (wenn schon umgestellt) bzw. APNS (dauerhaft stehende Verbindung). Allein eine Anbindung zu den Push Diensten ist schon ein potentielles Leck, je nach Realisierung (Klartext?) verrät sie Details über den Zustand der Anlage (weil hier Comments kamen bzgl Alexa).

Ist die SSL-Zertfikatsprüfung unsauber (passiert häufig, nicht spez. bezogen auf diese Geräte jetzt!), hänge ich mich als MIM dazwischen und lese mit, wenn die Payload nicht irgendwie weiter dynamisch verschlüsselt ist und ich mich nicht in die Aushandlung einklinken kann. Feste Schlüssel in Anlage/App sind natürlich kompromittierbar.

Hängt noch der Server des Anbieters dazwischen, tun sich weitere Issues auf - z.B. auch mal, das Notifications an falsche Empfänger gehen können. Ohne E2E-Verschlüsselung nicht gut. Wie gesagt, alles an die Wand gemalt, ohne die jeweilige konkrete Implementierung zu kennen und zu behaupten, dass es bei denen so ist. Als Denkanstoß. Gilt potentiell für ALLE IoT Geräte. Gab ja letztens erst was kurioses eines chin. Cloud-Kamera-Herstellers in Verbindung mit einem amerik. Display-Assistenten. Ganz anderes Problem als hier beschrieben. Auswirkung gleich. Aber ich schweife ab.

Wo ziehst du die Linie zum "Smart Home". Allein die Anbindung in ein Netzwerk ist das Einfallstor. Da brauchst du kein Smarthome. Ein im Netzwerk befindlicher PC, der entsprechend infiziert ist und ab geht die Luzi. Und alles was dann zusätzlich noch per Portforwarding oder P2P ins Internet geleitet wird, ist klar schlimmer. Vermutlich meinst du das mit Smart Home. Smart Home ist aber mehr und lässt sich sehr wohl sicher realisieren.

Ich kenne keine der Anlagen direkt. Aber alle kochen nur mit Wasser. Bei den einen ist es sauberer, bei den anderen weniger. Aber es ist Wasser.

(20-01-2020 19:20)funkistnichtalles schrieb:  @bastelheini: ich spreche dir nach deinem letzten Post die Fähigkeit ab, eine aktuelle Alarmanlage und deren Aufbau eplizit zu kennen. Du hast keine Ahnung vom Zusammenspiel von Hauptplatinen und Übertragungsgeräten.

Ich rede auch nie von Platinen. Ich rede von der Software. Du weißt also was drin steckt, an Software? Dann erzähl mal...

(20-01-2020 19:20)funkistnichtalles schrieb:  Mag sein, dass du Netzwerkplatinen analysieren kannst,

Nein, kann ich nicht und habe ich auch nie behauptet.

(20-01-2020 19:20)funkistnichtalles schrieb:  vielleicht kannst du sie auch in (d)ein Botnetzwerk übernehmen. Nur: was bringt dir das? Was bringt das Gewafe mit Firmwareupdates und geschlossene Lücken? Was erreichst du damit, wenn dein Tool weiss was hintendran sein will. Deswegen kommst du noch lange nicht drauf, geschweige weisst du was du auslösen musst, um für diese Sache einen Schaden von Leib und Leben zu generieren. So sehe ich es wie peteralarm, da lehne ich mich mal dezent zurück.

Ich denke, du hast das was nicht vollständig verstanden. Einem Botnetz-Betreiber geht es idR nicht darum, die deine EMA zu bedienen oder abzuschalten. Der hat andere Beweggründe. Ein Netzwerk aus vielen Rechnern (was anderes ist die EMA nämlich am Ende nicht) um dann eben mehr oder minder kriminelle Dinge zu tun, z.B. DDOS-Attacken auf irgendwelche Server irgendeiner Firma, Proxy für IP-Verschleierungen usw. Die Folgen davon sind für den Betreiber des Gerätes unmittelbar folgende im Falle des Falles: Der Angriff ins Internet (und den Zugriff haben sie ja, sonst könnten sie keine Push Nachrichten senden oder E-Mails) geht von der IP-Adresse des Besitzers aus. Bei wem wird wohl die Polizei aufkreuzen, wenn über den Internet Zugang DDOS-Attacken rausgehen oder anderere Inhalte per Proxy (ich will da jetzt keine bösen Wörter in den Mund nehmen) durchgeleitet werden, um die wahre IP der Verursacher zu verschleiern...

Sucht mal nach "Thingbot", der Begriff tauchte so das erste mal vor über 5 Jahren auf als Begriff, damals wurden neben üblichen Appliances wie Router und Co auch die ersten Kühlschränke und Waschmaschinen mit Internetzugang zu diesen Zwecken gekapert. Automatisiert.

Das Problem für den EMA Betreiber für die Alarmsicherung wird sein, dass die Kisten (idR ist da irgendein ARM-Basierter Prozessor verbaut, schmale Leistung) unter recht hoher Last läuft. Und so ggf. die Alarmsignale nicht korrekt zeitnah verarbeiten kann.

Jetzt könnte euer Einwand mit den mehreren Platinen kommen, die die Dinger haben mögen und die unterschiedliche Aufgaben haben. Ja das könnte sein, dass das hilft. Wenn das Board für Webzugang usw für interner Schnittstellen auf ein getrenntes Board für den Rest zugreift, dann mögt ihr Recht haben.

Der Rest ist aber eben nicht vom Tisch - vorausgesetzt, die FW Updates patchen ensprechende Lücken in verwundbaren Modulen. Da es scheinbar keine öffentlichen Changelogs gibt, ist dazu auch schwer was zu sagen.

(20-01-2020 19:20)funkistnichtalles schrieb:  Trotzdem: ich bin die nächsten 2 Tage auf ner Fachtagung und da stelle ich diesen Beitrag mal zur Diskussion. Mal schauen, was die Fachingenieure dazu sagen.

Gerne, solange das keine Sales Leute sind sondern wirklich auch die Software-Leute der Unternehmen. Ich bin auch gespannt, ernst gemeint.

(20-01-2020 19:20)funkistnichtalles schrieb:  Bis jetzt gab es hier im Forum KEINEN Beitrag von einer übernommenen Anlage.
Wenn doch, würde er hier zitiert werden.
Somit stelle ich deinen Beitrag als Getöse ab.

Nutzer merken sowas u.U. auch nicht. Und sonst wird das auch nie jemand öffentlich zugeben (Hersteller bezogen, nachvollziehbar).

So wie es ja aktuell die NFC-Bankkarten sicher sind und niemand unbemerkt einfach Geld abzwacken kann... jaja... hüstel... Den Quatsch haben ja nun selbst schon die ÖR widerlegt. Die Banken mauern weiter und erzählen Märchen.

---

(20-01-2020 20:50)mucki schrieb:  Ok, das man seine Alarmanlage nicht mit Alexa schaltet ist für mich selbstredend.

Im vorherigen Post hast du von einer "Tatsache" geschrieben, dass die Gewohnheiten nachverfolgt werden können. Im nächsten Post stellt sich dann heraus, dass du mal was gelesen hast, dass Amazon angeblich das Mikrofon ferngesteuert aktiviert hat leitest daraus ab, dass ein findiger Hacker Schaltvorgänge herausfinden kann.

Also von Tatsache hin zu einer möglichen Legende...
Hatte schon Angst ich hätte eine Neuigkeit diesbezüglich verpasst :-)

Verzeih es mir, @peteralarm, wenn ich hier mal antworte

Wenn du deine Anlage mit Alexa verknüpfst, ist das so, dass du deine Anlage dauerhaft gegenüber einem Server(-verband) und damit dem Internet öffentlich machst. D.h. über dauerhaft gültiges Token kann der Dienst auf deine Anlage zugreifen und per API Befehle eben Dinge auslesen und umstellen. Was genau, obliegt der Implementierung auf der API Seite, als konkret hier jetzt, ob abfragbar ist, ob deine Anlage scharf/unscharf ist. Ich glaube, Lupusec hat das getrennt.

Aber auch über andere Dinge sind Anwesenheiten auslesbar. Lange kein Fenster offen? Steckdosen alle aus? Heizung runtergedreht usw... Ich kann das ja jede Minute auslesen und daraus ein Profil erstellen.

Sicherheits-Problem-Vektoren:
1. Über Serverfehler (Bugs, Softwarelücken usw) könnte es passieren, dass irgendein anderer Kunde auf deine Anlage zugreift. Ähnliches gab es letztens bei einem bekannten chin. Kamera-Hersteller in Verbindung mit dem anderem Assistenten und einem Gerät mit Display. Man sah dann Bilder von anderen Kunden statt seinen...

2. Jemand, der in deinen Am**** Account reinkommt, kann darüber auf deine Anlage zugreifen. U.u. auch die Mitarbeiter des Am**** Supports.

3. Jemand könnte sich dazwischen hängen (MIM) und die Anlage steuern. Bei Vorhandensein von etwaigen Sicherheitslücken in der Implementierung aller Art kann entsprechend mehr passieren bis hin zur Übernahme der Kiste.

4. Der Skill selbst ist auch nur programmiert, auch dort können Lücken drin sein. Ggf. auch temporäres/vergessenes Logging mit der Gefahr eines Leaks. Öffentlich rumliegende Files auf öffentlichen S3 Buckets sind ja täglich Brot heute ^^

Daher empfehle ich stets: Die Kisten gehören nicht ins Netz. Direkt aussperren, nur die Ports erlauben, die erwünscht sind wie z.B. 465 zum Mailversand. Kein Portforwarding. Zugriff per VPN. Und im Ideallfall zu Hause die Kiste in einem VLan betreiben.