StrandHogg 2.0 ist eine gefährliche neue Android-Sicherheitslücke. Hier erfahren Sie, welche Auswirkungen es auf Benutzer haben kann und wie Entwickler ihre Apps davor schützen können.
Es ist 22:00 Uhr. Wissen Sie, wo sich Ihre Aktivitäten befinden? Es gibt eine neue Sicherheitslücke, die auf Millionen von Android-Geräten ausgenutzt werden kann, und sie ist auch ziemlich schlimm. Kurz gesagt ermöglicht dieser Designfehler einem Angreifer, seine eigene Aktivität (Seite) über der einer anderen App anzuzeigen, was den Benutzer möglicherweise dazu verleitet, seine privaten Daten preiszugeben. Die Sicherheitslücke trägt den Namen StrandHogg 2.0 und wurde kürzlich von bekannt gegeben Promon, ein norwegisches Sicherheitsunternehmen.
Die Schwachstelle StrandHogg 2.0 betrifft theoretisch alle Android-Geräte, auf denen Android-Versionen ab Honeycomb (3.0) und bis zu Android 9 Pie (9.0) laufen. Basierend auf Statistiken zur Verteilung der neuesten Android-Versionen, das bedeutet, dass Ungefähr 91,8 % aller Android-Geräte sind anfällig für StrandHogg 2.0
Promon war so freundlich, uns ihre Proof-of-Concept-App und ihren Quellcode zuzusenden, damit wir es bestmöglich nutzen können Erklären Sie, wie der Exploit funktioniert, warum er für Benutzer wichtig ist und wie Entwickler ihre Apps schützen können dagegen.
Wie es funktioniert
Angenommen, Sie verwenden Gmail und klicken auf einen Weblink. Wenn Sie den Bildschirm „Letzte Apps“ aufrufen, stellen Sie möglicherweise fest, dass sich die Webseite scheinbar „in“ Gmail befindet. In der Vorschau wird die Website angezeigt, das App-Symbol und der Name stammen jedoch weiterhin von Gmail. Dies geschieht, wenn eine App/Aktivität eine andere App/Aktivität in derselben Aufgabe startet. Stellen Sie sich nun vor, Sie hätten diesen Link nicht absichtlich geöffnet. Für Sie sieht es so aus, als wäre es nur ein Teil der Gmail-App. Dies ist das Verhalten, das StrandHogg 2.0 ausnutzt.
Wir müssen hier einige Details weglassen, aber hier erfahren Sie ungefähr, wie dieser Exploit funktioniert. Nehmen wir im Folgenden an, dass der Angreifer an die Gmail-Anmeldedaten des Benutzers gelangen möchte.
- Der Benutzer lädt eine bösartige App herunter (natürlich ohne zu wissen, dass sie bösartig ist) und öffnet sie.
- Im Hintergrund öffnet die App Gmail, fügt darüber eine ähnliche Anmeldeaktivität ein und startet dann eine weitere Aktivität.
- Der Benutzer öffnet Gmail und sieht etwas, das wie der Anmeldebildschirm von Gmail aussieht, in Wirklichkeit aber die Phishing-Aktivität des Angreifers ist.
Die letzte in Schritt 2 gestartete Aktivität kann alles sein, was Verdacht vermeidet. Die App könnte einen Absturz vortäuschen und zum Startbildschirm zurückkehren oder einfach ihre Hauptaktivität öffnen, als ob nichts passiert wäre. Das einzig Verdächtige, was der Benutzer sehen könnte, ist eine Reihe von Eröffnungsanimationen, wenn alle Aktivitäten gestartet werden. Das Schlimmste: Es sieht nicht einmal so aus, als wäre Gmail geöffnet.
Natürlich kann ein Angreifer mehr tun, als nur einen gefälschten Anmeldebildschirm anzuzeigen. Eine bösartige App könnte stattdessen eine Berechtigungsaufforderung anzeigen und den Benutzer dazu verleiten, unerwünschte Berechtigungen zu erteilen. Während das Anfordern spezieller Berechtigungen wie Barrierefreiheit den Benutzer misstrauisch machen könnte, kann mit etwas wie Speicherzugriff großer Schaden angerichtet werden.
Die technischen Teile
Dieser nächste Abschnitt bietet einen allgemeinen Überblick über die Funktionsweise von StrandHogg 2.0. Promon wird die vollständigen Details erst in einigen Monaten veröffentlichen, daher können wir nicht genau mitteilen, wie dieser Exploit implementiert wird. Es gibt jedoch einige technische Details, über die wir sprechen können.
Kurz gesagt: StrandHogg 2.0 kapert Androids Context.startActivities() API-Methode mit drei Absichten.
- Der erste Intent ist derjenige, der in unserem Beispiel Gmail startet. Es ist mit gekennzeichnet
Intent.FLAG_ACTIVITY_NEW_TASK. - Die zweite Absicht ist die böswillige. In unserem Beispiel handelt es sich um die Lookalike-Login-Aktivität. Diese Absicht hat keine Flags.
- Die dritte Absicht ist die Ablenkung. Dadurch wird sichergestellt, dass der Benutzer nicht misstrauisch ist, weil Gmail einfach zufällig geöffnet wird und nicht die App, auf die er getippt hat (d. h. die App, die den Angriff gestartet hat). Es ist mit gekennzeichnet
Intent.FLAG_ACTIVITY_NEW_TASK.
Alle diese Absichten werden dann in einem Array an den übergeben startActivities() Methode.
Das Fehlen von Flags im zweiten Intent ist hier der Schlüssel. Damit haben wir im Grunde nur das Gmail-Beispiel von oben nachgebildet. Die Aufgabe ist technisch gesehen die von Gmail, aber die oberste Aktivität ist die des Angreifers. Wenn der Benutzer dann auf das Startbildschirmsymbol von Gmail klickt, wird die Aktivität des Angreifers anstelle der von Gmail angezeigt.
Konzeptioneller Beweiß
Mit den Informationen, die Promon uns geschickt hat, konnten wir den Machbarkeitsnachweis nachbilden. Hier ist eine Bildschirmaufnahme eines Samsung Galaxy Note8 mit Android 9 Pie, die es in Aktion zeigt.
Techniken und Probleme zur Schadensbegrenzung
Nun wird es nicht wirklich funktionieren, das Obige einfach im Code zu replizieren. Es handelt sich nicht um ein vollständiges Beispiel, und es gibt noch ein paar andere Dinge, die ein Angreifer tun muss, damit es funktioniert, die wir nicht weitergeben können. Aber sie sind auf eigene Faust nicht besonders schwer zu erraten, und das ist einer der Gründe, warum dieser Angriff so gefährlich ist. StrandHogg 2.0 ist ein relativ einfach zu implementierender und schwer zu entschärfender Exploit.
Die Schadensbegrenzung kann nicht einfach darin bestehen, alle Apps, die sie verwenden, auf die schwarze Liste zu setzen startActivities(), da es viele legitime Verwendungsmöglichkeiten dafür gibt. Es ist auch sehr schwierig, einen Erkennungsalgorithmus dafür zu automatisieren. Böswillige Entwickler können alle möglichen Tricks anwenden, um ihre Implementierung von StrandHogg 2.0 für Dienste wie Google Play Protect effektiv unsichtbar zu machen. Bei StrandHogg 1.0 musste der Angreifer ein Attribut zur AndroidManifest.xml der Schad-App hinzufügen, das relativ leicht zu erkennen war. StrandHogg 2.0 hingegen funktioniert vollständig in Java/Kotlin.
Unter Berücksichtigung von Verschleierung, Reflektion und auch nur unterschiedlicher Codierungsstile erscheint es unpraktisch, eine App, die diesen Exploit ausnutzt, automatisch richtig zu erkennen. Darüber hinaus weiß ein Benutzer möglicherweise nicht einmal, ob er Opfer eines StrandHogg 2.0-Angriffs ist. Wenn Sie Gmail öffnen und den Anmeldebildschirm sehen, denken Sie möglicherweise, dass Ihre Sitzung abgelaufen ist, und geben Ihre Anmeldedaten ein, ohne darüber nachzudenken.
Als wir Google um eine Antwort baten, gab ein Sprecher die folgende Erklärung ab:
„Wir schätzen die Arbeit der Forscher und haben eine Lösung für das von ihnen identifizierte Problem veröffentlicht. Darüber hinaus erkennt und blockiert Google Play Protect schädliche Apps, einschließlich solcher, die diese Technik verwenden.“
Das klingt gut und hoffentlich hat es zumindest eine gewisse Wirkung gegen StrandHogg 2.0-Angriffe. Es ist jedoch erwähnenswert, dass Google Play Protect nicht Erkennen Sie unsere Proof-of-Concept-App auch nach einem manuellen Scan als bösartig.
Promon sagt, dass sie „haben keine echte Malware beobachtet, die die Schwachstelle StrandHogg 2.0 ausnutzt“, aber es gibt keine Garantie dafür, dass dies das erste Mal ist, dass der Exploit entdeckt wurde. Aus diesem Grund empfiehlt Promon den Entwicklern, ihre Apps durch die Festlegung der Launcher-Aktivitäten zu schützen launchMode Flag zu entweder singleTask oder singleInstance. Jedes dieser Flags verhindert die Task-Injection, worauf StrandHogg 2.0 angewiesen ist. Wenn Ihre Aktivität jedoch eines dieser Flags verwendet, kann dies zu Problemen mit bestimmten App-Abläufen führen und ist daher nicht immer wünschenswert.
Promon bewirbt auch sein eigenes Produkt „In-App Protection by Promon SHIELD“, das wie eine Bibliothek klingt die App-Entwickler implementieren können, um die Aufgaben im Prozess Ihrer App zu überwachen und auf Unregelmäßigkeiten zu prüfen Einfügungen. Da es keine wirklich wirksame Strategie zur Schadensbegrenzung für Entwickler oder Benutzer gibt, ist es sehr wichtig, dass die Hersteller den Patch implementieren, um das Problem so schnell wie möglich zu beheben.
Glücklicherweise befolgte Promon die Richtlinien zur verantwortungsvollen Offenlegung, bevor er diesen Exploit veröffentlichte (und Es ist immer noch nicht vollständig öffentlich – Promon wartet 90 Tage, bevor es vollständig offenlegt, wie StrandHogg 2.0 funktioniert funktioniert). Google hat seitdem Patches für diesen Exploit auf Android 8.0 Oreo, Android 8.1 Oreo und Android 9 Pie zurückportiert Android-Sicherheitspatch-Level (SPL) vom Mai 2020. Benutzer von Android 10 und höher sind nicht anfällig, obwohl wir nicht ganz sicher sind, warum das so ist. Es hat wahrscheinlich etwas mit den neuen Einschränkungen von Android 10 beim Starten von Aktivitäten und der Art und Weise zu tun, wie Google diese in den Aufgabenstapel integriert hat. Promon sagt, dass „auf Android 10 der Angriff völlig wirkungslos ist und die Aktivitäten entsprechend in verschiedene Aufgaben und in separate Aufgabenstapel aufgeteilt sind.“ adb shell dumpsys activity activities."
Wenn Ihr Gerätehersteller immer noch Sicherheitsupdates bereitstellt (lesen Sie mehr darüber). Hier erfahren Sie, wie der Sicherheitspatch-Prozess funktioniert), sollten Sie sie schnellstmöglich um ein Update bitten. Andernfalls müssen Sie nur vorsichtig sein, welche Apps Sie herunterladen und ausführen (obwohl Sie das sowieso tun sollten).
Weitere Details und Anwendungsfälle von StrandHogg 2.0 finden Sie im offizielle Ankündigung auf der Website von Promon. Für benutzerdefinierte ROM-Entwickler finden Sie die relevanten AOSP-Commits zur Verhinderung von StrandHogg 2.0-Angriffen Hier Und Hier.
Offenlegungszeitplan
Hier ist der Zeitplan für die Offenlegung, den Promon in seinem StandHogg 2.0-Dokument veröffentlicht hat:
- 4. Dezember 2019 – Problem an Google gemeldet
- 4. Dezember 2019 – Eine PoC-„schädliche App“ und ein Video mit Google geteilt
- 4. Dezember 2019 – Google hat den Erhalt des Berichts bestätigt
- 9. Dezember 2019 – Google hat den Schweregrad des Befundes als „Kritisch“ eingestuft
- 9. Dezember 2019 – Google bestätigt, dass das Problem reproduziert werden kann
- 14. Februar 2020 – Wir informieren Google, dass die 90-Tage-Offenlegung Anfang März näher rückt, und bitten um den Status auf ihrer Seite
- 14. Februar 2020 – Google antwortet, dass April der früheste Zeitpunkt sei, eine Lösung einzuführen
- 14. Februar 2020 – Wir informieren Google, dass wir an Abhilfemaßnahmen arbeiten
- 14. Februar 2020 – Google antwortet. Sie arbeiten an Abhilfemaßnahmen und fragen, ob wir Ihnen mitteilen können, welche Abhilfemaßnahmen wir empfehlen
- 17. Februar 2020 – Wir teilen Google mit, dass wir die Offenlegung bis April zurückhalten können. Wir fordern die CVE-Nummer an
- 17. Februar 2020 – Wir teilen unsere Abhilfestrategien und wie wir uns eine Plattformabschwächung vorstellen
- 23. März 2020 – Google antwortet mit der CVE-ID (CVE-2020-0096)
- 23. März 2020 – Google antwortet, dass die allgemeine Verfügbarkeit des Fixes für Android im Mai verfügbar sein wird
- 23. März 2020 – Google fragt, ob wir erwägen, die Offenlegung auf Mai zu verschieben
- 27. März 2020 – Wir antworten, dass wir die Offenlegung bis Mai verschieben werden
- 22. April 2020 – Google teilt uns mit, dass das Mai-Sicherheitsbulletin voraussichtlich einen Patch für die Schwachstelle enthalten wird