Nym Mixnet ও Vesting Contract নিরাপত্তা নিরীক্ষা

ভূমিকা

With২০২২ সালের ডিসেম্বর মাসে Nym একটি স্বাধীন নিরাপত্তা নিরীক্ষার মধ্য দিয়ে যায়, যা পরিচালনা করে জার্মানি-ভিত্তিক সাইবারসিকিউরিটি কনসালটিং ফার্ম Oak Security—যারা তৃতীয় প্রজন্মের ব্লকচেইন ও বিকেন্দ্রীভূত প্রোটোকল নিরীক্ষায় বিশেষজ্ঞ। Cosmos, Terra, Polkadot এবং Flow-এর মতো ইকোসিস্টেমগুলোতে ব্যাপক অভিজ্ঞতাসম্পন্ন Oak Security-কে Nym ইকোসিস্টেমের দুটি গুরুত্বপূর্ণ উপাদান মূল্যায়নের দায়িত্ব দেওয়া হয়েছিল: (১) Nym মিক্সনেট এবং ভেস্টিং চুক্তি (দেখুন সম্পূর্ণ রিপোর্ট) এবং (২) Nym ওয়ালেট (দেখুন সম্পূর্ণ রিপোর্ট)। এই নিরীক্ষার উদ্দেশ্য ছিল এই উপাদানগুলোর নির্ভরযোগ্যতা মূল্যায়ন করা, সম্ভাব্য দুর্বলতাগুলো চিহ্নিত করা এবং কোড ডেভেলপমেন্টের ক্ষেত্রে সর্বোত্তম অনুশীলন নিশ্চিত করা। বিষয়গুলো সহজে বোঝার সুবিধার্থে, আমরা প্রতিটি উপাদানের ফলাফল আলাদা আলাদাভাবে ভাগ করে উপস্থাপন করেছি। Nym ওয়ালেট নিরীক্ষার সারসংক্ষেপ দেখতে পারেন এখানে।

Oak Security কর্তৃক Nym মিক্সনেট এবং ভেস্টিং চুক্তির নিরীক্ষার সারসংক্ষেপ

২ সপ্তাহ ধরে চলা এই নিরীক্ষায় ৪ জন বিশেষজ্ঞের একটি দল কাজ করেন। Nym টিম Oak Security-কে প্রকল্পের কোডবেস, বিস্তারিত প্রকল্প স্পেসিফিকেশন এবং সহায়ক নথিপত্রের সম্পূর্ণ অ্যাক্সেস প্রদান করেছিল। নিরীক্ষার পরিধির মধ্যে ছিল Nym মিক্সনেট এবং ভেস্টিং চুক্তিগুলোর contracts/mixnet ও contracts/vesting রিপোজিটরি এবং এই চুক্তিগুলোর দ্বারা আমদানিকৃত প্রাসঙ্গিক উপাদানসমূহ।

Oak Security কোডটি পুঙ্খানুপুঙ্খভাবে পর্যালোচনা করেছে, যেখানে নিরাপত্তা দুর্বলতা উন্মোচন, কোডের গুণমান মূল্যায়ন এবং নিরাপদ কোডিং নীতির পরিপালন যাচাই করার জন্য স্বয়ংক্রিয় সোর্স কোড ও ডিপেন্ডেন্সি বিশ্লেষণের পাশাপাশি প্রতিটি লাইন ম্যানুয়ালি পরিদর্শন করা হয়েছে। এই ব্যাপক পদ্ধতির মধ্যে গুরুত্বপূর্ণ ক্ষেত্রগুলোর একটি গভীর বিশ্লেষণ অন্তর্ভুক্ত ছিল, যেমন—রেস কন্ডিশন দুর্বলতা, আন্ডারফ্লো এবং ওভারফ্লো সমস্যা, কি ব্যবস্থাপনা পদ্ধতি, ক্রিপ্টোগ্রাফিক দৃঢ়তা, তথ্য ফাঁসের ঝুঁকি, পাসওয়ার্ড পরিচালনা এবং প্রবেশাধিকার ও অনুমোদন নিয়ন্ত্রণ।

