DeepSeek Harness نے ایک sandboxed حملہ آور کو محض HTTP Host header کو 127.0.0.1 میں تبدیل کر کے من مانے کمانڈز (arbitrary commands) چلانے کی اجازت دے دی، جس کا CVSS اسکیل پر اسکور 9.4 ہے۔ یہ خامی ظاہر کرتی ہے کہ کس طرح اعتماد کا ایک غلط فیصلہ حفاظتی سرحد کو ایک کھلے بیک ڈور (backdoor) میں بدل سکتا ہے۔
یہ خامی کیسے پیدا ہوئی
یہ کمزور کوڈ ایک ہی فنکشن میں موجود ہے جو درخواست کے Host header کو پڑھتا ہے اور اگر اس کی ویلیو loopback address کے برابر ہو، تو درخواست کو مقامی مشین (local machine) سے آنے والی درخواست سمجھ لیتا ہے۔
ایک حملہ آور جو sandbox کے اندر کوڈ چلا سکتا ہے، اسے کسی پیچیدہ payload کی ضرورت نہیں ہے۔ صرف ایک HTTP درخواست Host: 127.0.0.1 کے ساتھ بھیج کر، بیک اینڈ یہ سمجھ لیتا ہے کہ یہ کال خود ہوسٹ سے آ رہی ہے اور تمام سیکیورٹی پرامپٹس، rate-limit چیکس، اور command-validation اقدامات کو چھوڑ دیتا ہے۔ نتیجہ: بغیر کسی مزید مداخلت کے غیر محدود کمانڈ ایگزیکیوشن۔
ہیڈرز پر بھروسہ کرنا کیوں خطرناک ہے
Headers کال کرنے والے کی طرف سے فراہم کردہ سادہ ٹیکسٹ (plain-text) اسٹرنگز ہیں۔ چاہے فیلڈ کا نام Host ہو، X-Forwarded-For ہو، یا کوئی بھی کسٹم نام، کلائنٹ اسے اپنی مرضی کی کسی بھی ویلیو پر سیٹ کر سکتا ہے۔ کنکشن اصل میں کہاں سے آیا ہے، اس بارے میں حقیقت کا واحد قابل اعتماد ذریعہ transport layer ہے – یعنی socket کا source IP address جسے آپریٹنگ سسٹم اس وقت ریکارڈ کرتا ہے جب TCP handshake مکمل ہو جاتا ہے۔
جب کوئی ایپلی کیشن یہ تصدیق کیے بغیر کہ اسے کسی معلوم اور درست طریقے سے کنفیگر شدہ پراکسی (proxy) نے شامل کیا ہے، کسی ہیڈر پر بھروسہ کرنے کا فیصلہ کرتی ہے، تو وہ حملہ آور کو سلطنت کی چابیاں تھما دیتی ہے۔ DeepSeek Harness کی یہ خامی اس غلطی کی ایک کلاسیکی مثال ہے۔
حقیقی دنیا پر اثرات: shell.online کی مثال
اوپن سورس shell.online پروجیکٹ، جو ایک ویب پر مبنی ٹرمینل فراہم کرتا ہے، نے حال ہی میں اسی طرح کے مسئلے کو دستاویز کیا ہے۔ یہ TRUST_PROXY نامی ایک کنفیگریشن فلیگ استعمال کرتا ہے:
- TRUST_PROXY = 0 – ایپ X-Forwarded-For ہیڈر کو نظر انداز کر دیتی ہے اور socket کے ریموٹ ایڈریس پر انحصار کرتی ہے۔ یہ کلائنٹ کو ریٹ لمٹس (rate limits) سے بچنے یا کسی قابل اعتماد صارف کے طور پر ظاہر ہونے کے لیے IP ایڈریس کو جعلی بنانے سے روکتا ہے۔
- TRUST_PROXY = 1 – ایپ کلائنٹ کی شناخت کے طور پر X-Forwarded-For ہیڈر پر بھروسہ کرتی ہے۔ اگر سروس کسی اصل پراکسی کے پیچھے نہیں ہے جو اس ہیڈر کو صاف (sanitise) کرے، تو ایک حملہ آور ہر درخواست پر ایک نیا IP ایڈریس فراہم کر سکتا ہے، جس سے مؤثر طور پر ہر IP کے لیے لگائی گئی تھروٹلنگ (throttling) ری سیٹ ہو جاتی ہے۔
DeepSeek کی خامی اسی منظرنامے کی عکاسی کرتی ہے: کوڈ نے Host پر ایسے بھروسہ کیا جیسے اسے کسی پراکسی نے سیٹ کیا ہو، حالانکہ سروس تک براہ راست رسائی حاصل کی جا سکتی تھی۔
ڈویلپرز کو اب کیا کرنے کی ضرورت ہے
- ہر اس جگہ کا آڈٹ کریں جہاں آپ کلائنٹ کی طرف سے فراہم کردہ ہیڈرز پڑھتے ہیں۔ شناخت کریں کہ آپ کن ہیڈرز کو مستند (authoritative) سمجھتے ہیں (مثلاً Host، X-Forwarded-For، X-Real-IP) اور اس بات کی تصدیق کریں کہ ایک قابل اعتماد پراکسی آپ کی ایپلی کیشن تک پہنچنے سے پہلے انہیں دوبارہ لکھنے (rewrite) کی ضمانت دیتا ہے۔
- جہاں ممکن ہو، سیکیورٹی فیصلوں کو socket address سے جوڑیں۔ تصدیق (authentication)، ریٹ لمٹینگ (rate-limiting)، اور رسائی کے کنٹرول (access-control) کے چیکس کے لیے OS کی طرف سے فراہم کردہ source IP کا استعمال کریں۔
- پراکسی-ٹرسٹ (proxy-trust) فلیگز کو صرف اسی صورت میں فعال کریں جب سروس کے سامنے ایک درست طریقے سے کنفیگر شدہ ریورس پراکسی (reverse proxy) موجود ہو۔ اگر آپ ایپ کو براہ راست چلا رہے ہیں، تو ان فلیگز کو غیر فعال رکھیں۔
- اپنے پروجیکٹ کے README یا ڈیپلائمنٹ گائیڈ میں مطلوبہ ڈیپلائمنٹ ٹوپولوجی (deployment topology) کو دستاویز کریں، تاکہ خود سے ہوسٹ کرنے والے صارفین پراکسی-ٹرسٹ کی ضرورت سے واقف ہوں۔
- اسٹیٹک اینالیسس (static-analysis) یا کوڈ-ریویو ٹولز چلائیں جو پراکسی-ویلیڈیشن لاجک کے بغیر سیکیورٹی فیصلوں کے لیے ہیڈرز کے براہ راست استعمال کو نشان زد کریں۔
آگے کیا نظر آئے گا
وہ کمیونٹیز جو خود سے ہوسٹ کی جانے والی ویب سروسز فراہم کرتی ہیں، اس واقعے کے بعد اپنے پراکسی-ٹرسٹ سیٹنگز پر نظر ثانی کرنے کا امکان ہے۔
بنیادی سبق بالکل واضح ہے: کبھی بھی انٹرنیٹ پر موجود کسی بھی شخص کے لکھے ہوئے ٹیکسٹ کو اپنے سسٹم کی سیکیورٹی کا فیصلہ کرنے کی اجازت نہ دیں۔ نیٹ ورک لیئر پر بھروسہ کریں، ریکویسٹ لیئر پر نہیں۔