Microsoft ได้ออกประกาศเตือนความปลอดภัยในระบบปฏิบัติการ Windows หลังพบผู้บุกรุกใช้ 2 ช่องโหว่ zero-day ใหม่สามารถเรียกใช้การโจมตีระยะไกล (RCE) ในไลบรารี Adobe Manager

รายละเอียดช่องโหว่โดยย่อ
2 ช่องโหว่ zero-day ใหม่นี้อยู่ใน Adobe Type Manager Library (atmfd.

อัปเดตล่าสุด: 16 March 2020, Afternoon
การเปลี่ยนแปลง: เพิ่มรายละเอียดกับการวิเคราะห์แบบ Post-mortem analysis

สืบเนื่องจากการเปิดเผยรายละเอียดของช่องโหว่โดย Cisco Talos เมื่อวันอังคารที่ผ่านมา ในวันที่ 10 มีนาคม 2020 Microsoft ได้เผยแพร่ ADV200005 คำแนะนำสำหรับช่องโหว่ RCE (Remote Code Execution) ใน Microsoft Server Message Block 3.1.1 (SMBv3) ซึ่งให้รายละเอียดและข้อมูลที่มากขึ้นเกี่ยวกับช่องโหว่ (CVE-2020-0796) ที่มีลักษณะ “Wormable” ในโปรโตคอล SMB โดยผู้โจมตีสามารถใช้ช่องโหว่เพื่อโจมตีจากระยะไกลและสามารถเเพร่กระจายเช่นเดียวกับกรณีของ CVE-2017-0143/0144 ที่ WannaCry Ransomware ใช้

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

รายละเอียดช่องโหว่โดยย่อ
การโจมตีช่องโหว่
ระบบที่ได้รับผลกระทบ
การตรวจจับและป้องกันการโจมตี
การวิเคราะห์ระบบที่คาดว่าถูกโจมตีโดยช่องโหว่
อ้างอิง

รายละเอียดช่องโหว่โดยย่อ
CVE-2020-0796 หรือที่ถูกเรียกในอีกชื่อหนึ่งว่า Corona Blue และ SMB Ghost ช่องโหว่เป็นการโจมตีจากระยะไกลใช้ประโยชน์จากข้อผิดพลาดโดยการส่งแพ็คเก็ตที่ออกแบบมาเป็นพิเศษไปยังเซิร์ฟเวอร์ SMBv3 ที่เป็นเป้าหมายซึ่งเหยื่อจะต้องเชื่อมต่อด้วย โดยจากข้อมูลเบื้องต้นนั้น ช่องโหว่นี้เกิดจากปัญหา Buffer overflow ในส่วนที่มีการบีบอัดข้อมูล นอกจากนี้ช่องโหว่จะทำให้การโจมตีแบบ “Wormable” หรือมัลแวร์ชนิดต่างๆ สามารถแผ่กระจายไปบนคอมพิวเตอร์ไคลเอนต์ของเหยื่อได้ง่ายและยากต่อการป้องกัน

อ้างอิงจาก CERT/CC ช่องโหว่นี้ถูกประเมินด้วยคะแนน CVSSv2 แบบ Base score 10 คะแนนเต็ม โดยมีคะแนน Temporal score ซึ่งเกี่ยวข้องกับความเป็นไปได้ในการโจมตีและการลดผลกระทบ 8.1 คะแนน เช่นเดียวกับ Environmental score

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

ฟังก์ชันที่มีค่า Similarity ต่ำหรือทุก Change ไปเยอะมากในไฟล์ srv2.sys คือฟังก์ชัน SmbDecompressData
ในฟังก์ชันดังกล่าว จุดที่เปลี่ยนไปมากที่สุดคือการเพิ่มกระบวนการตรวจสอบก่อนการเรียกใช้ฟังก์ชัน SrvNetAllocateBuffer ซึ่งจะถูกเรียกขึ้นมาไว้ในการจองพื้นที่หน่วยความจำเพื่อรองรับการ decompress ข้อมูล
ในรูปทางด้านซ้ายซึ่งเป็นซอร์สโค้ดของไฟล์ srv2.sys ที่ยังไม่ถูกแพตช์ ฟังก์ชัน SrvNetAllocateBuffer จะทำการนำค่า OriginalCompressedSegmentSize และ OffsetOrLength มาใช้เพื่อประเมินหน่วยของความจำที่จะจอง
เนื่องจากสองค่านี้เป็นค่าที่ผู้ใช้งานสามารถควบคุมได้ ผู้ใช้งานสามารถควบคุมทั้งสองค่าให้เกิด Integer overflow เมื่อมีการหาส่วนต่าง และทำให้ SrvNetAllocateBuffer ต้องจอง buffer ขนาดใหญ่เกินจริงจนกลายเป็น BSOD "PAGE_FAULT_IN_NON_PAGED_AREA" ได้
ช่องโหว่ Integer overflow สามารถนำไปใช้ในการพัฒนาต่อเป็น Remote code execution ได้ ทั้งนี้ผู้โจมตีจะต้องทำการพัฒนาโค้ดเพื่อ bypass ฟีเจอร์ Exploit mitigation อีกมากมายในทำให้ได้มาซึ่ง RCE ด้วย

บริษัทรักษาความปลอดภัยทางไซเบอร์ Kryptos Logic ได้กล่าวว่ามีโฮสต์ประมาณ 48,000 รายทั่วอินเทอร์เน็ตที่มี Port เปิดการเชื่อมต่อผ่านอินเทอร์เน็ตผ่านโปรโตคอล SMB และมีความเสี่ยงต่อการถูกโจมตีโดยใช้จุดบกพร่องนี้ และได้ทำการเเชร์คลิปการการทดสอบโจมตีนี้ด้วย
การโจมตีช่องโหว่
ในขณะนี้ยังไม่พบการใช้ช่องโหว่นี้การโจมตี หรือการปรากฎของโค้ดสำหรับโจมตีและโค้ด POC ใดๆ ทั้งนี้เราตรวจพบสคริปต์สำหรับการใช้ระบุหาช่องโหว่แล้ว โดยในเบื้องต้นนั้นสคริปต์เหล่านี้ดำเนินการตรวจสอบเพียงแค่รุ่นของเซิร์ฟเวอร์ตามรายละเอียดในเบื้องต้นของช่องโหว่เท่านั้น
ระบบที่ได้รับผลกระทบ
รุ่นของระบบที่ได้รับผลกระทบจากช่องโหว่มีตามรายการดังต่อไปนี้

Windows 10 Version 1903 for 32-bit Systems
Windows 10 Version 1903 for ARM64-based Systems
Windows 10 Version 1903 for x64-based Systems
Windows 10 Version 1909 for 32-bit Systems
Windows 10 Version 1909 for ARM64-based Systems
Windows 10 Version 1909 for x64-based Systems
Windows Server, version 1903 (Server Core installation)
Windows Server, version 1909 (Server Core installation)

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

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

อัปเดตวันที่ 13 มีนาคม 2563: ไมโครซอฟต์ได้ดำเนินการปล่อยแพตช์รหัส KB 4551762 เพื่อปิดช่องโหว่นี้แล้ว โดยแพตช์จะเพิ่มกระบวนการตรวจสอบค่าในส่วนของโปรแกรมที่มีช่องโหว่ นี่คือวิธีที่ดีที่สุดในการป้องกันการถูกโจมตีโดยช่องโหว่นี้และเราแนะนำเป็นอย่างยิ่งให้ดำเนินการแพตช์โดยทันที (ดาวโหลดแพตช์ได้จากที่นี่)
ในมุมของการ Hardening มีการปล่อยไฟล์ ADMX ซึ่งจะเพิ่มตัวเลือกใน Group Policy ให้สามารถปิดฟีเจอร์ SMB Compression ได้ (ดูเพิ่มเติม)
คำแนะนำของ Microsoft คือให้ทำการติดตั้งการปรับปรุงช่องโหว่นี้ทันทีที่ออก Patch ป้องกัน เบื้องต้นเราสามารถปิดใช้งานกระบวนการบีบอัดซึ่งคาดว่าจะเกี่ยวข้องกับช่องโหว่เพื่อ Block ผู้โจมตีที่ไม่ได้รับอนุญาตจากการโจมตีช่องโหว่จากเซิร์ฟเวอร์ SMBv3 ด้วยคำสั่ง PowerShell ด้านล่าง

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force

เนื่องจาก SMB เป็นโปรโตคอลที่ส่วนใหญ่จะใช้กันในองค์กร ทาง Microsoft จึงแนะนำให้ Block Traffic ขาเข้าและขาออกสำหรับเครือข่ายภายนอกบน Port TCP 445 บน Firewall ในองค์กรเพื่อป้องกันเครือข่ายและจะช่วยปกป้องระบบที่อยู่หลัง Firewall จากความพยายามโจมตีช่องโหว่นี้ เป็นวิธีการป้องกันที่ดีที่สุดเพื่อช่วยหลีกเลี่ยงการโจมตีทางอินเทอร์เน็ต อย่างไรก็ตามระบบยังอาจเสี่ยงต่อการถูกโจมตีจากภายในองค์กรอยู่ (ดูเพิ่มเติมวิธีการ Block Port TCP 445 ออกจากเครื่องเซิร์ฟเวอร์องค์กร)

การวิเคราะห์ระบบที่คาดว่าถูกโจมตีโดยช่องโหว่
หลังจากที่ไมโครซอฟต์ได้มีการปล่อยแพตช์สำหรับช่องโหว่นี้ออกมา พร้อมกับรายงานการวิเคราะห์ช่องโหว่จากผู้เชี่ยวชาญด้านความปลอดภัย ในวันที่ 14 มีนาคม 2020 นักวิจัยด้านความปลอดภัย eerykitty ได้มีการเปิดเผยโค้ดสำหรับโจมตีช่องโหว่ดังกล่าวซึ่งส่งผลให้ระบบเกิดการ Crash และเหตุการณ์ Blue Screen of Death (BSOD) ในมุมมองของทีมตอบสนองการโจมตีและภัยคุกคาม แม้ว่าผลกระทบจากช่องโหว่ในเวลานี้จะทำให้ระบบสูญเสียได้เพียงความพร้อมในการใช้งาน (Availability) แต่การสูญเสียเพียงความพร้อมในการใช้งานหรือให้บริการก็ส่งผลให้คุณลักษณะที่ทำให้เกิดความมั่นคงปลอดภัยของระบบนั้นไม่สมบูรณ์ได้

ในประเด็นนี้ทีมตอบสนองการโจมตีและภัยคุกคามจะมาสรุปสิ่งที่เราค้นพบในรูปแบบของ Post-mortem analysis ซึ่งสามารถใช้ในการประเมินความปลอดภัยระบบในลักษณะของ Compromised assessment และการช่วยระบุหาต้นตอความผิดปกติหากสงสัยว่าระบบอาจถูกโจมตีด้วยช่องโหว่ CVE-2020-0796 ได้

เราทำการจำลองระบบที่ใช้ในการทดสอบโดยทำการติดตั้งระบบ Windows 10 Enterprise รุ่น 1903 ที่ยังไม่ถูกแพตช์ โดยระบบไม่มีการตั้งค่าหรือติดตั้งโปรแกรมใดๆ เพิ่มเติม การระบุหาตัวบ่งชี้ภัยคุกคาม (Indicator of compromise) จะดำเนินการบนข้อมูลที่ระบบสร้างหรือบันทึกเป็นค่าเริ่มต้นเท่านั้น เพื่อให้ข้อมูลที่สามารถใช้ยืนยันการโจมตีได้ครอบคลุมกับระบบที่มีอยู่ทั่วไปในโลกมากที่สุด

โครงการ eerykitty/CVE-2020-0796-PoC มีการนำแก้ไขการทำงานของไลบรารี smbprotocol เพื่อให้รองรับการทำงานกับฟีเจอร์ compression ใน SMB รุ่น 3.1.1 โดยเพื่อทำการ overflow พื้นที่ในหน่วยความจำ ผู้พัฒนาได้มีการกำหนดค่า OffsetOrLength ในเฮดเดอร์ให้มีค่าเป็น 0xffffffff ไว้ในโค้ดของ smbprotocol อยู่แล้ว

เมื่อระบบที่มีช่องโหว่รับแพ็คเกตจากสคริปต์ที่ใช้โจมตี ระบบจะเกิดการ Crash และจะแสดงอาการ Blue screen of death ด้วย Stop code คือ PAGE_FAULT_IN_NON_PAGED_AREA โดย Stop code มักเกิดจากปัญหาการอ้างอิงข้อมูลในหน่วยความจำที่ไม่ถูกต้องจนทำให้ระบบไม่สามารถทำงานได้

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

ตรวจสอบ Event log ของระบบโดยให้ระบุหา EID41 Kernel-Power ใน System log ซึ่งระบุการรีสตาร์ทของระบบแบบผิดปกติและ EID1001 BugCheck ใน System log ที่ช่วงเวลาใกล้เคียงซึ่งจะระบุว่าระบบเกิดปัญหาจาก "บั๊ก" ของโปรแกรมบางอย่างจนต้องมีการรีสตาร์ท ในกรณีทั่วไประบบจะมีการบันทึกข้อมูลในหน่วยความจำไว้ในลักษณะ Memory dump ซึ่งสามารถใช้ในการระบุหาที่มาของข้อผิดพลาดได้อีกด้วย
ทำการตรวจสอบไฟล์ MEMORY.DMP ด้วย Dumpchk หรือ Windbg โดยในกรณีที่ระบบถูกโจมตีด้วย CVE-2020-0796 นั้น ลักษณะของ Call stack จะปรากฎตามรูปด้านบนซึ่งมีสาเหตุมาจากการพยายามใช้พื้นที่ของหน่วยความจำที่ถูกจองขึ้นมาผิดพลาด

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

ระบุหาข้อมูลเครือข่ายที่เกี่ยวข้องกับพอร์ต 445 และมีเป้าหมายมายังระบบที่เกิดความผิดปกติในช่วงเวลาใกล้เคียงกัน เราพบว่าหลังจากที่มีการสั่งโจมตี ระบบจะใช้เวลา 1-2 วินาทีก่อนจะมีการ Crash เกิดขึ้น
ยืนยันว่าระบบที่เกิดความผิดปกตินั้นขาดซึ่งการติดตั้งแพตช์และมีการเปิดใช้งานฟีเจอร์ที่เกี่ยวข้องกับการเกิดขึ้นของช่องโหว่จริง

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

https://securityaffairs.

Cisco ออกแพตช์ให้ช่องโหว่ร้ายแรงใน Firepower Management Center
มีช่องโหว่ร้ายแรงในหน้า web interface ของ Firepower Management Center (CVE-2019-16028) ถ้าเปิดให้ authentication ผ่าน external LDAP server ผู้โจมตีจะสามารถสร้าง HTTP request อันตรายเพื่อเข้าถึงหน้า web interface ด้วยสิทธิ์ผู้ดูแลระบบได้
สามารถตรวจสอบได้ว่ามีความเสี่ยงต่อช่องโหว่นี้หรือไม่ได้จากเมนู System > Users > External Authentication แล้วตรวจสอบว่ามีการเปิดใช้ LDAP หรือไม่
Cisco แนะนำว่าควรปิดการใช้งานการ authentication ด้วย LDAP จนกว่าจะทำการอัปเดตแพตช์

ที่มา : Cisco

Microsoft Office ออกอัปเดตแก้ไขช่องโหว่รันคำสั่งจากระยะไกล
Microsoft Office ออกอัปเดตแพตช์รักษาความปลอดภัย 16 รายการ โดยช่องโหว่ที่สำคัญคือ CVE-2019-1462 ของ PowerPoint รุ่น 2010, 2013 และ 2016 ถ้าผู้โจมตีทำการโจมตีช่องโหว่ดังกล่าวสำเร็จ จะทำให้สามารถรันคำสั่งอันตรายได้ด้วยสิทธิ์ของผู้ที่ใช้งาน PowerPoint ซึ่งในกรณีที่ผู้ใช้งานมีสิทธิ์ administrative ผู้โจมตีก็จะได้สิทธิ์ในการควบคุมเครื่อง
นอกจากนี้ยังมีการแก้ไขช่องโหว่ในโปรแกรมตระกูล Microsoft Office อีกหลายรายการ ผู้ใช้งานและผู้ดูแลระบบสามารถดูรายละเอียดแพตช์รักษาความปลอดภัยทั้งหมดได้ที่ Support Microsoft

ที่มา : Microsoft Office December Security Updates Fix Remote Execution Bugs

เมื่อวันที่ 17 มิถุนายน 2019 ที่ผ่านมา ทีม Security Engineer จาก Netflix ได้มีการเปิดเผย 4 ช่องโหว่ใหญ่ในส่วนของโปรแกรมซึ่งอิมพลีเมนต์โปรโตคอล TCP ในระบบ FreeBSD และลินุกซ์ ซึ่งส่งผลให้ด้วยการส่งแพ็คเกตที่มีลักษณะเฉพาะบางประการ แฮกเกอร์สามารถล่มระบบใดก็ได้ได้จากระยะไกล

ทีม Intelligent Response จาก บริษัทไอ-ซีเคียว จำกัด จะมาติดตามรายละเอียดของช่องโหว่นี้ พร้อมทั้งอธิบายที่มา การตรวจจับและการป้องกันการโจมตีช่องโหว่นี้ในโพสต์นี้กันครับ

รายละเอียดช่องโหว่โดยย่อ
ที่มาของช่องโหว่
การโจมตีช่องโหว่
ระบบที่ได้รับผลกระทบ
การตรวจจับการโจมตี
การป้องกันการโจมตี

รายละเอียดของช่องโหว่โดยย่อ
ช่องโหว่ในตระกูล SACK Panic นี้มีทั้งหมด 4 ช่องโหว่ ได้แก่

ช่องโหว่ SACK Panic รหัส CVE-2019-11477 คะแนน CVSSv3 7.5
ช่องโหว่ SACK Slowness รหัส CVE-2019-11478 คะแนน CVSSv3 5.3
ช่องโหว่ SACK Slowness รหัส CVE-2019-5599 ยังไม่มีการระบุคะแนน CVSS
ช่องโหว่ไม่มีชื่อเฉพาะ รหัส CVE-2019-11479 คะแนน CVSSv3 5.3

ที่มาของช่องโหว่
อ้างอิงจาก Security Advisories ของ Netflix ช่องโหว่ทั้ง 4 ช่องโหว่นี้เป็นช่องโหว่ที่เกิดขึ้นในส่วนของโค้ดซึ่งอยู่ในแกนกลางของระบบปฏิบัติการ FreeBSD และเคอร์เนลของระบบปฏิบัติการลินุกซ์ซึ่งทำหน้าที่เกี่ยวข้องกับโปรโตคอล TCP โดยช่องโหว่เหล่านี้นั้นเกี่ยวข้องกับการกำหนดค่า minimum segment size (MSS) และค่า TCP Selective Acknowledgement (SACK) ซึ่งทั้งสองค่าเป็นการตั้งค่าของโปรโตคอล TCP

สำหรับช่องโหว่แรกคือ SACK PANIC (CVE-2019-11477) นั้นเป็นช่องโหว่ซึ่งเกิดขึ้นเมื่อผู้โจมตีมีการสร้างลำดับของแพ็คเกต TCP ซึ่งมีลำดับของค่า SACK เฉพาะ โดยเมื่อส่งไปยังเป้าหมายซึ่งมีช่องโหว่แล้ว จะทำให้เกิดการเงื่อนไข integer overflow ซึ่งนำไปสู่เงื่อนไขการทำงานที่ผิดพลาดของเคอร์เนล (Kernel panic) และทำให้เกิดเงื่อนไข DoS ได้

ในส่วนของช่องโหว่ที่สองคือ SACK Slowness (CVE-2019-11478) นั้นเป็นช่องโหว่ที่ทำให้เกิดการใช้งานทรัพยากรของระบบมากขึ้นโดยเป็นผลมาจากการได้รับลำดับของแพ็คเกต TCP ที่มีค่า SACK เฉพาะซึ่งจะทำให้เกิดการแบ่งส่วนในกระบวนการจัดลำดับเพื่อจัดส่งแพ็คเกตใหม่ในโปรโตคอล TCP ในลักษณะที่ไม่ถูกต้องได้

ช่องโหว่ที่สามหรือช่องโหว่ SACK Slowness (CVE-2019-5599) เป็นช่องโหว่ที่เกิดขึ้นในลักษณะที่คล้ายกับ SACK Slowness (CVE-2019-11478) จากความเหมือนกันในประเด็นเรื่องของผลกระทบและรูปแบบการโจมตี แต่แตกต่างในส่วนของคอมโพเนนต์และระบบปฏิบัติการที่ได้รับผลกระทบ

ช่องโหว่สุดท้ายในลำดับ 4 คือช่องโหว่รหัส CVE-2019-11479 เป็นช่องโหว่ที่ทำให้เกิดการใช้งานทรัพยากรของระบบที่มากขึ้นหรือมากเกินซึ่งเป็นผลมาจากการกำหนดค่า MSS ต่ำ โดยผู้โจมตีนั้นสามารถบังคับให้ลินุกซ์เคอร์เนลทำการแบ่งส่วนแพ็คเกตที่จะทำการตอบกลับออกเป็นหลาย TCP segment ที่มีขนาด 8 ไบต์ ซึ่งส่งผลให้ระบบจำเป็นต้องใช้แบนด์วิธและทรัพยากรอื่นๆ ที่มากขึ้นในการส่ง เงื่อนไขเดียวในการโจมตีข่องโหว่นี้คือการที่ผู้โจมตีจะต้องทำการโจมตีอยู่ตลอดเวลา เนื่องจากความเสียหายที่เกิดจากการโจมตีนั้นจะหยุดหากการโจมตีหยุดลงทันที
การโจมตีช่องโหว่
ยังไม่มีการปรากฎของโค้ดหรือ PoC ที่ใช้สำหรับโจมตีช่องโหว่ในขณะนี้
ระบบที่ได้รับผลกระทบ

ช่องโหว่ SACK Panic (CVE-2019-11477) ส่งผลกระทบกับลินุกซ์เคอร์เนลตั้งแต่เวอร์ชัน 2.6.29 เป็นต้นไป
ช่องโหว่ SACK Slowness (CVE-2019-11478) ส่งผลกระทบกับลินุกซ์เคอร์เนลรุ่น 4.15 หรือต่ำกว่า
ช่องโหว่ SACK Slowness (CVE-2019-5599) ส่งผลกระทบกับ FreeBSD รุ่น 12 ที่ใช้ RACK TCP Stack
ช่องโหว่ CVE-2019-11479 ส่งผลกระทบกับลินุกซ์ทุกเวอร์ชัน

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

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

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

สำหรับช่องโหว่ SACK Panic (CVE-2019-11477) ให้ทำการอัปเดตแพตช์ PATCH_net_1_4.patch ในกรณีที่ลินุกซ์เคอร์เนลเป็นเวอร์ชัน 4.14 หรือใหม่กว่า ให้ทำการอัปเดตแพตช์ PATCH_net_1a.patch ไปพร้อมกันด้วย
สำหรับช่องโหว่ SACK Slowness (CVE-2019-11478) ให้ทำการอัปเดตแพช์ PATCH_net_2_4.patch กับเคอร์เนล
สำหรับช่องโหว่ SACK Slowness (CVE-2019-5599) ให้ทำการอัปเดตแพตช์ split_limit.

จากเมื่อวันที่ 21 เมษายน 2019 ทีม KnownSec 404 จาก ZoomEye ประกาศการค้นพบช่องโหว่ระดับวิกฤติใน Oracle WebLogic Server ได้รับ CVE-2019-2725 ช่องโหว่ดังกล่าวกระทบ Oracle WebLogic Server รุ่น 10.x และรุ่น 12.1.3.0 เป็นช่องโหว่ที่สามารถรันคำสั่งจากระยะไกลได้ (remote code-execution) โดยที่ผู้โจมตีไม่จำเป็นต้องทำการเข้าสู่ระบบดังกล่าว ด้วยความร้ายแรงของช่องโหว่นี้ทำให้ Oracle ได้ออกแพตช์เฉพาะกิจมาเพื่อแก้ไขช่องโหว่ดังกล่าวในวันที่ 26 เมษายน 2019

โดยหลังจากที่ออกแพตช์ไม่นาน (2 พฤษภาคม 2019) นักวิจัยจากบริษัทรักษาความปลอดภัยทางไซเบอร์หลายบริษัทพบการโจมตี Oracle WebLogic Server รวมถึงมีการเผยแพร่ POC สำหรับค้นหาและโจมตีช่องโหว่ CVE-2019-2725 จำนวนมาก รวมถึงมีข่าวการโจมตีผ่านช่องโหว่ CVE-2019-2725 ด้วยมัลแวร์หลายครั้ง

หลังจากที่ได้ทำการศึกษาและทดสอบช่องโหว่ สำหรับในบล็อกนี้ทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) จากบริษัท ไอ-ซีเคียว จำกัด จะมาเล่าการทดสอบช่องโหว่ดังกล่าวให้ฟังกันโดยแบ่งเนื้อหาออกเป็นหัวข้อดังต่อไปนี้