এই নিরীক্ষার মূল লক্ষ্য ছিল প্রোটোকলগুলোর সঠিক কার্যকারিতা নিশ্চিত করা, কোনো শোষণযোগ্য দুর্বলতা বা স্মার্ট চুক্তির ত্রুটি চিহ্নিত করা এবং কোডের নিরাপত্তা ও পঠনযোগ্যতা বৃদ্ধির জন্য প্রয়োজনীয় উন্নতির সুপারিশ করা।

অনুসন্ধানের সংক্ষিপ্ত বিবরণ

Nym মিক্সনেট এবং ভেটিং চুক্তিগুলো উচ্চ পাঠযোগ্যতা ও স্বচ্ছতা দ্বারা বৈশিষ্ট্যমণ্ডিত ছিল এবং এদের নির্ভরযোগ্যতা সমর্থনে শক্তিশালী পরীক্ষা-নিরীক্ষার আওতাও ছিল। তাদের মূল্যায়নে, নিরীক্ষকরা ১৯টি ত্রুটি চিহ্নিত করেছেন, যার মধ্যে ৯টি নিরাপত্তা দুর্বলতা – যেগুলো গুরুতর ও মারাত্মক পর্যায়ের সমস্যা নিয়ে গঠিত – এবং ১০টি সাধারণ দুর্বলতা রয়েছে, যেগুলোকে সামান্য বা তথ্যমূলক হিসেবে শ্রেণিবদ্ধ করা হয়েছে।

Nym টিম দ্রুততার সাথে সকল গুরুতর ও প্রধান সমস্যাগুলোর সমাধান করেছে। Oak নিরাপত্তা টিম আমাদের সমাধানগুলো যাচাই ও অনুমোদন করেছে।

NYM-MIX-VEST-CONTRACT-1: একটি ব্যর্থ epoch বা বিরতিকালীন ঘটনা সম্পাদন epoch-এর অগ্রগতিকে স্থায়ীভাবে অবরুদ্ধ করে দেয় (গুরুতর)

নিরীক্ষায় contracts/mixnet/src/interval/transactions.rs-এ AdvanceCurrentEpoch বার্তাগুলো পরিচালনার ক্ষেত্রে একটি দুর্বলতা চিহ্নিত করা হয়েছে। একটি ধারাবাহিক লুপ সরাসরি লেনদেনের কাঠামোর মধ্যেই সমস্ত অপেক্ষমাণ ইভেন্ট সম্পাদন করে, ফলে একটিমাত্র ইভেন্ট ব্যর্থ হলে পুরো লেনদেনটিই বাতিল হয়ে যেতে পারে, যা প্রোটোকলটিকে স্থবির করে দেয় এবং epoch ও interval-এর অগ্রগতি স্থায়ীভাবে থামিয়ে দেয়।

এটি সমাধানের জন্য নিরীক্ষক দল একটি সাড়া দেওয়ার নীতিসহ উপ-বার্তার মধ্যে ইভেন্ট সম্পাদন প্রক্রিয়াটিকে আবদ্ধ করার সুপারিশ করেছিলেন। এই পদ্ধতিটি পুরো লেনদেন বাতিল না করেই সিস্টেমকে যেকোনো ব্যর্থতা সুন্দরভাবে পরিচালনা করার সুযোগ দিত। তা সত্ত্বেও, আমরা সচেতনভাবে এই সুপারিশটি অনুসরণ না করার সিদ্ধান্ত নিয়েছি। কারণ, ইভেন্ট সম্পাদনের সময় কোনো ব্যর্থতা ঘটার অর্থ হলো সেখানে বড় ধরনের যৌক্তিক ত্রুটি রয়েছে, যা রিওয়ার্ড বিতরণ প্রক্রিয়াকে ঝুঁকিতে ফেলতে পারে। তাই ত্রুটিপূর্ণ অবস্থায় সিস্টেম সচল রাখার ঝুঁকি নেওয়ার চেয়ে, ম্যানুয়াল তদন্তের জন্য epoch-এর অগ্রগতি থামিয়ে দেওয়াটাই বেশি শ্রেয় বলে আমরা মনে করেছি। এর পরিবর্তে, ব্যর্থ epoch অগ্রগতি সনাক্ত করতে এবং আমাদের সতর্কবার্তা পাঠাতে আমরা Nym API-তে একটি উন্নত পর্যবেক্ষণ ব্যবস্থা বাস্তবায়ন করেছি। এই পদ্ধতিটি নিশ্চিত করে যে এ ধরনের ব্যর্থতাগুলো যেন অবিলম্বে চিহ্নিত করা যায়, যা সমস্যা সমাধানের জন্য সময়মতো প্রয়োজনীয় পদক্ষেপ গ্রহণে সহায়তা করে।

