การรักษาความปลอดภัยที่ร้ายแรง: ข้อผิดพลาดในการเข้าสู่ระบบ Samba เกิดจากการเข้ารหัสลับที่ล้าสมัย

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

ในช่วงปลายทศวรรษที่ 1990 ระบบเครือข่ายของ Microsoft ได้ขจัดลักษณะที่ทึบและเป็นกรรมสิทธิ์ออกไป และกลายเป็นมาตรฐานเปิดที่เรียกว่า CIFS ซึ่งย่อมาจาก ระบบไฟล์อินเทอร์เน็ตทั่วไป.

แต่ไม่มีอะไรที่ "ทั่วไป" หรือ "เปิด" เกี่ยวกับเรื่องนี้ในช่วงต้นทศวรรษ 1990 เมื่อ Andrew Tridgell นักวิชาการชาวออสเตรเลียเริ่มแก้ไขโดยการนำระบบที่เข้ากันได้ซึ่งจะช่วยให้เขาเชื่อมต่อคอมพิวเตอร์ Unix กับเครือข่าย Windows และในทางกลับกัน

ในตอนนั้น โปรโตคอลถูกเรียกอย่างเป็นทางการว่า SMB ซึ่งย่อมาจาก บล็อกข้อความเซิร์ฟเวอร์ (ชื่อที่คุณยังคงได้ยินบ่อยกว่า CIFS) ดังนั้น Tridge ซึ่งเป็นที่รู้จักในชื่อ Andrew Tridgell จึงเรียกโปรเจ็กต์ของเขาว่า "SMBserver" เพราะนั่นคือสิ่งที่เคยเป็นมา

แต่มีผลิตภัณฑ์เชิงพาณิชย์ของชื่อนั้นอยู่แล้ว ดังนั้นจึงจำเป็นต้องมีชื่อเล่นใหม่

นั่นคือเมื่อโครงการกลายเป็นที่รู้จักในฐานะ แซมบ้าชื่อที่น่าจดจำซึ่งเป็นผลมาจากการค้นหาพจนานุกรมสำหรับคำในรูปแบบนี้ S?M?B?.

ในความเป็นจริง samba ยังคงเป็นคำแรกที่ออกจากประตูตามตัวอักษรใน dict ไฟล์ที่พบได้ทั่วไปในคอมพิวเตอร์ Unix ตามด้วยคำที่ค่อนข้างไม่เหมาะสม scramble และไม่เหมาะสมอย่างยิ่ง scumbag:

ข้อบกพร่องบางอย่างที่คุณทำ แต่ข้อบกพร่องบางอย่างที่คุณได้รับ

ในช่วงหลายปีที่ผ่านมา โครงการ Samba ไม่เพียงแต่นำเสนอและแก้ไขจุดบกพร่องเฉพาะของตนเองเหมือนที่โครงการซอฟต์แวร์ที่ซับซ้อนทั่วไปทำ แต่ยังสืบทอดจุดบกพร่องและจุดบกพร่องในโปรโตคอลพื้นฐาน เนื่องจากเป้าหมายของโครงการคือการทำงานร่วมกับเครือข่าย Windows ได้อย่างราบรื่น

(น่าเสียดายที่เรียกว่า ความเข้ากันได้ของข้อบกพร่อง มักเป็นส่วนที่หลีกเลี่ยงไม่ได้ในการสร้างระบบใหม่ที่ทำงานร่วมกับระบบที่มีอยู่เดิม)

ปลายปี 2022 หนึ่งใน “ช่องโหว่ที่สืบทอดมา” ถูกพบและรายงานไปยัง Microsoft โดยระบุตัวระบุ CVE-2022-38023และแพตช์ในการอัปเดต Patch Tuesday ประจำเดือนพฤศจิกายน 2022

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

โดยเฉพาะอย่างยิ่ง การจัดการข้อมูลในเวลาเข้าสู่ระบบ อาชญากรไซเบอร์ที่มีไหวพริบสามารถดึงการโจมตีแบบ Elevation-of-privilege (EoP) ได้

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