รายละเอียดเกี่ยวกับช่องโหว่ CVE-2019-2725
สมมติฐานในการทดสอบช่องโหว่ CVE-2019-2725
วิธี setup เพื่อทดสอบช่องโหว่ CVE-2019-2725 
ปัญหาในการทดสอบช่องโหว่ CVE-2019-2725 
การทดสอบช่องโหว่ CVE-2019-2725  และ
สรุปการทดสอบช่องโหว่ CVE-2019-2725

คำเตือน: การทดสอบนี้เป็นไปเพื่อการศึกษาเท่านั้น 
รายละเอียดเกี่ยวกับช่องโหว่ CVE-2019-2725
ช่องโหว่ CVE-2019-2725 ถูกพูดถึงครั้งแรกใน CHINA NATIONAL VULNERABILITY DATABASE ใช้ชื่อว่า CNTA-2019-0014 เมื่อวันที่ 17 เมษายน 2019 ส่งผลกระทบกับ Oracle WebLogic Server  10.X และ Oracle WebLogic Server  12.1.3

KnownSec 404 Team ซึ่งเป็นหนึ่งในผู้แจ้งช่องโหว่ดังกล่าวไปยัง Oracle ได้เขียนสรุปรายละเอียดเกี่ยวกับช่องโหว่ว่าเกิดจากส่วนประกอบ wls9_async และ wls-wsat ซึ่งทำให้เกิดช่องโหว่ Deserialization Remote Command Execution ผู้โจมตีสามารถรันคำสั่งจากระยะไกลไปยังระบบที่มีช่องโหว่ได้ โดยที่ผู้โจมตีไม่จำเป็นต้องทำการเข้าสู่ระบบดังกล่าวและคำสั่งดังกล่าวจะรันด้วยสิทธิ์เดียวกันกับสิทธิ์ของ Oracle WebLogic Server

