Defense in Depth: ยกระดับการป้องกันด้วย WAF และ EDR สู่มาตรฐานใหม่ในการป้องกันระบบ

Key Message

• แฮ็กเกอร์มีความสามารถสูงขึ้นมากในปัจจุบัน การป้องกันระบบด้วยอุปกรณ์ใดอุปกรณ์หนึ่ง อาจไม่เพียงพออีกต่อไป การทำงานร่วมกันด้วย Defense in Depth Concept อาจเป็นมาตรการป้องกันที่มีประสิทธิภาพมากขึ้น
• แฮ็กเกอร์ที่มีความสามารถระดับสูงมีเทคนิคมากมายในการหลบเลี่ยงการตรวจจับจาก WAF ผ่านการปรับเปลี่ยน Payload ซึ่งอาจทำให้ Signature เดิม ๆ ตรวจจับไม่ได้
• ในการป้องกัน WAF (รวมถึง IPS/NGFW) จำเป็นอย่างยิ่งที่จะต้องเห็น Payload ของการโจมตีทั้งหมดเพื่อจับ Exploit ได้อย่างแม่นยำ ซึ่งหากไม่ได้มีการกำหนดค่า Decrypt SSL อย่างถูกต้อง ระบบอาจจะไม่สามารถตรวจจับการโจมตีได้

       เมื่อช่วงต้นเดือนธันวาคม 2025 ได้มีการค้นพบช่องโหว่การเรียกใช้โค้ดที่เป็นอันตรายจากระยะไกล (RCE) โดยไม่ต้องผ่านการยืนยันตัวตน ระดับ Critical ในโปรโตคอล "Flight" ของ React Server Components (RSC) ซึ่งช่องโหว่นี้ส่งผลกระทบต่อ React 19 Ecosystem และเฟรมเวิร์กที่ใช้งาน โดยเฉพาะอย่างยิ่ง Next.js และมี Public Exploit ถูกเผยแพร่ออกมาแล้ว โดยรายละเอียดของช่องโหว่ดังกล่าวสามารถดูได้จาก Link

       ข้อมูลใน Blog นี้จะพามาดูกันว่า เมื่อเผชิญกับช่องโหว่ร้ายแรงอย่างเช่น "React2Shell" การพึ่งพาเพียงแค่การป้องกันระบบด้วยอุปกรณ์ใดอุปกรณ์หนึ่ง อาจไม่เพียงพอต่อการป้องกันการโจมตีได้อย่างสมบูรณ์ การยกระดับการป้องกันด้วย Defense in Depth Concept เช่น การทำงานร่วมกันระหว่าง WAF และ EDR จึงอาจเป็นมาตรการป้องกันที่มีประสิทธิภาพมากขึ้น เพื่อใช้ในการตรวจจับ และยับยั้งการโจมตีระหว่างที่องค์กรรอการอัปเดตแพตช์

ทำไมแค่ WAF ถึงอาจจะไม่พอ?

      ทีม I-SECURE ได้ทำการทดสอบการโจมตีระบบที่ใช้ React โดยใช้ Public Exploit สำหรับโจมตีช่องโหว่ React2Shell โดยที่ระบบดังกล่าวมีการป้องกันด้วย WAF (Web Application Firewall) และ Next Generation Firewall (NGFW) ที่ได้รับการอัปเดต Signature เพื่อป้องกันการโจมตีจาก CVE-2025-55182 แล้ว และมีการติดตั้ง Endpoint Detection and Response (EDR) ไว้บนระบบ

Lab Diagram

การทดสอบ 1 : ทดสอบโดยใช้ Public Exploit บน Github

       โดยจากการทดสอบใช้ Public Exploit หลายรายการ พบว่า Exploit ส่วนใหญ่ถูกตรวจจับได้จาก WAF Signature CVE-2025-55182 ซึ่งเป็น Signature สำหรับป้องกันการโจมตีจากช่องโหว่ React2Shell โดยตรง

       จากนั้นเมื่อตรวจสอบ Log ที่อุปกรณ์ NGFW จะพบว่าเห็นเพียง Traffic การเชื่อมต่อเป็น Application SSL แต่ไม่สามารถตรวจจับพฤติกรรมการโจมตีได้ ซึ่งสาเหตุหลักเกิดจากการที่อุปกรณ์ NGFW ไม่ได้มีการกำหนดค่า Decrypt SSL ของเว็บไซต์ไว้ ทำให้อุปกรณ์ไม่สามารถตรวจจับการโจมตีที่อยู่ใน Payload ได้

       ทางทีม I-SECURE จึงลองทดสอบอีกครั้งโดยเพิ่มการกำหนดค่า Decrypt SSL ของเว็บไซต์ไว้บน NGFW พบว่าครั้งนี้อุปกรณ์สามารถตรวจจับการโจมตีในรูปแบบ React2Shell ได้ด้วย Threat Signature “React Server Components Remote Code Execution Vulnerability”

