การเพิ่มสิทธิพิเศษใน Entra ID (เดิมชื่อ Azure AD)

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

ในสภาพแวดล้อมแบบไฮบริดในปัจจุบัน องค์กรต่าง ๆ กำลังเปลี่ยนทรัพยากรที่ละเอียดอ่อนไปยังแอป SaaS มากขึ้น อาซัวร์ Active Directory เป็นหนึ่งในผู้ให้บริการข้อมูลระบุตัวตนบนคลาวด์ชั้นนำที่ช่วยให้องค์กรสามารถจัดการการเข้าถึงและใช้งานแอพดังกล่าวได้จากส่วนกลาง

เมื่อเร็วๆ นี้เราได้ค้นพบปัญหาการยกระดับสิทธิ์ภายใน Entra ID (เดิม Azure AD) ที่อาจทำให้ผู้โจมตีสามารถเลี่ยงการป้องกันการรีเซ็ตรหัสผ่านได้ ทำให้ผู้ดูแลระบบระดับล่างกลายเป็นผู้ที่ได้รับสิทธิพิเศษอย่างเต็มที่ เราได้รายงานปัญหานี้ไปยัง Microsoft Security Response Center (MSRC) ซึ่งทำการตรวจสอบและใช้การแก้ไขแล้ว ในขณะที่มันไม่ก่อให้เกิดความเสี่ยงอีกต่อไป Entra ID ผู้ใช้ (เดิมคือ Azure AD) เราเชื่อว่าชุมชนความปลอดภัยในวงกว้างจะได้รับประโยชน์จากการดูการวิเคราะห์และการค้นพบของเรา

การวิเคราะห์ทางเทคนิค

พื้นที่ Entra ID (เดิมเรียกว่า Azure AD) ระบบบทบาทที่ได้รับสิทธิพิเศษทำงานเป็นลำดับชั้น ป้องกันไม่ให้ผู้ดูแลระบบที่มีสิทธิพิเศษต่ำกว่ารีเซ็ตรหัสผ่านของผู้ดูแลระบบที่มีสิทธิพิเศษสูงกว่า นอกเหนือจากตรรกะในการปฏิบัติงานแล้ว สิ่งนี้ยังป้องกันสถานการณ์ที่บัญชีผู้ดูแลระบบที่มีสิทธิ์ต่ำกว่าถูกบุกรุกโดยทำให้แน่ใจว่าผู้โจมตีไม่สามารถแก้ไขบัญชีที่มีสิทธิ์สูงกว่าได้

การป้องกันนี้มีผลเมื่อบทบาทของผู้ใช้ถูกตั้งค่าเป็น "มีสิทธิ์" หรือ "ใช้งานอยู่" อย่างไรก็ตาม, Entra ID (เดิมชื่อ Azure AD) ก็อนุญาตเช่นกัน บัญชีผู้ใช้ ที่จะได้รับมอบหมายให้ การใช้งานในอนาคต กล่าวคือ สิทธิ์ในระดับที่สูงกว่าจะได้รับตามวันที่และเวลาที่กำหนดไว้ล่วงหน้า

เราพบว่าในกรณีนี้ การป้องกันรหัสผ่านใช้ไม่ได้ สิ่งนี้เผยให้เห็น Entra ID (เดิมคือ Azure AD) ในสถานการณ์ต่อไปนี้:

1. การประนีประนอมเบื้องต้น: ผู้โจมตีบุกรุกบัญชีผู้ดูแลระบบที่มีสิทธิ์ต่ำ
2. การค้นพบการกำหนดบทบาทในอนาคต: ผู้โจมตีสแกน Entra ID (เดิมชื่อ Azure AD) เพื่อค้นหาบัญชีที่กำหนดให้เป็นผู้ดูแลระบบที่มีสิทธิ์สูงในอนาคต
3. รีเซ็ตรหัสผ่าน: ตอนนี้ผู้โจมตีจะรีเซ็ตรหัสผ่านของบัญชีเหล่านี้ โดยประนีประนอมก่อนที่จะมีการมอบหมายบทบาท ตามหลักการแล้ว ผู้โจมตีจะทำการรีเซ็ตนี้ให้ใกล้เคียงกับเวลาที่เปลี่ยนบทบาทมากที่สุด
4. การเพิ่มระดับสิทธิ์: การเปลี่ยนแปลงบทบาทเกิดขึ้น ทำให้ผู้โจมตีสามารถควบคุมบัญชีผู้ดูแลระบบที่มีสิทธิพิเศษสูงที่ใช้งานอยู่ได้อย่างเต็มที่

มาดูขั้นตอนเหล่านี้ทีละขั้นตอน:

การประนีประนอมเบื้องต้น

สำหรับจุดประสงค์ของการวิเคราะห์นี้ สมมติว่าสิ่งนี้เกิดขึ้นแล้ว ผู้โจมตีได้บุกรุกบัญชีของ “Shay Katz” ซึ่งได้รับมอบหมายให้เป็น “Helpdesk Administrator”

ภาพหน้าจอที่ 1: หน้าจอบทบาทที่ได้รับมอบหมายของ Shay Katz

