Pred nekaj tedni je novica o varnostnih težavah Log4j številne uporabnike omrežja obrnila na glavo in gre za eno od pomanjkljivosti, ki so jo najbolj izkoriščali in jo številni strokovnjaki označili za "najnevarnejšo v dolgem času", Od ranljivosti, ki so bile znane v omrežju, govorimo o nekaterih tukaj na blogu in tokrat smo našli novico drugega.
In to je pred nekaj dnevi objavljena je bila novica, da je bila v knjižnici Log4j 2 ugotovljena še ena ranljivost (ki je že naveden pod CVE-2021-45105) in je bil za razliko od prejšnjih dveh zadev razvrščen kot nevaren, vendar ne kritičen.
Nova težava omogoča zavrnitev storitve in se kaže v obliki zank in nenormalnih zaključkov pri obdelavi določenih vrstic.
Ranljivost vpliva na sisteme, ki uporabljajo iskanje po kontekstu, kot je $ {ctx: var}, da določite izhodni format dnevnika.
The Log4j različice 2.0-alpha1 do 2.16.0 niso imele zaščite pred nenadzorovano rekurzijo, kaj je napadalcu omogočilo, da manipulira z vrednostjo, uporabljeno pri zamenjavi povzroči neskončno zanko, pri kateri bi zmanjkalo prostora na skladu in povzročilo, da se proces obesi. Zlasti je prišlo do težave pri zamenjavi vrednosti, kot je "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Poleg tega, Omeniti je mogoče, da so raziskovalci Blumire predlagali napad na ranljive aplikacije Java ki ne sprejemajo zahtev iz zunanjih omrežij, na primer sisteme razvijalcev ali uporabnikov aplikacij Java lahko napadete na ta način.
Bistvo metode je, da če obstajajo ranljivi procesi Java v uporabnikovem sistemu, ki sprejema omrežne povezave samo iz lokalnega gostitelja (localhost) ali obdeluje zahteve RMI (remote Method Invocation, vrata 1099), napad se lahko izvede z izvršeno kodo JavaScript ko uporabnik v brskalniku odpre zlonamerno stran. Za vzpostavitev povezave z omrežnimi vrati aplikacije Java v takem napadu se uporablja API WebSocket, za katerega se za razliko od zahtev HTTP ne uporabljajo omejitve istega izvora (WebSocket se lahko uporablja tudi za skeniranje omrežnih vrat na lokalnem gostitelja za določitev razpoložljivih omrežnih gonilnikov).
Zanimivi so tudi rezultati ocenjevanja ranljivosti knjižnic, povezanih z odvisnostmi od Log4j, ki jih je objavil Google. Po Googlovih podatkih težava prizadene 8 % vseh paketov v skladišču Maven Central.
Zlasti 35863 paketov Java, povezanih z Log4j, z neposrednimi in posrednimi odvisnostmi je bilo izpostavljenih ranljivosti. Log4j se kot neposredna odvisnost prve stopnje uporablja le v 17 % primerov, v 83 % paketov, ki jih pokriva ranljivost, pa se vezava izvede prek vmesnih paketov, ki so odvisni od Log4j, torej tell. odvisnosti druge in najvišje stopnje (21% - druga raven, 12% - tretja, 14% - četrta, 26% - peta, 6% - šesta).
Stopnja popravljanja ranljivosti še vedno pušča veliko želenega, teden dni po odkritju ranljivosti je bila od 35863 identificiranih paketov težava doslej odpravljena le pri 4620, torej na 13%.
Spremembe paketa so potrebne za posodobitev zahtev glede odvisnosti in zamenjavo povezav stare različice s fiksnimi različicami Log4j 2 (paketi Java izvajajo vezavo na določeno različico in ne na odprt obseg, ki omogoča namestitev najnovejše različice).
Odpravljanje ranljivosti v aplikacijah Java ovira dejstvo, da programi pogosto vključujejo kopije knjižnic v dobavi in ni dovolj, da posodobite različico Log4j 2 v sistemskih paketih.
Medtem je ameriška agencija za zaščito infrastrukture in kibernetsko varnost izdala direktivo za nujne primere, ki od zveznih agencij zahteva, da pred 4. decembrom identificirajo informacijske sisteme, na katere vpliva ranljivost Log23j, in namestijo posodobitve, ki blokirajo težavo.
Po drugi strani pa je bila dana smernica do 28. decembra, v kateri so imele organizacije obveznost poročanja o opravljenem delu. Za poenostavitev identifikacije problematičnih sistemov je pripravljen seznam izdelkov, pri katerih je bila potrjena manifestacija ranljivosti (na seznamu je več kot 23 tisoč aplikacij).
Končno, Omeniti velja, da je bila ranljivost odpravljena v Log4j 2.17, ki je bil objavljen pred nekaj dnevi in uporabnikom, ki imajo onemogočene posodobitve, priporočamo, da izvedejo ustrezno posodobitev, poleg tega, da nevarnost ranljivosti omili tudi dejstvo, da se težava kaže le v sistemih z Javo 8.
vir: https://logging.apache.org/