Konttien, Kuberneteksen ja pilvien hakkerointi

https://media.ccc.de/v/rc3-2021-cbase-247-hacking-containers-ku

Valtuutukset ovat tehokas keino kontrolloida pääsyä REST-rajapintoihin. Niiden käsiinsä saaminen pitäisi olla hankalaa.

Valitettavasti on aika yleinen tapa jättää valtuutuksia lojumaan ympäriinsä samalla mahdollistaen tehokkaita hyökkäysvektoreita. Hyökkäys näyttää kuinka hakkeroidaan OpenShift-klusteri, joka on täysin yleisesti hyväksyttyjen NIST:in ja CIS:in standardien mukainen. Kontin kaappaminen antaa täyden kontrollin klusteriin, mukaan lukien pääsyn isäntäkoneeseen. Pilvessä ajattaessa klusteria voidaan käyttää jatkohyökkäyksiin, koska isäntäkoneella on toinen valtuutus pilvipalvelimen rajapintaan. Tällä valtuutuksella, voidaan kontrolloida mielivaltaisia tilejä ja pilviresursseja, mukaan lukien virtuaalikoneet, tallennustila jne.

Tämä tulee olemaan osa Kubernetes-tietoturvakoulutuksia, jotka on jaettu avoimen lähdekoodin lisenssillä osoitteessa:

https://github.com/thomasfricke/training-kubernetes-security

Thomas Fricke

https://pretalx.c3voc.de/rc3-2021-cbase/talk/GDMAKJ/

#rc3-2021-import #c-base

Translated by Markus Aurala
(KYBS2001 course assignment at JYU.FI)

Thomas Fricke: Paljon kiitoksia
kutsusta. Toinen puheeni huomenna,

kiitos, eikun, tänään. Tässä on
taustani. Teen enemmän tai vähemmän

Kubernetes-tietoturvaa ja kriiittistä
infraa, olen perustanut useita yrityksiä

ja nyt minun pääfokukseni on Kubernetes-
tietoturva. Tässä Kubernetes-kaninkolo.

Jos tutkit sitä yhtään syvemmin, pitäisi
sinua vähän pelottaa, ja minä kerron

sinulle miksi. Lähestytään ensin
sovellusta. Sitä ajetaan

normaalisti konteissa. Ja konteilla,
toisin kuin yleisesti tiedetään,

on pääsy Kuberneteksen palvelutileihin.
Tämä on yksi suurimmista

Kuberneteksen vioista tällä hetkellä.
Jos saat haltuusi palvelutilin, voit

saada haltuusi koko klusterin. Ja jos
saat haltuusi koko klusterin, voit saada

haltuusi koko noodin ja sitten koko
pilvitilin. Tämä on jonkun muun

tekosia, kerron siitä myöhemmin
esityksessäni. Katsotaanpa mitä tapahtuu:

Kohde on sovellus, joka minulla on
saatavilla Internetissä. Ja haluan

ottaa tuon klusterin haltuuni ulkoa käsin.
Sovellus on ehkä haavoittuva. Esimerkkejä?

Niitä on paljon. Yksi esimerkki on
ImageTragick. Normaalisti ei pitäisi

suorittaa eval- tai exec-komentoja missään
kehikossa – oli se PHP, NodeJS, tai jokin

muu kehikko. Eikä pidä suorittaa komentoja
sovelluksesi kontekstissa, koska

jotain voi mennä pieleen. Kehittäjät
ovat vastuussa tästä. Katsotaan miltä

se näyttää. Tässä on hyökkäysmalli. Se
perustuu hyökkäykseen, jota pidin vanhana

ja joka on korjattu vuonna 2016. Mutta nyt
Emil Lerner on tehnyt uuden katsauksen,

ja näyttänyt ImageMagickin olevan
edelleen käytettävissä hyväksi tällä

hyökkäyksellä. Se toimii. ImageMagickia
käytetään kuvien lataamiseen. Jos muunnat

kuvaa toiseen formaatiin, skaalaat sen
kokoa, ja teet jippoja tälle kuvalle,

voit omistaa koko kontin. Tämä
toimii myös ei-kontitetuille

