Cloud für Unternehmen: Typische Angriffe und wie Sie sich schützen (2/4)
OAuth-Phishing, Password Spraying und andere Cloud-optimierte Angriffstechniken sind erstaunlich effizient. Nur wer sie kennt, kann sich schützen.
- Inés Atug
- Manuel Atug
Die Autoren dieser Serie zu "Cloud für Unternehmen" begleiten und analysieren seit vielen Jahren Cloud-Projekte. Im ersten Teil erklärten sie die typischen Fehler und wie man diese vermeidet. Jetzt geht es darum, welchen neuen oder zumindest deutlich vergrößerten Gefahren man sich im Rahmen einer verstärkten Nutzung von Cloud-Diensten aussetzt. Und natürlich wie man sich davor schützen kann.
Die Autoren bereiten den Inhalt der kompletten Serie auch gezielt für Administratoren, IT- und Datenschutzverantwortliche in einem heise-Security-Webinar auf: In die Cloud – aber sicher
Daten in der Cloud wecken die Begehrlichkeiten der Angreifer. Denn im Gegensatz zu den bisher im internen Netzwerk – durch mehrere Sicherheitsringe geschützten – scheinen diese wolkigen Daten in erreichbarer Nähe zu liegen. Doch auch die Infrastruktur selbst und insbesondere die Rechenressourcen sind ein veritables Ziel für Angreifer.
Angriffe auf Cloud-Dienste beginnen häufig damit, dass der Angreifer versucht, die Rechte von Personen, Rollen oder Diensten zu erlangen – im Jargon heißt das: den sogenannten Identitäts-Perimeter zu durchdringen. Damit hat er dann Zugriff auf Daten und/oder Management-Funktionen, die er für seine Zwecke missbrauchen kann.
Die Techniken der Angreifer sind nicht grundsätzlich neu. Sie basieren auf bereits bekannten Mustern. So ist es weiterhin der Benutzer oder Administrator, der in einem glaubhaften Kontext nach Benutzerdaten oder dem Gewähren von Berechtigungen gefragt wird. Auch die Verwendung von Passwörtern aus einem früheren Datenabfluss mit Zugangsdaten oder die Verwendung versehentlich veröffentlichter Access Keys, gehören zum bekannten Vorgehen. Doch bei Cloud-Konten haben es die Angreifer oftmals viel leichter.
Denn den Anwendern fehlt es häufig noch an spezifischem Wissen um die konkreten Angriffsszenarien und wie man sich davor schützt. Vorhandene und vom Cloud-Anbieter integrierte Sicherheitsmechanismen werden oft gar nicht oder unzureichend verwendet.
Password Spraying
Es gibt verschiedene Techniken, Zugangspasswörter systematisch durchzuprobieren. Bei einer Brute-Force-Attacke probiert der Angreifer zu einem Benutzerkonto einfach stumpf alle möglichen Passwörter durch. Beim Passwort Spraying hingegen versucht er, mit wenigen, häufig verwendeten Passwörtern eine große Anzahl von Konten durchzuprobieren. Das erweist sich in vielen Fällen als effizienter als Brute Force.
Denn in der Regel sind gegen Brute-Force-Angriffe Sicherheitsmechanismen implementiert. Mehrfache Fehleingabe des Passworts führt im einfachsten Fall dazu, dass das Konto vorübergehend gesperrt wird. Bessere Verfahren sorgen dafür, dass die Neueingabe erst nach einer Frist wieder möglich ist, die sich mit jedem Versuch verdoppelt und so den Angriff exponentiell verlangsamt. Sogenannte Tar-Pits (Teergruben) bremsen den Angreifer noch raffinierter aus. Da bekommt er nämlich keine Fehlermeldung, sondern muss einfach immer länger auf das Ergebnis seines Login-Versuchs warten.
Password Spraying umgeht all diese Schutzmechanismen, da der Angreifer pro Konto nur wenige Versuche startet. Man kann sie eigentlich nur über das Monitoring erkennen. In einem solchen Fall sollte zuerst überprüft werden, ob der Angriff erfolgreich war und ein erfolgreicher Login in den Log-Daten enthalten ist. Ein erster Schritt zu mehr Sicherheit in diesem Bereich ist der Versuch, den Einsatz von leicht zu erratenden Passwörtern zu verhindern. Hierzu bieten viele Cloud-Anbieter entsprechende Möglichkeiten wie die Kennwortsperrliste, die man in Azure Active Directory aktivieren kann.
Wer jedoch die Qualität seiner Schutzmaßnahmen auf ein neues Niveau heben will, kommt um neue Konzepte zum Schutz der (Cloud-)Identitäten nicht herum. Die Rede ist von Multifaktor-Authentifizierung (MFA) etwa mit Smartcards, App-Tokens (Time based One Time Passwords, TOTP) oder auch FIDO2. Deren Einführung sorgt dafür, dass ganze Klassen von möglichen Angriffen wie klassisches Phishing, Brute Force, Password Spraying und Passwort-Diebstahl durch Trojaner nicht nur schwerer werden sondern technisch nicht mehr möglich sind. Und das ist die Form von Schutz, die man haben will.
OAuth-Angriffe
Allerdings darf man nicht den Fehler machen, von Multifaktor-Authentizierung Wunder zu erwarten. Denn insbesondere in Cloud-Szenarien gibt es weitere Angriffsflächen für Identitätsdiebstahl. So erfolgen in vielen Cloud-Szenarien die Authentifizierung und die Autorisierung von Zugriffen über OAuth.
OAuth ermöglicht etwa Webdiensten oder Apps einen Zugriff, ohne dass diese jedes Mal nach dem Passwort oder einem zweiten Faktor fragen müssen. Dazu erhält die App ein spezielles OAuth-Token, mit dem sie sich gegenüber dem Dienst ausweisen kann. Da fragt dann eben der Kalender der Google Suite oder von Office 365 nach, ob der zum Finden eines Termins eingesetzte Dienst Doodle diesen dann auch eintragen darf. Bejaht das der Nutzer, erhält Doodle die angefragten Zugriffsrechte in Form eines OAuth-Tokens. Die Details hinter den Kulissen erklärt der Artikel Wie man OAuth 2.0 richtig verwendet.
(Bild: Phishlabs )
Diese Tokens sind zwar zu lang und komplex, als dass sie sich knacken lassen, aber man kann sie durchaus abphishen. Dabei versenden die Angreifer an ausgewählte Mitarbeiter der Firma beispielsweise Mails, in denen sie Einschnitte im Budget ankündigen und dazu auf ein Excel-Dokument des CFO verweisen, das vermeintlich über SharePoint Online geteilt wird. Doch in Wirklichkeit verweist der Link auf eine App der Betrüger, die dann nach Zugriffsberechtigungen fragt.
Wenn der Empfänger das verlinkte Dokument der Phishing-Mail öffnet, wird er aufgefordert, sich am Cloud-Dienst anzumelden. Dies ist auch bei einem echten Link üblich, über den ein Dokument via OneDrive geteilt wurde. Doch als nächstes wird der Anwender dann abweichend aufgefordert, Berechtigungen an eine App etwa mit dem Namen "Budgetmanagement O365" zu vergeben. Das ist in diesem Kontext zwar verräterisch, aber der Anwender hat ähnliche Anfragen in anderem Kontext bereits gesehen und klickt häufig genug auf OK.
Systematisch ausgenutzt
Mit dem danach ausgestellten OAuth-Token kann der Angreifer eigenständig mit den Rechten des Nutzers auf die Cloud-Umgebung zugreifen – auch zu einem späteren Zeitpunkt. Es wird dabei keine Schwachstelle im OAuth-Protokoll ausgenutzt. Stattdessen wird der Benutzer dazu verleitet – wie in diesem Beispiel über eine Spear-Phishing-Mail – Rechte an die App des Angreifers zu vergeben, ohne dass ihm dies bewusst ist.
Mittlerweile kommt OAuth vorwiegend in der Version 2.0 zum Einsatz, die in Bezug auf Sicherheit deutliche Fortschritte bringt. Doch die geschilderte Phishing-Problematik schafft es leider nicht aus der Welt. Diese OAuth-Angriffe nehmen deutlich zu und haben etwa Microsoft bereits zu einer öffentlichen Warnung veranlasst. Auch uns sind mehrere Fälle bekannt, in denen Angreifer OAuth-Phishing einsetzten, um Zugriff auf die Google Suite oder Office 365 zu erlangen. Aktuell besonders beliebt sind Phishing-Mails mit Bezug zu COVID-19.
Typische Angreifer nutzen die gewonnenen Zugriffsrechte dann sehr besonnen und systematisch aus. Sie analysieren zunächst das E-Mail-Konto beziehungsweise dessen Inhalt, um unter anderem erfolgversprechende Betrugsszenarien auszuarbeiten. Um Mails mitlesen zu können und vor dem eigentlichen Account-Inhaber zu verstecken, richten die Eindringlinge oft automatische Weiterleitungsregeln ein. Da eine Weiterleitung an ein externes Ziel sehr auffällig wäre und unter Umständen im Monitoring auffällt, greifen sie zu einem Trick. Sie richten innerhalb des Kontos entweder einen neuen, unauffälligen Mail-Ordner ein oder benutzen einen alten, lange nicht genutzten Ordner und verschieben bestimmte ankommende Mails sofort dort hin.
Dann wird etwa an einen Kunden, der demnächst einen größeren Betrag zu bezahlen hat, eine Mail über eine Änderung der Bankverbindung geschickt. Der Angreifer kann die vorsorgliche Nachfrage zur Kontoänderung beantworten, ohne dass der Eigentümer des Kontos dies zu sehen bekommt. Landet das Geld auf dem Konto des Angreifers transferiert er es sofort weiter und es verschwindet unwiederbringlich in dessen Geldwaschanlage.
Wer jetzt glaubt, in seiner Firma ginge das so nicht, sollte sich nicht allzu sehr in Sicherheit wiegen. Erfahrene Cybercrime-Banden sind überaus einfallsreich und finden fast immer eine Möglichkeit, die erlangten Zugriffsrechte zu Geld zu machen. Im Weiteren werden wir noch andere Angriffsszenarien vorstellen.
Zu beachten ist, dass Multifaktor-Authentifizierung vor solchen OAuth-Angriffen nicht schützt. Darüber hinaus genügt nach einem erfolgreichen Einbruch auch das Ändern des Passworts nicht, solange dabei nicht auch alle zuvor erteilten Berechtigungen zurückgesetzt werden. Im Zweifelsfall muss man der App beziehungsweise dem Dienst manuell die Rechte entziehen, was im Hintergrund das ausgestellte Token entwertet.
Zum Schutz vor OAuth-Phishing muss man die Anwender durch Schulungen auf solche Angriffe vorbereiten, damit sie die typischen Warnungen erkennen und richtig interpretieren. Microsoft erklärt in einem kurzen Tutorial, wie Admins gefährliche OAuth-Apps aufspüren können. Bei manchen Cloud-Anbietern kann man auch ein Whitelisting von zugelassenen Drittanbieter-Apps einrichten. Alternativ kann man OAuth-Apps auch verbieten, wenn man diese selber im Unternehmen nicht einsetzt.
Gekommen um zu Bleiben
Häufig ist ein gekapertes Konto nur der erste Schritt zu weitreichenderen Aktivitäten, für die sich der Angreifer dauerhaft in der Cloud-Umgebung einnistet. Hierzu hat er verschiedene Möglichkeiten. Die offensichtlichste: Wenn die entsprechenden Berechtigungen vorhanden sind, kann er einen neuen Benutzer anlegen. Doch das Anlegen neuer Benutzerkonten wird meistens überwacht und so ist die Gefahr hoch, dass er entdeckt wird.
Doch es gibt eine Vielzahl von weniger offensichtlichen Nischen, die das betroffene Unternehmen vielleicht weniger konsequent überwacht. So kann man in Amazons AWS mit dem Dienst AWS Security Token Service (STS) temporäre Berechtigungen für bis zu 36 Stunden vergeben. Damit kann sich der Angreifer eine Art Hintertür einrichten, die ihm zumindest kurzfristig auch dann noch Zugriff gewährt, wenn das kompromittierte Session-Token gelöscht wurde.
Anderes Beispiel einer schwer zu entdeckenden Hintertür gefällig? Sofern er sich in Microsoft Azure ein Konto eines Global Administrators oder mit Application-Administrator-Rolle ergattert hat, kann der Angreifer einer bestehenden Applikation Berechtigungen hinzuzufügen und dann dem zugehörigen Service Principal ein weiteres Passwort oder Zertifikat verpassen.
Und was macht der Angreifer, wenn ihm die für die weiteren Aktivitäten benötigten Rechte fehlen? Er greift beispielsweise erneut zum Phishing. Immerhin kommen seine Mails ja jetzt sogar von einer internen E-Mail-Adresse; er kann dabei auf existierende Kommunikation zurückgreifen und sogar auf Rückfragen antworten. Mit Hilfe geschickter Umleitungen bekommt der echte Konto-Inhaber davon nichts mit. Das sind beste Voraussetzungen, sich zusätzliche Rechte oder vielleicht eine eigene VM in der Cloud zu besorgen. Oder einem Administrator ein OAuth-Token abzuluchsen.
Die Cloud als eigene Goldmine
Apropos Gefahr von Innen. Ein oftmals unterschätztes Angriffsszenario ist der sogenannte Innentäter. Uns sind mehrere Fälle bekannt, bei denen unzufriedene Mitarbeiter eine überaus unrühmliche Rolle gespielt haben. Ein auf wahren Begebenheiten beruhendes Missbrauchsszenario sieht dann etwa so aus: Eine unzufriedene Administratorin - wir nennen sie mal Rita Müller - richtet sich aus Frust über unbezahlte Überstunden einen kleinen Nebenverdienst ein.
Im Rahmen des neuen Cloud-Projekts erstellt Müller dazu ein paar zusätzliche VM-Instanzen in nicht überwachten Regionen des Cloud-Kontos. Auf denen installiert sie Linux und XMRig, eine Software zum Schürfen von Monero. Diese Kryptowährung hat sehr weitreichende Funktionen zum Schutz der Privatsphäre ihrer Nutzer, sodass sich Geldeingänge und Transaktionen so gut wie nie konkreten Personen zuordnen lassen. Das Gastsystem der VM passt sie so an, dass es keine verräterischen Protokolldaten gibt.
Da Müller das Schürfen bereits kurz nach dem Start des Cloud-Projekts in Betrieb nimmt, fallen die erhöhten Kosten aufgrund fehlender Vergleichswerte lange Zeit nicht als Anomalität auf und Müller erschürft sich auf Kosten ihres Arbeitgebers beiläufig ein erkleckliches Nebeneinkommen. Erst bei einem Penetrationstest fallen die im Schatten betriebenen virtuellen Maschinen auf. Nach einer forensischen Analyse, in der die Indizien und Beweise alle klar und deutlich auf Müller deuten, wird dieser fristlos gekündigt. Doch der Arbeitgeber stellt sich danach natürlich die Frage, ob er die Kryptomine bereits früher hätte entdecken oder gar verhindern können.
Mit lückenlosem Monitoring und mit dem Einsatz globaler Regeln, die die Aktivierung von Ressourcen in nicht gewollten Regionen unterbinden, wäre das Vorgehen von Rita Müller bereits vorher aufgefallen. Dazu gehört etwa das Etablieren eines geregelten Deployments von Cloud-Ressourcen mit Quality Gates und einem Freigabeprozess nach dem 4-Augen Prinzip. Dabei sollte die zweite Person nicht selbst am Deployment-Prozess beteiligt sein.
Die Implementierung von globalen Regeln und das Monitoring sind auch der Schlüssel zum Entdecken anderer Angriffe auf Cloud-Ressourcen. Etwa wenn wie bei der Los Angeles Times Angreifer in Webseiten den Crypto-Miner von Coinhive einschleusen. Der schürfte dann auf dem Rechner der Webseiten-Besucher heimlich im Hintergrund. Ursache war eine fehlerhafte Konfiguration der AWS S3 Buckets, in denen die Webseiten abgelegt waren. Mit Hilfe von AWS Config hätte dieser Konfigurationsfehler der LA Times leicht entdeckt werden können, wenn dort eine Regel zum Verbot öffentlich schreibbarer S3-Buckets konfiguriert worden wäre.
Fazit und Ausblick
Die aufgeführten Beispiele zeigen bereits mehrere Kernbestandteile eines sicheren Cloud-Konzepts:
- verbessertes Identitäts-Management am besten mit MFA
- minimale Rechte für Nutzer und Applikationen
- Schulung der Mitarbeiter, um sie auf die sicher kommenden Angriffe vorzubereiten
- lückenloses Monitoring und Überwachung der Cloud-Ressourcen
- Einsatz von globalen Sicherheitsregeln, um Mindestsicherheitsstandards durchzusetzen
Und am besten führt man das ein, bevor die Cloud-Ressourcen in den Produktionsbetrieb gehen. Wie man das am besten konkretisiert und umsetzt, erklärt der nächste Artikel der Serie "Cloud für Unternehmen": Eckpunkte eines sicheren Einstiegs-Konzepts. Darüber hinaus beantworten die Autoren im heise-Security-Webinar In die Cloud - aber sicher, das sich speziell an IT- und Sicherheitsverantwortliche richtet, auch gerne konkrete Fragen.
(ju)
