Log4Shell มองย้อนหลัง Firewall และ Egress Filtering ช่วยได้แค่ไหน

ในเดือนธันวาคม 2564 ข้อความเพียงบรรทัดเดียวใน log อาจทำให้เซิร์ฟเวอร์ Java ดาวน์โหลดและรันโค้ดของผู้อื่นได้ ทุกวันนี้ Log4Shell เป็นเรื่องเก่าแล้วครับ แต่ก็ยังเป็นตัวอย่างที่ชัดที่สุดที่ผมรู้จัก ว่า Firewall ทำอะไรได้และทำอะไรไม่ได้กับช่องโหว่ในระดับแอปพลิเคชัน บทความนี้คือบันทึกของผมจากแหล่งข้อมูลต้นทางครับ

ช่องโหว่นี้คืออะไร

CVE-2021-44228 เป็นช่องโหว่ใน log4j-core ซึ่งเป็นส่วนหนึ่งของไลบรารีบันทึก log ชื่อ Apache Log4j 2 ฟีเจอร์ JNDI ของไลบรารีไม่ได้ป้องกัน LDAP และ JNDI endpoint อื่นที่ผู้โจมตีควบคุม ผู้โจมตีที่ควบคุมข้อความ log หรือพารามิเตอร์ของข้อความได้ จึงสั่งรันโค้ดที่โหลดมาจาก LDAP server ได้ NVD ให้คะแนน 10.0 ซึ่งเป็นคะแนน CVSS สูงสุด เวอร์ชันที่ได้รับผลกระทบคือ 2.0-beta9 จนถึงก่อน 2.15.0 โดย Apache แก้ไขใน 2.15.0 สำหรับ Java 8 ขึ้นไป 2.12.2 สำหรับ Java 7 และ 2.3.1 สำหรับ Java 6 ช่องโหว่นี้อยู่เฉพาะใน JAR log4j-core แอปพลิเคชันที่ใช้เพียง log4j-api จึงไม่ได้รับผลกระทบ ส่วน Log4j 1 มีปัญหาที่เกี่ยวข้องแต่แยกกัน ติดตามเป็น CVE-2021-4104 และมีผลเฉพาะ configuration ที่ใช้ JMSAppender (หน้า security ของ Apache Log4j)

ในทางปฏิบัติ ผู้โจมตีเพียงแค่ทำให้ข้อความของตนถูกบันทึกลง log เท่านั้น Unit 42 พบ exploit string ส่วนใหญ่ใน URL และในฟิลด์ของ HTTP request header โดยฟิลด์ที่พบบ่อยได้แก่ Referer, X-Api-Version, Accept-Language, Cookie และ User-Agent (Unit 42)

ทำไมจึงกระทบระบบจำนวนมาก

Cyber Safety Review Board (CSRB) อธิบายไว้ตรงไปตรงมาว่า Log4j ใช้ง่าย ฟรี และทำงานได้ดี นักพัฒนา Java จึงฝังไลบรารีนี้ไว้ในซอฟต์แวร์อื่นหลายพันชุด ฟีเจอร์ JNDI lookup ถูกรับเข้ามาตั้งแต่ปี 2556 ก่อน Log4j 2 จะเปิดให้ใช้งานทั่วไป และแพร่กระจายไปพร้อมกัน อีกทั้งไม่มี "รายชื่อลูกค้า" ของ Log4j องค์กรและผู้ผลิตจึงต้องไล่หาเองว่าใช้ไลบรารีนี้อยู่ที่ไหน ในขณะที่ผู้โจมตีเริ่มสแกนแล้ว (รายงาน CSRB, กรกฎาคม 2565) Unit 42 ระบุว่า Apache Struts, Solr, Druid, Flink และ Elasticsearch เป็นซอฟต์แวร์ที่อาจได้รับผลกระทบ

ลำดับเหตุการณ์

