ภัยคุกคามจากการมอบหมาย: เจาะลึก Microsoft Patch ของช่องโหว่ KCD CVE-2020-17049

*****โดย Dor Segal นักวิจัยด้านความปลอดภัยที่ Silverfort*****

เมื่อวันที่ 11 พฤศจิกายน 2020 Microsoft ได้เปิดเผย CVE-2020-17049 ซึ่งเป็นเวอร์ชันใหม่ Kerberos ช่องโหว่บายพาสคุณลักษณะด้านความปลอดภัย แม้ว่าช่องโหว่ดังกล่าวจะไม่ได้รับการแก้ไขก่อนวันที่ 8 กุมภาพันธ์ 2021 แต่ Microsoft ได้ออกแพตช์ในวันที่ 8 พฤศจิกายนและ 8 ธันวาคม เพื่อลดการแสวงประโยชน์ในระหว่างนี้ มีการเปิดเผยน้อยมากเกี่ยวกับการทำงานภายในของช่องโหว่ โดยไม่มี POC สาธารณะหรือการวิเคราะห์ทางเทคนิค
โพสต์นี้พยายามเติมเต็มช่องว่างนี้บางส่วนโดยให้ความกระจ่างเกี่ยวกับ Kerberos Delegation โดยทั่วไปและเจาะลึกลงไปในแพตช์ที่ Microsoft ได้ออกสำหรับช่องโหว่ KCD CVE-2020-17049

คณะผู้แทน Kerberos 101

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

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

ขั้นที่ 1: การมอบหมายที่ไม่มีข้อจำกัด

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

กระบวนการนี้กำหนดให้ผู้ใช้ขอ TGT ที่ส่งต่อได้และแนบไปกับตั๋วบริการ จากนั้นบริการจะใช้ TGT และแทรกลงในแคชในเครื่อง lsass.exe เพื่อใช้ในภายหลัง

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

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

ขั้นตอนที่ 2: การมอบหมายที่มีข้อจำกัด

การมอบสิทธิ์รุ่นต่อไปมีข้อจำกัดมากขึ้น และอนุญาตให้บริการเลียนแบบการเข้าถึงเฉพาะทรัพยากรที่กำหนดด้วยแฟล็ก "บัญชีมีความละเอียดอ่อนและไม่สามารถมอบสิทธิ์ได้" บน Active Directory เพื่อจำกัดผู้ใช้เฉพาะจากการแอบอ้างบุคคลอื่น
การมอบหมายประเภทนี้เป็นที่ที่บริการดำเนินการตรวจสอบความถูกต้องโดยใช้ส่วนขยาย S4U2Self และ S4U2Proxy (MS-SFU)

ดังนั้นวิธีที่จะทำงาน?

บัญชีบริการของเราต้องเปิดใช้งานการตั้งค่าสถานะ TRUSTED_TO_AUTH_FOR_DELEGATION และแอตทริบิวต์ ms-AllowedToDelegateTo ที่มี SPN ของทรัพยากร

ผู้ใช้รับรองความถูกต้องตามปกติกับบริการโดยใช้การเจรจา kerberos (TGT & TGS)

ตอนนี้สิ่งนี้เริ่มซับซ้อน: บัญชีบริการที่ได้รับมอบสิทธิ์ร้องขอ TGT ที่ส่งต่อได้ให้กับตัวเอง เราใช้ตั๋วนี้เพื่อขอตั๋วบริการโดยใช้ S4U2SELF โดยใช้ชื่อผู้ใช้ปลอมสำหรับฟิลด์ PA-DATA ชื่อของเรา

บริการรับตั๋วนี้ แนบไปกับตั๋วบริการทรัพยากร (S4U2Proxy) ด้วยแฟล็กการมอบหมายที่มีข้อจำกัด

ตั๋วที่ได้รับเป็นการเลียนแบบผู้ใช้ปัจจุบันโดยบริการของเรา

ขั้นตอนที่ 3: การมอบหมายที่มีข้อจำกัดตามทรัพยากร

ความแตกต่างที่สำคัญในการมอบหมายนี้ส่วนใหญ่เป็นการบริหาร

แทนที่จะอนุญาตให้บริการได้รับสิทธิ์ในการเข้าถึงทรัพยากร เราให้อำนาจแก่เจ้าของทรัพยากรในการกำหนดบริการที่ได้รับอนุญาตให้ดำเนินการมอบหมาย

สิ่งนี้สามารถกำหนดค่าได้โดย PowerShell โดยใช้ Principals AllowedToDelegateToAccount พารามิเตอร์ หรือเพียงแค่แก้ไขแอตทริบิวต์ msDS-Allowed To Act OnBehalofOfOtherIdentity

Microsoft Security Patch สำหรับ CVE-2020-17049 – การวิเคราะห์ทางเทคนิค

ช่องโหว่ของโปรโตคอลนั้นยากที่จะบรรเทาลงเสมอ เนื่องจากต้องรองรับความเข้ากันได้แบบย้อนหลัง

