Interneti-haavatavus Log4Shell mõjutas hiljuti miljoneid masinaid. Selle põhjustab varjatud, kuid peaaegu üldlevinud tarkvara Log4j.
Log4j-d kasutatakse kõigi arvutisüsteemide kulisside taga toimuvate toimingute logimiseks.
See põhineb avatud lähtekoodiga logiraamatukogul, mida ettevõtted ja isegi valitsusasutused kasutavad enamikus rakendustes.
Kuna tegemist on ühe halvima küberturbe aukudega, mis kunagi avastatud, on oluline kaitsta oma süsteeme selle haavatavuse eest. Aga kuidas?
Uurime üksikasjalikult Log4j haavatavust ja selle kõiki võimalikke lahendusi.
Mis on Log4j?
Log4j on an avatud lähtekoodiga logiraamistik, mis võimaldab tarkvaraarendajatel salvestada oma rakendustes erinevaid andmeid. See on osa Apache Logging Services projektist, mida juhib Apache Software Foundation.
Sajad veebisaidid ja rakendused kasutavad Log4j-d kriitiliste toimingute tegemiseks, näiteks andmete logimiseks silumiseks ja muuks kasutuseks.
Kui sisestate kehva võrgulingi või klõpsate sellel ja saate 404 veateate, on see Log4j sagedane näide tööl. Veebiserver, mis käitab selle veebilingi domeeni, millele proovisite juurde pääseda, teatab teile, et sellist veebilehte pole olemas. Samuti logib see serveri süsteemiadministraatorite jaoks sündmuse Log4j-s.
Kõikides tarkvaraprogrammides kasutatakse sarnaseid diagnostikasignaale. Näiteks võrgumängus Minecraft kasutab server Log4j-d selliste tegevuste (nt kogu kasutatud RAM-i ja konsooli saadetud kasutajajuhiste) logimiseks.
Kuidas haavatavus tekib?
Otsingud on Log4j 2.0-s kasutusele võetud uus funktsioon, mis aitab logikirjetesse lisateavet lisada. Üks neist otsingutest on JNDI (Java nimetamise ja kataloogi liidese) otsing, mis on Java API kataloogiteenusega suhtlemiseks.
Seda lähenemisviisi kasutades saab sisemisi kasutajatunnuseid vastendada tegelike kasutajanimedega. See päring paljastab äsja avastatud RCE haavatavuse, kuna üks LDAP-serveri pakutavatest andmetüüpidest on Java-klassile osutav URI, mis seejärel laaditakse mällu ja mida käitab Log4j eksemplar.
Log4j teegi sisendi kontrollimise nõrkuse tõttu on võimalik sisestada suvaline LDAP-server ebausaldusväärsest allikast. Kuna arendajad eeldavad, et logidesse saadetud andmeid käsitletakse lihttekstina, siis täiendavat sisendi valideerimist ei teostata ja logidesse siseneb ohtlik kasutaja sisend.
Logi avaldus võib välja näha selline:
Pahatahtlik kasutaja sisestab nüüd URL-i parameetrisse JNDI-otsingu, mis viitab petturlikule LDAP-serverile. JNDI otsing oleks järgmine:
Seejärel suhtleb Log4j teek selle LDAP-serveriga saidil attacker.com, et saada kataloogiteavet, sealhulgas Java Factory ja Java koodibaasi väärtusi.
Need kaks väärtust hõlmavad ründaja Java-klassi, mis seejärel laaditakse mällu ja käivitatakse Log4j eksemplari poolt, lõpetades koodi täitmise.
Kes on ohus?
Log4j haavatavus on uskumatult lai, mõjutades ärirakendusi, manustatud seadmeid ja nende alamsüsteeme. Mõjutatud rakenduste hulka kuuluvad Cisco Webex, Minecraft ja FileZilla FTP.
See pole aga sugugi terve nimekiri. Viga mõjutab isegi Ingenuity Mars 2020 choppermissiooni, mis kasutab sündmuste salvestamiseks Apache Log4j-d.
Turvaringkond on koostanud a haavatavate süsteemide loend. Oluline on märkida, et neid loendeid uuendatakse pidevalt, nii et kui teatud programmi või süsteemi pole esile tõstetud, ärge eeldage, et see ei ole mõjutatud.
Selle haavatavusega kokkupuude on üsna tõenäoline ja isegi konkreetne tehnikapakk ei rakenda Java, peaksid turbejuhid eeldama, et kriitilised tarnijasüsteemid, SaaS-i tarnijad, pilvemajutuse pakkujad ja veebiserveri pakkujad seda teeksid.
Kuidas kontrollida Log4j haavatavust?
Esimene samm on teha kindlaks, kas rünnak on juba toimunud. Saate seda teha, kontrollides süsteemi logides RCE kasuliku koormuse fragmente.
Kui terminite, nagu „jndi”, „ldap” või „$::” otsing annab mingeid logisid, peaksid turbeuurijad edasi uurima, kas tegemist oli legitiimse rünnaku või lihtsalt sõrmejälgede võtmisega.
Avastati palju rünnakuid looduses, mis ei toonud kaasa kahjulikke koormaid. Sellegipoolest viisid need läbi turvaeksperdid, et teha kindlaks, kui palju rakendusi selle rünnaku suhtes haavatavad.
Järgmine samm on kõigi projektide tuvastamiseks kasutada Log4j teeki. Kui kasutatakse versioone vahemikus 2.0-beta9 kuni 2.14.1, võib projekt olla vastuvõtlik.
Arvestades selle haavatavuse kindlaksmääramise raskusi, võib eelistada eeldada, et projekt on vastuvõtlik ja et teegi värskendamine on parim viis koodi käitamise ohu kõrvaldamiseks.
Projekt ei ole haavatav, kui kasutatud versioon on väiksem kui 2.0-beeta 9, kuigi Log4j teeki tuleks siiski täiendada, kuna vahemiku 1.x versioonid on vanad ega saa enam värskendusi.
Kas tundlik projekt avastatakse, on soovitatav kontrollida, kas Log4j abil logitud teave sisaldab teavet, mida kasutaja saab muuta. Nende andmete näited on URL-id, päringu parameetrid, päised ja küpsised. Kui üks neist on sisse logitud, on projekt ohus.
Need teadmised aitavad teil süsteemi logidesse süveneda ja teha kindlaks, kas teie veebirakendust on juba rünnatud.
On olemas tasuta võrgutööriistad, mis suudavad tuvastada, kas veebirakendus on haavatav. Üks neist programmidest on Log4Shelli jahimees. See on avatud lähtekoodiga ja saadaval aadressil GitHub.
Kui võrgurakenduses avastatakse haavatav koodiala, saab avalikustatud tööriista kasulikku koormust kasutada selle sisestamiseks veebirakendusse. Testimistööriist paljastab haavatavuse ärakasutamise korral teie veebirakenduse ja nende LDAP-serveri vahel loodud ühendused.
Lahendused Log4j haavatavuse parandamiseks
Esimene samm on Log4j värskendamine, mida saate teha tavalisi paketihaldureid kasutades või selle otse siit alla laadides lehekülg.
Samuti on võimalik haavatavuse kasutatavust vähendada, määrates keskkonnamuutuja FORMAT MSG NO LOOKUPS väärtuseks true. See vastumeede kehtib aga ainult Log4j versioonide puhul, mis on suuremad kui 2.10 või sellega võrdsed.
Nüüd kaalume alternatiivseid võimalusi.
1. Log4j versiooni 2.17.0 lahendused
Log4Shelli eest kaitsmiseks on kindlasti soovitatav kasutada Log2.15.0j versiooni 4, kuid kui see pole võimalik, on saadaval ka muud lahendused.
Log2.7.0j versioonid 4 ja uuemad: Igasuguse rünnaku eest on võimalik kaitsta, muutes logitavate sündmuste vormingut, kasutades kasutaja edastatud andmete protsentuaalset m nolookups süntaksit. See värskendus nõuab programmi uue versiooni loomiseks Log4j konfiguratsioonifaili redigeerimist. Seetõttu tuleb enne selle uue versiooni juurutamist tehnilisi ja funktsionaalseid valideerimisetappe korrata.
Log4j versioonid 2.10.0 ja uuemad: Samuti on võimalik kaitsta mistahes rünnete eest, määrates konfiguratsiooniparameetri log4j2.formatMsgNoLookups väärtuseks tõene, näiteks Java virtuaalmasina käivitamisel valikuga -Dlog4j2. formatMsgNoLookups = true, Teine võimalus on klassitee argumendist eemaldada klass JndiLookup, mis eemaldab peamise ründevektori (uurijad ei välista ka teise ründevektori võimalust).
Amazon Web Services pakub kiirparandust, mida "tuleb kasutada omal vastutusel". Avaldatud on ka teisi "võtteid", nagu Logout4Shell, mis "kasutab seda haavatavust enda vastu". Turvaekspert seab kahtluse alla selle sammu seaduslikkuse, mis hõlmab "masina häkkimist selle parandamiseks".
2. Probleem on lahendatud versioonis Log4j v2.17.0.
Versioonide puhul, mis on suuremad kui 2.10: Log4j2.formatMsgNoLookups tuleks määrata väärtusele Tõene.
Versioonide 2.0 kuni 2.10.0 jaoks: LDAP-klassi eemaldamiseks Log4j-st käivitage järgmine käsk.
Log4j2.formatMsgNoLookups peaks süsteemiseadetes olema seatud väärtusele Tõene.
Leevendus JVM-is
Leevendus JVM-i parameetritega pole enam võimalik. Muud leevendusmeetodid on jätkuvalt edukad. Võimalusel uuendage Log4j versioonile 2.17.0. Log4j v1 jaoks on saadaval migratsioonijuhend.
Kui värskendamine pole võimalik, veenduge, et kliendi- ja serveripoolsetel komponentidel oleks atribuudikomplekt -Dlog4j2.formatMsgNoLookups = true system.
Pange tähele, et Log4j v1 on jõudnud oma eluea lõppu (EOL) ega saa enam veaparandusi. Teised RCE vektorid on samuti vastuvõtlikud Log4j v1 suhtes. Seetõttu soovitame tungivalt minna üle Log4j versioonile 2.17.0 niipea kui võimalik.
3. Leevendusmeetmed
Praegused ärakasutamine ei saa töötada isegi siis, kui Log4j on mõnel juhul vastuvõtlik, näiteks kui hostmasin töötab Java versioonist kõrgemal kui 6u212, 7u202, 8u192 või 11.0.2.
Selle põhjuseks on parem Java nimede andmise ja kataloogiliidese (JNDI) kauglaadimiskaitse praegustes versioonides, mis on rünnaku toimimiseks vajalik.
Lisaks saab Log4j versioonide puhul, mis on suuremad kui 2.10, probleemi vältida, määrates formMsgNoLookups süsteemiväärtuse väärtuseks Tõene, esitades JVM-i argumendi -Dlog4j2.formatMsgNoLookups = true või kustutades klassitee JndiLookup klassi.
Seni, kuni haavatavad eksemplarid on parandatud, saab haavatavust kõrvaldada allolevate tehnikate abil.
- Määrake süsteemiatribuudi log4j2.formatMsgNoLookups väärtuseks tõene, kui >=2.10.
- Määrake keskkonnasuvandi LOG4J FORMAT MSG NO LOOKUPS väärtuseks tõene, kui >=2.10.
- Eemaldage JndiLookup.class klassitee 2.0-beta9 kuni 2.10.0 jaoks: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Üks soovitatav parim tava on piirata Interneti-väljundliiklust ainult sobivate portidega.
Kuigi enamik rünnakuid selles valdkonnas edastatakse HTTP kaudu, võidakse haavatavust ära kasutada mis tahes protokolli kaudu, mis logib kasutaja sisendandmed Log4j abil.
Log4j versioonile 2.17.0 värskendamine on aga parim lahendus, sest keegi võib leida probleemile täiendava lähenemisviisi. Lisaks on paljud kirjastajad ja tootjad teatanud oma teenuste või rakenduste täiustamisest.
4. Log4Shelli haavatavuse paik
Log4j on kõikjal kohal, eriti nüüd, kui haavatavust kasutatakse ära. Kokkuvõtteks pole vaja teha muud, kui lisada Log4j poolt kontrollitavatesse logidesse järgmised märgid.
Ja see laadib alla ja käivitab URL-i lõpus asuva Java-faili. See on sama otsekohene kui dramaatiline.
Nagu teate, on selle Log4Shelli haavatavuse (CVE-2.17.0-4) kõrvaldamiseks ülioluline uuendada log2021j versioonile >= 44228.
Kui see pole võimalik:
Rakenduste puhul, mis kasutavad Log4j teegi versioone 2.10.0 ja uuemaid versioone, on võimalik ka rünnakute eest kaitsta, määrates näiteks konfiguratsiooniparameetri log4j2.formatMsgNoLookups väärtuseks True, näiteks Java virtuaalmasina käivitamisel väärtusega -Dlog4j2.formatMsgNoLookups = true valik.
Teine võimalus on kustutada klassitee argumendist JndiLookup klass, mis eemaldab esmase ründevektori (uurijad ei välista teise ründevektori olemasolu).
märkused
Organisatsioonid, kes kõhklevad või ei soovi tundlikes süsteemides muudatusi teha (või kes soovivad paigaldada täiendavaid kaitsemeetmeid), peaksid mõtlema järgmisele:
- Veenduge, et kogu liiklus suunatakse läbi iSensori/WAF/IPS. See võib takistada rünnakul süsteemile juurdepääsu saamast.
- Tundlikusse süsteemi jõudva liikluse piiramine Kui süsteem ei pea olema Internetiga ühendatud, piirake juurdepääsu ainult olulistele ja usaldusväärsetele IPS-idele ja vahemikele.
- Hosti volitatud väljamineva liikluse vähendamine. Kuna see rünnak toimib võltsserveriga ühenduse loomisel, tuleks kõik üleliigsed IP-aadressid ja pordid tulemüüris blokeerida.
- Kui teenust enam ei vajata, tuleks see keelata, kuni parandus on valmis.
Järeldus
Log4j vead vapustasid meie kogukonda ja tuletasid meile kõigile meelde, kui sõltuvad me avatud lähtekoodiga tarkvarast.
Log4j on ainulaadne. See pole ei operatsioonisüsteem, brauser ega ka tarkvara. Pigem on see see, mida programmeerijad nimetavad raamatukoguks, paketiks või koodimooduliks. See teenib lihtsalt üht eesmärki, see tähendab serveris toimuva üle arvestuse pidamist.
Inimesed, kes kirjutavad koodi, eelistavad keskenduda sellele, mis teeb nende tarkvara eriliseks. Neid ei huvita ratta uuesti leiutamine. Selle tulemusena tuginevad nad paljudele olemasolevatele kooditeekidele, nagu Log4j.
Log4j moodul pärineb Apache'ist, kõige laialdasemalt kasutatavast veebiserveri tarkvarast. Seetõttu saab seda avastada miljonites serverites. Seega suureneb julgeolekuoht.
Loodan, et ülaltoodud lahendused aitavad teil oma seadmeid turvaliselt hoida.
Olge HashDorkiga kursis, et saada tehnikamaailmast rohkem kasulikku teavet.
Jäta vastus