EST. 2026 — บันทึกงานเซิร์ฟเวอร์จริง SYSADMIN · SECURITY · AI · DIRECTADMIN เล่มที่ 01
THE SYSADMIN ALMANAC
หน้าหลัก / Security Update / BIND CVE-2015-5477 บั๊กปี 2015 ถูกลง CISA KEV ต.ค. 2026 เช็ก named ด่วน
Security Update

BIND CVE-2015-5477 บั๊กปี 2015 ถูกลง CISA KEV ต.ค. 2026 เช็ก named ด่วน

โดย Ton-Or ·8 ต.ค. 2026·อ่าน 5 นาที
BIND CVE-2015-5477 บั๊กปี 2015 ถูกลง CISA KEV ต.ค. 2026 เช็ก named ด่วน

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

สรุปใน 1 นาที

อาการ/ปัญหา
แพ็กเก็ต TKEY ที่ออกแบบมาโดยเฉพาะทำให้ named เจอ assertion failure แล้วปิดตัว (DoS) และถูกโจมตีจริงตาม KEV
ใครควรอ่าน
BIND 9.1.0 ถึง 9.8.x, 9.9.0 ถึง 9.9.7-P1 และ 9.10.0 ถึง 9.10.2-P2 ทั้ง recursive และ authoritative
ทางแก้แบบสั้น
อัปเป็น 9.9.7-P2, 9.10.2-P3 หรือรุ่นใหม่กว่า ISC ระบุว่าไม่มี workaround
ข้ามไปขั้นตอน

พอดีเห็น CISA เพิ่ม CVE-2015-5477 ของ ISC BIND เข้า KEV เมื่อ 8 ต.ค. 2026 ผมอ่านปีของเลข CVE แล้วนึกว่าพิมพ์ผิด แต่ไม่ผิดครับ มันคือบั๊กปี 2015 จริงๆ แปลว่า 11 ปีผ่านไปยังมี DNS server รุ่นเก่าบนอินเทอร์เน็ตให้ยิงอยู่ ผมเลยสรุปไว้ให้ใครที่ยังมี BIND รุ่นเก่าอยู่ในมือ

7.8CVSS v2 (ISC, NVD)
KEV 8 ต.ค.ถูกโจมตีจริง
ปี 2015ประกาศ 28 ก.ค.
ไม่มีworkaround

เกิดอะไรขึ้น

ตามประกาศของ ISC (AA-01272) แพ็กเก็ตที่สร้างขึ้นมาเฉพาะซึ่งเป็น TKEY query ทำให้ BIND เจอ REQUIRE assertion failure แล้ว named ปิดตัวเอง เซิร์ฟเวอร์ DNS ก็หยุดตอบ ใครยิงซ้ำได้เรื่อยๆ ก็ทำให้บริการล่มต่อเนื่อง เป็นการโจมตีแบบ DoS ไม่ใช่การเข้ายึดเครื่อง

ข้อที่ควรรู้คือ ISC ระบุว่าทั้ง recursive และ authoritative server โดนหมด และ ACL กับการตั้งค่าจำกัดการใช้งาน ป้องกันไม่ได้ เพราะโค้ดส่วนที่มีบั๊กทำงานก่อนขั้นตรวจพวกนั้น ISC ยังบันทึกว่ามี proof-of-concept ถูกเผยแพร่ไว้ในที่เก็บโค้ดสาธารณะโดยบุคคลที่สาม ผู้ค้นพบคือ Jonathan Foote

ทำไม ACL ถึงช่วยไม่ได้แพ็กเก็ต TKEYส่งมาจากเน็ตได้โค้ดอ่าน TKEYบั๊กอยู่ตรงนี้named ปิดตัวREQUIRE ล้มACL / ข้อจำกัดไม่ทันได้ทำงานลำดับการแก้named -vดูรุ่นที่รันอยู่จริงอัปเดตแพ็กเกจ9.9.7-P2 / 9.10.2-P3+restart namedแล้วเช็กรุ่นซ้ำ
โค้ดส่วนที่มีบั๊กทำงานก่อนขั้นตรวจสิทธิ์ ตั้ง ACL เข้มแค่ไหนก็ไม่ช่วย ทางเดียวคือรุ่นที่แก้

