Log4J-शमन-CVE-2021-44228,CVE-2021-45046,CVE-2021-45105,CVE-2021-44832

कृपया इस पेज पर नज़र बनाए रखें क्योंकि Apache Log4j टीम बहुत अधिक CVE का खुलासा कर रही है और सुरक्षा समस्याओं को बहुत तेज़ी से ठीक कर रही है।

अपडेट - 28-Dec-2021

CVE-2021-44832: Apache Log4j2, JDBC Appender के माध्यम से RCE के लिए असुरक्षित है जब हमलावर कॉन्फ़िगरेशन को नियंत्रित करता है।

Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) और 2.3.2 (Java 6) में ठीक किया गया

अपडेट - 17-Dec-2021

रातोंरात, Apache द्वारा खुलासा किया गया कि Log4j संस्करण 2.16 भी डेनियल ऑफ सर्विस हमले के माध्यम से असुरक्षित है, जिसका प्रभाव पूर्ण एप्लिकेशन क्रैश है, इसकी गंभीरता को उच्च (7.5) के रूप में वर्गीकृत किया गया है, CVE-2021-45105 जारी किया गया है, और Apache द्वारा एक नया फिक्स्ड संस्करण (2.17) प्रकाशित किया गया है, जिसमें अपग्रेड करने की अनुशंसा की जाती है।

पृष्ठभूमि:

इंटरनेट पर Apache की Java के लिए लोकप्रिय Log4J लॉगिंग लाइब्रेरी में एक 0-day भेद्यता (जो रिमोट कोड निष्पादन करा सकती है) के बारे में चर्चा जोरों पर थी। यह विशेष भेद्यता–जिसे CVE-2021-44228 के रूप में ट्रैक किया गया है, जिसका CVSS स्कोर अधिकतम "क्रिटिकल" 10 है–Log4J की लुकअप क्षमता में निहित है, जो JNDI (Java Naming and Directory Interface) के साथ संयुक्त है। यह समस्या व्यापक है क्योंकि कई डेवलपर्स अनजान थे कि Log4J का उपयोग अनफ़िल्टर्ड इनपुट के साथ करना खतरनाक था।

सबसे महत्वपूर्ण प्रभाव यह है कि एक हमलावर लॉगर तक एक स्ट्रिंग पहुँचा सकता है, जिसे Log4J द्वारा संसाधित करने पर, मनमाना कोड निष्पादित होता है। इसके पहले उदाहरणों में ${jndi:ldap} पथ का उपयोग किया गया था, जो रिमोट URL से मनमाना कोड लोड करने का कारण बन सकता है। यह पथ नए Java रनटाइम के उपयोग से आंशिक रूप से शमित होता है जो डिफ़ॉल्ट रूप से URL-आधारित क्लास लोडर को ब्लॉक करते हैं। दुर्भाग्य से, Java का आधुनिक संस्करण शोषण को रोकने के लिए पर्याप्त नहीं हो सकता है, क्योंकि एप्लिकेशन स्वयं ऐसी क्लासेस उजागर कर सकता है जिनका उपयोग मनमाना कोड चलाने के लिए किया जा सकता है।

JNDI आर्किटेक्चर:

विभिन्न वातावरणों के लिए शमन उपाय:

अपडेट - 17-Dec-2021

सुरक्षा भेद्यता CVE-2021-45105

विवरण:

Apache Log4j2 संस्करण 2.0-alpha1 से 2.16.0 तक स्व-संदर्भित लुकअप से अनियंत्रित रिकर्सन से सुरक्षा प्रदान नहीं करते थे। जब लॉगिंग कॉन्फ़िगरेशन Context Lookup के साथ एक गैर-डिफ़ॉल्ट

Pattern Layout का उपयोग करता है (उदाहरण के लिए, $${ctx:loginId}), तो Thread Context Map (MDC) इनपुट डेटा पर नियंत्रण रखने वाले हमलावर दुर्भावनापूर्ण इनपुट डेटा तैयार कर सकते हैं जिसमें

एक रिकर्सिव लुकअप होता है, जिसके परिणामस्वरूप StackOverflowError उत्पन्न होता है जो प्रक्रिया को समाप्त कर देगा। इसे DOS (डेनियल ऑफ सर्विस) हमले के रूप में भी जाना जाता है।

