Phishing mit Consent-Anforderung

Eine neue Masche von Phishing-Mails versucht ihnen einen Zustimmung abzuringen, damit eine App auf ihre Daten zugreifen kann. Je mehr Sie Dienste aus der Cloud nutzen, desto eher kennen Sie dieses Verhalten aber dass diese Weg von kriminellen Personen genutzt werden wird, war nur eine Frage der Zeit.

Wenn Sie bei der Gewährung von Zugriffsrechten von Apps nicht aufpassen, dann hat ein Malware-Service umfangreiche Rechte auf ihre Daten und kann in ihrem Namen auch mit anderen Personen interagieren.

Überlegen Sie, ob sie die Standardeinstellungen ihres Tenant verändern, um sicherer zu sein. Siehe "Gegenmaßnahme" am Ende der Seite.

Worum geht es?

Anwender nutzen immer mehr Dienste in der Cloud. Dazu zählt ihr Postfach in Exchange Online oder ihre Daten in OneDrive, Google Drive ebenso wie Zugänge zu sozialen Diensten wie Twitter, Facebook oder Schulungsplattformen wie edx.org. Die meisten Dienste erlauben ihnen natürlich, dass sie sich ein eigenes Benutzerkonto samt Kennwort anlegen aber sehr oft können Sie sich an einer Webseite in der Cloud auch mit ihrem "Twitter-Konto", "Facebook"-Konto Microsoft-Konto oder Google-Konto anmelden. Für Betreiber einer Webseite ist dieser Weg durchaus interessant, da viele Menschen sich scheuen, wieder ein Konto anzulegen und sich Kennworte zu merken.

Durch die Anmeldung mit einem Konto der großen Identity-Anbietern muss sich der Anwender kein weiteres Kennwort merken und der Anbieter erspart sich die Mühen für Kennwort-Rücksetzung, Benutzerverifikation etc. Es sieht aus wie eine Win-Win-Situation für beide Anbieter und den Anwender. Dass der Anwender damit natürlich mit jedem Zugriff auf den Service auch beim Identitätsprovider eine Spur hinterlässt ist unschön aber der Funktion geschuldet. Ebenso vertrauen sowohl der Dienstbetreiber und Sie dem Identitätsprovider, dass er nur legitimierten Personen ein entsprechendes Ticket ausstellen und niemand sonst so Zugriff auf ihre Daten erhält. Damit aber ein Dienstanbieter überhaupt hier mitspielen kann, müssen Sie als Anwender der Nutzung der Daten zustimmen. Sie sehen das bei einem Zugriff per Webbrowser als weiteren Dialog.

Eine Stufe weiter geht aber die Funktion, dass eine App oder ein Service nun mit ihren Berechtigungen auf ihre Daten zugreift. Auch das ist nicht mehr neu sondern wird immer mehr zum Standard. Früher haben Sie als Anwender sich mit "Benutzername" und "Kennwort" an einem Dienst legitimiert und auf die Daten zugegriffen. So konnte z.B. auch Thunderbird per IMAP4 auf ihre Exchange Postfach zugreifen. Die Problemstellung hier ist, dass die Kombination aus Benutzername und Kennwort auch für andere Zugänge und mit anderen Programmen genutzt werden könnte. Der Administrator hat so keine Kontrolle, welches Clients genutzt werden.

Für Funktionen von Conditional Access und Multi Faktor Authentifizierung (MFA) ist dieser Ansatz nicht leistungsfähig genug. Viele Cloud-Dienste nutzen daher die Funktion OAUTH2, mit der sich ein Anwender ein Ticket holt oder eine App das Recht bekommt, sich ein Ticket im Auftrag des Anwenders zu holen. Über den Weg können auch Dienstkonten auf Informationen zugreifen. Wenn der Administrator nun OAUTH fordert, dann müssen Sie oder der Administrator die Anwendung zulassen. Sie können das sehr einfach mit der Applikation "Graph Explorer" nachstellen.

Letztlich geben Sie damit aber einer Applikation das Recht, in ihrem Namen zu handeln. Es gibt viele Beispiele, an denen diese sogar wünschenswert ist:

  • CRM verwaltet ihre Termine
  • Archive exportiert Daten aus ihrem Postfach
  • VoiceMail nutzt ihr Exchange Postfach als Ablage
  • Bots verarbeiten Informationen in ihrem Postfach oder OneDrive
  • Outlook AddOns greifen auf ihre Daten auf dem Server zu
  • ...

