Patch Madness: คำแนะนำเกี่ยวกับข้อผิดพลาดของผู้ขายเสียแล้ว พังมาก

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

นั่นเป็นข้อโต้แย้งที่ Brian Gorenc และ Dustin Childs ซึ่งทั้งคู่มี Zero Day Initiative (ZDI) ของ Trend Micro ซึ่งสร้างจากเวทีของ Black Hat USA ในระหว่างเซสชันของพวกเขา “การคำนวณความเสี่ยงในยุคแห่งความคลุมเครือ: การอ่านระหว่างบรรทัดของคำแนะนำด้านความปลอดภัย".

ZDI ได้เปิดเผยช่องโหว่มากกว่า 10,000 รายการให้กับผู้ขายทั่วทั้งอุตสาหกรรมตั้งแต่ปี 2005 ในช่วงเวลานั้น Childs ผู้จัดการฝ่ายสื่อสารของ ZDI กล่าวว่าเขาสังเกตเห็นแนวโน้มที่น่าเป็นห่วง ซึ่งก็คือคุณภาพของแพตช์ที่ลดลงและการสื่อสารที่เกี่ยวกับการอัปเดตความปลอดภัยลดลง

“ปัญหาที่แท้จริงเกิดขึ้นเมื่อผู้จำหน่ายปล่อยแพตช์ที่ผิดพลาด หรือข้อมูลที่ไม่ถูกต้องและไม่สมบูรณ์เกี่ยวกับแพตช์เหล่านั้น ซึ่งอาจทำให้องค์กรคำนวณความเสี่ยงผิดพลาด” เขากล่าว “แพตช์ที่ผิดพลาดสามารถเป็นประโยชน์ในการใช้ประโยชน์จากนักเขียน เนื่องจาก 'n-days' นั้นใช้งานง่ายกว่า Zero-days มาก”

ปัญหากับคะแนน CVSS & ลำดับความสำคัญของการแก้ไข

ทีมรักษาความปลอดภัยในโลกไซเบอร์ส่วนใหญ่มีพนักงานไม่เพียงพอและอยู่ภายใต้ความกดดัน และคำขวัญที่ว่า “ทำให้ซอฟต์แวร์ทุกเวอร์ชันเป็นปัจจุบันอยู่เสมอ” ก็ไม่สมเหตุสมผลเสมอไปสำหรับหน่วยงานที่ไม่มีทรัพยากรเพียงพอที่จะครอบคลุมพื้นที่ริมน้ำ นั่นเป็นเหตุผลที่การจัดลำดับความสำคัญของแพตช์ที่จะใช้ตามระดับความรุนแรงใน Common Vulnerability Severity Scale (CVSS) ได้กลายเป็นทางเลือกสำรองสำหรับผู้ดูแลระบบจำนวนมาก

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

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

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

ดังนั้น แม้ว่าจุดบกพร่องอาจมีคะแนนวิกฤตที่ 10 จาก 10 ในระดับ CVSS แต่ผลกระทบที่แท้จริงอาจมีความเกี่ยวข้องน้อยกว่าป้ายกำกับที่สำคัญมาก

“บั๊กการเรียกใช้โค้ดจากระยะไกล (RCE) ที่ไม่ผ่านการตรวจสอบสิทธิ์ในเซิร์ฟเวอร์อีเมลอย่าง Microsoft Exchange จะสร้างความสนใจมากมายจากนักเขียนที่ใช้ประโยชน์จากช่องโหว่” เขากล่าว “บั๊ก RCE ที่ไม่ผ่านการตรวจสอบสิทธิ์ในเซิร์ฟเวอร์อีเมลอย่าง Squirrel Mail ไม่น่าจะสร้างความสนใจได้มากนัก”

