Security Check: IoT-Botnet-Angriffe

4. Januar 2017

Ein Rückblick in die „gute, alte Zeit“: Windows-Clients werden nur von Schadsoftware befallen, wenn kein aktueller Virenschutz vorhanden ist. Apple-Systeme oder Linux-/Unix-Geräte sind vor Schadsoftware zuverlässig geschützt – weil für diese Betriebssysteme (angeblich) keine Schadsoftware existiert. Größeren Aufruhr verbreiten höchstens „Schreckensmeldungen“ über den Loveletter-Wurm, der sich per E-Mail und ICQ verbreitet. Ansonsten müssen sich die Mitarbeiter in den Unternehmen sowie die Anwender „nur“ von Raubkopien fernhalten, und „ihren“ PCs wird mit an Sicherheit grenzender Wahrscheinlichkeit keine Infektion mit Malware drohen. Doch leider ist die damalige Situation kaum noch mit den aktuellen Bedrohungen zu vergleichen. Denn durch die fortschreitende Vernetzung müssen wir schon froh sein, wenn die Kaffeemaschine oder die LED-Deckenbeleuchtung nicht „digital gekapert“ und in das nächstbeste Botnet eingegliedert werden.

Neben den „direkten“ Verdienstmöglichkeiten der IT-Kriminalität (etwa Kreditkartenbetrug, Erpressung mittels Ransomware oder kompromittierte Online-Banking-Programmen) stehen auch „indirekte“  Geldquellen vermehrt im Fokus. Hier stehen bei den „bösen Jungs“ vor allem zwei Geschäftsfelder im Vordergrund: Zum einen der Verkauf von Daten (Kreditkartennummern, Ausweiskennungen, Telefonnummern samt Adressen und Geburtstagen), zum anderen die Bereitstellung von Dienstleistungen – wie beispielsweise DDoS-Attacken. Besonders letztgenanntes wird inzwischen nicht mehr über gekaperte Server mit hoher Einzelbandbreite realisiert. Vielmehr geht der Trend in diesem Dunkelbereich in die Richtung von Botnetzwerken bestehend aus Millionen Kleinstgeräten. Denn diese lassen sich – im Gegensatz zu wenigen, großen Servern – nicht so leicht blockieren. Falls ein Angriff mit 100 GBit/s Bandbreite von zehn bis 20 Servern ausgeht, können die betreffenden Quell-IPs schnell in den Firewalls blockiert werden.

Anzeige
CS espresso series

Ganz anders gestaltet sich das Problem, wenn hunderttausende oder gar Millionen von kleineren Systemen – jedes von einer anderen IP-Adresse aus – unerwünschte Datenpakete zu einer bestimmten Webseite oder zu einem Unternehmen senden. Selbst wenn diese Systeme nur in der Lage sind, DDoS-Attacken mit jeweils 100 KBit/s bis 1 MBit/s durchzuführen, summiert sich das etwa bei 500.000 „Bots“ bereits zu einer „Angriffsbandbreite“ von 50 GBit/s bis 500 GBit/s. Daher verlagerte sich das Problem „Botnet“ von Servern zu den Client-Systemen. Etwa ganz normale Desktop-Clients oder Notebooks in den Firmen, oder den Heimanwendern. Zusätzlich rücken in letzter Zeit immer mehr Kleinstgeräte aus dem IoT-Bereich (Internet of Things) in den Fokus der Botnet-Betreiber.

Alle IT-Geräteklassen im Visier von Botnets?

Während ältere Botnetze, wie etwa „Conficker“ oder „Zeus“ auf Windows-Server, -Clients und Heim-PCs zielten, kommen im Zuge der fortschreitenden IoT-Entwicklungen aktuell weitere Geräteklassen ins Fadenkreuz der Botnet-Betreiber. Viele der Geräte kommen sowohl bei den Heimanwendern, als auch in den Unternehmen zum Einsatz:

  • Internet-Router,
  • Drucker,
  • Print-Server,
  • Mobiltelefone,
  • Tablets,
  • E-Book-Reader,
  • IP-Kameras,
  • Smart-TVs,
  • digitale Videorecorder,
  • Bluray-Player,
  • vernetztes Kinderspielzeug,
  • Bluetooth-LED-Leuchtmittel oder
  • Soundbars.

Ein kürzlich bekannt gewordenes Botnet mit der Bezeichnung „Mirai“ verfügt über circa 500.000 solcher Kleinstgeräte, die als sogenannte „Thingbots“ agieren, und nur auf den Befehl einer zentralen Verwaltungsstelle (Command&Control-Server) warten. Ein bekannter Angriff ist beispielsweise die DDoS-Attacke auf den DNS-Dienstleister „Dyn“. Dies führte zu zeitweiligen Zugriffsproblemen auf viele bekannte Dienste wie etwa Twitter, Github oder Spotify. Ein weiteres Botnet mit über drei Millionen Bots wurde Anfang 2015 von den Behörden „deaktiviert“, indem die Command&Control-Server ausgeschaltet wurden. Dieses Netzwerk mit der Bezeichnung „Ramnit“ war zu diesem Zeitpunkt etwa drei Jahre „alt“.

