آسیب پذیری در کلاینت های SSH OpenSSH و PuTTY

در کلاینت های SSH OpenSSH و PuTTY شناخته شده است آسیب پذیری (CVE-2020-14002 در PuTTY و CVE-2020-14145 در OpenSSH)، منجر به نشت اطلاعات در الگوریتم مذاکره اتصال می شود. این آسیب‌پذیری به مهاجمی اجازه می‌دهد تا ترافیک کلاینت را رهگیری کند (به عنوان مثال، وقتی کاربر از طریق یک نقطه دسترسی بی‌سیم کنترل‌شده توسط مهاجم متصل می‌شود) تلاش برای اتصال اولیه کلاینت به میزبان را در زمانی که کلاینت هنوز کلید میزبان را ذخیره نکرده است، شناسایی کند.

با علم به اینکه کلاینت برای اولین بار در تلاش برای اتصال است و هنوز کلید میزبان را در کنار خود ندارد، مهاجم می تواند اتصال را از طریق خود (MITM) پخش کند و کلید میزبان خود را به کلاینت بدهد که کلاینت SSH آن را در نظر می گیرد. اگر اثر انگشت کلید را تأیید نکرد، کلید میزبان مورد نظر باشد. بنابراین، یک مهاجم می‌تواند MITM را بدون برانگیختن سوء ظن کاربر سازماندهی کند و جلساتی را که در آن سمت کلاینت از قبل کلیدهای میزبان را در حافظه پنهان دارد، نادیده بگیرد، تلاشی برای جایگزینی که منجر به هشدار در مورد تغییر کلید میزبان می‌شود. این حمله بر اساس بی احتیاطی کاربرانی است که هنگام اولین اتصال، اثر انگشت کلید میزبان را به صورت دستی بررسی نمی کنند. کسانی که اثر انگشت کلید را بررسی می کنند در برابر چنین حملاتی در امان هستند.

به عنوان نشانه ای برای تعیین اولین تلاش برای اتصال، از تغییر در ترتیب فهرست الگوریتم های کلید میزبان پشتیبانی شده استفاده می شود. اگر اولین اتصال رخ دهد، کلاینت لیستی از الگوریتم‌های پیش‌فرض را ارسال می‌کند، و اگر کلید میزبان از قبل در حافظه پنهان باشد، الگوریتم مرتبط در وهله اول قرار می‌گیرد (الگوریتم‌ها به ترتیب اولویت مرتب می‌شوند).

مشکل در نسخه های OpenSSH 5.7 تا 8.3 و PuTTY 0.68 تا 0.73 ظاهر می شود. مسئله حذف شده است در موضوع بتونه 0.74 با افزودن گزینه ای برای غیرفعال کردن ساخت پویا لیستی از الگوریتم های پردازش کلید میزبان به نفع فهرست کردن الگوریتم ها به ترتیب ثابت.

پروژه OpenSSH برنامه ای برای تغییر رفتار کلاینت SSH ندارد، زیرا اگر در ابتدا الگوریتم کلید موجود را مشخص نکنید، سعی می شود از الگوریتمی استفاده شود که با کلید ذخیره شده مطابقت ندارد و یک هشدار در مورد یک کلید ناشناخته نمایش داده می شود. آن ها یک انتخاب ایجاد می شود - یا نشت اطلاعات (OpenSSH و PuTTY)، یا هشدار در مورد تغییر کلید (Dropbear SSH) اگر کلید ذخیره شده با اولین الگوریتم در لیست پیش فرض مطابقت نداشته باشد.

برای تأمین امنیت، OpenSSH روش‌های جایگزینی را برای تأیید کلید میزبان با استفاده از ورودی‌های SSHFP در DNSSEC و گواهی‌های میزبان (PKI) ارائه می‌کند. همچنین می‌توانید انتخاب تطبیقی ​​الگوریتم‌های کلید میزبان را از طریق گزینه HostKeyAlgorithms غیرفعال کنید و از گزینه UpdateHostKeys استفاده کنید تا به مشتری اجازه دهید پس از احراز هویت، کلیدهای میزبان اضافی را دریافت کند.

منبع: opennet.ru