Palo Alto Networks เผยแพร่คำแนะนำเกี่ยวกับช่องโหว่การปลอมแปลง KDC ใน PAN-OS ซึ่งถูกค้นพบและเปิดเผยอย่างมีความรับผิดชอบต่อ Palo Alto Networks โดย Silverfort นักวิจัย Yoav Iellin Yaron Kassner และ Rotem Zach. ช่องโหว่นี้ส่งผลกระทบต่อ PAN-OS เวอร์ชันที่รองรับทั้งหมด และอินเทอร์เฟซทั้งหมดที่ใช้ Kerberos การรับรอง ประวัติโดยย่อ. หลังจากเปิดเผยช่องโหว่ Palo Alto Networks ได้แก้ไข PAN-OS เวอร์ชันที่รองรับทั้งหมดและเผยแพร่ ที่ปรึกษา เกี่ยวกับมัน. ช่องโหว่นี้อาจทำให้ผู้โจมตีสามารถเลี่ยงผ่าน Kerberos การรับรองความถูกต้องกับ PAN-OS และการเข้าถึงอินเทอร์เฟซการดูแลระบบไปยัง PAN-OS ตลอดจนการรับรองความถูกต้องของเซสชันไฟร์วอลล์ผ่านพอร์ทัลแบบ Captive

ช่องโหว่นี้คล้ายกับ KDC ปลอมแปลงช่องโหว่ที่นักวิจัยของเราค้นพบใน Cisco ASA. ดูเหมือนว่าการนำโปรโตคอลการตรวจสอบสิทธิ์ Kerberos ไปใช้นั้นไม่ได้ดำเนินการอย่างถูกต้องเสมอไป ทำให้ระบบเสี่ยงต่อการถูกโจมตี

Palo Alto Networks แก้ไขช่องโหว่นี้ใน PAN-OS ทุกเวอร์ชัน เราขอแนะนำอย่างยิ่งให้ใช้แพตช์นี้เพื่อป้องกันการถูกโจมตี

บทความนี้แสดงรายละเอียดเกี่ยวกับช่องโหว่การปลอมแปลง KDC ใน PAN-OS และแสดงวิธีการใช้เพื่อหลีกเลี่ยงการตรวจสอบความถูกต้องโดยไม่ทราบรหัสผ่าน โดยจะอธิบายวิธีหลีกเลี่ยงช่องโหว่เหล่านี้ในฐานะนักพัฒนาที่ใช้ Kerberos ตลอดจนองค์กรต่างๆ ที่ใช้การตรวจสอบสิทธิ์ Kerberos กับระบบของตน

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

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

Palo Alto Networks ใช้โปรโตคอลการตรวจสอบสิทธิ์ Kerberos ในอินเทอร์เฟซ PAN-OS จำนวนมาก เช่น SSL VPN, Captive Portal หรือล็อกอินผู้ดูแลระบบ ดังนั้น การข้ามการตรวจสอบสิทธิ์ Kerberos ทำให้ผู้โจมตีสามารถดูแลระบบ Palo Alto Networks Strata เลี่ยงการรักษาความปลอดภัย และเข้าถึงเครือข่ายเพิ่มเติมได้

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

1. ผู้ใช้รับรองความถูกต้องกับเซิร์ฟเวอร์
2. เซิร์ฟเวอร์รับรองความถูกต้องกับลูกค้า
3. KDC รับรองความถูกต้องกับเซิร์ฟเวอร์

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

การค้นพบช่องโหว่ใน PAN-OS

เราค้นพบช่องโหว่เมื่อเราพยายามเพิ่ม SilverfortMFA ของ MFA ไปยังอินเทอร์เฟซที่ใช้โปรโตคอล Kerberos รวมถึง SSL VPN, Captive Portal และการเข้าสู่ระบบของผู้ดูแลระบบ ในการตั้งค่านี้ เราได้กำหนดค่า Kerberos เป็นวิธีการตรวจสอบสิทธิ์และกำหนดค่านโยบาย MFA ที่ตรงกันบน Silverfort ด้านข้าง. คำอธิบายโดยละเอียดเกี่ยวกับโปรโตคอล Kerberos และการปลอมแปลง KDC อยู่ที่ส่วนท้ายของบทความนี้
ดังที่เห็นด้านล่าง การจับภาพเครือข่ายประกอบด้วย AS-REQ และ AS-REP แต่ไม่มี TGS-REQ:

การรับรองความถูกต้องสำเร็จแม้ว่าโปรโตคอลจะต้องการ TGS-REQ และขาดหายไปจากกระบวนการตรวจสอบความถูกต้อง เนื่องจากเราได้ค้นพบแล้ว ช่องโหว่ที่คล้ายกันกับ Cisco ASAเราต้องการยืนยันสิ่งนี้

เราย้อนกลับไปตรวจสอบคำแนะนำของ Palo Alto Networks สำหรับการกำหนดค่าการรับรองความถูกต้องของ Kerberos ด้านล่างนี้คือภาพหน้าจอของคู่มือในขณะนั้น:

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

ความพยายามที่จะใช้ประโยชน์จากช่องโหว่

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

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

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

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

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

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

ในฐานะนักพัฒนา

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

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

พื้นหลัง

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

โปรโตคอลการตรวจสอบสิทธิ์ Kerberos ได้รับการพัฒนาในปี 1980 โดย Steve Miller และ Clifford Neuman อนุญาตให้ลงชื่อเพียงครั้งเดียว (SSO) ในเครือข่ายที่มีการจัดการและเครือข่ายนั้น Active Directory การใช้งาน (AD) ได้เปลี่ยนให้เป็นโปรโตคอลการตรวจสอบสิทธิ์หลักสำหรับสภาพแวดล้อมภายในองค์กร

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

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

ระหว่างการแลกเปลี่ยน AS ผู้ใช้จะตรวจสอบความถูกต้องกับ Key Distribution Center (KDC) ในทางกลับกัน ผู้ใช้จะได้รับตั๋วและรหัสที่จำเป็นในการตรวจสอบสิทธิ์กับบริการในเครือข่ายโดยไม่ต้องป้อนข้อมูลประจำตัวอีกครั้ง เมื่อผู้ใช้ป้อนข้อมูลประจำตัวเป็นครั้งแรก ไคลเอ็นต์จะส่ง AS_REQ ไปยังฟังก์ชัน Authentication Service (AS) ของ KDC AS_REQ คือข้อความที่ลงนามโดยมาสเตอร์คีย์ ซึ่งเป็นฟังก์ชันของรหัสผ่านของผู้ใช้ บริการรับรองความถูกต้องซึ่งเป็นส่วนหนึ่งของ 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 ซึ่งภายหลังเป็นผู้ร่วมก่อตั้ง Duo security ได้รายงานว่า เทคนิค ใช้เพื่อข้ามโปรโตคอล Kerberos ในบางสถานการณ์:

เขาพบว่าการใช้งานและการกำหนดค่าบางอย่างของไคลเอนต์ 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. อีกวิธีหนึ่งที่เป็นไปได้คือเข้าควบคุมอุปกรณ์เครือข่าย เช่น สวิตช์หรือเราเตอร์ และควบคุมการสื่อสารจากที่นั่น