शमन उपाय:

संस्करण 2.17.0 (Java 8 के लिए) से, केवल कॉन्फ़िगरेशन में लुकअप स्ट्रिंग्स रिकर्सिव रूप से विस्तारित होती हैं; किसी भी अन्य

उपयोग में, केवल शीर्ष-स्तरीय लुकअप हल किया जाता है, और कोई भी नेस्टेड लुकअप हल नहीं किया जाता है।

पिछले रिलीज़ में इस समस्या को यह सुनिश्चित करके कम किया जा सकता है कि आपकी लॉगिंग कॉन्फ़िगरेशन निम्न कार्य करती है:

लॉगिंग कॉन्फ़िगरेशन में PatternLayout में, ${ctx:loginId} या $${ctx:loginId} जैसे Context Lookups को Thread Context Map पैटर्न (%X, %mdc, या %MDC) से बदलें।

अन्यथा, कॉन्फ़िगरेशन में, ${ctx:loginId} या $${ctx:loginId} जैसे Context Lookups के संदर्भ हटा दें जहाँ वे एप्लिकेशन के बाहरी स्रोतों जैसे HTTP हेडर या उपयोगकर्ता इनपुट से उत्पन्न होते हैं।

अपडेट - 13-Dec-2021

** Log4j(रिलीज़ 2.16.0 – 2021-12-13) में दो बेहतर सुविधाएँ हैं :**

---------------!!मैसेज लुकअप डिफ़ॉल्ट रूप से अक्षम होने के कारण उपलब्ध नवीनतम संस्करण में अपग्रेड करने की अत्यधिक अनुशंसा की जाती है।!!------------

https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

JNDI को डिफ़ॉल्ट रूप से अक्षम करें। JNDI की अनुमति देने के लिए log4j2.enableJndi को true पर सेट करना आवश्यक है।

Message Lookups के लिए समर्थन पूरी तरह से हटाएँ

नया अपडेट:

------------------CVE-2021-45046-----------------

Apache Log4j2 Thread Context Message Pattern और Context Lookup Pattern एक डेनियल ऑफ सर्विस हमले के प्रति असुरक्षित हैं।

शमन उपाय:

Log4j 1.x शमन: यह भेद्यता Log4j 1.x को प्रभावित नहीं करती है।

Log4j 2.x शमन: नीचे दी गई शमन तकनीकों में से एक को लागू करें।

Java 8 (या बाद के) उपयोगकर्ताओं को रिलीज़ 2.16.0 में अपग्रेड करना चाहिए। Java 7 की आवश्यकता वाले उपयोगकर्ताओं को उपलब्ध होने पर रिलीज़ 2.12.2 में अपग्रेड करना चाहिए (कार्य प्रगति पर है, जल्द उपलब्ध होने की उम्मीद है)।

अन्यथा, क्लासपाथ से JndiLookup क्लास हटाएँ: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

ध्यान दें कि केवल log4j-core JAR फ़ाइल इस भेद्यता से प्रभावित होती है। केवल log4j-api JAR फ़ाइल का उपयोग करने वाले एप्लिकेशन, जिनमें log4j-core JAR फ़ाइल नहीं है, इस भेद्यता से प्रभावित नहीं होते हैं।

------------------CVE-2021-44228-------------------

शमन उपाय

Log4j 1.x शमन: Log4j 1.x में Lookups नहीं होते हैं इसलिए जोखिम कम है। Log4j 1.x का उपयोग करने वाले एप्लिकेशन केवल तभी इस हमले के प्रति असुरक्षित होते हैं जब वे अपने

कॉन्फ़िगरेशन में JNDI का उपयोग करते हैं। इस भेद्यता के लिए एक अलग CVE (CVE-2021-4104) दर्ज किया गया है। शमन के लिए: अपनी लॉगिंग कॉन्फ़िगरेशन की जाँच करें ताकि यह सुनिश्चित हो कि कोई JMSAppender कॉन्फ़िगर नहीं है।

JMSAppender के बिना Log4j 1.x कॉन्फ़िगरेशन इस भेद्यता से प्रभावित नहीं होते हैं।

