eMudhra واقعہ کے بعد، Teku اور Besu نے اپنے اپنے Docker امیجز کو اپ ڈیٹ کیا، کیونکہ کمزور سرٹیفیکیٹ کلید نے باہری خدمات سے جڑنے والے سافٹ ویئر، جس میں کچھ ایتھریم ویریفائر ڈیپلومنٹس بھی شامل ہیں، کو خطرہ پیدا کیا۔
- Teku 26.10.3 اور Besu 26.10.2 میں eMudhra واقعہ کے باعث متاثرہ سرٹیفیکیٹ کی ٹرسٹ کو ڈاکر امیج سے خارج کر دیا گیا ہے۔
- Teku کا کہنا ہے کہ ڈیفالٹ مین نیٹ نوڈ متاثر نہیں ہوئے، اور اصلی اظہار کی درجہ بندی HTTPS کنکشن اور آپریٹر کے استعمال کیے جانے والے جاوا رن ٹائم پر منحصر ہے۔
- جھوٹے خدمات اور تصدیق کنندگان کے عمل سے متعلق جو خطرات ہیں، ان کا ذکر Teku کی نوٹیفیکیشن میں کوئی استعمال نہیں ہوا۔
آپریٹرز کے لیے اب کا سب سے برا مسئلہ یہ ہے کہ دوسری سروسز سے جڑتے وقت ان کا سافٹ ویئر جعلی سرٹیفکیٹس قبول کرے گا یا نہیں۔ جواب استعمال کی جانے والی کنکشن اور جاوا انسٹالیشن پر منحصر ہے، اس لیے کلائنٹ اپڈیٹ ہونا ہر ویریفائر کے لیے ایک جیسے خطرے کا مطلب نہیں۔
Teku اور Besu کے ڈاکر امیج کو اپڈیٹ کریں
ایتھریم کلائنٹ ٹیم نے بلاکچین کے باہر شروع ہونے والے سرٹیفیکیٹ کے مسئلے کو درست کرنے کے لیے اپڈیٹ جاری کر دیا ہے۔ متعلقہ تبدیلیاں نرم افزار کے طریقہ کار کو متاثر کرتی ہیں جس کے ذریعے وہ دور دراز سروسز کی اصلیت کا جائزہ لیتا ہے۔
Teku 26.10.3 اور Besu 26.10.2 نے متاثرہ سرٹیفیکیٹ رُوٹس کی تصدیق کو اپنے Docker امیج سے ختم کر دیا ہے۔ یہ اپڈیٹ eMudhra کے ساتھ متعلق کمزور کلید کی دریافت کے باعث جاری کیا گیا ہے۔
ویریفائر آپریٹرز کے لیے مسئلہ یہ ہے کہ حملہ آور نرم افزار کے جوڑے گئے سروس کا دعویٰ کرتا ہے۔ اس سروس کے کردار کے مطابق، جھوٹی جوابات ذمہ داریوں کو الگ کر سکتے ہیں، یا کچھ بلاک فیسز کی ادائیگی کی جگہ کو متاثر کر سکتے ہیں۔
لیکن اس کا مطلب یہ نہیں کہ ہر ایتھریم ویریفائر خطرے میں ہے۔ ٹیکو کی سیکیورٹی نوٹس کے مطابق، ڈیفالٹ مین نیٹ نوڈز متاثر نہیں ہیں، اور اب تک کوئی استعمال کیے جانے کی رپورٹ نہیں ہے۔
فرق تنصیب کے طریقے میں ہے۔ باہری HTTPS سروس کے استعمال کرنے والے کو ان کنکشنز کی جانچ کرنی چاہیے جو مکمل طور پر لوکل کمپونینٹس کی تنصیب میں ضروری نہیں ہوتے۔
یہ اپڈیٹس مخصوص انسٹالیشن ماحول کے لیے ہیں۔ پیچ کے بعد کا ڈاکر امیج میں کنٹینر کے اندر رن ٹائم میں تبدیلیاں شامل ہیں، جبکہ آرکائیف فائل سے انسٹال کیا گیا سافٹ ویئر ممکنہ طور پر آپریٹر کے ذریعہ فراہم کردہ جاوا استعمال کرتا ہے۔
یہ واقعہ ویریفائر کے اردگرد کی بنیادی ڈھانچے کو متاثر کرتا ہے، جبکہ ایتھریم کے متفقہ قواعد میں کوئی تبدیلی نہیں ہوئی ہے۔
کیوں سرٹیفیکیٹ کے مسائل سیکورٹی خطرے میں تبدیل ہو جاتے ہیں؟
سیفٹی سرٹیفکیٹس سافٹ ویئر کو یہ فیصلہ کرنے میں مدد کرتے ہیں کہ وہ کسی انتظار کیے گئے سروس سے جڑا ہوا ہے۔ معتبر سرٹیفکیٹ جاری کنندگان سرور سرٹیفکیٹ کے متعلقہ شناخت کو تصدیق کرتے ہیں۔
یہ مکینزم HTTPS ویب سائٹس میں عام ہے، لیکن براؤزر کے ذریعے مواصلات نہ کرنے والے ایپلیکیشنز میں بھی لاگو ہوتا ہے۔ بیک اینڈ سروسز بھی ان شناخت کی تصدیق پر منحصر ہو سکتے ہیں۔
سرٹیفیکیٹ جاری کنندہ، بھروسہ کیے گئے روت سرٹیفیکیٹ کے نیچے درمیانی سرٹیفیکیٹ استعمال کر سکتا ہے۔ ان درمیانی سرٹیفیکیٹس سے متعلقہ نجی کلید کو محفوظ رکھنا ضروری ہے، کیونکہ ان کا استعمال مزید سرٹیفیکیٹس جاری کرنے کے لیے کیا جا سکتا ہے۔
اس واقعہ میں صرف اس بات کا مسئلہ نہیں تھا کہ کسی نے سرور کی عام لاگ ان معلومات حاصل کر لیں۔ متاثرہ میڈیم کلیدیں پہلے سے شائع شدہ معلومات سے بازیافت کی جا سکتی ہیں۔
Go سیکورٹی ٹیم کے مطابق، یہ کمزوری مائیکرو سیکنڈ کے سطح پر پرائیویٹ کلید کو بحال کرنے کی اجازت دیتی ہے۔ اس کی وضاحت میں یہ بھی بتایا گیا ہے کہ حملہ آور بعد میں اپنے کنٹرول میں نہ ہونے والے ڈومین نام کے لیے سرٹیفکیٹ بناسکتے ہیں۔
اگر کوئی زیادہ حساس ایپلیکیشن یہ سمجھے کہ یہ سرٹیفکیٹ آخرکار اس کے اعتماد کیے گئے ادارے تک واپس جاتا ہے، تو وہ اسے قبول کر سکتا ہے۔ اس طرح، جھوٹی شناختیں وہ جانچ پڑتال سے گزرنے کا موقع پا سکتی ہیں جو اصل میں دھوکہ دہی کرنے والوں کو روکنے کے لیے تھیں۔
تاہم، حملہ آور کو متاثرہ صارفین کے کنکشن کو انٹر سیپ یا دوبارہ ہدایت دینے کا کوئی طریقہ درکار ہے۔ کمزور کلیدیں انہیں ہر صارف اور ہر سرور کے درمیان خود بخود نہیں لائیں گی۔
یہ شرط حملے کے طریقے کو محدود کرتی ہے، لیکن سرٹیفکیٹ کو بے اثر بنانے کو بے خطر نہیں بناتی۔ جب تک سافٹ ویئر جعلی اندھیرے کو اصل اینڈ پوائنٹ سمجھتا ہے، نیٹ ورک انٹرسیپشن زیادہ خطرناک ہو جاتا ہے۔
کودیل斯基 سیکیورٹی کی تحقیق متاثرہ سرٹیفیکیٹ لیورلز کا جائزہ لیتی ہے۔ مسئلہ یہ ہے کہ سافٹ ویئر حملہ آور کے ذریعہ دوبارہ تخلیق کیے جانے والے کلید سے جاری کردہ سرٹیفیکیٹس کو قبول کر سکتا ہے۔
eMudhra نے کمزور کلیدوں کو معالجہ کی غلطی کا سبب قرار دیا ہے
eMudhra کے واقعہ کے بیان میں کہا گیا ہے کہ ایک ریسرچر نے 17 اکتوبر کو 8 کمزور انٹرمیڈیٹ کلیدیں رپورٹ کیں۔ کمپنی نے اگلے دن ان 8 کلیدوں کو منسوخ کر دیا۔
کمپنی کا کہنا ہے کہ یہ درمیانی سرٹیفیکیٹس 30 اپریل 2025 کو ایک کلیدی تقریب کے دوران تخلیق کیے گئے تھے۔ کمپنی کے مطابق، خراب wrap اور unwrap مراحل نے اصل مضبوط کلید کے علاوہ کمزور نسخے بھی تخلیق کر دیے۔
کمپنی نے کہا کہ اس نے سرٹیفائیڈ ہارڈویئر سیکیورٹی میڈول کا استعمال کیا ہے۔ اس نے خرابی کو اس قسم کے ڈیوائس کی کمی کے بجائے ماحولیاتی عمل میں ایک مرحلے کی وجہ سے قرار دیا ہے۔
کمپنی نے مزید کہا کہ ان میں سے 7 درمیانی سرٹیفکیٹس کبھی بھی پیداواری ماحول میں استعمال نہیں کیے گئے، اور باقی 1 کا بھی سرٹیفکیٹ جاری نہیں کیا گیا۔ کمپنی کے مطابق، اس واقعے کے نتیجے میں انفراسٹرکچر کو نقصان نہیں پہنچا اور کوئی ڈیٹا لیک نہیں ہوا۔
یہ دعوے eMudhra کے اپنے اندر کے عمل کی وضاحت کرتے ہیں۔ لیکن سافٹ ویئر فراہم کنندہ کو ایک اور امکان کا مقابلہ کرنا پڑے گا: دوسرے افراد قابل واپسی کی کلید کا استعمال کر سکتے ہیں۔
سسٹم کو صرف اصل آپریٹر کے اس وعدے پر انحصار نہیں کرنا چاہیے کہ وہ کبھی بھی کوئی اور چیز جاری نہیں کریں گے۔ ایک بار جب کوئی اور کسی سائننگ کلید کو دوبارہ بنانے میں کامیاب ہو جائے، تو اس قسم کا عہد تمام ممکنہ سرٹیفکیٹس پر کنٹرول نہیں رکھ سکتا۔
اس لیے، رد عمل کے اقدامات صرف کلید بنانے والی کمپنی تک محدود نہیں ہیں۔ براؤزر فرنڈز، آپریٹنگ سسٹم فراہم کنندگان اور پروگرامنگ زبان ٹیمیں اپنے صارفین کے سافٹ ویئر کو کیا قبول ہونا چاہیے، اس کا خیال رکھتی ہیں۔
یہ درستگیاں صارفین تک مختلف اپڈیٹس کے ذریعے پہنچائی جائیں گی۔ براؤزر کو بلاک لسٹ مل سکتی ہے، جبکہ ایک الگ جاوا ایپلیکیشن اب بھی پرانے معتبر سرٹیفکیٹس کے مجموعے کا استعمال جاری رکھ سکتی ہے۔
کمزور کلید اور اس کلید کو قبول کرنے والی ایپلیکیشن ایک ہی مسئلے کے دو مختلف پہلو ہیں۔ سرٹیفکیٹ کی منسوخی ادارہ کے ریکارڈ کے لیے مسئلہ حل کرتی ہے، جبکہ کلائنٹ کو اس بات کا ایک قابل اعتماد طریقہ درکار ہے کہ وہ پتہ لگائے کہ اسے متاثرہ اعتماد کے راستوں کو مسترد کرنا چاہیے۔
بیرونی خدمات ویریفائرز کو مختلف خطرات پیدا کرتی ہیں
ایتھریم نوڈس مختلف ذمہ داریوں کو انجام دینے والے سافٹ ویئر سے بنے ہوتے ہیں۔ ایتھریم کلائنٹ ڈاکیومنٹیشن ایگزیکیشن کلائنٹس اور کنسینس کلائنٹس میں فرق کرتی ہے: پہلا ٹرینزیکشنز اور اسٹیٹ کو انجام دیتا ہے، جبکہ دوسرا اسٹیک پروف کنسینس کو فالو کرتا ہے۔
وریفائر سافٹ ویئر میں بلاک تجویز کرنے اور چین کی تصدیق کرنے کی ذمہ داریاں شامل ہو گئی ہیں۔ آپریٹرز ان کمپوننٹس کو مقامی طور پر چلا سکتے ہیں یا ان میں سے کچھ کو باہری سروسز کے ذریعے جوڑ سکتے ہیں۔
Teku اکانسس کلائنٹ ہے، Besu ایکزیکیشن کلائنٹ ہے۔ دونوں جاوا کا استعمال کرتے ہیں، جس کی وجہ سے ان کے رن ٹائم سرٹیفیکیٹ ٹرسٹ ان کے اجرا سے متعلق ہے۔
اس ترتیب کے لیے لوکل مشین کے باہر کی خدمات ایک شناخت تصدیق کا اضافہ کرتی ہیں۔ سافٹ ویئر کو یہ تصدیق کرنی ہوگی کہ درخواست کا جواب دینے والا اندراج واقعی متوقع فراہم کنندہ ہے۔
مثال کے طور پر، آپریٹرز ممکنہ طور پر ایک ریموٹ سائننگ سروس کا استعمال کرتے ہیں، جبکہ سائننگ آپریشنز کو ایک ہی پروسیس میں رکھتے ہیں۔ کچھ لوگ خارجی اینڈ پوائنٹس پر انحصار کرتے ہیں جو ڈیٹا یا بلاک بنانے کی سروس فراہم کرتے ہیں۔
دھوکہ دہی کرنے والوں کی جانب سے کیا نقصان ہو سکتا ہے، اس بات پر منحصر ہے کہ اس سروس کو کیا کرنے کی اجازت دی گئی ہے۔ صرف مانیٹرنگ ڈیٹا接收 کرنے والی سروسز اور فیصلوں پر دستخط کرنے میں شامل ہونے والی معلومات فراہم کرنے والی سروسز کا خطرہ مختلف ہوتا ہے۔
نیٹ ورک پاتھ بھی اہم ہے۔ عوامی بنیادی ڈھانچے کے ذریعے کنکشن، صرف ایک ہی ہوسٹ یا سختی سے کنٹرول شدہ پرائیویٹ نیٹ ورک میں موجود کمپوننٹس کے مقابلے میں الگ طرح کے انٹر سیپشن کے مواقع پیدا کرتا ہے۔
نیٹ ورک کی خصوصی صلاحیت تمام خرابیوں کو نا ممکن نہیں بناتی، لیکن یہ حملہ ور کے لیے ٹریفک میں رکاوٹ ڈالنے کے لیے درکار مقام حاصل کرنے کے مواقع کو کم کرتی ہے۔
اس لیے، صرف کلائنٹ کے نام سے یہ فیصلہ نہیں کیا جا سکتا کہ کیا اس کا افشا ہوا ہے۔ ایک ہی سافٹ ویئر مختلف اندراجات، ٹرسٹ لائبریریز اور ایکسس کنٹرول والے ماحول میں ڈپلوی کیا جا سکتا ہے۔
سچائی میں پوچھا جانے والا سوال یہ ہے کہ کون سا کنکشن متاثرہ راستے کے ذریعے سرٹیفکیٹ قبول کرتا ہے۔ اس بات کو واضح ہونے کے بعد، آپریٹرز اس بات کا جائزہ لے سکتے ہیں کہ دھوکہ دہی کی جانے والی سروس کو ویریفائر کے عمل میں کتنی اہمیت حاصل ہونی چاہیے۔
ڈاکر امیج اور آرکائیو انسٹال کیوں الگ ہوتے ہیں؟
ڈاکر ایمیج ایپلیکیشن اور اس کے چلانے کے لیے درکار ماحول کو ایک ساتھ پیک کرتا ہے، جس میں جاوا رن ٹائم اور اس رن ٹائم کے ذریعہ قابلِ اعتماد سرٹیفکیٹ شامل ہو سکتے ہیں۔
ہوسٹ پر جاوا کو اپ ڈیٹ کرنے سے موجودہ ایمیج میں جاوا کا تبادلہ خودبخود نہیں ہوتا۔ کنٹینرز اب بھی اپنے اندر شامل فائلز کا استعمال کرتے رہ سکتے ہیں۔
یہی وجہ ہے کہ کلائنٹ ریلیز نوٹس میں ڈاکر میں تبدیلیوں کا خاص طور پر ذکر کیا گیا ہے۔ ٹیکو کے نوٹس کے مطابق، اس وقت ان کا Eclipse Temurin بنیادی تصویر اس حذف کو شامل نہیں کرتا تھا، اس لیے کلائنٹ تصویر میں ب без تبدیلی کی گئی۔
Besu کے ریلی نوٹس میں بھی یہ بتایا گیا ہے کہ اس کی سرٹیفکیٹ حذف کرنے کی اپلائی ڈاکر امیج کے لیے ہے، اور اس نے مخصوص طور پر ان صارفین کو ہدایت دی ہے جو اپنا جاوا ایمرشن فراہم کرتے ہیں، وہ اپنے جاوا ایمرشن کا جائزہ لیں۔
آرکائیو انسٹالیشن اس ذمہ داری کو آپریٹرز پر چھوڑ دے گا۔ ایتھریم کلائنٹس اپ ڈیٹ ہو چکے ہو سکتے ہیں، لیکن ان کے الگ الگ رن ٹائم میں اب بھی پرانے سرٹیفیکیٹ اسٹور شامل ہو سکتے ہیں۔
اسی طرح، مینٹیننس کے دوران بھی ایسے فرق ظاہر ہوتے ہیں۔ ایک ہوسٹ رن ٹائم کو تبدیل کرنا اس رن ٹائم کا استعمال کرنے والے پروسیسز کو متاثر کرتا ہے، لیکن دوسرے جاوا پتے کا استعمال کرنے والے انسٹالیشن کو نہیں۔
اوریکل کی واقعہ ہدایات صارفین کو متاثرہ رن ٹائم کو اپ ڈیٹ کرنے یا اپنے دستاویز میں دیے گئے متبادل حل پر عمل کرنے کی تجویز کرتی ہیں۔ اس کے علاوہ، یہ موجودہ انسٹنس کو دوبارہ شروع کرنے اور ہر الگ انسٹالیشن کو الگ الگ تصور کرنے کی درخواست کرتی ہے۔
یہ بناتا ہے کہ چل رہے عمل کو ڈاؤن لوڈ کیے گئے اپ ڈیٹ سے زیادہ اہمیت دی جائے۔ سرور میں درست شدہ فائلیں ہو سکتی ہیں، لیکن پرانے عمل کو تبدیل یا ریسٹارٹ نہ ہونے تک جاری رکھا جائے گا۔
کسی ادارہ کے پاس جاوا کے ڈیفالٹ سرٹیفیکیٹ اسٹور کے علاوہ اپنی خدمتوں کے لیے محفوظ کردہ سرٹیفیکیٹ اسٹور بھی ہو سکتا ہے۔
اصلی کام صارفین کی طرف سے استعمال کی جانے والی چیز کو تلاش کرنا ہے۔ انسٹالیشن کا طریقہ، رن ٹائم کا مقام، اور اعتماد کی ترتیب مل کر یہ طے کرتی ہیں کہ جاری کردہ فکس وہ کنکشن تک پہنچ چکا ہے جسے اس کی ضرورت ہے۔
Different applications have different revocation checks
منسوخ کرنا کا مطلب ہے کہ سرٹیفیکیٹ کو مزید قبول نہیں کیا جانا چاہیے۔ لیکن اس کا مطلب یہ نہیں کہ ہر ایپ لنکشن کے قائم کرنے سے پہلے تازہ ترین منسوخ شدہ معلومات کی جانچ کرے گا۔
مختلف ایپلیکیشنز ان معلومات کو حاصل کرنے کے طریقے مختلف ہوتے ہیں۔ کچھ آن لائن سروسز کو کوئری کرتے ہیں، کچھ فراہم کنندہ کی فہرستوں کا استعمال کرتے ہیں، اور کچھ بنیادی طور پر مقامی اعتماد کے اسٹور میں سرٹیفکیٹس پر انحصار کرتے ہیں۔
گو ٹیم کے جواب میں یہ واضح کیا گیا کہ رن ٹائم سپلائر کو براہ راست مداخلت کی ضرورت کیوں پڑ سکتی ہے۔ ٹیم نے 19 اکتوبر کو ایک فوری سیکورٹی اپڈیٹ جاری کی اور بتایا کہ اطلاع ملنے کے تقریباً 7.5 گھنٹے بعد ہی پچ کا ورژن فراہم کر دیا گیا۔
یہ ایکشن متاثرہ سرٹیفیکیٹ پاتھ کو شامل کرنے والے متعلقہ Go تصدیق سلوک کے استعمال کو روک دیتا ہے۔ جاوا صارفین کو اپنے رن ٹائم اور اعتماد کی ترتیبات کے ذریعے حفاظت حاصل کرنی ہوگی۔
Teku کی نوٹیفیکیشن کے مطابق، جاوا ڈیفالٹ طور پر ریووکیشن کی جانچ نہیں کرتا۔ اسی لیے یہ ضروری ہے کہ آپ eMudhra کے ذریعہ ریووک کردہ اندرمیڈیٹ سرٹیفکیٹس کو مقامی طور پر اپنے اعتماد سے نکال دیں۔
جڑی سرٹیفیکیٹ کو ہٹانا اور درمیانی سرٹیفیکیٹ کو بلاک کرنا بھی مختلف سطحوں پر اثر انداز ہو سکتا ہے۔ پہلا، کسی خاص متاثرہ راستے کو مسترد کرتا ہے، جبکہ دوسرا، ہٹائے گئے جڑی سرٹیفیکیٹ تک جانے والی وسیع تر سرٹیفیکیٹ چین کو مسترد کر سکتا ہے۔
درست طریقہ کار فراہم کنندہ اور ایپلیکیشن کے مینٹیننس کرنے والے ادارے کے ہاتھ میں ہے۔ اگر شناخت کی تصدیق کو عارضی طور پر بند کر دیا جائے، تو صرف تحفظ کو ختم کر دیا جائے گا، مکانیت کے مسئلے کا حل نہیں ہوگا۔
قانونی خدمات کو بھی تبدیل کرنے کی ضرورت ہو سکتی ہے۔ اگر ان کے سرٹیفکیٹس کا اعتماد صارفین کے اب منع کردہ راستے پر منحصر ہے، تو سروس فراہم کنندہ کو صارفین سے عدم محفوظ اعتماد کو بحال کرنے کی امید نہیں کرنی چاہیے، بلکہ قابل قبول متبادل فراہم کرنا چاہیے۔
یہ بھی وضاحت کرتا ہے کہ ایک سرٹیفکیٹ واقعہ کیوں کئی دن تک جاری رہ سکتا ہے۔ دریافت فوری ہو سکتی ہے، لیکن حفاظت براؤزر، پیکجڈ ایپلیکیشنز اور پرائیویٹ انفراسٹرکچر کے مختلف اشاعت اور مینٹیننس عمل کے ذریعے تدریجی طور پر نافذ ہوتی ہے۔
Validators کے لیے اہم نتیجہ یہ ہے کہ متعلقہ کنکشن نے بھروسہ نہ کیے جانے والی شناختوں کو منع کر دیا ہے۔ دوسرے سافٹ ویئر ایکوسسٹم میں ریووکیشن کے اعلانات، اس بات کا ثبوت نہیں دیتے کہ ان کے نوڈ پروسیس نے یہ نتیجہ حاصل کر لیا ہے۔
انعامات اور تصدیق کنندگان کی کوٹیشن ایک ہی طرح سے مستحق ہیں؟
ویریفائرز کی اسٹیکنگ، دستخط کی ذمہ داریاں اور فیس ادائیگی ایک دوسرے سے متعلق ہیں، لیکن ان پر مختلف میکنزمز لاگو ہوتے ہیں۔ ان میں سے کسی ایک پر اثر ڈالنے والے مسائل کو خودکار طور پر ان سب پر کنٹرول کے طور پر نہیں بیان کیا جانا چاہئے۔
ایتھریم کے اسٹیکنگ ڈاکیومنٹ کے مطابق، ویریفائر اپنے فرائض انجام دینے پر انعامات حاصل کرتے ہیں اور آف لائن ہونے یا قابل ثبوت غلط عمل کی وجہ سے سزا کھاتے ہیں۔ دستخط کی اجازت اور نکالنے کی اجازت نظام میں مختلف کردار ادا کرتی ہیں۔
سرٹیفیکیٹ کی کلید وہ شناخت نظام کے لیے استعمال ہوتی ہے جس سے جڑا جاتا ہے۔ یہ ویریفائر کی نجی دستخط کلید نہیں ہے اور قید کردہ ETH نکالنے کے اہلیت کے حوالے سے کوئی معلومات بھی نہیں چھوڑتی۔
تاہم، دھوکہ دہی کی گئی سروس بھی ویریفائر کے رویے کو متاثر کر سکتی ہے۔ اس کا اثر اس بات پر منحصر ہے کہ وہ سروس کن درخواستوں یا جوابات کو سنبھالتی ہے اور کون سے اضافی چیکز برقرار رکھتی ہے۔
بلاک پیش کش میں متعلقہ ادائیگیوں کے فیس وصول کرنے والے کا ایڈریس شامل ہوتا ہے۔ اگر کوئی راستہ پیش کش یا ترتیب کو تبدیل کر سکتا ہے، تو پورے اسٹیکنگ کو کنٹرول کیے بغیر بھی اس کے نتائج ہو سکتے ہیں۔
دستخط سروس نے دوسرے مجموعے کے سوالات اٹھائے ہیں کیونکہ یہ اظہار کنندگان کے رویے کی تصدیق میں شامل ہے۔ اس کے اپنے تحفظ کے اقدامات، جن میں درخواستوں پر پابندیاں اور تضادی دستخطوں کو روکنے کے انتظامات شamil ہیں، حملہ آور کی صلاحیت کو متاثر کرتے ہیں۔
خدمت کے中断 کی وجہ سے ذمہ داریوں کا نہ ہونا بھی ایک ممکنہ نتیجہ ہے۔ یہاں تک کہ اگر کوئی ادائیگی کامیابی سے منتقل نہ ہوئی ہو، تو حملہ آور صرف درست جواب کو روک کر انعام کو کم بھی کر سکتا ہے۔
ان نتائج کا مالی اثر مختلف ہے۔ پیشکش شدہ بلاک کے موقع کو ضائع کرنا، عام آف لائن جرمانہ اور کٹوتی کی سزا، الگ الگ ہیں۔
کلائنٹ اعلان میں متاثرہ ترتیبات کے تحت ممکنہ نتائج کا ذکر کیا گیا ہے، لیکن یہ ثابت نہیں کرتا کہ ہر آپریٹر کو ان نتائج کا سامنا کرنا پڑا ہے یا اس قدر کا ETH چوری ہوا ہے۔
اقامہ خدمت کا استعمال کرنے والے مالکین کے لیے حقیقی طور پر متعلقہ بات یہ ہے کہ سروس پر کیا عملی اجراء کیا گیا ہے۔ کتنے ETH کا انتظام کیا گیا، اس سے نہیں پتہ چلتا کہ اس کے مالک نے کون سی دورِ بردہ خدمات یا سرٹیفکیٹ لائبریریز استعمال کی ہیں۔
ویریفائرز ایتھریم کے باہر کے سافٹ ویئر پر بھی انحصار کرتے ہیں
ایتھریم نیٹ ورک کے قواعد صرف آپریٹرز کی انحصار کی ایک جانب ہیں۔ ہارڈویئر، رن ٹائم، ہوسٹنگ، ترتیب اور خارجی خدمات بھی تصدیق کنندہ کے کام کو درست طریقے سے انجام دینے پر اثر انداز ہوتی ہیں۔
سروس کی تصدیق کے لیے ویریفکیشن سافٹ ویئر جب اس پر انحصار کرتا ہے، تو سرٹیفیکیٹ جاری کرنے والی ادارہ ایتھریم پروٹوکول کے باہر ہوتا ہے، اور اس کی خرابی متعلقہ ہو جاتی ہے۔ صرف اسی بات سے، ایک عام انٹرنیٹ سیکورٹی مسئلہ اسٹیکنگ انفراسٹرکچر میں داخل ہو جاتا ہے۔
کلائنٹ کی تنوع اب بھی قیمتی ہے، کیونکہ مختلف ایمپلیمنٹیشنز ایک منفرد کوڈ بیس پر انحصار کو کم کر سکتی ہیں۔ لیکن اس کا مطلب یہ نہیں کہ ہر انحصار الگ ہوتا ہے۔
دو کلائنٹس ایک ہی پروگرامنگ زبان کے رن ٹائم کا استعمال کر سکتے ہیں۔ مختلف آپریٹرز بھی ایک ہی ہوسٹنگ فراہم کنندہ، سائنیچر سروس یا بلاک بنانے کی بنیادی ڈھانچہ استعمال کر سکتے ہیں۔
یہ مشترکہ کمپوننٹس ایتھریم سافٹ ویئر کی مختلف صورتوں کے باوجود مشترکہ ایکسپوژر پیدا کرتے ہیں۔ اس لیے، ڈیپلویمنٹ کو سمجھنے کے لیے صرف کلائنٹ برانڈز کی تعداد دیکھنا کافی نہیں۔
آؤٹ سورسنگ بھی ایک توازن کا سبب بن سکتی ہے۔ مخصوص دستخط سروسز کلید کے تحفظ کے طریقے کو بہتر بناسکتی ہیں، لیکن اس سروس کے ساتھ تصدیق شدہ کنکشن کو زیادہ اہمیت دے دیتی ہیں۔
مقامی طور پر چلانے کے لیے اپنی اپنی مینٹیننس کی ضرورت ہوتی ہے۔ کمپوننٹس کو ایک ہی مشین پر رکھنا کچھ نیٹ ورک ایکسپوژر کو کم کر سکتا ہے، لیکن آپریٹرز کو اس مشین پر سافٹ ویئر اپڈیٹس اور تکنیکی رسائی کا انتظام کرنا پڑتا ہے۔
یہ واقعہ خودبخود ایک ایسی ڈھانچہ نہیں دیتا جو تمام صورتحال میں سب سے محفوظ ہو۔ یہ بتاتا ہے کہ ہر کنکشن کے اردگرد کی ذمہ داریوں کو سمجھنا اور برقرار رکھنا ضروری ہے۔
یہ فرق عام ETH صارفین کے لیے بھی اہم ہے۔ نوڈ انفراسٹرکچر میں سرٹیفیکیٹ کا پیچ نہیں ہے کہ ہر والٹ میں فنڈز منتقل کرنے کی ضرورت ہو، یا ایتھریم اکاؤنٹ کا باقیہ تبدیل ہو گیا ہو۔
متعلقہ اقدامات متاثرہ سافٹ ویئر آپریٹرز کے ذمہ ہیں۔ وہی اس بات کو پہچاننے کی صلاحیت رکھتے ہیں کہ کون سے رن ٹائم، اینڈ پوائنٹس اور ٹرس سیٹنگز ملوث ہیں، اور پھر ان سسٹمز پر فراہم کنندہ کی متعلقہ ہدایات لاگو کرتے ہیں جو ان کنکشنز کو قائم کر رہے ہیں۔
آپریٹر کو اپڈیٹس لاگو اور چیک کرنے ہوں گے
یہ اشاعتیں آپریٹرز کو سپورٹ کیے گئے ڈاکر امیجز سے متاثرہ اعتماد کے راستوں کو ہٹانے کا طریقہ فراہم کرتی ہیں۔ آرکائیو صارفین کو اپنے Java فراہم کنندگان کی ہدایات کے مطابق الگ الگ رن ٹائم کام کرنا ہوگا۔
اپ ڈیٹ کیا گیا ماحول صرف ایک مرحلہ ہے۔ اسے حقیقی طور پر چلانا ہوگا اور اس کی توقع شدہ ترتیب اور خدمات کام کرتی رہنی چاہئیں۔
سروس فراہم کنندگان کے لیے، حالیہ مسترد کردہ سرٹیفکیٹ کی وجہ سے ہونے والی خرابی کے لیے، اندراج پر سرٹیفکیٹ تبدیل کرنے کی ضرورت ہو سکتی ہے۔ خدمات کو دوبارہ شروع کرتے وقت شناخت کی تصدیق کو برقرار رکھنا چاہیے، اسے نظرانداز نہیں کرنا چاہیے۔
مکمل تفصیلات کے ساتھ مزید اطلاعات دی جا سکتی ہیں۔ آپریٹرز کسی ایسے کنفیگریشن کی شناخت کر سکتے ہیں جس نے متاثرہ سرٹیفیکیٹ چین کو قبول کیا ہو، یا خاص سروس سے متعلق واقعات کی رپورٹ کر سکتے ہیں۔
اب تک، ٹیکو کی نوٹیفیکیشن رپورٹس کا استعمال نہیں کیا گیا ہے، اور یہ ڈیفالٹ مین نیٹ استعمال اور متاثرہ باہری کنکشنز کے درمیان فرق کرتی ہے۔ یہ ایتھریم کے موجودہ ایکسپوژر کو سب سے واضح طور پر بیان کرنے والا بنیادی ذریعہ ہے۔
متاثرہ آپریٹرز کو اپڈیٹ کرنے کا دلیل ہے۔ کوئی بھی مالی نقصان حملہ آور کے کس سروس کا دعویٰ کرنا، ٹریفک کو روکنا، اور ویریفائر کی طرف سے اس سروس کو کیا اجازت دینا، اس پر منحصر ہے۔
کیا دیکھنا چاہیے
- کلائنٹ اپڈیٹ: ٹیکو اور بیسو کے اجرا پر نظر رکھیں اور درست شدہ ورژن چل رہا ہے، یہ تصدیق کریں۔
- جاوا سرٹیفکیٹ: ہر انسٹالیشن کے لیے استعمال ہونے والے جاوا رن ٹائم اور سرٹیفکیٹ لائبریری کے فراہم کنندہ کی ہدایات دیکھیں۔
- بیرونی لنکس: ریموٹ سائنیچر، ڈیٹا اور بلاک بنانے کی خدمات کی طرف اشارہ کرنے والے HTTPS لنکس کا جائزہ لیں۔
- سیکورٹی نوٹس: حملوں یا مزید تفصیلات کی تصدیق کے لیے کلائنٹ ٹیم اور جاوا سپلائر کے اعلانات پر نظر رکھیں۔
عام سوالات
eMudhra واقعہ کیا ہے؟
اس واقعہ میں سرٹیفیکیٹ جاری کنندہ eMudhra کے انٹرمیڈیٹ سرٹیفیکیٹ سے متعلق کمزور پرائیویٹ کلید شامل ہے۔ تحقیق کاروں نے پایا کہ ان کلیدوں کو عوامی معلومات سے بحال کیا جا سکتا ہے، جس سے دوسرے اپنے کنٹرول میں نہ ہونے والے ڈومین ناموں کے لیے سرٹیفیکیٹ بناسکتے ہیں۔ ان متاثرہ سرٹیفیکیٹ پاتھ کو یقین رکھنے والے سافٹ ویئر اس طرح کی جعلی شناخت کو قبول کرسکتے ہیں۔ حملہ آور کو ابھی بھی مقصد سروس کی نقل کرنے کے لیے کنکشن کو انٹرcept یا ری ڈائریکٹ کرنے کا کوئی طریقہ درکار ہے۔
کیا ایتھریم کا متفقہ طریقہ ناکام ہو گیا ہے؟
نہیں۔ رپورٹ میں درج مسائل کا تعلق اسٹافٹ ویب سروسز کی شناخت کی جانچ کے طریقے سے ہے، نہ کہ ایتھریم کے بلاک چین پر متفقہ قواعد سے۔ کلائنٹ اپ ڈیٹس صرف متاثرہ سافٹ ویئر ماحول میں سرٹیفکیٹ کی قابلِ اعتمادیت کو تبدیل کرتے ہیں۔ کچھ ویریفائر ڈیپلومنٹس اگر بیرونی سروسز کی نقل بنانے کا شکار ہو جائیں تو ابھی بھی آپریشنل خطرات کا شکار ہو سکتے ہیں۔ یہ امکان منسلک کنکشن اور سروس کے کردار پر منحصر ہے، اور اس کا مطلب یہ نہیں کہ ایتھریم کا متفقہ قاعده توڑ دیا گیا ہے۔
کون سے کلائنٹس اپ ڈیٹ کیے گئے؟
Teku 26.10.3 اور Besu 26.10.2 نے اپنے ڈاکر امیجز کو تبدیل کیا ہے تاکہ متاثرہ سرٹیفیکیٹ ٹرسٹ کو ختم کیا جا سکے۔ Teku کنسنس کلائنٹ ہے اور Besu ایگزیکیشن کلائنٹ ہے، دونوں جاوا استعمال کرتے ہیں۔ انسٹالیشن کا طریقہ اہم ہے کیونکہ یہ تبدیلی ان امیجز میں فراہم کردہ ماحول پر لاگو ہوتی ہے۔ جو آپریٹرز کلائنٹ آرکائیوز کو انسٹال کرتے ہیں اور خود جاوا رن ٹائم فراہم کرتے ہیں، انہیں اس رن ٹائم کے لیے الگ گائیڈ لائن دیکھنی چاہیے۔
کیا تمام ویریفائرز متاثر ہوں گے؟
نہیں۔ تیکو کی نوٹیفیکیشن کے مطابق، ڈیفالٹ مین نیٹ نوڈ متاثر نہیں ہیں۔ خطرہ اس بات پر منحصر ہے کہ کسی ڈیپلومنٹ نے متعلقہ بیرونی HTTPS کنکشنز کیے ہیں یا نہیں، اور اس کا سرٹیفکیٹ چیک متاثرہ تھراست پاتھ کو قبول کرتا ہے یا نہیں۔ مختلف آپریٹرز ایک ہی کلائنٹ کو مختلف سروسز، جاوا ورژن اور سرٹیفکیٹ لائبریریز پر چلا سکتے ہیں۔ اس لیے، کلائنٹ کا نام یا قید کردہ ETH کی تعداد، کسی خاص ویریفائر کے متاثر ہونے کا اندازہ نہیں دیتے۔
کیا ڈاکر اپڈیٹ تمام انسٹالیشن طریقہ کاروں کو کور کرتا ہے؟
نہیں۔ پیچ کے بعد کا ڈاکر امیج، اس امیج میں شامل ماحول کو اپڈیٹ کرے گا، لیکن آرکائیو انسٹالیشن ممکنہ طور پر آپریٹر کے ذریعہ فراہم کردہ جاوا استعمال کرتا ہے۔ دیگر کنٹینرز یا سروسز بھی اپنے اپنے رن ٹائم رکھ سکتے ہیں۔ آپریٹر کو یہ پہچاننا ہوگا کہ چل رہے عمل کون سی انسٹالیشن کا استعمال کر رہا ہے، اور اس کے سپلائر کے ہدایات پر عمل کرنا ہوگا۔ سرور پر پیچ شدہ فائلیں، پرانے ماحول میں چل رہے عملز کو محفوظ نہیں کرسکتیں۔
کیا استعمال کیا گیا ہے؟
اس مضمون میں بیان کردہ وقت پر، ٹیکو کی نوٹیفیکیشنز نے کوئی استعمال نہیں بتایا۔ متعلقہ اطلاعات ایک کمزوری اور اس کے ممکنہ نتائج کی وضاحت کرتی ہیں، نہ کہ یہ ثابت کرتی ہیں کہ حملہ آور نے اسے ویریفائر کے لیے استعمال کیا ہے۔ نقصان کی بحث میں یہ فرق اہم ہے۔ ایک سروس کا دھوکہ دینے کا ممکنہ راستہ موجود ہونا، دستخط کے فرائض کو تبدیل کرنا، فیس ادائیگیوں کو منتقل کرنا یا قید شدہ ETH چوری ہونا، اس بات کے برابر نہیں ہے۔
کیا ویلیڈیٹر جماعتوں کا جمع کرنا خود بخود ظاہر ہو جائے گا؟
نہیں۔ سرٹیفیکیٹ سائننگ کلید، ویریفائر سائننگ کلید سے الگ ہے اور نکالنے کے لیے استعمال ہونے والی اجازت سے بھی الگ ہے۔ متاثرہ سرٹیفیکیٹ کلید کو بحال کرنا، ETH جمع کرانے کے لیے ضروری کلید کو خودبخود فاش نہیں کرتا۔ جھوٹی سروس کا اثر، اس کے ڈیپلومنٹ کے طریقے کے مطابق، ذمہ داریوں کو بگاڑ سکتا ہے یا ویریفائرز کے استعمال کی معلومات کو متاثر کر سکتا ہے۔ اس سروس کو مکمل جمع کردہ رقم تک خودکار رسائی کے طور پر نہیں دیکھنا چاہیے، بلکہ اس کے ممکنہ نتائج کا جائزہ لینا چاہیے۔
آپریٹر کو کیا کرنا چاہیے؟
آپ کو متعلقہ Teku یا Besu ریلیز نوٹس اور اپنے Java ایمرجن کے ہدایات کی پابندی کرنی چاہیے۔ ہر متاثرہ پروسیس کے استعمال کردہ رن ٹائم اور سرٹیفیکیٹ اسٹور کو شناخت کرنا ضروری ہے، جس میں کنٹینرز میں فراہم کردہ حصے بھی شامل ہیں۔ تجاویز کے مطابق اپڈیٹس لاگو کرنے کے بعد، یہ یقینی بنانا چاہیے کہ اپڈیٹڈ سروسز چل رہی ہیں اور درکار کنکشنز اب بھی درست طریقے سے کام کر رہے ہیں۔ ناکام کنکشنز کو بحال کرنے کے لیے سرٹیفیکیٹ چیکس معطل کرنا، ان چیکس کے ذریعے فراہم کی جانے والی حفاظت کو ختم کر دے گا۔