Damit eine Applikation oder ein Service aber diese Funktion nutzen kann, muss Sie von ihnen als Anwender oder durch den Administrator für die Firma zugelassen werden.

Zustimmung einfordern

Eine App oder ein Service hat mehrere Wege, sich diese Berechtigungen zu erbeten. Klassischerweise nutzen Sie eine Applikation und diese versucht auf den Daten zugreifen. Das Datenbackup erkennt den Zugriff, der aber noch nicht erlaubt ist und leitet sie als Anwender auf eine Webseite des Identity-Providers, über welche Sie dann ihre Zustimmung erteilen. Als einfache Beispiel könnten Sie den Graph-Explorer auf https://developer.microsoft.com/en-us/graph/graph-explorer starten und sich mit ihrem Office 365 Konto anmelden. Sehr schnell sollten Sie einen Dialog sehen:

Sie müssen hier zustimmen und da Sie ja gerade eben auch auf Graph-Explorer waren, können Sie direkt einen Zusammenhang mit dieser Anfragen herstellen. Technisch ist es aber einfach eine Webseite, auf die Sie über die App umgeleitet wurden. Hier ist es die Adresse "https://login.microsoftonline.com/common/SAS/ProcessAuth" und wenn Sie den Request per Fiddler genauer anschauen, dann sehen Sie auch den Request und den Referer:

Der Refer enthält die ganzen Parameter inklusive der angeforderten Rechte. Da ich die App aber noch nicht zugelassen habe, wurde der Client von login.microsoftonline.com/common/oauth2 zu https://login.microsoftonline.com/common/SAS/ProcessAuth" weiter geleitet.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
   response_mode=fragment
   &nonce=graph_explorer
   &prompt=select_account
   &mkt=en-US
   &client_id=xxx-xxx-xxx-xxx-xxx
   &response_type=token
   &redirect_uri=https%3A%2F%2Fdeveloper.microsoft.com%2Fen-us%2Fgraph%2Fgraph-explorer
   &state=%7B%22client_id%22%3A%22de8bc8b5-d9f9-48b1-a8ad-b748da725064%22%2C%22network%22%....
   &scope=openid%20profile%20User.ReadWrite%20User.ReadBasic.All%20Sites.ReadWrite.All%20
          Contacts.ReadWrite%20People.Read%20Notes.ReadWrite.All%20Tasks.ReadWrite%20
          Mail.ReadWrite%20Files.ReadWrite.All%20Calendars.ReadWrite

Wenn ich hier dann zustimmen, dann hat das Programm die zugeteilten Rechte. Es gibt hier auch für Malware durchaus interessante Ansätze, z.B. auf das Postfach des Benutzers zuzugreifen oder Dateien in OneDrive zu verändern:

Die Berechtigungen können sogar noch weiter gehen, dass Sie das Programm den Zugriff auch ohne weitere Interaktion mit dem Anwender gewähren lässt. Dann hat eine App, die irgendwo gehostet wird, entsprechend Zugriff auf ihre Daten erhält. Diesen Zugriff gibt es nicht nur für Office 365 sondern auch andere Dienste.

In an illicit consent grant attack, the attacker creates an Azure-registered application that requests access to data such as contact information, email, or documents. The attacker then tricks an end user into granting that application consent to access their data either through a phishing attack, or by injecting illicit code into a trusted website. After the illicit application has been granted consent, it has account-level access to data without the need for an organizational account. Normal remediation steps, like resetting passwords for breached accounts or requiring Multi-Factor Authentication (MFA) on accounts, are not effective against this type of attack, since these are third-party applications and are external to the organization.
Quelle: Detect and Remediate Illicit Consent Grants https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide

Im Grunde ist es ja wünschenswert, wenn eine Applikation die benötigten Berechtigungen beim Benutzer oder Administrator anfordert und dieser dann Zustimmen kann. Allerdings darf der Benutzer und erst recht nicht der Administrator auf kriminelle Anfragen hereinfallen. Als Administrator können sie zumindest im AzureAD einstellen, dass ein Benutzer selbst keinen Consent erteilen darf.

Bei der Basiseinrichtung (Checkliste Tenant Einrichtung) eines Tenant stelle ich die Funktion erst einmal ab, dass Benutzer se.bst einen Consent erteilen können.