ด้วยความร้ายแรงของช่องโหว่นี้ทำให้ Oracle ได้ออกแพตช์เฉพาะกิจมาเพื่อแก้ไขช่องโหว่ดังกล่าวในวันที่ 26 เมษายน 2019 โดยอัปเดตเป็น Oracle WebLogic Server รุ่น 12.2.1

หลังจากที่มีการประกาศการแก้ไขช่องโหว่ได้ไม่นานได้มีผู้เผยแพร่ POC ออกมาเป็นจำนวนมาก รวมถึงมีการเขียน Exploits สำหรับ Metasploit ออกมาอีกด้วย รวมถึงมีข่าวการโจมตีผ่านช่องโหว่ CVE-2019-2725 ด้วยมัลแวร์หลายครั้ง เช่น โจมตีด้วย Sodinokibi ransomware

ไม่ใช่ทุก POC และ Exploits ที่เผยแพร่จะใช้ได้เสมอไป
อ้างอิงจากที่ทีม KnownSec 404 ได้เล่ารายละเอียดเพิ่มเติมเกี่ยวกับการค้นพบช่องโหว่ดังกล่าวใน WebLogic RCE (CVE-2019-2725) Debug Diary ว่า CVE-2019-2725 ที่เกิดจากความสำเร็จในการ bypass ตัว blacklist ที่ Oracle ใช้ป้องกัน CVE 2017-10271