ความคล่องตัวในการเข้ารหัส

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

---

---

โดยรวม เราต้องการทั้งทักษะและความตั้งใจที่จะละทิ้งอัลกอริธึมแบบเก่าไปตลอดกาล ทันทีที่พบว่ามีข้อบกพร่อง และอย่าปล่อยไว้เฉยๆ จนกลายเป็นปัญหาของคนอื่น (ว่า "คนอื่น" อาจกลายเป็นเราในอีกสิบปีข้างหน้า)

น่าแปลกใจที่ช่องโหว่ CVE-2022-38023 มีอยู่ตั้งแต่แรก เนื่องจากทั้ง Windows และ Samba ยังคงรองรับรูปแบบการป้องกันความสมบูรณ์ตามอัลกอริทึมการแฮช MD5 ที่เลิกใช้งานมานาน

พูดง่ายๆ คือ การรับรองความถูกต้องของเครือข่ายโดยใช้โปรโตคอล Kerberos เวอร์ชันของ Microsoft ยังคงอนุญาตให้ข้อมูลได้รับการปกป้องอย่างสมบูรณ์ (หรือ ตรวจสอบผลรวมเพื่อใช้ศัพท์เฉพาะที่ไม่เป็นทางการแต่ไม่ถูกต้องอย่างเคร่งครัด) โดยใช้การเข้ารหัสที่มีข้อบกพร่อง

คุณไม่ควรใช้ MD5 อีกต่อไปเพราะถือว่าใช้งานไม่ได้: ผู้โจมตีที่ตั้งใจจริงสามารถหาอินพุตที่แตกต่างกันสองรายการที่ลงท้ายด้วยแฮช MD5 เดียวกันได้อย่างง่ายดาย

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

ในศัพท์แสง อินพุตสองตัวที่มีแฮชเดียวกันเรียกว่า a การปะทะกันและไม่ควรมีลูกเล่นทางโปรแกรมหรือทางลัดใดๆ เพื่อช่วยให้คุณค้นหาได้อย่างรวดเร็ว

ไม่มีทางที่จะพบการชนที่ดีกว่าโชคดีง่ายๆ – พยายามซ้ำแล้วซ้ำอีกกับไฟล์อินพุตที่เปลี่ยนแปลงตลอดเวลาจนกว่าคุณจะเจอแจ็คพอต

ค่าใช้จ่ายที่แท้จริงของการชนกัน

สมมติว่าเป็นอัลกอริทึมที่เชื่อถือได้ โดยไม่มีจุดอ่อนที่ใช้ประโยชน์ได้ คุณคาดว่าแฮชที่มีเอาต์พุต X บิตจะต้องใช้ประมาณ 2^X-1 พยายามค้นหาอินพุตที่สองที่ชนกับแฮชของไฟล์ที่มีอยู่

แม้ว่าสิ่งที่คุณต้องทำคือค้นหาสองอินพุตใดๆ (สองอินพุตโดยพลการ โดยไม่คำนึงถึงเนื้อหา ขนาด หรือโครงสร้าง) ที่เพิ่งมีแฮชเดียวกัน คุณคาดว่าจะต้องใช้มากกว่า 2 เล็กน้อย^{X / 2} พยายามก่อนที่คุณจะชนกัน

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

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

