ช่วยให้องค์กรสามารถแก้ไขความเสี่ยงของ NTLMv1

หน้าแรก » บล็อก » ช่วยให้องค์กรสามารถแก้ไขความเสี่ยงของ NTLMv1

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

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

จากนั้นเราจะแสดงวิธีการ Silverfort ช่วยให้องค์กรสามารถเอาชนะความเสี่ยงจาก NTLMv1 ด้วยการค้นพบ การตรวจสอบ และ ควบคุมทุกการรับรองความถูกต้อง และความพยายามในการเข้าถึงที่ยังคงใช้โปรโตคอลโบราณนี้ 

การรับรองความถูกต้อง NTLM: ประวัติโดยย่อ

ตามที่ วิกิพีเดีย, "ใน Windows เครือข่าย New Technology LAN Manager (NTLM) เป็นชุดของ ไมโครซอฟท์ โปรโตคอลความปลอดภัยที่มีจุดประสงค์เพื่อให้การรับรองความถูกต้อง ความสมบูรณ์ และการรักษาความลับแก่ผู้ใช้ NTLM เป็นตัวตายตัวแทนของโปรโตคอลการรับรองความถูกต้องใน Microsoft ตัวจัดการ LAN. ชุดโปรโตคอล NTLM ถูกนำมาใช้ใน ผู้ให้บริการสนับสนุนความปลอดภัยซึ่งผสมผสานระหว่าง ตัวจัดการ LAN โปรโตคอลการตรวจสอบความถูกต้อง NTLMv1, NTLMv2 และ NTLM2 ในแพ็คเกจเดียว” (NTLM2 รวมทั้ง NTLMv1 และ NTLMv2) 

NTLMv1 เปิดตัวในปี 1993 และเป็นโปรโตคอลการตรวจสอบความถูกต้องที่ตอบสนองต่อความท้าทาย ซึ่งหมายความว่ากระบวนการตรวจสอบความถูกต้องจะดำเนินการในสามขั้นตอน: 

  1. เครื่องไคลเอนต์สร้างการเชื่อมต่อเครือข่ายไปยังเซิร์ฟเวอร์เป้าหมาย
  2. เซิร์ฟเวอร์ส่งคำท้าไปยังเครื่องไคลเอนต์
  3. เครื่องไคลเอนต์ตอบสนองต่อความท้าทายและเซิร์ฟเวอร์จะอนุญาตหรือปฏิเสธการเข้าถึงตามการตอบสนอง

ในปี 1998 NTLMv2 ได้รับการเผยแพร่บน Windows NT 4.0 SP 4 และเป็นโปรโตคอลเวอร์ชันปัจจุบันตั้งแต่นั้นเป็นต้นมา

ปัญหาด้านความปลอดภัย NTLM ทั่วไป

การรับรองความถูกต้อง NTLM ทุกเวอร์ชันประสบปัญหาด้านความปลอดภัยต่อไปนี้:

  1. ขาด เกลือ ทำให้เทียบเท่ากับรหัสผ่านแฮช หมายความว่าหากคุณสามารถดึงค่าแฮชจากเซิร์ฟเวอร์ได้ คุณจะสามารถตรวจสอบสิทธิ์ได้โดยไม่ต้องรู้รหัสผ่านจริง ซึ่งหมายความว่าผู้โจมตีที่สามารถดึงแฮชได้ และมีหลายวิธีในการดัมพ์จากหน่วยความจำของเครื่อง จะสามารถเข้าถึงเซิร์ฟเวอร์เป้าหมายและปลอมตัวเป็นผู้ใช้จริงได้อย่างง่ายดาย
  2. แม้ว่าเซิร์ฟเวอร์จะตรวจสอบตัวตนของไคลเอนต์อย่างแท้จริง แต่ก็ไม่มีการยืนยันตัวตนของเซิร์ฟเวอร์ที่สอดคล้องกัน ซึ่งเปิดโอกาสให้มีการโจมตีแบบ Man-In-The-Middle (MITM)
  3. NTLMv1 ขาดการท้าทายไคลเอ็นต์ – ในกรณีที่มีการโจมตี NTLMv1 ผู้โจมตีสามารถบังคับให้ไคลเอ็นต์คำนวณการตอบสนอง NTLMv1 ด้วยความท้าทายของเซิร์ฟเวอร์ที่รู้จัก จากนั้น ผู้โจมตีสามารถเดารหัสผ่านของผู้ใช้ได้อย่างมีประสิทธิภาพโดยการตรวจสอบการตอบสนองของ NTLMv1 กับ โต๊ะสายรุ้ง.
  4. ขาด ไอ้เวรตะไล การสนับสนุนจะกีดกันโปรโตคอลของการป้องกันใด ๆ ในกรณีของรหัสผ่านหรือแฮชที่ถูกบุกรุก 

ข้อกังวลเหล่านี้ทำให้ Microsoft แทนที่ NTLM ด้วยความปลอดภัยที่มากกว่า Kerberos โปรโตคอลการตรวจสอบความถูกต้องเป็นค่าเริ่มต้นในสภาพแวดล้อม AD แม้ว่าจะเก็บ NTLM ไว้เป็นข้อมูลสำรองก็ตาม แต่ถึงแม้จะอยู่ใน NTLM ก็ตาม NTLMv1 ก็มีความปลอดภัยน้อยกว่า NTLMv2 ที่ตามมาอย่างมาก