sovelluksille. Jos sinulla on palvelin,
joka käyttää ImageMagickia johonkin, ole

siis varovainen. Jos olemme onnistuneet
tässä vaiheessa, seuraava vaihe on, että

haluamme pääsyn palvelutiliin. Ja tämä on
oletuksena mahdollista Kuberneteksessa.

Se on siis Kuberneteksen suunnittelu-
virhe, koska palvelutili näkyy konttiin,

jossa sovellusta ajetaan. Hyökkääjän
seuraava askel on asentaa

ylimääräisiä sovelluksia. Jos haluat ottaa
sen haltuusi, tarvitset curl:in, kubectl:n

tai chmod:in. Ja sitten sinä oletkin
palvelutilin omistaja ja voit ajaa komen-

toja lataamalla kuvia ImageTragickiin.
Tästä viasta on vastuussa siis kuvan

luoja. Katsotaan mitä muuta voi
tapahtua. Saadaksesi täyden kontrollin,

tarvitset klusteriylläpitäjän roolin.
Tämä ei ole käytössä oletusarvoisesti,

mutta Internet on täynnä huonoja neuvoja.
Joten jos kopioit asennusvaatimukset tai

-suositukset Internetistä, joku saattaa
kohta ottaa haltuunsa koko klusterin.

Katsotaan tarkemmin asiaa: huonoimman
menetelmän jonka voit löytää, löydät

Elasticin asennussuosituksista: he sanovat
käyttävänsä uudempaa versiota,

mutta he käyttävät klusteriylläpitäjän
oikeuksia asentaakseen Elasticsearchin

Kubernetes-klusteriisi. He siis neuvovat
näin ja niin tekee moni muukin sovellus

asennusvaatimuksissaan. Vaikka se
onkin vanhentunutta tietoa, se on aika

yleistä. Älä koskaan tee tätä, kiitos!
Sen mukana saattaa tulla Helm Charts,

jonka mukana tulee se klusteri-
ylläpitäjän rooli. Näet sen tässä, se oli

Apache Heronissa, joka on Apache-
projekti. Se käyttää klusteriylläpitäjän

roolia, joten Helm-asennuksen kautta
tämä kosketttaa ehkä sinuakin. Näillä

neljällä askeleella, käytännössä kolmella,
sinulla on koko klusteriapplikaatio

paljastettuna, ja sen polun kautta koko
klusteri voidaan ottaa haltuun

etäältä, ja tehdä mitä klusteriylläpitäjä
voi tehdä. Käytännössä tämä

klusteriylläpitäjän rooli on kuin
ovimattohyökkäys - sinulla on paras

salakirjoitus, kalleimmat lukot ja
sitten laitat avaimen ovimaton alle

tai kukkaruukun alle tai
jotain sellaista. Tämä on

jotain sellaista, mitä todellakaan et
halua. Voin näyttää esimerkinomaisesti

miten se menisi. Olen julkaisuut
kaikki koulutusmuistikirjani

GitHubissa. Tässä on miten voit kääntää
tämän vanhentuneen ImageTragickin

OpenShiftissä. Minä käytän CRC:tä, joka on
CodeReady Container -versio. Se perustuu

Mike Williamsin ImageTragick-
esimerkkikoodiin. Tässä ajat ja luot

haavoittuvan levykuvan. Aika pitkä.
Se on käännetty sisään jne. Joten älä

ota koko versiota. Tästä syystä en
näytä sitä tässä, mutta loppujen

lopuksi sinulla on haavoittuva
sovellus kontitettuna ja

OpenShiftissä. Ja sen me juuri tarvitsemme
ajaaksemme sovelluksen. Hyväksi-

käyttö alkaa tästä sillä,
että se kontti otetaan käyttöön

standardi-Kuberneteksessä.
Työkalu oc vastaa kubesctl:iä.

Lisäksi OpenShiftissä on hyvin
yksinkertainen tapa luoda reitti,

joka on kytketty isäntänimeen. Ja sitten
voit ladata sen isäntänimeä käyttäen.

Paljasta asennus, paljasta
luotu palvelu, lopulta paljasta