• 24 พ.ย. 2564: วิศวกรความปลอดภัยของ Alibaba Cloud รายงานช่องโหว่ไปยัง Apache Software Foundation (CSRB)
• 5–6 ธ.ค.: Apache commit การแก้ไขและติดแท็ก release candidate 2.15.0-rc1 (CSRB)
• 9 ธ.ค.: โพสต์บน WeChat แสดงภาพหน้าจอ proof-of-concept exploit ที่ปิดบังบางส่วน ตามมาด้วยรายงานการโจมตีจริงในที่สาธารณะ (CSRB)
• 10 ธ.ค.: Apache ออกเวอร์ชัน 2.15.0 และ CVE ถูกเปิดเผยต่อสาธารณะ CISA ออกแถลงการณ์ (CSRB) และเพิ่ม CVE นี้ลงใน Known Exploited Vulnerabilities catalog ในวันเดียวกัน (NVD)
• 13 และ 16 ธ.ค.: มี CVE ตามมาอีกสองรายการ CVE-2021-45046 แสดงว่าการแก้ไขใน 2.15.0 ยังไม่ครบในบาง configuration ที่ไม่ใช่ค่าเริ่มต้น และ CVE-2021-45105 เป็นช่องโหว่ denial of service (CISA AA21-356A, Apache) NVD ระบุว่า 2.15.0 ปิดพฤติกรรมอันตรายนี้เป็นค่าเริ่มต้นแล้ว และตั้งแต่ 2.16.0 ฟังก์ชันนี้ถูกนำออกทั้งหมด
• 17 ธ.ค.: CISA ออก Emergency Directive 22-02 ถึงหน่วยงานพลเรือนของรัฐบาลกลางสหรัฐฯ (แนวทางของ CISA)
• 22 ธ.ค.: CISA, FBI, NSA และหน่วยงานพันธมิตรในออสเตรเลีย แคนาดา นิวซีแลนด์ และสหราชอาณาจักร ออก joint advisory AA21-356A
• กรกฎาคม 2565: CSRB เรียก Log4j ว่าเป็น "endemic vulnerability" ซึ่งเวอร์ชันที่มีช่องโหว่อาจยังคงอยู่ในระบบต่าง ๆ ไปอีกสิบปีหรือนานกว่านั้น

ระบบป้องกันเครือข่ายช่วยได้ตรงไหน

การโจมตีมีสองขั้น ขั้นแรก string ที่เป็นอันตรายเข้ามา ขั้นที่สอง เซิร์ฟเวอร์ที่มีช่องโหว่เชื่อมต่อออกไปดึงโค้ดของผู้โจมตี advisory ของ Palo Alto Networks อธิบายการป้องกันระดับเครือข่ายตามสองขั้นนี้พอดี signature ของ Threat Prevention ใช้บล็อกขั้นแรกของการโจมตี ส่วน egress filtering ที่เหมาะสมเป็นกุญแจสำคัญในการบล็อกขั้นที่สอง advisory แนะนำให้ใช้ App-ID บล็อก ldap และ rmi-iiop ทั้งขาเข้าและขาออกจากเครือข่ายที่ไม่น่าเชื่อถือ ระบุว่าต้องเปิด SSL decryption จึงจะบล็อกการโจมตีที่รู้จักผ่าน HTTPS ได้ และย้ำว่าไม่ควรพึ่ง signature เพียงอย่างเดียว (PAN-SA CVE-2021-44228)

joint advisory ของ CISA ให้คำแนะนำเรื่อง egress ในแนวเดียวกัน คือบล็อก LDAP และ RMI ขาออก หรืออนุญาตเฉพาะปลายทางที่รู้ว่าปลอดภัย และบล็อก DNS ขาออกจากเครื่องอื่นนอกจาก DNS resolver ขององค์กรเอง CSRB พบว่าผู้ดูแลระบบที่ยังอัปเกรดทันทีไม่ได้ ใช้ egress filtering, กฎบน WAF และการลบคลาส JndiLookup เป็นมาตรการชั่วคราว

ตรงไหนที่ช่วยไม่ได้

