Hogyan támadják meg és használják fel a konténereket a fenyegetés szereplői? Ez az a kérdés, amin folyamatosan gondolkodom. Több mint két évtizede dolgozom ezen a területen, és úgy érzem, hogy választ kell kapnom. De én nem.
Ehelyett nagyon sokféle ötletem van, és egyiket sem tudom igazán helyesnek minősíteni. Ennek a határozatlanságnak az az oka, hogy rengeteg időt töltöttem a biztonság tanulásával az „örökölt” világban. A konténereknek valójában nincs analógjuk. Természetesen a virtuális gépek (VM-ek) gyakran össze vannak keverve tárolókkal, de soha nem voltak képesek a konténerekhez hasonlóan skálázni. Teljesen más célokra is használják, mint a konténereket. Beletelt egy kis időbe, hogy kiigazítsam a gondolkodásomat, és megértsem, hol férnek el a konténerek a támadási felületen.
A konténeres környezetek elleni támadások nyilvános példái nagyon korlátozottak. Az incidensek szinte mindig kriptominózással kapcsolatosak, amelyek súlyos támadások, de a bennem lévő incidensre válaszoló félelmetesnek találja őket. Egy másik közös jellemző, hogy ezek többnyire hibás konfiguráció eredménye, legyen szó akár Kubernetes-ről, akár felhőfiókról. Az indítékok és a taktika kombinációja eddig nem volt túl inspiráló.
A régi út
A távoli kódvégrehajtás (RCE) sérülékenységei hosszú ideig jelentik a számítógépes biztonság fő problémáját. Még mindig vannak, de hogyan vonatkozik ez a gondolkodásmód a konténerekre? Könnyű azonnal az RCE-re ugrani, mint az elsődleges fenyegetésre, de úgy tűnik, nem ez a megfelelő módja a konténerek megközelítésének. Egyrészt a konténerek gyakran nagyon rövid élettartamúak – A konténerek 44%-a kevesebb mint öt percet él – tehát egy betolakodónak gyorsnak kell lennie.
Ez a megközelítés azt is feltételezi, hogy a tároló ki van téve az internetnek. Bizonyos konténerek természetesen így vannak beállítva, de gyakran nagyon egyszerűek, és jól tesztelt technológiákat használnak, mint például az NGINX. Előfordulhat, hogy ezekre az alkalmazásokra nulla nap áll rendelkezésre, de rendkívül értékesek és nehezen elérhetőek lennének. Tapasztalataim azt mutatják, hogy sok tárolót belsőleg használnak, és nem csatlakoznak közvetlenül az internethez. Ebben az esetben az RCE forgatókönyv sokkal nehezebbé válik. meg kell említenem log4j, bár az ilyen típusú sebezhetőségek távolról kihasználhatók, még akkor is, ha a sérülékeny rendszer nincs a szélén.
Az új út
Ha nem az RCE jelenti a legnagyobb veszélyt a konténerekre, akkor mi az? A konténerek még a fenyegetés szereplőinek radarján is szerepelnek? Igen, a konténerek és az őket támogató infrastruktúra túl fontosak ahhoz, hogy figyelmen kívül hagyjuk. A konténerhangszerelő szoftver lehetővé tette a konténeres munkaterhelések elképzelhetetlen számokra való méretezését. A használati trend is növekszik, így biztos lehetsz benne, hogy célpontok lesznek. Egyszerűen nem lehet úgy tekinteni rájuk, mint az RCE sebezhetőségein keresztül elért szerverekre.
Ehelyett a fordítottja igaz. Ahelyett, hogy kívülről befelé támadnánk a konténereket, belülről kifelé kell őket támadni. Lényegében ezt teszik az ellátási lánc támadásai. Az ellátási lánc rendkívül hatékony támadási vektor a konténerek ellen, amikor elkezdi megérteni, hogyan épülnek fel. A tároló egy definíciós fájllal kezdődik, például a Dockerfile fájllal, amely mindent meghatároz, ami a tárolóban lesz, amikor fut. Egyszer megépített képpé válik, és ez a kép az, ami számtalanszor felpörgeti a munkaterhelést. Ha a definíciós fájlban bármi feltört, akkor minden futó munkaterhelés veszélybe kerül.
A konténerek gyakran, de nem mindig, olyan alkalmazással készülnek, amely végrehajt valamit, és kilép. Ezek az alkalmazások szinte bármiek lehetnek – fontos megérteni, hogy mennyit építenek fel mások által írt, zárt vagy nyílt forráskódú könyvtárakból. A GitHubnak több millió projektje van, és nem ez az egyetlen kódtár. Amint azt a SolarWinds esetében láttuk, a zárt forráskód az ellátási lánc támadásaival szemben is sebezhető.
Az ellátási lánc támadása nagyszerű módja annak, hogy a fenyegetés szereplői bejussanak a célpont konténerkörnyezetébe. Még azt is megengedhetik, hogy az ügyfél infrastruktúrája átméretezze a támadást helyettük, ha a kompromisszum észrevétlen marad. Ez a fajta forgatókönyv már kijátssza magát, amint láttuk a Codecov megsértése. De nehéz felismerni, mert mindez mennyire új, és gondolkodásunk még mindig a múlt problémáiban gyökerezik.
Út előre
A legtöbb probléma megoldásához hasonlóan a láthatóság általában jó kiindulópont. Nehéz megjavítani azt, amit nem lát. A konténerek rögzítéséhez be kell látni magukba a konténerekbe, valamint a teljes csővezetékbe, amely azokat építi. A sérülékenységkezelés a láthatóság egyik típusa, amelyet integrálni kell az összeállítási folyamatba. Más statikus elemző eszközöket is beiktatnék, például olyanokat, amelyek ehhez is keresik a kiszivárgott titkokat. Mivel nem igazán lehet megjósolni, hogyan néz ki az ellátási lánc támadása, a futásidejű felügyelet kritikussá válik, hogy pontosan tudja, mit csinálnak a konténerek.