Log4j 2.x शमन: नीचे दी गई शमन तकनीकों में से एक को लागू करें।

Java 8 (या बाद के) उपयोगकर्ताओं को रिलीज़ 2.16.0 में अपग्रेड करना चाहिए।

Java 7 की आवश्यकता वाले उपयोगकर्ताओं को उपलब्ध होने पर रिलीज़ 2.12.2 में अपग्रेड करना चाहिए (कार्य प्रगति पर है, जल्द उपलब्ध होने की उम्मीद है)।

अन्यथा, क्लासपाथ से JndiLookup क्लास हटाएँ: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

ध्यान दें कि केवल log4j-core JAR फ़ाइल इस भेद्यता से प्रभावित होती है। केवल log4j-api JAR फ़ाइल का उपयोग करने वाले एप्लिकेशन, जिनमें log4j-core JAR फ़ाइल शामिल नहीं है, इस भेद्यता से प्रभावित नहीं होते हैं।

 1. Apache Log4j:
        रिलीज़ >=2.10** में और
        रिलीज़ >=2.0-beta9 और <=2.10.0 के लिए
        
2. pom.xml फिक्स:
 
3. Azure App Service (Windows और Linux):
 
4. कोई भी कंटेनरीकृत एप्लिकेशन:
 
5. Azure Functions:

6. Apache Log4j के लिए हॉटपैच

7. Defender for Cloud Log4j भेद्यताओं से प्रभावित मशीनों को कैसे ढूँढता है

8. Azure Sentinel और Azure WAF लॉग पर डिटेक्शन

9.Maven प्लग-इन कॉन्फ़िगरेशन जो भविष्य के बिल्ड में log4j2 असुरक्षित संस्करणों पर प्रतिबंध लगाता है

1. Apache Log4j:

CVE-2021-44228: Apache Log4j2 JNDI सुविधाएँ हमलावर-नियंत्रित LDAP और अन्य JNDI संबंधित एंडपॉइंट्स से सुरक्षा प्रदान नहीं करती हैं।

प्रभावित संस्करण: सभी log4j-core संस्करण >=2.0-beta9 और <=2.14.1 Apache Log4j <=2.14.1 में कॉन्फ़िगरेशन, लॉग संदेशों और पैरामीटरों में उपयोग की जाने वाली JNDI सुविधाएँ हमलावर-नियंत्रित LDAP और अन्य JNDI संबंधित एंडपॉइंट्स से सुरक्षा प्रदान नहीं करती हैं। जब मैसेज लुकअप प्रतिस्थापन सक्षम होता है, तो एक हमलावर जो लॉग संदेशों या लॉग संदेश पैरामीटरों को नियंत्रित कर सकता है, LDAP सर्वर से लोड किए गए मनमाने कोड को निष्पादित कर सकता है। Log4j 2.15.0 से, यह व्यवहार डिफ़ॉल्ट रूप से अक्षम कर दिया गया है।

रिलीज़ >=2.10 में**, इस व्यवहार को सिस्टम प्रॉपर्टी log4j2.formatMsgNoLookups या environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true सेट करके कम किया जा सकता है। रिलीज़ >=2.7 और <=2.14.1 के लिए, सभी PatternLayout पैटर्न को संशोधित किया जा सकता है ताकि मैसेज कन्वर्टर को सिर्फ %m के बजाय %m{nolookups} के रूप में निर्दिष्ट किया जा सके।

रिलीज़ >=2.0-beta9 और <=2.10.0 के लिए, शमन का तरीका क्लासपाथ से JndiLookup क्लास को हटाना है: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class।

2.pom.xml फिक्स:

pom.xml में निर्भरता को अपडेट करें और dependencies अनुभाग में उपलब्ध नवीनतम संस्करण के साथ बदलें: https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom

<dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->            
<!--         <version>2.17.0</version>-->
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->       
<!--         <version>2.17.0</version>-->
        </dependency>
    </dependencies>

संदर्भ: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18

3.Azure App Service (Windows और Linux):