reitti, ja sitten sinulla on pääsy.
Seuraava askel on, että saat

reitin ja sitten sinulla on URL, jota
voit käyttää. Demossa minä vain

kutsuisin tätä URL:ia ja lähettäisin
kuvia palvelimelle. Olen luonut nämä

ehdat PostScript-tiedostot. Näette,
että niiden perässä on komentoja.

Ja tässä... Koska kontissa on curl,
voin ladata sinne version

kubectl:stä. Käytännössä kontit -
erityisesti Red Hatin - eivät ole niin

haavoittuvia kuin muut. Mutta niissäkin on
aina kirjoitettava tilapäishakemisto, joka

riittää joillekin ohjelmille. Lataamme
curl:illa kubectl:n tilapäishakemistoon,

sitten käytämme chmod-komentoa
aktivoidaksemme kubectl:n. Nyt voimme

suorittaa kubectl-komentoja kontista
käsin. Tuomiopäivän kellot. Juuri oikeassa

paikassa. Meillä on nyt toimiva hyökkäys.
Varoitus: tämä toimii ehkä aiemmissa

Kuberneteksen versioissa.
Uudemmissa tarvitaan lisäksi

nk. myrkkypilleri. Ja tämä
on juurikin tämä kytkös

klusteriylläpitäjän rooliin joka on
oltava, jotta saamme täyden pääsyn ulkoa.

Ja jos me teemme sen, ja paljastamme
roolin sille tunnukselle, joka

on jo paljastettuna kontissa, voimme
suorittaa komentoja kubectl:llä.

Voimme asentaa ohjelmia lataamalla
palvelimelle kuvia. Ja tätä sinä et ikinä

halua, mutta nyt hyökkääjällä on vapaa
pääsy klusteriisi vain lataamalla sinne

käpisteltyjä kuvia. Näin voi tehdä.
Ja tämä on esimerkki vain.

Luo ja tuhoa kontteja ja asennuksia
tällä tavoin. Voit tehdä vaikka mitä.

Ja yhä edelleen, tämä on ongelma
sovelluksen puolella. Jos sinulla

on haavoittuva versio ImageMagickista,
voit lisätä komentoja, ja voit taatusti

asentaa ohjelmia Kubernetes-
palvelimelle. On monia tapoja

korjata tätä. Esimerkiksi, voit käyttää
parempia levykuvia kuten Red Hat tekee.

On Red Hatin terveysindeksi, joka on aika
hyvä. Mutta loppupeleissä nämä levykuvissa

vain se etu, että et aja niissä mitään
pääkäyttäjänä. Mutta ajat näitä kuitenkin

toisella tunnuksella ja sillä tunnuksella
on oikeus kirjoittaa tilapäishakemistoon.

Joten käytännössä et tarvitse pääkäyttäjän
tunnusta asentaaksesi ohjelmia. Kontissa

on hyvät käytännöt: ei pääkäyttäjää, muut-
tumaton juuritiedostojärjestelmä. Mutta

curl, joka on täysin tarpeeton, on
myös asennettuna. Meillä on kirjoitettava

tilapäishakemisto. Meillä on chmod. Ja se
ensimmäinen asia joka tulisi estää kaikki

mitä esittelen tässä nyt. Jos opit edes jotain
tästä esityksestäni, ole hyvä ja mene

katsomaan palvelutilejäsi ja yritä poistaa
käytöstä automountServiceAccountToken-

toiminnallisuudet. Ne palvelutilit, jotka,
eivät tarvitse operaattoreita, eivät

tarvitse myöskään tätä käytössään. Jos
käytät operaattoria, se voi olla nyt rikki,

kapselin määritysten ylikirjoittama.
Mutta käytännössä tämä koko

esimerkki ei toimisi ilman tätä
palvelutilivaltuutusta. Me olemme nyt

korjanneet sen. Me emme voi korjata
sovellusta, koska se on jotain, minkä joku

muu on meille luonut. Ja ei meillä ehkä
ole tietoakaan haavoittuvuudesta. Se voi

olla nollapäivähaavoittuvaisuus. Seuraava
toimenpide on estää ohjelmien asentaminen.

