Um sich vor einem Angriff schützen zu können, ist es essentiell zu verstehen, wie Angreifer vorgehen und welche Schwachstellen und Lücken sie ausnutzen. Nur wer die Techniken der Angreifer kennt, kann sich selber effektiv davor schützen. Kürzlich haben wir bei einem virtuellen Event einen Live Cloud-Hack durchgeführt. Für alle, die nicht dabei sein konnten, möchte ich in diesem Post zeigen, wie das funktioniert.


Am Anfang steht die Informationsbeschaffung

Die im Allgemeinen bekannteste Form von Cloud sind die SaaS Services wie Dropbox, Salesforce und Office365. Der nächste Schritt Richtung Infrastruktur geht über PaaS (z.B. Datenbank Services) hin zu IaaS, wo man von einzelnen VM’s hin zu komplexen VPCs (Virtual Private Clouds) alles betreiben kann, was man schon aus einem On-Premises Datacenter kennt. Inzwischen weit verbreitet sind auch Container Lösungen, vor allem Kubernetes sowie auch Serverless (wie z.B. Lambda Funktionen). 

Bei unserem Cloud-Hack haben wir uns vor allem auf IaaS, PaaS, Container und Serverless konzentriert und SaaS nicht mit einbezogen. Als Basis haben wir die Cloud ATT&CK Matrix von Mitre benutzt:

Quellenangabe: attack.mitre.org/matrices/enterprise/cloud/, abgerufen am 24.06.2020

Aber als wirklichen Einstiegspunkt eignet sich die PRE-ATT&CK Matrix sogar noch besser:

Quellenangabe: attack.mitre.org/matrices/enterprise/cloud/, abgerufen am 24.06.2020

Hier sieht man bei den Taktiken für “Technical Information Gathering” wie man Informationen über Firmen und deren Infrastruktur beschaffen kann, ob diese On-Prem oder in der Cloud sind, spielt in diesem Schritt noch keine grosse Rolle.

Einige erste, interessante Schritte sind:

    • Acquire OSINT data sets and information
      OSINT oder Open source intelligence sind Informationen, die man über öffentliche Quellen bekommt. Dies kann alles das sein, was man über Google herausbekommt, aber es gibt auch viele spezialisierte Tools, die viel tiefer gehen. Mit einem Tool wie Spiderfoot, kann man sehr einfach IP-Adressen, Domain-Namen, E-Mail-Adressen, Usernamen, Subnetze, ASN’s usw. von einem potenziellen Target herausfinden. Weitere gute Quellen sind SHODAN, oder die Datenbank von HaveIBeenPwned.
    • Conduct active and/or passive scanning
      Wenn man die IP ranges kennt, die von einem Unternehmen benutzt werden, kann man diese scannen, um herauszufinden welche Server eingesetzt werden. Ein interessantes Tool sind DnsDumpster und MX Toolbox. Damit findet man schnell alle DNS-Server, MX Server, alle Subdomänen und auch die Information wo diese Webseiten gehostet sind. Shodan ist wohl das bekannteste Scanning Tool schlechthin und man kann in der dazugehörigen Datenbank passiv nach Informationen suchen (offene Ports, SSL Zertifikate, Webserver etc.).
    • Determine 3rd party infrastructure services
      In diesem Schritt will man herausfinden, ob die Applikationen in einem externen Datacenter gehostet sind und ob 3rd Party Services benutzt werden. Zudem will man herausfinden, ob Cloud Services eingesetzt werden und wenn ja, welche.
    • Determine firmware version
      Die Idee hier ist einfach herauszufinden, welche Firmware oder welche OS Version oder welche Software Version auf den Routern, Servern, Firewalls etc. läuft. Wenn eine neue Schwachstelle aufgedeckt wird (CVE-XXX), dann müssen die Unternehmen die betroffenen Systeme updaten. Dies kann in Grossunternehmen ziemlich lange dauern. Mit Shodan kann man gezielt nach bestimmten Versionen von Webservern (z.b. Apache oder NGINX) suchen, die eine bekannte Schwachstelle haben und noch nicht gepatcht wurden.

Ich werde hier nicht alle Techniken von ATT&CK durchgehen, aber man sollte sich bewusst sein, dass Angreifer und Verteidiger ähnliche Techniken und Taktiken einsetzen.

