Kritiska ievainojamība Java bibliotēkā log4j
Lai gan decembris vēl nav beidzies, var ar pārliecību apgalvot, ka nupat atklātais caurums log4j žurnalēšanas bibliotēkā kļūs par vienu no gada lielākajiem incidentiem.
Atklātā ievainojamība “log4shell” ļauj uzbrucējam palaist sistēmā patvaļīgu kodu, injicējot strādājošajā Java programmā savu klasi, piemēram ar LDAP protokola starpniecību:
Tā kā log4j ir ļoti populāra bibliotēka Java pasaulē, tad kopā ar to ievainojami kļuvuši visi produkti un servisi, kas no tās atkarīgi. Tādu produktu skaits ir mērāms simtos, daudzi no tiem — tirgus līderi ar lielu klientu skaitu.
Kas ir log4shell ievainojamība?
Kad problēma atklāta?
Problēma pamanīta un novērsta decembra sākumā, taču tā netika atpazīta kā kritiska drošības problēma. Plaša pasaule par log4j ievainojamību un tās potenciālu uzzināja tikai pagājušās nedēļas beigās, kad to sāka izmantot Minecraft spēļu serveros.
Nosūtot neparasta satura tekstu Minecraft čatā bija iespējams uzlauzt citu spēlētāju datorus (kas izmanto Java versiju) un pat spēles serverus.
Kāds ir ievainojamības efekts?
Sliktākajā gadījumā var panākt Remote Code Execution, t.i. patvaļīgā koda izpildi, sk. demonstrāciju:
Eksploitam populārākajā formā ir divas daļas: pirmā daļa veic LDAP pieprasījumu, pieslēdzoties uzbrucēju kontrolētam serverim; otrā daļa lejupielādē Java izpildāmo kodu no uzbrucēju web servera.
- Pirmā daļa, kas rada informācijas atklāšanas risku, darbojas visur pie nosacījuma, ka tiek izmantota ievainojama Log4j versija.
Savukārt otrā daļa pēc noklusējuma tiek bloķēta ar standarta JVM iestatījumiem, sākot ar 8u191 (UPD: Ir atrasti vairāki apvedceļi, kas ļauj panākt RCE neatkarībā no JVM versijas uncom.sun.jndi.rmi.object.trustURLCodebase=false).trustURLCodebasevērtības.
Taču kā atklājās praksē, daudzi produkti maina JVM iestatījumus vai arī izmanto alternatīvu JVM implementāciju, rezultātā šie produkti ir ievainojami un tie nekavējoties jāatjaunina.
Jāpiebilst, ka pamatproblēma — JNDI var tikt ekspluatēta vairākos veidos, ne tikai kombinācijā ar LDAP, tāpēc konkrētiem produktiem iespējami specifiski eksploiti.
Cik vienkārši izmantot šo ievainojamību?
Vairumā gadījumu sarežģītākā daļa ir piemeklēt informāciju, kas tiek rakstīta žurnālfailos.
“Low hanging fruit” tipa masveida uzbrukumi fokusējas uz acīmredzamiem headeriem — User-Agent un Api-Key. Sistēmas, kas ir ievainojamas un žurnalē šos parametrus tiks uzlauztas pirmajā kārtā.
Daudzas citas sistēmas ar sarežģītāku arhitektūru šķietami netiks ietekmētas šajos sākotnējos uzbrukumos, taču tās joprojām var būt ievainojamas. Teiksim, web frontends var izmantot citu programmēšanas valodu vai framework, bet daļa datu tiek papildus analizēta ar Java bāzētu risinājumu, kas ir ievainojams. Uzbrucēju uzdevums šajā gadījumā ir piemeklēt tādu user input, kas tiek ielogots un notrigerē eksploitu (iespējams dians vēlāk).
Atsevišķi jāpiemin sistēmas, kuras vispār pamatā žurnalēšanu neveic, taču uzbrucējs var izraisīt kļūdas stāvokli, kas tad tiek ielogots un notrigerē eksploitu.
Kā pasargāties no log4shell ievainojamības?
Visdrošākais aizsardzības veids, bez šaubām, ir log4j bibliotēkas atjaunošana. Taču vairumā gadījumu šim risinājumam ir nepieciešama izstrādātāju iesaiste vai vendora atbalsts.
Čehijas GovCert ir publicējis labu infografiku, kas apkopo alternatīvās mitigācijas, kas pieejamas, ja nav iespējams pietiekami ātri ieviest log4j ielāpus:
Jāatzīmē, ka plašas pieejamās JNDI funkcionalitātes dēļ (kas turklāt darbojas rekursīvi) WAF nevar sniegt pilnīgu aizsardzību no visiem uzbrukumiem, lai gan visiem populāriem risinājumiem jāspēj atvairīt vismaz visbiežākie masveida uzbrukumi.
Savukārt mitigācijas, kas paļaujas uz JNDI funkcionalitātes atslēgšanu vai ierobežošanu, ir riskantas dēļ cilvēcīgiem faktoriem — konfigurācija var tikt ieviesta nepareizi, ne līdz galam vai tā var būt pārrakstīta. Drošākais veids šajos gadījumos ir pārliecināties, ka problēma ir novērsta, veicot ielaušanās testus pret savu sistēmu.
Kopsavilkums
“Log4shell” ievainojamība ir bezprecedenta, bet labi iederas 2021. gadā, ilustrējot piegādes ķēžu drošības problēmas.
Ētiskajiem hakeriem / pentesteriem noteikti jāiemācās atpazīt un izmantot praksē šo ievainojamību, jo daudzās sistēmās tā paliks neatrisināta vairākus gadus.