Comment le Log4j Grinch a volé Noël (avec mes excuses au Dr Seuss)

Votre équipe de cybersécurité mérite un cadeau de vacances tardif, ou peut-être quelques jours de congé supplémentaires. Alors que la plupart d'entre nous profitaient des fêtes de fin d'année, de nombreux professionnels de la cybersécurité travaillaient dur pour essayer de corriger la vulnérabilité Log4j qui est devenue un problème majeur à partir de fin novembre. Au lieu de passer la dernière partie de décembre en mode verrouillage, les professionnels de l'informatique s'efforçaient de déterminer l'étendue du problème et de prendre toutes les mesures correctives nécessaires. Beaucoup de temps de sommeil et de vacances ont été perdus dans le processus.

Même si votre entreprise n'a pas été directement touchée par un cyberincident causé par Log4j, elle peut avoir été affectée par un fournisseur tiers qui l'a été. Juste à temps pour les rapports de fin d'année, Kronos, qui propose des produits de ressources humaines, a détecté " une activité inhabituelle affectant les solutions UKG utilisant Kronos Private Cloud ", ce qui a rendu les services indisponibles.

Log4j, la vulnérabilité trouvée dans le package de journalisation de Java, montre à la fois l'importance et les faiblesses des logiciels open source. Dans un avertissementla FTC a déclaré : "La vulnérabilité Log4j fait partie d'un ensemble plus large de problèmes structurels. C'est l'un des milliers de services open source méconnus mais d'une importance cruciale qui sont utilisés par une variété presque innombrable de sociétés Internet. Ces projets sont souvent créés et maintenus par des bénévoles, qui ne disposent pas toujours des ressources et du personnel adéquats pour la réponse aux incidents et la maintenance proactive, même si leurs projets sont essentiels à l'économie Internet. »

Cette vulnérabilité particulière n'est pas un événement isolé, ce n'est pas non plus quelque chose de nouveau. La violation d'Equifax d'il y a plusieurs années, par exemple, était également due à une vulnérabilité open source.

Les cyberattaques open source ont augmenté de 650 % entre 2020 et 2021, et elles continueront d'augmenter car l'open source est plus que jamais utilisé tout au long de la chaîne d'approvisionnement logicielle.

Les acteurs de la menace ciblant la popularité de l'open source

Beaucoup d'utilisateurs sont coincés dans l'état d'esprit selon lequel les virus et les vulnérabilités se trouvent principalement sur les machines Windows et dans les logiciels Microsoft. Bien que cela ait pu être le cas il y a dix ans, nous avons dépassé cela. Et c'est grâce à la popularité de Linux et de l'open source, où les pirates se sont déplacés, et maintenant où certaines des attaques les plus importantes et les plus dommageables que nous voyons se produisent, parfois dans les modules logiciels les plus élémentaires.

De tels modules. comme fonction de journalisation. C'est un morceau de code assez bénin, mais Log4j exploite un code mal écrit dans la fonction de journalisation utilisée dans des milliers de produits et de systèmes embarqués exécutant Linux. Ce n'est pas un élément central de l'application; il crée des journaux. Il s'agit d'une fonctionnalité de base qui est devenue une porte dérobée pour les menaces, prenant un morceau de code généralement négligé et le détournant. Maintenant, il est partout, et grâce au timing de sa découverte, Log4j est devenu le Grinch qui a volé beaucoup de fêtes de Noël et de fêtes.

Il doit servir d'avertissement sur les risques liés à la chaîne d'approvisionnement open source.

Tous les codes ne sont pas créés égaux

Parce que l'open source est une conception logicielle collective, les développeurs doivent assumer la responsabilité des vulnérabilités et des failles de sécurité trouvées dans le code. C'est comme ça que ça devrait fonctionner, en théorie. En réalité, tous les codes ne sont pas créés égaux. Les scanners de code utilisés par les développeurs n'ont pas identifié la vulnérabilité de journalisation jusqu'à ce qu'elle soit exploitée.

Le défi pour les RSSI et les DSI utilisant des logiciels open source au sein de leur organisation est de trouver un moyen d'examiner plus attentivement des éléments plus importants du code, en approfondissant les mauvaises herbes pour trouver des problèmes potentiels dans des endroits inattendus. Les outils utilisés doivent évoluer.

La plupart des diplômés en informatique préfèrent écrire leur propre logiciel plutôt que de déboguer ou de trouver des vulnérabilités dans le code d'autres développeurs. Mais il faut le faire. Les RSSI et les responsables de l'ingénierie vont maintenant se demander pourquoi la fonction de journalisation n'a pas fait l'objet d'un examen plus approfondi. Après le prochain exploit d'un code oublié, la même question reviendra : "Pourquoi personne n'a pensé à regarder ça et à le réparer avant que ça ne devienne un problème ?" (Réponse : parce que tout le monde veut travailler sur des problèmes plus intéressants.)

Il faut se concentrer sur la sécurité open source, à tous les niveaux du code. Cela devrait faire partie d'un ensemble de freins et contrepoids que les développeurs utilisent pour s'assurer qu'aucun code n'est oublié. Il devrait également être partiellement automatisé, en utilisant l'IA pour effectuer le travail fastidieux que les humains préféreraient ignorer. Les deux parties, travaillant en tandem, doivent être utilisées dans tous les composants de l'open source, en particulier lorsque l'open source est utilisé dans une infrastructure critique.

C'est effrayant de penser que quelque chose d'aussi basique, d'aussi peu important pour la valeur du produit global, a la capacité de détruire des opérations commerciales entières. Oui, certains sont convaincus que l'open source est plus sûr que les logiciels propriétaires en raison des millions de personnes qui consultent le code. En décembre dernier, nous avons vu que ces millions de paires d'yeux ne voyaient pas tout. Jusqu'à ce que les processus soient en place pour des analyses approfondies du code, l'open source continuera d'être une menace potentielle.