ตารางต่อไปนี้นำมาจาก Entra IDหน้าเว็บบทบาทในตัวของ (เดิมคือ Azure AD) แสดงสิทธิ์ในการรีเซ็ตรหัสผ่านของบทบาทต่างๆ ภายใน Entra ID (เดิมชื่อ Azure AD) เราจะเห็นว่า “Helpdesk Administrator” ไม่สามารถรีเซ็ตรหัสผ่านของบทบาท “Authentication Admin” และ “Password Admin” ได้

หน้าจอ 2: Entra ID ตารางสิทธิ์การรีเซ็ตรหัสผ่าน (เดิมคือ Azure AD)

ผู้โจมตีได้เข้าสู่ระบบแล้ว Entra ID (เดิมชื่อ Azure AD) ในฐานะผู้ใช้ “Shay Katz”

การค้นพบการกำหนดบทบาทในอนาคต

ก่อนที่จะมีการแก้ไขของ Microsoft มีสองตัวเลือกในการค้นหางานผู้ดูแลระบบในอนาคตในราคาที่ถูกลง ผู้ใช้สิทธิ์:

1. ตลอด Entra ID พอร์ทัล (เดิมคือ Azure AD) โดยการตรวจสอบหน้า “คำขอที่รอดำเนินการ” สำหรับการมอบหมายบทบาทในอนาคตของผู้ดูแลระบบระดับที่สูงกว่า
2. ผ่านสคริปต์โดยใช้กราฟทรัพยากร

ก) การอนุญาตที่จำเป็น:

แสดงรายการคำขอสิทธิ์ของบทบาทตามกำหนดการ: ต้องการ: ReadWrite.AzureAD

รายการที่มี:

1. DeviceManagementApps อ่านทั้งหมด
2. DeviceManagementApps.ReadWrite.All
3. ไดเร็กทอรี.อ่าน.ทั้งหมด
4. ไดเรกทอรี ReadWrite.All
5. ผู้ใช้.อ่าน.ทั้งหมด
6. User.ReadBasic.All
7. User.ReadWrite.All

b) เรียกใช้แบบสอบถาม “https://graph.microsoft.com/beta/roleManagement/directory/roleEligibilityScheduleRequests” เพื่อรับคำขอตามกำหนดเวลา
กรองสถานะ = 'จัดเตรียม' AND ตารางข้อมูล ['startDateTime'] > ปัจจุบันและ รหัสบทบาทคำนิยาม ใน ProtectRoleIdList

c) เรียกใช้แบบสอบถาม “https://graph.microsoft.com/beta/users?$select=displayName,id” เพื่อรับ display_name ของผู้ใช้โดยใช้ปุ่ม PrincipalId

การใช้ Entra ID (เดิมชื่อ Azure AD) พอร์ทัล (ตัวเลือก A) ผู้โจมตีค้นพบบัญชีทดสอบตัวอย่างซึ่งขณะนี้ไม่มีการกำหนดบทบาท "ใช้งานอยู่" หรือ "มีสิทธิ์"

ภาพหน้าจอ 3: บัญชี 'ทดสอบ' โดยไม่มีการกำหนด 'มีสิทธิ์' หรือ 'ใช้งานอยู่'

อย่างไรก็ตาม ช่อง "เวลาร้องขอ" และ "เวลาเริ่มต้น" แสดงให้เราเห็นว่าบัญชีทดสอบนี้มีคำขอที่รอดำเนินการเพื่อเพิ่มเป็นผู้ดูแลระบบสากลในอนาคต

ภาพหน้าจอ 4: คำขอที่รอดำเนินการสำหรับบัญชีทดสอบเพื่อเป็น Global Administrator

ตอนนี้ผู้โจมตีพบเป้าหมายที่สมน้ำสมเนื้อแล้ว: บัญชีที่มีสิทธิพิเศษต่ำพร้อมการกำหนดบทบาทในอนาคต ตอนนี้เราสามารถย้ายไปยังขั้นตอนต่อไป

ตั้งค่ารหัสผ่าน

ผู้โจมตีสามารถรีเซ็ตรหัสผ่านบัญชีทดสอบได้โดยใช้ Entra ID (เดิมชื่อ Azure AD) พอร์ทัล:

ภาพหน้าจอ 5: รีเซ็ตรหัสผ่านสำหรับบัญชีทดสอบ

การเลื่อนระดับสิทธิ์

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

การแก้ไขของ Microsoft

Microsoft ได้แก้ไขปัญหาด้วยการใช้การควบคุมต่อไปนี้:

• ผู้ดูแลระบบที่มีสิทธิ์น้อยจะไม่เห็นคำขอที่รอดำเนินการในพอร์ทัลอีกต่อไป
• หากคุณพยายามรีเซ็ตรหัสผ่านสำหรับการกำหนดบทบาทพิเศษในอนาคต คุณจะพบข้อผิดพลาด (โดยปกติ หากคุณไม่ได้รับอนุญาตให้รีเซ็ตรหัสผ่าน ปุ่มรีเซ็ตรหัสผ่านจะถูกล็อก)

สรุป

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