Silverfort นักวิจัยพบช่องโหว่ KDC Spoofing ใน F5 Big-IP [CVE-2021-23008]

ปีที่แล้วเราได้รายงานช่องโหว่การปลอมแปลง Key Distribution Center (KDC) สามรายการ Cisco ASA, เครือข่ายพาโลอัลโต PAN-OS และ IBM QRadar. เราได้พูดถึงอีกเรื่องหนึ่งที่กำลังจะมา และตอนนี้ก็เป็นเช่นนั้น F5 ได้ออกการแก้ไขเรากำลังเผยแพร่ช่องโหว่การปลอมแปลง KDC ครั้งที่สี่ที่เราระบุ ซึ่งคราวนี้อยู่ใน Big-IP ช่องโหว่ KDC Spoofing ช่วยให้ผู้โจมตีสามารถข้ามการตรวจสอบสิทธิ์ Kerberos ไปยัง Big-IP Access Policy Manager เลี่ยงนโยบายความปลอดภัย และเข้าถึงเวิร์กโหลดที่มีความละเอียดอ่อนได้อย่างไม่มีข้อจำกัด ในบางกรณีสามารถใช้เพื่อข้ามการตรวจสอบสิทธิ์ไปยังคอนโซลผู้ดูแลระบบ Big-IP ได้เช่นกัน เราได้ทำงานอย่างใกล้ชิดกับวิศวกรของ F5 เพื่อช่วยแก้ไขปัญหานี้ ซึ่งส่งผลให้ เพิ่งออกคำแนะนำ. โพสต์ในบล็อกนี้สรุปช่องโหว่ และอธิบายวิธีหลีกเลี่ยงข้อบกพร่องเหล่านี้เมื่อนำไปใช้งาน Kerberosและหารือเกี่ยวกับขั้นตอนการบรรเทาผลกระทบสำหรับลูกค้าที่ใช้ Big-IP และระบบที่ใช้ Kerberos อื่นๆ

อธิบายช่องโหว่

F5 Big-IP Application Delivery Services เป็นโซลูชันที่นำเสนอแอปพลิเคชันในลักษณะที่ปลอดภัยและปรับขนาดได้ หนึ่งในองค์ประกอบหลักคือ Access Policy Manager (APM) ซึ่งจัดการและบังคับใช้นโยบายเพื่อให้แน่ใจว่าการเข้าถึงได้รับการตรวจสอบสิทธิ์และอนุญาตอย่างเหมาะสม บางครั้ง APM ยังใช้เพื่อปกป้องการเข้าถึงคอนโซลผู้ดูแลระบบ Big-IP

ช่องโหว่นี้อยู่ที่การใช้งานโปรโตคอล Kerberos ของ F5 Kerberos เป็นโปรโตคอลการตรวจสอบสิทธิ์ที่ใช้บ่อยที่สุดสำหรับการตรวจสอบสิทธิ์ภายในองค์กร มีการใช้กันอย่างแพร่หลายในเครือข่ายองค์กรเนื่องจากความนิยมของ Active Directoryและเป็นที่ต้องการมากกว่าโปรโตคอลการตรวจสอบสิทธิ์ที่อ่อนแอ เช่น NTLM

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

เพื่อให้โปรโตคอล Kerberos ทำงานได้ ควรมีสามสิ่งต่อไปนี้:

1. ผู้ใช้รับรองความถูกต้องไปยังเซิร์ฟเวอร์
2. เซิร์ฟเวอร์รับรองความถูกต้องไปยังไคลเอนต์
3. KDC ตรวจสอบสิทธิ์ไปยังเซิร์ฟเวอร์

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

สำหรับคำศัพท์และภูมิหลังของ Kerberos เกี่ยวกับวิธีการทำงานของการโจมตีด้วยการปลอมแปลง KDC โปรดดูที่ส่วนท้ายของโพสต์บล็อกนี้

ด้านล่างนี้คือภาพหน้าจอคำแนะนำในการกำหนดค่าการตรวจสอบสิทธิ์ AD สำหรับนโยบายการเข้าถึง ซึ่งนำมาจาก เว็บไซต์ F5.

หลังจากการกำหนดค่านี้ เมื่อผู้ใช้พยายามตรวจสอบสิทธิ์แอปที่อยู่หลังพร็อกซี ผู้ใช้จะถูกขอให้ป้อนชื่อผู้ใช้และรหัสผ่าน เมื่อผู้ใช้ป้อนรหัสผ่าน ผลิตภัณฑ์จะใช้ Kerberos ในการตรวจสอบสิทธิ์กับตัวควบคุมโดเมน (DC) อย่างไรก็ตาม APM จะไม่ขอตั๋วบริการและให้สิทธิ์การเข้าถึงตาม AS_REP ที่สำเร็จ
ไม่เหมือนกับสถานการณ์อื่นๆ F5 ให้คุณกำหนดค่าชื่อผู้ใช้และรหัสผ่านของผู้ดูแลระบบ

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

