Kõik Log4j, logiback vead, millest me seni teame ja miks peaksite 2.15 loobuma


Nüüdseks on kõik kuulnud kriitilisest log4j nullpäevast. 'Log4Shelliks' ja 'Logjamiks' nimetatud haavatavus pani Interneti põlema.

Seni on log4j haavatavust, mida jälgitakse kui CVE-2021-44228, kuritarvitanud kõikvõimalikud ohus osalejad, alates riigi toetatud häkkeritest kuni lunavararühmadeni ja teisteni, et süstida Monero kaevureid haavatavatesse süsteemidesse.

Log4j kasutamine on paljude tarkvaratoodete seas laialt levinud ja sellest ajast peale on ilmunud mitme müüja hoiatused. Ja nüüd tundub, et isegi sisselogimine pole nii immuunne.



Allpool võtame kokku mitmed seni tuvastatud asjakohased CVE-d ja head põhjused, miks loobuda log4j versioonist 2.15.0, asendades selle versiooniga 2.16.0.

Mida peaksin kõigi CVE-de pärast muretsema?

Kõik sai alguse eelmisel neljapäeval, 9. detsembril, kui GitHubi tabas Log4j jaoks kriitiline nullpäevane PoC ärakasutamine.

Järgnes haavatavuse avalikustamine ja massiline skaneerimine ründaja tegevus, mis on suunatud haavatavatele serveritele.

Arvestades Log4j laialdast kasutamist enamikus Java rakendustes, sai Log4Shelist kiiresti õudusunenägu ettevõtetele ja valitsustele üle kogu maailma.

Siin on CVE-d nende ilmumise järjekorras, millest peaksite teadma:

    CVE-2021-44228 [kriitiline]Märkus. Algne 'Log4Shelli' või 'logjam'i haavatavus on ebausaldusväärne deserialiseerimisviga. See on hinnatud raskusastme poolest kriitiliseks, CVSS-i skaalal 10 ja annab autentimata ründajatele koodi kaugkäivitamise (RCE) võimalused, võimaldades süsteemi täielikku hõivamist.

    Chen Zhaojun Alibaba pilveturbe meeskonnast teatas Apache'ile 24. novembril, CVE-2021-44228 mõjutab mitme Apache raamistiku vaikekonfiguratsioone, sealhulgas Apache Struts2, Apache Solr, Apache Druid, Apache Flink ja teised.

    Olles kõige ohtlikum, peitub see haavatavus log4j-core komponendis, mis on piiratud 2.x versiooniga: alates 2.0-beta9 kuni 2.14.1 (kaasa arvatud). Log4Shelli parandus rakendati versioonis 2.15.0, kuid seda peeti mittetäielikuks (loe edasi).

    Küberohtude analüütik Florian Roth jagas Sigma reegleid [1, 2], mida saab kasutada ühe kaitsevahendina.

    CVE – 2021-45046 [Madal]:Hinnanguliselt madala raskusastmega, see on teenuse keelamise (DoS) viga, mille hind on ainult 3,7. Viga tekkis mittetäieliku paranduse tõttu, mis läks versioonile 2.15.0 CVE-2021-44228 jaoks. Kuigi versioonile 2.15.0 rakendatud parandus lahendas probleemi suures osas, ei kehtinud see mõne mittevaikekonfiguratsiooni puhul.

    Log4j 2.15.0 teeb 'parima katse' piirata LDAP JNDI otsinguid kohalik host vaikimisi. Kuid ründajad, kellel on kontroll Thread Context Map (MDC) sisendandmete üle, võivad DoS-i rünnakute tekitamiseks luua JNDI otsingumallide kaudu pahatahtlikke kasulikke koormusi. See kehtib mittevaikekonfiguratsioonide kohta, kus mittevaikemalli paigutus kasutab kontekstiotsingut (nt $${ctx:loginId}) või lõime kontekstikaardi malli (%X, %mdc või %mdc) .

    'Log4j 2.16.0 lahendab selle probleemi, eemaldades sõnumiotsingu mallide toe ja keelates vaikimisi JNDI funktsioonid, ' ütleb NVD nõustaja. 2.12.1 haru kasutajate jaoks viidi parandus tagasi versioonile 2.12.2.

    CVE-2021-4104 [kõrge] : Kas me mainisime, et Log4j 2.x versioonid olid haavatavad? Aga Log4j 1.x?

    Kuigi varem arvati, et see on turvaline, on Log4Shell leidnud ka võimaluse end vanasse Log4j sisse peita. Põhimõtteliselt on Log4j 1.x eksemplaride vaikekonfiguratsioonist erinev JMSAppender klass muutub vastuvõtlikuks ka ebausaldusväärsele deserialiseerimisveale.

    Kuigi see on CVE-2021-44228 vähem tõsine variant, mõjutab see CVE kõiki komponentide log4j:log4j ja org.apache.log4j:log4j versioone, mille jaoks on olemas ainult 1.x versioon. Kuna tegemist on kasutusea lõppväljaannetega, pole 1.x haru parandust kusagil olemas ja seda tuleb värskendada log4j-core 2.16.0.

    CVE-2021-42550 [Mõõdukas]:See on Logbacki logimise raamistiku haavatavus. Log4j 1.x teegi järglane Logback väidab, et jätkab seal, kus log4j 1.x lahkub.

    Kuni eelmise nädalani uhkustas Logback ka sellega, et see 'ei ole seotud log4j 2.x-ga, [logback] ei jaga oma haavatavusi'.

    See hüpotees kummutati kiiresti, kui avastati, et CVE-2021-4104 mõjutas ka Log4j 1.x, ja uuriti võimalikku mõju Logbackile. Välja on antud Logbacki uuemad versioonid, 1.3.0-alpha11 ja 1.2.9, mis kõrvaldavad selle vähem tõsise haavatavuse.

    Veel üks CVE...?Jätka lugemist.

