SSH کلائنٹس میں OpenSSH اور PuTTY ( پٹی میں اور OpenSSH میں)، کنکشن گفت و شنید الگورتھم میں معلومات کے رساو کا باعث بنتا ہے۔ کمزوری ایک حملہ آور کو اجازت دیتی ہے کہ وہ کلائنٹ ٹریفک کو روکنے کے قابل ہو (مثال کے طور پر، جب کوئی صارف حملہ آور کے زیر کنٹرول وائرلیس ایکسیس پوائنٹ کے ذریعے رابطہ کرتا ہے) جب کلائنٹ نے ابھی تک میزبان کلید کو کیش نہیں کیا ہو تو ابتدائی طور پر کلائنٹ کو میزبان سے مربوط کرنے کی کوشش کا پتہ لگاتا ہے۔
یہ جانتے ہوئے کہ کلائنٹ پہلی بار رابطہ قائم کرنے کی کوشش کر رہا ہے اور اس کے پاس ابھی تک میزبان کلید نہیں ہے، حملہ آور کنکشن کو خود (MITM) کے ذریعے نشر کر سکتا ہے اور کلائنٹ کو اپنی میزبان کلید دے سکتا ہے، جس پر SSH کلائنٹ غور کرے گا۔ ہدف کے میزبان کی کلید بنیں اگر یہ کلیدی فنگر پرنٹ کی تصدیق نہیں کرتا ہے۔ اس طرح، ایک حملہ آور صارف کے شکوک و شبہات کو ہوا دیے بغیر MITM کو منظم کر سکتا ہے اور ان سیشنز کو نظر انداز کر سکتا ہے جن میں کلائنٹ کی طرف سے پہلے ہی میزبان کیز کو کیش کیا گیا ہے، اس کو تبدیل کرنے کی کوشش جس کے نتیجے میں میزبان کلید کی تبدیلی کے بارے میں انتباہ ہو گا۔ یہ حملہ ان صارفین کی لاپرواہی پر مبنی ہے جو پہلی بار رابطہ کرتے وقت میزبان کلید کے فنگر پرنٹ کو دستی طور پر چیک نہیں کرتے ہیں۔ کلیدی انگلیوں کے نشانات چیک کرنے والے ایسے حملوں سے محفوظ رہتے ہیں۔
کنکشن کی پہلی کوشش کا تعین کرنے کی علامت کے طور پر، معاون میزبان کلیدی الگورتھم کی فہرست سازی کی ترتیب میں تبدیلی کا استعمال کیا جاتا ہے۔ اگر پہلا کنکشن ہوتا ہے تو، کلائنٹ پہلے سے طے شدہ الگورتھم کی فہرست منتقل کرتا ہے، اور اگر میزبان کلید پہلے سے ہی کیشے میں ہے، تو متعلقہ الگورتھم کو پہلی جگہ پر رکھا جاتا ہے (الگورتھم کو ترجیح کے مطابق ترتیب دیا جاتا ہے)۔
مسئلہ OpenSSH ریلیز 5.7 سے 8.3 اور PuTTY 0.68 سے 0.73 میں ظاہر ہوتا ہے۔ مسئلہ مسئلہ میں الگورتھم کو مستقل ترتیب میں درج کرنے کے حق میں میزبان کلیدی پروسیسنگ الگورتھم کی فہرست کی متحرک تعمیر کو غیر فعال کرنے کا اختیار شامل کرکے۔
OpenSSH پروجیکٹ SSH کلائنٹ کے رویے کو تبدیل کرنے کا ارادہ نہیں رکھتا ہے، کیونکہ اگر آپ پہلے سے موجود کلید کے الگورتھم کی وضاحت نہیں کرتے ہیں، تو ایک الگورتھم کو استعمال کرنے کی کوشش کی جائے گی جو کیشڈ کلید سے مطابقت نہیں رکھتی اور نامعلوم کلید کے بارے میں ایک انتباہ دکھایا جائے گا۔ وہ. ایک انتخاب پیدا ہوتا ہے - یا تو معلومات کا رساو (OpenSSH اور PuTTY)، یا کلید (Dropbear SSH) کو تبدیل کرنے کے بارے میں انتباہ اگر محفوظ کی گئی کلید پہلے سے طے شدہ فہرست میں پہلے الگورتھم سے مطابقت نہیں رکھتی ہے۔
سیکورٹی فراہم کرنے کے لیے، OpenSSH DNSSEC اور میزبان سرٹیفکیٹس (PKI) میں SSHFP اندراجات کا استعمال کرتے ہوئے میزبان کلید کی تصدیق کے لیے متبادل طریقے پیش کرتا ہے۔ آپ HostKeyAlgorithms آپشن کے ذریعے میزبان کلیدی الگورتھم کے موافق انتخاب کو بھی غیر فعال کر سکتے ہیں اور کلائنٹ کو تصدیق کے بعد اضافی میزبان کیز حاصل کرنے کی اجازت دینے کے لیے UpdateHostKeys آپشن کا استعمال کر سکتے ہیں۔
ماخذ: opennet.ru