Lacuna de securitate critică găsită în omniprezentul Log4j a trimis unde de șoc mult dincolo de industria securității cibernatice – iată ce știm până acum

Tocmai în prag de sărbători, o vulnerabilitate critică dintr-o bibliotecă de cod Apache numită Log4j 2 a venit să bată la ușă. Log4j este o bibliotecă de jurnalizare open-source bazată pe Java, care este utilizată pe scară largă de multe produse, servicii și componente Java. Nu este de mirare că defectul, care a obținut un punctaj perfect de 10 pe scara CVSS și pune nenumărate servere în pericol de preluare completă, a trimis unde de șoc mult dincolo de industria securității cibernetice.

Într-adevăr, cu codul de exploatare (demonstrat fucțional) deja disponibil online, asistăm acum la o întrecere în masă între hackeri, care efectuează scanări generale la nivel de internet și exploatează atât sistemele vulnerabile, apărători ai securității, care fac actualizări de sistem și încep să pună în aplicare măsuri de atenuare, cât și dezvoltatorii, care auditează aplicațiile și bibliotecile de cod pentru orice dependențe care ar putea include versiuni vulnerabile ale bibliotecii log4j.

Ce este Log4Shell?

Indexat ca CVE-2021-44228, defectul este o vulnerabilitate de execuție de cod la distanță (RCE), care permite unui atacator să ruleze codul la alegere pe un server afectat. În scenariul în care un intrus pătrunde în rețeaua locală, chiar și sistemele interne care nu sunt expuse internetului pot fi exploatate. Cu alte cuvinte, o vulnerabilitate RCE înseamnă că un atacator nu necesită acces fizic pentru a rula cod arbitrar, care ar putea duce la controlul complet asupra sistemelor afectate și la furtul de date sensibile.

Cronologie

Pentru a ajuta la înțelegerea evenimentelor din jurul acestei vulnerabilități critice, iată o cronologie de bază:

 - 26 noiembrie: ID-ul CVE pentru vulnerabilitate este rezervat.

 - 1 decembrie: Prima exploatare cunoscută a vulnerabilității detectată în formă brută.

 - 10 decembrie: ID-ul CVE este publicat și este lansat un patch.

 - 11 decembrie: La ora 14:24 CET, modulul ESET Network Attack Protection a primit o actualizare de detectare pentru a rezolva această vulnerabilitate.

Detectare

ESET a lansat o detectare pentru exploatările acestei vulnerabilități care ar putea fi prezente atât în ​​traficul de intrare, cât și în cel de ieșire pe sistemele Windows. Atacatorii care încearcă să se deplaseze lateral în acest tip de sisteme vor fi astfel blocați. Detectarea încercărilor de exploatare a fost lansată cu următoarele nume de detectare:

 - JAVA/Exploit.CVE-2021-44228

 - JAVA/Exploit.CVE-2021-44228.B

#BREAKING #ESETresearch heatmap shows hundreds of thousands of blocked #log4j exploitation attempts most of which were in the ??US, ??the UK, ??Turkey, ??Germany and ??the Netherlands. Find out more about the vulnerability in our blogpost: https://t.co/J7tfY8NXFh pic.twitter.com/F4RGwO2sIG

— ESET research (@ESETresearch) December 14, 2021

Etape de atenuare

Pentru a vă proteja de exploatări rău intenționate, este esențial să găsiți toate versiunile vulnerabile ale bibliotecii. Începeți prin a face o listă prioritizată de sisteme prin care să căutați, evaluându-le unul câte unul pe măsură ce parcurgeți lista. Partea dificilă poate fi identificarea versiunilor vulnerabile existente în arhivele Java Archive (JAR) ca dependențe tranzitive.

Iată câteva scripturi de bază pe care le puteți utiliza (care ar trebui modificate pentru a se potrivi cu sistemele dvs.):

1. Detectați prezența Log4j în sistemele dvs.  (Linux, Windows)

Acest script, disponibil pe GitHub, caută fișierul defect JndiLookup.class în orice arhivă .jar de pe sistemul dumneavoastră.

Linux

sudo grep -r --include "*.jar" JndiLookup.class /

Windows

findstr /s /i /c:"JndiLookup.class" C:\*.jar

2. Detectați încercările de exploatare a vulnerabilității în jurnalele dvs. de logare  (Linux)

Acest script, disponibil și el pe GitHub (vezi linkul de mai sus), caută încercări de exploatare în fișierele necomprimate din directorul de jurnale Linux /var/log și în toate subdirectoarele sale:

Grep

sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log

Zgrep

sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+'

3. Înregistrați rezultatele

După rularea oricăror scripturi sau instrumente de detectare, asigurați-vă că înregistrați rezultatele pentru a ajuta la crearea unei documentații complete de analiză a tuturor sistemelor dumneavoastră. Un audit ar trebui să precizeze dacă ați găsit Log4j pe un sistem și dacă au fost descoperite încercări de exploatare în jurnale.

4. Treceți la cea mai recentă versiune de Log4j

Versiunile vulnerabile ale Log4j 2 sunt toate versiunile log4j-core de la 2.0-beta9 la 2.14.1. Rețineți că această bibliotecă nu trebuie confundată cu log4j-api, care nu este afectată de această vulnerabilitate. Cel mai bun remediu este să vă actualizați toate sistemele si aplicațiile pentru a utiliza cea mai recentă versiune, care este 2.15.0.

Deși versiunile 1.x ale Log4j nu sunt afectate de această vulnerabilitate specială, ele au și alte puncte sensibile. Ar trebui să elaborați planuri concrete pentru a migra la cea mai recentă versiune a bibliotecii. De fapt, acum este un moment foarte bun pentru a merge mai departe cu acele planuri.

5. Blocați adresele IP suspecte

În cele din urmă, adresele IP despre care se știe că sunt suspecte pot fi blocate cu firewall și/sau sistemul de prevenire a intruziunilor.

Sfaturile tehnice ESET adresate clienților, dedicate Log4j2, sunt disponibile aici.