การปลอมแปลงการรับรองความถูกต้องของ Kerberos

ต่อไปนี้เป็นขั้นตอนที่ผู้โจมตีสามารถทำได้เพื่อปลอมแปลง DC เพื่อเลี่ยงผ่านการรับรองความถูกต้องประเภทนี้ สมมติว่าเรามีความสามารถในการแย่งชิงการสื่อสารเครือข่ายระหว่าง Big-IP และ DC ในกรณีนี้ เราสามารถสร้าง DC ปลอมด้วยชื่อผู้ใช้ที่เหมือนกับชื่อผู้ใช้ของผู้ดูแลระบบและรหัสผ่านที่เราเลือก จากนั้นเราเริ่มต้นการตรวจสอบสิทธิ์กับ Big-IP และใช้ผู้ใช้และรหัสผ่านที่เราเลือก Big-IP ตรวจสอบสิทธิ์กับ Kerberos และเราแย่งชิงการสื่อสาร Kerberos และส่งคืน AS_REP ที่สอดคล้องกับรหัสผ่านที่เราเลือก และ TGS_REP ที่ประกอบด้วยตั๋วบริการที่เข้ารหัสด้วยคีย์เซสชันบริการที่เราเลือก และคีย์เซสชันที่เราเลือกซึ่งเข้ารหัสด้วยรหัสผ่านที่เราเลือก เนื่องจากในขั้นตอนเหล่านี้ การตรวจสอบความถูกต้องเพียงอย่างเดียวที่ทำบนฝั่ง Big-IP ขึ้นอยู่กับรหัสผ่านที่เราเลือก Big-IP จะอนุญาตให้มีการตรวจสอบสิทธิ์ได้

การแสวงหาผลประโยชน์

เราจำลองการโจมตีโดยเปลี่ยนเส้นทางการรับส่งข้อมูลระหว่าง Big-IP และ KDC (ในกรณีนี้คือตัวควบคุมโดเมน) บนพอร์ต 88 (พอร์ต Kerberos) ไปยังของเราเอง windows Server. เราตั้งค่าโดเมนปลอมบนเซิร์ฟเวอร์ windows และตรวจสอบให้แน่ใจว่ามีผู้ใช้ที่มี UPN เดียวกันกับผู้ดูแลระบบ Big-IP ในโดเมนจริง เรากำหนดค่ารหัสผ่านของผู้ใช้นั้นเป็น “1” ในโดเมนปลอม

จากนั้นเราลองสถานการณ์ต่อไปนี้:

• เข้าสู่ระบบปกติ (ไม่เปลี่ยนเส้นทางการรับส่งข้อมูล) – เราจัดการเพื่อเข้าสู่ระบบด้วยรหัสผ่านเดิมของผู้ใช้ตามที่คาดไว้ เมื่อลองใช้รหัสผ่าน “1” การเข้าสู่ระบบล้มเหลว
• การเข้าสู่ระบบโดยเปลี่ยนเส้นทางการรับส่งข้อมูลไปยัง DC ปลอมของเรา การเข้าสู่ระบบด้วยรหัสผ่านเดิมของผู้ดูแลระบบล้มเหลว แต่การเข้าสู่ระบบด้วยรหัสผ่าน "1" ทำงานได้

การป้องกันและบรรเทาสาธารณภัย

ขั้นตอนการบรรเทาผลกระทบสำหรับผู้เชี่ยวชาญด้านความปลอดภัย

1. อัปเกรด Big-IP ของคุณเป็นเวอร์ชันที่แก้ไขแล้ว
2. หากไม่มีเวอร์ชันที่แก้ไขแล้วสำหรับเวอร์ชันของ Big-IP ที่คุณใช้อยู่ ให้ตรวจสอบให้แน่ใจ ไอ้เวรตะไล เปิดใช้งาน.
3. อัปเดตของคุณ Silverfort นโยบายสำหรับ Big-IP ตามนั้น
4. ตรวจสอบการรับรองความถูกต้อง Kerberos ของคุณอย่างต่อเนื่อง ค้นหาทรัพยากรที่ขอ AS_REQ เท่านั้น หากไม่มี TGS_REQ แสดงว่าเป็นสัญญาณสีแดง
5. ใช้ Silverfortเครื่องมือโอเพ่นซอร์สของ เพื่อค้นหาบันทึกการรับรองความถูกต้องสำหรับบริการที่ไม่ได้ร้องขอตั๋วบริการ
6. ดูคำแนะนำสำหรับนักพัฒนาสำหรับแอปพลิเคชันที่พัฒนาภายในที่ใช้ Kerberos และระบบที่คุณกำหนดค่าด้วยตนเอง

