ด่วน! พบเทคนิคการโจมตี DoS แบบใหม่ “HTTP/2 Bomb” องค์กรใช้งาน Web Server ที่มีช่องโหว่ เสี่ยงถูกโจมตี

ยอดเข้าชม: 68 views

ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (ThaiCERT) ได้ติดตามสถานการณ์ข่าวสารภัยคุกคามทางไซเบอร์ พบรายงานเทคนิคโจมตีแบบ Remote Denial-of-Service (Remote DoS) รูปแบบใหม่ ชื่อ “HTTP/2 Bomb” โดยผู้โจมตีจะใช้ช่องโหว่ในการสร้างการเชื่อมต่อเพื่อดึงหน่วยความจำของ Server ไปใช้จนหมดอย่างรวดเร็ว ส่งผลให้ระบบล่มและไม่สามารถให้บริการได้ ช่องโหว่นี้ส่งผลกระทบโดยตรงต่อระบบ Web Server และ Proxy Server หลายผลิตภัณฑ์ที่เปิดใช้งาน HTTP/2 เป็นค่าเริ่มต้น ได้แก่ NGINX, Apache, Microsoft IIS, Envoy และ Cloudflare Pingora [1]

1. รายละเอียดช่องโหว่ [2]
HTTP/2 Bomb เป็นเทคนิคโจมตีแบบ Remote DoS ที่ผสมผสานเทคนิคการโจมตี 2 รูปแบบเข้าด้วยกัน ได้แก่ การขยายขนาดข้อมูลจากการบีบอัดส่วน Header (HPACK compression amplification) และการหน่วงการเชื่อมต่อแบบล่อหลอก (Slowloris-style hold) ผ่านระบบควบคุมการไหลของข้อมูล (HTTP/2 flow-control) ซึ่งในสถานการณ์ปกติ HPACK จะช่วยบีบอัดข้อมูลส่วนหัว (Header) เพื่อให้การส่งข้อมูลรวดเร็วขึ้น แต่ผู้โจมตีสามารถดัดแปลงให้ข้อมูลขนาดเล็กที่ถูกส่งไป เกิดการขยายขนาดเมื่อไปถึงฝั่งเซิร์ฟเวอร์ ทำให้เซิร์ฟเวอร์ต้องจองพื้นที่หน่วยความจำ (Memory allocation) เป็นจำนวนมาก จากนั้นผู้โจมตีจะใช้เทคนิคการแจ้งเซิร์ฟเวอร์ว่าฝั่งผู้รับไม่มีพื้นที่รับข้อมูล (Zero-byte flow-control window) เพื่อหน่วงเวลาให้เซิร์ฟเวอร์ไม่สามารถส่งข้อมูลกลับมาได้ และไม่สามารถคืนพื้นที่หน่วยความจำส่วนนั้นกลับสู่ระบบได้ตามปกติ
จากการทดสอบพบว่า ผู้โจมตีที่ใช้อินเทอร์เน็ตความเร็วเพียง 100 Mbps สามารถดึงหน่วยความจำของ Web Server ที่ได้รับผลกระทบ ไปใช้จนหมดภายในไม่กี่วินาที เช่น ผลิตภัณฑ์ของ Envoy ใช้จนหมด 32 GB ภายใน 10 วินาที, Apache ภายใน 18 วินาที, NGINX ภายใน 45 วินาที และ IIS ดึงหน่วยความจำไปถึง 64 GB ภายใน 45 วินาที

ทั้งนี้ HTTP/2 Bomb ไม่มีหมายเลขช่องโหว่ (CVE) รวมเพียงหมายเลขเดียว แต่จะถูกแยกตามผลิตภัณฑ์ที่ได้รับผลกระทบ เช่น Apache ได้รับการระบุเป็น CVE-2026-49975 และ Envoy ได้รับการระบุเป็น CVE-2026-47774 โดย Envoy advisory ระบุความรุนแรงระดับ High คะแนน CVSS 3.1 เท่ากับ 7.5

