DeepSeek Harness मुळे सँडबॉक्समधील (sandboxed) अटॅकर केवळ HTTP Host हेडर 127.0.0.1 मध्ये बदलून कोणतेही कमांड्स (arbitrary commands) रन करू शकत होता, ज्याचा CVSS स्केलवर स्कोअर 9.4 आहे. ही त्रुटी दर्शवते की विश्वासाचा एक चुकीचा निर्णय कशा प्रकारे संरक्षणात्मक सीमांचे रूपांतर उघड्या बॅकडोअरमध्ये (open backdoor) करू शकतो.
ही त्रुटी कशी निर्माण झाली
ही असुरक्षित कोड (vulnerable code) एका सिंगल फंक्शनमध्ये आहे जे रिक्वेस्टचे Host हेडर वाचते आणि जर त्याचे मूल्य लूपबॅक ॲड्रेसच्या (loopback address) समान असेल, तर ती रिक्वेस्ट लोकल मशीनमधून येत आहे असे मानले जाते.
सँडबॉक्समध्ये कोड एक्झिक्युट करू शकणाऱ्या अटॅकरला कोणत्याही क्लिष्ट पेलोडची (sophisticated payload) गरज नसते. Host: 127.0.0.1 सह एक HTTP रिक्वेस्ट पाठवून, बॅकएंडला असे वाटते की ही कॉल स्वतः होस्टमधूनच येत आहे आणि त्यामुळे सर्व सुरक्षा सूचना (security prompts), रेट-लिमिट चेक आणि कमांड-व्हॅलिडेशन स्टेप्स वगळल्या जातात. परिणाम: कोणत्याही पुढील इंटरॅक्शनशिवाय अनियंत्रित कमांड एक्झिक्युशन (unrestricted command execution).
हेडर्सवर विश्वास ठेवणे धोकादायक का आहे
हेडर्स हे कॉलरद्वारे पुरवलेले प्लेन-टेक्स्ट स्ट्रिंग्स असतात. ते फील्ड Host, X-Forwarded-For किंवा कोणतेही कस्टम नाव असले तरीही, क्लायंट ते आपल्या इच्छेनुसार कोणत्याही व्हॅल्यूवर सेट करू शकतो. कनेक्शन खरोखर कुठून आले आहे याबद्दलचा एकमेव विश्वसनीय स्रोत म्हणजे ट्रान्सपोर्ट लेयर (transport layer) – म्हणजे सॉकेटचा सोर्स IP ॲड्रेस, जो TCP हँडशेक पूर्ण झाल्यावर ऑपरेटिंग सिस्टम रेकॉर्ड करते.
जेव्हा एखादे ॲप्लिकेशन एखादा प्रॉक्सी (proxy) तो हेडर इंजेक्ट करत असल्याची खात्री न करता हेडरवर विश्वास ठेवण्याचा निर्णय घेते, तेव्हा ते अटॅकरला संपूर्ण सिस्टमची चावी सोपवते. 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 वापरा.
- सर्व्हिसच्या समोर योग्यरित्या कॉन्फिगर केलेला रिव्हर्स प्रॉक्सी (reverse proxy) असेल तरच प्रॉक्सी-ट्रस्ट फ्लॅग्स सक्षम करा. जर तुम्ही ॲप्लिकेशन थेट चालवत असाल, तर ते फ्लॅग्स अक्षम (disabled) ठेवा.
- तुमच्या प्रोजेक्टच्या README किंवा डिप्लॉयमेंट गाईडमध्ये आवश्यक डिप्लॉयमेंट टोपोलॉजीचे (deployment topology) दस्तऐवजीकरण करा, जेणेकरून सेल्फ-होस्ट करणाऱ्या वापरकर्त्यांना प्रॉक्सी-ट्रस्टच्या आवश्यकतेबद्दल माहिती मिळेल.
- स्टॅटिक-ॲनॅलिसिस (static-analysis) किंवा कोड-रिव्ह्यू टूल्स चालवा, जे प्रॉक्सी-व्हॅलिडेशन लॉजिकशिवाय सुरक्षा निर्णयांसाठी थेट हेडर्सचा वापर केल्यास इशारा देतात.
पुढे काय लक्ष ठेवावे
या घटनेनंतर, सेल्फ-होस्टेड वेब सर्व्हिसेस प्रदान करणाऱ्या कम्युनिटीज त्यांच्या स्वतःच्या प्रॉक्सी-ट्रस्ट सेटिंग्जचा पुन्हा विचार करण्याची शक्यता आहे.
मुख्य धडा स्पष्ट आहे: इंटरनेटवरील कोणीही लिहू शकणाऱ्या मजकुराला तुमच्या सिस्टमची सुरक्षा स्थिती (security posture) ठरवू देऊ नका. रिक्वेस्ट लेयरवर नाही, तर नेटवर्क लेयरवर विश्वास ठेवा.