NYM-MIX-VEST-CONTRACT-2: আক্রমণকারীরা অনাথ মিক্স নোডগুলোকে তাদের সম্মতি ছাড়াই একটি পরিবারে যোগ দিতে বাধ্য করতে পারে, যাতে একই লেয়ারে বিপুল পরিমাণে সেগুলোকে একত্রিত করা যায় (গুরুতর)।

JoinFamilyOnBehalf বার্তার ক্ষেত্রে একটি দুর্বলতা চিহ্নিত করা হয়েছিল, যা একজন আক্রমণকারীকে কোনো মিক্স নোডের সম্মতি ছাড়াই সেটিকে একটি ফ্যামিলিতে যুক্ত করার সুযোগ দিতে পারত। আক্রমণকারী একটি ক্ষতিকারক ফ্যামিলি তৈরি করে এবং ভুক্তভোগী মিক্স নোডের প্রাইভেট কি দ্বারা স্বাক্ষরিত আইডেন্টিটি কি-কে স্বাক্ষর হিসেবে ব্যবহার করে মিক্স নোডটিকে সেই ফ্যামিলির মধ্যে আটকে ফেলতে পারত। এটি সম্ভাব্যভাবে একজন আক্রমণকারীকে অনাথ মিক্স নোডগুলোকে একটি একক ফ্যামিলিতে দলভুক্ত করার সুযোগ দিত, যা একই স্তরের নোডগুলোর কেন্দ্রীকরণ ঘটিয়ে নেটওয়ার্কের কার্যকারিতা ব্যাহত করত এবং রাউটিংকে প্রভাবিত করার ক্ষেত্রে আক্রমণকারীর সম্ভাবনা বাড়িয়ে দিত।

JoinFamilyOnBehalf বার্তার এই দুর্বলতা দূর করতে চুক্তির স্বাক্ষর প্রক্রিয়াটি নতুন করে ডিজাইন করা হয়েছে। শুধুমাত্র মিক্স নোডের আইডেন্টিটি স্বাক্ষর করার পরিবর্তে, একটি স্পষ্ট উদ্দেশ্য এবং একটি অনন্য ননস সম্বলিত বার্তা অন্তর্ভুক্ত করার জন্য স্বাক্ষর ব্যবস্থাটি আপডেট করা হয়েছে। এই পরিবর্তনটি নিশ্চিত করে যে স্বাক্ষরগুলি পুনরায় ব্যবহার বা পুনরায় চালানো যাবে না।

NYM-MIX-VEST-CONTRACT-3: TrackUndelegation মেসেজ হ্যান্ডলিং-এ অনিয়ন্ত্রিত পুনরাবৃত্তি ব্যবহারকারীকে আনডেলিগেট করতে অক্ষম করে তুলতে পারে, যা epoch অগ্রগতিকেও স্থায়ীভাবে বাধাগ্রস্ত করে (গুরুতর)।

TrackUndelegation বার্তার এই সীমাহীন পুনরাবৃত্তি, প্রচুর পরিমাণে ডেলিগেশন থাকা অ্যাকাউন্টগুলো পরিচালনা করার সময় গ্যাস শেষ হওয়ার কারণ হতে পারে, যা ব্যবহারকারীদের আনডেলিগেট করতে বাধা দেবে। এই ব্যর্থতা epoch-এর অগ্রগতিকেও থামিয়ে দেবে, যার ফলে প্রোটোকলটি তার বর্তমান অবস্থায় আটকে থাকবে।