Korjaa levykuvat. Käytä muuttumattomia.
Väliaikaislevytilaa vain jos sitä oikeasti

tarvitaan. PID on 1 joka tapauksessa. OK,
sinulla on ehkä muuttuvaa dataa, mutta

käytä tyhjästä luotuja kontteja, ei curlia
tai wgetiä. Koskee myös Red Hat -UBI:eja

Useimmissa peruslevykuvissa on tämä vika -
niissä on sisällä koko käyttöjärjestelmä

työkaluineen. Mutta tämä
ei ole sinun juttu. Se on

työkalu hyökkääjälle. Joten aja vain
luotettuja levykuvia, rakenna omat

levykuvasi ja rakenna ne alusta pitäen.
Tämä on GitHubiin lataamani esimerkki

konttien tiukentamisesta. Se
perustuu Ngnix:ään Alpinessa. Se on

normaalisti hyvin pieni kontti, mutta voit
tehdä enemmäkin. Voit käyttää skriptiä,

joka on GitHubissa, jotta saat sinne vain
tarvitsemasi työkalut. Tämä ei ole

staattisesti linkitetty, koska Nginx ei
ole alkujaan staattisesti linkitetty,

mutta se on lähellä. Tämä tarkoittaa, että
asennat vain tarvitsemasi ohjelmat. Tämä

on dynaamisesti linkitetty. "-d" jotta
käytetään LVD:tä purkamaan kaikki

dynaamisesti linkitetyt kirjastot ja
tarpeelliset konfiguraatiotiedostot.

/etc/passwd, /etc/group. OK. Jotain
lisenssejä ja jako. Tarvitaan hakemistoja

logitukseen ja sitten voit asentaa sen
tyhjästä, koska tämä skripti asentaa sen

hakemistoon /tmp/harden. Voit tällä
monivaiheisella prosessilla asentaa

mitä haluat /tmp/harden -hakemistosta.
Ja sitten seuraava kontti rakentuu alusta

ja voit käyttää Nginx:ää niin kuin
olet tottunut sitä käyttämään -

staattisesti linkitettynä sovelluksena.
Nyt meillä on tiukennettu levykuva

ilman kubectl:ää, curl:ia. Olemme siis
paljon lähempänä turvallista sovellusta.

Seuraava juttu on tämä linkitys klusteri-
ylläpitäjän rooliin. Älä tee sitä. Jos

jotain menee pieleen sovelluksessasi,
sinulla on lisätoimenpiteitä, joita voit

ottaa käyttöön estääksesi sovellusta
murtautumasta ulos kontista. Voit

erottaa palveluiden ja sisääntulo-
osoitteiden näkyvyyden Internetiin

etuoikeutetuista operaatiosta. On noodi-
asetukset. ElasticSearch tekee paljon

näitä, joten paljon ei ole oikeasti totta.
Tehdään sysctl. Joillakin sovelluksilla

on hostPath päällä tai niillä on yhteys
prosessien väliseen kommunikaatioon, mikä

ei ole tarpeellista jos olet sallinut sen
ja erottelet sitä tarvitsevat sovellukset

niistä, jotka eivät tarvitse sitä.
Klusteriylläpitäjän rooli pitäisi olla

rajoitettu erittäin etuoikeutetuille
operaattoreille. Sitä paitsi, Argo on myös

hyvin etuoikeutettu operaattori. Älä aja
sitä Kuberneteksessa ympäristössä, jossa

tietoturva on kriittistä. Olen nähnyt sen
käyttävän klusteriylläpitäjän roolia.

En tarkoita Argon olevan oletusarvoisesti
turvaton, mutta se on hyvin monimutkainen

sovellus ja minä ajaisin sitä ihan
erillisessä klusterissa, en kriittisessä

klusterissa. Ja miltä arkkitehtuurikorjaus
näyttää? Tässä näet kapselin elinkaaren.

Aika kulkee vasemmalta oikealle.
Tässä näet onko kontti

valmis ja saako siihen yhteyden
Internetistä. Jos teet jotain käynnistys-

järjestelmästä käsin, kuten ajat sysctl:n,
tee se kontista, joka ei ole yhteydessä