Infektionswege

Nun stellt sich die Frage, auf welche Weise die Botnet-Betreiber die Kontrolle über derartig viele Systeme übernehmen können? Vor allem handelt es sich dabei ja nicht um „normale“ Windows-Clients, bei denen man die Anwender, die diese Systeme tagtäglich einsetzen, um Email-Kommunikation abzuwickeln, oder im Internet zu surfen. Ein großer Faktor stellt sicherlich die mangelnde Gerätesicherheit dar. Zudem richten viele Nutzer, vor allem im privaten Umfeld, diese Geräte nicht mit dem entsprechenden Know-how ein. Sie ändern beispielsweise die Standard-Anmeldepasswörter nicht ab. Auch läuft auf Videorecordern oder IP-Kameras keine Virenschutzsoftware, und die Anwender melden sich nicht direkt auf den Systemen an. Viele Geräte verfügen auch nur über rudimentäre Benutzerschnittstellen (APIs), und können kaum Rückmeldung geben, falls es zu Problemen kommt. Solange die erwartete Funktion weiter bereitgestellt wird (etwa das Live-Bild einer Kamera), hat der Anwender – oder auch der Administrator – keinen Grund anzunehmen, dass etwas nicht in Ordnung sei.

Bots werden in der Regel nicht manuell installiert oder von Hackern „persönlich“ angegriffen. Dies wäre ja auch bei der großen Anzahl an Mini-Systemen, die für ein „anständiges“ Botnet benötigt werden, nicht praktikabel. Vielmehr bedienen sich die Botnet-Betreiber unterschiedlicher, automatisierter Möglichkeiten, um die Schadsoftware auf ihren Zielen zu installieren.

Dabei scannen diese Applikationen große Teile der verfügbaren IP-Adressbereiche ab, und versuchen zum einen bestimmte Gerätetypen zu identifizieren. Bei denen bereits Sicherheitslücken oder Standard-Anmeldeinformationen bekannt sind. Zum anderen lässt sich der Spieß auch umdrehen, etwa um eine begrenzte Anzahl an Passwort-Fehleingaben zu umgehen. Denn dabei werden statt die Passwörter die Systeme „durchprobiert“. Sprich man nimmt eine bekannte Standard-Passwort-Kombination (etwa Benutzername „admin“ samt dem Kennwort „password“) und versucht die Anmeldung hintereinander bei unterschiedlichsten IP-Adressen.

Somit können die Botnet-Betreiber beispielsweise sehr viele Router oder Printer im Internet, die noch mit diesen Standard-Credentials arbeiten, „abgrasen“. Um auch (etwas) komplexere Passwörter zu „knacken“, setzen die Botnet-Betreiber und Schadsoftware-Programmierer auf bekannte Methoden, wie etwa Wörterbuchattacken, oftmals kombiniert mit Permutationen (etwa „Apf3lbaUm“ statt „Apfelbaum“). Zudem lassen sich auch bestimmte, vorberechnete Hashwert-Tabellen einsetzen (sogenannte „Rainbow-Tables“), oder Passwörter mit kurzer Kennwortlänge direkt per „Brute Force“ ermitteln.

Aber selbst wenn die Administratoren diese Anmeldedaten direkt bei Inbetriebnahme in sichere Zeichenfolgen ändern, kann es durchaus vorkommen, dass versteckte (und festverdrahtete) Anmeldedaten weiterhin funktionieren. Werden diese doch oftmals in der Firmware fix abgelegt. Etwa um automatische Konfigurationen von Internet-Provider auf bestimmten Router-Klassen vorzunehmen, oder damit der automatische Firmware-Upgrade Vorgang reibungslos abläuft, oder zu allgemeinen Wartungszwecken.

Auch spielen schwache Authentifizierungsmethoden und (teilweise) veraltete Standards eine große Rolle. Auch auf der Seite der Betriebssystemsoftware (oftmals in Form einer Geräte-Firmware) drohen Sicherheitslücken. Werden doch viele dieser Kleingeräte einmal aufgesetzt oder konfiguriert, und danach nie wieder gewartet. Manchmal sind vom Hersteller keine Updates zu erwarten: Kurze Produktzyklen lohnen sich besonders, wenn auf Service, Support und Bugfixing verzichtet wird. Teilweise stellen die Hersteller zwar Firmware-Updates in regelmäßigen Abständen zum Download bereit, werden aber aus unterschiedlichen Gründen nicht auf die Geräte aufgespielt. Dies kann entweder aus Bequemlichkeit geschehen, aus Unwissenheit, oder auch mit voller Absicht. Etwa wenn das Aufspielen eines Firmware-Upgrades die komplette Konfiguration in die Werkseinstellung versetzt, werden Updates oftmals nicht eingespielt. Warum auch, wenn alles funktioniert? Gilt in der IT nicht das Credo „Never touch a running System“?

Lesen Sie auch