এই সমস্যাটি সমাধানের জন্য, আমরা প্রতি অ্যাকাউন্টে সর্বোচ্চ ২৫টি ভেস্টিং ডেলিগেশনের একটি সীমা নির্ধারণ করেছি। তৎকালীন সময়ে সর্বোচ্চ সংখ্যক ভেস্টিং ডেলিগেশনের যে রেকর্ড ছিল, তার ওপর ভিত্তি করেই এই সমাধানটি করা হয়েছিল।

আপডেট: ২০২৪ সাল থেকে ভেস্টিং ডেলিগেশন করার সুবিধাটি সম্পূর্ণভাবে নিষ্ক্রিয় করা হয়েছে।

NYM-MIX-VEST-CONTRACT-4: একজন আক্রমণকারী BondMixnodeOnBehalf ও CreateFamilyOnBehalf বার্তাগুলোর আগে নিজের বার্তা সম্পাদন করতে পারে এবং সেগুলোর পে-লোড পরিবর্তন করতে পারে (গুরুতর)

এই দুর্বলতাটি একজন আক্রমণকারীকে BondMixNodeOnBehalf এবং CreateFamilyOnBehalf বার্তাগুলোর আগে নিজের বার্তা সম্পাদন করার, স্বাক্ষরটি হাতিয়ে নেওয়ার এবং পে-লোড পরিবর্তন করার সুযোগ দেবে। BondMixNodeOnBehalf-এর ক্ষেত্রে, আক্রমণকারী নিজেকে প্রক্সি হিসেবে সেট করতে পারে, যার ফলে সে নিবন্ধিত বন্ডের ওপর পূর্ণ নিয়ন্ত্রণ পেয়ে যাবে।

এই দুর্বলতা দূর করতে আমরা দ্বিমুখী সমাধান বাস্তবায়ন করেছি। প্রথমত, আমরা NYM-MIX-VEST-CONTRACT-2 এ বর্ণিত স্বাক্ষর তৈরির পরিবর্তনগুলো এখানেও প্রয়োগ করেছি, যা একটি স্পষ্ট উদ্দেশ্য এবং একটি অনন্য ননস যুক্ত করেছে। দ্বিতীয়ত, আমরা আইনি প্রক্সি অ্যাড্রেসটিকে শুধুমাত্র ভেস্টিং অ্যাকাউন্টের মধ্যেই সীমাবদ্ধ করে দিয়েছি, যা নিশ্চিত করে যে আক্রমণকারীরা নিজেদের প্রক্সি হিসেবে সেট করতে পারবে না এবং নিবন্ধিত বন্ডগুলোর ওপর অননুমোদিত নিয়ন্ত্রণ নিতে পারবে না।

আপডেট: ২০২৪ সাল থেকে সমস্ত প্রক্সি কার্যক্রম নিষ্ক্রিয় করা হয়েছে, যার ফলে এই আক্রমণটি এখন আর কার্যকর নয়।

NYM-MIX-VEST-CONTRACT-5: ব্যবহারকারীদের ছদ্মবেশ ধারণ করার জন্য "অন্যের পক্ষে" লেনদেনের মধ্যে স্বাক্ষর পুনরায় ব্যবহার করা যেতে পারে (গুরুতর)

এই দুর্বলতাটি "অন্যের পক্ষে" লেনদেনের মধ্যে স্বাক্ষর পুনরায় ব্যবহার করার সুযোগ দেয়, যা আক্রমণকারীদের ব্যবহারকারীদের ছদ্মবেশ ধারণ করতে সাহায্য করে। যেহেতু স্বাক্ষরগুলোতে শুধুমাত্র মূল ডেটা থাকে এবং ননস বা বার্তা শনাক্তকারীর মতো কোনো অতিরিক্ত মেটাডেটা থাকে না, তাই একজন আক্রমণকারী ফ্যামিলি মেম্বারদের জোরপূর্বক সরিয়ে দেওয়ার জন্য একটি বার্তার স্বাক্ষর অন্য বার্তায় পুনরায় ব্যবহার করতে পারে। তাছাড়া, আক্রমণকারীরা একই ধরনের বার্তার জন্য স্বাক্ষর পুনরায় ব্যবহার করতে পারে, যার ফলে একজন সদস্য একই স্বাক্ষর ব্যবহার করে একাধিকবার একটি ফ্যামিলিতে পুনরায় যোগ দিতে পারে।

