mergebase/log4j-detectorफ़ाइल-सिस्टम स्कैनर जो संकलित जावा क्लासेज़ (nested archives सहित) का विश्लेषण करके कमजोर Log4J संस्करणों (CVE-2021-44228, CVE-2021-45046) का पता लगाता है। लिनक्स, विंडोज़ और मैक पर काम करता है।
स्कैनर जो कमजोर Log4J संस्करणों का पता लगाता है, ताकि टीमों को CVE-2021-44228 (गंभीर), CVE-2021-45046, CVE-2021-45105, और CVE-2021-44832 के प्रति अपने जोखिम का आकलन करने में मदद मिल सके। यह पूर्ण फ़ाइल-सिस्टम, जिसमें सभी स्थापित एप्लिकेशन शामिल हैं, की सावधानीपूर्वक जांच करके Log4J इंस्टेंस खोज सकता है। यह कई परतों में छिपे Log4J इंस्टेंस को भी ढूँढने में सक्षम है। Linux, Windows, और Mac पर काम करता है, और उन सभी जगहों पर भी जहाँ Java चलता है!
log4j-core लाइब्रेरी के विरुद्ध हिट की रिपोर्ट करता है। log4j-api के बारे में क्या?वर्तमान में log4j-core संस्करण 2.3.2, 2.12.4, और 2.17.1 को _SAFE_ के रूप में, 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0, और 2.17.0 को _OKAY_ के रूप में, और अन्य सभी संस्करणों को _VULNERABLE_ के रूप में रिपोर्ट करता है (हालांकि यह पूर्व-2.0-beta9 को _POTENTIALLY_SAFE_ के रूप में रिपोर्ट करता है)। यह पुराने log4j-1.x संस्करणों को _OLD_ के रूप में रिपोर्ट करता है।
यह executable spring-boot jars/wars, uber jars में मिश्रित निर्भरताओं, shaded jars, और यहाँ तक कि फ़ाइल-सिस्टम पर बिना संपीड़न के पड़े exploded jar फ़ाइलों (उर्फ *.class) में log4j का सही-सही पता लगा सकता है।
हम वर्तमान में परीक्षण के लिए उपयोग किए जाने वाले log4j-samples का एक संग्रह बनाए रखते हैं।
java -jar log4j-detector-2021.12.29.jar ./samples
-- github.com/mergebase/log4j-detector v2021.12.29 (by mergebase.com) analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
false-hits/log4j-core-2.12.2.jar contains Log4J-2.x == 2.12.2 _OKAY_
false-hits/log4j-core-2.12.3.jar contains Log4J-2.x == 2.12.3 _OKAY_
false-hits/log4j-core-2.12.4.jar contains Log4J-2.x == 2.12.4 _SAFE_
false-hits/log4j-core-2.15.0.jar contains Log4J-2.x == 2.15.0 _OKAY_
false-hits/log4j-core-2.16.0.jar contains Log4J-2.x == 2.16.0 _OKAY_
false-hits/log4j-core-2.17.0.jar contains Log4J-2.x == 2.17.0 _OKAY_
false-hits/log4j-core-2.17.1.jar contains Log4J-2.x >= 2.17.1 _SAFE_
false-hits/log4j-core-2.3.1.jar contains Log4J-2.x == 2.3.1 _OKAY_
false-hits/log4j-core-2.3.2.jar contains Log4J-2.x == 2.3.2 _SAFE_
true-hits/log4j-core-2.0-beta9.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_
true-hits/log4j-core-2.10.0.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_
true-hits/log4j-core-2.10.0.zip contains Log4J-2.x >= 2.10.0 _VULNERABLE_
true-hits/log4j-core-2.11.0.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_
true-hits/log4j-core-2.11.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_
true-hits/log4j-core-2.11.2.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_
true-hits/log4j-core-2.12.0.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_
true-hits/log4j-core-2.12.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_
true-hits/log4j-core-2.14.0.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_
true-hits/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_
true-hits/log4j-core-2.2.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_
true-hits/log4j-core-2.3.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_
true-hits/log4j-core-2.4.1.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_
true-hits/log4j-core-2.4.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_
true-hits/log4j-core-2.9.1.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_
old-hits/log4j-1.1.3.jar contains Log4J-1.x <= 1.2.17 _OLD_
old-hits/log4j-1.2.17.jar contains Log4J-1.x <= 1.2.17 _OLD_
old-hits/log4j-core-2.0-beta2.jar contains Log4J-2.x <= 2.0-beta8 _POTENTIALLY_SAFE_ (Did you remove JndiLookup.class?)
_VULNERABLE_ -> आपको इस फ़ाइल को अपग्रेड करने या हटाने की आवश्यकता है।
_OKAY_ -> हम इसे Log4J संस्करण 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0, और 2.17.0 के लिए रिपोर्ट करते हैं। हम 2.17.1 में अपग्रेड करने की सलाह देते हैं।
_SAFE_ -> हम वर्तमान में इसे केवल Log4J संस्करण 2.3.2, 2.12.4, और 2.17.1 (और उससे ऊपर) के लिए रिपोर्ट करते हैं।
_OLD_ -> आप CVE-2021-44228 से सुरक्षित हैं, लेकिन आपको अपग्रेड करने की योजना बनानी चाहिए क्योंकि Log4J 1.2.x 7 वर्षों से EOL है और इसमें कई ज्ञात कमजोरियाँ हैं।
_POTENTIALLY_SAFE_ -> "JndiLookup.class" फ़ाइल मौजूद नहीं है, या तो क्योंकि आपका Log4J संस्करण बहुत पुराना है (पूर्व-2.0-beta9), या क्योंकि किसी ने पहले ही इस फ़ाइल को हटा दिया है। सुनिश्चित करें कि आपकी टीम या कंपनी के किसी व्यक्ति ने "JndiLookup.class" हटाया है, यदि ऐसा है, क्योंकि हमलावर समझौता किए गए सिस्टम तक अतिरिक्त प्रतिस्पर्धी हमलावरों की पहुँच को रोकने के लिए स्वयं इस फ़ाइल को हटाने के लिए जाने जाते हैं।
java -jar log4j-detector-2021.12.29.jar
Usage: java -jar log4j-detector-2021.12.29.jar [--verbose] [--json] [--stdin] [--exclude=X] [paths to scan...]
--json - STDOUT परिणामों को JSON में आउटपुट करें। (त्रुटियाँ/चेतावनियाँ अभी भी STDERR पर उत्सर्जित होती हैं)
--stdin - अन्वेषण करने के लिए STDIN से पथ पढ़ें (प्रति पंक्ति एक पथ)
--exclude=X - जहाँ X एक JSON सूची है जिसमें बहिष्कृत करने के लिए पूर्ण पथ शामिल हैं। यह मान्य JSON होना चाहिए।
उदाहरण: --exclude='["/dev", "/media", "Z:\TEMP"]'
निकास कोड: 0 = कोई कमजोर Log4J संस्करण नहीं मिला।
1 = कम से कम एक विरासत Log4J 1.x संस्करण मिला।
2 = कम से कम एक कमजोर Log4J संस्करण मिला।
के बारे में - MergeBase log4j detector (संस्करण 2021.12.29)
दस्तावेज़ - https://github.com/mergebase/log4j-detector
(C) कॉपीराइट 2021 Mergebase Software Inc. आपको GPLv3 के माध्यम से लाइसेंस प्राप्त।
git clone https://github.com/mergebase/log4j-detector.git
cd log4j-detector/
mvn install
java -jar target/log4j-detector-latest.jar
हम log4j नमूनों का एक संग्रह यहाँ बनाए रखते हैं: https://github.com/mergebase/log4j-samples
GPL संस्करण 3.0
Java कंपाइलर स्ट्रिंग लिटरल को सीधे संकलित *.class फ़ाइलों में संग्रहीत करता है। यदि log4j-detector आपके फ़ाइल-सिस्टम पर "JndiManager.class" नाम की फ़ाइल का पता लगाता है, तो यह इस स्ट्रिंग के लिए उस फ़ाइल की जाँच करता है: "Invalid JNDI URI - {}". पता चलता है कि वह विशिष्ट स्ट्रिंग लिटरल केवल Log4J के पैच किए गए संस्करण (संस्करण 2.15.0) में मौजूद है। Log4J के कोई भी संस्करण जिनमें वह स्ट्रिंग नहीं है, कमजोर हैं।
*.class फ़ाइलों में स्ट्रिंग लिटरल की जाँच करने की यही तकनीक सुरक्षित संस्करणों 2.3.2, 2.12.4, और 2.17.1 का सटीक पता लगाने के लिए और विस्तारित की गई है।
log4j-core लाइब्रेरी के विरुद्ध हिट की रिपोर्ट करता है। log4j-api के बारे में क्या? कई स्कैनर (जिनमें GitHub का अपना Dependabot भी शामिल है) वर्तमान में "log4j-core" और "log4j-api" दोनों लाइब्रेरी को कमजोर बताते हैं। ये स्कैनर गलत हैं। वर्तमान में "log4j-api" लाइब्रेरी का कोई मौजूदा संस्करण नहीं है जिसका इनमें से किसी भी कमजोरी द्वारा शोषण किया जा सके।
MergeBase में हम अपनी स्कैन सटीकता पर गर्व करते हैं। आप पहले से ही अपने सिस्टम को पैच और बचाव करने में काफी व्यस्त हैं। हम नहीं चाहते कि आप झूठी सकारात्मकता पर अपना समय बर्बाद करें। इसलिए हम log4j-api के विरुद्ध कोई हिट रिपोर्ट नहीं करते हैं।
संस्करण 2.10.0 महत्वपूर्ण है क्योंकि यह पहला संस्करण है जहाँ Log4J की कमजोर "message lookup feature" को Log4J कॉन्फ़िगरेशन के माध्यम से अक्षम किया जा सकता है।
संस्करण 2.12.2 महत्वपूर्ण है क्योंकि यह Log4J का Java 7 संगत संस्करण है जो CVE-2021-44228 के प्रति कमजोर नहीं है।
संस्करण 2.15.0 और 2.16.0 महत्वपूर्ण हैं क्योंकि ये पहले संस्करण हैं जहाँ Log4J का डिफ़ॉल्ट आउट-ऑफ-द-बॉक्स कॉन्फ़िगरेशन CVE-2021-44228 के प्रति कमजोर नहीं है।
और संस्करण 2.3.2, 2.12.4, और 2.17.1 महत्वपूर्ण हैं क्योंकि वे हाल ही में खोजी गई CVE जैसे CVE-2021-45046 और CVE-2021-45105 के प्रति कमजोर नहीं हैं। हालाँकि ये बहुत कम गंभीर कमजोरियाँ हैं, हम अनुमान लगाते हैं कि हर कोई 2.3.2, 2.12.4, या 2.17.1 में से किसी एक को पैच करना चाहेगा।
"!" का अर्थ है कि log4j-detector ने एक zip संग्रह (जैसे, *.zip, *.ear, *.war, *.aar, *.jar) में प्रवेश किया। चूँकि zip फ़ाइलों में zip फ़ाइलें हो सकती हैं, एक एकल परिणाम में अपने परिणाम में एक से अधिक "!" संकेतक हो सकते हैं।
नोट: log4j-detector केवल zip संग्रह में पुनरावर्ती रूप से प्रवेश करता है। यह tar या gz या bz2 आदि में प्रवेश नहीं करता है। इसका मुख्य कारण यह है कि Java सिस्टम अक्सर jars के अंदर jars को निष्पादित करने के लिए कॉन्फ़िगर किए जाते हैं, लेकिन वे अन्य फ़ाइल स्वरूपों को निष्पादित करने के लिए कभी कॉन्फ़िगर नहीं किए जाते हैं (जहाँ तक मुझे पता है!)। और इसलिए *.tar.gz के अंदर एक log4j प्रति संभवतः चल रहे Java सिस्टम के लिए पहुँच योग्य नहीं है, और इसलिए, रिपोर्ट करने योग्य कमजोरी नहीं है।
दूसरा नोट: zips-inside-zips के लिए हमारा स्कैनर इनर-ज़िप को पूरी तरह से मेमोरी में (ByteArrayInputStream का उपयोग करके) लोड करता है, इससे पहले कि वह इसे स्कैन करने का प्रयास करे। यदि आपके सिस्टम पर अत्यधिक बड़े इनर-ज़िप हैं (जैसे, 1 GB या उससे अधिक), तो आपको Java को कुछ अतिरिक्त मेमोरी देने की आवश्यकता हो सकती है।
केवल Log4J 2.x (2.0-beta9 से 2.14.1 तक) के संस्करण CVE-2021-44228 के प्रति कमजोर हैं।
बढ़िया सवाल! चूँकि हम यहाँ Github पर पूरा स्रोत कोड (Java की सभी 2500 पंक्तियाँ) शामिल करते हैं, साथ ही इसे बनाने के चरण भी, और चूँकि इस उपकरण की कोई निर्भरता नहीं है, इसलिए कोड का ध्यानपूर्वक अध्ययन करने में आपको अधिक समय नहीं लगना चाहिए। यदि आप Maven पर भरोसा नहीं करते हैं, तो आप सीधे "src/main/java/com/mergebase/log4j" निर्देशिका में जा सकते हैं और "javac *.java" टाइप कर सकते हैं। वह भी काम करता है!
हम रिपॉजिटरी के मूल में रखे गए पूर्व-संकलित jar (./log4j-detector-2021.12.29.jar) पर MergeBase कोड साइनिंग कुंजी से हस्ताक्षर करते हैं। कृपया इसकी पुष्टि करने के लिए "jarsigner -verbose -verify log4j-detector-2021.12.29.jar" चलाएँ।
MergeBase एक SCA कंपनी (सॉफ्टवेयर कम्पोजिशन एनालिसिस) है जो वैंकूवर, कनाडा में स्थित है। हम Snyk, Sonatype, Blackduck आदि जैसी कंपनियों के समान हैं, इसमें हम कंपनियों को उनके सॉफ्टवेयर में कमजोर ओपन-सोर्स लाइब्रेरी का पता लगाने और प्रबंधित करने में मदद करते हैं। हमें देखें! हमारी सटीकता बहुत अच्छी है, भाषा समर्थन बहुत अच्छा है, और हम बहुत महंगे भी नहीं हैं: mergebase.com/pricing।
यदि कोई हमारे SCA उत्पाद का 2-सप्ताह का निःशुल्क परीक्षण लेता है तो हमें खुशी होगी! और यदि आप हमारे CEO ([email protected]) को "log4j-detector" विषय के साथ ईमेल करते हैं, तो हम आपके निःशुल्क परीक्षण को 4 सप्ताह तक बढ़ा देंगे।