Internetiin. Voit vain paussata
kontin, koska paussaus rajoittaa

konttia eikä se ole sitten enää
yhteydessä verkkoon. Ja se on

jotain mikä kattaa arkkitehtuurin.
Lisäksi mainitsin täällä jo

verkkokäytännöt, jotka tulevat myöhemmin.
Tämä on meidän uhkamatriisimme. Olemme

paljastaneet ja piilottaneet palveluita.
On etuoikeutettuja ei ei-etuoikeutettuja

juttuja. Julkiset etuoikeutetut palvelut
ovat vaarallisia. Normaalisti sinulla

on näitä olemassa vain jos ajat
IDE:ä Kuberneteksessä. Sellaista en

haluaisi nähdä kriittisessä
infrastruktuurissa. Sellaista kuin

RStudio tai web-käyttöliittymä GitOps-
kehikkoon. Normaalisti sinulla on vain

web-sovellus. Ja se mitä ei pitäisi olla
paljastettuna normiolosuhteissa on

operaattorin sysctl, käännösjärjestelmät,
isäntäoperaattorit jne. Nämä tehtyäsi on

lähes mahdotonta kaapata klusteriasi.
Sinun pitäisi tehdä kaikki kolme, koska

jos sinulla on useita turvakerroksia, voit
tehdä virheen yhdellä tasolla ja ne

muut tasot pitävät sinut turvassa
hyökkäyksiltä. Voit tehdä vielä

enemmän eristämistä verkkopuolella,
verkkokäytännöt sisääntuloreiteille.

Noodeissa voit aktivoida seccompin,
gVisorin ja yleiset kehikot, SELinuxin ja

AppArmorin. Voit käyttää PodSecurity-
käytäntöjä, jatkossa Open Policy Agentia,

estääksesi noodiasi tulemaan häkätyksi.
Identiteetin ja pääsyn hallinnan puolesta,

sinun pitäisi käyttää omia
palvelutilejä kaikille tehtävillesi.

Joten sinulla on paljon rooleja. Sinun pitäisi
käyttää roolipohjaista pääsynhallintaa

tarkistaaksesi tämän. OK. Minä lupaan,
että voimme mennä syvemmällekin ja

tähän tarvitaan apua pilviylläpitäjältäsi.
Tässä esimerkki Nico Meisenzahlilta,

joka tekee hyvin samanlaista esimerkkiä
Kuberneteksen kaappaamisesta, ja hän

tekee sen yhdessä näistä pilvistä. Ja
mitä hän on saanut selville on, että

voit saada haltuusi azure.json-tiedoston,
jossa on käyttäjäidentiteetit. Nämä eivät

ole Kubernetes-identiteettejä. Nämä ovat
Azure-identiteettejä. Voit saada valtuutuksen,

voit saada tilauksen, voit saada resurssi-
ryhmän ja sitten voit saada curl-komennon

tällä valtuutuksella, muuttaaksesi
asioita resurssiryhmän API-versiolla

tilausta käyttäen. Joten sinun voit ehkä
hakkeroida noodisi etuoikeutetulla

kontilla ja sitten ottaa haltuun koko
tilin. Ja hän kertoi minulle, että tämä

on totuus myös muiden pilvien kanssa. Se
voi toimia myös esimerkiksi AWS:ssä ja

GCP:ssä. Joten ole hyvä ja suojaa myös
pilvitilisi. Ymmärrä identeetin ja pääsyn-

hallintasi pilvessä. Ainakin
jonkun tiimissä pitäisi

ymmärtää se. Ja rajoittaa myös alla
oleva tili minimiinsä. Se voi olla

jopa hyvä idea estää pääsy siihen
osoitteista 169.254.*. Ja tämä voi -

kuten jo mainitsin - koskea myös
niitä muita pilviä. Oma pyyntöni

pilvipalveluntarjoajille on, että älkää
jakako tilitietoja konteissa tai noodeissa.

Tämä ei ole tarpeellista. Se on hyvin
mukavaa, kuten palvelutilin

yhteys ajettavien operaattorien kanssa
on mukavaa. Mutta se on iso tietoturva-

