বিওসিন সোলানা অ্যানকর ফ্রেমওয়ার্কের লো-ভার্শনে গুরুতর আইডিএল নির্দেশনা দুর্বলতা প্রকাশ করেছে

iconMetaEra
শেয়ার
AI summary iconসারাংশ
বিওসিনের সিকিউরিটি টিম লো-ভার্শন সোলানা অ্যানকর ফ্রেমওয়ার্কে একটি গুরুতর আইডিএল ইনস্ট্রাকশন ভালনারেবিলিটি শনাক্ত করেছে। এই ত্রুটির কারণে আক্রমণকারীরা AccountInfo ডিক্লেরেশন ব্যবহার করে প্রোগ্রাম-অনুসৃত PDA অ্যাকাউন্ট হ্যাক করতে পারে, যার ফলে ব্যবহারকারীর অনুমতি ছাড়াই দুই ধাপে ফান্ড চুরি করা সম্ভব। এই ঘটনাটি স্মার্ট চুক্তি বিকাশে একটি শক্তিশালী কমপ্লায়েন্স ফ্রেমওয়ার্কের প্রয়োজনীয়তা তুলে ধরে। MiCA (ইউরোপীয় ক্রিপ্টো-অ্যাসেটস মার্কেটস রেগুলেশন) আসন্ন হওয়ায়, এই ধরনের ভালনারেবিলিটি রিয়েল-টাইম সিকিউরিটি অডিট এবং নিয়ামক মানদণ্ডের সঙ্গে পালনের গুরুত্বকে আরও বেশি জোর দিয়েছে।

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

বিওসিন সিকিউরিটি টিম একটি গুরুত্বপূর্ণ ভালনের প্যাটার্ন প্রকাশ করবে: অ্যানকরের পুরানো সংস্করণে, ডেভেলপাররা যখন প্রোগ্রাম-অনুমোদিত PDA অ্যাকাউন্ট ঘোষণা করতে AccountInfo ব্যবহার করেন, তখন আক্রমণকারীরা অ্যানকর দ্বারা স্বয়ংক্রিয়ভাবে ইনজেক্ট করা IDL নির্দেশনা ব্যবহার করে শুধুমাত্র দুটি ধাপে অ্যাকাউন্টের নিয়ন্ত্রণ দখল করতে পারে এবং এর মধ্যে সমস্ত SOL খালি করে দিতে পারে, এই প্রক্রিয়ায় কোনও বিশেষ অধিকারের প্রয়োজন হয় না।

এক, আইডিএল নির্দেশনা এবং সংশ্লিষ্ট কার্যপ্রণালী বিশ্লেষণ

1.1 আইডিএল নির্দেশনা

অ্যানকর ডিফল্টরূপে প্রতিটি প্রোগ্রামে একটি আইডিএল (ইন্টারফেস ডিফিনিশন ল্যাঙ্গুয়েজ, ইন্টারফেস সংজ্ঞায়ন ভাষা) পরিচালনা নির্দেশনা ইনজেক্ট করে, যদি না বিল্ডের সময় no-idl ফিচারটি স্পষ্টভাবে সক্রিয় করা হয়। এই নির্দেশনাগুলি হল:

IdlCreateAccount: একটি চেইন-অন আইডিএল অ্যাকাউন্ট তৈরি করুন

IdlWrite: আইডিএল অ্যাকাউন্ট / বাফার অ্যাকাউন্টে ডেটা লিখুন

IdlSetAuthority: আইডিএল অ্যাকাউন্টের অথরিটি (নিয়ন্ত্রক) পরিবর্তন করুন

IdlCloseAccount: আইডিএল অ্যাকাউন্ট বন্ধ করুন এবং এর সমস্ত ল্যামপোর্টস নির্দিষ্ট গ্রহণকারীকে স্থানান্তর করুন

IdlResizeAccount: আইডিএল অ্যাকাউন্টের আকার পরিবর্তন করুন

IdlCreateBuffer: আইডিএল বাফার অ্যাকাউন্ট (আইডিএল বাফার) তৈরি করুন

