با کوبیدن یک رمز عبور بیش از حد طولانی، یک سیستم لینوکس musl روت کنید

در برخی از سیستم‌های لینوکس، مهاجم می‌تواند با وارد کردن رمز عبور بیش از 256 بایت، دسترسی ریشه داشته باشد. این آسیب‌پذیری که توسط محقق Wakefield، Özgün Kültekin که آن را کشف کرده، *sshole نامیده است، تنها در شرایط بسیار خاص قابل استفاده است.

این نقص سیستم‌های لینوکس خاصی را تحت تأثیر قرار می‌دهد که از musl libc به‌جای کتابخانه سنتی GNU C استفاده می‌کنند، و حتی در آن زمان فقط سیستم‌هایی را تحت تأثیر قرار می‌دهد که از دیمون پوسته ایمن OpenSSH بدون ماژول‌های تأیید اعتبار قابل اتصال (PAM) و با تأیید اعتبار رمز عبور فعال هستند، استفاده می‌کنند.

اگر این شرایط برآورده شود و حداقل یک حساب دیگر دارای هش رمز عبور معتبر باشد، حساب‌هایی که نباید رمز عبور را بپذیرند، مانند کاربران root، کاربران استقرار فقط کلید، و کاربران LDAP، ممکن است با ارائه گذرواژه‌ای بین 257 تا 1024 کاراکتر قابل دسترسی باشند. حساب‌های مورد نظر باید دارای یک ستاره (*) در قسمت رمز عبور خود باشند و ورود مستقیم ریشه منوط به پیکربندی OpenSSH است.

ممکن است جالب به نظر برسد، اما متاسفم: اینطور نیست.

Musl libc در سیستم های لینوکس جاسازی شده به دلیل ردپای کم آن رایج است. مهم‌تر از آن، این کتابخانه استاندارد C برای Alpine Linux است که تصاویر رسمی ابری را برای AWS و Azure ارائه می‌کند. بنابراین، برخی از سیستم های آلپاین که در آن محیط ها اجرا می شوند، بسته به پیکربندی آنها ممکن است آسیب پذیر باشند.

طلوع * shole

آسیب‌پذیری OpenSSH در سیستم‌های لینوکس مبتنی بر musl به سال 2016 برمی‌گردد، اما Kültekin توضیح می‌دهد که ریشه‌های آن بسیار بیشتر است - در واقع به دوران BSD Unix.

در سال 1980، بیل جوی، یکی از بنیانگذاران Sun Microsystems و BSD Unix سنگین وزن، در توسعه BSD Unix شرکت داشت که فایل رمز عبور آن شامل یک ستاره در ورودی /etc/passwd برای کاربر دیمون بود. ستاره یک هش رمز عبور نبود و به طور موثر احراز هویت رمز عبور را برای آن حساب غیرفعال کرد.

امروزه، هش‌های رمز عبور معمولا در /etc/shadow زندگی می‌کنند و حاوی اطلاعات هش‌شده‌ای هستند که سیستم برای تأیید رمز عبور متن ساده وارد شده توسط کاربر استفاده می‌کند. ستاره‌ها هنوز برای حساب‌هایی وجود دارند که قرار نیست ورود رمز عبور را بپذیرند، اما همانطور که Kültekin در نوشته‌اش توضیح می‌دهد، این دقیقا یک راه بی‌خطر برای دور نگه داشتن افراد نیست.

تابع crypt() که هش های رمز عبور را برای مقایسه با مقادیر ذخیره شده تولید می کند، اگر نتواند هش را محاسبه کند، می تواند NULL را برگرداند. برنامه هایی که نتوانند آن نتیجه را بررسی کنند ممکن است از کار بیفتند. توسعه دهندگان Musl libc در عوض انتخاب کردند که یک کاراکتر را برای خرابی های خاص برگردانند و ستاره را انتخاب کردند.

Musl همچنین هش رمز عبور مبتنی بر SHA-512 را تقریبا در همان زمان اضافه کرد، که Kültekin خاطرنشان می‌کند که هرچه گذرواژه طولانی‌تر باشد کندتر می‌شود و اگر شخصی سروری با رمز عبور فوق‌العاده طولانی را پر کند، به طور بالقوه منجر به انکار سرویس می‌شود. Musl گذرواژه‌های 256 بایتی را محدود کرد، و احتمالا می‌توانید ببینید که این به کجا می‌رود.

در سال 2016، OpenSSH راه حلی را برای جلوگیری از شمارش نام حساب های معتبر از طریق SSH توسط مهاجمان معرفی کرد. قبل از تغییر، sshd می‌توانست تلاش‌های احراز هویت را برای کاربرانی که وجود نداشتند، سریع‌تر از تلاش‌های مربوط به حساب‌های معتبر رد کند. تلاش‌ها علیه حساب‌های معتبر بیشتر طول کشید زیرا سرور باید رمز عبور ارائه‌شده را قبل از رد کردن آن هش می‌کرد. راه حل این بود که sshd هش رمز عبور ساختگی را برای کاربران نامعتبر انجام دهد، با استفاده از یک الگوریتم هش مناسب و salt برای کاهش تفاوت در زمان پاسخ.

در سیستم‌های لینوکس مبتنی بر musl آسیب‌دیده، حساب‌هایی که به‌جای هش رمز عبور با یک ستاره علامت‌گذاری شده‌اند، می‌توانند با ارائه گذرواژه‌ای بیش از ۲۵۶ بایت باز شوند - نقصی که به سال ۲۰۱۶ بازمی‌گردد. هر سیستم لینوکس مبتنی بر musl که یک پیکربندی OpenSSH آسیب‌پذیر را بدون PAM اجرا می‌کند، با یک گذرواژه دیگر با حداقل یک رمز عبور معتبر با علامت‌گذاری رمز عبور معتبر، با یک گذرواژه معتبر فعال است. هش می تواند در برابر حمله *sshole آسیب پذیر باشد.

خوشبختانه، OpenSSH برای رفع این مشکل سریع عمل کرد و هر نسخه OpenSSH 10.6p2 (منتشر شده پنجشنبه) یا جدیدتر محافظت می شود. از طرف دیگر، اگر نمی توانید اجرای OpenSSH خود را در یک سیستم آسیب دیده به روز کنید، فقط احراز هویت رمز عبور را غیرفعال کنید و شبح SSH را مجددا راه اندازی کنید و باید کاملا آماده باشید.

هیچ نشانه‌ای مبنی بر سوء استفاده از سیستم‌های آسیب‌پذیر وجود ندارد، اما اگر می‌خواهید بررسی کنید، Kültekin یک دستور ساده CLI را در نوشتن خود گنجانده است که می‌تواند برای بررسی اینکه آیا حساب‌های بدون رمز عبور در یک ماشین حساس اخیرا رمز عبور دریافت کرده‌اند یا خیر. ®