TL; DR
บทความจาก Maven Central ที่เผยแพร่แล้ว io.github.davidtimur:c2-lab ได้เผยแพร่เวอร์ชันออกไปเก้าเวอร์ชัน โดยแปดเวอร์ชันนั้นได้เรียกใช้เพย์โหลดการเข้าถึงระยะไกลระหว่างการคอมไพล์โปรเจกต์ปลายทางใดๆ ก็ตามที่วางไฟล์ jar ไว้ในเส้นทางตัวประมวลผลคำอธิบายประกอบ ไม่จำเป็นต้องนำเข้าโค้ดแอปพลิเคชันใดๆ และไม่จำเป็นต้องอ้างอิงถึงไฟล์นั้นในบรรทัดซอร์สโค้ดใดๆ เลย ไม่มีสคริปต์การติดตั้ง ไม่มีฟังก์ชันหลังการติดตั้ง และไม่มีกลไกการทำงานใดๆ ที่เครื่องมือจะตรวจสอบได้
เวกเตอร์การเรียกใช้งานคือไฟล์ขนาด 46 ไบต์ไฟล์เดียวที่อยู่ภายในไฟล์ JAR: การลงทะเบียนผู้ให้บริการ Java ที่ระบุชื่อคลาสที่ใช้งานอินเทอร์เฟซดังกล่าว javax.annotation.processing.Processorคอมไพเลอร์ Java จะค้นหาการลงทะเบียนดังกล่าวโดยอัตโนมัติ เมื่อพบแล้ว javac สร้างอินสแตนซ์และรันคลาสเป็นส่วนหนึ่งของการคอมไพล์ตามปกติ นั่นหมายความว่าสภาพแวดล้อมการทำงานของเพย์โหลดคือเครื่องสร้างโปรแกรม และในขณะนี้เครื่องสร้างโปรแกรมกำลังทำสิ่งเดียวที่มันควรทำ
ตลอดการออกเวอร์ชันทั้งเก้าครั้ง ช่องทางการควบคุมและสั่งการได้รับการสร้างใหม่ถึงสามครั้ง: ครั้งแรกเป็น URL เรียกกลับที่ผู้ปฏิบัติงานจัดหาให้ จากนั้นเป็น reverse shell ผ่านอุโมงค์ TCP ของ ngrok จากนั้นเป็นช่องทางการสำรวจ HTTP ที่เส้นทางเปลี่ยนไปอีกสองครั้ง เวอร์ชันสุดท้ายได้ติดตั้งตัวจัดการความเชื่อถือ TLS ที่ไม่มีการดำเนินการใดๆ เป็นค่าเริ่มต้นของ JVM ยอมรับใบรับรองใด ๆ ตลอดระยะเวลาการคอมไพล์.
ไฟล์ดังกล่าวมีคำว่า "C2 Lab Payload" อยู่ในไฟล์ POM ของตัวเอง และมีใบอนุญาต MIT นอกจากนี้ยังเผยแพร่อยู่บน Maven Central ตลอดช่วงเวลาที่เราสังเกตการณ์ และ ถูกถอดออกไปแล้ว พร้อมกับส่วนประกอบทั้งหมด io.github.davidtimur กลุ่ม
กายวิภาคศาสตร์: คอมไพเลอร์ในฐานะเครื่องมือประมวลผล
เฟรมเวิร์กการประมวลผลคำอธิบายประกอบของ Java มีอยู่เพื่อให้ไลบรารีสามารถสร้างโค้ดได้ในระหว่างการคอมไพล์ ซึ่งเป็นกลไกเบื้องหลัง Lombok, Dagger และเครื่องมือ ORM และการแปลงข้อมูลเป็นรูปแบบอนุกรมอีกมากมาย ตัวประมวลผลจะประกาศตัวเองด้วยไฟล์ข้อความธรรมดาภายในไฟล์ jar:
META-INF/services/javax.annotation.processing.Processor
เนื้อหาของไฟล์นั้นในทุกเวอร์ชันที่ได้รับผลกระทบ ตรงตามต้นฉบับทุกประการ:
io.github.davidtimur.c2lab.C2ตัวประมวลผล
ไฟล์นี้มีโครงสร้างไบต์เหมือนกันทุกประการในเวอร์ชัน 1.0.1 ถึง 1.0.8, md5 7d2a08a5c8869a47eea9fa62487dfbe4. เวอร์ชัน 1.0.0 ไม่มีฟีเจอร์นี้
เมื่อ จาวัค เมื่อรันโปรแกรม มันจะสแกนเส้นทางตัวประมวลผลคำอธิบายประกอบเพื่อค้นหารายการบริการเหล่านี้ และโหลดสิ่งที่พบ ไม่จำเป็นต้องกล่าวถึงตัวประมวลผล ใส่คำอธิบายประกอบ หรือกำหนดค่าใดๆ ในโปรเจกต์ที่กำลังคอมไพล์ เพียงแค่มีอยู่ในเส้นทางก็เพียงพอแล้ว นี่คือคุณสมบัติที่ทำให้ JavacDoor แตกต่างจากรูปแบบห่วงโซ่อุปทานที่เครื่องมือส่วนใหญ่สร้างขึ้น:
install hook คือการประกาศใน manifest และ manifest ก็เป็นสิ่งแรกที่ทุกคนอ่าน ส่วน payload ที่ส่งมาตอน import อย่างน้อยก็อยู่ในซอร์สโค้ดที่อ่านได้ แต่การลงทะเบียนบริการนั้นไม่ใช่ทั้งสองอย่าง: มันเป็นเพียงชื่อไฟล์บวกกับบรรทัดเดียวที่ระบุชื่อคลาส และพฤติกรรมนั้นอยู่ใน bytecode ที่คอมไพล์แล้วซึ่งอยู่ห่างออกไปในไดเร็กทอรีอื่น
คลาสเพย์โหลดจะทำการสำรวจโฮสต์โดยการส่งคำสั่งออกไป ส่วนพูลค่าคงที่ของคลาสที่คอมไพล์แล้วนั้นประกอบด้วย... bin / sh /, whoami, uname -a, รหัสผ่าน บนเส้นทาง Unix และ Tasklist บนเส้นทาง Windows พร้อมกับ สตรีมข้อผิดพลาดการเปลี่ยนเส้นทาง เพื่อผสานเอาต์พุตข้อผิดพลาดของกระบวนการลูกเข้ากับสตรีมที่บันทึกไว้ เทมเพลต JSON สองแบบจะส่งผลลัพธ์ออกจากโฮสต์ — สัญญาณการลงทะเบียน:
{"host":"%s","os":"%s","user":"%s","dir":"%s"}
ประชากรมาจาก ชื่อโฮสต์ คำสั่งและ ชื่อระบบปฏิบัติการ, user.nameและ ผู้ใช้.ไดเร็ก คุณสมบัติของระบบ และฟังก์ชันเรียกกลับผลลัพธ์:
{"version":"%s","host":"%s","time":"%s","output":"%s"}
ตัวบ่งชี้ความคืบหน้าที่ปรากฏในผลลัพธ์ของคอมไพเลอร์นั้นตรงไปตรงมาอย่างผิดปกติ: [C2] การดำเนินการคอมไพล์เสร็จสมบูรณ์, [C2] ส่งการเรียกกลับ → HTTP , [C2] เปลือกที่เชื่อมต่อกับ .
เก้ารุ่น สามเจเนอเรชั่นของ C2
การเผยแพร่เหล่านี้ไม่ใช่สำเนาเก้าชุดของข้อมูลเดียวกัน แต่เป็นบันทึกการเปลี่ยนแปลง และการอ่านตามลำดับจะแสดงให้เห็นว่าช่องทางการสื่อสารได้รับการสร้างใหม่ในขณะที่เวกเตอร์การส่งยังคงที่
มีรายละเอียดสามอย่างในตารางนั้นที่ควรนำมากล่าวถึง เพราะแต่ละอย่างจะเปลี่ยนแปลงวิธีการอ่านชุดสิ่งประดิษฐ์นั้น
เวกเตอร์มาถึงที่ 1.0.1 ไม่ใช่ 1.0.2 เวอร์ชัน 1.0.0 มีตรรกะการสำรวจและการเรียกกลับแบบเดียวกัน แต่ไม่มีไฟล์บริการและไม่มีการนำเข้าการประมวลผลคำอธิบายประกอบ มันจะทำงานก็ต่อเมื่อมีการเรียกใช้เท่านั้น ตั้งแต่เวอร์ชัน 1.0.1 เป็นต้นไปจะมีไฟล์บริการและคลาสที่คอมไพล์แล้วจะมีการนำเข้า javax.annotation.processing.SupportedSourceVersionการประเมินใดๆ ที่เปรียบเทียบเวอร์ชันที่วางจำหน่ายสองเวอร์ชัน — 1.0.0 และ 1.0.2 — สรุปได้อย่างถูกต้องว่ามีบางอย่างเปลี่ยนแปลงไป แต่ระบุตำแหน่งที่เปลี่ยนแปลงผิดพลาด
เปลือกกลับด้านมีอยู่ในเวอร์ชันเดียวเท่านั้น เวอร์ชัน 1.0.2 ประกอบด้วย 0.tcp.ngrok[.]ioบรรทัดบันทึก [C2] เชลล์เชื่อมต่อกับ 0.tcp.ngrok[.]io:19823แบนเนอร์แบบอินเทอร์แอ็กทีฟ เปลือก c2และตัวยุติเฟรม __จบ__เวอร์ชัน 1.0.3 เป็นต้นไปไม่มีส่วนประกอบเหล่านั้น และเปลี่ยนไปใช้โฮสต์ HTTPS แทน การร้องขอให้ลบโดยระบุเฉพาะเวอร์ชันที่มีตั๋วแจ้งปัญหา จะอ้างถึงปลายทาง TCP ที่ใช้งานไม่ได้ ในขณะที่ไม่ได้กล่าวถึงช่องทาง HTTP ที่ใช้งานได้ ซึ่งมีอยู่ในเวอร์ชันต่อมาอีกหกเวอร์ชัน
เวอร์ชันสุดท้ายได้ลบการตรวจสอบการขนส่งออกไปแล้ว เวอร์ชัน 1.0.8 เพิ่มคลาสที่ใช้งานอินเทอร์เฟซนี้ javax.net.ssl.X509TrustManager ซึ่งวิธีการตรวจสอบใบรับรองนั้นไม่ได้ทำอะไรเลย โดยมีตัวตรวจสอบชื่อโฮสต์ที่ถูกต้องเสมอซึ่งลงทะเบียนผ่าน setDefaultHostnameVerifierและใน เชื่อถือทั้งหมด ขั้นตอนดังกล่าวจะติดตั้งทั้งสองอย่างเป็นค่าเริ่มต้นของ JVM ผลที่ได้คือ ตลอดกระบวนการคอมไพล์นั้น JVM จะยอมรับใบรับรองใดๆ จากโฮสต์ใดๆ ก็ได้ ไม่เพียงแต่สำหรับการรับส่งข้อมูลของเพย์โหลดเองเท่านั้น แต่ยังรวมถึงสิ่งอื่นๆ ที่การสร้างดำเนินการผ่าน TLS ในภายหลังด้วย
ช่องทาง HTTP ในทั้งหกเวอร์ชันที่ใช้งานนั้น มีโฮสต์เพียงตัวเดียวเป็นตัวกลาง: tableful-fervor-crazed.ngrok-free[.]devทุกคำขอจะมีส่วนหัว (header) อยู่ด้วย ngrok-skip-browser-warningซึ่งจะระงับหน้าคั่นกลางที่อุโมงค์ ngrok เวอร์ชันฟรีแสดงต่อเบราว์เซอร์ ชุดเส้นทางจะเปลี่ยนแปลงไปในแต่ละเวอร์ชัน — /ออก หายไปในเวอร์ชัน 1.0.7 และ /ซม สลับกับ /โพลล์ — แต่เจ้าภาพไม่เคยเปลี่ยน
การยกเว้นตนเองบอกว่า
ไฟล์ POM ทุกไฟล์ตั้งแต่เวอร์ชัน 1.0.1 เป็นต้นไปจะกำหนดอาร์กิวเมนต์คอมไพเลอร์สำหรับการสร้างอาร์ติแฟกต์นั้นๆ:
-โปรซี:ไม่มี
ธงนั้นจะปิดใช้งานการประมวลผลคำอธิบายประกอบ ผลของมันคือ precise: เมื่อโปรเจกต์ที่มีโปรเซสเซอร์ถูกคอมไพล์ โปรเซสเซอร์จะไม่ทำงาน
ธงนี้มีประโยชน์ใช้สอยทั่วไปโดยสิ้นเชิง โครงการที่จัดส่งตัวประมวลผลคำอธิบายประกอบมักต้องการหลีกเลี่ยงการใช้ตัวประมวลผลนั้นกับตัวเองในระหว่างการบูต และเอกสารประกอบเครื่องมือสร้างก็แนะนำเช่นนั้น หากพิจารณาเพียงอย่างเดียวแล้ว มันไม่ได้พิสูจน์อะไรเลย
เมื่อพิจารณาร่วมกับสิ่งที่โปรเซสเซอร์ทำแล้ว มันจะอธิบายถึงความไม่สมมาตรที่เฉพาะเจาะจง: โค้ดจะทำงานบนเครื่องของทุกคนที่คอมไพล์โดยใช้ไฟล์ต้นฉบับ ไม่ใช่บนเครื่องที่สร้างไฟล์ต้นฉบับนั้น ธงนี้ปรากฏในเวอร์ชันเดียวกับที่แนะนำไฟล์บริการ — 1.0.1 — และในทุกเวอร์ชันหลังจากนั้น ความสัมพันธ์ระหว่าง “เวอร์ชันที่เริ่มการทำงานในระหว่างการคอมไพล์” และ “เวอร์ชันที่ปิดการทำงานในระหว่างการคอมไพล์ในเครื่อง” เป็นสัญญาณวิเคราะห์ที่มีประโยชน์ที่สุดในชุดไฟล์ต้นฉบับ และสามารถมองเห็นได้ในไฟล์ POM ที่เป็นข้อความธรรมดาโดยไม่ต้องถอดรหัสอะไรเลย
เราสังเกตผลกระทบและหยุดอยู่แค่นั้น ไม่มีสิ่งใดในหลักฐานบ่งชี้ว่าเหตุใดจึงมีการปักธงขึ้น
มีข้อมูลเมตาอีกชิ้นหนึ่งที่ควรกล่าวถึง โดยส่วนใหญ่ก็เพื่อกำจัดมันทิ้งไป ไฟล์ POM ระบุชื่อโครงการว่า “C2 Lab Payload” อธิบายว่าเป็น “สิ่งประดิษฐ์จาก C2 lab payload” และอนุญาตให้ใช้งานภายใต้ลิขสิทธิ์ MIT การติดป้ายกำกับด้วยตนเองในลักษณะนี้บางครั้งถูกนำเสนอเป็นหลักฐานว่าแพ็กเกจนั้นเป็นงานวิจัยcise มากกว่าภัยคุกคามที่มีชีวิต และบางครั้งการตีความนั้นก็ถูกต้อง — นกคานารีที่ประกาศไว้แต่ไม่มีโครงสร้างพื้นฐานที่เข้าถึงได้นั้นเป็นวัตถุที่แตกต่างจากสิ่งนี้ มันไม่สามารถนำมาใช้ได้ในกรณีนี้ อิมแพลนต์ที่ใช้งานได้ซึ่งเผยแพร่ไปยังที่เก็บข้อมูลสาธารณะ สามารถเข้าถึงได้โดยผู้ใช้รายใดก็ได้ พร้อมโครงสร้างพื้นฐานขาออกที่ได้รับการสร้างใหม่สามครั้งตลอดเก้าเวอร์ชัน ถือเป็นความสามารถที่มีชีวิตโดยไม่คำนึงถึงว่าเมตาเดตาจะเรียกมันว่าอะไร ชื่อในไฟล์ POM ไม่ได้เปลี่ยนแปลงอะไรเกี่ยวกับสิ่งที่เกิดขึ้นบนเครื่องที่คอมไพล์กับมัน
ตัวบ่งชี้สำหรับเครื่องสร้างชิ้นงาน
หากโฮสต์สำหรับการสร้างโปรแกรมคอมไพล์โดยใช้ไฟล์ต้นฉบับนี้ หลักฐานจะอยู่ในบันทึกการสร้างโปรแกรมและข้อมูลการวัดระยะทางผ่านเครือข่าย แทนที่จะถูกฝังไว้ในดิสก์อย่างถาวร เพราะเพย์โหลดจะทำงานภายในกระบวนการคอมไพล์และสิ้นสุดการทำงานพร้อมกับกระบวนการนั้น
ในไฟล์ jar หรือแคชของที่เก็บข้อมูลในเครื่อง
META-INF/services/javax.annotation.processing.Processorการตั้งชื่อio.github.davidtimur.c2lab.C2Processor- ไฟล์บริการ md5
7d2a08a5c8869a47eea9fa62487dfbe4 - ชั้นเรียนภายใต้
io/github/davidtimur/c2lab/:C2Processor,C2Task,Taskและในเวอร์ชัน 1.0.8 คลาสภายในTask$1
ในผลลัพธ์การสร้าง
[C2] compile-time execution complete[C2] callback sent → HTTP[C2] callback failed:[C2] shell connected to- แบนเนอร์แบบอินเทอร์แอ็กทีฟ
c2-shellตัวจบเฟรม__END__
การวัดระยะทางระหว่างกระบวนการ
javacในฐานะผู้ปกครองของ/bin/sh -c(Unix) หรือตัวแปลคำสั่งของ Windows- คำสั่งสำหรับเด็ก
whoami,uname -a,pwd(ยูนิก) หรือtasklist(Windows) ถูกกำหนดให้เป็นลูกของขั้นตอนการคอมไพล์
ในระบบส่งข้อมูลทางไกลผ่านเครือข่าย
- การส่งออก TCP ไปยัง
0.tcp.ngrok[.]io:19823(เวอร์ชัน 1.0.2) - HTTPS ไปยัง
tableful-fervor-crazed.ngrok-free[.]devเส้นทาง/register,/cmd,/poll,/out(เวอร์ชัน 1.0.3 ถึง 1.0.8) - ส่วนหัวของคำขอ
ngrok-skip-browser-warning: true - ร้องขอหน่วยงานที่ตรงกัน
{"host":...,"os":...,"user":...,"dir":...}or{"version":...,"host":...,"time":...,"output":...}
ในการตั้งค่า
- ตัวแปรสภาพแวดล้อม
CALLBACK,CALLBACK_URLคุณสมบัติของระบบcallback.url
ข้อมูลเมตาของผู้เผยแพร่
- บัญชีกลุ่ม
io.github.davidtimurที่อยู่สำนักพิมพ์davudboi999@gmail[.]comกุญแจลงนามE520C345EF94423D
การสร้างระบบที่ใช้เวอร์ชัน 1.0.8 จำเป็นต้องตรวจสอบเพิ่มเติมอีกหนึ่งอย่าง เนื่องจากเวอร์ชันนั้นติดตั้งตัวจัดการความเชื่อถือแบบอนุญาตเป็นค่าเริ่มต้นทั่วทั้ง JVM ดังนั้นการเชื่อมต่อ TLS ใดๆ ที่เกิดขึ้นในภายหลังใน JVM เดียวกัน ไม่ว่าจะเป็นการแก้ไขการพึ่งพา การอัปโหลดอาร์ติแฟกต์ หรือขั้นตอนการปรับใช้ จะดำเนินการโดยไม่มีการตรวจสอบความถูกต้องของใบรับรอง การรับส่งข้อมูลจากช่วงเวลานั้นจึงไม่ควรสันนิษฐานว่าได้รับการตรวจสอบความถูกต้องแล้ว
เหตุใดอาร์ติแฟกต์ที่คอมไพล์แล้วจึงต้องการการสแกนที่แตกต่างกัน
JavacDoor เป็นกรณีทดสอบที่มีประโยชน์ เพราะมันสามารถหักล้างข้อสมมติฐานทั่วไปสองข้อได้ในคราวเดียว และความล้มเหลวทั้งสองข้อนี้ไม่ได้จำเพาะเจาะจงกับเครื่องมือของผู้จำหน่ายรายใดรายหนึ่ง
ข้อสันนิษฐานแรกคือ โค้ดที่เป็นอันตรายจะแสดงตัวออกมาในไฟล์ manifest เครื่องมือจัดการห่วงโซ่อุปทานจำนวนมากถูกจัดระเบียบโดยคำนึงถึงวงจรชีวิตของผลิตภัณฑ์ hooksเพราะสำหรับ npm และ PyPI นั่นคือจุดที่การทำงานมักเกิดขึ้น JavacDoor ไม่มี hook ตัวกระตุ้นของมันคือไฟล์ลงทะเบียนบริการที่มีชื่อเป็นอินเทอร์เฟซ Java และเนื้อหาเป็นชื่อคลาส ในการดักจับสิ่งนั้นแบบ static คุณต้องจัดการ META-INF/services/javax.annotation.processing.Processor ในฐานะจุดเริ่มต้นการดำเนินการที่มีความสำคัญในตัวเอง เทียบเท่ากับ หลังการติดตั้ง เขียนสคริปต์ — แล้วจึงตามชื่อคลาสเข้าไปในไบต์โค้ด ระบบนิเวศแต่ละระบบมีกลไกการค้นหาอัตโนมัติในรูปแบบนี้ และแต่ละระบบถือเป็นจุดเริ่มต้น ไม่ว่าเครื่องมือจะระบุว่าเป็นจุดเริ่มต้นหรือไม่ก็ตาม
ข้อสมมติฐานข้อที่สองคือ สตริงต่างๆ อยู่ในไฟล์ต้นฉบับ สำหรับไฟล์ JAR นั้น เอนด์พอยต์ คำสั่งเชลล์ เทมเพลต JSON และตัวบ่งชี้บันทึก ล้วนอยู่ในพูลคงที่ของ .ระดับ ไฟล์ต่างๆ เครื่องมือที่ใช้ grep ค้นหาข้อความไม่พบอะไรเลย ไม่ใช่เพราะสตริงถูกเข้ารหัส แต่เพราะมันอยู่ในคอนเทนเนอร์ไบนารีที่มีโครงสร้างซึ่งการสแกนข้อความไม่สามารถแยกวิเคราะห์ได้ ตัวบ่งชี้เครือข่ายทุกตัวในโพสต์นี้ได้มาจากการแยกวิเคราะห์พูลค่าคงที่ หนึ่งในนั้นเป็นข้อมูลที่สมบูรณ์ https:// URL ปรากฏให้เห็นได้ชัดเจนภายในไฟล์คลาส การสแกนข้อความของเนื้อหาที่อ่านได้ในไฟล์ JAR ก็ยังไม่สามารถแสดง URL นั้นได้ ไม่มีการเข้ารหัสใดๆ ที่ต้องเอาชนะ มีเพียงรูปแบบคอนเทนเนอร์ที่ต้องอ่านเท่านั้น
ช่องว่างทั้งสองมีรูปร่างเหมือนกัน: รูปแบบของอาร์ติแฟกต์ถูกมองว่าเป็นเพียงถุงไฟล์ แทนที่จะเป็นโครงสร้างที่มีความหมายที่กำหนดไว้ วิธีแก้ไขนั้นไม่น่าดึงดูดใจนัก — คือ การวิเคราะห์คอนเทนเนอร์ การระบุจุดเริ่มต้นการค้นหาอัตโนมัติของระบบนิเวศ และติดตามจุดเหล่านั้นเข้าไปในโค้ดที่คอมไพล์แล้ว สำหรับเวกเตอร์ในระหว่างการสร้างโดยเฉพาะ การตรวจสอบครั้งที่สามนั้นง่ายและให้การวินิจฉัยที่น่าประหลาดใจ: เปรียบเทียบสิ่งที่อาร์ติแฟกต์ทำกับผู้ใช้งานกับสิ่งที่มันยกเว้นตัวเอง อาร์ติแฟกต์ที่ลงทะเบียนโปรเซสเซอร์ในระหว่างการคอมไพล์และในขณะเดียวกันก็ปิดใช้งานการประมวลผลในระหว่างการคอมไพล์สำหรับการสร้างของตัวเองนั้นได้บอกอะไรบางอย่างเกี่ยวกับตัวมันเองในไฟล์ POM แบบข้อความธรรมดาเพียงสองบรรทัด
สำหรับทีมที่ใช้งาน Maven artifacts ในปัจจุบัน มีมาตรการปฏิบัติสามประการดังต่อไปนี้:
- ให้ถือว่าเส้นทางการประมวลผลคำอธิบายประกอบเป็นขอบเขตการดำเนินการ ส่วนประกอบที่เกี่ยวข้องจะเรียกใช้โค้ดในการสร้างของคุณ ในกรณีที่การสร้างไม่จำเป็นต้องมีการประมวลผลคำอธิบายประกอบ -โปรซี:ไม่มี มีประโยชน์ในเชิงป้องกันเช่นเดียวกับที่ปรากฏในพื้นที่นี้ โดยในกรณีที่ใช้ ให้กำหนดชุดโปรเซสเซอร์อย่างชัดเจนแทนที่จะสืบทอดจากคลาสพาธการคอมไพล์
- บันทึกกระบวนการย่อยของคอมไพเลอร์ ขั้นตอนการคอมไพล์ที่เรียกใช้เชลล์นั้นเป็นเรื่องผิดปกติในโปรเจกต์ส่วนใหญ่ และสามารถแจ้งเตือนได้อย่างง่ายดาย
- อย่าถือว่าข้อมูลเมตาเป็นหลักฐาน คำว่า “Lab”, “test”, “payload” และ “PoC” ในชื่อหรือคำอธิบายของแพ็กเกจ ไม่ใช่ข้อจำกัดของขอบเขต แต่การเข้าถึงได้และพฤติกรรมต่างหากที่เป็นข้อจำกัด
วัตถุโบราณและกลุ่มวัตถุทั้งหมดถูกนำออกจากพื้นที่ Maven จากรายงานของเรา ศูนย์กลางได้แจ้งว่าทั้งเส้นทางของอาร์ติแฟกต์และเส้นทางของกลุ่มต่างส่งคืนค่า 404 และดัชนีศูนย์กลางรายงานว่าไม่มีพิกัดที่ตรงกัน นั่นทำให้ปิดอาร์ติแฟกต์นี้ไปแล้ว แต่ไม่ได้ปิดเวกเตอร์ ซึ่งเป็นคุณสมบัติที่ได้รับการบันทึกไว้ของคอมไพเลอร์ Java และพร้อมใช้งานสำหรับทุกคนที่เผยแพร่ไฟล์ jar
อ้างอิง
บทความนี้ไม่ได้อ้างอิงแหล่งข้อมูลภายนอกใดๆ ข้อมูลทั้งหมดได้มาจากการวิเคราะห์แบบคงที่ (static analysis) ของไฟล์ JAR ที่เผยแพร่แล้วทั้ง 9 ไฟล์ ซึ่งดึงมาจาก Maven Central ก่อนที่จะถูกลบออกไป ไม่มีการเรียกใช้โค้ดใดๆ จากไฟล์เหล่านั้นเลย