Consent prüfen

Mit einem passenden Konto können Sie sehr schnell mal prüfen, wem Sie welche Rechte bereits wissentlich oder unwissentlich eingeräumt haben. Ich bin sicher, dass bei den meisten Anwendern hier die ein oder andere App erscheint.

Vielleicht haben die die Zeit nun genutzt, einige alte Apps auch mal wieder zu löschen.

Mail mit Authorize-Link

Genauso, wie wie Dienste aus der Cloud nutzen, nimmt auch die Zusammenarbeite mit der Cloud zu. Fast tägliche komme ich Mails von anderen Firmen, dass ich eingeladen werden. Das kann ein Team in einer anderen Firma sein, eine per OneDrive freigegebene Datei oder ein Link auf ein Dokument, welches aus "Sicherheitsgründen" leider nicht per Mail zugestellt wird und ich mir das bitte abholen soll. In allen Fällen ist es eine perfekt aussehende Mail des angeblichen Absenders, der ihnen z.B. Zugriff auf sein OneDrive, Google-Drive oder Dropbox gewährt.

Der Anwender ist hier natürlich versucht, dann auf den Link zu klicken und natürlich glaubt er den nächsten Dialog zu kennen. Er erwartet natürlich, dass er sich irgendwie authentifizieren muss.

Aber manchmal ist der Anwender schon an dem Dienst angemeldet und dann kommt kein Authentifizierungsdialog. Bei einem Phishing-Versuch kommt dann direkt die "Consent"-Abfrage, die ein Anwender aber zu leicht mit einer allgemeinen Rückfrage verwechseln kann und vorschnell auf "Zulassen" klickt:

Bei OneDrive und Office 365 sieht es ähnlich aus. die URL bei Google sieht dabei wie folgt aus:

https://accounts.google.com/signin/oauth/oauthchooseaccount?client_id=xxxxx.apps.googleusercontent.com
   &as=xxxxx-xxxx
   &nosignup=1
   &destination=http%3A%2F%2F127.0.0.1%3A18313
   &approval_state=xxxxxxxx
   &oauthgdpr=1
   &oauthriskyscope=1
   &delegation=1
   &xsrfsig=xxxx-xxxx
   &flowName=GeneralOAuthFlow

Eine URL bei Facebook sieht ähnlich aus:

https://www.facebook.com/login.php?skip_api_login=1
   &api_key=1518363378406228
   &kid_directed_site=0
   &app_id=1518363378406228
   &signed_next=1
   &next=https%3A%2F%2Fwww.facebook.com%2Fv3.2%2Fdialog%2Foauth%3Freturn_scopes%3Dtrue%26
         redirect_uri%3Dhttps%253A%252F%252Fcourses.edx.org%252Fauth%252Fcomplete%252Ffacebook%252F%26state%xxx%26
         client_id%xxx%26ret%3Dlogin%26fbapp_pres%3D0%26logger_id%xxx-xx-xx-xx-xxx
   &cancel_url=https%3A%2F%2Fcourses.edx.org%2Fauth%2Fcomplete%2Ffacebook%2F%3Ferror%3Daccess_denied%26
         error_code%3D200%26error_description%3DPermissions%2Berror%26error_reason%3Duser_denied%26state%xxx%23_%3D_
   &display=page
   &locale=de_DE
&pl_dbl=0

Genauso einfach wie Anwender heute schadhafte Office-Anlagen öffnen und die Makros aktivieren, werden Sie auch solche Dialoge einfach abnicken. Der Schaden ist aber je nach erteilter Berechtigung sehr viel höher, denn als Firma können sie den Fremdzugriff auf die Cloud nicht auf den lokalen Clients nachvollziehen. Kein Virenscanner, SIEM-System oder Firewall kann einen Missbrauch erkennen, denn er passiert gar nicht in ihrem Netzwerk.

Der Anwender hat einer App, die irgendwo gehostet werden kann, das Recht zum "Zugriff als Benutzer" eingeräumt und der Angreifer kann in aller Ruhe sich als Anwender in dessen Daten tummeln. Im günstigsten Fall verschlüsselt/löscht dieser die Daten um einen schnellen Gewinn zu erzielen. Perfider aber in den richtigen Kreisen lohnender ist eine selektive Veränderung von Inhalten, z.B. Kalkulationstabellen.