เราเริ่มดูแพตช์ของ Microsoft โดยอ่านข้อมูลที่เผยแพร่บนเว็บไซต์อย่างเป็นทางการ

เราทราบดีว่าช่องโหว่นี้เกี่ยวกับ "การปลอมแปลงตั๋ว" และพบช่องโหว่อยู่ในกระบวนการของ Kerberos Constrained Delegation

เราเลือกที่จะจำลองการมอบสิทธิ์บน Domain Controller ที่มีช่องโหว่และทำซ้ำบนแพตช์เพื่อตรวจสอบความแตกต่าง:

การเปลี่ยนแปลงที่เห็นได้ชัดเจนอย่างแรกอยู่ที่ความยาวของแต่ละแพ็กเก็ต เราจะเห็นว่าคำขอ Self-Signed Ticket (S4U2Self) นั้นเหมือนกันแต่การตอบกลับนั้นยาวกว่า 40 ไบต์

สิ่งนี้ใช้กับคำขอและการตอบกลับ S4U2Proxy ถัดไปด้วย มีอะไรเปลี่ยนแปลงบ้าง

การเปรียบเทียบข้อความไม่มีประโยชน์เนื่องจากข้อความที่เปลี่ยนถูกเข้ารหัสภายในตั๋ว

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

เมื่อดูที่ฟิลด์ AuthorizationData เราจะเห็นฟิลด์ใหม่ที่ไม่รู้จัก เริ่มต้นที่ offset 840 ด้วยขนาด 20

สนามใหม่นี้มาจากไหน? KDC รับมืออย่างไร?

สิ่งที่ฉันชอบมากที่สุดเกี่ยวกับโปรโตคอลคือโปรโตคอลส่วนใหญ่มีการบำรุงรักษาและอัปเดต RFC อย่างสม่ำเสมอ – และ Kerberos ก็ไม่มีข้อยกเว้น

เที่ยว MS-SFU สังเกตว่ามีการอัปเดตเมื่อวันที่ 11/23/2020 เมื่อเราเปิด เอกสารต่าง เราเรียนรู้แมลง 3.2.5.2.2 ว่ามีลายเซ็นใหม่ที่ใช้ในการตรวจสอบความสมบูรณ์ของตั๋ว นอกจากนี้ แพตช์ของไมโครซอฟต์บอกใบ้ว่าตั๋วแก้ไขใบแรกคือ S4U2Self
เราได้ดึงข้อมูลเพิ่มเติมจาก RFC โดยดูที่การอ้างอิงของ Ticket Signature – MS-PAC 2.8.3:
“KDC จะใช้คีย์ KDC (krbtgt) [RFC4120] เพื่อให้ KDC อื่นๆ สามารถตรวจสอบลายเซ็นนี้ได้เมื่อได้รับ PAC”
“ลายเซ็นตั๋วใช้เพื่อตรวจจับการปลอมแปลงตั๋วโดยฝ่ายอื่นที่ไม่ใช่ KDC ลายเซ็นตั๋วควรรวมอยู่ในตั๋วที่ไม่ได้เข้ารหัสบัญชี krbtgt (รวมถึงบริการเปลี่ยนรหัสผ่าน) หรือบัญชีที่เชื่อถือ”
“ตรงกับลายเซ็นตั๋วจะมีค่า 0x00000010”
MS-PAC RFC เปิดเผยความลึกลับเบื้องหลังฟิลด์ที่ไม่รู้จักใน offset 840 ซึ่งเป็นลายเซ็นตั๋วใหม่ที่เข้ารหัสโดยใช้คีย์ krbtgt เพื่อตรวจสอบความถูกต้อง

Kerberos บรอนซ์บิต

เมื่อวันที่ 8 ธันวาคมการดำเนินการของ CVE-2020-17049 ช่องโหว่ KCD ใน Kerberos การโจมตีบิตสีบรอนซ์ ได้รับการเผยแพร่ในรายละเอียดเพิ่มเติม ให้ความกระจ่างเพิ่มเติมเกี่ยวกับการจัดการตั๋ว S4U2Self

การใช้ประโยชน์เกี่ยวข้องกับการถอดรหัสและแก้ไขบิตของฟิลด์ที่สามารถส่งต่อได้ภายใน encRepPart ของตั๋ว

บริการที่มีความสามารถในการมอบหมายสามารถสร้างตั๋ว S4U2Self ได้ ผู้ใช้ทุกคน แม้แต่ผู้ที่มีการตั้งค่าสถานะ 'บัญชีมีความละเอียดอ่อนและไม่สามารถมอบสิทธิ์ได้'
การตั้งค่าสถานะนี้ตั้งค่าสถานะการส่งต่อเป็น False แต่ตั๋วไม่เคยผ่านการตรวจสอบโดย KDC ในกรณีที่มีการแก้ไข

คำสุดท้าย

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