ระดับความรุนแรง

  • CVSS v2: 7.8 เวกเตอร์ AV:N/AC:L/Au:N/C:N/I:N/A:C ทั้ง ISC และ NVD ให้ค่านี้ ISC ติดป้าย Critical ให้ในประกาศของตัวเอง
  • CVSS v3.1: 7.5 เวกเตอร์ AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H ตัวเลขนี้ NVD แสดงเป็นของผู้ให้คะแนนรายที่สอง ไม่ใช่ของ NVD เอง
  • CISA KEV: ลง 8 ต.ค. 2026 กำหนดแก้ 11 ต.ค. 2026 การประเมินของ CISA ในรายการนี้ระบุ exploitation เป็น active และ automatable เป็น yes ข้อกำหนดที่ NVD แสดงคือใช้มาตรการลดผลกระทบตามผู้ผลิต ตาม CISA BOD 26-04 ถ้าทำไม่ได้ให้เลิกใช้ผลิตภัณฑ์นั้น
  • Ransomware: ฟีด KEV ระบุ Unknown

ผลกระทบคือ DoS ล้วนๆ ไม่มีรายงานว่าเอาไปรันโค้ดหรืออ่านข้อมูลในประกาศที่ผมเปิดอ่าน แต่สำหรับ DNS ที่เว็บและเมลของทั้งองค์กรพึ่งอยู่ การที่ named ล้มแค่ครั้งเดียวก็เท่ากับทุกอย่างหาโดเมนไม่เจอ

รุ่นที่กระทบและรุ่นที่แก้

สายของ BIND สถานะตาม ISC AA-01272
9.1.0 ถึง 9.8.x กระทบ ไม่มีรุ่นแก้ในสายนี้ ต้องย้ายไปสายที่ใหม่กว่า
9.9.0 ถึง 9.9.7-P1 กระทบ แก้ใน 9.9.7-P2
9.10.0 ถึง 9.10.2-P2 กระทบ แก้ใน 9.10.2-P3
รุ่นอื่นที่ไม่อยู่ในรายการข้างบน ISC ไม่ได้ระบุว่ากระทบ

ISC แนะนำให้อัปเกรดไปรุ่นแก้ที่ใกล้กับรุ่นที่ใช้อยู่มากที่สุด และระบุว่าไม่มี workaround ส่วนข้อมูลของ distro: ในรายการอ้างอิงของ CVE record มีประกาศของ Debian (DSA-3319), Ubuntu (USN-2693-1) และ Red Hat (RHSA-2015:1513, 1514, 1515) ผมไม่ได้เปิดอ่านแต่ละฉบับ ใครใช้ package จาก distro ให้ดูใน changelog ด้วยคำสั่งด้านล่าง เพราะ distro มักแพตช์ลงรุ่นเดิมโดยไม่เปลี่ยนเลขรุ่น

วิธีเช็กและวิธีแก้

เช็กรุ่นของ named ที่รันอยู่จริง ไม่ใช่แค่ที่ติดตั้งไว้

named -v
# Debian / Ubuntu
dpkg -l bind9 | grep '^ii'
apt changelog bind9 2>/dev/null | grep -m1 CVE-2015-5477
# RHEL / Rocky / AlmaLinux
rpm -q bind
rpm -q --changelog bind | grep -m1 CVE-2015-5477

ถามรุ่นจากข้างนอกได้ด้วย แต่หลายที่ซ่อนหรือแก้ค่านี้ไว้ ถ้าไม่ตอบ ไม่ได้แปลว่าปลอดภัย

dig +short chaos txt version.bind @ns1.example.com

ถ้าเลขรุ่นอยู่ในช่วงที่กระทบ ให้อัปเดตแล้ว restart

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade bind9
sudo systemctl restart named     # บาง distro ใช้ชื่อ bind9

# RHEL ตระกูลเดียวกัน
sudo dnf upgrade bind
sudo systemctl restart named
named -v
ระหว่างที่ยังอัปเดตไม่ได้