vika ja voit menettää kaikki tilisi ja
datasi. Loppupäätelmä: meillä on

täysi hyökkäysketju sovelluksesta
pilvitilille. Ja se on sinun tehtäväsi

estää se ja korjata se, Tätä kutsutaan
jaetuksi vastuuksi. Pilvipalvelun

tarjoajat huolehtivat käytännössä vain
infrastruktuurista, mutta eivät oikeastaan

tietoturvasta pilvessä. Tämä on teidän
tehtävänne. OK? Kitos huomiostanne,

toivottavasti se oli mielenkiintoista.
Olkaa hyvät ja kysykää nyt.

Aplodeja

Herald: Kiitos esityksestä. Toimiiko tämä?
Jep. Onko meillä yhtään kysymyksiä

Internetistä? En näe mitään tulossa
vielä, mutta luulen meidän olevan

hieman etuajassa, joten kysyn yhden:
Mitä ajattelet siitä, kuka on lähinnä

vastuussa näiden turvattomuuksien
korjaamisesta? Luuletko, että tämän

voi korjata paremmilla oletusarvoilla
infrastruktuurissa ja konfiguraatioissa?

Korjaantuuko tämä paremmilla ohjeilla
ja DevOps-insinöörien paremmalla

koulutuksella? Mikä oli pääpointti
liittyen vastuisiin?

Thomas: Minä pitäisin parhaana turvallisia
oletusasennuksia. Mutta sitten sinulla

on tämä jaettu vastuu sopimuksissa.
Tietystä kulmasta katsottuna sinä itse

olet vastuussa tilisi turvallisuudesta.
Me näemme sen monimutkaisuuden,

koska voi olla 20 vaihetta. Jokainen vaihe
on yksinkertainen ja näyttää varsin

harmittomalta, mutta kaikki vaiheet
yhdessä voivat mahdollistaa hyökkäyksen.

Joten tätä pitää valvoa. Se on erittäin
vaikeaa pilvinatiiveille kehittäjille. He

keskittyvät yleisesti sovelluksensa
tietoturvaan. Kehittäjillä on nykyään

10-100 kertaa enemmän koodia
kovalevyillään kuin 10 vuotta sitten.

Se tarkoittaa, että kehittäjillä
ei voi olla täyttä ymmärrystä

tietoturvasta. Tämä on jotain mistä
kehittäjät puhuvat kun puhuvat tietoturvasta,

olivat he erikoistuneet siihen tai eivät ole
nähneet tälläisiä juttuja. Mitä huomaan

normaalisti on se, että kehittäjät
eivät tunne tälläisiä ongelmia.

H: OK. Ja mitä ajattelet siitä mitä voimme
tehdä monimutkaisuudelle? Tarvitsemmeko

parempaa koulutusta ihmisille, jotta
he ymmärtävät paremmin järjestelmiä?

Vain onko joku tapa, jolla pilvi-infra
voisi vähentää monimutkaisuutta?

T: Parempaa koulutusta ja pitää tehdä
yksinkertaisia korjauksia. Tässä on viisi

vaihetta. Korjaukset ovat yksinkertaisia.
ja ne pitää tarkistaa. Siihen pitää

olla työkalu, koska sinulla voi olla 20
klusteria ja jokaisessa 20 sovellusta.

Tämä voi olla aika monimutkaista. Joten
tarvitset työkaluja saadaksesi kuvan.

Koulutusmateriaaleista löydät esimerkkejä
siitä, miten voit tarkastaa Kubernetes-

klusterin tälläisten hyökkäysten varalta.
H: OK, kiitos todella paljon. Kiitos

kun olit täällä. Jatkamme noin puolen
päästä seuraavalla esityksellä. Sitten

taas saksaksi. Kiitos.
Thomas: Kiitos todella paljon. aplodeja

Outro: Kaikki on CC BY 4.0 -lisenssoitu.
Kaikki on yhteisölle,

tuntemattomille ja ihan kaikille.

Subtitles created by c3subtitles.de
in the year 2022. Join, and help us!

Translated by Markus Aurala
(KYBS2004 course assignment at JYU.FI)