Kuidas ohus osalejad konteinereid ründavad ja kasutavad? See on küsimus, millele ma pidevalt mõtlen. Olen selles valdkonnas töötanud juba üle kahe aastakümne ja tunnen, et mul peaks olema vastus. Aga ma ei tee seda.
Selle asemel on mul palju erinevaid ideid, millest ma ei saa tegelikult ühtki õigeks nimetada. Osa sellest otsustamatusest tuleneb kogu ajast, mille kulutasin turvalisuse õppimisele „pärandi” maailmas. Konteineritel pole tegelikult analoogi. Muidugi seotakse virtuaalmasinad (VM-id) sageli konteineritega, kuid neid ei saanud kunagi mahutite sarnaselt skaleerida. Neid kasutatakse ka täiesti erinevatel eesmärkidel kui konteinereid. Võttis natuke aega, et mu mõtlemist kohandada ja aru saada, kuhu konteinerid rünnakupinnale tegelikult mahuvad.
Avalikud näited konteinerkeskkondade vastu suunatud rünnakutest on väga piiratud. Rikkumised on peaaegu alati seotud krüptomineerimisega, mis on tõsised rünnakud, kuid intsidendile reageerija leiab, et need on üle jõu käivad. Teine ühine joon on see, et need on enamasti tingitud valest konfiguratsioonist, olgu see siis Kubernetes või pilvekontol. Motiivide ja taktika kombinatsioon pole seni olnud kuigi inspireeriv.
Vana tee
Koodi kaugkäivitamise (RCE) haavatavused on olnud arvutiturbe peamiseks probleemiks pikka aega. On ikka, aga kuidas selline mõtteviis konteinerite puhul käib? Lihtne on kohe hüpata RCE-le kui peamisele ohule, kuid see ei tundu olevat õige viis konteineritele lähenemiseks. Esiteks on konteinerid sageli väga lühikese elueaga – 44% konteineritest elab vähem kui viis minutit – nii et sissetungija peaks olema kiire.
See lähenemisviis eeldab ka seda, et konteiner on Internetiga avatud. Kindlasti on mõned konteinerid sel viisil seadistatud, kuid sageli on need väga lihtsad ja kasutavad hästi testitud tehnoloogiaid, nagu NGINX. Nende rakenduste jaoks võib olla null päeva, kuid need oleksid äärmiselt väärtuslikud ja raskesti kättesaadavad. Minu kogemus on näidanud, et palju konteinereid kasutatakse sisemiselt ja need ei loo otse Interneti-ühendust. RCE stsenaarium muutub sel juhul palju keerulisemaks. Peaksin mainima log4j, kuigi seda tüüpi turvaauke võib eemalt ära kasutada isegi siis, kui haavatav süsteem pole äärel.
Uus tee
Kui RCE ei ole suurim oht konteineritele, siis mis see on? Kas konteinerid on isegi ohustajate radaril? Jah, konteinerid ja neid toetav infrastruktuur on liiga olulised, et neid ignoreerida. Konteinerite orkestreerimistarkvara on võimaldanud konteinerite töökoormust skaleerida kujuteldamatuteks numbriteks. Kasutustrend on samuti kasvamas, nii et võite olla kindel, et need on sihtmärgiks. Neid lihtsalt ei saa pidada serveriteks, mille juurde pääsete RCE haavatavuste kaudu.
Selle asemel on tegelikult tõsi vastupidine. Selle asemel, et rünnata konteinereid väljastpoolt sissepoole, tuleb neid rünnata seest välja. See on sisuliselt see, mida tarneahela rünnakud teevad. Tarneahel on äärmiselt tõhus ründevektor konteinerite vastu, kui hakkate aru saama, kuidas need on üles ehitatud. Konteiner algab määratlusfailiga, näiteks Dockerfile, mis määratleb kõik, mis konteineris selle käivitamisel on. See muudetakse pildiks, kui see on ehitatud ja see pilt on see, mida saab lugematul hulgal kordi töökoormuseks keerata. Kui midagi selles definitsioonifailis rikutakse, on ohus iga töötav töökoormus.
Konteinerid on sageli, kuid mitte alati, spetsiaalselt loodud rakendusega, mis teeb midagi ja väljub. Need rakendused võivad olla peaaegu kõik – oluline on mõista, kui palju on ehitatud teiste inimeste kirjutatud teeke (kas suletud lähtekoodiga või avatud lähtekoodiga) kasutades. GitHubil on miljoneid projekte ja see pole ainus koodihoidla. Nagu nägime SolarWindsi puhul, on suletud allikas haavatav ka tarneahela rünnakute suhtes.
Tarneahela rünnak on suurepärane viis ohus osalejatele sihtmärgi konteinerikeskkonda sattumiseks. Nad võivad isegi lasta kliendi infrastruktuuril oma rünnakut enda eest skaleerida, kui kompromiss jääb märkamatuks. Seda tüüpi stsenaarium mängib end juba välja, nagu nägime rakenduse puhul Codecovi rikkumine. Kuid seda on raske tuvastada, kuna see kõik on uus ja kuidas meie mõtlemine on endiselt juurdunud mineviku probleemidesse.
Tee edasi
Nagu enamiku probleemide lahendamise puhul, on nähtavus tavaliselt suurepärane koht alustamiseks. Raske on parandada seda, mida te ei näe. Oma konteinerite kinnitamiseks peab teil olema nähtavus nii konteineritele endile kui ka kogu torujuhtmele, mis neid ehitab. Haavatavuse haldamine on üks nähtavuse tüüp, mis tuleb integreerida ehitusprotsessi. Lisaksin ka muid staatilise analüüsi tööriistu, näiteks selliseid, mis otsivad ka selle jaoks lekkinud saladusi. Kuna tarneahela rünnaku väljanägemist ei saa tegelikult ennustada, muutub käitusaegne jälgimine kriitiliseks, et saaksite täpselt teada, mida teie konteinerid teevad.
