Pregled sadržaja[Sakriti][Pokazati]
Log4Shell, internetska ranjivost, nedavno je zahvatila milijune strojeva. Log4j, nejasan, ali gotovo sveprisutan softver, uzrokuje to.
Log4j se koristi za bilježenje svih radnji koje se događaju iza scene u različitim računalnim sustavima.
Temelji se na biblioteci zapisnika otvorenog koda koju koriste tvrtke, pa čak i vladine organizacije u većini aplikacija.
Budući da je jedna od najgorih rupa u kibernetičkoj sigurnosti ikada otkrivenih, ključno je zaštititi svoje sustave od ove ranjivosti. Ali kako?
Istražimo detaljno Log4j ranjivost i sva moguća rješenja za popravak.
Što je Log4j?
Log4j je an open-source okvir za evidentiranje koji programerima softvera omogućuje snimanje različitih podataka unutar svojih aplikacija. To je komponenta projekta Apache Logging Services, koji vodi Apache Software Foundation.
Stotine web-mjesta i aplikacija koriste Log4j za obavljanje kritičnih operacija kao što su zapisi podataka za otklanjanje pogrešaka i druge namjene.
Kada unesete ili kliknete na lošu internetsku vezu i dobijete obavijest o pogrešci 404, ovo je čest primjer Log4j na poslu. Web-poslužitelj koji pokreće domenu web-veze kojoj ste pokušali pristupiti obavještava vas da takva web-stranica ne postoji. Također bilježi događaj u Log4j za administratore sustava poslužitelja.
U svim softverskim programima koriste se slični dijagnostički signali. U online igrici Minecraft, na primjer, poslužitelj koristi Log4j za bilježenje aktivnosti kao što je ukupna korištena RAM memorija i korisničke upute koje se šalju na konzolu.
Kako nastaje ranjivost?
Pronalaženja su nova značajka uvedena u Log4j 2.0, koja pomaže u uključivanju dodatnih informacija u unose dnevnika. Jedno od tih traženja je JNDI (Java Naming and Directory Interface) pretraživanje, što je Java API za komunikaciju s uslugom imenika.
Koristeći ovaj pristup, interni korisnički ID-ovi mogu se preslikati na stvarna korisnička imena. Ovaj upit razotkriva novootkrivenu RCE ranjivost, budući da je jedan od tipova podataka koje dostavlja LDAP poslužitelj URI koji ukazuje na Java klasu, koja se zatim učitava u memoriju i pokreće od strane Log4j instance.
Zbog slabosti u provjeri valjanosti unosa knjižnice Log4j, moguće je ubaciti proizvoljni LDAP poslužitelj iz nepouzdanog izvora. Budući da programeri pretpostavljaju da će se podaci poslani u zapisnike obrađivati kao običan tekst, ne poduzima se dodatna provjera valjanosti unosa, a opasan korisnički unos ulazi u zapisnike.
Izjava dnevnika može izgledati ovako:
Zlonamjerni korisnik bi sada u URL parametar umetnuo JNDI traženje koje se odnosi na lažni LDAP poslužitelj. JNDI traženje bi bilo kako slijedi:
Knjižnica Log4j zatim razgovara s ovim LDAP poslužiteljem na attacker.com kako bi dobila informacije o direktoriju, uključujući vrijednosti za Java Factory i Java Codebase.
Ove dvije vrijednosti uključuju napadačevu Java klasu, koja se zatim učitava u memoriju i izvršava od strane Log4j instance, dovršavajući izvršenje koda.
Tko je u riziku?
Ranjivost Log4j je nevjerojatno široka i utječe na poslovne aplikacije, ugrađene uređaje i njihove podsustave. Pogođene aplikacije uključuju Cisco Webex, Minecraft i FileZilla FTP.
Međutim, ovo nipošto nije cijeli popis. Greška čak utječe na misiju helikoptera Ingenuity Mars 2020, koja koristi Apache Log4j za snimanje događaja.
Sigurnosna zajednica je sastavila a popis ranjivih sustava. Ključno je napomenuti da se ovi popisi kontinuirano ažuriraju, pa ako određeni program ili sustav nisu istaknuti, nemojte pretpostaviti da to ne utječe.
Izloženost ovoj ranjivosti vrlo je vjerojatna, čak i ako je specifična tehnološki stog ne primjenjuje Javu, rukovoditelji sigurnosti bi trebali očekivati da to učine kritični sustavi dobavljača, SaaS dobavljači, pružatelji usluga hostinga u oblaku i pružatelji web poslužitelja.
Kako provjeriti ima li Log4j ranjivost?
Prvi korak je utvrditi je li se napad već dogodio. To možete učiniti provjeravanjem zapisnika sustava za fragmente korisnog opterećenja RCE.
Ako pretraživanje pojmova poput "jndi", "ldap" ili "$::" daje bilo kakve zapise, istraživači sigurnosti trebali bi dalje istražiti je li to bio legitiman napad ili samo uzimanje otiska prsta.
Otkriveno je mnogo napada u divljini koji nisu donijeli nikakvu štetnu korist. Unatoč tome, proveli su ih stručnjaci za sigurnost kako bi utvrdili koliko je aplikacija ranjivo na ovaj napad.
Sljedeći korak je korištenje biblioteke Log4j za identifikaciju svih projekata. Ako se koriste verzije između 2.0-beta9 i 2.14.1, projekt može biti osjetljiv.
S obzirom na poteškoće u određivanju gdje ova ranjivost postoji, može biti bolje pretpostaviti da je projekt osjetljiv i da je ažuriranje knjižnice najbolji način djelovanja za uklanjanje opasnosti od izvršenja koda.
Projekt nije ranjiv ako je korištena verzija manja od 2.0-beta 9, iako bi knjižnicu Log4j ipak trebalo nadograditi jer su verzije u rasponu 1.x stare i više ne dobivaju ažuriranja.
Bilo da se otkrije osjetljiv projekt, savjetuje se da se provjeri sadrži li bilo koja informacija zabilježena pomoću Log4j informacije koju korisnik može promijeniti. URL-ovi, parametri zahtjeva, zaglavlja i kolačići primjeri su ovih podataka. Ako se jedan od njih zabilježi, projekt je ugrožen.
Ovo znanje može vam pomoći da dublje zadubite u zapisnike sustava i utvrdite je li vaša web aplikacija već napadnuta.
Postoje besplatni online alati koji mogu otkriti je li web aplikacija ranjiva. Jedan od tih programa je Log4Shell lovkinja. On je otvorenog koda i dostupan na GitHub.
Ako se otkrije ranjivo područje koda u online aplikaciji, nosivost koju pruža otkriveni alat može se koristiti za ubacivanje u web aplikaciju. Alat za testiranje otkrio bi veze između vaše web aplikacije i njihovog LDAP poslužitelja ako je ranjivost iskorištena.
Rješenja za popravljanje ranjivosti Log4j
Prvi korak je ažuriranje Log4j, što možete učiniti korištenjem uobičajenih upravitelja paketa ili preuzimanjem izravno s ovog stranica.
Također je moguće smanjiti iskoristivost ranjivosti postavljanjem varijable okoline FORMAT MSG NO LOOKUPS na true. Ova je protumjera, međutim, primjenjiva samo na verzije Log4j veće ili jednake 2.10.
Razmotrimo sada alternativne opcije.
1. Zaobilazna rješenja za Log4j verziju 2.17.0
Svakako se preporučuje korištenje Log4j verzije 2.15.0 za zaštitu od Log4Shell-a, međutim, ako to nije moguće, dostupna su druga rješenja.
Verzije 2.7.0 i novije verzije Log4j: Izvedivo je zaštititi se od bilo kakvog napada promjenom formata događaja koji se bilježe korištenjem sintakse postotnih m nolookups podataka za podatke koje je dostavio korisnik. Ovo ažuriranje zahtijeva uređivanje konfiguracijske datoteke Log4j za generiranje nove verzije programa. Kao rezultat toga, prije implementacije ove nove verzije, faze tehničke i funkcionalne validacije moraju se ponoviti.
Log4j verzije 2.10.0 i novije: Također je moguće zaštititi se od bilo kakvog napada postavljanjem konfiguracijskog parametra log4j2.formatMsgNoLookups na true, na primjer, prilikom pokretanja Java virtualnog stroja s opcijom -Dlog4j2.” formatMsgNoLookups = true, Druga opcija je uklanjanje klase JndiLookup iz argumenta classpath, što će ukloniti glavni vektor napada (istraživači ne isključuju mogućnost drugog vektora napada).
Amazon Web Services pruža hotpatch koji se "treba koristiti na vlastitu odgovornost". Objavljene su i druge "tehnike", kao što je Logout4Shell, koji "koristi ovu ranjivost protiv sebe". Stručnjak za sigurnost dovodi u pitanje zakonitost ovog poteza, koji uključuje “hakiranje stroja kako bi se popravio”.
2. Problem je riješen u Log4j v2.17.0.
Za verzije veće od 2.10: Log4j2.formatMsgNoLookups treba postaviti na true.
Za verzije od 2.0 do 2.10.0: Pokrenite sljedeću naredbu da uklonite LDAP klasu iz Log4j.
Log4j2.formatMsgNoLookups treba biti postavljen na true u postavkama sustava.
Ublažavanje u JVM-u
Ublažavanje s JVM parametrima više nije opcija. Ostale metode ublažavanja i dalje su uspješne. Nadogradite na Log4j verziju 2.17.0 ako je moguće. Dostupan je vodič za migraciju za Log4j v1.
Ako ažuriranje nije moguće, provjerite imaju li komponente na strani klijenta i na strani poslužitelja postavljeno svojstvo sustava -Dlog4j2.formatMsgNoLookups = true.
Imajte na umu da je Log4j v1 došao do kraja životnog vijeka (EOL) i više neće primati ispravke grešaka. Ostali RCE vektori također su osjetljivi na Log4j v1. Stoga vas pozivamo da što prije nadogradite na Log4j 2.17.0.
3. Mjere ublažavanja
Trenutna eksploatacija ne može funkcionirati čak i ako je Log4j osjetljiv u nekim slučajevima, kao što je ako glavni stroj radi na verziji Jave višu od 6u212, 7u202, 8u192 ili 11.0.2.
To je zbog bolje zaštite od učitavanja udaljene klase Java imenovanja i sučelja imenika (JNDI) u trenutnim verzijama, što je neophodno za funkcioniranje napada.
Nadalje, s verzijama Log4j većim od 2.10, problem se može izbjeći postavljanjem vrijednosti sustava formatMsgNoLookups na true, pružanjem JVM argumenta -Dlog4j2.formatMsgNoLookups = true ili brisanjem klase JndiLookup iz staze klase.
U međuvremenu, dok se ranjivi slučajevi ne poprave, ranjivost se može riješiti pomoću tehnika u nastavku:
- Postavite svojstvo sustava log4j2.formatMsgNoLookups na true za >=2.10.
- Postavite opciju okruženja LOG4J FORMAT MSG NO LOOKUPS na true za >=2.10.
- Uklonite JndiLookup.class iz staze klase za 2.0-beta9 do 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Jedna preporučena najbolja praksa je ograničiti izlazni promet na internet samo na odgovarajuće portove.
Iako se većina napada na terenu isporučuje putem HTTP-a, ranjivost se može iskoristiti putem bilo kojeg protokola koji bilježi korisničke ulazne podatke koristeći Log4j.
Međutim, ažuriranje na log4j 2.17.0 najbolji je lijek jer netko može otkriti dodatni pristup problemu. Nadalje, mnogi izdavači i proizvođači najavili su poboljšanja svojih usluga ili aplikacija.
4. Zakrpa za ranjivost Log4Shell
Log4j je sveprisutan, pogotovo sada kada se ranjivost iskorištava. Ukratko, sve što trebate učiniti je uključiti sljedeće znakove u zapisnike koje je pregledao Log4j.
I to će preuzeti i izvršiti Java datoteku koja se nalazi na kraju URL-a. To je jednako jednostavno koliko i dramatično.
Kao što znate, ključno je nadograditi log4j na verziju >= 2.17.0 kako biste otklonili ovu ranjivost Log4Shell (CVE-2021-44228).
Ako ovo nije moguće:
Za aplikacije koje koriste knjižnicu Log4j verzije 2.10.0 i novije, također je moguće zaštititi se od bilo kakvog napada postavljanjem konfiguracijskog parametra log4j2.formatMsgNoLookups na true, na primjer, dok se Java virtualni stroj pokreće s -Dlog4j2.formatMsgNoLookups = true opcija.
Druga je mogućnost brisanje klase JndiLookup iz argumenta classpath, što će ukloniti primarni vektor napada (istraživači ne isključuju postojanje drugog vektora napada).
bilješke
Organizacije koje oklijevaju ili ne žele izvršiti prilagodbe osjetljivih sustava (ili koje žele uvesti dodatne zaštitne mjere) trebale bi razmisliti o:
- Provjerite je li sav promet preusmjeren kroz iSensor/WAF/IPS. To može spriječiti napad da dobije pristup sustavu.
- Ograničavanje količine prometa koji može doći do osjetljivog sustava Ako sustav ne mora biti povezan s internetom, ograničite pristup samo na bitne i pouzdane IPS i raspone.
- Smanjenje autoriziranog odlaznog prometa hosta. Budući da ovaj napad djeluje spajanjem na lažni poslužitelj, sve suvišne IP adrese i portovi trebaju biti blokirani na vatrozidu.
- Ako usluga više nije potrebna, treba je onemogućiti dok popravak nije spreman.
Zaključak
Nedostaci Log4j šokirali su našu zajednicu i podsjetili nas sve koliko se oslanjamo na softver otvorenog koda.
Log4j je jedinstven. Niti je operativni sustav, niti je preglednik, niti je softver. Umjesto toga, programeri to nazivaju bibliotekom, paketom ili kodnim modulom. Služi samo jednoj svrsi, to jest vođenju evidencije o tome što se događa na poslužitelju.
Ljudi koji pišu kod radije se koncentriraju na ono što njihov softver čini prepoznatljivim. Oni nisu zainteresirani za ponovno izmišljanje kotača. Kao rezultat toga, oslanjaju se na mnoštvo postojećih biblioteka koda, kao što je Log4j.
Modul Log4j izveden je iz Apachea, najraširenije korištenog softvera web poslužitelja. Zato se može otkriti na milijunima poslužitelja. Dakle, povećanje sigurnosnih prijetnji.
Nadam se da će vam gornja rješenja pomoći da svoje uređaje zaštitite.
Pratite HashDork za više korisnih informacija iz svijeta tehnologije.
Ostavi odgovor