Goldoson et le côté obscur des bibliothèques d'applications mobiles tierces

Chez VMX Labs, nous avons appris que 60 applications mobiles véhiculent le même logiciel malveillant Android n'est pas nécessairement plus choquant que d'autres attaques de logiciels malveillants d'une portée potentiellement considérable impliquant des appareils mobiles. Cependant, c'est l'occasion d'illustrer à nos lecteurs pourquoi le code réel (ou la source du code) doit faire l'objet d'une attention particulière au cours du processus de développement de l'application.

Après tout, le récent logiciel malveillant Goldoson, signalé par Bleeping Computer, semble avoir étendu ses tentacules par le biais de plus de 100 millions de téléchargements associés à ces 60 applications mobiles infectées. Deux des plus grandes applications concernées sont L.POINT with L.PAY et Money Manager Expense & Budget (toutes deux avec plus de 10 millions de téléchargements). Bleeping computer rapporte que le composant malveillant Goldoson fait partie d'une bibliothèque tierce utilisée par toutes les applications. C'est ainsi que commence la production massive de maux de tête pour de nombreux développeurs. 

Les attaques de la chaîne d'approvisionnement de ce type, où les attaquants injectent leur code dans des bibliothèques libres (ou des bibliothèques provenant de sources non fiables), peuvent être difficiles à éviter pour les développeurs d'applications, car même s'ils n'utilisent que des logiciels libres évalués par des pairs, des injections de code de logiciels malveillants dans ces bibliothèques peuvent toujours se produire. Étant donné que ces logiciels malveillants ne déploient leur activité qu'une fois l'application déployée, les scanners de sécurité, même les examens de sécurité, ainsi que ceux des magasins d'applications, ne détectent pas ces attaques. Pour avoir un semblant de tranquillité d'esprit, les développeurs d'applications doivent être en mesure de surveiller en permanence leur application sur le terrain, d'identifier ces problèmes lorsqu'ils se manifestent et de remédier à la menace dans les plus brefs délais. Les bibliothèques tierces concernées sont souvent une partie cruciale de l'anatomie d'une application, de même que sa posture de cybersécurité, pour avoir cette couche supplémentaire de contrôle.

Découvert par McAfee, Goldoson recueillerait des données sur les applications d'un appareil, les dispositifs Wi-Fi et Bluetooth, ainsi que sur l'emplacement de l'appareil, tout en cliquant frauduleusement et silencieusement sur des publicités en arrière-plan. Dès qu'un utilisateur lance une application qui a utilisé la bibliothèque infectée, Goldoson se met au travail, lui indiquant les données à voler et les publicités à cliquer. Les applications impliquées qui ont reçu de nombreuses autorisations de la part de l'utilisateur sont clairement celles qui volent le plus de données.  

La plupart des consommateurs ignorent que les boutiques d'applications telles que Google Play ne sont pas responsables de la sécurisation des applications individuelles qui ne sont pas produites par Google. Ce n'est pas leur rôle. La politique habituelle de Google, qui consiste à supprimer les applications qui ne sont pas conformes à ses règles en raison de problèmes connus, en est la preuve. La responsabilité de la sécurité des applications mobiles incombe donc uniquement au développeur de l'application. Ironiquement, le thème des problèmes de sécurité fréquents associés à tout ce qui est "tiers", en particulier pour les applications mobiles, se poursuit non seulement avec la nécessité de remédier à l'infection de la bibliothèque tierce concernée, mais aussi avec le fait que les boutiques d'applications Android tierces pourraient toujours héberger la même bibliothèque malveillante.  

Ces types d'attaques, qui illustrent la menace importante que peut représenter l'anatomie non surveillée ou non vérifiée d'une application mobile, incitent l'industrie à mettre en place une chaîne d'approvisionnement en logiciels qui donne la priorité non seulement à la connaissance de l'arrière-plan de toute son anatomie (également connue sous le nom de composants), mais aussi à la capacité de déterminer si quelque chose ne va pas dans l'activité d'une application et doit être corrigé parce qu'un élément a été négligé lors de l'examen initial de la chaîne d'approvisionnement en logiciels. Cela peut concerner à la fois le code source ouvert et le code propriétaire, comme le souligne ce document de TechTarget de TechTarget.