• Signature ไล่ตาม string CISA เตือนว่ามีหลายวิธีในการอำพราง exploit string และการบล็อก IP ของผู้โจมตีทำให้เกิด false positive จำนวนมาก
• การเข้ารหัสซ่อนขั้นแรกไว้ ถ้าไม่ถอดรหัส IPS จะมองไม่เห็น string ที่อยู่ใน HTTPS request
• สัญญาณรบกวน การสแกนของนักวิจัยแยกได้ยากจากการโจมตีจริง ห้าวันหลังการเปิดเผย Cloudflare พบความพยายามโจมตี 400 ครั้งต่อวินาที (CSRB) CISA จึงแนะนำให้มองหาร่องรอยการโจมตีที่สำเร็จ มากกว่าการสแกน
• มาตรการเครือข่ายไม่ได้แก้โค้ด CISA ระบุว่าการแพตช์ Java ไม่เพียงพอ ต้องอัปเกรดไลบรารี Log4j เอง และรายการใน catalog ของ CISA กำหนดให้หน่วยงานรัฐบาลกลางอัปเดตหรือนำสินทรัพย์ที่ได้รับผลกระทบออกจากเครือข่ายภายในวันที่ 24 ธันวาคม 2564 โดยยอมรับมาตรการชั่วคราวเฉพาะในช่วงที่ยังไม่มีอัปเดตเท่านั้น (NVD)

บทเรียนที่ผมได้

1. เซิร์ฟเวอร์ควรมี egress แบบ default-deny เซิร์ฟเวอร์ที่ไม่เคยต้องใช้ LDAP หรือ RMI ออกไปยังอินเทอร์เน็ต ก็ไม่ควรทำได้ครับ egress filtering ทำงานกับการเชื่อมต่อขาออก ไม่ได้ทำงานกับตัว string ซึ่งเป็นเหตุผลที่ทั้ง Palo Alto Networks และ CISA แนะนำมาตรการนี้
2. การตรวจต้องมองเห็นทราฟฟิก threat prevention บนทราฟฟิกเข้ารหัสที่ไม่ได้ถอดรหัส เป็นเพียงความหวัง ไม่ใช่มาตรการควบคุม
3. Signature ช่วยซื้อเวลา การอัปเกรดคือการปิดปัญหา ให้มอง IPS เป็นสะพานไปสู่การแพตช์
4. รู้ว่าตัวเองใช้อะไรอยู่ CSRB พบว่าองค์กรที่รับมือได้ดีที่สุดคือองค์กรที่รู้ว่าใช้ Log4j อยู่ที่ไหนและมีการจัดการสินทรัพย์ที่เป็นระบบ ข้อเสนอแนะของรายงานจึงรวมถึงการมีบัญชีสินทรัพย์และแอปพลิเคชันที่ถูกต้อง และเครื่องมือ SBOM ที่ดีขึ้น
5. ถ้ามีช่องโหว่และเปิดสู่ภายนอก ให้ถือว่าถูกเจาะแล้ว CISA แนะนำให้ถือว่าสินทรัพย์ที่มีหรือสงสัยว่ามีช่องโหว่ถูกเจาะแล้ว และตรวจสอบอย่างละเอียด

คำแนะนำเหล่านี้ไม่ใช่เรื่องใหม่ครับ Log4Shell เพียงแสดงให้เห็นในวงกว้างว่าชั้นป้องกันใดยืนหยัดได้ และชั้นใดไม่ได้

เมื่อมองย้อนกลับไป สิ่งที่ผมว่ามีประโยชน์ที่สุดคือแหล่งข้อมูลทั้งหมดแบ่งปัญหาไว้ชัดเจนมากครับ ทั้ง advisory ของผู้ผลิต joint advisory ของหน่วยงานรัฐ และรายงานของ CSRB พูดเรื่องเดียวกันด้วยถ้อยคำต่างกัน คือมาตรการเครือข่ายช่วยชะลอการโจมตีและทำให้ขั้นที่สองล้มเหลวได้ แต่มีเพียงการอัปเกรดไลบรารีเท่านั้นที่ปิดช่องโหว่ได้จริง ถ้าต้องอธิบาย Log4Shell ให้วิศวกรใหม่ฟังในประโยคเดียว ผมก็จะพูดแบบนี้

แหล่งข้อมูล

• NVD: CVE-2021-44228 (คำอธิบาย คะแนน CVSS และรายการใน CISA KEV)
• Apache Log4j: หน้า security
• Unit 42: Apache log4j vulnerability CVE-2021-44228
• Palo Alto Networks security advisory: CVE-2021-44228
• CISA, FBI, NSA และหน่วยงานพันธมิตร: joint advisory AA21-356A
• CISA: Apache Log4j vulnerability guidance
• Cyber Safety Review Board: Review of the December 2021 Log4j Event (กรกฎาคม 2565, PDF)