IdlSetBuffer: বাফার অ্যাকাউন্টের ডেটা দিয়ে প্রোডাকশন IDL অ্যাকাউন্ট ওভাররাইট করুন

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

1.2 আইডিএল বাফার অ্যাকাউন্ট

IDL বাফার অ্যাকাউন্ট (IDL Buffer) হল Anchor দ্বারা বড় IDL ডেটা পর্যায়ক্রমে আপলোড করার জন্য প্রবর্তিত একটি অস্থায়ী অ্যাকাউন্ট। যেহেতু সম্পূর্ণ IDL (JSON-এ সংকুচিত) একক ট্রানজেকশনের আকারের সীমা অতিক্রম করতে পারে, Anchor প্রথমে IdlCreateBuffer ব্যবহার করে একটি বাফার তৈরি করতে দেয়, তারপর IdlWrite এর মাধ্যমে একাধিক ট্রানজেকশনে বাফারে লিখতে দেয়, এবং শেষে IdlSetBuffer ব্যবহার করে একবারে সম্পূর্ণ ডেটা জমা দেয়।

IDL অ্কাউন্ট / বাফার অ্কাউন্টের ডেটা স্ট্রাকচারের মূল বিষয়: এটি একটি ফিক্সড লেআউটের হেডার দিয়ে শুরু হয়, যার মধ্যে authority: Pubkey ফিল্ড রয়েছে (এই পরীক্ষার আউটপুটে এটিকে controller বলা হয়েছে)। IDL ইনস্ট্রাকশন এই ফিল্ডের মাধ্যমে বুঝতে পারে “কে এই অ্কাউন্টের উপর কাজ করার অধিকারী”।

কিন্তু সমস্যাটি হলো: পুরনো সংস্করণের Anchor-এর IdlCreateBuffer প্রক্রিয়াটি প্রবেশ করানো যেকোনো অ্যাকাউন্টকে বাফার অ্যাকাউন্ট হিসেবে ইনিশিয়ালাইজ করে, যা এই প্রোগ্রামের মালিকানাধীন, এবং authority-কে সরাসরি ট্রানজেকশনের স্বাক্ষরকারীতে সেট করে। অর্থাৎ, যদি কোনো অ্যাকাউন্টের owner এই প্রোগ্রাম হয় (যেমন: প্রোগ্রামের PDA ট্রেজারি), তবে আক্রমণকারী নিজেকে এর controller হিসেবে লিখে ফেলতে পারবে, এবং তারপর IdlCloseAccount ব্যবহার করে অ্যাকাউন্টের সমস্ত SOL-কে আইনসম্মতভাবে সরিয়ে ফেলতে পারবে।

1.3 ভেদযোগ্যতার ট্রিগার শর্ত

দুর্বলতাটি সক্রিয় করতে নিম্নলিখিত শর্তগুলি একসাথে পূরণ করা প্রয়োজন:

  • পুরানো সংস্করণের Anchor ব্যবহার করুন: বিপজ্জনক IDL নির্দেশনা পর্যাপ্ত অ্যাকাউন্ট পরীক্ষা করে না, যার ফলে ব্যবসায়িক অ্যাকাউন্টকে IDL অ্যাকাউন্ট হিসেবে ভুল করে পরিচালনা করা হয়।
  • no-idl সক্ষম নয়: প্রোগ্রামটি বিল্ড করার সময় ডিফল্ট ইনজেক্টেড IDL ইনস্ট্রাকশন এন্ট্রি রাখে, যা আক্রমণের ক্ষেত্রকে বাইরের দিকে প্রকাশ করে।
  • AccountInfo ব্যবহার করে প্রোগ্রামের স্বত্বাধিকারী PDA ঘোষণা করা: ডেভেলপাররা ব্যবহার করেন সরাসরি AccountInfo টাইপের অ্যাকাউন্ট (যেমন: ট্রেজারি PDA), যা Anchor-এর টাইপড অ্যাকাউন্ট (যেমন: Account) দ্বারা সরবরাহকৃত discriminator / owner চেক বহন করে না, যার ফলে এই অ্যাকাউন্টটি IDL নির্দেশের দৃষ্টিতে IDL অ্যাকাউন্টের সাথে “অবিভাজ্য” হয়ে যায়।
  • অ্যাকাউন্টটি প্রোগ্রামের মালিকানাধীন এবং ল্যামপার্টস ধারণ করে: owner == এই প্রোগ্রাম হল IDL নির্দেশনা দ্বারা এটি পরিচালনা করার শর্ত; SOL ধারণ করলেই এটি শূন্য করার মূল্য থাকে।