เพื่อเติมเต็มช่องว่างตามบริบท ทีมรักษาความปลอดภัยมักจะหันไปหาคำแนะนำของผู้ขาย ซึ่ง Childs ตั้งข้อสังเกตว่ามีปัญหาที่เห็นได้ชัดคือ พวกเขามักจะฝึกความปลอดภัยผ่านความมืดมน

Microsoft Patch Tuesday คำแนะนำขาดรายละเอียด

ในปี 2021 Microsoft ได้ตัดสินใจ เพื่อลบบทสรุปผู้บริหาร
จากคู่มือการอัปเดตความปลอดภัย แทนที่จะแจ้งให้ผู้ใช้ทราบว่าคะแนน CVSS จะเพียงพอสำหรับการจัดลำดับความสำคัญ ซึ่งเป็นการเปลี่ยนแปลงที่ Childs ทำลาย

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

นอกเหนือจาก Microsoft "การลบหรือปิดบังข้อมูลในการอัปเดตที่ใช้เพื่อสร้างแนวทางที่ชัดเจน" ในขณะนี้ยังระบุข้อมูลพื้นฐานของ Patch Tuesday ได้ยากขึ้น เช่น จำนวนข้อบกพร่องที่ได้รับการแก้ไขในแต่ละเดือน

“ตอนนี้คุณต้องนับตัวเอง และมันก็เป็นหนึ่งในสิ่งที่ยากที่สุดที่ฉันทำ” Childs ตั้งข้อสังเกต

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

“ตัวอย่างเช่น กับ 121 CVEs กำลังถูกแก้ไขในเดือนนี้เป็นการยากที่จะเจาะลึกพวกมันทั้งหมดเพื่อค้นหาว่าตัวใดอยู่ภายใต้การโจมตี” Childs กล่าว “แต่ตอนนี้ผู้คนพึ่งพาแหล่งข้อมูลอื่นๆ เช่น บล็อกและบทความข่าว แทนที่จะใช้ข้อมูลที่น่าเชื่อถือจากผู้ขายเพื่อช่วยกำหนดความเสี่ยง”

ควรสังเกตว่า Microsoft ได้เพิ่มขึ้นสองเท่าในการเปลี่ยนแปลง. ในการสนทนากับ Dark Reading ที่ Black Hat USA รองประธานบริษัท Security Response Center ของ Microsoft Aanchal Gupta กล่าวว่าบริษัทได้ตัดสินใจที่จะจำกัดข้อมูล CVE ที่ให้ไว้เพื่อปกป้องผู้ใช้ในขั้นต้น แม้ว่า CVE ของ Microsoft จะให้ข้อมูลเกี่ยวกับความรุนแรงของจุดบกพร่อง และแนวโน้มที่จะถูกโจมตี (และไม่ว่าจะถูกโจมตีอย่างแข็งขันหรือไม่ก็ตาม) บริษัทจะระมัดระวังในการเปิดเผยข้อมูลการใช้ประโยชน์จากช่องโหว่นี้

เป้าหมายคือการให้เวลาฝ่ายบริหารความปลอดภัยเพียงพอที่จะใช้โปรแกรมแก้ไขโดยไม่ทำให้เกิดอันตราย Gupta กล่าว “หากใน CVE ของเรา เราได้ให้รายละเอียดทั้งหมดเกี่ยวกับวิธีการใช้ประโยชน์จากช่องโหว่ เราจะไม่ทำให้ลูกค้าของเราเป็นศูนย์” เธอกล่าว

ผู้ค้ารายอื่นฝึกฝนความสับสน

Microsoft แทบจะไม่ได้ให้รายละเอียดเพียงเล็กน้อยในการเปิดเผยจุดบกพร่อง Childs กล่าวว่าผู้ขายจำนวนมากไม่ให้ CVE เลยเมื่อเผยแพร่การอัปเดต

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

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

