eMudhra ইভেন্টের পর টেকু এবং বেসু তাদের প্রতিটি ডকার ইমেজ আপডেট করেছে, কারণ দুর্বল সার্টিফিকেট কী বাহ্যিক সেবার সাথে সংযোগ স্থাপনকারী সফটওয়্যারের জন্য ঝুঁকি তৈরি করেছিল, যার মধ্যে কিছু ইথারিয়াম ভেরিফায়ার ডিপ্লয়মেন্টও অন্তর্ভুক্ত ছিল।
- eMudhra ঘটনার কারণে Teku 26.10.3 এবং Besu 26.10.2 ডকার ইমেজ থেকে প্রভাবিত সার্টিফিকেট ট্রাস্ট সরিয়ে দেওয়া হয়েছে।
- Teku বলেছে, ডিফল্ট মেইননেট নোডগুলি প্রভাবিত হয়নি, এবং প্রকৃত প্রকাশের মাত্রা HTTPS কানেকশন এবং অপারেটর দ্বারা ব্যবহৃত জাভা রানটাইমের উপর নির্ভর করে।
- প্রকাশিত ঝুঁকিগুলি প্রতারণামূলক সেবা এবং যাচাইকারী অপারেশন সম্পর্কিত, এবং টেকুর বিজ্ঞপ্তিতে কোনো দুর্বলতা ব্যবহারের কথা উল্লেখ করা হয়নি।
অপারেটরদের জন্য বর্তমানে সবচেয়ে সরাসরি প্রশ্নটি হল: অন্যান্য সেবাগুলির সাথে সংযোগ করার সময় তাদের সফটওয়্যার কি প্রতারক সার্টিফিকেট গ্রহণ করবে? উত্তরটি ব্যবহৃত সংযোগ এবং Java ইনস্টলেশনের উপর নির্ভর করে, তাই ক্লায়েন্ট আপডেট করা প্রতিটি ভেরিফায়ারকে একই ঝুঁকির মুখোমুখি হতে বাধ্য করে না।
Teku এবং Besu ডকার ইমেজ আপডেট করুন
এথেরিয়াম ক্লায়েন্ট টিম একটি ব্লকচেইনের বাইরে শুরু হওয়া সার্টিফিকেট সমস্যা সমাধানের জন্য আপডেট প্রকাশ করেছে। সংশ্লিষ্ট পরিবর্তনগুলি দূরবর্তী সেবা কি প্রকৃত কিনা তা সফটওয়্যার কিভাবে নির্ধারণ করে তার সাথে সম্পর্কিত।
Teku 26.10.3 এবং Besu 26.10.2 এর ডকার ইমেজ থেকে প্রভাবিত সার্টিফিকেট রুটগুলির বিশ্বাস সরিয়ে নেওয়া হয়েছে। এই প্রকাশটি eMudhra সার্টিফিকেট অথরিটির সাথে সম্পর্কিত দুর্বল কী আবিষ্কারের ফলে হয়েছে।
ভেরিফায়ার অপারেটরদের জন্য সমস্যা হলো আক্রমণকারীরা সফটওয়্যার যে সেবার সাথে সংযুক্ত হয় তার প্রতারণা করা। সেবাটির ভূমিকা অনুযায়ী, মিথ্যা প্রতিক্রিয়া দায়িত্বগুলি বিকল্প করতে পারে বা কিছু ব্লক ফির প্রদানের দিকে প্রভাব ফেলতে পারে।
কিন্তু এর অর্থ এই নয় যে প্রতিটি এথারিয়াম ভেরিফায়ার ঝুঁকির মধ্যে রয়েছে। টেকুর নিরাপত্তা নোটিশে বলা হয়েছে যে ডিফল্ট মেইননেট নোডগুলি প্রভাবিত হয়নি, এবং এখনও কোনো দুর্বলতা ব্যবহারের প্রতিবেদন করা হয়নি।
পার্থক্যটি ইনস্টলেশন পদ্ধতিতে। বাহ্যিক HTTPS সেবা ব্যবহারকারীদের অবশ্যই সেই সংযোগগুলি পরীক্ষা করতে হবে যেগুলি সম্পূর্ণ স্থানীয়ভাবে ডিপ্লয় করা উপাদানগুলিতে অনুপস্থিত হতে পারে।
এই আপডেটগুলি নির্দিষ্ট ইনস্টলেশন পরিবেশের জন্য প্রযোজ্য। প্যাচযুক্ত ডকার ইমেজে কন্টেইনারের ভিতরে রানটাইম পরিবর্তনগুলি প্যাকেজ করা হয়েছে, যখন আর্কাইভ ফাইল থেকে ইনস্টল করা সফটওয়্যারটি অপারেটর দ্বারা প্রদানকৃত Java ব্যবহার করতে পারে।
এই ঘটনাটি ভেরিফায়ারদের চারপাশের ইনফ্রাস্ট্রাকচারকে প্রভাবিত করেছে, যেখানে ইথেরিয়ামের কনসেনসাস নিয়মগুলি অপরিবর্তিত রয়েছে।
কেন সার্টিফিকেট সমস্যা নিরাপত্তা ঝুঁকিতে পরিণত হয়?
সার্টিফিকেট সফটওয়্যারকে সহায়তা করে যে এটি প্রত্যাশিত সেবার সাথে সংযুক্ত হয়েছে কিনা তা চিহ্নিত করতে। বিশ্বস্ত সার্টিফিকেট প্রদানকারী সার্ভার সার্টিফিকেটের পরিচয়ের জন্য প্রতিশ্রুতি দেয়।
এই মেকানিজমটি HTTPS ওয়েবসাইটগুলিতে সাধারণ, কিন্তু ব্রাউজারের মাধ্যমে যোগাযোগ না করে কাজ করা অ্যাপ্লিকেশনগুলিতেও প্রযোজ্য। ব্যাকএন্ড সার্ভিসগুলিও এই পরিচয় যাচাইয়ের উপর নির্ভর করতে পারে।
সার্টিফিকেট প্রদানকারী সংস্থা বিশ্বস্ত মূল সার্টিফিকেটের নিচে মধ্যবর্তী সার্টিফিকেট ব্যবহার করতে পারে। এই মধ্যবর্তী সার্টিফিকেটগুলির সাথে সম্পর্কিত ব্যক্তিগত চাবি নিরাপদে রাখা আবশ্যিক, কারণ এগুলি ব্যবহার করে আরও সার্টিফিকেট জারি করা যেতে পারে।
এই ঘটনায় সমস্যা শুধু কেউ সার্ভারের সাধারণ লগইন তথ্য পেয়েছে তাই নয়। প্রভাবিত মধ্যবর্তী চাবি পূর্বে প্রকাশিত তথ্য থেকে পুনরুদ্ধার করা যায়।
Go সিকিউরিটি টিমের বিবৃতি অনুসারে, এই দুর্বলতাটি মাইক্রোসেকেন্ড স্তরে প্রাইভেট কী পুনরুদ্ধার করতে দেয়। এটির বর্ণনায় আরও উল্লেখ করা হয়েছে যে আক্রমণকারীরা পরবর্তীতে তাদের নিয়ন্ত্রণে না থাকা ডোমেইনগুলির জন্য সার্টিফিকেট তৈরি করতে পারে।
যদি কোনো সহজে আক্রমণযোগ্য অ্যাপ্লিকেশন মনে করে যে এই সার্টিফিকেটটি এটি বিশ্বাস করা সংস্থার দিকে ফিরে যায়, তাহলে এটি এটিকে গ্রহণ করতে পারে। এভাবে, প্রতারকদের বাদ দেওয়ার জন্য তৈরি পরীক্ষাগুলির মধ্যে দিয়ে প্রতারণামূলক পরিচয় প্রবেশ করতে পারে।
তবে, আক্রমণকারীদের এখনও কোনও পদ্ধতি প্রয়োজন যার মাধ্যমে তারা শিকারের সংযোগ বাধা দিতে বা পুনঃনির্দেশিত করতে পারে। দুর্বল কীগুলি স্বয়ংক্রিয়ভাবে তাদের প্রতিটি ব্যবহারকারী এবং প্রতিটি সার্ভারের মধ্যে উপস্থিত করবে না।
এই শর্তটি আক্রমণের পদ্ধতিকে সীমিত করে, কিন্তু সার্টিফিকেট বাতিলকে নিরাপদ করে তোলে না। যতক্ষণ সফটওয়্যারটি প্রতারককে বাস্তব এন্ডপয়েন্ট হিসাবে গ্রহণ করবে, নেটওয়ার্ক ইন্টারসেপশন আরও বিপজ্জনক হয়ে উঠবে।
কুডেলস্কি সিকিউরিটির গবেষণা প্রভাবিত সার্টিফিকেট স্তরগুলি পর্যালোচনা করে। সমস্যাটি হলো, সফটওয়্যারটি আক্রমণকারীদের পুনরুৎপাদন করতে সক্ষম চাবি দ্বারা স্বাক্ষরিত সার্টিফিকেটগুলি গ্রহণ করতে পারে।
eMudhra প্রক্রিয়াকরণ ত্রুটির জন্য দুর্বল চাবির দায়ী করেছে
eMudhra-এর ঘটনা বিবৃতিতে বলা হয়েছে যে, একজন গবেষক 17 অক্টোবর অষ্টাদশ দুর্বল মধ্যবর্তী চাবি রিপোর্ট করেন। কোম্পানিটি পরের দিন এই অষ্টাদশ চাবি বাতিল করে।
কোম্পানিটি বলেছে যে এই মধ্যবর্তী সার্টিফিকেটগুলি ২০২৫ সালের ৩০ এপ্রিল একটি কী সমারোহের সময় তৈরি করা হয়েছিল। কোম্পানির মতে, দুর্বল ওয়্যাপ এবং আনওয়্যাপ ধাপগুলি মূল শক্তিশালী কীর বাইরে দুর্বল কপি তৈরি করেছিল।
কোম্পানিটি সার্টিফাইড হার্ডওয়্যার সিকিউরিটি মডিউল ব্যবহার করেছে বলে জানিয়েছে। এটি এই ত্রুটিকে এই ধরনের ডিভাইসের অভাবের জন্য নয়, বরং পারিশ্রমিক প্রক্রিয়াগুলির মধ্যে একটি ধাপের জন্য দায়ী করেছে।
কোম্পানিটি আরও বলেছে যে এই 7টি মধ্যবর্তী সার্টিফিকেট কখনও উৎপাদন পরিবেশে ব্যবহৃত হয়নি, এবং বাকি 1টি এখনও সার্টিফিকেট জারি করা হয়নি। কোম্পানিটি বলেছে যে এই ঘটনায় কোনও অবকাঠামো হ্যাক বা ডেটা লিকের ঘটনা ঘটেনি।
এই দাবিগুলি eMudhra-এর আন্তঃপ্রক্রিয়া সম্পর্কে তাদের বর্ণনাকে ব্যাখ্যা করে। তবে সফটওয়্যার সরবরাহকারীদের আরও একটি সম্ভাবনার সম্মুখীন হতে হবে: অন্যান্য পক্ষগুলি পুনরুদ্ধারযোগ্য চাবিগুলি ব্যবহার করতে পারে।
সার্টিফিকেট সিস্টেম শুধুমাত্র মূল অপারেটরের প্রতিশ্রুতির উপর নির্ভর করতে পারে না যে তারা আর কোনও কিছু সাইন করবে না। একবার অন্য কেউ কোনও সাইনিং কীকে পুনরুৎপাদন করে ফেললে, এই নিশ্চয়তা সম্ভাব্যভাবে তৈরি হওয়া সমস্ত সার্টিফিকেটকে নিয়ন্ত্রণ করতে পারবে না।
অতএব, প্রতিক্রিয়া পদক্ষেপগুলি কী তৈরি করা কোম্পানির বাইরে চলে গেছে। ব্রাউজার প্রস্তুতকারকদের, অপারেটিং সিস্টেম সরবরাহকারীদের এবং প্রোগ্রামিং ভাষা দলগুলিকে তাদের ব্যবহারকারীদের সফটওয়্যার কী গ্রহণ করবে তা বিবেচনা করতে হবে।
এই সংশোধনগুলি বিভিন্ন আপডেটের মাধ্যমে ব্যবহারকারীদের কাছে প্রেরিত হবে। ব্রাউজার ব্লক লিস্ট পেতে পারে, যখন একটি স্বতন্ত্র জাভা অ্যাপ্লিকেশন এখনও পুরনো বিশ্বস্ত সার্টিফিকেট সেট ব্যবহার করতে থাকতে পারে।
দুর্বল চাবি এবং এই চাবি গ্রহণ করা অ্যাপ্লিকেশন একই সমস্যার দুটি ভিন্ন অংশ। সার্টিফিকেট বাতিলকরণ প্রতিষ্ঠানের রেকর্ড স্তরের সমস্যা সমাধান করে, কিন্তু ক্লায়েন্টকে এখনও একটি নির্ভরযোগ্য উপায় প্রয়োজন যাতে তারা বুঝতে পারে যে তাদের কোন বিশ্বাসযোগ্য পথটি অস্বীকার করা উচিত।
বাহ্যিক সেবাগুলি ভেরিফায়ারদের জন্য বিভিন্ন ঝুঁকি তৈরি করে
এথেরিয়াম নোডগুলি বিভিন্ন দায়িত্ব পালনকারী সফটওয়্যার দিয়ে গঠিত। এথেরিয়াম ক্লায়েন্ট ডকুমেন্টেশন এক্সিকিউশন ক্লায়েন্ট এবং কনসেনসাস ক্লায়েন্টকে পৃথক করে: প্রথমটি ট্রানজেকশন এক্সিকিউশন এবং স্টেট পরিচালনা করে, যখন দ্বিতীয়টি প্রুফ-অফ-স্টেক কনসেনসাস অনুসরণ করে।
ভেরিফায়ার সফটওয়্যারে ব্লক প্রস্তাব করা এবং চেইনের প্রমাণ দেওয়ার দায়িত্ব যোগ করা হয়েছে। অপারেটররা এই উপাদানগুলি স্থানীয়ভাবে চালাতে পারেন বা বাইরের সেবার মাধ্যমে এর কিছু অংশ সংযুক্ত করতে পারেন।
Teku হল কনসেনসাস ক্লায়েন্ট, বেসু হল এক্সিকিউশন ক্লায়েন্ট। উভয়ই জাভা ব্যবহার করে, যার কারণে রানটাইম সার্টিফিকেট ট্রাস্ট তাদের প্রকাশের সাথে সম্পর্কিত।
এই ব্যবস্থার জন্য স্থানীয় মেশিনের বাইরের সেবাগুলি একটি পরিচয় যাচাইকরণ যোগ করে। সফটওয়্যারটি অনুরোধের প্রতিক্রিয়া প্রদানকারী প্রান্তিকটির প্রত্যাশিত সরবরাহকারী হওয়া নিশ্চিত করে।
উদাহরণস্বরূপ, অপারেটর একই প্রক্রিয়ায় স্বাক্ষর অপারেশন রাখার পরিবর্তে রিমোট স্বাক্ষর সেবা ব্যবহার করতে পারেন। কেউ কেউ বাহ্যিক এন্ডপয়েন্টের উপর নির্ভর করতে পারেন যা ডেটা বা ব্লক নির্মাণ সেবা প্রদান করে।
প্রতারকদের ক্ষতির পরিমাণ নির্ভর করে সেই সেবাটির অনুমোদিত কাজের উপর। শুধু মনিটরিং ডেটা গ্রহণ করে এমন সেবা এবং স্বাক্ষর সিদ্ধান্তে অংশগ্রহণকারী তথ্য প্রদানকারী সেবার ঝুঁকি একই নয়।
নেটওয়ার্ক পাথও একই প্রাধান্য রাখে। পাবলিক ইনফ্রাস্ট্রাকচারের মধ্যে দিয়ে যাওয়া কানেকশনগুলির ইন্টারসেপশনের সুযোগ একই হোস্ট বা কঠোরভাবে নিয়ন্ত্রিত প্রাইভেট নেটওয়ার্কের মধ্যে থাকা কম্পোনেন্টগুলির তুলনায় ভিন্ন।
প্রাইভেট নেটওয়ার্ক সমস্ত সমস্যা ঘটতে দেয় না, কিন্তু এটি আক্রমণকারীদের ট্রাফিক বিঘ্নিত করার জন্য প্রয়োজনীয় অবস্থান অর্জনের সুযোগ কমিয়ে দেয়।
অতএব, ক্লায়েন্ট নাম মাত্র দিয়ে এটি কি প্রকাশিত হয়েছে কিনা তা বিচার করা যায় না। একই সফটওয়্যার ভিন্ন এন্ডপয়েন্ট, ট্রাস্ট লাইব্রেরি এবং অ্যাক্সেস নিয়ন্ত্রণ সহ পরিবেশে বাস্তবায়িত হতে পারে।
প্রকৃতপক্ষে উত্তর দেওয়া প্রয়োজন হওয়া প্রশ্নটি হল: কোন কানেকশনটি প্রভাবিত পথের মাধ্যমে সার্টিফিকেট গ্রহণ করেছে। এটি স্পষ্ট হওয়ার পর, অপারেটররা যাচাইকারীর কার্যক্রমে প্রতারিত সেবাটির কতটা অনুমতি থাকা উচিত ছিল তা মূল্যায়ন করতে পারবেন।
ডকার ইমেজ এবং আর্কাইভ ইনস্টলেশন কেন ভিন্ন?
ডকার ইমেজ অ্যাপ্লিকেশন এবং এর চলার জন্য প্রয়োজনীয় পরিবেশকে একসাথে প্যাকেজ করে, যার মধ্যে জাভা রানটাইম এবং এই রানটাইম দ্বারা বিশ্বস্ত সার্টিফিকেট অন্তর্ভুক্ত থাকতে পারে।
হোস্টে জাভা আপডেট করলে বিদ্যমান ইমেজের জাভা স্বয়ংক্রিয়ভাবে প্রতিস্থাপিত হয় না। কন্টেইনারগুলি এখনও নিজেদের প্যাকেজযুক্ত ফাইলগুলি ব্যবহার করতে পারে।
এটিই ক্লায়েন্ট প্রকাশনা নোটে ডকার পরিবর্তনগুলির কথা উল্লেখ করার কারণ। টেকুর নোটে বলা হয়েছে যে তখন তাদের Eclipse Temurin বেস ইমেজে সেই অপসারণগুলি অন্তর্ভুক্ত ছিল না, তাই ক্লায়েন্ট ইমেজটি সরাসরি পরিবর্তন করা হয়েছিল।
বেসুর রিলিজ নোটেও উল্লেখ করা হয়েছে যে সার্টিফিকেট সরানো ডকার ইমেজের জন্য প্রযোজ্য এবং ইনস্টলেশনের জন্য ব্যবহারকারীদের নিজেদের প্রদান করা জাভা ডিস্ট্রিবিউশন পরীক্ষা করার জন্য স্পষ্টভাবে অনুরোধ করা হয়েছে।
আর্কাইভ ইনস্টলেশন এই দায়িত্বটি অপারেটরের উপর ছেড়ে দেয়। ইথারিয়াম ক্লায়েন্টটি হয়তো আপডেট হয়ে গেছে, কিন্তু এর আলাদা রানটাইমে এখনও পুরনো সার্টিফিকেট স্টোর থাকতে পারে।
অন্যদিকে, রক্ষণাবেক্ষণের সময়ও এই ধরনের পার্থক্য দেখা যায়। একটি হোস্ট রানটাইম প্রতিস্থাপন করলে সেই রানটাইম ব্যবহারকারী প্রক্রিয়াগুলি প্রভাবিত হয়, কিন্তু অন্য একটি ভিন্ন Java পথ ব্যবহারকারী ইনস্টলেশনকে প্রভাবিত করে না।
অরাকলের ইভেন্ট গাইডলাইন ব্যবহারকারীদের প্রভাবিত রানটাইম আপডেট করতে বা তাদের ডকুমেন্টে উল্লিখিত বিকল্পগুলি অনুসরণ করতে সুপারিশ করে। এটি চলমান ইনস্ট্যান্সগুলি পুনরায় শুরু করতে এবং প্রতিটি স্বতন্ত্র ইনস্টলেশনকে আলাদাভাবে বিবেচনা করতেও অনুরোধ করে।
এটি ডাউনলোড করা আপডেটের চেয়ে চলমান প্রক্রিয়াগুলিকে বেশি গুরুত্ব দেয়। সার্ভারে প্যাচযুক্ত ফাইল থাকতে পারে, কিন্তু পুরনো প্রক্রিয়াগুলি প্রতিস্থাপন বা রিস্টার্ট না হওয়া পর্যন্ত চলতে থাকবে।
কাস্টম সার্টিফিকেট স্টোরে আরও একটি পরিবর্তন যোগ করা হয়েছে। কোনও সংগঠন শুধুমাত্র জাভার ডিফল্ট সার্টিফিকেট স্টোর নয়, বরং নিজস্ব সেবাগুলির জন্য রক্ষিত সার্টিফিকেট স্টোর ব্যবহার করতে পারে।
বাস্তব কাজটি হল এই বুঝে বের করা যে ক্লায়েন্টটি সত্যিই কী ব্যবহার করছে। ইনস্টলেশন পদ্ধতি, রানটাইম অবস্থান এবং বিশ্বাসযোগ্যতা কনফিগারেশন একসাথে নির্ধারণ করে যে প্রকাশিত ফিক্সটি কি সেই কানেকশনে পৌঁছেছে যেখানে এটি প্রয়োজন।
বিভিন্ন অ্যাপ্লিকেশনে রিভোকেশন চেকের পার্থক্য
প্রত্যাহার অর্থ হল সার্টিফিকেটটি আর গ্রহণযোগ্য নয়। কিন্তু এটি নিশ্চিত করে না যে প্রতিটি অ্যাপ্লিকেশন কানেকশন স্থাপনের আগে সর্বশেষ প্রত্যাহারের তথ্য চেক করবে।
বিভিন্ন অ্যাপ্লিকেশন এই তথ্যগুলি পাওয়ার জন্য বিভিন্ন পদ্ধতি ব্যবহার করে। কিছু অনলাইন সেবা প্রশ্ন করে, কিছু সরবরাহকারী দ্বারা প্রদত্ত ব্লক তালিকা ব্যবহার করে, এবং কিছু স্থানীয় বিশ্বস্ত লাইব্রেরিতে সার্টিফিকেটের উপর প্রধানত নির্ভর করে।
গো টিমের প্রতিক্রিয়াটি ব্যাখ্যা করে যে কারণে রানটাইম সাপ্লায়ারদের সরাসরি হস্তক্ষেপ করার প্রয়োজন হতে পারে। টিমটি 19 অক্টোবর একটি জরুরি সিকিউরিটি রিলিজ শুরু করে এবং জানানোর পর প্রায় 7.5 ঘন্টার মধ্যে প্যাচ সংস্করণ প্রদান করেছে।
এই ক্রিয়াটি সংশ্লিষ্ট Go যাচাইকরণ আচরণ ব্যবহারকারী অ্যাপ্লিকেশনগুলির প্রভাবিত সার্টিফিকেট পাথকে বন্ধ করে দেয়। জাভা ব্যবহারকারীদের নিজেদের রানটাইম এবং বিশ্বস্ততা সেটিংসের মাধ্যমে সুরক্ষা পেতে হবে।
Teku-এর নোটিফিকেশন অনুসারে, Java ডিফল্টরূপে রিভোকেশন চেক করে না। এটিই কারণ যে, eMudhra এই মধ্যবর্তী সার্টিফিকেটগুলি রিভোক করে দিলেও, স্থানীয়ভাবে বিশ্বাস সরিয়ে ফেলা প্রয়োজন।
রুট সার্টিফিকেট অপসারণ এবং মধ্যবর্তী সার্টিফিকেট ব্লকিং একই সাথে বিভিন্ন স্তরে কাজ করতে পারে। পূর্ববর্তীটি একটি নির্দিষ্ট ক্ষতিগ্রস্ত পথকে অস্বীকার করে, যখন পরবর্তীটি অপসারিত রুট সার্টিফিকেটের দিকে পরিচালিত ব্যাপক সার্টিফিকেট চেইনকে অস্বীকার করতে পারে।
সঠিক বাস্তবায়ন সরবরাহকারী এবং অ্যাপ্লিকেশনটি রক্ষণাবেক্ষণ করে এমন সংগঠনের দায়িত্ব। পরিচয় যাচাইকরণ অস্থায়ীভাবে অক্ষম করা কেবল সুরক্ষা সরিয়ে ফেলবে, বিশ্বাসের সমস্যা সমাধান করবে না।
বৈধ সেবাগুলিও সামঞ্জস্য করা প্রয়োজন হতে পারে। যদি তাদের সার্টিফিকেটগুলি ক্লায়েন্ট এখন অস্বীকার করা পথের উপর নির্ভর করে, তাহলে সেবা প্রদানকারীদের ব্যবহারকারীদের অনিরাপদ বিশ্বাস পুনরুদ্ধারের প্রত্যাশা করার পরিবর্তে গ্রহণযোগ্য বিকল্প প্রদান করতে হবে।
এটিই ব্যাখ্যা করে যে কেন একটি সার্টিফিকেট ইভেন্ট কয়েক দিন ধরে চলতে পারে। আবিষ্কার প্রায় তাত্ক্ষণিক হতে পারে, কিন্তু সুরক্ষা ব্রাউজার, প্যাকেজড অ্যাপ্লিকেশন এবং ব্যক্তিগত অবকাঠামোর বিভিন্ন প্রকাশ এবং রক্ষণাবেক্ষণ প্রক্রিয়ার মধ্যে ধীরে ধীরে চালু হয়।
ভেরিফায়ার অপারেটরদের জন্য, সংশ্লিষ্ট সংযোগগুলি কি অবিশ্বস্ত পরিচয়গুলিকে অস্বীকার করেছে তা হল প্রধান ফলাফল। সফটওয়্যার ইকোসিস্টেমের অন্যত্র প্রত্যাহারের ঘোষণা দিয়ে এই ফলাফলটি পৌঁছানোর প্রমাণ হয় না।
পুরস্কার এবং ভেরিফায়ার স্টেকিং কি একইভাবে প্রকাশিত হয়?
ভেরিফায়ারদের স্টেকিং, সাইনেটিং দায়িত্ব এবং ফি পরিশোধ পরস্পর সম্পর্কিত, কিন্তু এগুলি ভিন্ন মেকানিজম দ্বারা নিয়ন্ত্রিত। এগুলির মধ্যে একটির উপর প্রভাব ফেলা সমস্যাকে স্বয়ংক্রিয়ভাবে এগুলির সবগুলির উপর নিয়ন্ত্রণ হিসাবে বর্ণনা করা উচিত নয়।
এথেরিয়াম স্টেকিং ডকুমেন্টে বর্ণিত হয়েছে যে ভেরিফায়াররা তাদের দায়িত্ব পালনের জন্য পুরস্কার পায় এবং অফলাইন থাকা বা প্রমাণযোগ্য অনুপযুক্ত আচরণের জন্য শাস্তি পায়। স্বাক্ষর এবং উত্তোলন অধিকার সিস্টেমে ভিন্ন ভিন্ন ভূমিকা পালন করে।
সার্টিফিকেট কী হল সংযোগ করার জন্য ব্যবহৃত পরিচয় সিস্টেমের অংশ। এটি ভেরিফায়ারের ব্যক্তিগত স্বাক্ষর কী নয় এবং প্রতিজ্ঞাবদ্ধ ETH উত্তোলনের যাচাইকরণের যেকোনো যাচাইকরণ প্রকাশ করে না।
তবে, প্রতারণামূলক সেবাটি ভেরিফায়ারদের আচরণকে প্রভাবিত করতে পারে। এর প্রভাব নির্ভর করে ঐ সেবাটি কোন অনুরোধ বা প্রতিক্রিয়া প্রক্রিয়া করে এবং কোন অতিরিক্ত চেক এখনও রাখে।
ব্লক প্রস্তাবে সংশ্লিষ্ট পেমেন্টের জন্য ফি গ্রহণকারী অন্তর্ভুক্ত থাকে। যদি কোনো পথ প্রস্তাব বা কনফিগারেশন পরিবর্তন করতে পারে, তবে সম্পূর্ণ স্টেকিং নিয়ন্ত্রণ না করেও এটি পরিণতি ঘটাতে পারে।
সাইনেট সার্ভিস আরও একটি সেট প্রশ্ন তুলে ধরেছে, কারণ এটি অথরাইজেশন ভেরিফিকেশনের কাজে জড়িত। এর নিজস্ব সুরক্ষা ব্যবস্থা, যেমন অনুরোধের সীমাবদ্ধতা এবং কনফ্লিক্টিং সাইনেচার প্রতিরোধের ব্যবস্থা, আক্রমণকারীদের কী করতে পারবে তা প্রভাবিত করে।
সেবা বিঘ্নের কারণে দায়িত্ব অবহেলা করা একটি সম্ভাব্য পরিণতি। যদিও কোনো পেমেন্ট সফলভাবে স্থানান্তরিত না হয়, আক্রমণকারী শুধুমাত্র সঠিক প্রতিক্রিয়া বন্ধ করে পুরস্কার কমিয়ে দিতে পারে।
এই ফলাফলগুলির আর্থিক প্রভাব একই নয়। প্রস্তাবিত ব্লকের সুযোগ হারানো, সাধারণ অফলাইন শাস্তি এবং কাটিং শাস্তি একই বিষয় হিসেবে বিবেচনা করা যায় না।
ক্লায়েন্ট ঘোষণাটি প্রভাবিত কনফিগারেশনের অধীনে সম্ভাব্য পরিণতি বর্ণনা করে, কিন্তু প্রতিটি অপারেটরের জন্য এই পরিণতি ঘটেছে কিনা বা সংশ্লিষ্ট পরিমাণে ETH চুরি হয়েছে কিনা তা প্রমাণ করে না।
যে ধারকদের প্রতিজমা সেবাদাতা ব্যবহার করছেন, তাদের জন্য প্রকৃতপক্ষে প্রাসঙ্গিক হল সেবাদাতার বাস্তব বাস্তবায়ন। কতটা ETH পরিচালনা করা হচ্ছে, তা তাদের পরিচালকদের কোন দূরবর্তী সেবা বা সার্টিফিকেট লাইব্রেরি ব্যবহার করছেন তা নির্দেশ করে না।
ভেরিফায়াররা এথেরিয়ামের বাইরের সফটওয়্যারের উপরও নির্ভর করে।
এথেরিয়াম নেটওয়ার্ক নিয়মগুলি শুধুমাত্র অপারেটরদের উপর নির্ভরশীল একটি অংশ। হার্ডওয়্যার, রানটাইম, হোস্টিং, কনফিগারেশন এবং বাহ্যিক সেবাগুলি ভেরিফায়ারদের সঠিকভাবে দায়িত্ব পালন করতে পারে কিনা তা প্রভাবিত করে।
সার্টিফিকেট প্রদানকারী এথেরিয়াম প্রোটোকলের বাইরে অবস্থিত, কিন্তু যখন ভেরিফায়ার সফটওয়্যার সেবা চিহ্নিত করতে এটির উপর নির্ভর করে, তখন এর ব্যর্থতা প্রাসঙ্গিক হয়ে ওঠে। এটি মাত্রই যথেষ্ট যে একটি সাধারণ ইন্টারনেট নিরাপত্তা সমস্যাকে স্টেকিং অবকাঠামোতে আনা হয়।
ক্লায়েন্ট বৈচিত্র্য এখনও মূল্যবান, কারণ বিভিন্ন বাস্তবায়ন একক কোডবেসের উপর নির্ভরশীলতা কমাতে পারে। কিন্তু এর অর্থ এই নয় যে প্রতিটি নির্ভরশীলতা স্বাধীন।
দুটি ক্লায়েন্ট একই প্রোগ্রামিং ভাষার রানটাইম ব্যবহার করতে পারে। বিভিন্ন অপারেটররা একই হোস্টিং সেবাদাতা, স্বাক্ষর সেবা বা ব্লক বিল্ডিং অবকাঠামোও ব্যবহার করতে পারে।
এই শেয়ার করা উপাদানগুলি এথেরিয়াম সফটওয়্যারের নিজস্ব বিভিন্নতার কারণে সাধারণ প্রকাশিত পৃষ্ঠ তৈরি করে। তাই, বাস্তবায়ন পরিস্থিতি বুঝতে শুধুমাত্র ক্লায়েন্ট ব্র্যান্ডের সংখ্যা দেখা যথেষ্ট নয়।
আউটসোর্সিংয়ের সাথে বিনিময়ও আসে। বিশেষায়িত স্বাক্ষর সেবা কী সুরক্ষার পদ্ধতি উন্নত করতে পারে, কিন্তু এই সেবার সাথে প্রমাণীকরণ সংযোগকে আরও গুরুত্বপূর্ণ করে তোলে।
স্থানীয়ভাবে চালানোরও নিজস্ব রক্ষণাবেক্ষণের প্রয়োজন হয়। উপাদানগুলিকে একই মেশিনে রাখা কিছুটা নেটওয়ার্ক প্রকাশ কমাতে পারে, কিন্তু অপারেটরদের এই মেশিনের জন্য সফটওয়্যার আপডেট এবং অ্যাক্সেস ব্যবস্থাপনা করতে হবে।
এই ঘটনাটি সমস্ত পরিস্থিতিতেই সবচেয়ে নিরাপদ আর্কিটেকচার স্বয়ংক্রিয়ভাবে প্রদান করে না। এটি দেখিয়ে দেয় যে, প্রতিটি সংযোগের চারপাশের দায়িত্বগুলি বুঝতে এবং রক্ষণাবেক্ষণ করা প্রয়োজন।
এই পার্থক্যটি সাধারণ ETH ব্যবহারকারীদের জন্যও গুরুত্বপূর্ণ। নোড ইনফ্রাস্ট্রাকচারে সার্টিফিকেট প্যাচ করা মানে এই নয় যে প্রতিটি ওয়ালেটের অর্থ স্থানান্তর করতে হবে বা এথেরিয়াম অ্যাকাউন্টের ব্যালেন্স পরিবর্তিত হয়েছে।
সংশ্লিষ্ট কার্যক্রমগুলি প্রভাবিত সফটওয়্যার অপারেটরদের দ্বারা পরিচালিত হয়। তাদেরই সক্ষমতা রয়েছে সংশ্লিষ্ট রানটাইম, এন্ডপয়েন্ট এবং বিশ্বাসযোগ্য সেটিংস চিহ্নিত করতে এবং এই সংযোগগুলি স্থাপন করা সিস্টেমগুলিতে সরবরাহকারীর সংশ্লিষ্ট নির্দেশাবলী প্রয়োগ করতে।
অপারেটরদের আপডেট প্রয়োগ এবং চেক করতে হবে
এই প্রকাশনাগুলি অপারেটরদের সমর্থিত ডকার ইমেজ থেকে প্রভাবিত বিশ্বাসের পথগুলি সরানোর জন্য সুযোগ প্রদান করে। আর্কাইভ ব্যবহারকারীদের তাদের প্রতিটি জাভা সরবরাহকারীর নির্দেশিকা অনুসরণ করে আলাদা রানটাইম কাজগুলি প্রক্রিয়া করতে হবে।
প্যাচ উপলব্ধ হওয়া শুধু প্রক্রিয়ার প্রথম ধাপ। আপডেটকৃত পরিবেশটি আসলে চালু হতে হবে এবং প্রত্যাশিত কনফিগারেশন এবং সেবাগুলি স্বাভাবিকভাবে কাজ করতে থাকতে হবে।
সেবা প্রদানকারীদের জন্য, সাম্প্রতিকভাবে অস্বীকৃত সার্টিফিকেট দ্বারা ঘটিত বিঘ্নের কারণে এন্ডপয়েন্টে সার্টিফিকেট পরিবর্তন প্রয়োজন হতে পারে। সেবা পুনরুদ্ধারের সময় পরিচয় যাচাইকে এড়িয়ে যাওয়ার পরিবর্তে এটি বজায় রাখা উচিত।
পরবর্তী প্রকাশ প্রভাবকে আরও বিস্তারিতভাবে নির্ধারণ করতে পারে। অপারেটরগুলি প্রভাবিত সার্টিফিকেট চেইন গ্রহণকারী কনফিগারেশন চিহ্নিত করতে পারেন বা নির্দিষ্ট সেবাগুলির সাথে সম্পর্কিত ঘটনাগুলি রিপোর্ট করতে পারেন।
বর্তমানে, টেকুর নোটিফিকেশন রিপোর্ট ব্যবহার করা হয়নি এবং ডিফল্ট মেইননেট ব্যবহার এবং প্রভাবিত বাহ্যিক কানেকশনগুলিকে পৃথক করেছে। এটিই বর্তমান ইথারিয়াম এক্সপোজার সম্পর্কে সবচেয়ে স্পষ্ট ভিত্তি।
প্রভাবিত অপারেটরদের আপডেট করার যুক্তিসহ কারণ রয়েছে। যেকোনো আর্থিক ক্ষতি নির্ভর করে আক্রমণকারী কোন সেবা প্রতারণা করেছিল, ট্রাফিক বন্ধ করা হয়েছিল কিনা, এবং যাচাইকারী ঐ সেবাকে কী করতে অনুমতি দিয়েছিল।
কী দেখতে হবে
- ক্লায়েন্ট আপডেট: টেকু এবং বেসুর প্রকাশ অনুসরণ করুন এবং প্যাচ করা সংস্করণটি চালু হয়েছে কিনা তা নিশ্চিত করুন।
- জাভা সার্টিফিকেট: প্রতিটি ইনস্টলেশনে ব্যবহৃত জাভা রানটাইম এবং সার্টিফিকেট লাইব্রেরির সরবরাহকারীর নির্দেশিকা দেখুন।
- বাহ্যিক লিঙ্ক: দূরবর্তী স্বাক্ষর, ডেটা এবং ব্লক নির্মাণ সেবার দিকে ইঙ্গিত করে এমন HTTPS লিঙ্কগুলি পরীক্ষা করুন।
- সুরক্ষা নোটিফিকেশন: আক্রমণ বা অতিরিক্ত বিবরণ নিশ্চিত করার জন্য ক্লায়েন্ট টিম এবং জাভা সরবরাহকারীদের প্রকাশনা মনোযোগ সহকারে পর্যবেক্ষণ করুন।
প্রায়শই জিজ্ঞাসিত প্রশ্নাবল�
eMudhra ইভেন্ট কী?
এই ঘটনাটি eMudhra সার্টিফিকেট প্রদানকারীর মধ্যবর্তী সার্টিফিকেটের সাথে সম্পর্কিত দুর্বল প্রাইভেট কী নিয়ে জড়িত। গবেষকদের কাছে প্রমাণিত হয়েছে যে এই কীগুলি পাবলিক তথ্য থেকে পুনরুদ্ধার করা যায়, যা অন্যরা তাদের নিয়ন্ত্রণে না থাকা ডোমেইনের সার্টিফিকেট তৈরি করার সম্ভাবনা তৈরি করে। প্রভাবিত সার্টিফিকেট পাথকে বিশ্বাস করা সফটওয়্যারগুলি এই জালিয়াতির পরিচয়কে গ্রহণ করতে পারে। তবে, আক্রমণকারীদের লক্ষ্য সেবা প্রতারণা করতে হলে, তাদের সংযোগগুলি বন্ধ বা পুনঃনির্দেশিত করার জন্য কোনও পদ্ধতির প্রয়োজন হয়।
কি এথেরিয়াম কনসেনসাস ব্যর্থ হয়েছে?
না। রিপোর্টে উল্লিখিত সমস্যাটি সফটওয়্যার কিভাবে বাহ্যিক সেবার পরিচয় পরীক্ষা করে তার সাথে সম্পর্কিত, এথারিয়ামের ব্লকচেইনে সম্মতি পৌঁছানোর নিয়মের সাথে নয়। ক্লায়েন্ট আপডেটটি প্রভাবিত সফটওয়্যার পরিবেশের সার্টিফিকেট বিশ্বাসকে পরিবর্তন করে। কিছু ভ্যালিডেটর ডিপ্লয়মেন্ট যদি বাহ্যিক সেবার অপব্যবহারের শিকার হয়, তবে এটি এখনও অপারেশনাল ঝুঁকির সম্মুখীন হতে পারে। এই সম্ভাবনা কানেকশন এবং সেবার ভূমিকার উপর নির্ভর করে, এটি এথারিয়ামের কনসেনসাস নিয়মগুলির ভঙ্গের অর্থ বহন করে না।
কোন ক্লায়েন্টগুলি আপডেট করা হয়েছে?
Teku 26.10.3 এবং Besu 26.10.2 তাদের Docker ইমেজ আপডেট করে প্রভাবিত সার্টিফিকেট ট্রাস্ট সরিয়ে ফেলেছে। Teku হল কনসেনসাস ক্লায়েন্ট এবং Besu হল এক্সিকিউশন ক্লায়েন্ট, যেগুলি উভয়ই Java ব্যবহার করে। ইনস্টলেশন পদ্ধতি গুরুত্বপূর্ণ, কারণ এই পরিবর্তনটি এই ইমেজগুলিতে প্রদত্ত পরিবেশের জন্য প্রযোজ্য। ক্লায়েন্ট আর্কাইভগুলি ইনস্টল করে এবং নিজেদের Java রানটাইম প্রদান করা অপারেটরদের ঐ রানটাইমের জন্য পৃথকভাবে গাইডলাইন দেখতে হবে।
সমস্ত ভেরিফায়ার প্রভাবিত হবে?
না। টেকুর নোটিফিকেশন অনুযায়ী, ডিফল্ট মেইননেট নোডগুলি প্রভাবিত হয়নি। ঝুঁকি নির্ভর করে কোনো ডিপ্লয়মেন্ট কি সংশ্লিষ্ট বাহ্যিক HTTPS কানেকশন করেছে এবং এর সার্টিফিকেট চেক কি প্রভাবিত ট্রাস্ট পাথকে গ্রহণ করেছে। বিভিন্ন অপারেটররা একই ক্লায়েন্টকে বিভিন্ন সার্ভিস, জাভা ভার্সন এবং সার্টিফিকেট লাইব্রেরির অধীনে চালাতে পারে। তাই, ক্লায়েন্টের নাম বা কোয়েস্ট করা ETH-এর পরিমাণ দিয়ে কোনো নির্দিষ্ট ভেরিফায়ারের প্রতিরোধক্ষমতা নির্ণয় করা যায় না।
ডকার আপডেট সমস্ত ইনস্টলেশন পদ্ধতিকে কভার করে?
না। প্যাচযুক্ত ডকার ইমেজটি ইমেজের ভিতরে প্যাকেজযুক্ত পরিবেশকে আপডেট করবে, কিন্তু আর্কাইভ ইনস্টলেশনটি অপারেটর দ্বারা প্রদানকৃত অন্য একটি জাভা ব্যবহার করতে পারে। অন্যান্য কন্টেইনার বা সার্ভিসগুলিও নিজস্ব রানটাইম রাখতে পারে। অপারেটরকে চলমান প্রক্রিয়াগুলির কোন ইনস্টলেশন পদ্ধতি ব্যবহার করা হচ্ছে তা চিহ্নিত করতে হবে এবং এর সরবরাহকারীর নির্দেশাবলী অনুসরণ করতে হবে। সার্ভারের প্যাচযুক্ত ফাইলগুলি পুরনো পরিবেশে চলমান প্রক্রিয়াগুলিকে সুরক্ষিত করতে পারে না।
কি ব্যবহার করা হয়েছে তা নিশ্চিত করা হয়েছে?
প্রস্তাবিত সময়ে, টেকুর নোটিফিকেশন কোনো দুর্বলতা বা ব্যবহারের কথা জানায়নি। সংশ্লিষ্ট প্রকাশনাটি একটি দুর্বলতা এবং এর সম্ভাব্য পরিণতির কথা বর্ণনা করে, যা যাচাইকারীদের জন্য আক্রমণকারীদের ব্যবহারের প্রমাণ নয়। ক্ষতির আলোচনায় এই পার্থক্যটি গুরুত্বপূর্ণ। একটি পরিষেবাকে নকল করার সম্ভাব্য পথ থাকা মানে এই নয় যে স্বাক্ষরের দায়িত্বগুলি হস্তক্ষেপ করা হয়েছে, ফি পরিশোধ পরিবর্তিত হয়েছে, অথবা质押 ETH চুরি করা হয়েছে।
ভেরিফায়ার জমা স্বয়ংক্রিয়ভাবে প্রকাশিত হবে?
না। সার্টিফিকেট সাইনিং কী ভেরিফায়ার সাইনিং কী এবং উত্তোলন নিয়ন্ত্রণের যাচাইকরণ থেকে ভিন্ন। প্রভাবিত সার্টিফিকেট কী পুনরুদ্ধার করলে প্লেসমেন্ট করা ETH উত্তোলনের জন্য প্রয়োজনীয় কীগুলি স্বয়ংক্রিয়ভাবে প্রকাশিত হবে না। প্রতারণার মাধ্যমে সেবা এখনও দায়িত্বগুলি বিকৃত করতে বা ভেরিফায়ারদের ব্যবহার করা তথ্যকে প্রভাবিত করতে পারে, যা বাস্তবায়নের উপর নির্ভর করে। এটিকে সমস্ত জমা রাশির জন্য স্বয়ংক্রিয় অ্যাক্সেস হিসাবে বিবেচনা না করে, এই সেবার জন্য সম্ভাব্য পরিণতি মূল্যায়ন করা উচিত।
অপারেটরদের কী করা উচিত?
অপারেটরদের সংশ্লিষ্ট Teku বা Besu রিলিজ নোট এবং তাদের Java রিলিজের নির্দেশিকা অনুসরণ করা উচিত। প্রতিটি প্রভাবিত প্রক্রিয়া দ্বারা ব্যবহৃত রানটাইম এবং সার্টিফিকেট লাইব্রেরি, যেমন কন্টেইনারের মধ্যে প্রদানকৃত অংশগুলি চিহ্নিত করা প্রয়োজন। সুপারিশকৃত আপডেটগুলি প্রয়োগের পরে, আপডেটকৃত সেবাগুলি চলমান রয়েছে এবং প্রয়োজনীয় কানেকশনগুলি স্বাভাবিকভাবেই কাজ করছে কিনা তা নিশ্চিত করা উচিত। ব্যর্থ কানেকশনগুলি পুনরুদ্ধারের জন্য সার্টিফিকেট চেক অক্ষম করা, এই চেকগুলির দ্বারা প্রদানকৃত সুরক্ষা সরিয়ে ফেলে।