Aber auch der Zugriff auf Postfachdaten und Kontakte ist immer noch lohnend, auch wenn der Versand von Mails als Benutzer in die Welt gar nicht mehr so erfolgsversprechend ist. Eine Ausweitung des Angriffs durch individuell zugeschneiderte Mails an Kollegen ist hier das größere Risiko.

Consent für App Zugriff

Das folgende Beispiel zeigt, dass eine Application nicht nur die Berechtigung zum Zugriff durch den Anwender anfordern kann, sondern auch eigenständige Zugriffe angefragt werden.

Die Webseite "Credly" (Teil des Schulungsanbieters PearsonVue) verteilt gewisse Auszeichnungen (Badges) an Teilnehmer, die so ihre Kenntnisse anzeigen können. Über Sinn/Unsinn machen Sie sich bitte getrennt ihre Gedanken. Aber möchten Sie, dass dieser Service auch ohne ihre aktive Mithilfe, z.B. durch den Besuch der Webseite, auf ihre Profildaten zugreift um diese zu nutzen? Aus Sicht des Anbieters kann es ja interessant sein, immer mal wieder zu prüfen, ob ihre Daten noch aktuell sind. Aber sie sollten das schon unterscheiden können. Leider können Sie hier nicht sehen, was genau "read your profile" bedeutet. Ist es nur Vorname, Nachname, Adresse oder vielleicht auch Alter, Geburtsdatum, private Rufnummern, Mobilfunk? Der Zugriff auf microsoft.com/consent zeigt die beiden Rechte aber ich kann sie nur alle oder nichts wegnehmen:

Zudem habe ich die App hier definitiv einige Tage nicht genutzt und dennoch listet Microsoft auf, dass heute ein Zugriff erfolgt ist. Ich stelle mir grade vor, wie wertvoll "aktuelle" Daten sind.

Variante mit Fake-URL

Eine Abwandlung des Angriffs ist natürlich eine Umleitung auf eine vom Angreifer gehostete Webseite, die einfach nur so aussieht wie eine Anmeldeseite von Facebook, Google, Microsoft, Twitter etc. Viele Tools starten den Anmeldedialog nämlich gar nicht in einem eigenen Browser sondern betten diese in ihrem Fenster mit ein. Damit kann der Anwender die angesprochene URL kaum oder gar nicht sehen und muss. So erfolgt die Anmeldung an Vimeo in der Software "Camtasia Studio" in einem kleinen Fenster ohne Hinweis auf die URL.

Theoretisch könnte der Inhalt von überall kommen und das Kennwort damit abgefischt werden. Das sind natürlich auch wieder handfeste Argumente für MFA oder sogar "Password Less Authentication". Wenn ich mein Kennwort nicht eingeben muss, weil ich auf einem anderen Gerät die Anmeldung bestätigen muss oder einen weiteren Faktor benötige, dann ist die Offenlegung eines Kennworts zwar weiterhin ein Grund dieses zu ändern aber eben nicht gleich ein offenes Tor für einen Angreifer.

Gegenmaßnahmen

Auch hier gibt es keinen 100%-Schutz aber die ein der anderen Schutzvorkehrungen sind durchaus möglich:

  • User Awareness
    Man kann es einfach nicht oft genug wiederholen, dass die Sensibilisierung der Anwender der wichtigste Baustein einer Schutzstrategie ist. Das ist zwar leichter gesagt als getan, zeitaufwändig und muss auch immer wieder wiederholt werden aber der Benutzer ist die Schwachstelle und es gibt sehr viele unterschiedliche Angriffsszenarien.
  • Consent-URLs blocken
    Damit der Anwender den Fehler begehen kann, muss die Mail mit der falschen URL beim Anwender ankommen. Die Content-URLs sind für die vier großen Identity-Provider, die genutzt werden, aber recht einfach zu erkennen und könnten auf einem Spamfilter unschädlich gemacht werden. Aber auch der Zugriff von intern per Browser auf diese URL könnte ein Proxy-Server gezielt blockieren da auch die Applikation in der URL enthalten ist. Eine Firma könnte also eine Allowlist pflegen.
    Das hilft aber nicht gegen die Fake-URL Variante, bei der der Anwender nur eine Phsihing-Webseite sieht und das Kennwort sowieso in Klartext eingibt.
  • Office 365 User Consent unterbinden
    Bei Office 365 können Sie als Administrator im Azure-Portal steuern, ob Anwender selbst einen "Consent" erteilen dürfen. Das ist zumindest Richtung Office 365-Dienst eine sehr sicherer Weg, der aber leider nicht "Default" ist. Den Punkt habe ich aber schon länger in meiner Checkliste Tenant Einrichtung aufgenommen. Das bedeutet aber auch, dass immer ein Administrator erst eine App erlauben muss, ehe die Benutzer damit arbeiten.

    Hier sehen Sie aber auch schon eine Funktion, dass es bald ein Vieraugen-Prinzip geben wird, bei der ein Benutzer eine Anforderung einreicht, die dann ein Administrator final bestätigt.
  • Reporting
    Mit dem Schwerpunkt auf Office 365 und Azure können Sie natürlich Berichte erhalten, welcher Benutzer welche App berechtigt hat und daraus ihre Rückschlüsse ziehen. Wenn Sie also nicht direkt den "User-Consent" unterbinden wollen, dann wäre ein Change Auditing hier ratsam. Allerdings ist es natürlich immer zu spät, wenn es wirklich mal eine bösartige App geschafft hat

