La sécurité des applications est une priorité incontournable pour Okayo et pour nos clients . Pour cela, nous accordons une place importante à l’encadrement de cette problématique avec des entités compétentes en termes d’hébergement et de réseau et en partenariat avec des sociétés expertes telles Exodata.
De quoi parle-ton ?
Au début du mois de Décembre 2021, une faille de sécurité majeure et internationale a été détectée par un expert IT de l’entreprise Alibaba Cloud. Cette vulnérabilité, connue sous le nom de CVE-2021-44228, permet d’exécuter du code directement sur les serveurs concernés. Concrètement, les possibilités qu’offrent la vulnérabilité sont la récupération d’informations figurant sur le serveur, la création de fichiers sur le disque, etc. En outre, l’attaquant ciblant une victime pourrait alors prendre totalement possession de la machine de manière relativement transparente. Plus médiatiquement, cette vulnérabilité est appelée Log4Shell, en référence à log4j et Shell.
Cette faille concerne les technologies Java. Elle peut être exploitée via HTTP et HTTPS qui sont les deux protocoles les plus répandus du Web.
Qu’est ce que Log4J ?
Une librairie Apache
L’objectif lors de l’élaboration d’un logiciel ou application informatique, est d’offrir une valeur maximale. Pour cela, il est très fréquent d’utiliser des lignes de code écrites et partagées par d’autres développeurs. Ces lignes de codes sont ensuite utilisables en « prêt à l’emploi ». C’est ce que l’on appelle une librairie, qui sera donc une dépendance de l’outil final. Des outils comme NPM, ou encore Maven Central, appelés « Répertoires de dépendances », correspondent à l’annuaire de ces dépendances, pour des langages et des technologies différentes.
Un Logger
Lorsque l’on développe du code informatique qui s’exécute sur un serveur, il est systématique de tracer l’exécution du code. Cette trace peut prendre la forme d’écriture dans un fichier sur le serveur, d’enregistrement dans une base de données, d’envoi de mail, etc. En effet, le rôle d’un serveur est d’exécuter en parallèle des actions dictées par le code. Ces traces (ou logs) permettent à un humain, une équipe, une organisation, ou d’autres outils informatiques, de « surveiller » (ou « monitorer ») l’activité du serveur.
try{ myFunction(); logger.info("MyFunction went well!"); } catch (Exception ex){ logger.error("There's an error !", ex); }
Dans cet exemple, si la fonction myFunction se déroule sans problème, on pourra tracer cela à un niveau « INFO ». Dans le cas contraire, on tracera l’anomalie (l’Exception) à un niveau « ERROR », ce qui pourra déclencher des actions ultérieures comme l’envoi d’un E-Mail, un enregistrement en base de données, l’appel à une API, etc.
En d’autres termes, Log4j est une librairie de log utilisée dans le cas du langage Java. Elle est développée par la Fondation Apache , et est Open-Source, c’est à dire que son code est disponible et lisible au grand public. Il est disponible sur GitHub.
Risque et mesures à prendre sous l’angle de la sécurité
Log4j est omniprésent dans un très grand nombre d’applications et de services web. La faille Log4Shell en question étant relativement facile à exploiter et désormais publique. Par conséquent une réelle urgence y a été mise, comme le soulignent les « score » des différents site référençant cette vulnérabilité. En effet, la procédure pour un « pirate » informatique est de faire des scans massifs des sites Internet pour identifier toutes les applications concernées et vulnérables, prendre leur contrôle et y installer des logiciels « fantômes » qui vont travailler à distance, pour des exploitations diverses, allant de l’extraction de données présentes sur le serveur, à l’utilisation des ressources physiques de la machine (par exemple pour le minage de cryptomonnaies).
Par la suite, d’autres vulnérabilités ont été découvertes au fil de ces derniers jours, notamment sur les versions 2.15 et 2.16 de Log4j, développées en urgence sous forme de « patchs » pour pallier la faille initiale, repérée sur toutes les versions 2.0 à 2.14.1 de cette même bibliothèque.
L’agence fédérale américaine Cybersecurity and Infrastructure Security Agency fait état de plus de 500 logiciels d’entreprise potentiellement exposés. Mais le recensement de toutes les applications concernées à travers le monde s’étendrait sans aucun doute à plusieurs dizaines de milliers.
Le plus important pour chaque acteur – sociétés, administrations… – est d’identifier tous les endroits où la bibliothèque Log4j est utilisée « afin de colmater les brèches ». Serveurs Amazon ou IBM, smartphones Apple, voitures Tesla…
Le point de vue éditeur sur la sécurité
Un éditeurs de logiciel n’est pas épargné par cette vulnérabilité, et des patchs correctifs intégrant la version 2.17 (et 2.17.1 à date de rédaction de cet article) sont livrés en urgence chez nos clients.
Afin d’être proactifs sur ce genre de vulnérabilités, il est pertinent d’intégrer les problématiques de sécurité au plus tôt dans la chaine de développement, avec des pratiques comme DevSecOps. Dans cet esprit, Okayo intègre progressivement l’outil Snyk, en partenariat avec Bitbucket, afin d’obtenir une réelle vision d’ensemble des dépendances vulnérables au sein de l’application. Par ailleurs, la mise en place des règles OWASP doit également rester une priorité.
Source Image : https://moisesbm.wordpress.com/2021/07/14/powerful-combination-for-your-devsecops-snyk-bitbucket-or-github/
