StrandHogg 2.0 est une nouvelle vulnérabilité Android dangereuse. Voici comment cela peut affecter les utilisateurs et comment les développeurs peuvent protéger leurs applications contre cela.
Il est 22h00. Savez-vous où se situent vos activités? Il existe une nouvelle vulnérabilité qui peut être exploitée sur des millions d’appareils Android, et elle est également assez méchante. En un mot, ce défaut de conception permet à un attaquant de présenter sa propre activité (page) au-dessus de celle d'une autre application, ce qui peut inciter l'utilisateur à divulguer ses données privées. La vulnérabilité a été baptisée StrandHogg 2.0 et a été récemment révélée par Promotion, une entreprise de sécurité norvégienne.
La vulnérabilité StrandHogg 2.0 affecte théoriquement tous les appareils Android exécutant des versions d'Android aussi anciennes que Honeycomb (3.0) et jusqu'à Android 9 Pie (9.0). Basé sur dernières statistiques de distribution de la version Android, cela signifie que environ 91,8 % de tous les appareils Android sont vulnérables à StrandHogg 2.0
. La vulnérabilité a été attribuée CVE-2020-0096 et on lui a donné un niveau de gravité « critique ». Il ne nécessite aucune autorisation spéciale pour fonctionner et peut fonctionner presque entièrement sans interaction de l'utilisateur. Tout ce qu’un utilisateur a à faire est d’ouvrir une application contenant du code malveillant caché, et il est alors vulnérable à l’exploitation.Promon a eu la gentillesse de nous envoyer son application de preuve de concept et son code source afin que nous puissions mieux expliquer comment fonctionne l'exploit, pourquoi il est important pour les utilisateurs et comment les développeurs peuvent protéger leurs applications encontre.
Comment ça fonctionne
Supposons que vous utilisez Gmail et que vous cliquez sur un lien Web. Si vous accédez à l'écran de vos applications récentes, vous remarquerez peut-être que la page Web semble être « à l'intérieur » de Gmail. L'aperçu montre le site Web, mais l'icône et le nom de l'application proviennent toujours de Gmail. C'est quelque chose qui se produit lorsqu'une application/activité lance une autre application/activité dans la même tâche. Imaginez maintenant que vous n'avez pas volontairement ouvert ce lien. Pour vous, il semble que ce soit simplement une partie de l'application Gmail. C'est le comportement qu'exploite StrandHogg 2.0.
Nous allons devoir laisser de côté certains détails ici, mais voici à peu près comment fonctionne cet exploit. Pour ce qui suit, supposons que l'attaquant souhaite obtenir l'identifiant Gmail de l'utilisateur.
- L'utilisateur télécharge une application malveillante (bien sûr, sans savoir qu'elle est malveillante) et l'ouvre.
- En arrière-plan, l'application ouvre Gmail, place une activité de connexion similaire par-dessus, puis lance une autre activité.
- L'utilisateur ouvre Gmail et voit ce qui ressemble à l'écran de connexion de Gmail, mais qui est en réalité l'activité de phishing de l'attaquant.
L'activité finale lancée à l'étape 2 peut être tout ce qui évite les soupçons. L'application pourrait simuler un crash et revenir à l'écran d'accueil, ou elle pourrait simplement s'ouvrir à son activité principale comme si de rien n'était. La seule chose suspecte que l'utilisateur pourrait voir est un tas d'animations d'ouverture lors du lancement de toutes les activités. Le pire: il ne semblera même pas que Gmail ait été ouvert.
Bien entendu, un attaquant peut faire plus que simplement afficher un faux écran de connexion. Une application malveillante pourrait présenter une invite d'autorisation à la place, incitant l'utilisateur à accorder des autorisations non désirées. Bien que demander des autorisations spéciales telles que l'accessibilité puisse rendre l'utilisateur suspect, il est possible de faire beaucoup de dégâts avec quelque chose comme l'accès au stockage.
Les éléments techniques
Cette section suivante est un aperçu général du fonctionnement de StrandHogg 2.0. Promon ne publiera pas tous les détails avant quelques mois, nous ne pouvons donc pas partager exactement comment cet exploit est implémenté. Il y a cependant quelques détails techniques dont nous pouvons parler.
En un mot, StrandHogg 2.0 détourne le système d'Android Context.startActivities() Méthode API, utilisant trois Intents.
- La première Intent est celle qui lance, dans le cas de notre exemple, Gmail. Il est signalé par
Intent.FLAG_ACTIVITY_NEW_TASK. - La deuxième intention est la malveillante. Dans notre exemple, il s'agit de l'activité de connexion similaire. Cette intention n’a aucun indicateur.
- La troisième intention est la distraction. Cela garantit que l'utilisateur ne se méfie pas de l'ouverture aléatoire de Gmail au lieu de l'application sur laquelle il a appuyé (c'est-à-dire celle qui lance l'attaque). Il est signalé par
Intent.FLAG_ACTIVITY_NEW_TASK.
Toutes ces intentions sont ensuite transmises dans un tableau au startActivities() méthode.
Le manque de drapeaux dans la deuxième intention est la clé ici. Ce faisant, nous avons simplement reproduit l’exemple Gmail ci-dessus. Techniquement, la tâche revient à Gmail, mais l'activité la plus importante est celle de l'attaquant. Lorsque l'utilisateur clique ensuite sur l'icône de l'écran d'accueil de Gmail, l'activité de l'attaquant s'affiche à la place de celle de Gmail.
Preuve de concept
Grâce aux informations que Promon nous a envoyées, nous avons pu reproduire leur preuve de concept. Voici un enregistrement d'écran d'un Samsung Galaxy Note8 exécutant Android 9 Pie le montrant en action.
Techniques et problèmes d’atténuation
Désormais, la simple réplication de ce qui précède dans le code ne fonctionnera pas réellement. Ce n'est pas un exemple complet, et il y a quelques autres choses qu'un attaquant doit faire pour que cela fonctionne, que nous ne pouvons pas partager. Mais ils ne sont pas particulièrement difficiles à deviner par vous-même, et c’est en partie ce qui rend cette attaque si dangereuse. StrandHogg 2.0 est un exploit relativement facile à mettre en œuvre et difficile à atténuer.
L'atténuation ne peut pas simplement impliquer de mettre sur liste noire toutes les applications qui utilisent startActivities(), car il existe de nombreuses utilisations légitimes. Il est également très difficile d’automatiser un algorithme de détection. Les développeurs malveillants peuvent utiliser toutes sortes d'astuces pour rendre leur implémentation de StrandHogg 2.0 effectivement invisible pour des services comme Google Play Protect. StrandHogg 1.0 obligeait l'attaquant à ajouter un attribut dans le fichier AndroidManifest.xml de l'application malveillante, ce qui était relativement facile à détecter. StrandHogg 2.0, en revanche, fonctionne entièrement en Java/Kotlin.
Compte tenu de l’obscurcissement, de la réflexion et même de différents styles de codage, il semble peu pratique de détecter automatiquement et correctement une application utilisant cet exploit. De plus, si un utilisateur fait l'objet d'une attaque StrandHogg 2.0, il se peut qu'il ne le sache même pas. Si vous ouvrez Gmail et que vous voyez son écran de connexion, vous pourriez simplement penser que votre session a expiré et saisir vos informations de connexion sans hésiter.
Lorsque nous avons contacté Google pour obtenir une réponse, un porte-parole a fait la déclaration suivante :
"Nous apprécions le travail des chercheurs et avons publié un correctif pour le problème qu'ils ont identifié. De plus, Google Play Protect détecte et bloque les applications malveillantes, y compris celles utilisant cette technique."
Cela semble bien, et j'espère que cela aura au moins un certain effet contre les attaques StrandHogg 2.0. Il convient toutefois de noter que Google Play Protect n'a pas détecter notre application de preuve de concept comme malveillante, même après avoir effectué une analyse manuelle.
Promon dit qu'ils "je n'ai observé aucun logiciel malveillant réel utilisant la vulnérabilité StrandHogg 2.0", mais rien ne garantit que ce soit la première fois que l'exploit est découvert. Pour cette raison, Promon recommande aux développeurs de protéger leurs applications en définissant l'activité de leur lanceur. launchMode drapeau vers l'un ou l'autre singleTask ou singleInstance. L'un ou l'autre de ces indicateurs empêchera l'injection de tâches, sur lequel s'appuie StrandHogg 2.0. Cependant, le fait que votre activité utilise l'un de ces indicateurs peut entraîner des problèmes avec certains flux d'applications, ce n'est donc pas toujours souhaitable.
Promon fait également la promotion de son propre produit « In-App Protection by Promon SHIELD » qui ressemble à une bibliothèque. que les développeurs d'applications peuvent mettre en œuvre pour surveiller les tâches du processus de votre application afin de vérifier les irrégularités insertions. Puisqu’il n’existe pas de stratégie d’atténuation vraiment efficace pour les développeurs ou les utilisateurs, il est très important que les fabricants mettent en œuvre le correctif pour résoudre ce problème dès que possible.
Heureusement, Promon a suivi les directives de divulgation responsable avant de rendre public cet exploit (et ce n'est pas encore entièrement public – Promon attend 90 jours avant de révéler complètement comment StrandHogg 2.0 travaux). Google a depuis rétroporté les correctifs pour cet exploit sur Android 8.0 Oreo, Android 8.1 Oreo et Android 9 Pie avec le Niveau de correctif de sécurité Android (SPL) de mai 2020. Les utilisateurs d’Android 10 et versions ultérieures ne sont pas vulnérables, même si nous ne savons pas vraiment pourquoi c’est le cas. Cela a probablement quelque chose à voir avec les nouvelles restrictions d'Android 10 concernant le lancement d'activités et la manière dont Google les a intégrées dans la pile de tâches. Promon affirme que « sur Android 10, l'attaque est totalement inefficace et les activités sont divisées en différentes tâches et en piles de tâches distinctes selon adb shell dumpsys activity activities."
Si le fabricant de votre appareil fournit toujours des mises à jour de sécurité (vous pouvez en savoir plus sur comment fonctionne le processus de correctif de sécurité ici), vous devriez les harceler pour une mise à jour dès que possible. Sinon, vous devrez simplement faire attention aux applications que vous téléchargez et exécutez (même si vous devriez le faire de toute façon).
Pour plus de détails et de cas d'utilisation de StrandHogg 2.0, consultez le annonce officielle sur le site de Promon. Pour les développeurs de ROM personnalisées, vous pouvez trouver les commits AOSP pertinents pour empêcher les attaques StrandHogg 2.0. ici et ici.
Chronologie de la divulgation
Voici le calendrier de divulgation partagé par Promon dans son document StandHogg 2.0 :
- 4 décembre 2019 – Problème signalé à Google
- 4 décembre 2019 – Partage d’une « application malveillante » PoC et d’une vidéo avec Google
- 4 décembre 2019 – Google a confirmé avoir reçu le rapport
- 9 décembre 2019 – Google a défini la gravité du résultat comme « Critique »
- 9 décembre 2019 – Google confirme être capable de reproduire le problème
- 14 février 2020 – Nous informons Google que la divulgation dans les 90 jours approche début mars et demandons un statut de leur côté.
- 14 février 2020 – Google répond qu'avril est le plus tôt possible pour déployer un correctif
- 14 février 2020 – Nous informons Google que nous travaillons sur des mesures d’atténuation
- 14 février 2020 – Google répond. Ils travaillent sur des mesures correctives et demandent si nous pouvons partager les mesures d'atténuation que nous recommandons.
- 17 février 2020 – Nous informons Google que nous pouvons retarder la divulgation jusqu'en avril. Nous demandons le numéro CVE
- 17 février 2020 – Nous partageons nos stratégies d’atténuation, ainsi que la manière dont nous envisageons une atténuation de la plateforme
- 23 mars 2020 – Google répond avec l'identifiant CVE (CVE-2020-0096)
- 23 mars 2020 – Google répond que la disponibilité générale du correctif pour Android sera disponible en mai
- 23 mars 2020 – Google demande si nous envisagerons de retarder la divulgation jusqu'en mai
- 27 mars 2020 – Nous répondons que nous retarderons la divulgation jusqu’en mai
- 22 avril 2020 – Google nous informe que le bulletin de sécurité de mai devrait contenir un correctif pour la vulnérabilité