"สิ่งนี้อาจทำให้การคำนวณความเสี่ยงของคุณคลาดเคลื่อน" เขากล่าว “ตัวอย่างเช่น ถ้าคุณดูการซื้อผลิตภัณฑ์ และคุณเห็น 10 CVE ที่ได้รับการแก้ไขในระยะเวลาหนึ่ง คุณอาจได้ข้อสรุปหนึ่งของความเสี่ยงจากผลิตภัณฑ์ใหม่นี้ อย่างไรก็ตาม หากคุณรู้ว่า 10 CVE นั้นมาจากรายงานข้อผิดพลาดมากกว่า 100 รายการ คุณอาจได้ข้อสรุปที่ต่างออกไป”

Placebo Patches การจัดลำดับความสำคัญของโรคระบาด

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

“ดังนั้น บั๊กนั้นจึงยังคงอยู่ที่นั่นและสามารถใช้ประโยชน์จากผู้คุกคามได้ ยกเว้นตอนนี้พวกเขาได้รับแจ้งแล้ว” เขากล่าว “มีหลายสาเหตุที่สิ่งนี้อาจเกิดขึ้น แต่มันเกิดขึ้น - ข้อบกพร่องที่ดีมากเราแก้ไขสองครั้ง”

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

Childs ใช้ตัวอย่างของปัญหาจำนวนเต็มล้นใน Adobe Reader ที่นำไปสู่การจัดสรรฮีปที่ไม่ธรรมดา ซึ่งส่งผลให้เกิดบัฟเฟอร์ล้นเมื่อมีการเขียนข้อมูลมากเกินไป

“เราคาดหวังให้ Adobe ทำการแก้ไขโดยตั้งค่าใด ๆ เหนือจุดใดจุดหนึ่งให้ไม่ดี” Childs กล่าว “แต่นั่นไม่ใช่สิ่งที่เราเห็น และภายใน 60 นาทีของการเปิดตัว มีแพตช์บายพาสและพวกเขาต้องแก้ไขอีกครั้ง การฉายซ้ำไม่ได้มีไว้สำหรับรายการทีวีเท่านั้น”

วิธีต่อสู้กับปัญหาการจัดลำดับความสำคัญของแพตช์

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

อย่างไรก็ตาม ปัญหาความรวดเร็วหลังการเปิดเผยข้อมูลเป็นอีกประเด็นสำคัญที่องค์กรต้องให้ความสำคัญ

Gorenc ผู้อำนวยการอาวุโสของ ZDI กล่าวว่าอาชญากรไซเบอร์ไม่ต้องเสียเวลาในการรวม vulns กับพื้นผิวการโจมตีขนาดใหญ่เข้ากับชุดเครื่องมือ ransomware หรือชุดเครื่องมือหาช่องโหว่ โดยมองหาอาวุธจากช่องโหว่ที่เพิ่งถูกเปิดเผยก่อนที่บริษัทต่างๆ จะมีเวลาในการแก้ไข บั๊ก n-day เหล่านี้เรียกว่า catnip สำหรับผู้โจมตี ซึ่งโดยเฉลี่ยแล้วสามารถรีเวิร์สเอ็นจิเนียร์บั๊กได้ในเวลาเพียง 48 ชั่วโมง

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

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

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

“เมื่อมีการเปลี่ยนแปลงเกิดขึ้นกับแนวภัยคุกคาม (การแก้ไขโปรแกรมแก้ไข การพิสูจน์แนวคิดสาธารณะ และการเผยแพร่ช่องโหว่) องค์กรต่างๆ ควรเปลี่ยนทรัพยากรของตนเพื่อตอบสนองความต้องการและต่อสู้กับความเสี่ยงล่าสุด” Gorenc อธิบาย “ไม่ใช่แค่ช่องโหว่ที่เปิดเผยและตั้งชื่อล่าสุดเท่านั้น สังเกตสิ่งที่เกิดขึ้นในแนวภัยคุกคาม กำหนดทรัพยากรของคุณ และตัดสินใจว่าจะต้องดำเนินการเมื่อใด”