อะไรทำให้ NTLMv1 มีความเสี่ยงด้านความปลอดภัย

ระดับความปลอดภัยของโปรโตคอลขึ้นอยู่กับความท้าทาย ยิ่งยากต่อการประนีประนอม การรับรองความถูกต้องก็จะปลอดภัยมากขึ้น 

ในกรณีของ NTLMv1 ความแตกต่างอยู่ที่ความท้าทายเฉพาะ:

  1. NTLMv1 สร้างความท้าทายด้วยตัวเลขความยาวคงที่ 16 บิต ในขณะที่ NTLMv2 สร้างความท้าทายด้วยความยาวผันแปร
  2. NTLMv1 ใช้อัลกอริธึมการเข้ารหัส DES ที่อ่อนแอซึ่งถอดรหัสได้รวดเร็ว ทำให้เสี่ยงต่อการถูกดุร้าย ในขณะที่ NTLMv2 ใช้ HMAC-MD5 ที่ช้ากว่าซึ่งสามารถต้านทานการโจมตีเหล่านี้ได้ดีกว่า เนื่องจากการถอดรหัสไม่สามารถเกิดขึ้นได้แบบเรียลไทม์ 

ดังนั้นระบบใดๆ ที่ใช้การพิสูจน์ตัวตนแบบ NTLMv1 จึงเสี่ยงต่อการถูกประนีประนอม เนื่องจากผู้โจมตีสามารถสร้างวิธีการยอมรับความท้าทายและเข้าถึงระบบได้อย่างง่ายดาย 

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

อุปสรรคในการตรวจจับและลบ NTLMv1

ในโลกอุดมคติ จะมีตัวกรองบางตัวที่เมื่อคลิกแล้วจะเปิดเผยการตรวจสอบสิทธิ์ NTLMv1 ทั้งหมดที่เกิดขึ้นภายในสภาพแวดล้อม น่าเสียดายที่ความจริงไม่ง่ายอย่างนั้น

เส้นทางที่ตรงไปตรงมาที่สุดคือเปิดใช้งานการตรวจสอบการเข้าสู่ระบบสำเร็จบนตัวควบคุมโดเมน ตามเอกสารประกอบของ Microsoft ตำแหน่งข้อมูลแต่ละจุดควรสร้างเหตุการณ์พร้อมข้อมูลที่จำเป็น (เหตุการณ์การตรวจสอบสำเร็จ 4624 ซึ่งมีข้อมูลเกี่ยวกับรุ่นของ NTLM บันทึกเหตุการณ์ที่ได้รับมีฟิลด์ 'ชื่อแพ็คเกจ (NTLM เท่านั้น)' ที่ระบุว่า NTLM ของ รุ่น). อย่างไรก็ตาม การรวบรวมบันทึกเหล่านี้ไม่สามารถทำได้จากส่วนกลางบน DC และต้องเรียกค้นจากแต่ละเครื่อง เช่นกัน ในหลายกรณี เหตุการณ์ไม่มีข้อมูลเวอร์ชัน NTLM หรือยังไม่ได้สร้างด้วยซ้ำ 

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

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

ดังนั้นความท้าทายจึงไม่ได้อยู่ที่ความไม่ปลอดภัยในตัวของ NTLMv1 เท่านั้น แต่ยังอยู่ที่ความยากลำบากในการพิจารณาว่ามีการใช้ภายในสภาพแวดล้อมที่กำหนดหรือไม่ 

Silverfortการป้องกันของพื้นผิวการโจมตี NTLMv1

พื้นที่ Silverfort การป้องกันตัวตนแบบครบวงจร แพลตฟอร์มช่วยให้องค์กรมีความสามารถพิเศษ ไม่เพียงแต่ค้นหาการพิสูจน์ตัวตน NTLMv1 ทั้งหมดภายในสภาพแวดล้อมเท่านั้น แต่ยังปิดกั้นการพิสูจน์ตัวตนเหล่านั้นด้วย 

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

การค้นพบ

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

ตารางบันทึก ntlmv1

NTLMv1 เปิดใช้งานใน Silverfortหน้าจอบันทึกการรับรองความถูกต้องของ

การป้องกัน 

ในทำนองเดียวกัน Silverfort เปิดใช้งานการใช้ตัวบ่งชี้ความเสี่ยง NTLMv1 เป็นทริกเกอร์เพื่อเปิดใช้งานนโยบายการเข้าถึง การกระทำจะเป็นอย่างใดอย่างหนึ่ง:

  • ปฏิเสธ: เลือกตัวเลือกนี้หากคุณไม่ต้องการอนุญาต NTLMv1 เลยภายในสภาพแวดล้อมเพื่อเป็นมาตรการป้องกันเพิ่มเติม
ntlmv1 ปฏิเสธนโยบาย

Silverfort นโยบายปฏิเสธการเข้าถึงผ่าน NTLMv1

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

Silverfort นโยบายกำหนดให้ MFA step-up เมื่อตรวจสอบสิทธิ์ผ่าน NTLMv1

เส้นทางสู่ความปลอดภัยที่ครอบคลุม

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

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

เป็น NTLMv1 หรือไม่ พื้นผิวการโจมตี คุณต้องการที่จะอยู่? กำหนดเวลาการประชุมกับผู้เชี่ยวชาญของเรา  โปรดคลิกที่นี่เพื่ออ่านรายละเอียดเพิ่มเติม.

หยุดการคุกคามตัวตนเดี๋ยวนี้