La vulnérabilité Eavesdropper
L’alerte est lancée et la sécurité des applications mobiles est en jeu. La faille présente dans presque 700 applications mobiles relance le débat des risques, piratage des appels et SMS, possibilité d’écoutes téléphoniques, enregistrements audio, et de la manière dont les développeurs intègrent le code dans les applications.
Cette vulnérabilité Eavesdropper permet aux pirates d’accéder aux métadonnées de leurs comptes Twilio (messagerie vocale et textuelle). Appthority explique, « nous avons détecté la vulnérabilité Eavesdropper sur plus de 685 applications d’entreprise (44 % Android, 56 % iOS) associées à des comptes développeur Twilio ». Fin août, 170 étaient encore disponibles (Google et Apple) et les applications Android auraient été téléchargées plus de 180 millions de fois.
Le sous-titrage n'est plus une option mais un levier de croissance : 80 % des vidéos sur les réseaux sociaux sont consommées sans le son. Pourtant, choisir entre le format…
La confidentialité des messages affectée
Alors que les applications mobiles utilisées reposent souvent sur des services cloud, Johannes Ullrich, Directeur du SANS Internet Storm Center, Directeur Recherche, SANS Technology Institute commente « pour utiliser ces services, l’utilisateur doit fournir des informations d’identification – généralement sous la forme d’une clé API, sachant que le développeur lui-même dispose d’une clé API. Dans le cas de Twillio, service de messagerie vocale et textuelle, si un développeur inclut sa clé API dans l’application, alors cette clé peut être extraite de l’application et utilisée pour transmettre des commandes arbitraires à Twillio, ce qui peut affecter la confidentialité des messages envoyés par d’autres utilisateurs qui utilisent les mêmes informations d’identification fournies par le développeur. »
La clé API en jeu
Le développeur ne devrait jamais inclure une clé API au sein d’une application qui bénéficie d’un accès complet aux fonctionnalités des services Web. « Le développeur devrait plutôt fournir des jetons (tokens) d’accès individualisés à chaque utilisateur de l’application, ceci pouvant être automatisé. Une autre option est d’utiliser des technologies comme OAuth pour que l’utilisateur configure un compte directement avec un service Web tiers. Mais cela tend à être plus complexe. Dans certains cas, le service Web peut être en mesure de fournir des jetons d’accès aux capacités limitées. En dernier recours, le développeur peut configurer un proxy qui recevra la requête de l’application mobile, l’authentifiera à l’aide des informations d’identification de l’application de l’utilisateur, puis transmettra la requête au service Web en utilisant les informations d’identification du développeur. Dans ce cas, les informations d’identification du développeur ne sont jamais envoyées à l’utilisateur. Mais cette méthode ajoute des frais supplémentaires et de la complexité à l’application » poursuit Johannes Ullrich.
Passez à la cybersécurité proactive, transformez la collecte et l’analyse des logs en un bouclier dynamique contre les cybermenaces. Découvrez comment mettre en place une approche SIEM modulaire, évolutive et…
