บทบาทที่มีสิทธิ์เกินจำเป็นและช่องโหว่ API ของ Azure เปิดโอกาสให้เครือข่ายองค์กรถูกโจมตีเพื่อเข้าควบคุม VPN
กรอบการรักษาความปลอดภัยของ Microsoft Azure กำลังถูกตรวจสอบอย่างเข้มข้นหลังจากนักวิจัยค้นพบช่องโหว่สำคัญที่ช่วยให้ผู้โจมตีสามารถบุกรุกคีย์ VPN และแทรกซึมเข้าสู่เครือข่ายองค์กรได้ ผลการวิจัยที่เผยแพร่โดย Wiz Research Team เปิดเผยว่าบทบาทที่มีสิทธิ์เกินจำเป็นและจุดอ่อนของ API สร้างเส้นทางการโจมตีหลายช่องทางสำหรับผู้ประสงค์ร้าย
ช่องโหว่นี้มีจุดศูนย์กลางอยู่ที่บริการ REACT ของ Azure ซึ่งเป็นคอมโพเนนต์ภายในของ Microsoft ที่จัดการการกำหนดบทบาทและแปลงเป็นคำจำกัดความของบทบาท แม้ว่าจะถูกออกแบบให้ปลอดภัยด้วยพื้นผิวการโจมตีที่เล็ก แต่นักวิจัยพบวิธีการจัดการบทบาทเหล่านี้และได้รับการเข้าถึงที่ไม่ได้รับอนุญาตไปยังทรัพยากรสำคัญ
เส้นทางการโจมตี Azure VPN:
- ผู้โจมตีได้รับสิทธิ์การเข้าถึงระดับสูงไปยัง Azure Connectors
- แจกแจงรายการ virtual network gateways ทั้งหมด (สามารถทำได้โดยไม่ต้องมีสิทธิ์อ่านข้อมูลใน subscription)
- เรียกใช้คำสั่ง GET บนทรัพยากร virtual network gateway connection
- ดึงข้อมูล shared keys เพื่อเข้าถึง VPN
- ได้รับความสามารถในการแทรกซึมเครือข่าย
 |
|---|
| สำรวจ Role Roulette ของ Azure : วิเคราะห์ว่าช่องโหว่เปิดโอกาสให้เครือข่ายองค์กรถูกโจมตีได้อย่างไร |
สถาปัตยกรรมที่ซับซ้อนสร้างจุดบอดด้านความปลอดภัย
แนวทางการพัฒนาแบบกระจายของ Azure ได้สร้างเขาวงกตของบริการที่เชื่อมโยงกันซึ่งแม้แต่วิศวกรที่มีประสบการณ์ยังต้องดิ้นรนเพื่อนำทาง เอกสารประกอบของแพลตฟอร์มมีชื่อเสียงในด้านการแยกส่วน โดยข้อมูลสำคัญกระจัดกระจายอยู่ในบทความหลายฉบับ ความซับซ้อนนี้ไม่ใช่เพียงปัญหาด้านการใช้งาน แต่กำลังกลายเป็นความกังวลด้านความปลอดภัยที่ร้ายแรง
การวิจัยเน้นให้เห็นว่าระบบควบคุมการเข้าถึงตามบทบาทของ Azure สามารถถูกใช้ประโยชน์ผ่านสิทธิ์ที่ดูเหมือนไม่เป็นอันตราย ผู้โจมตีที่มีสิทธิ์สูงสามารถระบุเกตเวย์เครือข่ายเสมือน ดึงคีย์ที่ใช้ร่วมกัน และในที่สุดได้รับการเข้าถึง VPN ไปยังเครือข่ายองค์กร เส้นทางการโจมตีเกี่ยวข้องกับการเรียกคำขอ GET บนทรัพยากรการเชื่อมต่อเกตเวย์เครือข่ายเสมือน ซึ่งเปิดเผยคีย์ที่ใช้ร่วมกันที่จำเป็นสำหรับการตรวจสอบสิทธิ์ VPN
 |