यदि संभव हो, तो ग्राहकों को Log4j को संस्करण v2.15.0 में अपग्रेड करना चाहिए और एप्लिकेशन को फिर से डिप्लॉय करना चाहिए। यह प्राथमिक अनुशंसित शमन उपाय है। यदि आप अपने एप्लिकेशन को फिर से डिप्लॉय नहीं कर सकते हैं, तो Log4j संस्करण 2.10 और उससे अधिक में, आप सिस्टम प्रॉपर्टी "-Dlog4j2.formatMsgNoLookups=true" सेट करके इस व्यवहार को कम कर सकते हैं। App Service पर, आप JAVA_OPTS नाम की एक ऐप सेटिंग बनाकर इस प्रॉपर्टी को सेट कर सकते हैं जिसका मान "-Dlog4j2.formatMsgNoLookups=true" हो। JAVA_OPTS ऐप सेटिंग आपके Java एप्लिकेशन को शुरू होने पर पास की जाती है। यदि आपने पहले से JAVA_OPTS ऐप सेटिंग सेट की है, तो बस मौजूदा मान में "-Dlog4j2.formatMsgNoLookups=true" जोड़ दें। यदि आप Log4J संस्करण 2.9 या उससे कम का उपयोग कर रहे हैं, तो यह सिस्टम प्रॉपर्टी शमन काम नहीं करेगा और आपको v2.15.0 में अपग्रेड करना चाहिए।

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"

4.कोई भी कंटेनरीकृत एप्लिकेशन

• कंटेनरीकृत एप्लिकेशनों के लिए, यदि आप जिस Log4j 2 संस्करण का उपयोग कर रहे हैं वह 2.10.0 या उससे बाद का है, तो एक पर्यावरण चर या Java कमांड लाइन विकल्प है जिसका उपयोग आप असुरक्षित प्रतिस्थापन व्यवहार को अक्षम करने के लिए कर सकते हैं। आप यह पंक्ति जोड़ सकते हैं:

  root@kitploit:~

   ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
  

  Docker फ़ाइल संदर्भ: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile

• अपनी Dockerfile में, या आप अपने कंटेनर में चलाए जाने वाले कमांड में समतुल्य फ़्लैग "-Dlog4j.formatMsgNoLookups=true" जोड़ सकते हैं, उदाहरण के लिए:

  root@kitploit:~

   CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
  

• आप पर्यावरण चर को रनटाइम पर भी कॉन्फ़िगर कर सकते हैं, जो आसान हो सकता है, उदाहरण के लिए Kubernetes के लिए आप ये पंक्तियाँ अपने कॉन्फ़िगरेशन में जोड़ सकते हैं।

  root@kitploit:~

   spec:
     containers:
     - name: ...
       image: ...
       env:
       - name: LOG4J_FORMAT_MSG_NO_LOOKUPS
         value: "true"
  

5.Azure Functions:

सिस्टम प्रॉपर्टी को कॉन्फ़िगर करना आपकी होस्टिंग विकल्प की पसंद पर निर्भर करेगा: dedicated, premium या consumption। एक अनुस्मारक के रूप में, प्राथमिक अनुशंसित शमन उपाय Log4J को 2.15.0 में अपग्रेड करना और अपने एप्लिकेशन को फिर से डिप्लॉय करना है। यदि आप किसी भी कारण से ऐसा नहीं कर सकते हैं, तो आप सिस्टम प्रॉपर्टी लागू कर सकते हैं।

- Dedicated और Premium Functions:

JAVA_OPTS नाम की एक ऐप सेटिंग बनाएँ जिसका मान "-Dlog4j2.formatMsgNoLookups=true" हो। यदि आपने पहले से JAVA_OPTS ऐप सेटिंग सेट की है, तो बस मौजूदा मान में "-Dlog4j2.formatMsgNoLookups=true" जोड़ दें।

- Consumption Functions:

Linux: "languageWorkers__java__arguments" नाम की एक ऐप सेटिंग बनाएँ जिसका मान "-Dlog4j2.formatMsgNoLookups=true" हो। Windows: "languageWorkers:java:arguments" नाम की एक ऐप सेटिंग बनाएँ जिसका मान "-Dlog4j2.formatMsgNoLookups=true" हो। **ध्यान दें कि ऐप सेटिंग को अपडेट करने से आपके Web और Function ऐप्स पुनः प्रारंभ होंगे, जो कोल्ड स्टार्ट प्रदर्शन को प्रभावित कर सकता है। यदि आप Log4J संस्करण 2.9 या उससे कम का उपयोग कर रहे हैं, तो यह सिस्टम प्रॉपर्टी शमन काम नहीं करेगा और आपको v2.15.0 में अपग्रेड करना चाहिए।

6.Apache Log4j के लिए हॉटपैच

यह कैसे काम करता है? यह टूल एक चालू JVM प्रक्रिया में एक Java एजेंट इंजेक्ट करता है। एजेंट सभी लोडेड org.apache.logging.log4j.core.lookup.JndiLookup इंस्टेंस की lookup() विधि को पैच करने का प्रयास करता है ताकि वह बिना शर्त स्ट्रिंग "Patched JndiLookup::lookup()" लौटाए। यह Java प्रक्रिया को पुनः प्रारंभ किए बिना Log4j में CVE-2021-44228 रिमोट कोड निष्पादन भेद्यता को संबोधित करने के लिए डिज़ाइन किया गया है।

यदि आपके पास अपनी Java प्रक्रियाओं को फिर से डिप्लॉय करने की संभावना है, तो आप इसे एक स्थिर एजेंट के रूप में भी उपयोग कर सकते हैं, जिसका अर्थ है कि आप अपने सर्वरों में सीधे लॉग इन किए बिना इस पैच को अपने रनटाइम में शामिल कर सकते हैं।

Github : https://github.com/corretto/hotpatch-for-apache-log4j2

7.Defender for Cloud Log4j भेद्यताओं से प्रभावित मशीनों को कैसे ढूँढता है

इन्वेंट्री का उपयोग करके, आपके पास अपने जोखिम को निर्धारित करने के दो शक्तिशाली तरीके हैं:

सॉफ़्टवेयर इन्वेंट्री

भेद्यता आकलन निष्कर्ष

https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/how-defender-for-cloud-finds-machines-affected-by-log4j/ba-p/3037271

8.Azure Sentinel और WAF लॉग पर डिटेक्शन:

Azure WAF Log4j CVE-2021-44228 हंटिंग

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/WAF_log4j_vulnerability.yaml

Log4j भेद्यता (CVE-2021-44228) के लिए Azure WAF मिलान

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AzureDiagnostics/AzureWAFmatching_log4j_vuln.yaml

9.भविष्य के बिल्ड में log4j2 असुरक्षित संस्करणों पर प्रतिबंध लगाने के लिए Maven प्लग-इन कॉन्फ़िगरेशन:

पुराने log4j2 संस्करणों के किसी भी उपयोग से बचने के लिए अपने पैरेंट POM में डालने हेतु Maven प्लग-इन कॉन्फ़िगरेशन, जिनमें से कुछ RCE CVE-2021-44228

("Log4Shell"), CVE-2021-45046, और CVE-2021-45105 के अधीन हैं।

संदर्भ: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d

 <!-- plug-in configuration to put into your parent POM for avoiding any usages of
     outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
     ("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
     latest version of log4j2 at
     https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.0.0</version>
  <executions>
    <execution>
      <id>ban-bad-log4j-versions</id>
      <phase>validate</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>
...

योगदान:

समुदाय से योगदान पाकर खुशी होगी। योगदान दिशानिर्देश:

-->कृपया एक PR बनाएँ।

-->अधिक संदर्भ के लिए कृपया एक संदर्भ स्रोत शामिल करना सुनिश्चित करें

कई अलग-अलग वातावरण और ठीक करने के अन्य तरीके हो सकते हैं ,एक पुल रिक्वेस्ट खोलने के लिए स्वतंत्र महसूस करें :

संदर्भ:

https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

https://github.com/justincormack/log4jpoc

https://www.rumble.run/blog/finding-log4j/

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay

https://docs.oracle.com/javase/jndi/tutorial/getStarted/overview/index.html

https://logging.apache.org/log4j/2.x/security.html

https://aws.amazon.com/blogs/opensource/hotpatch-for-apache-log4j/