Saturs[Paslēpt][Rādīt]
Interneta ievainojamība Log4Shell nesen skāra miljoniem mašīnu. Log4j, neskaidra, taču gandrīz visuresoša programmatūra, to izraisa.
Log4j tiek izmantots, lai reģistrētu visas darbības, kas notiek dažādu datorsistēmu aizkulisēs.
Tā ir balstīta uz atvērtā pirmkoda reģistrēšanas bibliotēku, ko lielākajā daļā lietojumprogrammu izmanto uzņēmumi un pat valdības organizācijas.
Tā kā tā ir viena no sliktākajām kiberdrošības problēmām, kas jebkad atklāta, ir ļoti svarīgi aizsargāt jūsu sistēmas no šīs ievainojamības. Bet kā?
Detalizēti izpētīsim Log4j ievainojamību un visus iespējamos tās labošanas risinājumus.
Kas ir Log4j?
Log4j ir an atvērtais avots reģistrēšanas sistēma, kas programmatūras izstrādātājiem ļauj savās lietojumprogrammās ierakstīt dažādus datus. Tā ir daļa no Apache Logging Services projekta, ko vada Apache Software Foundation.
Simtiem vietņu un lietotņu izmanto Log4j, lai veiktu kritiskas darbības, piemēram, reģistrētu datus atkļūdošanai un citiem mērķiem.
Kad ievadāt vai noklikšķināt uz sliktas tiešsaistes saites un saņemat 404 kļūdas paziņojumu, šis ir bieži sastopams Log4j piemērs darbā. Tīmekļa serveris, kas vada tās tīmekļa saites domēnu, kurai mēģinājāt piekļūt, informē, ka šādas tīmekļa lapas nav. Tas arī reģistrē notikumu log4j servera sistēmas administratoriem.
Visās programmatūras programmās tiek izmantoti līdzīgi diagnostikas signāli. Piemēram, tiešsaistes spēlē Minecraft serveris izmanto Log4j, lai reģistrētu darbības, piemēram, kopējo izmantoto RAM un lietotāja instrukcijas, kas nosūtītas konsolei.
Kā rodas ievainojamība?
Uzmeklēšana ir jauns līdzeklis, kas ieviests programmā Log4j 2.0, kas palīdz žurnāla ierakstos iekļaut papildu informāciju. Viens no šiem meklējumiem ir JNDI (Java nosaukumu piešķiršanas un direktoriju saskarnes) uzmeklēšana, kas ir Java API saziņai ar direktoriju pakalpojumu.
Izmantojot šo pieeju, iekšējos lietotāju ID var kartēt ar faktiskajiem lietotāju vārdiem. Šis vaicājums atklāj jaunatklāto RCE ievainojamību, jo viens no LDAP servera nodrošinātajiem datu veidiem ir URI, kas norāda uz Java klasi, kas pēc tam tiek ielādēta atmiņā un tiek darbināta ar Log4j gadījumu.
Log4j bibliotēkas ievades validācijas vājuma dēļ ir iespējams ievadīt patvaļīgu LDAP serveri no neuzticama avota. Tā kā izstrādātāji pieņem, ka dati, kas nosūtīti uz žurnāliem, tiks apstrādāti kā vienkāršs teksts, papildu ievades validācija netiek veikta, un žurnālos tiek ievadīta bīstama lietotāja ievade.
Žurnāla paziņojums varētu izskatīties šādi:
Ļaunprātīgs lietotājs tagad URL parametrā ievieto JNDI uzmeklēšanu, atsaucoties uz negodīgu LDAP serveri. JNDI meklēšana būtu šāda:
Log4j bibliotēka pēc tam sarunājas ar šo LDAP serveri vietnē attacker.com, lai iegūtu direktoriju informāciju, tostarp Java Factory un Java Codebase vērtības.
Šīs divas vērtības ietver uzbrucēja Java klasi, kas pēc tam tiek ielādēta atmiņā un tiek izpildīta Log4j instancē, pabeidzot koda izpildi.
Kurš ir pakļauts riskam?
Log4j ievainojamība ir neticami plaša, ietekmējot biznesa lietojumprogrammas, iegultās ierīces un to apakšsistēmas. Ietekmētās lietotnes ir Cisco Webex, Minecraft un FileZilla FTP.
Tomēr tas nekādā gadījumā nav viss saraksts. Trūkums pat ietekmē Ingenuity Mars 2020 smalcinātāja misiju, kas notikumu ierakstīšanai izmanto Apache Log4j.
Drošības aprindas ir apkopojušas a neaizsargāto sistēmu saraksts. Ir svarīgi ņemt vērā, ka šie saraksti tiek nepārtraukti atjaunināti, tādēļ, ja noteikta programma vai sistēma netiek piedāvāta, nedomājiet, ka tā netiek ietekmēta.
Pakļaušana šai ievainojamībai ir diezgan iespējama, un pat tad, ja tā ir specifiska tehnikas kaudze neattiecas uz Java, drošības vadītājiem vajadzētu sagaidīt, ka to darīs kritiskās piegādātāju sistēmas, SaaS piegādātāji, mākoņa mitināšanas pakalpojumu sniedzēji un tīmekļa serveru nodrošinātāji.
Kā pārbaudīt Log4j ievainojamību?
Pirmais solis ir noteikt, vai uzbrukums jau ir noticis. To var izdarīt, pārbaudot sistēmas žurnālos RCE lietderīgās slodzes fragmentus.
Ja, meklējot tādus vārdus kā “jndi”, “ldap” vai “$::”, tiek iegūti žurnāli, drošības pētniekiem vajadzētu sīkāk izpētīt, vai tas bija likumīgs uzbrukums vai tikai pirkstu nospiedumu noņemšana.
Tika atklāti daudzi uzbrukumi savvaļā, kas nenogādāja nekādas kaitīgas kravas. Tomēr tos veica drošības eksperti, lai noteiktu, cik daudz lietotņu bija neaizsargātas pret šo uzbrukumu.
Nākamais solis ir izmantot Log4j bibliotēku, lai identificētu visus projektus. Ja tiek izmantotas versijas no 2.0-beta9 līdz 2.14.1, projekts var būt jutīgs.
Ņemot vērā grūtības noteikt, kur šī ievainojamība pastāv, var būt vēlams pieņemt, ka projekts ir jutīgs un ka bibliotēkas atjaunināšana ir labākais veids, kā novērst koda izpildes risku.
Projekts nav ievainojams, ja izmantotā versija ir mazāka par 2.0-beta 9, lai gan Log4j bibliotēka joprojām ir jājaunina, jo 1.x diapazona versijas ir vecas un vairs nesaņem atjauninājumus.
Neatkarīgi no tā, vai tiek atklāts jutīgs projekts, ieteicams pārbaudīt, vai informācija, kas reģistrēta, izmantojot Log4j, satur informāciju, ko lietotājs var mainīt. Šo datu piemēri ir vietrāži URL, pieprasījuma parametri, galvenes un sīkfaili. Ja kāds no tiem ir reģistrēts, projekts ir apdraudēts.
Šīs zināšanas var palīdzēt jums iedziļināties sistēmas žurnālos un noteikt, vai jūsu tīmekļa lietojumprogramma jau ir uzbrukusi.
Ir bezmaksas tiešsaistes rīki, kas var noteikt, vai tīmekļa lietojumprogramma ir neaizsargāta. Viena no šīm programmām ir Log4Shell medniece. Tas ir atvērtā koda avots un pieejams vietnē GitHub.
Ja tiešsaistes lietojumprogrammā tiek atklāts ievainojams koda apgabals, atklātā rīka sniegto lietderīgo slodzi var izmantot, lai to ievadītu tīmekļa lietojumprogrammā. Pārbaudes rīks atklātu savienojumus starp jūsu tīmekļa lietojumprogrammu un to LDAP serveri, ja ievainojamība tiktu izmantota.
Risinājumi Log4j ievainojamības novēršanai
Pirmais solis ir atjaunināt Log4j, ko varat izdarīt, izmantojot parastos pakotņu pārvaldniekus vai lejupielādējot to tieši no šī lappuse.
Ir iespējams arī samazināt ievainojamības izmantojamību, iestatot vides mainīgo FORMAT MSG NO LOOKUPS uz True. Tomēr šis pretpasākums ir piemērojams tikai Log4j versijām, kas ir lielākas vai vienādas ar 2.10.
Tagad apsvērsim alternatīvas iespējas.
1. Risinājumi Log4j versijai 2.17.0
Noteikti ir ļoti ieteicams izmantot Log4j versiju 2.15.0, lai aizsargātu pret Log4Shell, taču, ja tas nav iespējams, ir pieejami citi risinājumi.
Log2.7.0j versijas 4 un jaunākas versijas: Ir iespējams aizsargāt pret jebkuru uzbrukumu, mainot reģistrējamo notikumu formātu, izmantojot lietotāja sniegto datu procentuālo nolookups sintaksi. Šim atjauninājumam ir jārediģē Log4j konfigurācijas fails, lai ģenerētu jaunu programmas versiju. Rezultātā pirms šīs jaunās versijas izvietošanas ir jāatkārto tehniskās un funkcionālās validācijas posmi.
Log4j versijas 2.10.0 un jaunākas versijas: Tāpat ir iespējams aizsargāties pret jebkuru uzbrukumu, iestatot log4j2.formatMsgNoLookups konfigurācijas parametru uz true, piemēram, startējot Java virtuālo mašīnu ar opciju -Dlog4j2. formatMsgNoLookups = true, Vēl viena iespēja ir noņemt klasi JndiLookup no classpath argumenta, kas noņems galveno uzbrukuma vektoru (pētnieki neizslēdz cita uzbrukuma vektora iespēju).
Amazon Web Services nodrošina labojumfailu, kas "vajadzētu izmantot uz jūsu risku". Ir publicētas citas “metodes”, piemēram, Logout4Shell, kas “izmanto šo ievainojamību pret sevi”. Drošības eksperts apšauba šīs darbības likumību, kas ietver "mašīnas uzlaušanu, lai to salabotu".
2. Problēma ir atrisināta Log4j v2.17.0.
Versijām, kas ir lielākas par 2.10: Log4j2.formatMsgNoLookups ir jāiestata uz True.
Versijām 2.0–2.10.0: palaidiet šo komandu, lai noņemtu LDAP klasi no Log4j.
Log4j2.formatMsgNoLookups sistēmas iestatījumos ir jāiestata uz True.
Mīkstināšana JVM
Seku mazināšana ar JVM parametriem vairs nav iespējama. Citas mazināšanas metodes joprojām ir veiksmīgas. Ja iespējams, jauniniet uz Log4j versiju 2.17.0. Log4j v1 ir pieejams migrācijas ceļvedis.
Ja atjaunināšana nav iespējama, pārliecinieties, vai klienta un servera puses komponentiem ir -Dlog4j2.formatMsgNoLookups = true system rekvizītu kopa.
Lūdzu, ņemiet vērā, ka Log4j v1 ir sasniedzis savas dzīves beigas (EOL) un vairs nesaņems kļūdu labojumus. Arī citi RCE vektori ir jutīgi pret Log4j v1. Tāpēc mēs aicinām jūs pēc iespējas ātrāk jaunināt uz Log4j 2.17.0.
3. Seku mazināšanas pasākumi
Pašreizējie ekspluatācijas veidi nevar darboties pat tad, ja Log4j dažos gadījumos ir jutīgs, piemēram, ja resursdatorā darbojas Java versija, kas ir augstāka par 6u212, 7u202, 8u192 vai 11.0.2.
Tas ir saistīts ar labāku Java nosaukumu piešķiršanas un direktoriju saskarnes (JNDI) attālās klases ielādes aizsardzību pašreizējās versijās, kas ir nepieciešama uzbrukuma darbībai.
Turklāt ar Log4j versijām, kas ir lielākas par 2.10, problēmu var novērst, iestatot formatMsgNoLookups sistēmas vērtību uz True, nodrošinot JVM argumentu -Dlog4j2.formatMsgNoLookups = true vai dzēšot JndiLookup klasi no klases ceļa.
Tikmēr, kamēr neaizsargātie gadījumi nav novērsti, ievainojamību var novērst, izmantojot tālāk norādītās metodes.
- Iestatiet sistēmas rekvizītu log4j2.formatMsgNoLookups uz true >=2.10.
- Iestatiet vides opciju LOG4J FORMAT MSG NO LOOKUPS uz true >=2.10.
- Noņemiet JndiLookup.class no klases ceļa 2.0-beta9 uz 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Viena ieteicamā paraugprakse ir ierobežot izejas trafiku uz internetu tikai ar atbilstošajiem portiem.
Lai gan lielākā daļa uzbrukumu šajā jomā tiek piegādāti, izmantojot HTTP, ievainojamība var tikt izmantota, izmantojot jebkuru protokolu, kas reģistrē lietotāja ievades datus, izmantojot Log4j.
Tomēr atjaunināšana uz log4j 2.17.0 ir labākais risinājums, jo kāds var atklāt papildu pieeju problēmai. Turklāt daudzi izdevēji un ražotāji ir paziņojuši par savu pakalpojumu vai lietotņu uzlabojumiem.
4. Log4Shell ievainojamības ielāps
Log4j ir visuresošs, it īpaši tagad, kad tiek izmantota ievainojamība. Apkopojot, viss, kas jums jādara, ir Log4j pārbaudītajos žurnālos jāiekļauj šādas rakstzīmes.
Un tas lejupielādēs un izpildīs Java failu, kas atrodas URL beigās. Tas ir tikpat vienkārši, cik dramatiski.
Kā jūs zināt, ir ļoti svarīgi jaunināt log4j uz versiju >= 2.17.0, lai novērstu šo Log4Shell ievainojamību (CVE-2021-44228).
Ja tas nav iespējams:
Lietojumprogrammām, kas izmanto Log4j bibliotēkas versijas 2.10.0 un jaunākas, ir iespējams arī aizsargāt pret jebkādiem uzbrukumiem, iestatot konfigurācijas parametru log4j2.formatMsgNoLookups uz True, piemēram, startējot Java virtuālo mašīnu ar -Dlog4j2.formatMsgNoLookups = true opciju.
Vēl viena iespēja ir dzēst JndiLookup klasi no argumenta classpath, kas noņems primāro uzbrukuma vektoru (pētnieki neizslēdz cita uzbrukuma vektora esamību).
Piezīmes
Organizācijām, kuras vilcinās vai nevēlas veikt pielāgojumus jutīgajās sistēmās (vai kuras vēlas uzstādīt papildu aizsardzības līdzekļus), ir jādomā par:
- Pārliecinieties, ka visa satiksme tiek maršrutēta caur iSensor/WAF/IPS. Tas var neļaut uzbrukumam piekļūt sistēmai.
- Trafika apjoma ierobežošana, kas var sasniegt jutīgo sistēmu Ja sistēmai nav jābūt savienotai ar internetu, ierobežojiet piekļuvi tikai svarīgam un uzticamam IPS un diapazoniem.
- Saimnieka atļautās izejošās trafika samazināšana. Tā kā šis uzbrukums darbojas, izveidojot savienojumu ar negodīgu serveri, visas liekās IP adreses un porti ir jābloķē ugunsmūrī.
- Ja pakalpojums vairs nav nepieciešams, tas ir jāatspējo, līdz ir gatavs labojums.
Secinājumi
Log4j trūkumi šokēja mūsu kopienu un atgādināja mums visiem, cik mēs esam atkarīgi no atvērtā pirmkoda programmatūras.
Log4j ir unikāls. Tā nav ne operētājsistēma, ne pārlūkprogramma, ne programmatūra. Drīzāk programmētāji to dēvē par bibliotēku, paketi vai koda moduli. Tas kalpo tikai vienam mērķim, tas ir, serverī notiekošo uzskaitei.
Cilvēki, kuri raksta kodu, dod priekšroku koncentrēties uz to, kas padara viņu programmatūru atšķirīgu. Viņi nav ieinteresēti izgudrot riteni no jauna. Rezultātā viņi paļaujas uz daudzām esošajām kodu bibliotēkām, piemēram, Log4j.
Log4j modulis ir iegūts no Apache, visplašāk izmantotās tīmekļa servera programmatūras. Tāpēc to var atklāt miljonos serveru. Tādējādi palielinās drošības draudi.
Ceru, ka iepriekš minētie risinājumi palīdzēs nodrošināt ierīču drošību.
Sekojiet līdzi HashDork, lai iegūtu noderīgāku informāciju no tehnoloģiju pasaules.
Atstāj atbildi