ถ้ามี 2^X เอาต์พุตแฮชที่เป็นไปได้ที่แตกต่างกัน คุณหวังว่าจะมีโอกาส 50:50 ในการค้นหาอินพุตที่มีแฮชเฉพาะเจาะจงที่กำหนดไว้ล่วงหน้าหลังจากลองมาแล้วประมาณครึ่งหนึ่ง และ 2^X/ 2 = 2^X-1. การค้นหาไฟล์สองไฟล์ที่ชนกันนั้นง่ายกว่า เพราะทุกครั้งที่คุณลองอินพุตใหม่ คุณจะชนะหากแฮชใหม่ชนกับ ใด ของอินพุตก่อนหน้านี้ที่คุณได้ลองแล้ว เนื่องจากอนุญาตให้ใช้อินพุตคู่ใดก็ได้ สำหรับการชนกันของ "ไฟล์สองไฟล์ในบัคเก็ตยักษ์นี้จะทำ" คุณมีโอกาสสำเร็จ 50:50 ที่มากกว่ารากที่สองของจำนวนแฮชที่เป็นไปได้เพียงเล็กน้อย และ √2^X = 2^{X / 2}. ดังนั้น สำหรับแฮช 128 บิต เช่น MD5 โดยเฉลี่ยแล้ว คุณคาดว่าจะแฮชประมาณ 2¹²⁷ บล็อกเพื่อให้ตรงกับค่าเอาต์พุตเฉพาะ และ 2⁶⁴ บล็อกเพื่อค้นหาคู่ของอินพุตที่ชนกัน

การชนกันของ MD5 อย่างรวดเร็วทำให้เป็นเรื่องง่าย

เมื่อเป็นเช่นนั้น คุณจะไม่สามารถสร้างอินพุตเทียมเทียมที่แตกต่างกันโดยสิ้นเชิงสองรายการที่ไม่เกี่ยวข้องกันซึ่งมีแฮช MD5 เหมือนกันได้อย่างง่ายดาย

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

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

ตัวอย่างเช่น นี่คือโปรแกรม Lua ที่เราเขียนขึ้นซึ่งสามารถตัดออกเป็นสามส่วนที่แตกต่างกันได้อย่างสะดวก แต่ละส่วนยาว 128 ไบต์

มีคำนำหน้ารหัสที่ลงท้ายด้วยบรรทัดข้อความที่เริ่มต้นความคิดเห็นของ Lua (สตริงที่เริ่มต้น --[== ในบรรทัดที่ 8) จากนั้นจะมีข้อความความคิดเห็น 128 ไบต์ที่สามารถแทนที่ด้วยสิ่งที่เราต้องการได้ เนื่องจากข้อความนั้นจะถูกละเว้นเมื่อไฟล์ทำงาน (บรรทัดที่ 9 ถึง 11) และมีรหัสต่อท้าย 128 ไบต์ที่ปิดความคิดเห็น ( สตริงเริ่มต้น --]== ในบรรทัดที่ 12) และจบโปรแกรม

แม้ว่าคุณจะไม่ใช่โปรแกรมเมอร์ คุณอาจเห็นว่าโค้ดที่ใช้งานอ่านอยู่ในเนื้อหา [บรรทัดที่ 14] ของไฟล์ซอร์สโค้ดเอง (ใน Lua ค่า arg[0] ในบรรทัดที่ 5 คือชื่อของไฟล์สคริปต์ที่คุณกำลังเรียกใช้อยู่) จากนั้นพิมพ์ออกมาเป็น hex dump [line 15] ตามด้วย MD5 hash [line 17]:

การเรียกใช้ไฟล์เป็นการอธิบายตัวเองเป็นหลัก และทำให้บล็อกขนาด 128 ไบต์สามบล็อกชัดเจน:

ใช้ MD5 เครื่องมือวิจัย ที่เรียกว่า md5_fastcollสร้างสรรค์โดยนักคณิตศาสตร์ มาร์ค สตีเวนส์ ในฐานะส่วนหนึ่งของปริญญาโทด้านวิทยาการเข้ารหัสลับในปี 2007 เราได้ผลิตชิ้นส่วน “MD128 Collaboration-Building” ขนาด 5 ไบต์อย่างรวดเร็ว ซึ่งเราใช้แทนที่ข้อความแสดงความคิดเห็นที่แสดงในไฟล์ด้านบน

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

แต่มีความแตกต่างกันอย่างเห็นได้ชัดในหลายๆ ไบต์ ดังนั้นควรมีค่าแฮชที่แตกต่างกันโดยสิ้นเชิง ดังโค้ดต่อไปนี้ diff (ศัพท์แสงสำหรับ ทิ้งความแตกต่างที่ตรวจพบ) เผย