উপরের শর্তগুলি পূরণ করার পরে, আক্রমণকারীকে শুধুমাত্র দুটি সাধারণ লেনদেন করতে হবে: প্রথমে IdlCreateBuffer দিয়ে controller নিয়ে নেওয়া, তারপর IdlCloseAccount ব্যবহার করে সমস্ত SOL স্থানান্তর করা, যার জন্য লক্ষ্য প্রোগ্রাম কোনও অনুমতি প্রদান করতে হয় না।

1.4 আক্রমণ চেইন

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

আক্রমণ প্রক্রিয়ার সারাংশ

ধাপ ১: IdlCreateBuffer(treasury, signer = attacker)    
└─ treasury.controller  ==>  attacker   (নিয়ন্ত্রক হয়ে যায়) 
ধাপ ২: IdlCloseAccount(treasury, authority = attacker, dest = attacker)  
  └─ treasury.lamports    ==>  attacker   (কোষ থেকে সমস্ত টাকা সরিয়ে নেওয়া হয়)

প্রথম ধাপ: IdlCreateBuffer দ্বারা কর্তৃত্ব অর্জন

অ্যানকরের অভ্যন্তরীণ বাস্তবায়ন প্রায় এরকম:

#[derive(Accounts)]pub struct IdlCreateBuffer {  
#[account(zero)]          // ← Key: একটি অ্যাকাউন্ট যার ডিসক্রিমিনেটর সব 0  pub buffer: Account,  
pub authority: Signer,}    
pub fn idl_create_buffer(ctx: Context) -> Result 
{ 
 let idl = &mut ctx.accounts.buffer;  idl.authority = *ctx.accounts.authority.key; // অথরিটি হিসেবে আক্রমণ সেট করুন  Ok(())}

#[account(zero)] এর অর্থ হলো: একটি ডিসক্রিমিনেটর সম্পূর্ণ শূন্য এবং প্রোগ্রাম দ্বারা স্বামিত্বে থাকা অ্যাকাউন্টকে অনিনিয়োজিত IDL অ্যাকাউন্ট হিসেবে ইনিশিয়ালাইজ করা। এবং ভল্ট ঠিক এই দুটি শর্তই পূরণ করে:

ভল্টের অবস্থা

শর্তাবলী

প্রোগ্রাম দ্বারা স্বত্বাধিকারী

init_if_needed এর পরে মালিক এই প্রোগ্রামে সেট করা হয়েছে

ডিসক্রিমিনেটর সম্পূর্ণ শূন্য

অ্যাকাউন্টইনফো টাইপ ব্যবহার করে, অ্যানকর ডিসক্রিমিনেটর লিখবে না, ডেটা সম্পূর্ণ শূন্য

অতএব আক্রমণকারী ভল্টটিকে IdlCreateBuffer-এ পাঠানোর পর:

  • অ্যানকর ভল্টের আগে 8 বাইটে ইডিএলএকাউন্টের ডিসক্রিমিনেটর লিখুন;
  • আক্রমণকারীর পাবলিক কীটি authority ফিল্ডে লিখুন।

এখন পর্যন্ত, ভল্টটিকে একটি আক্রমণকারীকে কেন্দ্র করে তৈরি IdlAccount হিসাবে "প্রতারণা" করা হয়েছে—এবং এর ভিতরের SOL একটি মাত্র টুকরোও নড়েনি।

দ্বিতীয় ধাপ: IdlCloseAccount —— ফান্ড খালি করুন

#[derive(Accounts)] pub struct IdlCloseAccount { #[account(mut, has_one = authority)] // ← যাচাই করুন যে authority == signer pub account: Account, pub authority: Signer, #[account(mut)] pub destination: AccountInfo, // ← আক্রমণের ওয়ালেট}

এখন ভল্টটি সম্পূর্ণরূপে যাচাইকৃত হয়েছে:

  • ডিসক্রিমিনেটর আইডিএল অ্যাকাউন্টের সাথে মেলে
  • authority ফিল্ড = আক্রমণকারীর পাবলিক কী
  • has_one = ক্ষমতা যাচাই সফল

সুতরাং ভল্টের সমস্ত ল্যামপোর্টস (ব্যবহারকারী জমা দেওয়া সমস্ত SOL) আইনগতভাবে আক্রমণকারীর অ্যাকাউন্টে স্থানান্তরিত হয়েছে, ভল্টটি শূন্য হয়ে গেছে।

মূল কারণ:

deposit.rs-এ টাইপড অ্যান্কর অ্যাকাউন্টের পরিবর্তে AccountInfo ব্যবহার করা এই ভুলের মূল কারণ:

(1) প্রকারের অ্যাকাউন্ট (যেমন Account) ইনিশিয়ালাইজেশনের সময় এই স্ট্রাকচারের জন্য বিশেষ 8 বাইট ডিসক্রিমিনেটর লিখবে;

(2) নিজের discriminator লেখার পরে, Anchor এটিকে IdlAccount হিসাবে ব্যবহার করতে পারবে না (discriminator মেলে না), তাই প্রথম ধাপের IdlCreateBuffer ব্যর্থ হবে এবং আক্রমণ শৃঙ্খল বিচ্ছিন্ন হয়ে যাবে।

দ্বিতীয়: কেস স্টাডি

এই পরীক্ষাগুলি Anchor 0.31.0 এর উপর ভিত্তি করে তৈরি ক্রস-চেইন ব্রিজ স্মার্ট চুক্তির PoC এর উপর ভিত্তি করে। পরীক্ষাটি একটি প্রকৃত ব্রিজ ট্রেজারি (Bridge Treasury) কে সিমুলেট করে, যার মালিক ব্রিজ প্রোগ্রাম, যাতে ব্যবহারকারীদের দ্বারা জমা দেওয়া 1.001281 SOL রয়েছে। আক্রমণকারীর ওয়ালেটে প্রাথমিকভাবে 2 SOL রয়েছে, এবং এতে কোনও বিশেষাধিকার নেই।

প্রকল্প

মান / বর্ণনা

ব্রিজ প্রোগ্রাম

CJutNlr8d3oxdb11ReOLaZd5jPsqUxgwt2mv5e7equtE

ট্রেজারি অ্যাকাউন্ট

DxGkzaMhP5Wy824GhoehErdD6MudfuEPGPwaV2s77FsM

কুকিন মালিক

= ব্রিজ প্রোগ্রাম (প্রোগ্রাম-অনুমোদিত PDA)

কুকিন প্রাথমিক ব্যালেন্স

1.001281 SOL (ব্যবহারকারী দ্বারা জমা করা অর্থ)

প্রাথমিক নিয়ন্ত্রক

0x0000...0000 (সম্পূর্ণ শূন্য, সেট করা হয়নি)

আক্রমণকারীর ওয়ালেটের প্রাথমিক ব্যালেন্স

2.000000 SOL

প্রয়োজনীয় অধিকার

কোনও অনুমতি প্রয়োজন নেই

ট্রেড সংখ্যা

2টি

কুকিন ফাইনাল ব্যালেন্স

0.000000 SOL (খালি করা হয়েছে)

আক্রমণকারী লাভ করেছেন

+1.001281 SOL

PoC চলাকালীন স্ক্রিনশট (tests/poc-idl-hijack.ts):

https://wdcdn.qpic.cn/MTMxMDI3MDE1MTgxMDU0NzA_812435_a37-yrU_dY02i1_I_1785900257?w=1080&h=1287

দেখা যাচ্ছে, ধাপ 1-এর IdlCreateBuffer আক্রমণকারীকে গুদামের কন্ট্রোলার হিসেবে সেট করে (ব্যালেন্স অপরিবর্তিত রাখে); ধাপ 2-এর IdlCloseAccount গুদাম থেকে 1.001281 SOL সম্পূর্ণভাবে আক্রমণকারীর ওয়ালেটে স্থানান্তরিত করে, যার ফলে গুদামের ব্যালেন্স শূন্য হয়ে যায়।

সংশোধন/সুরক্ষা পরামর্শ:

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

(2) নো-আইডিএল সক্ষম করে বিল্ড করুন: উৎপাদন পরিবেশের জন্য ইডিএল নির্দেশ ইনজেকশন সক্ষম করুন, যাতে এই আক্রমণের ক্ষেত্রটি মূল থেকেই অপসারণ করা যায়।

(3) বিশুদ্ধ AccountInfo-এর পরিবর্তে টাইপড অ্যাকাউন্ট ব্যবহার করুন: অ্যাকাউন্ট / সিস্টেমঅ্যাকাউন্ট ইত্যাদি ডিসক্রিমিনেটর এবং মালিক যাচাইকৃত টাইপ ব্যবহার করে ফান্ড অ্যাকাউন্ট বহন করুন, যাতে IDL নির্দেশ এটিকে ভুলভাবে চিহ্নিত না করে।

(4) সর্বনিম্ন পরিমাণে প্রোগ্রামের মালিকানাধীন খালি করা যায় এমন অ্যাকাউন্ট: ফান্ড জমা রাখা PDA-তে স্পষ্ট owner / seeds / discriminator সীমাবদ্ধতা যোগ করুন এবং গুরুত্বপূর্ণ নির্দেশে অ্যাকাউন্ট ডিসক্রিমিনেটর যাচাই করুন।

শেষ কথা

এই ভেদ্যতা মূলত “ফ্রেমওয়ার্ক লুকানো নির্দেশ + অ্যাকাউন্ট টাইপ চেক অনুপস্থিতি” এর সংমিশ্রণ। ডেভেলপারদের অবশ্যই বুঝতে হবে যে Anchor ডিফল্টভাবে ইনজেক্ট করা IDL নির্দেশগুলি বাস্তবিক আক্রমণের ক্ষেত্র, ফ্রেমওয়ার্কের সংস্করণ আপগ্রেড করা এবং ফান্ড অ্যাকাউন্টগুলিতে স্ট্রং-টাইপড কনস্ট্রেইন্ট প্রয়োগ করলে এই ধরনের অননুমোদিত ফান্ড প্রতারণা প্রতিরোধ করা যায়।

Beosin একটি শীর্ষস্থানীয় ব্লকচেইন নিরাপত্তা এবং নিয়ন্ত্রণ পালন প্রযুক্তি কোম্পানি, যা প্রকল্প লঞ্চের আগে স্মার্ট চুক্তির নিরাপত্তা অডিট, প্রকল্প চলাকালীন নিরাপত্তা ঝুঁকি মনিটরিং এবং বন্ধকরণ, চুরি করা সম্পদ ফেরত পাওয়া, ভার্চুয়াল সম্পদের বিপদের বিরুদ্ধে ধোঁকাধন (AML) এবং তদন্ত-অনুসরণের উপর ফোকাস করে। Beosin বিশ্বের 20টিরও বেশি দেশ এবং অঞ্চলের নিয়ন্ত্রণকারী এবং বাহিনী সংস্থা, 200টিরও বেশি ভার্চুয়াল সম্পদ সেবাদানকারী এবং 4500টিরও বেশি Web3 প্রকল্পকে “এক-স্টপ” ব্লকচেইন কমপ্লায়েন্স পণ্য + নিরাপত্তা সেবা প্রদান করেছে। আমাদের সাথে যোগাযোগের জন্য গিটহাবের মেসেজ বক্সে ক্লিক করুন।

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