การทดสอบ 2 : ทดสอบโดยการแก้ไข Payload จาก Public Exploit บน Github

       ทางทีม I-SECURE ลองทดสอบอีกครั้ง โดยการนำ Public Exploit ที่มีการแก้ไข Payload บางส่วน พบว่า Exploit ยังถูกตรวจจับได้จากอุปกรณ์ WAF แต่กลับถูกตรวจจับได้จาก WAF Signature ที่ถูกพบตั้งแต่ปี 2019 (อาจจะเกิดจากการที่มี Payload ของการโจมตีบางส่วนที่คล้ายกันกับช่องโหว่ของปี 2019) ซึ่งหมายความว่าหากแฮ็กเกอร์ที่มีความสามารถสูง ทำการเปลี่ยนแปลง Payload บางอย่าง ก็อาจจะสามารถ Bypass การป้องกันของ WAF ได้

       โดยเมื่อตรวจสอบที่อุปกรณ์ NGFW (ที่มีการเพิ่มการ Decrypt SSL ของเว็บไซต์ไว้แล้ว) ก็พบว่าอุปกรณ์ยังสามารถตรวจจับการโจมตีในรูปแบบ React2Shell ได้ด้วย Threat Signature “React Server Components Remote Code Execution Vulnerability” เช่นเดียวกับ Exploit ในครั้งแรก

การทดสอบ 3 : ทดสอบโดยการเรียกใช้คำสั่งหลังจาก Exploit สำเร็จ

       ทางทีม I-SECURE ทดสอบต่อไปโดยการเรียกใช้คำสั่งบนระบบภายหลังจากการ Exploit สำเร็จ เพื่อดูพฤติกรรมที่เกิดขึ้นบน Crowdstrike EDR ที่อยู่บน Server โดยพบว่า EDR มีข้อมูล Telemetry Process จากการเรียกใช้คำสั่งที่เกิดขึ้นภายหลังจากที่การโจมตีสำเร็จ โดยจะพบรายละเอียดของ Process Tree ดังนี้:

• Process “node” พยายามเรียกใช้คำสั่งต่าง ๆ ด้วย Process “dash/bash”

       โดยพฤติกรรมการเรียกใช้คำสั่งบน Server ดังกล่าวจะไม่ถูก Block โดย Crowdstrike EDR เนื่องจาก CrowdStrike จะไม่ Block การเรียกใช้คำสั่งบน Server โดยค่าเริ่มต้น หรือไม่ Block ในทุกสถานการณ์ เนื่องจากแอปพลิเคชันที่ถูกต้องตามปกติก็สามารถรันคำสั่งบน OS ได้เช่นกัน ยกเว้นบางคำสั่งจะแสดงพฤติกรรมที่เป็นอันตราย ”อย่างชัดเจน” เพื่อป้องกันการ Block ที่เป็น False Positive ซึ่งอาจส่งผลกระทบกับการใช้งานตามปกติได้

การทดสอบ 4 : ทดสอบโดยการเขียน Detection Rule เพิ่มเติมบน EDR

      ทางทีม I-SECURE ทดสอบต่อไปโดยการเขียน Detection Rule เพิ่มเติมเพื่อนำมาช่วยยกระดับการตรวจจับพฤติกรรมการเรียกใช้คำสั่งบน Server จาก Telemetry Process

      ซึ่งพบว่าภายหลังจากทดสอบการเรียกใช้คำสั่งบน Server อีกรอบ Crowdstrike EDR สามารถป้องกันการเรียกใช้คำสั่งที่เป็นผลมาจากการโจมตีแบบ React2Shell ได้

บทสรุป

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

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

       ดังนั้นการพึ่งพาเพียงแค่การป้องกันระบบด้วยอุปกรณ์ใดอุปกรณ์หนึ่ง อาจไม่เพียงพอต่อการป้องกันการโจมตีได้อย่างสมบูรณ์ หากระบบขององค์กรกำลังถูกโจมตีจากช่องโหว่ React2Shell หรือช่องโหว่อื่น ๆ ในลักษณะคล้ายกัน การนำ Defense in Depth Concept เช่น การใช้งาน WAF ร่วมกับ EDR คืออีกหนึ่งตัวช่วยที่เข้ามาช่วยตรวจจับ, ยับยั้ง หรือชะลอการโจมตีได้ ซึ่งถือเป็นมาตรการป้องกันระหว่างที่องค์กรยังไม่สามารถอัปเดตแพตซ์ได้ รวมไปถึงเป็นมาตรการป้องกันสำหรับช่องโหว่ในลักษณะคล้ายกันในอนาคต

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

อ้างอิงจาก

• https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 
• https://www.bleepingcomputer.com/news/security/react2shell-flaw-exploited-to-breach-30-orgs-77k-ip-addresses-vulnerable/