เราได้แปลงชิ้นส่วนที่สร้างการชนกันขนาด 128 ไบต์ซึ่งไม่สมเหตุสมผลว่าเป็นข้อความที่พิมพ์ได้ให้เป็นเลขฐานสิบหกเพื่อความชัดเจน:

อย่างไรก็ตาม การเรียกใช้ทั้งคู่แสดงให้เห็นอย่างชัดเจนว่าเป็นการชนกันของแฮช เนื่องจากพวกมันมีเอาต์พุต MD5 เหมือนกัน:

สำรวจความซับซ้อนของการชนกัน

MD5 เป็นแฮช 128 บิต เนื่องจากสตริงเอาต์พุตด้านบนทำให้ชัดเจน

ดังที่ได้กล่าวไว้ก่อนหน้านี้ เราคาดว่าจะต้องใช้ประมาณ 2^128/2หรือ 2⁶⁴ พยายามโดยเฉลี่ยเพื่อสร้างการชนกันของ MD5 ไม่ว่าประเภทใดก็ตาม

นั่นหมายถึงการประมวลผลขั้นต่ำประมาณ 18 quintillion MD5 hash block เนื่องจาก 2⁶⁴ = 18,446,744,073,709,551,616

ที่อัตราแฮช MD5 สูงสุดโดยประมาณที่ประมาณ 50,000,000 บล็อก/วินาทีบนแล็ปท็อปของเรา นั่นหมายความว่าเราต้องรอนานกว่า 10,000 ปี และแม้ว่าผู้โจมตีที่มีเงินทุนดีอาจดำเนินการได้เร็วกว่านั้น 10,000 ถึง 100,000 เท่า แม้ว่าพวกเขาจะ ต้องรอหลายสัปดาห์หรือหลายเดือนเพื่อให้การชนกันแบบสุ่ม (และไม่จำเป็นต้องมีประโยชน์) ปรากฏขึ้น

แต่ไฟล์ Lua แบบสองหน้าคู่ด้านบนซึ่งมีแฮช MD5 เหมือนกันทุกประการ แม้ว่าจะไม่เหมือนกันอย่างชัดเจนก็ตาม เราใช้เวลาเพียงไม่กี่วินาทีในการเตรียมตัว

การสร้างการชนกันที่แตกต่างกัน 10 ครั้งสำหรับไฟล์ 10 ไฟล์ โดยใช้คำนำหน้าเริ่มต้นที่แตกต่างกัน 10 รายการที่เราเลือกเอง ใช้เวลา: 14.9 วินาที, 4.7 วินาที, 2.6 วินาที, 2.1 วินาที, 10.5 วินาที, 2.4 วินาที, 2.0 วินาที, 0.14 วินาที, 8.4 วินาที, และ 0.43 วินาที

เห็นได้ชัดว่าสัญญาการเข้ารหัสของ MD5 จะให้สิ่งที่เรียกว่า ความต้านทานการชน ถูกทำลายโดยพื้นฐาน…

…เห็นได้ชัดว่ามีปัจจัยอย่างน้อย 25 หมื่นล้าน จากการหารเวลาเฉลี่ยที่เราคาดว่าจะรอเพื่อหาการชนกัน (หลายพันปีตามที่ประมาณไว้ข้างต้น) ด้วยเวลาที่แย่ที่สุดที่เราวัดได้จริง (14.9 วินาที) ขณะปั่นออก การชนที่แตกต่างกันสิบแบบสำหรับบทความนี้เท่านั้น

อธิบายข้อบกพร่องในการตรวจสอบสิทธิ์

แล้วการใช้ MD5 ที่ไม่ปลอดภัยใน CVE-2022-38023 ล่ะ?

ในรหัสหลอกแบบ Lua รหัสตรวจสอบข้อความที่มีข้อบกพร่องซึ่งใช้ระหว่างการเข้าสู่ระบบคือ คำนวณแบบนี้:

เพื่ออธิบาย: รหัสการรับรองความถูกต้องที่ใช้จะคำนวณโดย hmac.md5() การเรียกใช้ฟังก์ชันในบรรทัดที่ 15 โดยใช้สิ่งที่เรียกว่า a แฮชคีย์ในกรณีนี้คือ HMAC-MD5

