Cuprins[Ascunde][Spectacol]
Log4Shell, o vulnerabilitate a internetului, a afectat recent milioane de mașini. Log4j, un program obscur, dar aproape omniprezent, provoacă acest lucru.
Log4j este folosit pentru a înregistra toate acțiunile care au loc în culise într-o varietate de sisteme informatice.
Se bazează pe o bibliotecă de jurnalizare open-source care este folosită de companii și chiar de organizațiile guvernamentale în majoritatea aplicațiilor.
Fiind una dintre cele mai grave găuri de securitate cibernetică descoperite vreodată, este esențial să vă protejați sistemele de această vulnerabilitate. Dar cum?
Să explorăm vulnerabilitatea Log4j în detaliu și toate soluțiile posibile de remediere pentru aceasta.
Ce este Log4j?
Log4j este un open-source cadru de înregistrare care permite dezvoltatorilor de software să înregistreze diferite date în aplicațiile lor. Este o componentă a proiectului Apache Logging Services, care este condus de Apache Software Foundation.
Sute de site-uri web și aplicații folosesc Log4j pentru a efectua operațiuni critice, cum ar fi înregistrarea datelor pentru depanare și alte utilizări.
Când introduceți sau faceți clic pe un link online slab și obțineți o notificare de eroare 404, acesta este un exemplu frecvent de Log4j la locul de muncă. Serverul web care rulează domeniul link-ului web pe care ați încercat să îl accesați vă informează că nu există o astfel de pagină web. De asemenea, înregistrează evenimentul în Log4j pentru administratorii de sistem ai serverului.
În cadrul programelor software, sunt folosite semnale de diagnosticare similare. În jocul online Minecraft, de exemplu, serverul folosește Log4j pentru a înregistra activități precum RAM totală utilizată și instrucțiuni de utilizator trimise în consolă.
Cum apare vulnerabilitatea?
Căutările sunt o nouă caracteristică introdusă în Log4j 2.0, care ajută la încorporarea de informații suplimentare în intrările de jurnal. Una dintre aceste căutări este căutarea JNDI (Java Naming and Directory Interface), care este un API Java pentru comunicarea cu un serviciu de director.
Folosind această abordare, ID-urile de utilizator interne pot fi mapate cu numele de utilizator reale. Această interogare expune vulnerabilitatea RCE recent descoperită, deoarece unul dintre tipurile de date furnizate de serverul LDAP este un URI care indică o clasă Java, care este apoi încărcat în memorie și rulat de instanța Log4j.
Din cauza unei slăbiciuni în validarea de intrare a bibliotecii Log4j, este posibil să injectați un server LDAP arbitrar dintr-o sursă neîncrezătoare. Deoarece dezvoltatorii presupun că datele trimise în jurnalele vor fi tratate ca text simplu, nu se efectuează nicio validare suplimentară a intrărilor, iar inputurile periculoase ale utilizatorului intră în jurnale.
O declarație de jurnal ar putea arăta astfel:
Un utilizator rău intenționat ar insera acum o căutare JNDI care se referă la un server LDAP nepoliticos într-un parametru URL. Căutarea JNDI ar fi după cum urmează:
Biblioteca Log4j discută apoi cu acest server LDAP la attacker.com pentru a obține informații despre director, inclusiv valori pentru Java Factory și Java Codebase.
Aceste două valori includ clasa Java a atacatorului, care este apoi încărcată în memorie și executată de instanța Log4j, completând execuția codului.
Cine este în pericol?
Vulnerabilitatea Log4j este incredibil de largă, afectând aplicațiile de afaceri, dispozitivele încorporate și subsistemele acestora. Aplicațiile afectate includ Cisco Webex, Minecraft și FileZilla FTP.
Cu toate acestea, aceasta nu este în niciun caz o listă întreagă. Defectul afectează chiar misiunea elicopter Ingenuity Mars 2020, care folosește Apache Log4j pentru înregistrarea evenimentelor.
Comunitatea de securitate a compilat un lista sistemelor vulnerabile. Este esențial să rețineți că aceste liste se actualizează continuu, așa că dacă un anumit program sau sistem nu este prezentat, nu presupuneți că nu este afectat.
Expunerea la această vulnerabilitate este destul de probabilă și chiar dacă este specifică stivă tehnologică nu aplică Java, directorii de securitate ar trebui să se aștepte ca sistemele de furnizori critice, furnizorii SaaS, furnizorii de găzduire în cloud și furnizorii de servere web să facă acest lucru.
Cum se verifică vulnerabilitatea Log4j?
Primul pas este să determinați dacă a avut loc deja un atac. Puteți face acest lucru verificând jurnalele de sistem pentru fragmente de sarcină utilă RCE.
Dacă o căutare a unor termeni precum „jndi”, „ldap” sau „$::” generează jurnalele, cercetătorii de securitate ar trebui să exploreze în continuare pentru a vedea dacă a fost un atac legitim sau doar amprenta digitală.
Au fost descoperite multe atacuri în sălbăticie care nu au livrat încărcături utile dăunătoare. Cu toate acestea, acestea au fost efectuate de experți în securitate pentru a determina câte aplicații au fost vulnerabile la acest atac.
Următorul pas este să utilizați biblioteca Log4j pentru a identifica toate proiectele. Dacă sunt utilizate versiuni între 2.0-beta9 și 2.14.1, proiectul poate fi susceptibil.
Având în vedere dificultatea de a determina unde există această vulnerabilitate, poate fi de preferat să presupunem că proiectul este susceptibil și că actualizarea bibliotecii este cel mai bun curs de acțiune pentru a elimina pericolul executării codului.
Proiectul nu este vulnerabil dacă versiunea utilizată este mai mică de 2.0-beta 9, deși biblioteca Log4j ar trebui în continuare actualizată, deoarece versiunile din gama 1.x sunt vechi și nu mai primesc actualizări.
Indiferent dacă este descoperit un proiect susceptibil, se recomandă să fie verificat pentru a vedea dacă orice informație înregistrată folosind Log4j conține informații pe care utilizatorul le poate modifica. Adresele URL, parametrii de solicitare, anteturile și modulele cookie sunt exemple ale acestor date. Dacă unul dintre acestea este înregistrat, proiectul este în pericol.
Aceste cunoștințe vă pot ajuta să explorați în continuare jurnalele de sistem și să determinați dacă aplicația dvs. web a fost deja atacată.
Există instrumente online gratuite care pot detecta dacă o aplicație web este vulnerabilă. Unul dintre aceste programe este Vânătoarea Log4Shell. Este open-source și disponibil pe GitHub.
Dacă este descoperită o zonă vulnerabilă de cod în aplicația online, sarcina utilă furnizată de instrumentul dezvăluit poate fi utilizată pentru a o injecta în aplicația web. Instrumentul de testare ar dezvălui conexiunile făcute între aplicația dvs. web și serverul lor LDAP dacă vulnerabilitatea a fost exploatată.
Soluții pentru remedierea vulnerabilității Log4j
Primul pas este să actualizați Log4j, lucru pe care îl puteți face folosind managerii de pachete obișnuiți sau descărcându-l direct de pe acest pagină.
De asemenea, este posibil să scadă exploabilitatea vulnerabilității prin setarea variabilei de mediu FORMAT MSG NO LOOKUPS la true. Această contramăsură, totuși, este aplicabilă numai versiunilor Log4j mai mari sau egale cu 2.10.
Să luăm acum în considerare opțiunile alternative.
1. Soluții pentru Log4j versiunea 2.17.0
Este cu siguranță recomandat să utilizați versiunea Log4j 2.15.0 pentru a vă proteja împotriva Log4Shell, cu toate acestea, dacă acest lucru nu este posibil, sunt disponibile și alte soluții.
Versiunile 2.7.0 și ulterioare ale Log4j: Este posibil să se protejeze împotriva oricărui atac prin modificarea formatului evenimentelor care urmează să fie înregistrate folosind sintaxa procent m nolookups pentru datele furnizate de utilizator. Această actualizare necesită editarea fișierului de configurare Log4j pentru a genera o nouă versiune a programului. Ca urmare, înainte de implementarea acestei noi versiuni, etapele de validare tehnică și funcțională trebuie repetate.
Versiunile Log4j 2.10.0 și ulterioare: De asemenea, este posibil să vă protejați împotriva oricărui atac setând parametrul de configurare log4j2.formatMsgNoLookups la true, de exemplu, când porniți mașina virtuală Java cu opțiunea -Dlog4j2.” formatMsgNoLookups = true, O altă opțiune este să eliminați clasa JndiLookup din argumentul classpath, care va elimina vectorul principal de atac (cercetătorii nu exclud posibilitatea unui alt vector de atac).
Amazon Web Services oferă un hotpatch care „ar trebui să fie utilizat pe propriul risc”. Au fost publicate și alte „tehnici”, cum ar fi Logout4Shell, care „folosește această vulnerabilitate împotriva sa”. Expertul în securitate pune la îndoială legalitatea acestei mișcări, care implică „piratarea unei mașini pentru a o repara”.
2. Problema a fost rezolvată în Log4j v2.17.0.
Pentru versiunile mai mari decât 2.10: Log4j2.formatMsgNoLookups ar trebui să fie setat la true.
Pentru versiunile 2.0 până la 2.10.0: Rulați următoarea comandă pentru a elimina clasa LDAP din Log4j.
Log4j2.formatMsgNoLookups ar trebui să fie setat la true în setările de sistem.
Atenuare în JVM
Atenuarea cu parametrii JVM nu mai este o opțiune. Alte metode de atenuare continuă să aibă succes. Faceți upgrade la Log4j versiunea 2.17.0 dacă este posibil. Există un ghid de migrare disponibil pentru Log4j v1.
Dacă nu este posibilă o actualizare, asigurați-vă că componentele client și server au setată proprietatea de sistem -Dlog4j2.formatMsgNoLookups = true.
Vă rugăm să rețineți că Log4j v1 a ajuns la sfârșitul duratei de viață (EOL) și nu va mai primi remedieri de erori. Alți vectori RCE sunt, de asemenea, susceptibili la Log4j v1. Prin urmare, vă recomandăm să faceți upgrade la Log4j 2.17.0 cât mai curând posibil.
3. Măsuri de atenuare
Exploatările actuale nu pot funcționa chiar dacă Log4j este susceptibil în unele cazuri, cum ar fi dacă mașina gazdă rulează o versiune Java mai mare decât 6u212, 7u202, 8u192 sau 11.0.2.
Acest lucru se datorează protecției mai bune împotriva încărcării clasei de la distanță JNDI (Java Naming and Directory Interface) în versiunile curente, care este necesară pentru ca atacul să funcționeze.
În plus, cu versiunile Log4j mai mari decât 2.10, problema poate fi evitată setând valoarea de sistem formatMsgNoLookups la true, furnizând argumentul JVM -Dlog4j2.formatMsgNoLookups = true sau ștergând clasa JndiLookup din calea clasei.
Între timp, până la remedierea instanțelor vulnerabile, vulnerabilitatea poate fi abordată folosind tehnicile de mai jos:
- Setați proprietatea de sistem log4j2.formatMsgNoLookups la true pentru >=2.10.
- Setați opțiunea de mediu LOG4J FORMAT MSG NO LOOKUPS la adevărat pentru >=2.10.
- Eliminați JndiLookup.class din calea de clasă pentru 2.0-beta9 până la 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
O bună practică recomandată este limitarea traficului de ieșire către internet doar la porturile corespunzătoare.
Deși majoritatea atacurilor din domeniu sunt livrate prin HTTP, vulnerabilitatea poate fi exploatată prin orice protocol care înregistrează datele introduse de utilizator folosind Log4j.
Cu toate acestea, actualizarea la log4j 2.17.0 este cel mai bun remediu, deoarece cineva poate descoperi o abordare suplimentară a problemei. În plus, mulți editori și producători au anunțat îmbunătățiri ale serviciilor sau aplicațiilor lor.
4. Patch de vulnerabilitate Log4Shell
Log4j este omniprezent, mai ales acum că vulnerabilitatea este exploatată. Pentru a rezuma, tot ce trebuie să faceți este să includeți următoarele caractere în jurnalele inspectate de Log4j.
Și aceasta va descărca și executa fișierul Java situat la sfârșitul adresei URL. Este pe cât de simplu, pe atât de dramatic.
După cum știți, este esențial să actualizați log4j la versiunea >= 2.17.0 pentru a remedia această vulnerabilitate Log4Shell (CVE-2021-44228).
Dacă acest lucru nu este posibil:
Pentru aplicațiile care utilizează bibliotecă Log4j versiunile 2.10.0 și ulterioare, este, de asemenea, posibil să se protejeze împotriva oricărui atac prin setarea parametrului de configurare log4j2.formatMsgNoLookups la true, de exemplu, în timp ce pornește mașina virtuală Java cu -Dlog4j2.formatMsgNoLookups = true opțiune.
O altă opțiune este să ștergeți clasa JndiLookup din argumentul classpath, care va elimina vectorul de atac primar (cercetătorii nu exclud existența unui alt vector de atac).
notițe
Organizațiile care ezită sau nu doresc să facă ajustări la sistemele susceptibile (sau care doresc să instaleze măsuri de siguranță suplimentare) ar trebui să se gândească la:
- Asigurați-vă că tot traficul este direcționat printr-un iSensor/WAF/IPS. Acest lucru poate împiedica atacul să obțină acces la sistem.
- Limitarea cantității de trafic care poate ajunge la sistemul susceptibil Dacă sistemul nu trebuie să fie conectat la internet, restricționați accesul doar la IPS și intervale esențiale și de încredere.
- Reducerea traficului de ieșire autorizat al gazdei. Deoarece acest atac operează prin conectarea la un server necinstit, toate adresele IP și porturile de prisos ar trebui blocate pe un firewall.
- Dacă serviciul nu mai este necesar, ar trebui să fie dezactivat până când este gata o remediere.
Concluzie
Defectele Log4j au șocat comunitatea noastră și ne-au reamintit tuturor cât de dependenți de software-ul open-source.
Log4j este unic. Nu este nici un sistem de operare, nici un browser, nici un software. Mai degrabă, este ceea ce programatorii se referă ca o bibliotecă, un pachet sau un modul de cod. Acesta servește doar unui scop, adică păstrarea unei evidențe a ceea ce se întâmplă pe un server.
Oamenii care scriu cod preferă să se concentreze pe ceea ce face software-ul lor distinctiv. Nu sunt interesați să reinventeze roata. Drept urmare, se bazează pe o multitudine de biblioteci de cod existente, cum ar fi Log4j.
Modulul Log4j este derivat din Apache, cel mai utilizat software de server web. De aceea poate fi descoperit pe milioane de servere. Prin urmare, creșterea amenințărilor la securitate.
Sper că soluțiile de mai sus vă ajută să vă păstrați dispozitivele în siguranță.
Rămâneți pe HashDork pentru mai multe informații utile din lumea tehnologiei.
Lasă un comentariu