Une autre vulnérabilité RCE perturbe la communauté des applications Java

Une autre vulnérabilité de type zero-day impliquant l'exécution de code à distance (RCE) ébranle la communauté des applications Java à la suite de la divulgation d'une faille dans le Spring framework, largement employé dans le développement de ces applications.

Connue sous le nom de Spring4Shell, cette vulnérabilité permet à un pirate d'exécuter à distance un code arbitraire sur le serveur cible. Elle permet aux pirates de se servir à mauvais escient d'une annotation RequestMapping qui permet de mapper les demandes HTTP entrantes aux fonctions de traitement appropriées. Cette vulnérabilité se produit lorsque RequestMapping est utilisé en association avec des outils Java traditionnels comme le paramètre de gestionnaire.Une telle attaque peut permettre d'accéder à toutes les données internes du site web, et notamment à toutes les bases de données. Elle peut également permettre d'accéder à des ressources internes additionnelles en vue d'obtenir davantage d'autorisations ou de s'orienter vers d'autres parties du réseau interne. Les applications Java concernées utilisent les versions 5.3.17 ou 5.2.19 du Spring framework et la version 9 ou supérieure du kit de développement Java (Java Development Kit, JDK).

La divulgation de la vulnérabilité de Spring4Shell fait suite à la découverte d'un programme d'exploitation RCE dans le logiciel open source Log4j connu sous le nom de Log4Shell, que de nombreuses entreprises utilisent pour gérer les logs créés par une application Java. À la suite de la découverte de cette vulnérabilité, il semble que les experts en sécurité aient intensifié leurs efforts pour déceler d'autres vulnérabilités RCE dans les applications Java.

Les changements à apporter afin de faire face aux vulnérabilités

Personne ne peut dire avec certitude s'il existe d'autres vulnérabilités de ce type, mais les équipes de cybersécurité seraient bien avisées de se préparer au pire. Outre la modernisation des processus de gestion des incidents, de nombreuses entreprises ont adopté de manière plus offensive les meilleures pratiques DevSecOps, qui confèrent aux développeurs une plus grande responsabilité en matière de sécurité des applications. Après tout, les développeurs ne sont pas seulement ceux qui doivent corriger ces vulnérabilités, ils ont aussi souvent une connaissance plus précise des applications en cours d'exécution qui pourraient être affectées.

La question de savoir jusqu'à quel point il faut transférer la responsabilité de la sécurité des applications suscite bien sûr de nombreux débats. En théorie, de nombreux développeurs sont désormais tenus de gérer l'ensemble du cycle de vie d'une application, et notamment toutes les mises à jour de sécurité. Le problème est que la plupart des développeurs ne possèdent pas une grande expertise en matière de sécurité. Il convient plutôt d'intégrer divers types d'outils d'analyse de code dans les plateformes d'intégration continue/de livraison continue (CI/CD) que de nombreuses entreprises utilisent désormais pour la gestion du développement des applications. Plutôt que de tout changer, les équipes d'exploitation qui soutiennent les développeurs pourraient les aider d'une manière qui n'oblige pas les développeurs à devenir des experts en sécurité.

Quelle que soit l'approche adoptée, la surveillance des chaînes d'approvisionnement des logiciels s'est déjà accrue à la suite d'une série de violations très médiatisées qui ont conduit l'administration Biden à publier un décret exigeant des pratiques plus strictes. Le véritable enjeu consiste maintenant à déterminer lesquelles des anciennes applications il est judicieux de conserver, malgré le risque de découverte de nouvelles vulnérabilités de type zero-day, et à les remplacer par des applications plus récentes, développées dans un langage de programmation qui pourrait être intrinsèquement plus sûr.

Le problème est que le nombre de vulnérabilités de type zero-day révélées ne cesse d'augmenter. Malheureusement, les cybercriminels accordent beaucoup plus d'attention à ces informations que la plupart des entreprises concernées. Dans de nombreux cas, personne ne cherche à détecter les vulnérabilités de type zero-day. Après tout, le pourcentage de leurs applications qui ont été touchées par une vulnérabilité de type zero-day pourrait se révéler relativement faible.