ชื่อ HMAC ย่อมาจาก โครงสร้างการเข้ารหัสสำหรับการสร้างรหัสการตรวจสอบข้อความที่ใช้แฮชและส่วนต่อท้าย -MD5 หมายถึงอัลกอริทึมการแฮชที่ใช้ภายใน

HMAC ใช้คีย์ลับ ร่วมกับการเรียกใช้แฮชพื้นฐาน XNUMX รายการ แทนที่จะใช้เพียง XNUMX รายการ เพื่อสร้างรหัสยืนยันข้อความ:

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

สิ่งนี้ช่วยลดการควบคุมที่แคร็กเกอร์เข้ารหัสมีอย่างมาก เมื่อพวกเขาพยายามกระตุ้นการชนกันหรือพฤติกรรมที่ไม่สุ่มในกระบวนการแฮช เหนือสถานะภายในของฟังก์ชันแฮชเมื่อถึงไบต์แรกของข้อมูลอินพุต

โดยเฉพาะอย่างยิ่ง คีย์ลับจะป้องกันไม่ให้ผู้โจมตีเริ่มต้นด้วยคำนำหน้าข้อความที่ตนเลือก ดังที่เราทำใน twohash.lua ตัวอย่างด้านบน

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

วิธีนี้จะป้องกันผู้โจมตีจากการจัดการส่วนสุดท้ายของการคำนวณ HMAC เช่นกัน โดยเฉพาะการป้องกันไม่ให้เพิ่มส่วนต่อท้ายที่ตนเลือกไว้ในขั้นตอนสุดท้ายของกระบวนการแฮช

อันที่จริง แม้ว่าคุณไม่ควรใช้ MD5 เลย แต่เราไม่ทราบถึงการโจมตีใดๆ ในปัจจุบันที่สามารถทำลายอัลกอริทึมได้ เมื่อใช้ในรูปแบบ HMAC-MD5 ด้วยคีย์ที่สุ่มเลือก

รูอยู่ตรงกลาง

ดังนั้นช่องโหว่ที่เจาะจงได้ในรหัสปลอมด้านบนจึงไม่อยู่ในบรรทัดใดบรรทัดหนึ่งที่ hmac.md5() มีการใช้ฟังก์ชัน

หัวใจของบั๊กคือบรรทัดที่ 11 ซึ่งข้อมูลที่คุณต้องการตรวจสอบสิทธิ์จะถูกบีบอัดเป็นสตริงที่มีความยาวคงที่...

.. โดยการผลักดันผ่านการเรียกเพียงครั้งเดียวของ MD5 เก่าธรรมดา

กล่าวอีกนัยหนึ่ง ไม่ว่าคุณจะเลือกฟังก์ชัน HMAC ใดในบรรทัดที่ 15 และไม่ว่าขั้นตอนสุดท้ายจะแข็งแรงและทนทานต่อการชนกันเพียงใด คุณก็มีโอกาสที่จะทำให้เกิดการชนกันของแฮชที่บรรทัดที่ 11

พูดง่ายๆ ก็คือ หากคุณทราบข้อมูลที่ควรจะเข้าสู่ chksum() ฟังก์ชันที่จะตรวจสอบความถูกต้อง และคุณสามารถใช้ตัวสร้างการชนกันเพื่อค้นหาบล็อกข้อมูลอื่นที่มีแฮช MD5 เดียวกัน...

…บรรทัดที่ 11 หมายความว่าคุณจะจบลง ด้วยค่าอินพุตที่เท่ากันทุกประการ (ตัวแปร signdat ในรหัสเทียม) ถูกผลักเข้าสู่ขั้นตอนสุดท้าย HMAC ที่ปลอดภัยเหมือนคุณ

ดังนั้น แม้ว่าคุณอาจใช้ฟังก์ชันแยกย่อยข้อความคีย์ที่รัดกุมในตอนท้าย แต่คุณก็อาจกำลังตรวจสอบแฮช MD5 ที่ได้มาจากข้อมูลแอบอ้าง