এই সমস্যার সমাধানটি NYM-MIX-VEST-CONTRACT-4-এ বাস্তবায়িত সমাধানের অনুরূপ।

NYM-MIX-VEST-CONTRACT-6: (মালিক, প্রক্সি) জোড়ার জন্য কী জেনারেশন সংঘর্ষের কারণ হতে পারে (গুরুতর)

এই দুর্বলতাটি দুটি ভিন্ন (মালিক, প্রক্সি) অ্যাড্রেস জোড়াকে generate_owner_storage_subkey ফাংশনে একই XOR ফলাফল তৈরি করার সুযোগ দেয়, যা কি কলিশন এবং ডেটা ওভাররাইট হওয়ার ঝুঁকি তৈরি করতে পারে।

NYM-MIX-VEST-CONTRACT-4-এ আইনি প্রক্সিকে শুধুমাত্র ভেস্টিং চুক্তির অ্যাড্রেসের মধ্যে সীমাবদ্ধ করার যে সমাধানটি প্রয়োগ করা হয়েছিল, তা এই দুর্বলতাটিও দূর করে। XOR অপারেশনটি সর্বদা একটি নির্দিষ্ট স্ট্রিং-এর বিপরীতে সম্পন্ন হওয়া নিশ্চিত করার মাধ্যমে, এই পরিবর্তনটি কার্যকরভাবে সংঘর্ষের ঝুঁকি সম্পূর্ণরূপে নির্মূল করে।

NYM-MIX-VEST-CONTRACT-7: একই ব্লকের মধ্যে একাধিক ডেলিগেশন প্রসেস করা হলে track_delegation বিদ্যমান ডেলিগেশন ওভাররাইট করে ফেলতে পারে (গুরুতর)

এই সমস্যাটি একই ব্লকের মধ্যে একাধিক ডেলিগেশন করা হলে কি কলিশন ঘটার সুযোগ তৈরি করত। এর ফলে সম্ভাব্যভাবে save_delegation ফাংশনটি একটি বিদ্যমান ডেলিগেশন ওভাররাইট করে ফেলতে পারত, যার দরুন আগের ডেলিগেশনটি হারিয়ে যেত।

এই সমস্যাটি সমাধানের জন্য, আমরা save_delegation ফাংশনের লজিক পরিবর্তন করেছি যাতে নতুন ডেলিগেশনটি সংরক্ষণ করার আগে প্রথমে বিদ্যমান ডেলিগেশনের পরিমাণটি পড়ে নেওয়া হয়। যদি একই কি-এর জন্য ইতিমধ্যেই কোনো ডেলিগেশন থেকে থাকে, তবে আমরা বর্তমান পরিমাণটি উদ্ধার করি, সেটির সাথে নতুন ডেলিগেশনটি যোগ করি এবং তারপর আপডেট হওয়া মোট পরিমাণটি সংরক্ষণ করি; যা নিশ্চিত করে যে কোনো বিদ্যমান ডেলিগেশন ওভাররাইট হবে না।

NYM-MIX-VEST-CONTRACT-8: বন্ড যদি কোনো প্রক্সি দ্বারা "অন্যের পক্ষে" তৈরি করা হয়, তবে বন্ডের মালিক কোনো অপারেশন সম্পাদন করতে পারেন না (গুরুত্বপূর্ণ)