สำหรับนักพัฒนา

เราขอแนะนำสองสามขั้นตอนเพื่อให้แน่ใจว่าโซลูชันของคุณไม่เสี่ยงต่อการปลอมแปลง KDC:

1. ตรวจสอบว่าการใช้งาน Kerberos ต้องใช้รหัสผ่านหรือแท็บคีย์: ในการตรวจสอบ DC คุณต้องใช้ความลับที่ใช้ร่วมกันบางประเภท หากโซลูชันของคุณไม่เปิดใช้งานการกำหนดค่าไฟล์แท็บคีย์ หรือ บัญชีบริการ รหัสผ่าน แอปพลิเคชันมีความอ่อนไหวต่อการปลอมแปลง KDC อย่างแน่นอน
2. เรียกใช้ Wireshark – ใช้ Wireshark เพื่อดูว่าคำขอ Kerberos ใดถูกส่งไปในระหว่างการตรวจสอบสิทธิ์ หากไม่มี TGS_REQ นี่เป็นธงสีแดง
3. หากคุณต้องการใช้โปรโตคอลการตรวจสอบสิทธิ์ด้วยตนเอง คุณต้องปฏิบัติตามข้อกำหนดของโปรโตคอลอย่างจริงจัง เราขอแนะนำให้ใช้เส้นทางที่ง่ายกว่าและใช้การใช้งานโปรโตคอลเหล่านี้ที่มีอยู่
4. ใช้ไลบรารีของบุคคลที่สามอย่างเหมาะสม - ไลบรารีของบุคคลที่สามบางแห่งจำเป็นต้องมีการกำหนดค่าเฉพาะเพื่อหลีกเลี่ยงการปลอมแปลง KDC ตัวอย่างเช่น ไลบรารีทั่วไปที่ใช้สำหรับ Kerberos ชื่อ pam-krb3 จะต้องมีแท็บคีย์ที่กำหนดค่าให้ทำงานได้อย่างถูกต้อง นี่คือย่อหน้าที่เกี่ยวข้องจากเอกสารของพวกเขา (https://github.com/rra/pam-krb5/blob/master/README.md)

ทำอะไรต่อไป

ฉันแน่ใจว่านี่เป็นช่องโหว่การปลอมแปลง KDC สุดท้ายที่เราเคยพบมา

พื้นหลัง

ภาพรวมของพิธีสาร Kerberos

โปรโตคอลการตรวจสอบสิทธิ์ Kerberos ได้รับการพัฒนาในปี 1980 โดย Steve Miller และ Clifford Neuman อนุญาตให้ลงชื่อเพียงครั้งเดียว (SSO) ในเครือข่ายที่มีการจัดการและเครือข่ายนั้น Active Directory การใช้งาน (AD) ได้เปลี่ยนให้เป็นโปรโตคอลการตรวจสอบสิทธิ์หลักสำหรับสภาพแวดล้อมภายในองค์กร
โปรโตคอลประกอบด้วยการแลกเปลี่ยนสามครั้งเพื่อให้การรับรองความถูกต้องร่วมกันสำหรับผู้ใช้และเซิร์ฟเวอร์ที่เข้าถึง เมื่อผู้ใช้เข้าสู่ระบบ ผู้ใช้จะป้อนข้อมูลประจำตัวและการแลกเปลี่ยน Authentication Service (AS) จะเกิดขึ้น ผู้ใช้จะได้รับ Ticket Granting Service (TGT) ซึ่งจะใช้ในภายหลังเพื่อรับตั๋วไปยังบริการเฉพาะในระหว่างการแลกเปลี่ยน Ticket Granting Service (TGS) ตั๋วจะถูกใช้ในระหว่างการแลกเปลี่ยนไคลเอนต์/เซิร์ฟเวอร์เพื่อทำการรับรองความถูกต้อง:

1. บริการรับรองความถูกต้อง (AS) Exchange

ในระหว่างการแลกเปลี่ยน AS ผู้ใช้จะรับรองความถูกต้องกับ Key Distribution Center (KDC) ในทางกลับกัน ผู้ใช้จะได้รับตั๋วและคีย์ที่จำเป็นในการตรวจสอบสิทธิ์กับบริการในเครือข่ายโดยไม่ต้องป้อนข้อมูลประจำตัวอีกครั้ง เมื่อผู้ใช้ป้อนข้อมูลประจำตัวครั้งแรก ไคลเอ็นต์จะส่ง AS_REQ ไปยังฟังก์ชัน Authentication Service (AS) ของ KDC AS_REQ เป็นข้อความที่ลงนามโดยมาสเตอร์คีย์ ซึ่งเป็นฟังก์ชันของรหัสผ่านของผู้ใช้ Authentication Service ซึ่งเป็นส่วนหนึ่งของ KDC จะตรวจสอบ AS_REQ ตามคีย์หลัก ซึ่ง KDC สามารถใช้ได้เช่นกัน หลังจากการตรวจสอบความถูกต้องของ AS_REQ แล้ว KDC จะส่งกลับ AS_REP ซึ่งมีคีย์เซสชันการเข้าสู่ระบบและ Ticket-Granting Ticket (TGT) ที่ถูกเข้ารหัสด้วยคีย์ของ KDC AS Exchange มีรายละเอียดดังนี้ TGT จะถูกใช้โดยการแลกเปลี่ยน TGS เพื่อเข้าถึงบริการเฉพาะ

2.การแลกเปลี่ยนบริการออกบัตรโดยสาร (TGS)

เมื่อผู้ใช้พยายามเข้าถึงบริการในเครือข่าย ผู้ใช้จะส่ง TGS_REQ ไปยังฟังก์ชัน Ticket Granting Server (TGS) ของ KDC ข้อความนี้เข้ารหัสด้วยคีย์เซสชันการเข้าสู่ระบบ ซึ่งได้รับระหว่าง AS Exchange TGS_REQ ได้รับการตรวจสอบโดย TGS ซึ่งจะส่งคืน TGS_REP TGS_REP ประกอบด้วยคีย์เซสชันบริการและตั๋วบริการ ซึ่งเข้ารหัสด้วยคีย์หลักของเซิร์ฟเวอร์ที่โฮสต์บริการ มาสเตอร์คีย์ของเซิร์ฟเวอร์ในระบบที่ใช้ Unix ได้รับการกำหนดค่าในไฟล์ที่เรียกว่าไฟล์แท็บคีย์ มาสเตอร์คีย์ของเซิร์ฟเวอร์ในเซิร์ฟเวอร์สมาชิกได้มาจากรหัสผ่านของบัญชีคอมพิวเตอร์ TGS Exchange แสดงไว้ด้านล่าง

3.การแลกเปลี่ยนไคลเอนต์/เซิร์ฟเวอร์

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

โปรโตคอลป้องกันการปลอมแปลง

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

KDC Spoofing คืออะไร?

ในปี 2000 Dug Song รายงานก ความอ่อนแอ ที่ส่งผลต่อโปรโตคอล Kerberos (เพลง Dug.2000. ช่องโหว่ Kerberos KDC Spoofing 28 สิงหาคม).

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

1. สร้าง KDC ปลอม
2. รับชื่อผู้ใช้ที่ได้รับอนุญาตให้เข้าถึงบริการที่ต้องการโจมตี
3. สร้างผู้ใช้ใน KDC ปลอมด้วยรหัสผ่านที่ผู้โจมตีเลือก ตัวอย่างเช่น ลองเรียกรหัสผ่านนี้ว่า "1"
4. รับรองความถูกต้องกับบริการด้วยชื่อผู้ใช้และรหัสผ่านที่ได้รับ "1"
5. จี้การสื่อสารจากไคลเอนต์ไปยัง DC และโอนไปยัง KDC ปลอม
6. ระหว่าง AS Exchange ให้ส่งคืน AS_REP ที่สอดคล้องกับรหัสผ่าน ”1” คีย์ KDC ปลอม และคีย์เซสชันการเข้าสู่ระบบปลอม
7. ระหว่างการแลกเปลี่ยน TGS ให้ส่งคืน TGS_REP ใดๆ
8. ลูกค้าจะยอมรับการรับรองความถูกต้องโดยไม่ต้องทำการแลกเปลี่ยนแอปพลิเคชัน

การโจมตีด้วยการปลอมแปลง KDC ถือว่าผู้โจมตีสามารถแย่งชิงการรับส่งข้อมูลเข้าและออกจาก KDC และตอบกลับในนามของ KDC ซึ่งสามารถทำได้โดยใช้เทคนิคต่างๆ ตัวอย่างเช่น หากผู้โจมตีอยู่ในกลุ่มเครือข่ายทางกายภาพเดียวกันกับไคลเอนต์ ผู้โจมตีก็สามารถโจมตีด้วยการปลอมแปลง ARP ดังที่ระบุไว้ใน Network Security Hacks (Lockhart 2007). อีกวิธีหนึ่งที่เป็นไปได้คือเข้าควบคุมอุปกรณ์เครือข่าย เช่น สวิตช์หรือเราเตอร์ และควบคุมการสื่อสารจากอุปกรณ์นั้น

กิตติกรรมประกาศ

การวิจัยและการค้นพบช่องโหว่นี้เป็นความพยายามร่วมกับ Thierry Van Steirteghem ซึ่งทำงานที่ Exclusive Networks ในขณะที่ค้นพบ