Alle diese Techniken zur Informationsbeschaffung sind natürlich auch auf Cloud-Umgebungen anzuwenden, aber oft gibt es noch zusätzliche, Cloud-spezifische Techniken die eingesetzt werden können. Gut bekannt dürfte die Suche nach offenen (public) S3 Buckets sein. Es gibt viele Tools, mit denen man schnell nach offenen S3 Buckets scannen kann (z.B. Burp, BucketDump etc.), aber einige funktionieren nicht mehr (Slurp, s3enum), denn AWS hat die darunterliegenden Verhaltensmuster bereits geändert (z.B. DNS enumeration).


An die Credentials gelangen – Credentials schützen

Wenn wir wieder auf die ATT&CK Cloud Matrix schauen, finden wir “Valid Accounts” als eine der Techniken um einen ersten Access auf die Cloud-Umgebung zu bekommen (Initial Access). Dies mag jetzt sehr banal klingen, ist aber ein sehr einfacher Weg und funktioniert leider auch sehr oft.  Auf diesem Link (attack.mitre.org/techniques/T1078/) findet man verschiedene Beispiele von Breaches, bei denen gestohlene Credentials benutzt wurden.

Credentials kann man auf verschiedensten Wegen bekommen, man kann sie z.B. auf einschlägigen Foren kaufen, oder man versucht durch Phishing auf einen Endpoint zu gelangen und benutzt die Logindaten dann um sich in die Cloud-Umgebung einzuloggen. Sich gegen diesen Angriffsvektor zu schützen, ist ziemlich einfach, meistens genügt es, eine Two-Factor Authentication (oder Multi-Factor Authentication – MFA) einzusetzen. Dies wird aus Usability Gründen oft nicht konsequent gemacht, ist für einen User aber nur eine Sache der Gewöhnung. Zusätzlich kann man auch einen sogenannten Conditional Access benutzen und dann ein MFA gezielt einzuschalten, wenn nötig. Conditional Access bedeutet, abzuklären woher der User kommt, der sich einloggen möchte. Dabei verifiziert man aus welcher Region der User kommt (Geolocation), aus welchem Netz er kommt (Homeoffice, Public Wi-Fi, Corporate Network), ob sein Endpoint gewisse Vorgaben erfüllt (kein Jailbreak auf dem Mobile, OS auf einem gewissen Stand) usw. Ein User in der HR Abteilung loggt sich aus Russland ein, er könnte ja in den Ferien sein, aber wenn er das noch ausserhalb der normalen Arbeitszeiten macht, dann ist das mindestens Verdächtig und dieser User sollte in so einem Fall gezwungen werden, sich über MFA anzumelden. Wenn seine Credentials (sein Username und Passwort) gestohlen wurden, sind die ohne MFA nutzlos. 


Über Schwachstellen zum Ziel

Ein oft benutzter Einstiegspunkt auf IaaS Umgebungen sind Services, die ungenügend sicher oder sogar falsch konfiguriert worden sind. Wie bereits bei der ATT&CK Cloud Matrix gesehen, wird oft nach bekannten Schwachstellen gesucht (Systeme die nicht gepatcht/upgedated wurden) aber schlecht konfigurierte Systeme sind ebenso interessant. Ein gutes Beispiel sind Server die mit SSH oder RDP offen vom Internet zugänglich sind. Kann so ein Server garantiert kompromittiert werden? Nein, natürlich nicht, aber es gibt sehr viele Schwachstellen und Exploits für SSH und RDP. Auch hier ist es relativ einfach, solche Fehlkonfigurationen zu identifizieren und zu korrigieren, und dies sollte kontinuierlich geschehen (eventuell sogar mit einer automatisierten Remediation). 


Fazit

Klar ist, viele Angriffsvektoren in Cloud-Umgebungen sind ähnlich wie die in On-Premises. In weiteren Blog-Beiträgen werde ich mehr auf die Cloud-spezifischeren Risiken eingehen.

Ich habe hier nur an der Oberfläche gekratzt. Wer sich in diesen Themen weiter vertiefen möchte, dem empfehle ich zuerst einmal, die Mitre ATT&CK Matrixen zu studieren. Ebenfalls kann man die Aufzeichnung unseres Hack the Cloud Events hier einsehen: