Node.js RCE शमन: अंतिम रक्षा पंक्ति के रूप में DevOps

यह प्रोजेक्ट Next.js एप्लिकेशन (विशेष रूप से सर्वर एक्शन के माध्यम से) में एक गंभीर रिमोट कोड निष्पादन (RCE) भेद्यता प्रदर्शित करता है और दिखाता है कि कैसे इंफ्रास्ट्रक्चर सख्ती हमले को प्रभावी ढंग से बेअसर करती है, भले ही कोड भेद्यता बनी रहे।

यह एक मानक "असुरक्षित" तैनाती की तुलना एक कठोर "सुरक्षित" तैनाती से करता है, जिसमें Distroless इमेज और रीड-ओनली फ़ाइलसिस्टम का उपयोग किया गया है।

🛡️ अवधारणा: "गहराई में सुरक्षा"

सॉफ्टवेयर भेद्यताएं अपरिहार्य हैं। जब कोड विफल होता है, तो आपके इंफ्रास्ट्रक्चर को हमलावर को अपने पैर जमाने से रोकना चाहिए।

भेद्यता

Next.js द्वारा उपयोग किए जाने वाले React Server Components (RSC) कार्यान्वयन में एक गंभीर RCE (CVE-2025-55182, उर्फ React2Shell) मौजूद है।

• CVSS: 10.0 (गंभीर)
• मूल कारण: "फ्लाइट" प्रोटोकॉल का असुरक्षित डिसेरियलाइज़ेशन हमलावर को सर्वर एक्शन प्रोसेसिंग के दौरान आंतरिक ऑब्जेक्ट्स (प्रोटोटाइप प्रदूषण या समान तंत्र के माध्यम से) में हेरफेर करने की अनुमति देता है।
• प्रभाव: यह बिना प्रमाणीकरण के मनमाना कोड निष्पादन (spawnSync जैसा) की अनुमति देता है।

हमले के वैक्टर

1. लिविंग ऑफ द लैंड (LotL): गोपनीय जानकारी चुराने या मैलवेयर डाउनलोड करने के लिए OS में पहले से मौजूद टूल्स (curl, wget, ls, cat) का उपयोग करना।
   • तंत्र: शोषण Node.js child_process.spawnSync() का उपयोग करता है। यह बाइनरी को सीधे निष्पादित करता है, बिना किसी शेल (/bin/sh) की आवश्यकता के।
2. ब्रिंग योर ओन लैंड (BYOL): यदि मानक उपकरण गायब हैं, तो हमलावर अपनी स्वयं की बाइनरी (जैसे, एक संकलित Go निष्पादन योग्य) अपलोड करता है, इसे निष्पादन योग्य चिह्नित करता है (chmod +x), और चलाता है।

🏗️ आर्किटेक्चर तुलना

📝 एप्लिकेशन लॉग विश्लेषण

निम्नलिखित लॉग दर्शाते हैं कि एप्लिकेशन के दृष्टिकोण से हमले के प्रयास कैसे दिखते हैं। यह विरोधाभास सुरक्षा उपायों की प्रभावशीलता को स्पष्ट रूप से उजागर करता है।

सुरक्षित ऐप लॉग (logs/server.safe.log)

लॉग बार-बार विफलता (ENOENT) दिखाते हैं।

• क्यों? spawnSync ls, id, curl चलाने का प्रयास करता है। Distroless इमेज में ये बाइनरी बिल्कुल नहीं हैं। यह केवल शेल के गायब होने के बारे में नहीं है; उपकरण स्वयं गायब हैं।

[Instrumentation] Logging initialized. Writing to: /app/logs/server.safe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"2. Verify Binary was Written","verification":{...},"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"","stderr":"","error_obj":{"message":"spawnSync /tmp/hello_test EACCES","code":"EACCES"},"success":true}`'

असुरक्षित ऐप लॉग (logs/server.unsafe.log)

लॉग सफल कमांड निष्पादन और फ़ाइल सिस्टम हेरफेर की पुष्टि करते हैं।

[Instrumentation] Logging initialized. Writing to: /app/logs/server.unsafe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"Hello from Go binary!\\n","stderr":"","error_obj":null,"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"id","args":[],"stdout":"uid=0(root) gid=0(root) ...","stderr":"","status":0,"signal":null}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"cat","args":["/app/.env"],"stdout":"","stderr":"cat: can\'t open \'/app/.env\': No such file or directory\n","status":1,"signal":null}`'

(नोट: असुरक्षित लॉग में, उपरोक्त cat /app/.env विफल होता है क्योंकि फ़ाइल का नाम रूट में .env है, लेकिन पूर्ण लॉग में ls -la निर्देशिका संरचना प्रकट करेगा।)

💥 POC परिणाम

1. मानक RCE (लिविंग ऑफ द लैंड)

मानक शेल कमांड चलाने का प्रयास।

• असुरक्षित: ✅ सफल। हमलावर id, ls, cat .env चला सकता है और संवेदनशील डेटा तक पहुंच सकता है।
• सुरक्षित: ❌ अवरुद्ध। spawnSync /bin/sh ENOENT। कमांड को निष्पादित करने के लिए कोई शेल नहीं है।

2. उन्नत हमला (ब्रिंग योर ओन लैंड)

एक कस्टम बाइनरी अपलोड करके "गायब उपकरणों" को बायपास करने का प्रयास।

