Überlegungen zu Amazon EC2 Instanzen als Ziel von Angriffen

Cloud-Computing ist ein Stichwort, das heutzutage in vielen Firmen, die grössere Webapplikationen oder Homepages unterhalten, in aller Munde ist. Amazons EC2-Plattform dürfte wohl momentan die grösste Cloud-Computing-Umgebung sein, die derzeit existiert.

Was ist EC2?

Die EC2-Plattform gibt jedem die Möglichkeit eigene virtuelle Server auf von Amazon bereitgestellter Hardware zu booten. Dazu lassen sich eigene System-Images auf der S3-Plattform von Amazon speichern, die dann direkt geladen werden. Jede Instanz erhält, solange sie läuft, einen eindeutigen Public-DNS-Eintrag der Form ec2-XXX-XXX-XXX-XXX.compute-X.amazonaws.com, über den auf die Instanz zugegriffen werden kann. Dabei bildet der Bereich XXX-XXX-XXX-XXX die IP der Instanz.

Was macht EC2-Instanzen zu einem lohnenden Angriffsziel?

Da gerade Web-Plattformen ihre Webserver mit EC2 entlasten, findet man dort oftmals Quelltexte verschiedenster Plattformen, deren Verkauf oder Veröffentlichung sicherlich für einige Probleme bei diesen Firmen sorgen kann. Da auch Datenbanken gern dann auf diesen Instanzen laufen, kommt man so auch leicht an die kompletten Kundenstämme der betroffenen Plattform und andere sensible Daten. Laufen auf den EC2-Instanzen keine eigenen Datenbanken, findet man fast immer bestehende Tunnel in die DMZ der angegriffenen Plattform.

Was macht den Angriff auf EC2-Instanzen einfacher als direkte Angriffe auf die zugehörige Plattform?

Schaut man sich mal in der Liste der öffentlich verfügbaren AMIs (Amazon Machine Images) etwas genauer um, findet man dort Unmengen veralteter Systeme. Natürlich erstellen die meisten Admins eigene Images, aber dies geschieht oftmals auf Basis von bestehenden Public-AMIs. Erstellt man ein eigenes AMI aus einem vorhandenen öffentlichen, kopiert man sein X.509-Zertifikat und die zugehörige Schlüsseldatei nach /mnt und erstellt mittels der EC2-Tools ein neues AMI, das man dann auf seinen S3-Speicher kopiert und als AMI für seine UserID registriert. Dieses AMI ist dann ‘private’ und kann nur über den zugehörigen Account genutzt werden. Bei der Erstellung von AMIs werden aber offenbar immer wieder ein paar typische Fehler gemacht.

Zuerstmal wird zumeist nicht beachtet, dass alle Public-AMIs bereits für den root-Account einen SSH-Key in der /root/.ssh/authorized_keys liegen haben, dessen Private-Key auch zumeist irgendwo im System rumschwirrt. Jemand, der sich also das zugrunde liegende Public-AMI bootet, kann so einen passenden Key für den root-Account erlangen. Weiterhin wird bei der Absicherung des Systems nicht beachtet, dass keine echte DMZ aufbaubar ist. Vergleichbar ist das mit Rootservern oder VServern, wie man sie bei jedem Hoster mieten kann. Dadurch werden viele DoS-Lücken nicht gefixt, die sonst die Firewall oder das IDS/IPS abfangen würde. (D)DoS-Angriffe auf eine EC2-Instanz können aber für den zugehörigen Account ziemlich teuer werden, denn dort gibt es keine Traffic-Flatrates.

Und das Problem der fehlenden DMZ erstreckt sich noch weiter… Um auf die Datenbanken (ich bleibe einfach mal beim Beispiel der Webplattformen) zuzugreifen, muss auf die DMZ der Plattform zugegriffen werden. Dabei spielt es keine Rolle, ob eine replizierte Datenbank auf der Instanz selbst läuft (meiner Erfahrung nach die häufigste Methode, da die Performance damit besser ist) oder ob direkt auf die Datenbankserver der Plattform zugegriffen wird. Zumeist werden für die Zugriffe auf die DMZ SSH- oder VPN-Tunnel verwendet. Nun muss man nicht lange raten um sich zu denken, dass die Keys dafür zumeist in den AMIs eingebunden und somit direkt auf der laufenden Instanz verfügbar sind. Hat man also Zugriff auf die Instanz, kommt man auch ganz schnell an alle anderen statischen Teile der zugehörigen Plattform.

Doch damit nicht genug… Auffällig ist auch, dass die Images offenbar nicht so schnell aktualisiert werden, wie es bei den zugehörigen statischen Teilen der Plattformen der Fall ist. Macht man bei einer EC2-Instanz ein Update, muss aus der Instanz ein neues AMI erstellt werden, damit es beim nächsten Booten auch wieder aktualisiert ist. Dies kostet natürlich Zeit, weswegen die Updates von EC2-Instanzen meist ziemlich hinterher hinken. Man findet sogar Instanzen, deren AMIs schon seit Monaten nicht aktualisiert wurden, so dass man passende Exploits auf jeder schlechten Cracker-Seite findet.

Zusammengefasst liegen die Schwächen von EC2-Instanzen in folgenden Punkten

• schlechte Einrichtung des AMI
• schlechte Update-Politik
• Nicht-Beachtung des Fehlens einer DMZ und externer Schutzsysteme wie Firewall, IDS/IPS usw.
• Zugriffe auf die DMZ einer Plattform über Tunnel

Wie bekommt man raus welches Image einem AMI zugrunde liegt?

Dies ist zumeist über die Fingerprints der Systeme möglich, wie man sie z.B. mit nmap ermitteln kann. Zuerstmal ermittelt man allgemein das System, das auf dem AMI läuft. Anhand der Kernel-Version sucht man nach passenden Public-AMIs, die man sich dann bootet und deren Fingerprints mit dem Ziel vergleicht. Auf diese Weise kann man recht gut das Public-AMI ermitteln, das als Grundlage des Instanz-AMI diente. Der Rest verlangt dann zumeist nur noch ein paar Grund-Skills um sich Zugang zur Instanz zu verschaffen.

Was sollte ein Admin, der mit EC2 arbeitet, beachten?

• bei der Einrichtung der AMIs kein public AMI verwenden oder dieses gründlich säubern
• zusätzlicher Schutz vor Angriffen muss eingerichtet werden
• Keys für notwendige Tunnel in die DMZ sollten von einem Remote-Medium geholt werden, das ausgehängt wird, wenn der Tunnel aufgebaut wurde
• SSH-Port verlegen (sollte man eh bei jedem Server tun)
• tmp-Verzeichnis sollte von einem Remote-Server (z.B. Rootserver) kommen und noexec gemountet werden, per Default haben EC2-Instanzen keine extra tmp-Partition
• Updates regelmässig machen und nach jedem Update ein neues AMI erstellen
• sobald ein Reboot notwendig ist immer das zuletzt erstellte AMI booten, keinen normalen Reboot machen

Naja… es gäbe noch einiges mehr, das man erwähnen könnte, aber ich brauch jetzt erstmal eine Tüte Schlaf. Wer Rechtschreibfehler findet, kann sie behalten.