BLACK HAT USA – Las Vegas – A biztonsági rés javításával lépést tartani a legjobb esetben is kihívást jelent, de a kontextushiányos CVSS-pontszámoknak, a sáros szállítói figyelmeztetéseknek és a hiányos javításoknak köszönhetően minden eddiginél nehezebb a prioritás meghatározása, hogy mely hibákra kell összpontosítani. hagyd az adminokat hamis biztonságérzettel.
Ez az az érv, amelyet Brian Gorenc és Dustin Childs, mindketten a Trend Micro Zero Day Initiative (ZDI) kezdeményezésével, a Black Hat USA színpadáról állítottak elő az ülésük során.A kockázat kiszámítása a homály korában: Olvasás a biztonsági tanácsok sorai között. "
A ZDI 10,000 óta több mint 2005 XNUMX sebezhetőséget tárt fel a gyártók számára az iparágban. Ez idő alatt a ZDI kommunikációs menedzsere, Childs azt mondta, hogy egy zavaró tendenciát észlelt, amely a javítások minőségének csökkenése és a biztonsági frissítésekkel kapcsolatos kommunikáció csökkenése.
"Az igazi probléma akkor merül fel, amikor a gyártók hibás javításokat adnak ki, vagy pontatlan és hiányos információkat adnak ki azokról a javításokról, amelyek miatt a vállalatok rosszul számolják ki kockázataikat" - jegyezte meg. „A hibás javítások az írók kihasználásában is hasznosak lehetnek, mivel az „n-napos” sokkal könnyebben használható, mint a nulla nap.”
Probléma a CVSS-pontszámokkal és a javítási prioritásokkal
A legtöbb kiberbiztonsági csapat létszámhiányos és nyomás alatt áll, és a „mindig tartsa naprakészen az összes szoftververziót” mantrának nem mindig van értelme azoknak a részlegeknek, akik egyszerűen nem rendelkeznek a vízpart lefedéséhez szükséges erőforrásokkal. Ez az oka annak, hogy a Common Vulnerability Severity Scale (CVSS) szerinti súlyossági besorolásuk alapján fontossági sorrendbe állítani, hogy mely javításokat alkalmazza, sok rendszergazda tartalékot jelent.
Childs azonban megjegyezte, hogy ez a megközelítés mélyen hibás, és erőforrásokat költhet olyan hibákra, amelyeket valószínűleg soha nem fognak kihasználni. Ennek az az oka, hogy számos olyan kritikus információ található, amelyet a CVSS-pontszám nem ad meg.
„A vállalatok túl gyakran csak a CVSS alapmagot keresik a javítási prioritás meghatározásához” – mondta. „A CVSS azonban nem igazán foglalkozik a kihasználhatósággal, vagy azzal, hogy a sérülékenységet a vadonban felhasználják-e. A CVSS nem mondja meg, hogy a hiba 15 vagy 15 millió rendszerben létezik-e. És nem mondja meg, hogy nyilvánosan elérhető szervereken van-e vagy sem.”
Hozzátette: "És ami a legfontosabb, nem mondja meg, hogy a hiba jelen van-e egy olyan rendszerben, amely kritikus az Ön vállalkozása számára."
Így annak ellenére, hogy egy hiba 10-ből 10-es kritikus besorolást kaphat a CVSS-skálán, a valódi hatása sokkal kevésbé aggályos, mint amit a kritikus címke jelez.
"A nem hitelesített távoli kódvégrehajtási (RCE) hiba egy olyan e-mail szerverben, mint a Microsoft Exchange, nagy érdeklődést vált ki az exploit írók körében" - mondta. „A Squirrel Mailhez hasonló e-mail szerverben található nem hitelesített RCE-hiba valószínűleg nem fog akkora figyelmet kelteni.”
A kontextuális hiányosságok pótlására a biztonsági csapatok gyakran fordulnak a szállítói tanácsokhoz – amelyeknek, Childs megjegyezte, megvan a maga szembeötlő problémája: gyakran a homályon keresztül gyakorolják a biztonságot.
A Microsoft javítási keddi figyelmeztetésekből hiányoznak a részletek
2021-ben a Microsoft meghozta a döntést a vezetői összefoglalók eltávolításához
a biztonsági frissítési útmutatókból, ehelyett tájékoztatja a felhasználókat arról, hogy a CVSS-pontszámok elegendőek lesznek a prioritások meghatározásához – ez a változás, amelyet Childs tönkretett.
"A változás eltávolítja azt a kontextust, amely a kockázat meghatározásához szükséges" - mondta. „Például egy információ közzétételi hiba kiírja a véletlenszerű memóriát vagy a személyazonosításra alkalmas adatokat? Vagy a biztonsági funkció megkerülése esetén mit kerül ki? Az ezekben az írásokban található információk következetlenek és változó minőségűek, annak ellenére, hogy a változást szinte általánosan kritizálják.”
Amellett, hogy a Microsoft „eltávolította vagy elfedte a frissítésekben szereplő információkat, amelyek korábban egyértelmű útmutatást adtak”, most már nehezebb meghatározni a javítási keddre vonatkozó alapvető információkat, például azt, hogy hány hibát javítanak havonta.
„Most meg kell számolnod magad, és valójában ez az egyik legnehezebb dolog, amit csinálok” – jegyezte meg Childs.
Emellett még mindig elérhető az információ arról, hogy hány sebezhetőséget támadnak aktívan, vagy hány sebezhetőséget ismernek nyilvánosan, de már el vannak temetve a közleményekben.
„Példaként a 121 CVE-t javítanak ebben a hónapban, nagyon nehéz mindegyiket átkutatni, hogy megkeressük, melyiket támadják aktívan” – mondta Childs. "Ehelyett az emberek más információforrásokra, például blogokra és sajtócikkekre hagyatkoznak, nem pedig arra, hogy az eladótól származó mérvadó információkra támaszkodjanak a kockázat meghatározásához."
Meg kell jegyezni, hogy a Microsoft megduplázta a változást. A Black Hat USA-nál a Dark Readinggel folytatott beszélgetés során a Microsoft Security Response Center vállalati alelnöke, Aanchal Gupta elmondta, hogy a vállalat tudatosan úgy döntött, hogy a felhasználók védelme érdekében korlátozza a CVE-vel kezdetben közölt információkat. Míg a Microsoft CVE-k tájékoztatást adnak a hiba súlyosságáról és kihasználásának valószínűségéről (és arról, hogy aktívan kihasználják-e), a vállalat megfontoltan fogja kiadni a sebezhetőséget kihasználó információkat, mondta.
A cél az, hogy a biztonsági adminisztrációknak elegendő időt biztosítsanak a javítás alkalmazására anélkül, hogy veszélyeztetnék őket – mondta Gupta. „Ha a CVE-nkban megadjuk a sebezhetőségek kihasználásának minden részletét, akkor ügyfeleink nulladik napját fogjuk érinteni” – mondta.
Más szállítók homályosságot alkalmaznak
A Microsoft aligha van egyedül azzal, hogy csekély részleteket közöl a hibaleírásokban. Childs azt mondta, hogy sok gyártó egyáltalán nem biztosít CVE-t, amikor frissítést ad ki.
„Csak azt mondják, hogy a frissítés számos biztonsági problémát megold” – magyarázta. "Mennyi? Mi a súlyossága? Mi a kihasználhatóság? Nemrég egy eladó kifejezetten azt mondta nekünk, hogy nem teszünk közzé nyilvános tanácsokat biztonsági kérdésekről. Ez merész lépés.”
Ezen túlmenően, egyes szállítók fizetőfalak vagy támogatási szerződések mögé helyeznek el tanácsokat, így tovább eltakarják kockázatukat. Vagy több hibajelentést egyesítenek egyetlen CVE-be, annak ellenére, hogy az általános felfogás szerint a CVE egyetlen egyedi sebezhetőséget jelent.
"Ez a kockázati számítás esetleges torzulásához vezethet" - mondta. „Például, ha egy termék vásárlásakor 10 CVE-t lát, amelyeket egy bizonyos idő alatt kijavítottak, akkor egy következtetésre juthat az új termék kockázatára vonatkozóan. Ha azonban tudná, hogy ez a 10 CVE több mint 100 hibajelentésen alapul, akkor más következtetésre juthatna.”
A placebo javítja a pestis prioritásait
A nyilvánosságra hozatali problémán túl a biztonsági csapatoknak magukkal a javításokkal is gondok vannak. Childs szerint a „Placebo javítások”, amelyek olyan „javítások”, amelyek valójában nem hajtanak végre hatékony kódmódosításokat, nem ritkák.
"Tehát ez a hiba továbbra is megvan, és kihasználható a fenyegető szereplők számára, kivéve, hogy most értesítették őket" - mondta. „Sok oka lehet annak, hogy ez megtörténhet, de megtörténik – olyan szép hibák, hogy kétszer foltozzuk őket.”
Gyakran előfordulnak hiányos foltok is; Valójában a ZDI programban a kutatók által elemzett hibák teljes 10-20%-a egy hibás vagy hiányos javítás közvetlen eredménye.
Childs példát használt az Adobe Reader egész szám túlcsordulási problémájára, amely alulméretezett kupackiosztáshoz vezet, ami puffertúlcsordulást eredményez, ha túl sok adatot írnak rá.
„Arra számítottunk, hogy az Adobe úgy javítja ki, hogy egy bizonyos pont feletti értéket rossznak állít be” – mondta Childs. „De nem ezt láttuk, és a bevezetést követő 60 percen belül kikerült a javítás, és újra kellett javítani. Az ismétlések nem csak a tévéműsorokhoz szólnak.”
Hogyan lehet leküzdeni a javítási prioritások problémáit
Végső soron, ami a javítások priorizálását illeti, a hatékony javításkezelés és kockázatszámítás a szervezeten belüli nagy értékű szoftvercélok azonosításán, valamint harmadik féltől származó források felhasználásán múlik, hogy leszűkítsék, mely javítások lennének a legfontosabbak egy adott környezetben. jegyezték meg a kutatók.
A nyilvánosságra hozatal utáni fürgeség kérdése azonban egy másik kulcsfontosságú terület, amelyre a szervezeteknek összpontosítani kell.
Gorenc, a ZDI vezető igazgatója szerint a kiberbűnözők nem vesztegetik az idejüket arra, hogy nagy támadási felülettel rendelkező biztonsági réseket integráljanak ransomware eszközkészleteikbe vagy kizsákmányoló készleteikbe, és megpróbálják felfegyverezni az újonnan feltárt hibákat, mielőtt a cégeknek idejük lenne javítani. Ezek az úgynevezett n-napos hibák macskagyökér a támadók számára, akik átlagosan akár 48 óra alatt képesek visszafejteni a hibát.
„Az offenzív közösség nagyrészt n-napos sebezhetőségeket használ, amelyekhez nyilvános javítások állnak rendelkezésre” – mondta Gorenc. "Fontos számunkra, hogy a nyilvánosságra hozatalkor megértsük, hogy egy hibát valóban fegyveressé teszik-e, de a legtöbb szállító nem ad tájékoztatást a kihasználhatóságról."
Így a vállalati kockázatértékelésnek kellően dinamikusnak kell lennie ahhoz, hogy a nyilvánosságra hozatalt követően megváltozzon, és a biztonsági csapatoknak figyelemmel kell kísérniük a fenyegetések intelligencia forrásait, hogy megértsék, mikor van egy hiba beépítve egy kizsákmányoló készletbe vagy ransomware-be, vagy mikor adnak ki egy exploitot online.
Ehhez járul, hogy a vállalatoknak megfontolandó fontos idővonal az, hogy mennyi időbe telik a javítás tényleges bevezetése a szervezeten belül, és hogy vannak-e szükség esetén hasznosítható erőforrások.
„Amikor változások következnek be a fenyegetettségi környezetben (javítások felülvizsgálata, a koncepciók nyilvános bizonyítása és az exploit kiadások), a vállalatoknak át kell fordítaniuk erőforrásaikat a szükségletek kielégítésére és a legújabb kockázatok leküzdésére” – magyarázta Gorenc. „Nem csak a legújabb nyilvánosságra hozott és elnevezett sebezhetőség. Figyelje meg, mi történik a fenyegetési környezetben, tájékoztassa erőforrásait, és döntse el, mikor kell cselekednie.”