• असुरक्षित: ✅ सफल।
  1. हमलावर एक बाइनरी को चंक करता है (पेलोड सीमा को बायपास करने के लिए)।
  2. इसे /tmp/malware पर लिखता है।
  3. chmod +x चलाता है।
  4. बाइनरी को निष्पादित करता है।
• सुरक्षित: ❌ अवरुद्ध।
  • लिखना विफल: EROFS: read-only file system।
  • हमलावर कहीं भी फ़ाइलें नहीं छोड़ सकता, BYOL हमले को प्रभावी ढंग से बेअसर करता है।

3. "ट्रू फ़ाइललेस" निष्पादन विश्लेषण

क्या हमलावर एक बाइनरी को वेरिएबल में लोड कर सकता है और उसे सीधे मेमोरी से निष्पादित कर सकता है?

• अवधारणा: एक बाइनरी के चंक को एक ग्लोबल JavaScript वेरिएबल (जैसे, global.payload = "...") में संयोजित करें, फिर इसे निष्पादित करें।
• वास्तविकता: विफल।
  • Node.js child_process फ़ंक्शन (spawn, exec) को एक फ़ाइल पथ की आवश्यकता होती है। वे किसी बफर या स्ट्रिंग को सीधे निष्पादित नहीं कर सकते।
  • इसे Linux पर बायपास करने के लिए, memfd_create (RAM में एक अनाम फ़ाइल बनाने के लिए एक सिसकॉल) की आवश्यकता होती है।
  • बाधा: Node.js मूल रूप से memfd_create को उजागर नहीं करता है। इसे एक्सेस करने के लिए एक C++ ऐडन (जैसे ffi-napi) को node_modules में पूर्व-स्थापित करने की आवश्यकता होगी।
  • Distroless प्रभाव: चूंकि इमेज में कंपाइलर (gcc, make) नहीं हैं, हमलावर मौके पर इस ऐडन का निर्माण नहीं कर सकता।

🔐 प्रदर्शित सर्वोत्तम अभ्यास

1. Distroless इमेज का उपयोग करें

"Distroless" इमेज में केवल आपका एप्लिकेशन और उसके रनटाइम निर्भरताएं होती हैं। उनमें पैकेज मैनेजर, शेल या मानक UNIX उपकरण नहीं होते हैं।

• क्यों? यदि किसी हमलावर को RCE मिल जाता है, तो वे आसानी से चारों ओर नहीं देख सकते (ls), फ़ाइलें डाउनलोड नहीं कर सकते (curl), या विशेषाधिकार नहीं बढ़ा सकते।

2. रीड-ओनली फ़ाइलसिस्टम

अपने कंटेनर रनटाइम को रूट फ़ाइलसिस्टम को केवल-पढ़ने के लिए माउंट करने के लिए कॉन्फ़िगर करें।

• क्यों? यह हमलावरों को आपके एप्लिकेशन कोड को डाउनलोड करने (BYOL) या संशोधित करने (स्थिरता) से रोकता है।
• कैसे? docker-compose.yml में:
  root@kitploit:~

  read_only: true
  tmpfs:
    - /tmp:noexec # महत्वपूर्ण: स्पष्ट रूप से निष्पादन को ब्लॉक करें!
  

  अवलोकन: इस सेटअप के साथ, हमारा POC दर्शाता है कि हमलावर बाइनरी को /tmp में लिख सकता है (लिखना सफल), लेकिन noexec फ़्लैग के कारण निष्पादन EACCES (अनुमति निषेध) के साथ विफल हो जाता है। यह कार्यक्षमता (लिखने योग्य tmp) को सुरक्षा के साथ संतुलित करता है।

3. देशी पर्यावरण चर ("निर्यात" स्थान)

अपने कंटेनर इमेज में .env फ़ाइल को शिप न करें। यदि कोई हमलावर फ़ाइलें पढ़ सकता है (जैसे, cat .env), तो आपके रहस्य समझौता हो जाते हैं।

• सुरक्षित दृष्टिकोण: वेरिएबल को सीधे प्रक्रिया वातावरण में रनटाइम पर इंजेक्ट करें (जैसे, Kubernetes Secrets, AWS Parameter Store, या Docker की environment कुंजी के माध्यम से)।
• क्यों? यह हमलावर के लिए एक ही फ़ाइल को पढ़ने की तुलना में एक साथ सभी रहस्यों को डंप करना अधिक कठिन बना देता है।

🚀 कैसे चलाएं

1. वातावरण प्रारंभ करें: सुरक्षित और असुरक्षित दोनों एप्लिकेशन एक ही docker-compose.yml फ़ाइल में परिभाषित हैं।

   root@kitploit:~

   docker compose up --build -d
   

2. शोषण चलाएं: आप अंतर देखने के लिए विशिष्ट पोर्ट पर शोषण चला सकते हैं।

   • असुरक्षित ऐप को लक्षित करना (पोर्ट 3001):

     root@kitploit:~

     # 1. मानक RCE (LotL) - सफल
     python exploit/poc.py http://localhost:3001
     
     # 2. उन्नत हमला (BYOL) - सफल
     python exploit/poc_advanced.py http://localhost:3001
     

   • सुरक्षित ऐप को लक्षित करना (पोर्ट 3000):

     root@kitploit:~

     # 1. मानक RCE (LotL) - विफल (ENOENT)
     python exploit/poc.py http://localhost:3000
     
     # 2. उन्नत हमला (BYOL) - विफल (EACCES/EROFS)
     python exploit/poc_advanced.py http://localhost:3000
     

3. सफाई:

   root@kitploit:~

   docker compose down