DeepSeek Harness ने एक सैंडबॉक्स्ड (sandboxed) हमलावर को केवल HTTP Host हेडर को 127.0.0.1 में बदलकर मनमाने कमांड (arbitrary commands) चलाने की अनुमति दे दी, जिसका CVSS स्केल पर स्कोर 9.4 है। यह खामी दर्शाती है कि कैसे भरोसे का एक गलत निर्णय सुरक्षात्मक सीमा को एक खुले बैकडोर (backdoor) में बदल सकता है।
यह बग कैसे आया
यह असुरक्षित कोड एक एकल फ़ंक्शन में है जो अनुरोध (request) के Host हेडर को पढ़ता है और यदि मान लूपबैक एड्रेस (loopback address) के बराबर है, तो अनुरोध को स्थानीय मशीन (local machine) से आने वाला मान लेता है।
एक हमलावर जो सैंडबॉक्स के भीतर कोड निष्पादित कर सकता है, उसे किसी जटिल पेलोड (payload) की आवश्यकता नहीं है। Host: 127.0.0.1 के साथ एक HTTP अनुरोध भेजकर, बैकएंड यह मान लेता है कि कॉल स्वयं होस्ट से आ रही है और सभी सुरक्षा प्रॉम्प्ट, रेट-लिमिट (rate-limit) जाँच और कमांड-वैलिडेशन चरणों को छोड़ देता है। परिणाम: बिना किसी अतिरिक्त इंटरैक्शन के अनियंत्रित कमांड निष्पादन।
हेडर पर भरोसा करना खतरनाक क्यों है
हेडर कॉलर (caller) द्वारा दिए गए प्लेन-टेक्स्ट स्ट्रिंग होते हैं। चाहे फ़ील्ड का नाम Host, X-Forwarded-For, या कोई भी कस्टम नाम हो, क्लाइंट इसे अपनी इच्छानुसार किसी भी मान पर सेट कर सकता है। कनेक्शन वास्तव में कहाँ से आया है, इसके बारे में सच्चाई का एकमात्र विश्वसनीय स्रोत ट्रांसपोर्ट लेयर (transport layer) है - सॉकेट का सोर्स IP एड्रेस जिसे ऑपरेटिंग सिस्टम TCP हैंडशेक पूरा होने पर रिकॉर्ड करता है।
जब कोई एप्लिकेशन यह पुष्टि किए बिना कि किसी ज्ञात और सही ढंग से कॉन्फ़िगर किए गए प्रॉक्सी ने इसे इंजेक्ट किया है, किसी हेडर पर भरोसा करने का निर्णय लेती है, तो वह हमलावर को पूरे सिस्टम की चाबियाँ सौंप देती है। DeepSeek Harness बग इस गलती का एक सटीक उदाहरण है।
वास्तविक दुनिया का प्रभाव: shell.online का उदाहरण
ओपन-सोर्स shell.online प्रोजेक्ट, जो एक वेब-आधारित टर्मिनल प्रदान करता है, ने हाल ही में इसी तरह की खामी को दर्ज किया है। यह TRUST_PROXY नामक एक कॉन्फ़िगरेशन फ्लैग का उपयोग करता है:
- TRUST_PROXY = 0 – ऐप X-Forwarded-For हेडर को अनदेखा करता है और सॉकेट के रिमोट एड्रेस पर भरोसा करता है। यह क्लाइंट को रेट लिमिट से बचने या भरोसेमंद उपयोगकर्ता के रूप में छिपने के लिए IP एड्रेस को फर्जी बनाने से रोकता है।
- TRUST_PROXY = 1 – ऐप क्लाइंट की पहचान के रूप में X-Forwarded-For हेडर पर भरोसा करता है। यदि सेवा किसी वास्तविक प्रॉक्सी के पीछे नहीं है जो इस हेडर को सैनिटाइज (sanitise) करती है, तो एक हमलावर हर अनुरोध पर एक नया IP एड्रेस दे सकता है, जिससे प्रभावी रूप से किसी भी प्रति-IP थ्रॉटलिंग (throttling) को रीसेट किया जा सकता है।
DeepSeek बग इसी परिदृश्य को दर्शाता है: कोड ने Host पर इस तरह भरोसा किया जैसे कि किसी प्रॉक्सी ने इसे सेट किया हो, फिर भी सेवा तक सीधे पहुँचा जा सकता था।
डेवलपर्स को अब क्या करने की आवश्यकता है
- उन सभी स्थानों का ऑडिट करें जहाँ आप क्लाइंट द्वारा दिए गए हेडर पढ़ते हैं। पहचानें कि आप किन हेडर को आधिकारिक (authoritative) मानते हैं (जैसे, Host, X-Forwarded-For, X-Real-IP) और सत्यापित करें कि एक भरोसेमंद प्रॉक्सी आपके एप्लिकेशन तक पहुँचने से पहले उन्हें फिर से लिखने (rewrite) की गारंटी देती है।
- जब भी संभव हो, सुरक्षा निर्णयों को सॉकेट एड्रेस से जोड़ें। प्रमाणीकरण (authentication), रेट-लिमिटिंग और एक्सेस-कंट्रोल जाँच के लिए OS द्वारा प्रदान किए गए सोर्स IP का उपयोग करें।
- प्रॉक्सी-ट्रस्ट फ्लैग्स को केवल तभी सक्षम करें जब सेवा के सामने एक सही ढंग से कॉन्फ़िगर किया गया रिवर्स प्रॉक्सी हो। यदि आप ऐप को सीधे चलाते हैं, तो उन फ्लैग्स को अक्षम (disabled) रखें।
- अपने प्रोजेक्ट के README या डिप्लॉयमेंट गाइड में आवश्यक डिप्लॉयमेंट टोपोलॉजी (deployment topology) को दस्तावेज़बद्ध करें, ताकि जो उपयोगकर्ता स्वयं होस्ट (self-host) करते हैं, उन्हें प्रॉक्सी-ट्रस्ट की आवश्यकता के बारे में पता चल सके।
- स्टैटिक-एनालिसिस (static-analysis) या कोड-रिव्यू टूल्स चलाएं जो प्रॉक्सी-वैलिडेशन लॉजिक के बिना सुरक्षा निर्णयों के लिए हेडर के सीधे उपयोग को चिह्नित करते हैं।
आगे क्या ध्यान रखें
इस घटना के बाद, जो समुदाय सेल्फ-होस्टेड वेब सेवाएं प्रदान करते हैं, वे अपनी प्रॉक्सी-ट्रस्ट सेटिंग्स की समीक्षा कर सकते हैं।
मुख्य सबक स्पष्ट है: इंटरनेट पर कोई भी लिख सकता है, ऐसे टेक्स्ट को कभी भी अपने सिस्टम की सुरक्षा स्थिति (security posture) तय न करने दें। नेटवर्क लेयर पर भरोसा करें, रिक्वेस्ट लेयर पर नहीं।