Cisco Firepower Management Center Lightweight Directory Access Protocol Authentication Bypass Vulnerability

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 December Security Updates Fix Remote Execution Bugs

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

แจ้งเตือนช่องโหว่ตระกูล SACK Panic ยิง FreeBSD และลินุกซ์ดับดิ้นได้จากระยะไกล

เมื่อวันที่ 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.

เรื่องเล่าจากการทดสอบช่องโหว่ CVE-2019-2725 ใน Oracle WebLogic

จากเมื่อวันที่ 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.

รู้จัก “Dirty Sock” ช่องโหว่ยกระดับสิทธิ์ (Privilege Escalation) บน Linux (CVE-2019-7304)

สรุปย่อ
เมื่อช่วงกลางเดือนกุมภาพันธ์ที่ผ่านมา 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 released security updates to address a vulnerability (CVE-2018-6983) that was recently discovered at the Tianfu Cup PWN competition.

ข้อบกพร่องของ 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

Hardware Encryption อาจไม่ได้ปลอดภัยเสมอไป – สรุปช่องโหว่ด้านความปลอดภัยล่าสุดบน SSD

สรุปย่อ
นักวิจัยจาก 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: No evidence attackers accessed third-party apps

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

ทำความรู้จักช่องโหว่ใหม่ระดับวิกฤติของ Apache Struts 2 (CVE-2018-11776)

สรุปย่อ
ในวันที่ 22 สิงหาคม 2018 ที่ผ่านมา Apache ได้ออกแพตช์เพื่อแก้ไขช่องโหว่ร้ายแรงระดับวิกฤติ (critical) ใน Apache Struts เพื่อแก้ไขช่องโหว่ CVE-2018-11776 ซึ่งเป็นช่องโหว่ remote code execution กระทบ Apache Struts รุ่น 2.3 ถึง 2.3.34 และ 2.5 ถึง 2.5.16 และอาจส่งกระทบกับ Apache Struts รุ่นอื่นๆ ที่เลิกซัพพอร์ตแล้ว

ทั้งนี้ช่องโหว่ remote code execution ถือเป็นช่องโหว่ที่มีความร้ายแรงสูงสุด เนื่องจากมีความเสี่ยงที่ผู้โจมตีจะรันคำสั่งอันตรายจนกระทั่งยึดครองทั้งระบบได้ ผู้ดูแลระบบควรรีบอัปเดตโดยด่วน
เกี่ยวกับ Apache Struts
Apache Struts เป็น open source framework สำหรับทำเว็บแอปพลิเคชันด้วยภาษา Java ที่กำลังได้รับความนิยมอย่างมากในองค์กรทั่วโลก ในปี 2017เกิดการโจมตี Equifax โดยใช้ช่องโหว่ remote code execution บน Apache Struts (CVE-2017-5638) และเนื่องจาก Equifax ไม่ได้อัปเดตแพตช์เพื่อแก้ไขช่องโหว่ดังกล่าวทำให้ข้อมูลลูกค้าหลุดกว่า 147ล้านคน สร้างความสูญเสียมูลค่ากว่า 600 ล้านดอลลาห์สหรัฐ
รายละเอียดของ CVE-2018-11776
นักวิจัยชื่อ Man Yue Mo จาก Semmle เป็นผู้ค้นพบช่องโหว่ CVE-2018-11776 และทำการแจ้งเตือน Apache Struts ตั้งแต่วันที่ 10 เมษายน 2018 ที่ผ่านมา เขาระบุว่าช่องโหว่ CVE-2018-11776 มีโอกาสที่จะทำให้เกิดความเสียหายได้มากกว่าการโจมตี Equifax เพราะสามารถโจมตีได้ง่ายกว่า เนื่องจากช่องโหว่ CVE-2018-11776 นี้อยู่บน core code ของ Apache Struts และไม่ต้องใช้ปลั๊กอินเสริมใดๆ ในการโจมตี ซึ่งช่องโหว่ดังกล่าวได้รับ CVSS v3 Base Score 9.8

ช่องโหว่ CVE-2018-11776 เกิดจากการไม่ตรวจสอบ input จากผู้ใช้ ทำให้ผู้โจมตีสามารถแทนที่ namespace ด้วยคำสั่งอันตรายได้ ซึ่ง Semmle ได้บอกจุดสังเกตที่ทำให้ถูกโจมตีผ่านช่องโหว่ CVE-2018-11776 คือ

