Accueil > Nouvelles > The Octopus Scanner Malware

The Octopus Scanner Malware

Logiciels libres ouverts privés et virus

samedi 30 mai 2020, par ScientificWare

Un rapport de l’équipe GitHub à lire absolument si vous êtes investi dans le développement logiciel. Attention, il faut bien comprendre la conclusion et ne pas hésiter à généraliser les risques à d’autres chaines de production.
En développant des applications informatiques, nous sommes vite confrontés à la question : Puis-je utiliser ce code trouvé sur le réseau, dans mon propre code ?
C’est souvent une facilité bien tentante que nous nous refusons d’utiliser chez ScientificWare.
Ce n’est pas une question réservée seulement aux petits développeurs. Cela touche tous les grands projets. Pratiquement tous les projets informatiques font appel à des bibliothèques ouvertes et libres. Mais quel est donc le degré de sécurité de ces projets incorporés ?
 ScientificWare n’utilise que des bibliothèques reconnues ou utilisées par d’autres petits ou grands projets auxquels il est associé.
 Pour Android, nous nous limitons aux API d’origine et à nos propres productions internes.
 De même pour tout autre projet Java y compris le langage lui-même à travers l’ OpenJDK et ses dérivés. Nous menons une veille et contribuons dès que nous identifions un problème.
Cette contrainte que nous nous imposons, limite un peu certaines fonctionnalités mais nous avons une grande responsabilité par rapport aux produits que nous diffusons. Cet incident invite à être encore plus prudent et conforte notre choix de contrôler et d’être partie prenante de tous les outils que nous utilisons.
Autrement dit, avant d’utiliser un code externe, il convient de le lire et s’investir dans sa maintenance pour garder un œil sur son évolution.
Enfin, une réflexion sur l’accès distant à ces bibliothèques sur certains dépôts doit être renforcée pour mieux maitriser les versions incorporées. Nous sommes encore réticents à leurs utilisations au regard des risques que nous percevons.


https://securitylab.github.com/

https://securitylab.github.com/research

https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain

While we have seen many cases where the software supply chain was compromised by hijacking developer credentials or typosquatting popular package names, a malware that abuses the build process and its resulting artifacts to spread is both interesting and concerning for multiple reasons.

In an OSS context, it gives the malware an effective means of transmission since the affected projects will presumably get cloned, forked, and used on potentially many different systems. The actual artifacts of these builds may spread even further in a way that is disconnected from the original build process and harder to track down after the fact.

Since the primary-infected users are developers, the access that is gained is of high interest to attackers since developers generally have access to additional projects, production environments, database passwords, and other critical assets. There is a huge potential for escalation of access, which is a core attacker objective in most cases.

It was interesting that this malware attacked the NetBeans build process specifically since it is not the most common Java IDE in use today. If malware developers took the time to implement this malware specifically for NetBeans, it means that it could either be a targeted attack, or they may already have implemented the malware for build systems such as Make, MsBuild, Gradle and others as well and it may be spreading unnoticed.

While infecting build processes is certainly not a new idea, seeing it actively deployed and used in the wild is certainly a disturbing trend.

As such, GitHub is continuously thinking about ways we can improve the integrity and security of the OSS supply chain. This includes features such to help detect issues in your dependencies, using Dependency Graph, security alerts for vulnerable dependencies, and automated security updates ; and features to help detect potential issues in your code, including code scanning and secret scanning. And of course, we maintain an active response channel and research capability through GitHub SIRT and GitHub Security Lab, as well as initiatives such as the Open Source Security Coalition.