2. ผลิตภัณฑ์ที่ได้รับผลกระทบ
2.1 NGINX ที่เปิดใช้งาน HTTP/2 ในเวอร์ชันก่อน 1.29.8
2.2 Apache HTTP Server ที่ใช้งาน mod_http2 เวอร์ชันก่อน 2.0.41 หรือแพ็กเกจที่ยังไม่ได้รวมแพตช์ดังกล่าว
2.3 Microsoft IIS ที่เปิดใช้งาน HTTP/2
2.4 Envoy เวอร์ชันก่อน 1.35.11, 1.36.7, 1.37.3 และ 1.38.1
2.5 Cloudflare Pingora หรือ deployment ที่ใช้ HTTP/2 และยังไม่มีมาตรการจำกัดจำนวน header / cookie header / decoded header size อย่างเหมาะสม
2.6 ระบบ Web Server, Reverse Proxy, Load Balancer หรือ API Gateway ใด ๆ ที่ terminate HTTP/2 จากอินเทอร์เน็ตโดยตรง

3. แนวทางการแก้ไข [3]
3.1 NGINX: อัปเดตเป็นเวอร์ชัน 1.29.8 หรือใหม่กว่า ซึ่งเพิ่ม directive max_headers โดยมีค่าเริ่มต้นเป็น 1000
3.2 Apache HTTP Server: อัปเดต mod_http2 เป็นเวอร์ชัน 2.0.41 หรือใหม่กว่า และตรวจสอบว่าแพ็กเกจ Apache ที่ใช้งานอยู่มีแพตช์ดังกล่าวแล้ว
3.3 Envoy: อัปเดตเป็นเวอร์ชันที่ได้รับการแก้ไข ได้แก่ 1.35.11, 1.36.7, 1.37.3, 1.38.1 หรือใหม่กว่า
3.4 Microsoft IIS และ Cloudflare Pingora: ตรวจสอบประกาศแพตช์จากผู้ผลิตอย่างใกล้ชิด และพิจารณาปิด HTTP/2 ชั่วคราวหากระบบมีความเสี่ยงสูงหรือเปิดรับทราฟฟิกจากอินเทอร์เน็ตโดยตรง

4. หากยังไม่สามารถอัปเดตได้ทันที ควรดำเนินการดังนี้
4.1 ปิดใช้งาน HTTP/2 ชั่วคราวในระบบที่เสี่ยง โดยเปลี่ยนให้รองรับเฉพาะ HTTP/1.1 เช่น NGINX ใช้ http2 off; และ Apache ใช้ Protocols http/1.1
4.2 วาง Web Application Firewall, Reverse Proxy, CDN หรือ Load Balancer ที่สามารถจำกัดจำนวน header ต่อ request และจำกัด decoded header size ได้ไว้ด้านหน้าเซิร์ฟเวอร์
4.3 จำกัดจำนวน HTTP/2 streams, concurrent connections, request header fields และ cookie header fragments ต่อ client
4.4 ตั้งค่า memory limit ให้ worker process หรือ container เช่น cgroups, container memory limit หรือ ulimit เพื่อลดโอกาสที่ process เดียวจะลากระบบทั้งเครื่องเข้าสู่ภาวะ swap หรือ OOM
4.5 เฝ้าระวัง memory usage ของ Web Server / Proxy ที่เพิ่มขึ้นผิดปกติอย่างรวดเร็ว
4.6 ตรวจสอบ log เพื่อค้นหาทราฟฟิก HTTP/2 ที่ผิดปกติ เช่น header/cookie pattern ซ้ำจำนวนมาก การเชื่อมต่อที่ค้างนานผิดปกติ หรือการเกิด OOM kill / exit status 137 ใน containerized environment
4.7 สำหรับระบบสำคัญที่เปิดสู่อินเทอร์เน็ต ควรทดสอบผลกระทบของการปิด HTTP/2 ในสภาพแวดล้อม staging ก่อนนำไปใช้จริง เพื่อหลีกเลี่ยงผลกระทบต่อ performance และ compatibility

แหล่งอ้างอิง
[1] https://dg.th/qtxyvr1p3h
[2] https://dg.th/3gp5n74mt6