এই সমস্যাটি বন্ডের মালিককে তাদের বন্ডের ওপর যেকোনো অপারেশন সম্পাদন করতে বাধা দিত, যদি বন্ডটি "অন্যের পক্ষে" তৈরি করা হয়ে থাকে এবং বর্তমান লেনদেনটি প্রক্সির পরিবর্তে সরাসরি মালিক দ্বারা শুরু করা হয়। যেহেতু প্রক্সিটি হ্যাক বা হারিয়ে যেতে পারত এবং মালিকের পক্ষে সেটি পরিবর্তন করার কোনো উপায় ছিল না, তাই এর ফলে বন্ডের ওপর মালিক তাদের নিয়ন্ত্রণ হারিয়ে ফেলতে পারতেন।

আমরা এটিকে কোনো সমস্যা মনে করি না, কারণ এটি ডিজাইন অনুযায়ী একটি ইচ্ছাকৃত আচরণ। যখন ভেস্টিং চুক্তির মাধ্যমে কোনো মিক্স নোড বন্ড করা হয় (অথবা ডেলিগেশন করা হয়), তখন সেই বন্ড বা ডেলিগেশনের সাথে পরবর্তী সমস্ত মিথস্ক্রিয়া শুধুমাত্র ভেস্টিং চুক্তির মাধ্যমেই সম্পাদিত হবে বলে আশা করা হয়।

আপডেট: ২০২৪ সাল থেকে ভেস্টিং চুক্তিটি সরিয়ে দেওয়া হয়েছে।

NYM-MIX-VEST-CONTRACT-9: উল্লেখযোগ্য সংখ্যক মিক্স নোড কোনো ফ্যামিলির সদস্য হলে LeaveFamily এবং LeaveFamilyOnBehalf বার্তাগুলোর সম্পাদন ব্যর্থ হতে পারে (গুরুত্বপূর্ণ)

এই সমস্যাটির কারণে MEMBERS ম্যাপে থাকা বিপুল সংখ্যক ফ্যামিলি মেম্বারদের ওপর ইটারেট করার সময় অতিরিক্ত গ্যাস খরচের ফলে LeaveFamily এবং LeaveFamilyOnBehalf বার্তাগুলোর সম্পাদন ব্যর্থ হতে পারত। এর ফলে মিক্স নোডগুলো কোনো ফ্যামিলি ছেড়ে বের হতে পারত না, যা কার্যত তাদের বর্তমান ফ্যামিলিতেই আটকে রাখত।

সমাধান: এই সমস্যাটি দূর করতে লজিকটি পুনর্গঠন করা হয়েছে, যার ফলে এখন সরাসরি MEMBERS ম্যাপ অ্যাক্সেস করে একটি মিক্স নোডের সদস্যপদ যাচাই করা যায়। এই পরিবর্তনের ফলে লুপ বা ইটারেট করার প্রয়োজনীয়তা দূর হয়েছে, যা আউট-অফ-গ্যাস ত্রুটির কারণ হতে পারত। এর মাধ্যমে এটি নিশ্চিত হয়েছে যে, ফ্যামিলিতে অনেক সদস্য থাকা সত্ত্বেও সদস্যরা সফলভাবে ফ্যামিলি ছেড়ে বের হতে পারবেন।

আপডেট: ২০২৪ সাল থেকে নোড ফ্যামিলি ফিচারটি সরিয়ে দেওয়া হয়েছে।

শেষ কথা

আমরা এই নিরীক্ষা প্রক্রিয়া জুড়ে Oak Security টিমকে তাদের দক্ষতা এবং নিষ্ঠার জন্য আন্তরিক ধন্যবাদ জানাতে চাই। সেই সাথে, নিরীক্ষার পরিকল্পনা ও বাস্তবায়ন—উভয় পর্যায়েই তাদের দেখানো সহযোগিতা ও পেশাদারিত্বের আমরা উচ্চ প্রশংসা করি। নিরাপত্তার প্রতি আমাদের চলমান প্রতিশ্রুতি সর্বদা আমাদের শীর্ষ অগ্রাধিকার হিসেবে থাকবে। আমাদের ইকোসিস্টেমের সর্বোচ্চ মান বজায় রাখতে আমরা আগামীতেও নিরাপত্তা বিশেষজ্ঞদের সাথে এই ধরনের অংশীদারিত্ব অব্যাহত রাখার জন্য আশাবাদী।