Des centaines d'apps contiennent des identifiants AWS en dur dans leur code
Plus de 1 800 applications iOS intègrent des identifiants AWS (Amazon Web Services) codés « en dur », alertent les chercheurs en sécurité de Symantec. Cela signifie que des malandrins pourraient fouiller dans le code de ces apps, récupérer ces informations et se connecter tranquillou à des bases de données confidentielles. Avec tous les risques de siphonnage des données que cela implique…
Ces bases de données peuvent héberger les détails de comptes, des informations d'enregistrement, des communications internes… Bref, des millions d'enregistrements en tout genre, un véritable coffre au trésor pour des forbans mal intentionnés comme ils le sont toujours. Symantec donne l'exemple d'un SDK tiers utilisé par plusieurs apps bancaires, qui embarque dans son code des identifiants valides vers des serveurs AWS.
Toutes les informations d'authentification des clients de ces banques (nom, date de naissance, parfois les empreintes digitales !) sont potentiellement en danger. Autre cas, celui d'une plateforme de paris sportifs utilisée par 16 apps de jeux d'argent en ligne : c'est l'infrastructure au complet de la plateforme qui est ouverte à tous les vents…
La présence de ces identifiants en dur dans ces applications s'explique généralement par l'utilisation de bouts de code tout prêts qui contiennent ces informations. Par négligence, ou en raison de l'absence d'outils d'examen adaptés, ces données restent dans l'app distribuée aux utilisateurs. Symantec, qui fournit aussi des solutions de sécurité, recommande de mettre en place des processus de vérification durant le cycle de développement de l'application.
« un SDK tiers utilisé par plusieurs apps bancaires, qui embarquent dans son code des identifiants valides vers des serveurs AWS »
On pouvait pas faire pire 🤣/😱
C’est quoi le rapport entre avoir accès au serveur et obtenir les infos dessus. Bon après on peut aussi avoir des données en clair sur le serveur, mais si c’est le cas, ils faut juste qu’il arrêtent leur métier.
@Nesus
A un moment donné, la majorité des données doit être « en clair » quelque part. Pour un mot de passe, un hashage (avec au moins un salt) suffit mais pour d’autres données, tu as bien besoin de les stocker dans une forme que tu peux réutiliser. Même si les données sont cryptées sur disque, si tu as accès au serveur contenant la clé de décryptage, tu peux accéder à la donnée en clair. C’est pour ça que les serveurs doivent être parfaitement sécurisés
@fornorst
https://chiffrer.info/ 🙂
TL;DR on décrypte quand justement on n’a pas la clé de déchiffrement.
@nmo
Tu as tout à fait raison, merci de la correction. C’est un abus de langage dans lequel je tombe fréquemment malheureusement :(
Encore merci !
C’est quoi le rapport entre avoir accès au serveur et obtenir les infos dessus. Bon après on peut aussi avoir des données en clair sur le serveur, mais si c’est le cas, ils faut juste qu’il arrêtent leur métier.
Si tu es assez malin pour chiffrer les données tu es assez malin pour chiffrer les identifiants... On peut donc conclure qui si tu ne protèges pas les identifiants, tu ne protèges pas les données...
"We identified 1,859 publicly available apps, both Android and iOS, containing hard-coded AWS credentials. Almost all were iOS apps (98%) - a trend and difference between the platforms we've been tracking for years, possibly linked to different app store vetting practices and policies."
Sur toutes les apps analysées, 98% de celles contenant ces données en dur sont des apps iOS !!! cette différence entre iOS et Android serait une conséquence, selon eux, des différences de pratiques et règles des app stores... ce serait intéressant de leur demander d'expliquer ce qui, dans les règles de l'AppStore iOS, serait la cause de ce problème.
Il doit y avoir un problème dans leur doc clairement sinon on aurait pas 98% des cas problématiques sur iOS
J'avoue que je ne comprends pas bien ce qui peut amener à avoir 98% des cas sur iOS... ce serait bien qu'ils expliquent les raisons qui donnent ce résultat.
ce serait intéressant de leur demander d'expliquer ce qui, dans les règles de l'AppStore iOS, serait la cause de ce problème.
Peut-être parce que la vérification chez Apple ne s'attarde pas à ce genre de détail alors que sur le PlayStore oui.
Ça me semble un peu gros comme explication. Tu imagines un développeur qui se voit retoquer la version Android de son app pour cette raison et qui n'irait pas vérifier si il n'a pas fait la même boulette sur la version iOS pour la corriger également?
Surtout que Apple est beaucoup beaucoup plus pointilleux que Google sur les vérifications d'apps donc je doute que ça vienne de là
AWS doit mal expliquer dans leur doc iOS comment implémenter leur SDK je vois pas d'autre explication
@r e m y
Il n’est pas rare que les dév des deux app ne soient pas les mêmes
J'espère qu'une fois cette mega faille identifiée, ils ont informé AWS au moins 6 mois avant de rendre public leur découverte et qu'AWS a mis à profit ce délai pour corriger!
Sinon, maintenant que le problème est rendu public, tous les forbans et autres malandrins qui n'en avaient pas conscience, vont aller fouiller dans les apps pour trouver ces infos et hacker les serveurs correspondants.
@r e m y
Le problème ne vient pas d’AWS mais des développeurs des apps / plateformes incriminées.
C’est juste la version « cloud » du mot de passe en clair dans le code
@r e m y
Tu n’as pas tout compris dans la News, c’est pas la faute d’Amazon si les dev mettent leur login/password en dur dans leurs applications
J'ai noté "Symantec donne l'exemple d'un SDK tiers utilisé par plusieurs apps bancaires, qui embarquent dans son code des identifiants valides vers des serveurs AWS."
J'imaginais que le sdk en question était fourni par AWS avec des identifiants internes à AWS. D'autant que 98% des apps concernées sont des apps iOS et j'ai pensé, bêtement sans doute, que ça venait de la version iOS du sdk (et pas des développeurs dont j'imagine mal qu'ils fassent cette erreur sur la version iOS de leur app et pas sur la version Android)
Maintenant si ça vient des développeurs, j'espère qu'Apple (dont le store regroupe 98% des apps concernées) a été informé en amont de cette annonce publique pour qu'ils analysent les apps à la recherche de ces infos en dur, qu'ils bloquent les apps en question et qu'ils alertent les développeurs de façon à ce qu'ils corrigent d'urgence...
Ce serait bien que le problème ait été corrigé avant de le rendre public !
Malandrin, c’est un mot couramment utilisé au Québec?
@amonbophis
Je ne sais pas mais ici oui 🙄
@amonbophis
C’est le mot préféré de MB. 😜
Faut vraiment être idiot pour faire ça...
La flemme d'avoir un serveur entre l'app et aws ? (BFF, backend for frontend) ?
Ou alors les chercheurs se trompent et confondent les clés privées avec droits admin des clé publics (anon) ?
Dans le second cas, si on parle du service Amplify, c'est sans risque et ça sert juste à authentifier publiquement le sdk auprès d'aws. La sécurité se fait ensuite côté aws en limitant l'accès des utilisateurs en fonction de règles de sécurités.
Édit : ok on parle du service S3 ... des développeurs stupides donc... amateurs !
Je sais pas ce que le type ont fait mais ça pourrait aussi être des clés avec un accès très restreint, par exemple uniquement le droit de créer des blob sur S3, sans la possibilité de les lire derrière
C'est franchement horrible, mais à priori pas de problème de sécurité pour les utilisateurs
Comment expliquez-vous que 98% des apps concernées soient des apps iOS? Car j'avoue que ça me dépasse... je ne trouve aucune explication crédible 🤔
« Ne vous inquiétez pas, nous sommes des professionnels, nous maîtrisons la situation. »
L’amateurisme ou plus certainement la recherche du moins coûteux pour plus de bénéfice a encore frappé.
AWS est partenaire de la blockchain layer 1 crypto Casper Network ! Pour information
Il existe des cloud providers qui imposent l’encryption de bout en bout..