DVMCP-এর বিরুদ্ধে capgate-এর পরীক্ষা
আমি Damn Vulnerable MCP (DVMCP) প্রজেক্টের দশটি ত্রুটিপূর্ণ MCP সার্ভারের বিরুদ্ধে আমার টুল, capgate, পরীক্ষা করেছি।
DVMCP হলো একটি শিক্ষামূলক টুল। প্রতিটি সার্ভার prompt injection, token theft, বা command injection-এর মতো নির্দিষ্ট আক্রমণ প্রদর্শন করে।
লক্ষ্যটি ছিল সহজ। আমি প্রতিটি টুলের জন্য একটি সঠিক manifest লিখেছি। তারপর আমি প্রশ্ন করেছি: capgate যে সীমানা (boundary) তৈরি করে তা কি আসলেই আক্রমণটি থামাতে পারে?
ফলাফলগুলো স্পষ্টভাবে দেখায় যে একটি capability compiler কী করতে পারে এবং কী করতে পারে না।
এটি যা থামায় (The Bullseye) Challenge 3-এ, একটি টুলের অতিরিক্ত পারমিশন রয়েছে। এটি একটি ফোল্ডার পড়ার দাবি করলেও আসলে পুরো ডিস্কটিই পড়তে পারে। আক্রমণটি একটি প্রাইভেট ফোল্ডার থেকে সিস্টেম ক্রেডেনশিয়াল (credentials) চুরি করার চেষ্টা করে। capgate এটি থামিয়ে দেয়। এটি manifest-টিকে একটি Docker container-এ কম্পাইল করে যা শুধুমাত্র অনুমোদিত ফোল্ডারটিকেই মাউন্ট (mount) করে। স্যান্ডবক্সের (sandbox) ভেতরে প্রাইভেট ফাইলগুলোর কোনো অস্তিত্ব থাকে না। ফলে আক্রমণটি ব্যর্থ হয়।
এটি যা নিয়ন্ত্রণ করে (The Middle Ground) Challenge 7-এ, একটি টুল একটি API key ফাঁস করে দেয়। capgate টুলটিকে কী (key) পড়া থেকে আটকাতে পারে না, কিন্তু এটি তথ্য পাচার (exfiltration) রোধ করে। এটি একটি egress proxy তৈরি করে যা শুধুমাত্র একটি নির্দিষ্ট হোস্টের সাথে সংযোগ স্থাপনের অনুমতি দেয়। আক্রমণকারী চুরি করা কী-টি তার নিজস্ব সার্ভারে পাঠাতে পারে না।
Challenge 8-এ, একটি টুল যেকোনো arbitrary shell command চালানোর অনুমতি দেয়। capgate তার গ্রামারে "allow any shell" এমন কিছু প্রকাশ করতে পারে না। পরিবর্তে, এটি টুলটিকে একটি বক্সের মধ্যে সীমাবদ্ধ করে ফেলে। এমনকি আক্রমণকারী কোনো কমান্ড চালালেও, প্রসেসটির কোনো নেটওয়ার্ক নেই, কোনো অতিরিক্ত প্রিভিলেজ নেই এবং এটি একটি read-only ফাইলসিস্টেম ব্যবহার করে। ফলে ক্ষতির পরিমাণ সীমিত থাকে।
এটি যা ধরতে পারে না (The Limits) Challenge 1-এ, আক্রমণটি হলো prompt injection। আক্রমণকারী মডেলটিকে নির্দেশাবলী উপেক্ষা করার জন্য প্ররোচিত করে। capgate এখানে কিছুই করতে পারে না। একটি sandbox compiler একটি টুল কী কী স্পর্শ করতে পারে তা সীমাবদ্ধ করে, কিন্তু একটি LLM কী বলবে তা নিয়ন্ত্রণ করতে পারে না।