|---|
| ทำความเข้าใจกระบวนการดึงข้อมูล shared key ผ่านการดำเนินการ API ของ Azure |
ประสบการณ์ของนักพัฒนาสะท้อนปัญหาที่ลึกซึ้งกว่า
ความหงุดหงิดของชุมชนกับ Azure ขยายไปเกินกว่าปัญหาความปลอดภัยไปสู่ตัวเลือกการออกแบบพื้นฐาน นักพัฒนาหลายคนรายงานว่า Azure รู้สึกเหมือนชุดของบริการที่สร้างโดยทีมต่างๆ ที่มีการประสานงานเพียงเล็กน้อย มากกว่าที่จะเป็นแพลตฟอร์มที่เชื่อมโยงกัน การแยกส่วนนี้ปรากฏในทุกสิ่งตั้งแต่การทับซ้อนของบริการที่สับสนไปจนถึงกระบวนการปรับใช้ที่ซับซ้อนโดยไม่จำเป็น
ชัดเจนมากหากคุณตรวจสอบ github ว่าบริการและเอกสารของ Azure เขียนโดยทีมกระจายที่มีการประสานงานเพียงเล็กน้อย เรามีคำพูดในบริษัทว่าข้อมูลทั้งหมดอยู่ในเอกสารของพวกเขา แต่ประโยคและย่อหน้าสำหรับสิ่งเล็กน้อยแม้แต่สิ่งที่ไม่สำคัญก็แยกออกเป็นสิบหรือสิบห้าบทความ
แนวทางของแพลตฟอร์มต่อการคำนวณแบบไร้เซิร์ฟเวอร์ทำให้นักพัฒนาหงุดหงิดเป็นพิเศษ ต่างจาก AWS Lambda ที่อนุญาตให้ปรับใช้ฟังก์ชันโดยตรง Azure กำหนดให้ผู้ใช้จัดเตรียมแผนบริการ แอปฟังก์ชัน และบัญชีจัดเก็บข้อมูลแม้สำหรับฟังก์ชันไร้เซิร์ฟเวอร์ที่ง่าย ความซับซ้อนนี้สร้างโอกาสมากขึ้นสำหรับการกำหนดค่าผิดพลาดที่อาจนำไปสู่ช่องโหว่ด้านความปลอดภัย
ความซับซ้อนของ Serverless ระหว่าง Azure กับ AWS:
- AWS Lambda: การ deploy function โดยตรง
- Azure Functions: ต้องจัดเตรียม service plan + function app + storage account + resource group
- Azure มีหลายประเภทของ plan (Consumption, Flex Consumption, App Service Plan)
- ความซับซ้อนเพิ่มเติมโดยไม่มีประโยชน์ที่ชัดเจนสำหรับการใช้งานแบบง่าย ๆ
การยอมรับขององค์กรแม้จะมีข้อบกพร่องทางเทคนิค
แม้จะมีปัญหาเหล่านี้ Azure ยังคงได้รับลูกค้าองค์กรเพิ่มขึ้น มักจะผ่านความสัมพันธ์ทางธุรกิจมากกว่าคุณค่าทางเทคนิค องค์กรหลายแห่งเลือก Azure เนื่องจากความร่วมมือกับ Microsoft ที่มีอยู่ ข้อกำหนดการเก็บข้อมูลในประเทศ หรือส่วนลดจากปริมาณมากกว่าความต้องการของวิศวกรรม พลวัตนี้หมายความว่า Microsoft เผชิญแรงกดดันน้อยกว่าในการแก้ไขความกังวลด้านการใช้งานและความปลอดภัยเมื่อเทียบกับคู่แข่งอย่าง AWS
การวิจัยแนะนำกลยุทธ์การบรรเทาหลายประการ รวมถึงการผลักดันให้อัปเดตบทบาทที่มีปัญหา การใช้หลักการสิทธิ์น้อยที่สุด และการตรวจสอบบทบาทที่กำหนดเองสำหรับสิทธิ์ที่เกินจำเป็น อย่างไรก็ตาม ปัญหาพื้นฐานยังคงอยู่ สถาปัตยกรรมที่ซับซ้อนของ Azure ทำให้องค์กรยากที่จะรักษาความปลอดภัยสภาพแวดล้อมคลาวด์ของตนอย่างเหมาะสม
มาตรการรักษาความปลอดภัยที่แนะนำ:
- ตรวจสอบและแทนที่บทบาทที่มีสิทธิ์เกินจำเป็นด้วยทางเลือกที่มีสิทธิ์น้อยที่สุด
- ใช้การจำกัดขอบเขตที่เหมาะสมในการกำหนดบทบาท
- ตรวจสอบบทบาทที่กำหนดเองอย่างสม่ำเสมอเพื่อหาสิทธิ์ที่เกินจำเป็น
- ผลักดันให้มีการอัปเดตบทบาท Azure Connector ที่มีปัญหา
- พิจารณาการผสานรวมทางเลือกอื่นๆ เมื่อเป็นไปได้
 |
|---|
| การทดสอบ APIs ของ Azure : สำคัญต่อการนำมาตรการรักษาความปลอดภัยไปใช้เพื่อป้องกันช่องโหว่ |
บทสรุป
ช่องโหว่เหล่านี้เน้นให้เห็นปัญหาที่กว้างขึ้นเกี่ยวกับท่าทีด้านความปลอดภัยและความซับซ้อนของสถาปัตยกรรมของ Azure แม้ว่า Microsoft จะมีทรัพยากรในการแก้ไขปัญหาเหล่านี้ แต่แนวทางการพัฒนาแบบแยกส่วนของแพลตฟอร์มยังคงสร้างพื้นผิวการโจมตีใหม่ องค์กรที่ใช้ Azure ควรตรวจสอบการกำหนดบทบาทอย่างระมัดระวังและพิจารณาใช้มาตรการรักษาความปลอดภัยเพิ่มเติมเพื่อป้องกันเวกเตอร์การโจมตีที่เพิ่งค้นพบเหล่านี้
หมายเหตุ: REACT - บริการภายในของ Microsoft สำหรับจัดการการกำหนดบทบาทและคำจำกัดความใน Azure Resource Manager
อ้างอิง: Azure's Role Renderers: How Over-Privileged Roles and API Vulnerabilities Expose Enterprise Networks