Ditch Log4j 2.15: DNS ja RCE võimalik väljafiltreerimine

Log4j 2.15.0 võib sisaldada veelgi tõsisemaid turvaauke kui seni avastatud, nii et 2.16.0 on kaugelt turvalisem.

Eespool kirjeldatud CVE-2021-45046 tõttu näis vea maksimaalne mõju algselt olevat DoS, kuid see eeldus areneb, on BleepingComputer teada saanud.

Pilveturbefirma Praetorian on näidanud, kuidas Log4j versioone 2.15.0 saab endiselt kuritarvitada DNS-põhise andmete väljafiltreerimiseks välistest hostidest, ja teeb koostööd Apache'iga kooskõlastatud avalikustamise nimel.

BleepingComputerile antud meiliintervjuus heidab pretorianide turvainsener Anthony Weems uurimisele valgust:

'Praetoriani ajaveebi postitus vastab CVE-2021-45046-le, mis kehtib Log4j versiooni 2.15 kohta. CVE kirjelduses öeldakse, et kui kasutatakse kindlat tüüpi mudelikujundust, võib see haavatavus viia DoS-i keelamiseni. Põhjus, miks see kuulutatakse DoS-iks, on tingitud ainult kohalik host lubade loend, ütleb Weems BleepingComputerile.

„Oleme selle „localhosti” lubatud loendi jaoks välja töötanud alistamise ja saatnud üksikasjad Apache'ile. Vähemalt tähendab see, et CVE-2021-45046 suhtes haavatavad süsteemid ei ole haavatavad mitte ainult DoS-i, vaid ka potentsiaalselt tundlike keskkondade DNS-i ja esfili suhtes. Muutujad. '

Praetorian jagas PoC-videot, mis näitab just seda:

''>

„Apache on kinnitanud meie teate kättesaamist; kas see väärib CVE muudatust või uut CVE-d, on hea küsimus; kaitsjate nõutud toiming on aga mõlemal juhul selge: liikuda 2.16.0-le, kus jndi vaikimisi keelamine on kõige turvalisem toimimisviis ja see on lähenemine, mida me oma klientidele soovitame, järeldas Praetorian oma avalduses BleepingComputerile.

Samuti on selle kirjutamise ajal BleepingComputer kokku puutunud mitme turvauurijaga, kes väidavad, et täielikku RCE-d on võimalik saada isegi 2.15.0-ga.

'Siin on PoC, kuidas mööda minna lubaidoLdapHost Y Lubatud klassid kontrollib Log4J 2.15.0. jõuda RCE-ni ... ja vältida Lubatud klassid lihtsalt vali JDK-s klassile nimi. Deserialiseerimine toimub nagu tavaliselt, selgitab teadur Márcio Almeida:

Samamoodi jagas Alvaro Muñoz GitHub Security Labist, kuidas õnnestus ületada versioonis 2.15.0 tehtud parandused, et saavutada koodi kaugkäivitamine:

Vahemärkusena võib öelda, et vaikeseadeid see ei mõjuta. Otsing tuleb lubada täpsustades %m {otsingut} või kasutades sellist meetodit nagu CVE-2021-45046, Ta ütleb turvateadlane Ryota K, lisades Muñozi uurimistööle.

Log4j 2.15.0-st tulenev halvim stsenaarium pole veel täielikult kindlaks määratud, kuid piisab, kui öelda, et see ei näi piirduvat DoS-iga.

Olukorra arenedes julgustatakse organisatsioone ja arendajaid värskendama versioonile 2.16.0 ja jätkama Apache'i Log4j hoiatuslehe värskenduste jälgimist.

Mida sa arvad?