Verizon Data Breach Digest
Was hilft gegen Datenverletzungen?
Fortsetzung des Artikels von Teil 1
Der Fall „Botnet Barrage“
Das IoT besitzt ein enormes Potenzial, mit Technologie für immer die Art und Weise zu verändern, wie wir interagieren. Die Verbreitung von IoT-Devices führt im Wesentlichen zu verstärkter Automation, Big-Data-Analysen und auf künstlicher Intelligenz basierenden Entscheidungen im Alltag. Eine IoT-Lösung erfordert detaillierte und umfassende Rahmenbedingungen für Sicherheit und Datenschutz. In diesem Bereich gibt es leider immer noch eine Menge zu tun und eine enge Zusammenarbeit der Player im IoT-Markt bei der zugrunde liegenden Sicherheit.
Das Hauptproblem besteht darin, dass vielen Firmen nicht bewusst ist, dass Komponenten, die hinter der Innovation IoT stehen, leicht aus dem Ruder laufen können. Und das kann weitaus größere Auswirkungen haben als das, was wir in der traditionellen IT-Landschaft beobachten können. Für gewöhnlich sind IoT-Devices permanent mit dem Internet verbunden und vom Standpunkt der Sicherheit nicht einsehbar. Damit sind sie eine Schwachstelle bei einer Vielzahl von Angriffen. Und ein ideales Ziel für die Eingliederung in eine Botnet-Armee.
Die Attacke: Das IT-Sicherheitsteam einer Universität erhielt zunehmend Beschwerden von Studenten auf dem gesamten Campus, das Internet sei zu langsam oder nicht zugänglich.
Die Hinweise: Wie so oft hatte der Helpdesk erste Beschwerden als belanglos abgetan. Erst deutlich nach 21 Uhr wurde das IT Security Team kontaktiert.
Trotz begrenzter Zugriffsmöglichkeiten hatte der Helpdesk eine Reihe bedenklicher Dinge entdeckt. Die Nameserver, verantwortlich für Domain Name Service (DNS) Lookups, produzierten in großer Zahl Alarmmeldungen und wiesen eine abnormale Anzahl von Anfragen nach Sub-Domains im Zusammenhang mit Seafood auf. Die Server bemühten sich, den Anfragen nachzukommen, legitime Lookups wurden fallen gelassen – wodurch der Zugang zu weiten Teilen des Internets unmöglich wurde. Zwar erklärte dies das „langsame Internet“, doch tauchten noch mehr besorgniserregende Fragen auf. Woher kamen all diese ungewöhnlichen DNS-Lookups? Und warum so viele? Interessierten sich plötzlich Studenten für Seafood-Dinner? Das war wenig wahrscheinlich.
Die Universität bat Experten des Verizon Risk-Teams um Hilfe und stellte ihnen die Netzwerk- und Firewall-Logs zur Überprüfung zur Verfügung. Sämtliche Logs wurden auf Indikatoren für böswillige Aktivitäten untersucht; insbesondere Firewall-Logs können dazu dienen, die Quellen dieser Anfragen ausfindig zu machen.
Sie konnten beobachten, dass die für DNS-Lookups zuständigen Nameserver legitime Anfragen ignorierten, wodurch der Zugang zu großen Teilen des Internets unmöglich wurde. Stattdessen beschäftigten sie sich lieber mit der abnormalen Anzahl der Anfragen nach Sub-Domains im Zusammenhang mit Seafood. Die Analyse der Firewall-Logs brachte über 5.000 einzelne Systeme zum Vorschein, die alle 15 Sekunden Hunderte von DNS-Lookups starteten.
Nahezu alle bezogen sich auf ein für IoT-Infrastruktur reserviertes Segment des Netzwerks. Diese IoT-Infrastruktur überwachte und verwaltete sozusagen alles auf dem riesigen Universitäts-Campus – von Glühbirnen bis hin zu Verkaufsautomaten. Zur Vereinfachung und für mehr Effizienz waren diese mit dem Internet verbunden. Zwar sollten diese IoT-Systeme isoliert vom übrigen Netzwerk arbeiten, doch war schnell klar, dass sie für die Nutzung von DNS-Servern in einem anderen Subnet konfiguriert waren.
Der Schuldige:– Ein IoT-Botnet hatte sich über sämtliche Devices gelegt – von der Glühbirne bis zum Cola-Automat – indem es einfach Standard- und schwache Passwörter geknackt hatte.
Die Analyse früherer Malware-Muster hatte gezeigt, dass das Control-Password – es dient zur Erteilung von Befehlen an infizierte Systeme – gleichzeitig als neues aktuelles Device-Passwort genutzt wurde. Diese Befehle gingen üblicherweise per Hypertext Transfer Protocol (HTTP) ein und in vielen Fällen wurde der Secure Sockets Layer (SSL) nicht zur Verschlüsselung der Übertragungen genutzt. Falls dies auch bei dieser Kompromittierung der Fall war, könnte man ein volles Paketerfassungs-Device dazu verwenden, den Internetverkehr zu verfolgen, und das neue Device-Passwort identifizieren. Der Plan war, über Kabel das Klartext-Passwort für ein kompromittiertes IoT-Device abzufangen und diese Information dazu zu verwenden, vor dem nächsten Malware-Update eine Passwort-Änderung vorzunehmen. Sofern dies korrekt und rasch geschah (und das tat es), hätten wir die Kontrolle über die IoT-Devices der Universität zurückgewonnen.
Gelerntes/Empfehlungen:
- Nicht alle Eier in einem Korb aufbewahren: Separate Netzwerkzonen für IoT-Systeme einrichten; wo immer möglich von anderen wichtigen Netzwerken entkoppelt halten.
- Keine direkte E/A-Konnektivität zum Internet zulassen; die Bedeutung eines In-Line-Proxy- oder Content-Filtersystems nicht unterschätzen.
- An den Devices die Standard-Zugangsdaten ändern; für Device-Accounts und WLAN-Netze starke, einmalige Passwörter vergeben.
- Regelmäßig Vorfälle und Logs überwachen; halten Sie nach Bedrohungen an Endpunkten Ausschau, ebenso auf Netzwerkebene; scannen Sie auf offene Fernzugriffs-Protokolle im Netzwerk und deaktivieren Sie grundsätzlich nicht genutzte oder ungesicherte Merkmale und Services (wie etwa UPnP und RTSP), die nicht benötigt werden.
- Nehmen Sie IoT-Devices in Ihr Asset-Verzeichnis auf; prüfen Sie regelmäßig Hersteller-Websites auf Firmware-Updates.
- Was hilft gegen Datenverletzungen?
- Der Fall „Botnet Barrage“
- Was kann man selbst tun?
Lesen Sie mehr zum Thema
