DeepSeek Harness একটি স্যান্ডবক্সড অ্যাটাকারকে শুধুমাত্র HTTP Host হেডার 127.0.0.1 এ পরিবর্তন করে যেকোনো কমান্ড চালানোর সুযোগ করে দিয়েছিল, যার CVSS স্কেলে স্কোর হলো 9.4। এই ত্রুটিটি দেখায় যে কীভাবে একটি ভুল আস্থার সিদ্ধান্ত একটি সুরক্ষা সীমানাকে একটি ওপেন ব্যাকডোরে পরিণত করতে পারে।
বাগটি কীভাবে ঢুকে পড়ল
ভুল কোডটি একটি একক ফাংশনের মধ্যে রয়েছে যা রিকোয়েস্টের Host হেডারটি পড়ে এবং যদি মানটি লুপব্যাক অ্যাড্রেসের সমান হয়, তবে রিকোয়েস্টটিকে লোকাল মেশিন থেকে আসা রিকোয়েস্ট হিসেবে গণ্য করে।
একজন অ্যাটাকার যে স্যান্ডবক্সের ভেতরে কোড এক্সিকিউট করতে পারে, তার জন্য কোনো জটিল পেলোডের প্রয়োজন নেই। Host: 127.0.0.1 সহ একটি HTTP রিকোয়েস্ট পাঠানোর মাধ্যমে, ব্যাকএন্ড বিশ্বাস করে যে কলটি হোস্ট নিজেই থেকে আসছে এবং এটি সমস্ত সিকিউরিটি প্রম্পট, রেট-লিমিট চেক এবং কমান্ড-ভ্যালিডেশন ধাপগুলো এড়িয়ে যায়। ফলাফল: কোনো অতিরিক্ত ইন্টারঅ্যাকশন ছাড়াই অবাধ কমান্ড এক্সিকিউশন।
হেডারকে বিশ্বাস করা কেন বিপজ্জনক
হেডার হলো সাধারণ টেক্সট স্ট্রিং যা কলারের মাধ্যমে সরবরাহ করা হয়। ফিল্ডটির নাম Host, X-Forwarded-For, বা যেকোনো কাস্টম নাম যাই হোক না কেন, ক্লায়েন্ট এটি তার ইচ্ছামতো যেকোনো মান সেট করতে পারে। একটি কানেকশন আসলে কোথা থেকে এসেছে সে সম্পর্কে একমাত্র নির্ভরযোগ্য সত্য হলো ট্রান্সপোর্ট লেয়ার – সকেটের সোর্স আইপি অ্যাড্রেস যা TCP হ্যান্ডশেক সম্পন্ন হওয়ার সময় অপারেটিং সিস্টেম রেকর্ড করে।
যখন কোনো অ্যাপ্লিকেশন একটি পরিচিত এবং সঠিকভাবে কনফিগার করা প্রক্সি এটি ইনজেক্ট করেছে কিনা তা নিশ্চিত না করেই একটি হেডারকে বিশ্বাস করার সিদ্ধান্ত নেয়, তখন এটি একজন অ্যাটাকারকে রাজত্বের চাবিকাঠি দিয়ে দেয়। DeepSeek Harness-এর বাগটি এই ভুলের একটি আদর্শ উদাহরণ।
বাস্তব জগতের প্রভাব: shell.online-এর উদাহরণ
ওপেন-সোর্স shell.online প্রজেক্টটি, যা একটি ওয়েব-ভিত্তিক টার্মিনাল প্রদান করে, সম্প্রতি একই ধরনের ত্রুটি নথিভুক্ত করেছে। এটি TRUST_PROXY নামক একটি কনফিগারেশন ফ্ল্যাগ ব্যবহার করে:
- TRUST_PROXY = 0 – অ্যাপটি X-Forwarded-For হেডারটি উপেক্ষা করে এবং সকেটের রিমোট অ্যাড্রেসের ওপর নির্ভর করে। এটি একজন ক্লায়েন্টকে রেট লিমিট এড়াতে বা বিশ্বস্ত ব্যবহারকারী হিসেবে ছদ্মবেশ ধারণ করতে আইপি অ্যাড্রেস জালিয়াতি করা থেকে বিরত রাখে।
- TRUST_PROXY = 1 – অ্যাপটি ক্লায়েন্টের পরিচয় হিসেবে X-Forwarded-For হেডারটিকে বিশ্বাস করে। যদি পরিষেবাটি এমন কোনো প্রকৃত প্রক্সির পেছনে না থাকে যা এই হেডারটিকে স্যানিটাইজ করে, তবে একজন অ্যাটাকার প্রতিটি রিকোয়েস্টে একটি নতুন আইপি অ্যাড্রেস সরবরাহ করতে পারে, যা কার্যকরভাবে প্রতিটি আইপি-ভিত্তিক থ্রটলিং রিসেট করে দেয়।
DeepSeek বাগটি এই পরিস্থিতিরই প্রতিফলন: কোডটি Host-কে এমনভাবে বিশ্বাস করেছিল যেন এটি একটি প্রক্সি সেট করেছে, অথচ পরিষেবাটি সরাসরি অ্যাক্সেস করা সম্ভব ছিল।
ডেভেলপারদের এখন যা করা প্রয়োজন
- ক্লায়েন্ট-সরবরাহকৃত প্রতিটি হেডার যেখানে আপনি পড়েন তা অডিট করুন। চিহ্নিত করুন কোন হেডারগুলোকে আপনি অথরিটেটিভ হিসেবে গণ্য করেন (যেমন, Host, X-Forwarded-For, X-Real-IP) এবং যাচাই করুন যে একটি বিশ্বস্ত প্রক্সি আপনার অ্যাপ্লিকেশনে পৌঁছানোর আগে সেগুলো অবশ্যই রিরাইট (rewrite) করছে।
- যতটা সম্ভব সিকিউরিটি সিদ্ধান্তগুলোকে সকেট অ্যাড্রেসের সাথে যুক্ত করুন। অথেন্টিকেশন, রেট-লিমিটিং এবং অ্যাক্সেস-কন্ট্রোল চেকের জন্য OS-প্রদত্ত সোর্স আইপি ব্যবহার করুন।
- শুধুমাত্র তখনই প্রক্সি-ট্রাস্ট ফ্ল্যাগ এনাবল করুন যখন পরিষেবার সামনে একটি সঠিকভাবে কনফিগার করা রিভার্স প্রক্সি থাকে। আপনি যদি অ্যাপটি সরাসরি চালান, তবে সেই ফ্ল্যাগগুলো ডিজেবল রাখুন।
- আপনার প্রজেক্টের README বা ডেপ্লয়মেন্ট গাইডে প্রয়োজনীয় ডেপ্লয়মেন্ট টপোলজি নথিভুক্ত করুন, যাতে সেলফ-হোস্ট করা ব্যবহারকারীরা প্রক্সি-ট্রাস্ট প্রয়োজনীয়তা সম্পর্কে জানতে পারেন।
- স্ট্যাটিক-অ্যানালাইসিস বা কোড-রিভিউ টুল ব্যবহার করুন যা প্রক্সি-ভ্যালিডেশন লজিক ছাড়াই সিকিউরিটি সিদ্ধান্তের জন্য সরাসরি হেডার ব্যবহারের ক্ষেত্রে সতর্কবার্তা দেয়।
পরবর্তীতে যা খেয়াল রাখতে হবে
যেসব কমিউনিটি সেলফ-হোস্টেড ওয়েব পরিষেবা সরবরাহ করে, এই ঘটনার পর তারা সম্ভবত তাদের নিজস্ব প্রক্সি-ট্রাস্ট সেটিংস পুনরায় যাচাই করবে।
মূল শিক্ষাটি অত্যন্ত স্পষ্ট: ইন্টারনেটে যে কেউ লিখতে পারে এমন কোনো টেক্সটকে কখনোই আপনার সিস্টেমের সিকিউরিটি পজিশন নির্ধারণ করতে দেবেন না। রিকোয়েস্ট লেয়ারের পরিবর্তে নেটওয়ার্ক লেয়ারকে বিশ্বাস করুন।