ทำให้สามารถสรุปได้ว่า WebLogic 10.X จะมีทั้งช่องโหว่ CVE 2017-10271 และ CVE-2019-2725 แต่ WebLogic 12.1.3 จะมีช่องโหว่แค่ช่องโหว่ CVE-2019-2725 เท่านั้น

ซึ่งบาง POC และบาง Exploits ที่ถูกเผยแพร่ออกมาจะใช้ได้กับ CVE 2017-10271 ซึ่งใช้กับ WebLogic 12.1.3 ไม่ได้

ดังนั้นเมื่ออยากจะทำการทดสอบ CVE-2019-2725 จึงควรใช้ WebLogic 12.1.3 เพื่อให้มั่นใจว่า POC ที่นำมาทดสอบสามารถใช้ได้จริง

โดยการโจมตี CVE-2019-2725 จะเกิดจากการส่ง http request ที่ทำเป็นพิเศษไปยังส่วนที่มีช่องโหว่คือ wls9_async และ wls-wsat ซึ่ง https://sissden.

สรุปย่อ
เมื่อช่วงกลางเดือนกุมภาพันธ์ที่ผ่านมา Canonical บริษัทผู้พัฒนา Ubuntu ได้ปล่อยแพตช์เพื่อแก้ไขช่องโหว่ที่ได้รับชื่อเรียกว่า Dirty Sock ค้นพบโดย Chris Moberly นักวิจัยจาก Shenanigans Labs ช่องโหว่ไม่ได้เป็นปัญหาของระบบปฏิบัติการ Linux โดยตรง แต่เป็นปัญหาในส่วนของ service ที่มีชื่อว่า Snapd ซึ่งถูกติดตั้งเป็น service พื้นฐานบนระบบปฎิบัติการ Linux หลายตัว เช่น Ubuntu, Debian, Arch Linux, OpenSUSE. Solus และ Fedora ถูกใช้เพื่อจัดการเกี่ยวกับการดาวโหลดและติดตั้งไฟล์ที่เป็น snaps (.snap) แพ็กเกจ ส่งผลให้ผู้ไม่หวังดีสามารถสร้างบัญชีที่มีสิทธิ์ระดับ root (Privilege Escalation) บนเครื่องได้ ผ่านช่องโหว่ใน API ของ Snapd