Microsoft beschreibt die Office 365 Einstellungen aber auch selbst recht ausführlich

Azure Schutz

Microsoft hat Ende Nov 2020 auch den Schutz noch einmal erhöht. Wenn Sie eine App in Azure veröffentlichen, die dann von anderen Anwendern in ihrem Tenant aber auch in anderen Tenants genutzt werden soll, dann müssen sie diese verifizieren lassen.


Quelle: https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationMenuBlade/Branding/appId/<guid der app>/isMSAApp/

Die Verifikation erfolgt mit einer Verknüpfung zur einer "Microsoft Partner Network ID" (MPN ID), hinter der sich eine Firma oder Person mit Geschäftsbeziehung zu Microsoft verbindet. Es wird damit zumindest schon einmal erschwert, mal schnell über eine Azure Trial-Installation eine bösartige App in Azure bereitzustellen und per Phishing-Mail von anderen Anwendern eine Zustimmung zum Datenzugriff zu erhalten.

Ein normaler Anwender kann hier nicht mehr "zustimmen". In dem Fall muss ein Administrator den "Consent" erteilen. Der Anwender sieht folgende Information:

Hier muss dann ein Administrator sich anmelden und den Zugriff gewähren. Das basiert natürlich auf der Hoffnung, dass ein Administrator wohl weiß, was er tut und sich vorher über die berechtigten Gründe und die Vertrauenswürdigkeit der App vergewissert hat

Proof of Concept

Ich werde keinen Beispielcode veröffentlichen, um genau so eine Lücke zu nutzen. Aber wenn Sie z.B. den Code auf Get-O365Usage betrachten, dann wissen sie, wie sie z.B. ein PowerShell-Script mit einer App-ID und einem Secret ausstatten können, damit sich die App gegenüber Office 365 identifiziert. Dann muss ihr Skript nur noch z.B. Mails lesen und senden und sie jubeln dem Ziel eine Consent-URL unter, mit der er genau diesem Skript die erforderlichen Rechte gibt. Ich habe aber mal eine App "MSXFAQ ConsentSpam" angelegt.

Ich muss dann nur noch die Rechte eintragen, die diese App benötigt:

Und dann eine passende Consent-URL dem Anwender unterschieben

Allerdings wird so ein Vorgehen zumindest bei Office 365 von Microsoft deutlich erschwert, denn Sie müssen ihre App ja erst im AzureAD veröffentlichen. Sie müssten also schon einen Tenant oder eine Azure-Subscription einrichten, bei der Microsoft zumindest eine rudimentäre Identitätsprüfung durchführt. Damit wird der Einsatz hier schon etwas erschwert.

Keinen Schutz seitens Azure können Sie aber erwarten, wenn eine Malware z.B. ihr Google Konto oder einen anderen Dienst ins Visier nimmt, der einer Anmeldung durch Facebook, Twitter, Google oder "Microsoft Konto" vertraut. Hier haben Sie als Administrator keine Möglichkeit für ihre sowieso nicht definierte Firma und deren Mitarbeiter eine Nutzung der Anmeldedaten zu unterbinden.

Weitere Links