น้อยจะได้รับมากขึ้น

ในฐานะของแซมบ้า บูเลทีนการรักษาความปลอดภัย อธิบายปัญหาอย่างกระชับ:

จุดอ่อน […] คือการคำนวณเช็คซัมที่ปลอดภัยเป็น HMAC-MD5(MD5(DATA),KEY)ซึ่งหมายความว่าผู้โจมตีที่ใช้งานอยู่ซึ่งทราบข้อมูลข้อความล้วนสามารถสร้างสิ่งที่แตกต่างออกไปได้ DATAด้วย MD5 checksum เดียวกัน และแทนที่ลงในสตรีมข้อมูลโดยไม่ถูกตรวจพบ

กระแทกแดกดันออกจาก MD5(DATA) ส่วนหนึ่งของสูตร HMAC ด้านบน ซึ่งดูเหมือนว่าจะเพิ่มกระบวนการ "ผสม" โดยรวม จะเพิ่มความต้านทานการชน

หากไม่มีการบีบอัด MD5 ตรงกลาง คุณจะต้องพบการชนกันใน HMAC-MD5 เอง ซึ่งอาจเป็นไปไม่ได้ในปี 2023 แม้จะมีเงินทุนจากรัฐบาลที่ไม่จำกัดก็ตาม อย่างน้อยที่สุดก็ไม่อยู่ในช่วงอายุของเซสชันเครือข่ายที่คุณพยายาม เพื่อประนีประนอม

อะไรใช้เวลานานมาก?

ถึงตอนนี้ คุณคงสงสัยว่าทำไมบั๊กนี้ถึงยังไม่ถูกค้นพบหรืออย่างน้อยก็ยังไม่ได้แพตช์เป็นเวลานานนัก

หลังจากทั้งหมด RFC 6151ซึ่งย้อนหลังไปถึงปี 2011 และมีชื่อที่มีนัยสำคัญ อัปเดตข้อควรพิจารณาด้านความปลอดภัยสำหรับ MD5 Message-Digest และอัลกอริทึม HMAC-MD5ให้คำแนะนำดังต่อไปนี้ (การเน้นของเรามากกว่าหนึ่งทศวรรษต่อมา):

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

อย่างไรก็ตาม ดูเหมือนว่าเนื่องจากแพลตฟอร์มเซิร์ฟเวอร์ SMB ล่าสุดส่วนใหญ่ได้ปิดการตรวจสอบสิทธิ์ HMAC-MD5 เมื่อผู้ใช้พยายามเข้าสู่ระบบ ไคลเอ็นต์ SMB ที่ยังคงรองรับโหมดที่ไม่ปลอดภัยนี้โดยทั่วไปจะไม่เคยใช้ (และจะล้มเหลวอยู่แล้วหากพวกเขาต้องการ พยายาม).

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

ดังนั้นปัญหาที่อาจเกิดขึ้นจึงไม่ได้รับความสนใจเท่าที่ควร

น่าเสียดายที่ “การรักษาความปลอดภัยตามสมมติฐาน” ประเภทนี้ล้มเหลวโดยสิ้นเชิง หากคุณบังเอิญเจอ (หรือถูกล่อลวง) เซิร์ฟเวอร์ที่ยอมรับความไม่ปลอดภัยนี้ chksum() อัลกอริทึมระหว่างการเข้าสู่ระบบ

“ปัญหาดาวน์เกรด” ประเภทนี้ไม่ใช่เรื่องใหม่ ย้อนกลับไปในปี 2015 นักวิจัยได้คิดค้น FREAK และ LogJAM การโจมตีซึ่งจงใจหลอกให้ไคลเอนต์เครือข่ายใช้รหัสที่เรียกว่า EXPORT ซึ่งเป็นโหมดการเข้ารหัสที่จงใจทำให้อ่อนแอลงซึ่งรัฐบาลสหรัฐฯ ยืนยันอย่างแปลกประหลาดโดยกฎหมายเมื่อศตวรรษก่อน