(ที่มา: https://www.

ข้อบกพร่องของ VMware Workstation ที่ได้รับการเปิดเผยในการแข่งขัน WCF Cup PWN

VMware ได้เปิดตัวการปรับปรุงด้านความปลอดภัยเพื่อแก้ไขช่องโหว่ (CVE-2018-6983) ที่เพิ่งค้นพบโดย Tianwen Tang ของทีม Vulcan ของ Qihoo 360 ในการแข่งขัน WCF Cup PWN
แฮ็กเกอร์ได้รับรายได้มากกว่า 1 ล้านเหรียญสำหรับการโจมตีที่ไม่มีวันถูกเปิดเผยในงานประกวดการแฮ็กที่เกิดขึ้นระหว่างวันที่ 16-17 พฤศจิกายนที่เมืองเฉิงตู
Tianwen Tang ได้รับ 100,000 เหรียญเพื่อใช้ประโยชน์จากข้อบกพร่องนี้ได้อย่างสมบูรณ์ได้แก้ไขช่องโหว่ของ Workstation และ Fusion อย่างรวดเร็ว
VMware ขอขอบคุณ Tianwen Tang จากทีม Qihoo 360Vulcan Team ที่เข้าร่วมการแข่งขัน Tianfu Cup 2018 International Pwn Contest เพื่อรายงานปัญหานี้แก่เรา
ช่องโหว่นี้เป็นข้อผิดพลาดจำนวนมากซึ่งส่งผลกระทบต่ออุปกรณ์เครือข่ายเสมือนจริง อาจใช้ประโยชน์จากการรันโค้ดบนโฮสต์เวิร์คสเตชันจากผู้เยี่ยมชม
ข้อบกพร่องมีผลต่อ Workstation 14.x และ 15.x บนแพลตฟอร์มใดก็ได้และ Fusion 10.x และ 11.x บน macOS

ที่มา : securityaffairs

สรุปย่อ
นักวิจัยจาก Radboud University ประเทศเนเธอร์แลนด์ค้นพบช่องโหว่ในฟีเจอร์ Self-Encrypting Drives ที่มีใน Solid State Disk (SSD) หลายยี่ห้อ โดยฟีเจอร์ Self-Encrypting เป็นฟีเจอร์สำคัญในกระบวนการเข้ารหัสอุปกรณ์ฮาร์ดดิสก์ซึ่งจะดำเนินการโดยตัวอุปกรณ์เอง ช่องโหว่ดังกล่าวทำให้ผู้โจมตีสามารถข้ามผ่านกระบวนการเข้ารหัสและเข้าถึงข้อมูลที่ถูกเข้ารหัสในอุปกรณ์ดังกล่าวได้โดยไม่ต้องทราบข้อมูลที่ใช้ในการพิสูจน์ตัวตน เช่น รหัสผ่านซึ่งถูกใช้เป็นกุญแจในการเข้ารหัส ที่ผู้ใช้งานตั้งเพื่อเข้ารหัสข้อมูลดังกล่าว

นอกจากนี้ ช่องโหว่ยังกระทบกับโปรแกรมเข้ารหัส BitLocker ของ Microsoft Window ที่เป็นการเข้ารหัสข้อมูลในอุปกรณ์จัดเก็บข้อมูลโดยซอฟต์แวร์ด้วยเนื่องจาก BitLocker จะเลือกใช้การเข้ารหัสในระดับ hardware หาก SSD นั้นรองรับ

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

รายละเอียด
กระบวนการเข้ารหัสแบบ full-disk encryption
ในกรณีที่ผู้ใช้งานต้องการป้องกันการเข้าถึงข้อมูลสำคัญใน harddisk หรือ Solid State Disk (SSD) ในกรณีที่สูญหายหรือถูกขโมย ผู้ใช้สามารถใช้กระบวนการ Full disk encryption ซึ่งเป็นการเข้ารหัสข้อมูลใน harddisk ทั้งลูกได้ โดยสามารถทำได้ทั้งจาก hardware และ software

โดยการทำ full-disk encryption จาก hardware สามารถทำได้หาก hardware ดังกล่าวมีความสามารถในการทำ Self-encrypting drive มาจากผู้ผลิต ในขณะเดียวกันการทำ full-disk encryption จาก software ก็สามารถทำได้จากโปรแกรมต่างๆ เช่น BitLocker, VeraCrypt, SafeGuard และ PrivateDisk เป็นต้น

อย่างไรก็ตามการเข้ารหัสโดยซอฟต์แวร์นั้นมักจะถูกมองว่ามีข้อเสียมากกว่าการใช้ฟีเจอร์การเข้ารหัสจากอุปรกร์ เพราะกุญแจเข้ารหัสมักจะปรากฏอยู่ใน RAM และทำให้ประสิทธิภาพของระบบลดลงระหว่างการเข้ารหัส
ช่องโหว่ใน Self-Encrypting Drives ที่มีใน Solid State Disk (SSD)
Carlo Meijer และ Bernard van Gastel ได้ทำการวิจัยบน SSD จากผู้ผลิตต่างๆ โดยวิเคราะห์ตามประเด็นความปลอดภัยที่อาจพบได้บนกระบวนการเข้ารหัสผ่านโดยใช้ฟีเจอร์ของอุปกรณ์ดังนี้

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

โดยจากสมมติฐานของการวิเคราะห์นั้น Carlo และ Bernard ค้นพบข้อเท็จจริงจากสมมติฐานซึ่งนำไปสู่ความเสี่ยงและผลกระทบต่อกระบวนการเข้ารหัสโดยฮาร์ดแวร์ดังต่อไปนี้

ในอุปกรณ์บางยี่ห้อ กระบวนการสร้างกุญแจเข้ารหัสนั้นไม่ได้มีการนำหรัสผ่านที่ผู้ใช้งานระบุมาใช้ในการสร้างกุญแจเข้ารหัสด้วย โดยอาศัยเพียงแค่ค่าเฉพาะซึ่งถูกฝังมาในตัวอุปกรณ์เพียงปัจจัยเดียวเท่านั้นในการเข้ารหัส ซึ่งเป็นกระบวนการสร้างกุญแจสำหรับเข้ารหัสที่ไม่ปลอดภัย
มีการใช้กุญแจเข้ารหัสเดียวกันทั้ง disk
ในการเข้ารหัส disk นั้นอาจจะต้องมีบางส่วนที่ไม่เข้ารหัส เช่น ในการเข้ารหัสด้วยโปรแกรม BitLocker จะเหลือส่วน partition table ไว้เพื่อให้ใช้งานได้ ซึ่งเมื่อใช้กุญแจเข้ารหัสเดียวกันทั้ง disk หากมีผู้เข้าถึงส่วนที่ไม่ถูกเข้ารหัสก็จะสามารถค้นหากุญแจเข้ารหัสได้
SSD จะมีการใช้เทคนิค Wear Leveling ซึ่งเป็นวิธีการกระจายการเขียนข้อมูลออกไปให้ทั่วๆ เพื่อไม่ให้มีการเขียนข้อมูลซ้ำที่ส่วนหนึ่งส่วนใดบ่อยครั้งเกินไป ข้อดีของเทคนิคนี้คือทำให้อุปกรณ์มีอายุการใช้งานที่นานขึ้น แต่ข้อเสียคือเมื่อผู้ใช้เข้ารหัส ซึ่งต้องมีการเขียนทับข้อมูลเดิมด้วยข้อมูลที่เข้ารหัสแล้ว ด้วยเทคนิค Wear Leveling นี้อาจทำให้ข้อมูลไม่ถูกเขียนทับจริง ข้อมูลเก่าจะถือว่าไม่ถูกใช้งานแต่ยังสามารถเข้าถึงได้ ทำให้สามารถค้นหาข้อมูลที่ยังไม่ถูกเข้ารหัสได้ (กระจายแต่ไม่ลงที่เดิมเพราะสุ่มกระจาย)
DevSleep (DEVSLP) เป็นฟังก์ชั่นที่เกี่ยวข้องกับการประหยัดพลังงานที่เพิ่มเข้ามาใหม่สำหรับ SATA drive โดยเป็นระบบจัดการพลังงานที่ช่วยลดการใช้พลังงานและยืดเวลาการใช้งานแบตเตอรี่ ช่วยรักษาความสมบูรณ์ของข้อมูลและทำให้ drive สามารถกู้ระบบในกรณีที่มีการปิดการทำงานแบบไม่ปลอดภัย แต่ในขณะเดียวกันอาจถูกผู้โจมตีใช้เพื่อกู้ข้อมูลกุญแจเข้ารหัสได้

Carlo Meijer และ Bernard van Gastel ได้ผลลัพธ์งานวิจัยเป็นการพบช่องโหว่ที่ทำให้สามารถกู้คืนข้อมูลจาก drive ได้โดยไม่ต้องรู้ password โดยช่องโหว่ดังกล่าวคือช่องโหว่ CVE-2018-12037 และ CVE-2018-12038
CVE-2018-12037
ช่องโหว่ CVE-2018-12037 เป็นช่องโหว่จากข้อผิดพลาดในการทำ encryption วิธีที่ถูกต้องคือต้องมีการเชื่อม password จากผู้ใช้งานเข้ากับกุญแจเข้ารหัสภายใน hardware แต่เกิดข้อผิดพลาดโดยไม่มีการเชื่อมกันดังกล่าว ทำให้การเข้ารหัส drive ขึ้นอยู่กับกุญแจเข้ารหัสภายใน hardware เพียงอย่างเดียว หากมีผู้โจมตีเข้าถึง hardware ก็จะสามารถค้นหากุญแจเข้ารหัสภายใน hardware และใช้ถอดรหัสได้

อุปกรณ์ที่ได้รับผลกระทบจากช่องโหว่นี้คือ

Crucial (Micron) MX100, MX200 และ MX300
Samsung T3 และ T5 portable
Samsung 840 EVO และ 850 EVO

CVE-2018-12038
ช่องโหว่ CVE-2018-12038 เกิดเมื่อทุกครั้งที่ผู้ใช้ใส่ password ใหม่จะมีการเขียนทับ key information ด้วย key information ที่ถูกเข้ารหัสแล้ว แต่เนื่องจากการเขียนทับอาจเขียนในคนละ sector ทำให้มีโอกาสที่ key information ที่ไม่ถูกเข้ารหัสจะยังปรากฏอยู่ได้

อุปกรณ์ที่ได้รับผลกระทบจากช่องโหว่นี้คือ Samsung 840 EVO
ผลกระทบของช่องโหว่ต่อโปรแกรมเข้ารหัสอย่าง BitLocker
โปรแกรม BitLocker จาก Microsoft Window ที่เป็นการเข้ารหัสจาก Software ด้วย เพราะ BitLocker จะเลือกใช้การเข้ารหัสในระดับ hardware หาก SSD นั้นรองรับเป็นค่าตั้งต้น
คำแนะนำ
นักวิจัยได้ให้คำแนะนำเพื่อลดผลกระทบจากช่องโหว่เหล่านี้โดยว่าผู้ใช้ SSD ที่ต้องการเข้ารหัสไม่ควรพึ่งพาความสามารถ Self-Encrypting Drives ที่มีใน SSD เพียงอย่างเดียว ควรเลือกใช้โปรแกรมเข้ารหัสเพื่อเข้ารหัสจาก software ร่วมด้วย เช่น ใช้โปรแกรม VeraCrypt โดยสามารถอ่านคำแนะนำอย่างละเอียดได้จากที่นี่และที่นี่

Microsoft Window ได้ออกคำแนะนำในการในการปิดค่าตั้งต้นของ BitLocker ใช้การเข้ารหัสจาก Software เท่านั้น โดยสามารถศึกษาได้จากที่นี่
แหล่งอ้างอิง

https://www.

Facebook ไม่มีพบหลักฐานของผู้บุกรุกที่สามารถเข้าถึงแอพฯ อื่นๆ (third-party) ได้

จากกรณีเมื่อสุดสัปดาห์ที่ผ่านมา Facebook เปิดเผยว่าพบว่ามี access token มากกว่า 50 ล้านบัญชีรั่วไหล หลายคนกลัวว่า Token ที่ถูกขโมยไปจะถูกนำไปใช้ในการเข้าถึงบริการอื่น ๆ (third-party) ซึ่งรวมถึง Instagram และ Tinder ผ่านทาง Facebook login แต่ข่าวดีล่าสุดจาก Guy Rosen ซึ่งเป็น Facebook Security VP ระบุว่าไม่พบหลักฐานใดๆ ที่สามารถพิสูจน์ว่าบริการอื่นๆ จาก third-party ที่ใช้งานผ่านทาง Facebook login ได้รับผลกระทบจากเหตุการณ์ในครั้งนี้

แต่นั่นไม่ได้หมายความว่า Token ที่ถูกเพิกถอนจาก Facebook จะไม่ก่อให้เกิดภัยคุกคามต่อบริการอื่น ๆ (third-party) ปัจจัยดังกล่าวนั้นขึ้นอยู่กับเว็บไซต์ดังกล่าวว่าได้มีการใช้งาน Facebook official SDKs เพื่อทำการตรวจสอบผู้ใช้งานของตนหรือไม่ โดย SDKs ที่ปรับปรุงนี้ จะช่วยผู้พัฒนา (developer) สามารถตรวจสอบได้เองว่าผู้ใช้งานคนไหนที่ได้รับผลกระทบจากเหตุการณ์ในครั้งนี้ แม้ว่า Facebook จะประกาศว่าไม่พบการเข้าถึงบริการของแอพฯอื่นๆ จากเหตุการณ์ในครั้งนี้ แต่บริการบางอย่าง เช่น Uber ก็ยังคงทำตามขั้นตอนที่จำเป็นเพื่อปกป้องผู้ใช้ของตน โดยการสั่งให้ session ทั้งหมดหลังเหตุการณ์นี้ที่ยังค้างอยู่ในระบบให้หมดอายุการใช้งานทันที และตรวจสอบเหตุการณ์ครั้งนี้ด้วยตนเอง

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

ที่มา : zdnet , thehackernews