Apache Struts ถูกตั้งค่าให้ alwaysSelectFullNamespace มีค่าเป็น True
Configuration file ของ Apache Struts มี <action ...> tag ที่ไม่ได้ระบุ optional namespace หรือมี <action ...> tag ที่ระบุเป็น wildcard namespace

ถึงแม้ว่าในขณะนี้ Apache Struts ที่ไม่ได้ตั้งค่าดังกล่าวจะปลอดภัย แต่เป็นไปได้ที่จะมีการโจมตีแบบอื่นขึ้นได้ในอนาคต จึงควรแก้ด้วยการอัปเดตแพตช์เป็นรุ่นล่าสุดมากกว่าการแก้ไขการตั้งค่า

ทั้งนี้ Recorded Future ได้ตรวจพบการพูดถึงวิธีโจมตีช่องโหว่ดังกล่าวอย่างมากในเว็บบอร์ดใต้ดินของจีนและรัสเซีย รวมถึงมีการเผยแพร่ Proof of Concept (POC) ของช่องโหว่นี้อย่างเปิดเผยทั่วไปแล้ว เช่น Apache Struts2 CVE-2018-11776 POC และ St2-057 Poc Example ผู้ดูแลระบบจึงควรทำการอัปเดต Apache Struts โดยด่วน
ผู้ที่ได้รับผลกระทบ
นอกจากผู้ใช้ Apache Struts ทั่วไปที่ใช้ Apache Struts รุ่น 2.3 ถึง 2.3.34 และ 2.5 ถึง 2.5.16 จะได้รับผลกระทบแล้ว บริษัทต่างๆ ที่มีการใช้ Apache Struts ในผลิตภัณฑ์อย่าง Cisco ยังได้รับผลกระทบอีกด้วย โดย Cisco อยู่ระหว่างการตรวจสอบว่ามีผลิตภัณฑ์ใดบ้างที่ได้รับผลกระทบบ้าง
แนวทางแก้ไข

อัปเดต Apache Struts เป็นเวอร์ชั่น 2.3.35 หรือ 2.5.17
ตั้งค่า namespace อยู่เสมอ

ตรวจจับการโจมตี

เนื่องจากการโจมตีช่องโหว่ CVE-2018-11776 สามารถโจมตีได้ผ่านเน็ตเวิร์ค ทำให้ Web Application Firewall (WAF) ต่างๆ เช่น Imperva ได้ทำการเพิ่มการดักจับการโจมตีดังกล่าวเข้าไปในบริการแล้ว
สามารถตรวจจับได้ด้วย Snort rule

โดย Talos ออกคำแนะนำว่าสามารถตรวจจับได้ด้วย Snort rule SID 29639, 39190, 39191 และ 47634
และมีผู้เผยแพร่ Snort rule เพื่อใช้ในการตรวจจับ ดังนี้

แหล่งอ้างอิง

https://researchcenter.

ทำความรู้จักช่องโหว่ Foreshadow (L1 Terminal Fault – L1TF) อ่านข้อมูลจากแคชซีพียูแม้มีโหมดป้องกันได้โดยตรง

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

ช่องโหว่ Foreshadow นี้ส่งผลโดยตรงกับคุณสมบัติของฟีเจอร์ Intel Software Guard Extensions (Intel SGX) ซึ่งมีหน้าที่สำคัญในการป้องกันการเข้าถึงข้อมูลจากโปรแกรม โค้ด ระบบปฏิบัติการหรือแม้แต่ hypervisor เองหากไม่ได้รับอนุญาตให้เข้าถึง

ในมุมของผู้ใช้งานนั้น ผลลัพธ์ของช่องโหว่ Foreshadow อาจคล้ายหรือใกล้เคียงกับผลลัพธ์ของช่องโหว่ Spectre หรือ Meltdown อย่างไรก็ตาม Foreshadow ระบุเฉพาะเจาะจงไปที่ซีพียูที่มีการใช้งานฟีเจอร์ป้องกัน Intel SGX ที่มักจะถูกเปิดใช้งานบนระบบที่ต้องการความปลอดภัยสูง และบ่งบอกว่าจะมีการป้องกันในระดับฮาร์ดแวร์ก็ยังคงได้รับผลกระทบอยู่เช่นกัน