ดังที่เราเขียนในตอนนั้น:

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

นั่นเป็นเพราะรหัสส่งออกถูกสหรัฐฯละทิ้งในราวปี 2000

เป็นความคิดที่งี่เง่าตั้งแต่เริ่มต้น: บริษัทในสหรัฐฯ เพิ่งนำเข้าซอฟต์แวร์เข้ารหัสที่ไม่มีข้อจำกัดในการส่งออก และทำร้ายอุตสาหกรรมซอฟต์แวร์ของตนเอง

แน่นอนว่าเมื่อผู้ร่างกฎหมายหลีกทางให้ EXPORT ciphersuites ก็กลายเป็นสิ่งที่ไม่จำเป็น ดังนั้นทุกคนจึงเลิกใช้มัน

น่าเศร้าที่ชุดเครื่องมือการเข้ารหัสจำนวนมาก รวมถึง OpenSSL และ SChannel ของ Microsoft เก็บโค้ดไว้เพื่อรองรับ ดังนั้นคุณ (หรือที่น่ากังวลกว่านั้น คือ มิจฉาชีพที่มีข้อมูลดี) จึงไม่ถูกหยุดใช้งาน

ครั้งนี้ ตัวการหลักในบรรดาเซิร์ฟเวอร์ที่ยังคงใช้กระบวนการ MD5-plus-HMAC-MD5 ที่เสียหายนี้ดูเหมือนจะเป็นช่วงของ NetApp ซึ่ง สินค้าบางอย่าง เห็นได้ชัดว่ายังคงใช้อัลกอริทึมที่มีความเสี่ยงนี้ (หรือทำจนกระทั่งเมื่อไม่นานมานี้)

ดังนั้น บางครั้งคุณยังอาจเข้าสู่กระบวนการเข้าสู่ระบบเครือข่ายที่มีช่องโหว่ และมีความเสี่ยงจาก CVE-2022-38023 โดยอาจไม่รู้ตัวด้วยซ้ำ

จะทำอย่างไร?

บั๊กนี้ได้รับในที่สุด จัดการกับอย่างน้อยก็ตามค่าเริ่มต้นใน Samba รุ่นล่าสุด

ใส่เพียงแค่ เวอร์ชันแซมบ้า 4.17.5 ตอนนี้บังคับให้ทั้งสองตัวเลือก reject md5 clients = yes และ reject md5 servers = yes.

ซึ่งหมายความว่าส่วนประกอบการเข้ารหัสใดๆ ในโปรโตคอลเครือข่าย SMB ต่างๆ ที่เกี่ยวข้องกับอัลกอริทึม MD5 (แม้ว่าจะมีความปลอดภัยในทางทฤษฎี เช่น HMAC-MD5) ห้ามโดยปริยาย.

หากต้องการจริงๆ คุณสามารถเปิดใช้งานอีกครั้งเพื่อเข้าถึงเซิร์ฟเวอร์เฉพาะในเครือข่ายของคุณ

ตรวจสอบให้แน่ใจว่าหากคุณสร้างข้อยกเว้นที่มาตรฐานอินเทอร์เน็ตได้แนะนำอย่างเป็นทางการแล้วให้ต่อต้านมานานกว่าทศวรรษ...

…ที่คุณกำหนดวันที่ที่คุณจะเลิกใช้ตัวเลือกที่ไม่ใช่ค่าเริ่มต้นในที่สุด!

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

ตัดมันออกจากโค้ดของคุณไปเลย เพราะหากไม่มีเลย คุณจะใช้มันไม่ได้ และคุณจะไม่ถูกหลอกให้ใช้โดยคนที่พยายามหลอกล่อให้คุณรู้สึกไม่ปลอดภัย

---

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• เพลโตบล็อคเชน Web3 Metaverse ข่าวกรอง ขยายความรู้. เข้าถึงได้ที่นี่.
• ที่มา: https://nakedsecurity.sophos.com/2023/01/30/serious-security-the-samba-logon-bug-caused-by-outdated-crypto/