นักวิจัยความปลอดภัยที่ Silverfortผู้ให้บริการแพลตฟอร์มการพิสูจน์ตัวตนแบบไม่ใช้เอเจนต์ พบช่องโหว่ร้ายแรงที่ทำให้แฮ็กเกอร์สามารถควบคุม Cisco Adaptive Security Appliance (ASA) ได้ เวอร์ชัน ASA ทั้งหมดได้รับผลกระทบ หลังจากเปิดเผยช่องโหว่ดังกล่าวแก่ Cisco แล้ว Cisco ได้แก้ไข ASA เวอร์ชันที่รองรับทั้งหมดและ เผยแพร่คำแนะนำ บนมัน ช่องโหว่ (CVE-2020-3125) ได้รับคะแนนความเสี่ยง CVSS 8.1 จาก 10 ซึ่งถือว่า "สูง" นี่เป็นเพราะช่องโหว่สามารถทำให้ผู้โจมตีสามารถหลีกเลี่ยงได้ Kerberos การรับรองความถูกต้องกับ Cisco ASA Silverfort นักวิจัยที่ได้รับเครดิตสำหรับการค้นพบช่องโหว่ ได้แก่ Yoav Iellin Yaron Kassner, ดอร์ ซีกัล & Rotem Zach.

Cisco แก้ไขช่องโหว่นี้ใน ASA ทุกเวอร์ชัน เราขอแนะนำให้องค์กรต่างๆ อัปเกรดเป็น ASA เวอร์ชันล่าสุดเพื่อป้องกันการเจาะระบบ

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

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

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

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

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

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

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

พื้นหลัง

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

เราค้นพบช่องโหว่ใน Cisco ASA ได้อย่างไร

เรากำลังมองหาวิธีเพิ่ม การตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) สำหรับผู้ดูแลระบบที่เข้าถึง Cisco ASA และ Anyconnect VPN หลังจากกำหนดค่า Cisco ให้ใช้ Kerberos เป็นโปรโตคอลการพิสูจน์ตัวตนแล้ว เราได้ตรวจสอบบันทึกการพิสูจน์ตัวตน Silverfortคอนโซลของ Silverfort ให้การมองเห็นเต็มรูปแบบในกิจกรรมการรับรองความถูกต้องทั้งหมดในเครือข่าย Silverfortบันทึกของแสดงให้เห็นว่า Cisco ASA กำลังขอ TGT โดยไม่ต้องขอตั๋วบริการ

เรากลับไปที่คู่มือการกำหนดค่า ซิสโก้. 2007. PIX/ASA : Kerberos Authentication และ LDAP Authorization Server Groups สำหรับผู้ใช้ไคลเอนต์ VPN ผ่านตัวอย่างการกำหนดค่า ASDM/CLI 30 กรกฎาคม. ; และดูพารามิเตอร์ที่จำเป็นในการกำหนดค่าการตรวจสอบสิทธิ์ Kerberos:

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

เราดำเนินการต่อและลองใช้แบบเดียวกันนี้กับอินเทอร์เฟซ Cisco อื่นๆ และพบว่ามีช่องโหว่เดียวกันนี้เมื่อเปิดเซสชันไฟร์วอลล์ การรับรองความถูกต้องของผู้ดูแลระบบ และแม้กระทั่งเมื่อใช้ SSH เพื่อเข้าถึง VM ดูด้านล่างคอลัมน์ Kerberos ในตารางสรุปการสนับสนุนของ Cisco สำหรับโปรโตคอลการรับรองความถูกต้องต่างๆ

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

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

เนื่องจากเราทราบชื่อผู้ใช้สำหรับผู้ดูแลระบบ Cisco ในโดเมนแรก (ในตัวอย่างนี้ Bob) เราจึงสร้างผู้ใช้ชื่อ Bob ในโดเมนปลอมของเรา เรากำหนดค่ารหัสผ่านของผู้ใช้รายนั้นในโดเมนปลอมให้เป็น “1”

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

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

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

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

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

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

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

1. ตรวจสอบว่าการใช้งาน Kerberos ต้องใช้รหัสผ่านหรือแท็บคีย์: ในการตรวจสอบ 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)