ISC ไม่มี workaround ให้ ที่ผมเสนอได้เป็นความเห็นผมเอง ไม่ใช่ของ ISC คือใช้ firewall จำกัดว่าใครส่งแพ็กเก็ตมาหา port 53 ได้ สำหรับ resolver ที่ไม่ต้องเปิดสาธารณะ และตั้งให้ systemd ดัน named กลับขึ้นมาเองเมื่อล้ม วิธีนี้แค่ลดเวลาล่ม ไม่ได้แก้ช่องโหว่ ส่วน authoritative ที่ต้องเปิดให้ทั้งโลกถามได้ ต้องอัปเดตอย่างเดียว

  1. ไล่รายการ DNS server ทุกตัวที่รู้จัก รวมอุปกรณ์ที่มี resolver ในตัว
  2. เช็กรุ่น ด้วย named -v และ changelog ของ package
  3. อัปเดต หรือย้ายสาย ถ้าเป็นสาย 9.8 ลงไป
  4. restart และเช็กซ้ำ ว่ารุ่นที่รันอยู่เปลี่ยนจริง
สิ่งที่ KEV ไม่ได้บอก

KEV ยืนยันว่ามีการโจมตีจริง แต่ไม่ได้บอกว่าโจมตีใคร หรือมีบริการล่มที่ไหนบ้าง ผมเลยไม่เดาเกินกว่านั้น

ทำไมของเก่าถึงยังเหลือ

ข้อนี้เป็นการคาดของผมเองจากที่เคยเจอ ไม่ใช่ข้อมูลจากประกาศ BIND ฝังอยู่ในอุปกรณ์หลายชนิด เช่น router, firewall appliance และกล่อง DNS ที่ผู้ผลิตเลิกออกเฟิร์มแวร์ไปแล้ว รุ่นนั้นอัปเดต package เองไม่ได้ และคนดูแลมักไม่รู้ว่ามี BIND อยู่ข้างใน ถ้ามี DNS server ที่ตั้งไว้นานแล้วและไม่มีใครกล้าแตะ ให้ไล่ดูเป็นพิเศษ ตั้งแต่ resolver ในวงภายใน DNS ของโดเมนเก่า ไปจนถึงเครื่องที่ถูกลืม

CISA ระบุไว้ในรายการว่าถ้าไม่มีทางลดผลกระทบ ให้เลิกใช้ผลิตภัณฑ์ ซึ่งสำหรับอุปกรณ์ที่ไม่มีเฟิร์มแวร์ใหม่ก็เท่ากับต้องเปลี่ยนตัว

เช็กว่าโดนหรือยัง

ISC และ CISA ไม่ได้เผยแพร่ IOC สำหรับตัวนี้ในที่ที่ผมเปิดอ่าน และผมไม่พบคำแนะนำทดสอบเฉพาะจาก ISC ในประกาศ AA-01272 เลยไม่เขียนวิธีทดสอบด้วยแพ็กเก็ตเอง สิ่งที่สังเกตได้คือ named ปิดตัวเองซ้ำๆ และใน log มีข้อความ assertion failure เกี่ยวกับ REQUIRE

sudo journalctl -u named --since "30 days ago" | grep -iE 'assertion|REQUIRE|exiting'

ถ้าพบหลายครั้ง แล้วรุ่นอยู่ในช่วงที่กระทบ ให้ถือว่าโดนยิงจริง

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

ปล. ถ้าเจอ BIND รุ่น 9.8 ลงไป อย่าคิดแค่จะลง patch เพราะสายนั้นไม่มีรุ่นแก้ ต้องย้ายขึ้นสายใหม่

ที่มา: ISC Security Advisory AA-01272 (https://kb.isc.org/docs/aa-01272), NVD CVE-2015-5477 (https://nvd.nist.gov/vuln/detail/CVE-2015-5477), CVE record (https://www.cve.org/CVERecord?id=CVE-2015-5477), CISA Known Exploited Vulnerabilities Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) ข้อมูลถึง 5 พ.ย. 2026 ถ้า ISC หรือ distro มีข้อมูลเพิ่ม เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ

อยากให้เราทำให้ไหม?

ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า

คุยเรื่องงานกับเรา

เคยเจองานแบบนี้ไหม? ติดตรงไหน?

มาแลกวิธีกันต่อในบอร์ด LinuxThai

→ คุยต่อในบอร์ด

ความคิดเห็น 0

ยังไม่มีความคิดเห็น — เป็นคนแรกเลย