Normale Ansicht

Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeHaupt-Feeds

Cloudflare: Botnetzwerke setzen auf gehackte VPS statt auf IoT

14. April 2023 um 10:45

Laut dem Content Delivery Network (CDN) Cloudflare setzen High-Performance Botnetzwerke mittlerweile bevorzugt auf gehackte Virtual Private Servers (VPS) statt wie bisher auf massenhaft gehackte IoT-Geräte (Internet of Things) wie Überwachungskameras oder Router.

Zwar hatte das einzelne IoT-Gerät nur eine sehr begrenzte Leistung und Durchsatz, doch in der Masse, mit Hunderttausenden oder gar Millionen Geräten, konnten leistungsfähige DDoS-Angriffe (Distributed Denial of Service) durchgeführt werden. Bei diesen Angriffen werden Webseiten beziehungsweise Server mit Anfragen überhäuft, bis sie unter der Last zusammenbrechen.

Eine neue Generation von Botnetzen verwende hingegen einen Bruchteil der Geräte, erklärt Cloudflare in einem Bericht. Genutzt würden leistungsfähige virtuelle Private Server in der Cloud, die beispielsweise von Start-ups oder Unternehmen für leistungsfähige Anwendungen genutzt werden.

Angreifer kompromittieren demnach ungepatchte Server oder können sich mit bekannt gewordenen APi-Anmeldeinformationen an den Verwaltungskonsolen anmelden. Um gegen solche kompromittierten VPS vorzugehen, arbeite Cloudflare mit etlichen Cloud-Anbietern zusammen, erklärt das Unternehmen. “Dank der schnellen Reaktion und der Sorgfalt der Cloud-Computing-Anbieter konnten große Teile dieser Botnets deaktiviert werden.”

Insgesamt hätten die DDoS-Angriffe im Vergleich zum letzten Quartal nicht zugenommen, im Vergleich zum Vorjahr sei aber ein Anstieg um 60 Prozent zu verzeichnen, erklärt Cloudflare. Insbesondere Rundfunk- und Fernsehanstalten sowie gemeinnützige Organisationen seien von den Angriffen betroffen. Dabei würde häufig auf Ransom-DDoS-Angriffe gesetzt, bei denen die Angreifer ein Lösegeld verlangen, um Angriffe zu stoppen oder weitere zu verhindern.

Der Beitrag Cloudflare: Botnetzwerke setzen auf gehackte VPS statt auf IoT erschien zuerst auf Linux-Magazin.

Smart-Home-Standard Matter 1.0 erschienen

05. Oktober 2022 um 11:28

Der Standard der Standards: Gestern wurde der Smart-Home-Standard Matter in Version 1.0 von der Connectivity Standards Alliance (CSA) veröffentlicht. Er soll Licht ins Dunkle bringen und das Standard-Chaos unter den Smart-Home-Geräten auflösen. Reflexartig werden viele meiner Leser jetzt die Zahl 927 in die Tastatur tippen, aber ich werde mich erstmal überraschen lassen, was sich ergibt. Vielleicht ist es nicht "yet another standard", sondern tatsächlich eine Verbesserung. Zudem haben sich viele große Smart-Home-Anbieter in der Allianz zusammengeschlossen, um diese Harmonisierung durchzuführen – bevor es die Regulatoren tun, wie wir gerade erst mit USB-C gesehen haben.

Ich werde mich in den nächsten Wochen genauer mit Matter beschäftigen und schauen, was sich dazu erforschen lässt. Auch die Security-Aspekte werden dabei relevant werden. Was ich aber ausgesprochen schade finde, ist, dass die Spezifikation (also der Kern des Standards), gar nicht öffentlich ist, wie sich in der Wikipedia lesen lässt:

Version 1.0 of the specification was published 30 September 2022. The Matter specification is provided at no charge upon request after providing full name, company name, email address and consenting to their privacy policy, but cannot be redistributed without permission from CSA.