รายละเอียดช่องโหว่
เมื่อวันที่ 14 สิงหาคม 2018 ที่ผ่านมา บริษัท Intel ร่วมกับนักวิจัยเปิดเผยสามช่องโหว่ใหม่ที่ส่งผลกระทบกับซีพียู (CPU) ยี่ห้อ Intel ซึ่งเป็นช่องโหว่ที่ใช้ประโยชน์จากกระบวนการทำงานหนึ่งของซีพียูที่เรียกว่า speculative execution เช่นเดียวกับช่องโหว่ Meltdown และ Spectre ที่เปิดเผยเมื่อต้นปี 2018 ที่ผ่านมา

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

ช่องโหว่ทั้งสามตัวนี้เป็นการใช้ประโยชน์จากกระบวนการ speculative execution เพื่ออ่านค่าของแคชระดับที่ 1 (L1 Cache) ซึ่งเป็นแคชอยู่ใกล้กับซีพียูที่สุด ช่องโหว่ทั้งสามถูกอ้างอิงด้วยศัพท์เทคนิคว่า L1 Terminal Fault หรือ L1TF 

ซึ่งแบ่งย่อยได้เป็น

L1 Terminal Fault – SGX หรือ CVE-2018-3615 หรือ Foreshadow
L1 Terminal Fault – OS/SMM หรือ CVE-2018-3620 หรือ Foreshadow-NG
L1 Terminal Fault – VMM หรือ CVE-2018-3646 หรือ Foreshadow-NG

ผลกระทบ
ช่องโหว่ L1 Terminal Fault – SGX ได้คะแนน CVSSv3 7.9 สามารถใช้โจมตี Intel Software Guard Extensions (SGX) ได้ โดย SGX เป็นเทคโนโลยีรักษาความปลอดภัยที่ใช้ในซีพียูของ intel ตั้งแต่ปี 2013 เป็นการรักษาความปลอดภัยของข้อมูลเพื่อให้อ่านหรือแก้ไขได้เฉพาะกระบวนการที่น่าเชื่อถือเท่านั้น ทำให้ทนทานต่อการโจมตีหลายรูปแบบ แต่ช่องโหว่ Foreshadow ทำให้ผู้โจมตีสามารถหลีกเลี่ยง SGX และอ่านข้อมูลภายในแคชระดับที่ 1 เช่น รหัสผ่านหรือคีย์เข้ารหัสได้ กระทบผู้ใช้ทั้งหมดที่ใช้ซีพียู Intel ที่มีการเปิดใช้งาน Intel SGX

ช่องโหว่ L1 Terminal Fault – OS/SMM ได้คะแนน CVSSv3 7.1 สามารถอ่านข้อมูลในเคอร์เนลของระบบปฎิบัติการ และข้อมูลใน system management mode (SMM) ผ่านแคชระดับที่ 1ได้ กระทบผู้ใช้ทั้งหมด

ช่องโหว่ L1 Terminal Fault – VMM ได้คะแนน CVSSv3 7.1 ทำให้อ่านข้อมูลบนระบบ hypervisor ได้ จึงอ่านค่าหน่วยความจำของเครื่องเสมือน (VM) อื่นบนซีพียูเดียวกันได้ กระทบผู้ใช้บริการเครื่องเสมือนบนคลาวด์  ระบบดาตาเซ็นเตอร์ และผู้ให้บริการคลาวด์โดยเฉพาะผู้ให้บริการคลาวด์ที่แชร์ซีพียูระหว่างเครื่องเสมือนของผู้ใช้หลายรายการเข้าด้วยกัน

ในขณะนี้ยังไม่มีการตรวจพบการใช้ช่องโหว่ทั้งสามในการโจมตีจริง
คำแนะนำสำหรับผู้ใช้งานทั่วไป
ช่องโหว่  L1 Terminal Fault – SGX และ L1 Terminal Fault – OS/SMM สามารถป้องกันได้โดยอัปเดต microcode ภายในซีพียู และอัปเดตระบบปฏิบัติการ ซึ่ง Microsoft ได้มีการอัปเดตเพื่อป้องกันไปในแพตช์ความปลอดภัยประจำเดือนสิงหาคม 2018 แล้ว
คำแนะนำสำหรับผู้ใช้งานคลาวด์
ผู้ใช้งานคลาวด์ควรอ่านคำแนะนำความปลอดภัยเกี่ยวกับ L1TF ที่ผู้ให้บริการที่ตนเองใช้งาน และปฏิบัติตามคำแนะนำดังกล่าว โดยผู้บริการต่างๆ ได้ให้คำแนะนำไว้ดังนี้

Amazon Web Services
Google Cloud
Microsoft Azure
DigitalOcean
Linode 
Oracle 

 แหล่งอ้างอิง

https://www.