เมื่อไม่กี่สัปดาห์ก่อน ข่าวเกี่ยวกับปัญหาด้านความปลอดภัยของ Log4j ทำให้ผู้ใช้หลายรายบนเครือข่ายกลับหัวกลับหาง และนี่คือหนึ่งในข้อบกพร่องที่มีการใช้ประโยชน์มากที่สุด และผู้เชี่ยวชาญหลายคนระบุว่า «ที่อันตรายที่สุดใน มานาน », จากช่องโหว่ที่ประกาศในเครือข่ายเราพูดถึงบางส่วนของพวกเขา ที่นี่ในบล็อก และครั้งนี้เราได้พบข่าวของอีกท่านหนึ่งแล้ว
และเมื่อไม่กี่วันก่อน ข่าวออกมาว่ามีการระบุช่องโหว่อื่นในห้องสมุด Log4j 2 (ซึ่งอยู่ภายใต้ CVE-2021-45105 แล้ว) และซึ่งไม่เหมือนกับสองประเด็นก่อนหน้านี้ ซึ่งจัดอยู่ในประเภทอันตรายแต่ไม่สำคัญ
ปัญหาใหม่ ยอมให้การปฏิเสธการบริการและแสดงออกในรูปแบบของการวนซ้ำและการสิ้นสุดที่ผิดปกติ เมื่อประมวลผลบางบรรทัด
ช่องโหว่ ส่งผลกระทบต่อระบบที่ใช้การค้นหาบริบท เช่น $ {ctx: var}เพื่อกำหนดรูปแบบเอาต์พุตบันทึก
ลา Log4j เวอร์ชัน 2.0-alpha1 ถึง 2.16.0 ขาดการป้องกันจากการเรียกซ้ำที่ไม่มีการควบคุม, อะไร อนุญาตให้ผู้โจมตีจัดการกับค่าที่ใช้ในการทดแทน เพื่อทำให้เกิดการวนซ้ำไม่รู้จบที่จะไม่มีเนื้อที่บนสแต็กและทำให้กระบวนการหยุดทำงาน โดยเฉพาะอย่างยิ่ง ปัญหาเกิดขึ้นเมื่อแทนที่ค่าเช่น "$ {$ {:: - $ {:: - $$ {:: - j}}}}"
นอกจากนี้ สังเกตได้ว่านักวิจัย Blumira ได้เสนอให้โจมตีแอปพลิเคชัน Java ที่มีช่องโหว่ ที่ไม่รับคำขอจากเครือข่ายภายนอก เช่น ระบบของนักพัฒนาหรือผู้ใช้แอปพลิเคชัน Java สามารถโจมตีได้ด้วยวิธีนี้
สาระสำคัญของวิธีการคือ หากมีกระบวนการ Java ที่เปราะบาง บนระบบของผู้ใช้ที่ยอมรับการเชื่อมต่อเครือข่ายจากโลคัลโฮสต์เท่านั้น (localhost) หรือประมวลผลคำขอ RMI (Remote Method Invocation, พอร์ต 1099) การโจมตีสามารถทำได้โดยรันโค้ด JavaScript เมื่อผู้ใช้เปิดหน้าที่เป็นอันตรายในเบราว์เซอร์ ในการสร้างการเชื่อมต่อกับพอร์ตเครือข่ายของแอปพลิเคชัน Java ในการโจมตีดังกล่าว มีการใช้ WebSocket API ซึ่งไม่เหมือนกับคำขอ HTTP ที่ไม่มีการใช้ข้อจำกัดที่มาเดียวกัน (WebSocket สามารถใช้สแกนพอร์ตเครือข่ายในเครื่องได้ โฮสต์เพื่อตรวจสอบไดรเวอร์เครือข่ายที่มีอยู่)
ผลการประเมินช่องโหว่ของไลบรารีที่เกี่ยวข้องกับการขึ้นต่อกันกับ Log4j ที่เผยแพร่โดย Google ก็เป็นที่น่าสนใจเช่นกัน จากข้อมูลของ Google ปัญหาดังกล่าวส่งผลกระทบต่อ 8% ของแพ็คเกจทั้งหมดในที่เก็บ Maven Central
โดยเฉพาะอย่างยิ่ง แพ็คเกจ Java ที่เกี่ยวข้องกับ Log35863j จำนวน 4 รายการที่มีการขึ้นต่อกันทางตรงและทางอ้อมมีความเสี่ยง ในทางกลับกัน Log4j ถูกใช้เป็นการพึ่งพาโดยตรงของระดับแรกเฉพาะใน 17% ของกรณีและใน 83% ของแพ็คเกจที่ครอบคลุมโดยช่องโหว่ การผูกจะทำผ่านแพ็คเกจระดับกลางที่ขึ้นอยู่กับ Log4j นั่นคือบอก การพึ่งพาของระดับที่สองและสูงสุด (21% - ระดับที่สอง, 12% - ที่สาม, 14% - ที่สี่, 26% - ที่ห้า, 6% - ที่หก)
ความเร็วในการซ่อมแซมช่องโหว่ยังคงเป็นที่ต้องการอย่างมาก หนึ่งสัปดาห์หลังจากระบุช่องโหว่ จากแพ็คเกจที่ระบุ 35863 รายการ ปัญหาได้รับการแก้ไขแล้วใน 4620 เท่านั้น นั่นคือที่ 13%
การเปลี่ยนแปลงแพ็กเกจมีความจำเป็นในการอัปเดตข้อกำหนดการพึ่งพาและแทนที่การโยงเวอร์ชันเก่าด้วยเวอร์ชันคงที่ของ Log4j 2 (แพ็กเกจ Java ฝึกการโยงกับเวอร์ชันเฉพาะ และไม่ใช่ช่วงเปิดที่อนุญาตให้ติดตั้งเวอร์ชันล่าสุด)
การกำจัดจุดอ่อนในแอปพลิเคชัน Java นั้นถูกขัดขวางโดยข้อเท็จจริงที่ว่าโปรแกรมต่างๆ มักจะมีสำเนาของไลบรารีในการจัดส่ง และไม่เพียงพอที่จะอัปเดตเวอร์ชัน Log4j 2 ในแพ็คเกจระบบ
ในขณะเดียวกัน U.S. Agency for Infrastructure Protection and Cybersecurity ได้ออกคำสั่งฉุกเฉินที่กำหนดให้หน่วยงานของรัฐบาลกลางต้องระบุระบบข้อมูลที่ได้รับผลกระทบจากช่องโหว่ของ Log4j และติดตั้งโปรแกรมปรับปรุงที่บล็อกปัญหา ก่อนวันที่ 23 ธันวาคม
ในทางกลับกัน ได้ให้แนวทางจนถึงวันที่ 28 ธันวาคม ซึ่งองค์กรมีหน้าที่ต้องรายงานเกี่ยวกับงานที่ทำ เพื่อลดความซับซ้อนในการระบุระบบที่มีปัญหาได้มีการเตรียมรายการผลิตภัณฑ์ที่ยืนยันการแสดงช่องโหว่ (มีแอปพลิเคชันมากกว่า 23 รายการในรายการ)
ในที่สุด เป็นมูลค่าการกล่าวขวัญว่าช่องโหว่ได้รับการแก้ไขใน Log4j 2.17 ซึ่งเผยแพร่เมื่อไม่กี่วันที่ผ่านมา และผู้ใช้ที่ปิดใช้งานการอัปเดตนั้นควรดำเนินการอัปเดตที่เกี่ยวข้อง นอกเหนือจากข้อเท็จจริงที่ว่าอันตรายของช่องโหว่นั้นบรรเทาลงได้ด้วยความจริงที่ว่าปัญหาปรากฏบนระบบที่มี Java 8 เท่านั้น
Fuente: https://logging.apache.org/