(Wikipedia contributors. Matter (standard). Wikipedia, The Free Encyclopedia. October 5, 2022, 05:54 UTC. Available at: https://en.wikipedia.org/w/index.php?title=Matter_(standard)&oldid=1114175110. Accessed October 5, 2022.)

Das steht natürlich im Kontrast zu anderen Standards wie QUIC, die einfach online und ohne Registrierung vom RFC Editor abgefragt werden können. Ich werde mir wohl für meine Arbeit einen Zugang diesbezüglich holen, kann dann aber im Blog höchstwahrscheinlich nicht mehr auf die Details aus der Spezifikation eingehen. Im Grunde ist es dann ähnlich wie mit Standards von z. B. der IEEE, aber die Chance der besseren Zugänglichkeit des Standards wurde offenbar nicht genutzt. Deswegen ein Blogartikel im Voraus mit meinen Hypothesen und Erwartungen.

Was ich bereits gut finde

Es gibt viele Standards, die sich in den vergangenen Jahren im IoT-Umfeld entwickelt haben. Das hat für eigene Anwendungen natürlich einen Einfluss auf den Layer 7 (Application), also die konkrete Implementierung von Anwendungen: wenn sich der Lichtschalter anders als der Heizkörperthermostat verhält (z. B. das eine System bietet nur HTTP REST auf einer Cloud an, das andere erwartet lokales MQTT), dann bedeutet das einen Mehraufwand, der verhindert werden könnte, wenn man sich auf ein Interface einigt. Aber bevor wir über Layer 7 überhaupt nachdenken können, muss Layer 3 (Network) geklärt sein. In beiden Fällen gibt Matter Vorgaben, wie in Abbildung 1 dargestellt: Layer 7 wird durch den Standard selber beschrieben und als Layer 3 wird IPv6 erwartet. Das ist spannend, da sich hier – sofern technisch dem Zugriff keine Schranken gesetzt werden – damit eine Integration in Heim- und Unternehmensnetze auf klassischen Standards möglich ist. Als Layer 1 bzw. 2 können Ethernet, Wi-Fi, Thread (IEEE 802.15.4), IPv6 for Bluetooth Low Energy, u. v. m. dienen.

Matter CHIP IP Pyramid

Abbildung 1: Protokollpyramide, Quelle: GitHub project-chip/connectedhomeip, Autor: Project CHIP Authors, Lizenz: Apache 2.0

Der Einsatz von IPv6 muss allerdings auch technisch implementiert werden: so müssen nicht nur Router und Firewall IPv6 generell unterstützen, sondern die (hoffentlich dedizierten) IPv6-Netze müssen auch bereitgestellt werden. Ob und in welchem Umfang die lokalen Unique Local Addresses (ULAs) nach RFC 1884 eingesetzt werden können, weiß ich zum aktuellen Zeitpunkt noch nicht. Begrüßenswert ist es in jedem Fall.

Warum rede ich überhaupt von ULA? Da IPv6 nativ kein NAT kennt, dürfte man doch damit gar nicht ins Internet kommen? Ja genau, das muss man bei Matter auch nicht, da der Standard auch lokal und ohne Cloud laufen kann. Somit müssen Schaltbefehle nicht umständlich über das Internet geroutet werden, sondern können den Weg direkt im Heim- oder Unternehmensnetz laufen. Auch das ist eine gute Sache, da so eine Zugriffskontrolle auf Vermittlungsebene in der Organisation durchgesetzt werden kann und man nicht vor verschlüsselten REST-Nachrichten steht.

Apropos Verschlüsselung, an die wurde auch gedacht. So sollen die ausgetauschten Nachrichten signiert und verschlüsselt werden können, ein Aspekt, der vielen Smart-Home-Geräten bisher fehlt.

Matter stellt weiterhin nicht nur eine Spezifikation, sondern auch ein SDK bereit. Dieses ist tatsächlich Open Source und unter der Apache-2.0-Lizenz auf GitHub verfügbar.

Wo ich noch genauer nachhaken werde

Grundsätzlich stellt sich die Frage der Zugänglichkeit zum System: es bleibt zu hoffen, dass die Geräte nicht nur mit fremden Smart-Home-Anwendungen, sondern auch mit den eigenen Smart-Home-Anwendungen kommunizieren können. Wenn ich mir ein Script schreiben will, das Steckdosen schaltet oder Heizthermostate einstellt, brauche ich einen standardisierten, nicht-diskriminierenden Zugriff. Konkret meine ich damit, dass das System – solange ich mich standardkonform verhalte – nicht danach unterscheiden (= diskriminieren) soll, ob ich ein anderes zertifiziertes Smart-Home-Device bzw. eine solche Anwendung bin, oder nicht. Wenn sich ein Ökosystem entwickelt, das zwar Institutionen freien Zugriff gewährt, aber interessierte Einzelpersonen kategorisch ausschließt, ist in der Frage dem fortgeschrittenen Smart-Home-Entwickler bzw. -Anwender wenig geholfen.

Auch der Punkt mit dem Distributed Compliance Ledger (vgl. diesen Artikel von Espressif, den ESP32-Machern, dazu) muss kritisch hinterfragt werden: die Funktionsweise liest sich wie die einer klassischen PKI, vor allem, da die CSA offenbar sowieso Top-Down organisiert ist. Vielen wird sowieso beim Begriff permissioned blockchain der Kamm hochgehen, da eine Blockchain-Datenbank mit Zugriffsverwaltung dem Urgedanken des P2P-Netzwerkes mit der gemeinsamen Konsensfindung zuwiderläuft. Bisher konnte ich diesbezüglich nur ein GitHub-Projekt der ZigBee-Alliance finden, bei dem als Grundlage die Cosmos-Blockchain läuft.

Von der Kritik deutlich zu trennen ist aber der lobenswerte Umstand, dass Firmware-Downloads überhaupt integritätsgeschützt und authentifiziert werden. Sollte es aber tatsächlich so sein, dass es sich beim DCL um eine PKI handelt, über die eine Blockchain gestülpt wurde, kann man sich die Blockchain mitunter gleich sparen.

Abschließend ist auch Kompatibilität ein Punkt: so sollen einige bereits existierende Smart-Home-Geräte zukünftig Matter-Fähigkeiten über ein Firmware-Update erhalten können. Mit Matter 2.0 stellt sich aber auch früher oder später die Frage, ob Matter sich als auf- und abwärtskompatibel erweisen wird: Können bestehende Matter-1.0-Geräte geupdated werden und wie gehen 2.0er-Geräte mit 1.0-Geräten um? Müssen diese mitunter neu gekauft werden?

Wofür ich einen Smart-Home-Standard brauche

Hier habe ich aktuell ein Projekt, das ich bei Gelegenheit implementieren möchte: so soll sich mein Heizthermostat an meinem Kalender orientieren. Wenn ich mir in meinem CalDAV-unterstützenden Kalender einen Außer-Haus-Termin setze, soll die Temperatur abgesenkt werden. Hierzu brauche ich ein Script auf einem Server und ein Heizthermostat. Dieses Heizthermostat selber soll nun aber nicht in meinen Kalender schauen können (Warum auch? Ich habe mehrere Kalender, die in Kombination betrachtet werden müssen.), sondern durch mein Script lokal angesteuert werden. Dieses Script arbeitet dann auf einer Workstation oder einem Raspberry Pi.

Somit managed das Script dynamisch die Heiztemperatur (Input: CalDAV-Kalender) und soll das den Aktoren, also den Thermostaten, über einen Standard mitteilen können.

Ich bin gespannt, ob Matter auch für so einen Fall gebaut ist oder ob der Schwerpunkt in Smart-Home-Zentralen größerer und kleinerer Hersteller liegt.

Neue Linux-Malware spielt verstecken

14. September 2022 um 11:07

Forscher haben eine neue Linux-Malware entdeckt, die sich besonders gut tarnt. Dabei kann sie sowohl als Kryptominer oder Spionage-Werkzeug agieren.

Forscher von AT&T Alien Labs haben eine neue Linux-Malware entdeckt, die sich auf besondere Weise tarnt und es auf Internet-of-Things-Geräte (IoT) und Server abgesehen hat. So wird der Payload mehrfach encodiert und zur Kommunikation werden bekannte Clouddienste eingesetzt. Zuerst berichtete das Onlinemagazin Ars Technica.

“Bedrohungsakteure suchen immer wieder nach neuen Möglichkeiten, Malware zu verbreiten, um unter dem Radar zu bleiben und nicht entdeckt zu werden”, schreibt der Forscher Ofer Caspi von AT&T Alien Labs. “Die Malware verwendet den polymorphen XOR-Codierer Shikata Ga Nai mit additiver Rückkopplung, der zu den beliebtesten Encodern in Metasploit gehört. Mithilfe des Encoders durchläuft die Malware mehrere Dekodierschleifen, wobei eine Schleife die nächste Ebene dekodiert, bis die endgültige Shellcode-Payload dekodiert und ausgeführt wird.”

Das eigentliche Ziel der Schadsoftware bleibt jedoch unklar. Einerseits verwendet sie eine Kryptomining-Software, die unter anderem zu heimlichem Kryptojacking genutzt werden kann. Andererseits lädt die Shikitega jedoch das Metasploit-Paket Mettle herunter und führt es aus. Damit lassen sich beispielsweise die Webcam steuern oder Anmeldeinformationen stehlen. Zudem bündelt das Paket mehrere Reverse-Shells. Entsprechend dürfte es nicht das Einzige Ziel der Malware sein, heimlich Monero zu schürfen.

Um eine Entdeckung zu erschweren, setzen die Bedrohungsakteure auf legitime Clouddienste als Command-and-Control-Instanz. Die von dort erhaltenen Befehle sowie das Mettle-Paket werden zudem nicht auf der Festplatte beziehungsweise SSD gespeichert, sondern nur im Arbeitsspeicher vorgehalten.

Außerdem versucht die Schadsoftware über zwei bekannte Sicherheitslücken Root-Rechte zu erlangen. Hierzu setzt sie auf die Sicherheitslücke Pwnkit (CVE-2021-4034), die rund 12 Jahre im Linux-Kernel lauerte, ehe sie Anfang des Jahres gepatcht wurde.

Die zweite Sicherheitslücke zur Rechte-Ausweitung wurde bereits im April 2021 aufgedeckt und ebenfalls vor geraumer Zeit gepatcht. Allerdings dürften insbesondere Internet-of-Things-Geräte die Patches nicht selten noch nicht eingespielt haben. Persistenz erlangt die Malware über Crontab-Einträge.

Der Beitrag Neue Linux-Malware spielt verstecken erschien zuerst auf Linux-Magazin.

IoT: Canonical bringt Ubuntu Core 22

17. Juni 2022 um 07:45

Canonical hat Ubuntu Core 22 veröffentlicht. Die containerisierte und für IoT- und Edge-Geräte optimierte Variante von Ubuntu basiert auf der Version 22.04 LTS.

Mit dem Echtzeit-Kernel von Ubuntu 22.04 LTS, der als Beta-Version verfügbar sei, biete Ubuntu Core 22 hohe Leistung und niedrige Latenzzeiten für Anwendungen in den Bereichen Industrie, Telekommunikation, Automotive und Robotik, verspricht Canonical. Die neue Version enthalte  einen vollständig preemptiblen Kernel. Mark Shuttleworth, CEO von Canonical ist überzeugt: “Mit dieser Version und dem Echtzeit-Kernel von Ubuntu sind wir bereit, die Vorteile von Ubuntu Core auf die gesamte Embedded-Welt auszuweiten.”

Ubuntu Core bietet zudem von Haus aus fortschrittliche Sicherheitsfunktionen, darunter sicheres Booten, vollständige Festplattenverschlüsselung, sichere Wiederherstellung und strikte Begrenzung des Betriebssystems und der Anwendungen.

Der Beitrag IoT: Canonical bringt Ubuntu Core 22 erschien zuerst auf Linux-Magazin.

Canonical veröffentlicht Ubuntu Core 22

16. Juni 2022 um 18:24

Ubuntu Core 22 wurde von Canonical veröffentlicht. Es handelt sich hierbei um eine containerbasierte Version von Ubuntu für IoT- und Edge-Geräte mit spezieller Optimierung. Die Basis ist Ubuntu 22.04 LTS. Das Betriebssystem ist jedoch nicht für Desktop Computer gedacht, sondern für IoT Geräte. Zum Einsatz kommt ein Echtzeitkernel, der hohe Leistung und sehr niedrige Latenzzeiten...

Der Beitrag Canonical veröffentlicht Ubuntu Core 22 erschien zuerst auf MichlFranken.

Yocto Project 4.0 mit neuen Rezepten

28. April 2022 um 09:28

Das Yocto-Projekt hat sich auf die Fahnen geschrieben, Entwickler mit benutzerdefinierten Linux-basierte Systeme unabhängig von der Hardware-Architektur zu versorgen. In Version 4.0 sind Bugfixes, Updates und neue Rezepturen für Systeme enthalten.

Das Yocto-Projekt bietet eine flexible Reihe von Tools und eine Anlaufstelle, wo Embedded-Entwickler Technologien, Software-Stacks, Konfigurationen und Best Practices austauschen können, um maßgeschneiderte Linux-Images für Embedded- und IOT-Geräte zu erstellen.

In Version 4.0 springt der Linux-Kernel auf Version 5.15 und Glibc auf 2.35. Die neue Version behebe die Reproduzierbarkeitsprobleme mit rust-llvm und golang. Auch seien die Rezepte in OpenEmbedded-Core nun vollständig reproduzierbar.

Zudem sei es nun erlaubt, den Shared State Cache des Autobuilders wiederzuverwenden. Das sei hilfreich, wenn die Netzwerkverbindung zwischen dem Yocto-Server und dem Rechner des Entwicklers schneller sei, als der Bau der Rezepte aus dem Quellcode. Ist dies der Fall könne man versuchen, die Builds zu beschleunigen, indem man solche Shared State und Hash Equivalence nutze. In den Release Notes sind zudem die neuen Recipes aufgeführt.

Der Beitrag Yocto Project 4.0 mit neuen Rezepten erschien zuerst auf Linux-Magazin.

❌
❌