
GlobalProtect ถูกใช้บุกรุกเรียกค่าไถ่ อุดช่องโหว่แล้วต้องเช็กคนที่เข้ามาก่อนด้วย
อัปเดต 27 ต.ค. 2026: รุ่นแก้ไขในตารางยังเหมือนเดิม ประกาศผู้ผลิตไม่ได้ออกฉบับแก้ใหม่ตั้งแต่ 3 มิ.ย. เราเพิ่มเส้นทางเมนูเช็กว่าเปิดคุกกี้ Authentication Override ไว้หรือไม่ ตามประกาศ Palo Alto Networks และรายการร่องรอยที่ Unit 42 ให้ค้นในบันทึก GlobalProtect ดูวิธีเช็กและแก้ทีละขั้นใน คู่มือสังเกตและแก้ภัยไซเบอร์ 5 เรื่องประจำสัปดาห์
7.8 คือคะแนนความรุนแรงที่ประกาศของ Palo Alto Networks ระบุสำหรับ CVE-2026-0257 ช่องโหว่ข้ามการยืนยันตัวตนใน GlobalProtect พร้อมจัดระดับเป็น HIGH และแนะนำความเร่งด่วนสูงสุดในการจัดการครับ (Palo Alto Networks) เรื่องนี้เกี่ยวกับทางเข้าระบบบริษัทที่พนักงานใช้ทำงานจากบ้าน และ Unit 42 พบว่ากลุ่มเรียกค่าไถ่ Qilin กับ Inc ใช้ช่องโหว่นี้เพื่อเข้าถึงเครือข่ายองค์กรแล้ว (Unit 42)
ประเด็นที่อยากให้จำก่อนรายละเอียดคือ มีแพตช์หรือชุดอัปเดตแก้ช่องโหว่มาตั้งแต่เดือนพฤษภาคม แต่การลงแพตช์อย่างเดียวอาจไม่ตัดสิทธิ์ที่ผู้บุกรุกได้ไปก่อนหน้า ตามคำเตือนของ ReliaQuest ที่ Help Net Security รายงานไว้ ดังนั้นคำว่า “อัปเดตแล้ว” ยังต้องมีคำถามต่อว่า ตรวจการเชื่อมต่อเก่าและคนที่เข้ามาแล้วหรือยัง (Help Net Security)
สรุป 30 วินาที: เกิดอะไรขึ้น
GlobalProtect เป็นระบบ VPN ของ Palo Alto Networks คำว่า VPN ในบริบทนี้หมายถึงการเชื่อมต่อจากภายนอกเข้าระบบองค์กร ใช้นึกถึงประตูให้พนักงานทำงานจากบ้านได้ ส่วน PAN-OS คือซอฟต์แวร์ที่ทำงานบนไฟร์วอลล์ หรืออุปกรณ์ควบคุมการเข้าออกของเครือข่าย ช่องโหว่นี้อยู่ในส่วนรับการเชื่อมต่อของ GlobalProtect และอาจทำให้คนที่ไม่ได้รับอนุญาตสร้างการเชื่อมต่อ VPN ได้ (Palo Alto Networks)
ผู้ผลิตเปิดเผยช่องโหว่วันที่ 13 พฤษภาคม 2026 โดยตอนแรกจัดระดับปานกลาง ก่อนแจ้งวันที่ 29 พฤษภาคมว่ารับทราบความพยายามโจมตีในวงจำกัดต่ออุปกรณ์ที่ยังไม่อัปเดตและไม่ได้ใช้มาตรการลดความเสี่ยง (Help Net Security) ส่วน Unit 42 ระบุว่าทีมสอบสวนเหตุบุกรุกที่เกี่ยวข้องมาตั้งแต่ต้นเดือนมิถุนายน (Unit 42)
ข้อมูลอัปเดตของ Unit 42 ระบุ Qilin และ Inc เป็นกลุ่มเรียกค่าไถ่ที่ใช้ช่องโหว่นี้ และรับทราบรายงานสาธารณะที่โยงการโจมตีกับผู้ใช้แรนซัมแวร์ Settra ด้วย แรนซัมแวร์คือมัลแวร์ที่ใช้เรียกค่าไถ่จากเหยื่อ ส่วนการระบุ Settra ในข้อความของ Unit 42 เป็นการอ้างรายงานภายนอก จึงควรแยกจากสิ่งที่ทีมระบุว่าพบเอง (Unit 42)
ทำไมเรื่องนี้เกี่ยวกับคุณ
สำหรับพนักงาน จุดสำคัญคือผู้โจมตีสามารถข้าม MFA หรือการยืนยันตัวตนหลายขั้นตอนเพื่อสร้างการเชื่อมต่อ VPN ได้ในกรณีนี้ การที่บริษัทให้ยืนยันตัวตนเพิ่มอีกขั้นจึงไม่ได้ตอบแทนการแก้ช่องโหว่ที่ตัวระบบรับการเชื่อมต่อ นี่เป็นข้อจำกัดเฉพาะของเส้นทางที่ถูกโจมตี ไม่ควรตีความว่าให้เลิกใช้ MFA ครับ (Unit 42)
สำหรับเจ้าของกิจการที่จ้างคนอื่นดูแลเครือข่าย ข่าวนี้เป็นเหตุให้ขอสถานะจากผู้ให้บริการได้ทันที โดยไม่ต้องรอให้พนักงานแจ้งว่าเปิดไฟล์ไม่ได้ก่อน เพราะ ReliaQuest เตือนว่าการเข้าผ่าน VPN ขององค์กรเองอาจดูคล้ายพนักงานทำงานทางไกลตามปกติ และอาจไม่ถูกพบจนเริ่มมีการขโมยรหัสผ่าน ย้ายไปยังเครื่องอื่น ขโมยข้อมูล หรือใช้แรนซัมแวร์แล้ว (Help Net Security)
คนเป็นผู้ปกครอง นักศึกษา หรือทำงานที่ไม่ได้ดูแลระบบเอง ก็ใช้ข่าวนี้เป็นเหตุผลส่งต่อให้ผู้รับผิดชอบตรวจสอบได้ Unit 42 ระบุว่างานสอบสวนครอบคลุมทั้งการศึกษา การเงิน สุขภาพ ภาครัฐ การผลิต และภาคธุรกิจอื่นอีกหลายกลุ่ม แต่รายชื่ออุตสาหกรรมนี้ไม่ได้ยืนยันว่าหน่วยงานใดในไทยได้รับผลกระทบ (Unit 42)
ทำงานยังไง
คำว่า authentication bypass แปลตรงตัวว่า “ข้ามการตรวจว่าเป็นใคร” ปัญหานี้เกี่ยวข้องกับคุกกี้สำหรับการยืนยันตัวตน คุกกี้ในที่นี้คือข้อมูลที่ระบบใช้ประกอบการยอมรับการเข้าใช้งาน โดยช่องโหว่เกิดจากการพึ่งข้อมูลดังกล่าวโดยตรวจสอบความถูกต้องและความครบถ้วนไม่เพียงพอ จึงเปิดทางให้ผู้โจมตีที่ยังไม่ได้ยืนยันตัวตนสร้างการเชื่อมต่อที่ไม่ได้รับอนุญาตได้ (Help Net Security)
เปรียบแบบใกล้ตัวคือ คีย์การ์ดพนักงานที่เครื่องอ่านเช็กแค่ว่ามีบัตร ไม่เช็กว่าบัตรจริงไหม ภาพนี้ช่วยให้เห็นว่าปัญหาอยู่ที่การตรวจหลักฐานก่อนยอมให้ผ่าน สำหรับระบบจริง รายละเอียดไม่ได้ง่ายเพียงเท่านั้น และผู้ผลิตระบุเงื่อนไขว่าต้องมี GlobalProtect portal หรือ gateway เปิดใช้งานร่วมกับคุกกี้ข้ามการยืนยันตัวตน และมีการตั้งค่าใบรับรองแบบเฉพาะ ใบรับรองคือข้อมูลดิจิทัลที่ระบบใช้ยืนยันความน่าเชื่อถือ (Palo Alto Networks)
Portal และ gateway เป็นส่วนของ GlobalProtect ที่รับการเข้าใช้งานและการเชื่อมต่อ VPN เงื่อนไขข้างต้นจึงสำคัญกว่าการเห็นชื่อยี่ห้อบนอุปกรณ์อย่างเดียว ขอบเขตข่าวครอบคลุมไฟร์วอลล์ทั้งเครื่องจริงและแบบเสมือนที่ใช้ PAN-OS รวมถึง Prisma Access ขณะที่ประกาศผู้ผลิตระบุว่า Panorama และ Cloud NGFW ไม่ได้รับผลกระทบจากช่องโหว่นี้ (Help Net Security, Palo Alto Networks)
เมื่อการเชื่อมต่อที่ไม่ควรได้รับอนุญาตเข้ามาทาง VPN ของบริษัทแล้ว การแยกออกจากงานปกติอาจยากขึ้น ReliaQuest อธิบายว่าต้นทางการเข้าถึงแบบนี้ทำให้กิจกรรมอันตรายดูเหมือนงานทางไกลที่ถูกต้อง ส่วน Unit 42 พบการใช้เครื่องมือดูแลระบบที่มีการใช้งานโดยชอบด้วยกฎหมายด้วย การเห็นชื่อเครื่องมือที่ฝ่ายไอทีคุ้นเคยจึงไม่เพียงพอจะตัดสินว่ากิจกรรมนั้นปลอดภัย (Help Net Security, Unit 42)
จุดหักมุม: แก้ทางเข้าแล้ว คนที่เข้ามาก่อนอาจยังอยู่
คำเตือนที่หนักกว่าคำว่า “รีบอัปเดต” คือ ReliaQuest ระบุว่าการลงแพตช์อย่างเดียวอาจไม่เอาการเข้าถึงที่เกิดก่อนแก้ไขออกไป พร้อมแนะนำให้ยุติการเชื่อมต่อ GlobalProtect ที่ยังทำงานอยู่ทั้งหมดหลังลงแพตช์ และตรวจการเชื่อมต่อที่ไม่คาดคิด คำว่า session ที่ทีมไอทีใช้ หมายถึงช่วงการเชื่อมต่อเข้าใช้งานที่ระบบยังถือว่าเปิดอยู่ครับ (Help Net Security)
อีกประเด็นที่ Unit 42 พบในงานสอบสวนคือการเข้าถึงระบบจัดการเครื่องเสมือน ซึ่งเป็นระบบที่ควบคุมเครื่องคอมพิวเตอร์เสมือนหลายเครื่อง ในกรณีหนึ่งที่รายงาน การโจมตีระดับนี้หลบการตรวจจับที่ทำงานอยู่ภายในเครื่องเสมือนได้ นี่เป็นเหตุผลให้ทีมป้องกันมองผลกระทบกว้างกว่าตัว VPN โดยไม่ควรนำกรณีเดียวไปสรุปว่าทุกองค์กรถูกโจมตีด้วยรูปแบบเดียวกัน (Unit 42)
รายงานเดียวกันยังกล่าวถึงการใช้การเข้าถึงครั้งแรกต่อเนื่องไปกับเครื่องมือโจมตีระบบสำรองข้อมูล Veeam ด้วย ข้อเสนอของผมจากข้อมูลนี้คือ เวลารายงานสถานะให้เจ้าของกิจการ ควรแยกให้ชัดระหว่าง “อัปเดตอุปกรณ์แล้ว” กับ “ตรวจผลกระทบต่อระบบภายในแล้ว” เพราะเป็นงานคนละส่วนที่ข่าวนี้ทำให้เห็นความสำคัญ (Unit 42)
เรื่องเงิน / ผลกระทบ
แหล่งข้อมูลชุดนี้ไม่ได้ให้ยอดค่าไถ่ มูลค่าความเสียหาย หรือจำนวนองค์กรไทยที่ได้รับผลกระทบ จึงยังประเมินเป็นเงินบาทไม่ได้ สิ่งที่มีรายงานคือการขโมยข้อมูลและรหัสผ่าน ตลอดจนการนำแรนซัมแวร์มาใช้หลังเข้าถึงเครือข่าย ซึ่งทำให้การตัดสินใจของธุรกิจต้องพิจารณามากกว่าค่าแรงอัปเดตอุปกรณ์เพียงครั้งเดียว (Help Net Security)
ในเชิงวางแผน ผมแนะนำให้ผู้ดูแลกับเจ้าของกิจการตกลงกันล่วงหน้าว่าใครรับผิดชอบตรวจการเชื่อมต่อย้อนหลัง ใครตัดสินใจเมื่อพบความผิดปกติ และใครแจ้งพนักงานให้เข้าใช้งานใหม่ เหตุผลส่วนหลังมีข้อมูลรองรับชัดเจน: ผู้ผลิตระบุว่าหลังอัปเกรดที่แก้ช่องโหว่ ระบบที่ใช้คุกกี้ดังกล่าวจะสร้างคุกกี้ด้วยวิธีที่ปลอดภัยขึ้น และผู้ใช้ต้องยืนยันตัวตนใหม่หนึ่งครั้ง แม้คุกกี้เดิมยังไม่หมดอายุ (Palo Alto Networks)
ReliaQuest ประเมินว่าการใช้ช่องโหว่นี้โจมตีมีแนวโน้มสูงที่จะดำเนินต่อไปในช่วงสามเดือนถัดจากรายงาน เพราะทั้งกลุ่มเรียกค่าไถ่และนายหน้าขายการเข้าถึงระบบยังมองหาเครื่องที่ไม่แก้ไขอยู่ นี่เป็นการประเมินของ ReliaQuest ที่ Help Net Security นำมารายงาน ไม่ใช่กำหนดวันสิ้นสุดของความเสี่ยง และไม่ได้หมายความว่าพ้นช่วงนั้นแล้วจะปลอดภัยอัตโนมัติ (Help Net Security)
ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน
ระดับปานกลางในวันแรก กับระดับสูงในประกาศปัจจุบัน: Help Net Security ระบุว่าตอนเปิดเผยวันที่ 13 พฤษภาคม ผู้ผลิตจัดความรุนแรงปานกลาง แต่ประกาศผู้ผลิตที่ให้มาระบุ HIGH และคะแนน 7.8 ผู้ผลิตอธิบายว่าระดับความรุนแรงผูกกับคะแนนภัยคุกคาม ซึ่งปรับตามข้อมูลการโจมตีจริง ส่วนคะแนนพื้นฐานที่ประเมินจากคุณสมบัติทางเทคนิคไม่ได้เปลี่ยนตามกลไกนั้น จึงไม่ควรใช้ป้ายระดับวันแรกแทนการประเมินสถานการณ์เดือนตุลาคม (Help Net Security, Palo Alto Networks)
วันที่ 19 กับ 20 ตุลาคม: Help Net Security ระบุว่า Unit 42 อัปเดตเรื่องกลุ่มเรียกค่าไถ่วันที่ 19 ตุลาคม ขณะที่ชื่อบทความ Unit 42 ระบุ Updated October 20 และมีบันทึกอัปเดตสองรายการ หากแปลงเวลาที่ระบุโซนไว้ รายการเพิ่มกิจกรรมเรียกค่าไถ่คือ 20 ตุลาคม เวลา 06:00 น. ไทย ส่วนรายการเพิ่มคำแนะนำตรวจสอบและแก้ไขคือ 21 ตุลาคม เวลา 03:30 น. ไทย จึงมีทั้งวันที่ตามโซนต้นทางและคนละรอบการปรับข้อมูลอยู่ในข่าวชุดนี้ (Help Net Security, Unit 42)
ข้อความเก่ากับข้อมูลใหม่ในหน้าเดียวกัน: ส่วนสรุปของ Unit 42 ยังมีข้อความว่า ณ เวลานั้นไม่พบพฤติกรรมหลังเข้าถึงหรือการย้ายไปยังระบบอื่น แต่ส่วนอัปเดตเดือนตุลาคมกลับอธิบายพฤติกรรมเหล่านี้แล้ว ผมอ่านว่านี่เป็นข้อมูลต่างช่วงเวลาที่คงอยู่ในหน้าเดียวกัน จึงยึดส่วนอัปเดตเมื่ออธิบายสถานการณ์ล่าสุด ไม่ใช้ข้อความช่วงแรกปฏิเสธสิ่งที่พบภายหลัง (Unit 42)
ชื่อ Settra และขอบเขตความเสียหาย: Help Net Security ระบุว่า ReliaQuest ติดตามการใช้ช่องโหว่โดยหลายกลุ่ม รวม Qilin และ Settra ส่วน Unit 42 ระบุ Qilin กับ Inc และอ้างรายงานสาธารณะสำหรับ Settra ความต่างนี้สะท้อนว่ากำลังอ้างการติดตามคนละชุด ไม่ได้ยืนยันว่าทุกเหตุมีผู้โจมตีกลุ่มเดียวกัน และทั้งสามแหล่งไม่ได้ระบุรายชื่อองค์กรไทยที่ได้รับผลกระทบ (Help Net Security, Unit 42)
แล้วเราควรทำอะไร
ทีมไอทีและผู้ดูแลความปลอดภัย
- ตรวจว่ามี GlobalProtect portal หรือ gateway ที่เข้าเงื่อนไขการใช้คุกกี้และใบรับรองในประกาศหรือไม่ แล้วเลือกแพตช์ตามสายรุ่นที่ใช้งานจริง ผู้ผลิตให้เส้นทางอัปเกรดแยกตามรุ่นย่อย จึงควรเทียบกับประกาศโดยตรงก่อนลงมือ ประกาศให้วิธีเช็กคุกกี้ในหน้าจัดการไว้ดังนี้ ฝั่ง portal ไปที่ Network > GlobalProtect > Portals → ชื่อ portal → แท็บ Agent → โปรไฟล์ Agent Configuration → แท็บ Authentication แล้วดูว่าติ๊ก “Generate cookie for authentication override” หรือ “Accept cookie for authentication override” ไว้หรือไม่ ฝั่ง gateway ไปที่ Network > GlobalProtect > Gateways → ชื่อ gateway → แท็บ Agent → โปรไฟล์ Client Settings → แท็บ Authentication Override แล้วดูว่าติ๊ก “Accept cookie for authentication override” ไว้หรือไม่ (Palo Alto Networks)
- ตรวจให้ครบทุก portal และ gateway ทั้งภายในและภายนอกที่สร้างหรือยอมรับคุกกี้นี้ ผู้ผลิตระบุว่าต้องอัปเกรดให้สอดคล้องกันเพื่อเลี่ยงปัญหาความเข้ากันได้ของคุกกี้ ถ้าใช้ Prisma Access ร่วมกับอุปกรณ์ในองค์กร ต้องรวมอุปกรณ์ฝั่งองค์กรไว้ในแผนด้วย (Palo Alto Networks)
- หากยังต้องใช้มาตรการลดความเสี่ยง ให้ทำตามประกาศผู้ผลิต ซึ่งเสนอการปิด Authentication Override หรือการใช้ใบรับรองใหม่ที่แยกเฉพาะสำหรับคุกกี้นี้ ห้ามนำใบรับรองของ portal หรือ gateway มาใช้ร่วม และใบรับรองที่เคยใช้กับงานอื่นแล้วต้องเปลี่ยนเป็นใบใหม่สำหรับงานนี้ (Palo Alto Networks)
- หลังลงแพตช์ ให้ยุติการเชื่อมต่อ GlobalProtect ที่ยังเปิดอยู่ทั้งหมดตามคำแนะนำ ReliaQuest พร้อมแจ้งผู้ใช้เรื่องเข้าใช้งานใหม่ เพื่อไม่ให้การอัปเดตจบลงแค่เปลี่ยนหมายเลขรุ่น (Help Net Security)
- ตรวจบันทึกการเข้า VPN ย้อนหลังตั้งแต่เดือนพฤษภาคม โดยให้ความสำคัญกับการเชื่อมต่อที่สำเร็จและไม่คาดคิด ข้อเสนอย้อนช่วงเวลานี้อิงรายงานที่ Help Net Security อ้าง Rapid7 ว่าพบการโจมตีตั้งแต่วันที่ 17 พฤษภาคม ส่วน Unit 42 แนะนำให้ค้นหากิจกรรมในบันทึกและเริ่มกระบวนการรับมือเหตุเมื่อพบการเชื่อมต่อสำเร็จที่เกี่ยวข้องกับหลักฐานในรายงาน (Help Net Security, Unit 42)
- ร่องรอยที่ Unit 42 ให้ค้นในบันทึก GlobalProtect: การล็อกอินสำเร็จจาก IP
23.128.228[.]6,104.207.144[.]154,146.19.216[.]119,146.19.216[.]120,146.19.216[.]125,179.43.172[.]213,185.195.232[.]139,198.12.106[.]60และ202.144.192[.]47ซึ่งเป็นกิจกรรมก่อนโค้ดสาธิตถูกปล่อยเมื่อ 29 พฤษภาคม 2026 (Unit 42) - เหตุการณ์ gateway-connected ที่สำเร็จจาก IP ใดก็ได้ แต่ใช้ host ID หรือชื่อเครื่องน่าสงสัย เช่น
aa:bb:cc:dd:ee:ff,00:11:22:33:44:55,WINDOWS-LAPTOP-001,DESKTOP-GP01หรือGP-CLIENT(Unit 42) - หลังโค้ดสาธิตถูกปล่อย ให้ค้นเหตุการณ์ gateway-connected ที่สำเร็จซึ่งมีค่า
endpoint_os_version : Microsoft Windows 10 Pro 64-bitคู่กับsource_user_info.domainว่าง เพราะเป็นค่าที่ฝังมาในโค้ดสาธิต (Unit 42)
- ร่องรอยที่ Unit 42 ให้ค้นในบันทึก GlobalProtect: การล็อกอินสำเร็จจาก IP
- ตรวจการเปิดให้เข้าถึงหน้าบริหารอุปกรณ์จากอินเทอร์เน็ตด้วย เพราะ Unit 42 พบการตั้งค่าที่ผูกโปรไฟล์ GlobalProtect กับบริการ HTTP/HTTPS บนอินเทอร์เฟซบริหาร ทำให้ส่วนบริหารเปิดออกอินเทอร์เน็ตที่พอร์ต 4443 และ 3879 โดยผู้ดูแลอาจไม่ทราบ Unit 42 แนะนำให้ลองเปิด HTTPS ไปที่ IP บริหารของอุปกรณ์ทางพอร์ตทั้งสองจากเบราว์เซอร์ภายนอกเครือข่าย แล้วจำกัดการเข้าถึงด้วย Interface Management profile ตามเอกสารผู้ผลิตครับ (Unit 42)
เจ้าของกิจการและธุรกิจที่จ้างผู้ให้บริการดูแลระบบ
- ติดต่อผู้ให้บริการดูแลไอทีหรือ MSP วันนี้ ขอให้ระบุว่ากิจการใช้ผลิตภัณฑ์และการตั้งค่าที่เข้าเงื่อนไขหรือไม่ พร้อมรุ่นที่ใช้งานและแผนแก้ไข ผมเสนอให้ขอคำตอบที่ตรวจสอบต่อได้ เพราะประกาศแยกทั้งรุ่นและเงื่อนไขการเปิดใช้งานไว้ชัดเจน (Palo Alto Networks)
- ขอผลยืนยันเรื่องยุติการเชื่อมต่อหลังแพตช์และตรวจการเข้าใช้งานย้อนหลังด้วย คำตอบว่า “ลงแพตช์แล้ว” เพียงอย่างเดียวยังไม่ครอบคลุมคำเตือนเรื่องการเข้าถึงที่เกิดก่อนแก้ไขของ ReliaQuest (Help Net Security)
พนักงานและผู้ใช้ทั่วไป
- ผมแนะนำว่าถ้ามีคำขอยืนยัน MFA ทั้งที่ไม่ได้กำลังเข้าใช้งาน ให้หยุดและแจ้งทีมไอที พร้อมบอกเวลาที่พบ เพื่อให้ผู้ดูแลนำไปตรวจประกอบ อย่ารออาการนี้เป็นเงื่อนไขเดียวในการตรวจระบบ เพราะ Unit 42 ระบุว่าการโจมตีนี้ข้าม MFA เพื่อเปิดการเชื่อมต่อได้ (Unit 42)
- เตรียมยืนยันตัวตนใหม่หลังองค์กรอัปเกรดตามแจ้ง ผู้ผลิตระบุว่านี่เป็นข้อกำหนดหนึ่งครั้งสำหรับระบบที่ใช้คุกกี้ดังกล่าว หลังจากนั้นอายุและการทำงานของคุกกี้จะเป็นไปตามเดิม (Palo Alto Networks)
รุ่นแก้ไข: เลือกตามสายที่ใช้งาน และอ่านข้อขัดแย้งก่อนอัปเกรด
ตารางนี้ยกเป้าหมายอัปเกรดที่ประกาศผู้ผลิตระบุสำหรับแต่ละสาย ไม่ใช่รายการแพตช์ย่อยทั้งหมด และไม่ใช่คำแนะนำให้ข้ามไปสายอื่นโดยไม่ตรวจสภาพแวดล้อม รุ่นเก่าที่หมดการสนับสนุนต้องอัปเกรดไปยังรุ่นที่ยังได้รับการสนับสนุนและมีการแก้ไขแล้ว (Palo Alto Networks)
| สายผลิตภัณฑ์ | เป้าหมายแก้ไขที่ระบุในประกาศ |
|---|---|
| PAN-OS 12.1 | 12.1.7 หรือใหม่กว่า |
| PAN-OS 11.2 | 11.2.12 หรือใหม่กว่า |
| PAN-OS 11.1 | 11.1.15 หรือใหม่กว่า |
| PAN-OS 10.2 | 10.2.18-h6 หรือใหม่กว่า |
| Prisma Access 10.2 | 10.2.10-h36 หรือใหม่กว่า |
| Prisma Access 11.2 | 11.2.7-h13 หรือใหม่กว่า |
ทุกรุ่นในตารางอ้างอิงประกาศผู้ผลิต ซึ่งยังระบุแพตช์ย่อยทางเลือกไว้ด้วย เช่น 12.1.4-h6 สำหรับช่วงรุ่นที่กำหนด การเลือกต้องอิงแถวของรุ่นปัจจุบัน ส่วน Prisma Access ระบุว่ากำลังทยอยอัปเกรดให้ลูกค้าตามกำหนดที่แจ้งไว้ จึงควรยืนยันสถานะของระบบที่ตนใช้กับผู้ให้บริการ (Palo Alto Networks)
มีจุดสะดุดในเอกสารที่ต้องบอกตรง ๆ: แถวคำแนะนำสำหรับ PAN-OS 10.2.17 ถึง 10.2.18-h* เขียนว่าให้อัปเกรดเป็น “10.2.18 หรือ 10.2.18-h6 หรือใหม่กว่า” แต่ตารางสถานะผลิตภัณฑ์ระบุเกณฑ์แก้ไขของช่วงนี้ที่ 10.2.18-h6 ข้อมูลที่ให้มายังไม่อธิบายความต่างนี้ ผมจึงแสดงเป้าหมาย 10.2.18-h6 ตามตารางสถานะ และแนะนำให้ผู้ดูแลยืนยันกับผู้ผลิตก่อนตัดสินใจใช้ 10.2.18 ที่ไม่มีส่วนต่อท้ายเป็นหลักฐานว่าแก้แล้ว (Palo Alto Networks)
ผมมองว่า…
ผมมองว่า บทเรียนของเรื่องนี้ ไม่ใช่การจำชื่อกลุ่มเรียกค่าไถ่ให้ครบ แต่คือการทำให้คำว่าแก้แล้วมีหลักฐานรองรับ นี่เป็นความเห็นของผมครับ การอัปเดต การตัดการเชื่อมต่อเดิม และการตรวจผลย้อนหลังควรถูกรายงานแยกกัน เพราะคำเตือนของ ReliaQuest ชี้ชัดว่าการลงแพตช์อาจไม่เอาการเข้าถึงเก่าออกไป (Help Net Security)
สำหรับคนทำงานทั่วไป ผมคิดว่าบทบาทที่ทำได้ดีคือส่งสัญญาณผิดปกติให้เร็วและทำตามประกาศเข้าใช้งานใหม่ขององค์กร ส่วนเจ้าของกิจการควรขอสถานะที่อ่านแล้วรู้ว่าต้องทำอะไรต่อ ผมไม่อยากให้ข่าวที่มีชื่อรุ่นยาว ๆ ทำให้คนที่ไม่ใช่ฝ่ายไอทีรู้สึกว่าเกี่ยวอะไรกับตัวเองไม่ได้ ประเด็นที่ต้องตัดสินใจร่วมกันคือใครตรวจ ใครรับผิดชอบ และตรวจแล้วพบอะไร
ปิดท้าย: สิ่งที่ต้องจับตา
สิ่งที่ควรติดตามต่อคือข้อมูลสอบสวนและคำแนะนำเพิ่มเติมจาก Unit 42 ซึ่งระบุว่าจะอัปเดตเมื่อมีข้อมูลที่เกี่ยวข้อง รวมถึงสถานะอัปเกรดตามประกาศผู้ผลิต ส่วนการคาดว่าการโจมตีจะดำเนินต่อในสามเดือนถัดไปยังเป็นการประเมินของ ReliaQuest ที่รายงานผ่าน Help Net Security ไม่ใช่ข้อยืนยันว่าทุกระบบจะถูกโจมตี (Unit 42, Palo Alto Networks, Help Net Security)
งานที่เริ่มได้จากข่าวนี้คือขอให้ผู้รับผิดชอบตรวจทั้งสถานะแพตช์และการเชื่อมต่อที่เกิดขึ้นแล้ว โดยยังไม่ด่วนสรุปว่าองค์กรของตนถูกบุกรุก หลักฐานที่ให้มายังไม่ยืนยันผลกระทบต่อองค์กรไทยแห่งใด และการประเมินแต่ละแห่งต้องอาศัยข้อมูลระบบของตนเอง
Recap
- ให้ผู้ดูแลตรวจผลิตภัณฑ์ รุ่น และเงื่อนไขการตั้งค่ากับประกาศผู้ผลิต
- เลือกแพตช์ตามสายรุ่น และตรวจทุก portal กับ gateway ที่เกี่ยวข้อง
- ยืนยันสถานะ Prisma Access และอุปกรณ์ในองค์กรหากใช้งานร่วมกัน
- วางแผนยุติการเชื่อมต่อเดิมหลังลงแพตช์และแจ้งผู้ใช้ล่วงหน้า
- ขอผลตรวจการเข้า VPN ย้อนหลังตั้งแต่เดือนพฤษภาคมและการเชื่อมต่อที่ไม่คาดคิด
- ให้ผู้ให้บริการดูแลระบบตอบทั้งเรื่องแพตช์และผลตรวจหลังแก้ไข
- แจ้งทีมไอทีเมื่อพบคำขอ MFA ที่ไม่ได้เริ่มเอง
- อย่าใช้สถานะอัปเดตสำเร็จแทนผลตรวจว่ามีผู้บุกรุกอยู่ก่อนแล้วหรือไม่