[English]Der im Januar 2021 bekannt gewordene Hack des US-Herstellers Ubiquiti Networks (IoT-Geräte, Kameras etc.) war wohl gravierender als vom Unternehmen zugegeben. Die Angreifer sollen Zugriff auf Quellcodes und Credentials gehabt haben. Ergänzung: Stellungnahme des Herstellers ergänzt.
Anzeige
Wer ist Ubiquiti?
Ubiquiti Networks ist ein amerikanischer Hersteller, der seit der Gründung im Jahr 2005 aktive Netzwerkkomponenten wie WLAN-Adapter für PCs vertreibt. Inzwischen wurde die Produktpalette um WLAN-Router, Access Points, WLAN-Antennen und Richtfunkantennen, insbesondere für den Außenbereich, erweitert. Seit dem Jahr 2014 hat der Hersteller auch VoIP-Telefone sowie Switche und Netzwerkkameras für den professionellen und semiprofessionellen Einsatz im Angebot. Die WLAN-Router von Ubiquiti basieren auf WLAN-Chips von Atheros und verwenden ein linuxbasiertes Betriebssystem („airOS"). Die nanoStation-Router sind im Freifunk-Bereich sehr populär, da sie die Nutzung einer eigenen Firmware gestatten. Ubiquiti-Produkte finden sich bei Amazon.de, Conrad und vielen anderen Elektronikhändlern im Angebot. Zudem hat Ubiquiti einen eigenen Shop, der auch EU-Kunden beliefert.
Der Ubiquiti-Hack
Im Januar 2021 wurde Ubiquit Opfer eines Cyber-Angriffs, bei dem ein Wochenende deren Cloud-Angebot kurzzeitig gestört war. Dumm: Der Hersteller forciert/erzwingt scheinbar ein Cloud-Konto zur Verwaltung lokaler Geräte-Konten (lässt sich aber umgehen, wie auch in folgenden Kommentaren aufgeführt). Kunden des Unternehmens erhielten dann eine E-Mail, in denen sie über den Vorfall informiert wurden. Sie wurden aufgefordert, vorsorglich ihre Kennwörter für die Zugänge zu ändern, da nicht ausgeschlossen werden könne, dass die Angreifer Zugriff auf persönliche Anmeldedaten hatten.
Ich hatte im Blog-Beitrag Hersteller Ubiquiti gehackt, Nutzer sollten Passwörter ändern über diesen Vorfall berichtet, der zwar unschön ist, aber sich doch irgendwie harmlos anhörte. Seinerzeit schrieb ich:
Anzeige
falls jemand also Router, Kameras, Türklingeln, Switches oder ähnliche Produkte dieses Herstellers im Einsatz hat, sollte er die Kennwörter (des Cloud-Kontos und ggf. der lokalen Geräte) vorsorglich ändern. Des weiteren empfehle ich darüber nachzudenken, ob ein US-Hersteller, der die Kennwortverwaltung für lokale Zugänge per eigenem Cloud-Angebot (quasi) aufdrängt, der richtige Partner sein kann.
Einziger Grund für den Einsatz bestimmter Produkte (Funkantennen) dieses Anbieters kann höchstens die Eingangs erwähnte die Möglichkeit sein, dort ein eigenes (nanoStation-Router-)Betriebssystem auf die Hardware zu flashen.
Whistleblower verrät das Desaster
Die Tage bin ich bei Brian Krebs auf den Artikel Whistleblower: Ubiquiti Breach "Catastrophic"gestoßen – und von den Vectra AI Cybersecurity-Experten habe ich diese Informationen ebenfalls erhalten. Ein Sicherheitsexperte bei Ubiquiti, von Krebs einfach Adam genannt, hat nun als Whistleblower Details an Krebs weitergegeben und spricht davon, dass das Unternehmensmanagement tatsächlich einen „katastrophalen" Vorfall heruntergespielt haben, um ihre Aktienkurse zu schützen.
Laut Whistleblower Adam "war der Verstoß massiv, Kundendaten waren gefährdet, der Zugriff auf Kundengeräte, die in Unternehmen und Privathaushalten auf der ganzen Welt eingesetzt wurden, war gefährdet." Der Insider berichtet auch, dass die Hacker vollen Lese- / Schreibzugriff auf Ubiquiti-Datenbanken bei AWS erhielten.
"Sie waren in der Lage, kryptografische Geheimnisse für Single-Sign-On-Cookies und Remote-Zugriff, vollständige Quellcode-Kontrollinhalte und die Exfiltration von Signierschlüsseln zu erhalten", so Adam. Der Quelle zufolge hatten der oder die Angreifer Zugriff auf privilegierte Anmeldeinformationen, die zuvor im LastPass-Konto eines Ubiquiti IT-Mitarbeiters gespeichert waren. So erlangten sie Root-Administrator-Zugriff auf alle AWS-Konten von Ubiquiti, einschließlich aller S3-Daten-Buckets, aller Anwendungsprotokolle, aller Datenbanken, aller Benutzerdatenbank-Anmeldeinformationen und der Geheimnisse, die zum Fälschen von Single Sign-On (SSO)-Cookies erforderlich sind.
Ein solcher Zugriff hätte es den Eindringlingen, laut den Ausführungen auf Krebs on Security, ermöglichen können, sich aus der Ferne an unzähligen Ubiquiti-Cloud-basierten Geräten auf der ganzen Welt zu authentifizieren. Laut seiner Website hat Ubiquiti mehr als 85 Millionen Geräte ausgeliefert, die eine Schlüsselrolle in der Netzwerkinfrastruktur in über 200 Ländern und Territorien weltweit spielen.
Einbruch vom Sicherheitsteam entdeckt
Aufgefallen ist das wohl nur, weil das Sicherheitsteam von Ubiquiti Ende Dezember 2020 Signale auffing, dass jemand mit administrativem Zugriff mehrere virtuelle Linux-Maschinen eingerichtet hatte, die nicht angemeldet waren. Dann fanden sie eine Hintertür, die ein Eindringling im System hinterlassen hatte. Als die Sicherheitstechniker das Konto mit der Hintertür in der ersten Januarwoche entfernten, schickten die Angreifer eine Nachricht. Darin forderten die Angreifer 50 Bitcoin (ca. 2,8 Millionen US-Dollar) als Gegenleistung für das Versprechen forderten, über den Einbruch zu schweigen. Die Angreifer lieferten auch Beweise dafür, dass sie den Quellcode von Ubiquiti gestohlen hatten, und versprachen, den Standort einer weiteren Hintertür preiszugeben, falls ihre Lösegeldforderung erfüllt würde.
Zwei Hintertüren entdeckt
Ubiquiti ließ sich nicht auf die Hacker ein, so Adam, und schließlich fand das Incident Response Team die zweite Backdoor, die die Erpresser im System hinterlassen hatten. Das Unternehmen verbrachte die nächsten Tage damit, die Zugangsdaten aller Mitarbeiter zu erneuern, bevor Ubiquiti damit begann, die Kunden darüber zu informieren, dass sie ihre Passwörter zurücksetzen müssen. Hier hätte Ubiquiti sofort alle Kundenkonten zurücksetzen müssen, weil die Eindringliche ja bereits über Anmeldedaten für den Fernzugriff auf die IoT-Systeme der Kunden verfügten. Andreas Müller, Director DACH beim IT-Sicherheitsanbieter Vectra AI kommentiert die neuen Informationen:
Der Whistleblower der Ubiquiti-Datenschutzverletzung liefert eine präzise Beschreibung des Ausmaßes und der Wucht des Angriffs. Laut dem Whistleblower hat der Angreifer „mehrere virtuelle Linux-Maschinen" eingerichtet. Dies ist eine sehr ungewöhnliche Angriffsmethode, aber eine sehr einfache Möglichkeit, innerhalb einer Organisation Fuß zu fassen. Die Folgen dieses Angriffs ähneln denen des „Sunburst" -Angriffs [Orion-Software]. Sobald der Täter Zugriff auf die Infrastruktur und die Netzwerkverwaltungskonsole hat, kann er tun, was er will.
Laut Müller versuchen Angreifer zunehmend, auf Cloud-Dienste von Anbietern zuzugreifen, um Zugang zu einer großen Anzahl von Unternehmen zu erhalten. Müller erwartet einen starken Anstieg dieser Arten von Angriffen, da viele Unternehmen dabei sind oder auf AWS / Azure / GCP-Clouds umsteigen oder umgestiegen sind. Dieser Angriff unterstreicht laut Müller das allgemeine Risiko der Verwendung von SaaS-Angeboten und die Bedeutung von Zertifizierungen wie der SOC2-Typ2-Konformität.
Die Verantwortung für die Cloud-Absicherung
Müller schreibt: AWS sei sich sehr klar über das von ihnen bereitgestellte Modell der geteilten Verantwortung. AWS sei aber nicht dafür verantwortlich, den Zugang zu ihrem Dienst zu sichern, Ubiquiti ist hier in der Pflicht. Der Mangel an Verantwortung von Ubiquiti und die bisherige Antwort stellen, laut Müller, vermutlich das Vertrauen in Frage, das Kunden in ihren Service setzen werden.
So hat Ubiquiti noch das Problem, dass keine Zugriffsprotokolle für die Daten vorhanden sind. Es lässt sich also nicht herausfinden, ob Zugriffe auf die Kundendaten erfolgten. Weitere Details zum Ubiquiti-Fall lassen sich bei Brian Krebs nachlesen.
Ubiquiti bestätigt Angriffsversuch
Ergänzung: Inzwischen hat Ubiquiti, wohl auf Grund dieser Berichterstattung für die wahren Folgen des Ausmaßes die nachfolgende Stellungnahme herausgegeben (Bleeping Computer hat das hier aufgegriffen).
Update to January 2021 Account Notification
As we informed you on January 11, we were the victim of a cybersecurity incident that involved unauthorized access to our IT systems. Given the reporting by Brian Krebs, there is newfound interest and attention in this matter, and we would like to provide our community with more information.
At the outset, please note that nothing has changed with respect to our analysis of customer data and the security of our products since our notification on January 11. In response to this incident, we leveraged external incident response experts to conduct a thorough investigation to ensure the attacker was locked out of our systems.
These experts identified no evidence that customer information was accessed, or even targeted. The attacker, who unsuccessfully attempted to extort the company by threatening to release stolen source code and specific IT credentials, never claimed to have accessed any customer information. This, along with other evidence, is why we believe that customer data was not the target of, or otherwise accessed in connection with, the incident.
At this point, we have well-developed evidence that the perpetrator is an individual with intricate knowledge of our cloud infrastructure. As we are cooperating with law enforcement in an ongoing investigation, we cannot comment further.
All this said, as a precaution, we still encourage you to change your password if you have not already done so, including on any website where you use the same user ID or password. We also encourage you to enable two-factor authentication on your Ubiquiti accounts if you have not already done so.
Thanks,
Team UI
Der Kernsatz, dass sich nichts gegenüber der ursprünglichen Bekanntgabe des Hacks für die Kunden geändert habe. Und man habe keine Beweise gefunden, dass auf Kundeninformationen zugegriffen worden sei. Hier sollte man sich den Satz So hat Ubiquiti noch das Problem, dass keine Zugriffsprotokolle für die Daten vorhanden sind. aus dem obigen Text zu Gemüte führen. In der Stellungnahme hat Ubiquiti zwar nicht gelogen, als sie schrieben "man habe keine Beweise, dass auf Kundendaten zugegriffen worden sei". Aber sie haben auch keine Beweise, dass es keine Zugriffe gab – oder deutlicher: Sie wissen es nicht. Unter diesem Aspekt ist die obige Stellungnahme imho eine Nebelkerze und jeder Kunde sollte sich die Frage nach dem Vertrauen in diesen Hersteller stellen.
Anzeige
Wer Produkte, insbesonders Netzwerkprodukte einsetzt, bei welchen ein Cloud-Zwang besteht ist selber Schuld.
Leider werden diese Produkte auch von vielen IT-Dienstleistern verkauft, was imho doppelt schlimm ist.
Meine Empfehlung: sofort alle Ubiquiti-Produkte entfernen!
"Wer Produkte, insbesonders Netzwerkprodukte einsetzt, bei welchen ein Cloud-Zwang besteht ist selber Schuld."
Diese Meinung teile ich uneingeschränkt mit Dir. Zumal es nicht nur "böse chinesische Konzerne" sein müssen, sondern auch die "doitsche Qualitätsoffensive" (ABUS, BOSCH, SIEMENS) sich mit lächerlichen und stümperhaften Fehlern (eingebettete root-Zugänge, unveränderte Paßwörter alá 0000 oder toor (mirror zu root).
Cloud-Bananenware hat nichts in Netzwerken verloren. Entweder kann man selber einen Server hosten, in den eigenen vier Wänden, oder man läßt es besser bleiben. Bei Privatkunden noch nachvollziehbar, wenn sie die Tragweite nicht begreifen, die sie mit einer externen Cloud eingehen.
Aber sobald es gewerblich / kommerziell wird, gibt es dafür keine Entschuldigung. Und bei Datenschutzverstößen muß die DSGVO mit maximaler Härte gegen solche Unternehmen vorgehen, völlig gleich, ob diese im Anschluß bankrott gehen – ihre Kundendaten bedeuteten ihnen schließlich ja auch nichts, weshalb sollten die Kunden also Mitgefühl für solche Unternehmen haben.
Auf diese Art kannst Du z.B. sämtlich Arztpraxen schließen. Denn die hängen mittlerweile alle in verschiedenen Clouds :-). Alle Schulen, weil sie unabhängig vom angebotenen Fernunterrichtstool allesamt per Windows im Netz hängen. Usw…
Da fürchte ich, muss man bestimmte Dinge ganz oben hinhängen, weltweit, also nie.
Prinzipielle Zustimmung, aber Deine Meinung basiert auf falschen Tatsachenbehauptungen.
Leider ist das, was Herr Born hier schreibt, (erneut) nicht wahr. Bereits im ursprünglichen Artikel zum Vorfall hatte ich darauf hingewiesen, dass man Ubiquiti network controller lokal hosten kann. Es gibt dafür sogar eine eigene Hardware, den "cloud key" (bescheuert benannt, weil es gerade eben die cloud umgeht). Alternativ kann man sich die Software für diverse Betriebssysteme herunterladen, man kann so einen controller sogar auf QNAP NAS-Geräten installieren.
Und ja, auch ein "cloud controller" auf Ubiquiti-Servern ist möglich und das Unternehmen hat immer mal wieder die unerfreuliche Tendenz, Benutzer dorthin drücken zu wollen.
Dass es einen Cloud-Zwang gäbe, ist aber schlicht und einfach die Unwahrheit!
Je meinungsstärker man sich äußert, sei es nun im Blog oder im Kommentarbereich, desto sicherer sollte man sein, dass die eigene Meinung sich auch aus Tatsachen herleitet.
Stimmt seit Version 6 nur noch beschränkt, da ist ein Cloud-Account Pflicht (nicht bei Upgrade, aber bei Neuinstallation). Man kann zwar danach einen lokalen Admin anlegen und den nutzen, aber der Cloud-Account bleibt und bestimmte Dinge gehen nur mit dem. (ja, ich rede vom Cloud Key)
Ok, wenn das mit dem Cloud Key mittlerweile so ist, eine sehr ärgerliche Entwicklung. Für Kundenumgebungen nutze ich in aller Regel den "Software-Controller", alleine in diesem Jahr hatte ich diesbezüglich drei neue Installationen. Nirgendwo wurde ein Cloud-Konto benötigt, auch nicht temporär. Und natürlich laufen alle Installationen auf einem Version6-Controller.
Kannst Du eine alternative Produktempfehlung geben?
Da musst Du bitte genau spezifizieren, für welchen Einsatz das Gerät gedacht ist, was es können muss, usw.
Ziemlich genau das, was das o.a. Produktportfolio bietet, zentrales Management, rocksolid WLAN einschl. gebäudeübergreifende Funkverbindungen, stabiles PoE für möglichst alle Komponenten einschl. Telefonie.
Seit dem Bekanntwerden des Hacks gab es mehrere Updates für alle Komponenten, Kennwortwechsel sowieso. Das ist nach einigen durchwachsenen Erfahrungen das erste Produkt bei mir, das seit der Einrichtung vor einigen Jahren "just works".
Als rein deutsches Angebot für den SMB und Privatbereich fällt mir noch AVM ein. Deren WLAN hatte hier aber nicht stabil funktioniert – leider.
Da wäre noch Lancom zu nennen!
Nicht ganz billig, aber sehr ordentliche Leistung mit hervorragendem Support!
Benutzen wir schon ewig (damals noch als ELSA ;]), kann ich nur empfehlen…
>>"Der Hersteller erzwingt ein Cloud-Konto zur Verwaltung lokaler Geräte-Konten"
Ohne, dass ich Ubiquiti hier in Schutz nehmen möchte, aber diese Aussage ist leider nicht gänzlich korrekt / präzise:
Ubiquiti vertreibt mehrere Produktlinien (EdgeRouter, EdgeSwitch, AirFiber, UniFi, etc.) von denen afaik nur die UniFi-Produkte "Cloud-Produkte" sind und selbst davon einige (z.B. APs & Switches) auch problemlos offline, vollkommen ohne Cloud genutzt werden können.
Ich selbst nutze mehrere UniFi WLAN-APs mit der Controller-Software auf einem Debian (läuft auch auf einem Raspberry Pi…), gänzlich ohne Cloud.
Selbst der Controller dient im Wesentlichen nur Management-Zwecken und die Geräte können teils auch "Standalone" betrieben werden.
Das Preis- / Leistungsverhältnis der Lösung mit einem zentralen Management ist IMHO recht gut.
Dass die Angreifer nun offenbar doch Zugriff auf Quellcodes hatten ist natürlich ein Problem, andererseits hat das auch schon andere, namenhaftere Hersteller viel schlimmer getroffen (siehe z.B. https://heise.de/-3051260).
Das kann ich so unterschreiben. Es geht auch ohne Cloud.
So, wie bei anderen Anbietern, die behaupten man könne die Webcams ohne "Kundenkonto" konfigurieren?
Ich gebe mal ein Beispiel zum besten: Mittels auf dem Smartphone heruntergeladener App übermittelt man das Paßwort seines W-LANS an den Anbieter, dann darf man gnädiger weise über Umwege sein Gerät konfigurieren und im Anschluß auf die (kostenpflichtige) Cloud verzichten.
Eine Änderung des W-LAN Paßwortes im Anschluß macht die Peripherie wieder unbenutzbar.
So einen Mist braucht niemand… wirklich nicht.
@Dat Bundesferkel: das ist allerdings ein schlechtes Beispiel und Hr. Born hatte leider die Meldungen in seinem letzten Blogartikel wohl nicht gelesen, wo bereits darauf hingewiesen wurde, dass die Produkte keinen Cloudzwang haben. Die Controller Software dient dem zentralen Management was ja die Philosophie hinter Ubiquiti ist, wenn man die nicht selbst hosten möchte, dafür gibt es die Cloud Lösung, ganz einfach. Wenn du Cisco APs kaufst gibt es standalone Dinger, aber das macht das ganze schnell mühsam so einen Fuhrpark zu überwachen…da stellst dann auch bald auf einen zentralen Controller um.
Super, man hat die Auswahl zwischen Pest (Cloud) und Cholera (Controller – Java-Schrott), aber Hauptsache nicht mühsam, naja wer den Aufwand für Security und Datenschutz nicht betreiben will solls bleiben lassen.
Doch, die unifi-Produkte haben bei einer Neuinstallation seit Version 6 einen Cloudzwang.
@Anonymous
"…andererseits hat das auch schon andere, namenhaftere Hersteller viel schlimmer getroffen".
Super Aussage und Rechtfertigung (um nicht dämlich zu sagen), Volkswagen Dieselskandal lässt grüssen :-).
Es geht nicht darum, dass es andere nicht getroffen hat, sondern darum wie danach mit solchen Dingen umgegangen wird, und da scheint bei Ubiquiti das "Abwiegeln" und Verschleiern im Vordergrund zu stehen, was wiederum zeigt wie Ubiquiti "tickt".
Wegen "erzwingen" habt ihr (Du und Sebastian) Recht. Ist beim C&P vom alten Artikel mit reingerutscht – und ich habe es drei Mal überlesen. Ist jetzt aber im Text angemerkt – danke für diesen Hinweis! Ist als Eindruck entstanden, weil ich in Foren las: Bin beim Einrichten zur Anmeldung geführt worden und hatte keine andere Möglichkeit.
PS: Was mich aber immer sehr nachdenklich zurück lässt (nicht nur hier): Du beschreibst einen sicherheitstechnischen Sachverhalt, der einige Folgen hat. Und dann stellst Du fest, die Diskussion beißt sich an einem Begriff oder Nebensatz fest. Wenn etwas falsch dargestellt wird, ist die Anmerkung ok und ich korrigiere. Aber mir fehlt dann oft der Blick fürs Ganze in der Diskussion. Lässt mich ratlos zurück.
Bitte nicht falsch verstehen, mir ging es nicht unbedingt darum auf einem Nebensatz rumzureiten sondern den Impact des Hacks korrekt zu beschreiben, auch mit dem Fokus, was das wirklich für den Kunden / Nutzer bedeutet…
Zum einen gibt es die UniFi-Produktline mit Cloud & Co. wo die Angreifer potenziell Zugriff auf zig Kundennetze gehabt haben könnten sofern die UniFi-Cloud genutzt wurde, das ist ein absoluter GAU (und das Grundproblem aller Cloud-Lösungen – wie sehr vertraue ich dem Anbieter…?).
Zum Anderen gibt es aber auch andere Produktlinien bei deren Einsatz es gar keinen Impact gibt sofern man nicht unbedingt die neuste, potenziell von den Angreifern manipulierte Firmware, einsetzt.
Ich habe leider selbst beruflich zu oft mit Situationen zu tun wo ich Kunden erklären muss, dass Problem X oder Lücke Y sie nicht betrifft obwohl sie ein entsprechendes Produkt nutzen und es dazu einen "Security-Alert" bei Heise & Co. gibt. Das sind oftmals sehr mühsame Diskussionen…
Unifi ist modern, preisgünstig und funktioniert top.
Ungewöhnlich bei den Unifi-Geräten ist, dass sie nicht direkt im Browser konfiguriert werden, sondern nur per SSH bzw. Controller.
Der funktioniert aber super und vereint WLAN-Hotspot, SDN, uvam in einer intuitiven, zentralen Oberfläche.
Den kostenlosen Controller kann man auf Windiws, Linux oder MacOS betreiben.
Außerdem gibt es ihn als App u.a. für Synology.
Als Hardwarelösung gibt es den Controller in der Dream Machine (Pro) und im Cloud Key.
Bei den Hardwarecontrollern kommt wirklich als Erstes die Frage nach dem Cloud Konto, es ist zumindest sehr versteckt wenn man das nicht will.
Ich sage mal Windows Installation läßt grüßen.
Aber noch im Installationsvorgang setzt man den Haken, ob man den Cloudzugriff will oder nicht. Und danach geht alles mit lokaler Anmeldung.
Ganz sauber ist das sicher nicht. Aber ich kann damit leben.
Uwe