Hack-Angriffe in Clouds

    Hack-Angriffe in CloudsEnde 2009 veröffentlichten vier Sicherheits­experten vom MIT und der UCSD eine Studie über die Risiken von Datendiebstahls und DOS-Attacken in gemieteten Cloud-Umgebungen (Infrastructure as a service, IaaS). Das Papier mit dem Titel „Hey, You, Get Off of My Cloud“ erwähnt auch Microsoft Azure und Rackspace Cloud, konzentriert sich für das Fallbeispiel möglicher Hack-Angriffe aber auf Amazon EC2. Der Angriff auf eine VM in der Cloud wird in vier Phasen skizziert:

    EC2-Netzwerk kartographieren

    Durch Abfragen sowohl von außerhalb als auch von innerhalb der Cloud (also von einer eigenen EC2-Instanz aus) lässt sich das prinzipielle Layout des Netzwerkes ermitteln: Mit Hilfe von Whois-Abfragen ermittelt man öffentliche IP-Adressbereiche, die auf EC2 laufen, per Wget erfährt man, auf welchen Servern der HTTP-Service aktiv ist und per EC2-interner DNS-Abfrage ermittelt man deren private IP-Adresse sowie den EC2-internen Hostnamen.

    Ergebnis: Die geographischen Verfügbarkeitsbereiche und die mietbaren VM-Leistungsklassen sind jeweils bestimmten internen EC2-IP-Adressbereichen zugeordnet. Außerdem interessant: Die Zuordnung einer VM-Instanz zu ihrer physischen Maschine blieb bei EC2 während des gesamten Beobachtungszeitraumes gleich.

    Opfer lokalisieren

    Mit Hilfe verschiedener Verfahren kann man feststellen, ob eine selbst gestartete EC2-Instanz ko-resident mit dem Opfer ist, also auf der gleichen physischen Maschine läuft. Dies ist höchstwahrscheinlich dann der Fall, wenn

    • Dom0 beider Maschinen die gleiche IP-Adresse hat,
    • die Paketumlaufzeit zwischen beiden Maschinen klein ist oder
    • beide IP-Adressen um nicht mehr als 7 auseinanderliegen.

    Feindliche VM plazieren

    Mittels der Kenntnisse aus der Netzwerk-Kartographie und den Ko-Residenz-Checks lässt sich eine feindliche VM auf der physischen Maschine des Opfers unterbringen. Prinzipiell gibt es dazu zwei Verfahren: Warten man auf ein zufälliges Opfer, lässt man eine Anzahl eigener Instanzen lange laufen und führt ständig Ko-Residenz-Checks durch.

    Will man dagegen in die Nähe eines bestimmten Opfers, setzt man instance flooding ein: Man wartet darauf, dass das Opfer eine Instanz startet, um unmittelbar danach so viele eigene Instanzen wie möglich in dessen per Netzwerk-Kartographie ermittelten Bereich zu starten und checkt jeweils auf Ko-Residenz.

    Die EC2-internen Plazierungsalgorithmen für neue Instanzen unterstützen den Angreifer hier sogar, so dass es recht wahrscheinlich ist, bald Erfolg zu haben. Die Autoren schätzen die Chance, für ein paar Dollar eine bösartige VM auf dem physischen Server des Opfers unterzubringen, auf 40 %.

    Angriff

    Die Autoren ermitteln etwa, wann eine physische Maschine eine besonders hohe CPU-Cache-Auslastung hat. Der CPU-Cache ist dann anfällig für indirekte Ausleseversuche. Doch oft geht es gar nicht um derart konkreten Daten; weniger aufwendige Netzwerk-Analysen etwa wollen nur ermitteln, wann der Web-Server eines Mitbewerbers besonders hohe Auslastungen hat und wie lange die Zugriffe dauern.

    Auch ist es denkbar, VM-Instanzen nur zu dem Zweck auf dem Server des Mitbewerbers zu starten, dessen Performance zu beeinträchtigen, ohne jeden Datenausleseversuch.

    Schlussfolgerungen

    Cloud-Provider sollten die interne Struktur ihrer Netzwerke besser verschleiern, indem einfache Zuordnungen von IP-Bereichen zu Services nicht vorgenommen würden. Auch kann man Ko-Residenz-Checks sehr erschweren, etwa indem man jeder VM-Instanz pro Start eine zufällige IP-Adresse zuordnet, Traceroute-Anfragen über Dom0 blockiert oder Konten jeweils mit virtuellen LANs ausstattet.

    Alle diese Maßnahmen bedeutet allerdings einen stark erhöhten Administrationsaufwand und damit Kosten – und sie würden den Aufwand für einen Angriff zwar stark erhöhen, ihn aber nicht komplett unmöglich machen. Daher glauben die Autoren, man sollte Risiko- und Kostenabwägung den Kunden gegenüber offen darlegen, und diese müssten dann entscheiden, wie viel Mehrkosten sie in mehr Sicherheit investieren wollen.

    Ein Kunde könnte sich dann etwa für ein teureres Modell entscheiden, bei dem eine physische Maschine ausschließlich mit seinen VMs bestückt ist – hätte dann allerdings auch die Opportunitätskosten zu tragen, wenn sie nicht ausgelastet ist.

    Keine Kommentare