آسیب پذیری SSHole در OpenSSH؛ دور زدن احراز هویت در سرورهای لینوکسی

آسیب پذیری SSHole در OpenSSH؛ دور زدن احراز هویت در سرورهای لینوکسی

در تاریخ ۵ نوامبر 2026 آسیب‌ پذیری SSHole با شناسه CVE-2026-123158 در سرویس OpenSSH شناسایی شد که امکان دور زدن احراز هویت و دسترسی غیرمجاز به برخی حساب‌های کاربری در سیستم‌های لینوکسی را فراهم می‌کند. این آسیب‌پذیری در شرایط پیکربندی خاص به مهاجمان اجازه می‌دهد بدون اطلاع از رمز عبور واقعی، از طریق سرویس SSH وارد حساب‌های آسیب‌پذیر شوند. اهمیت این نقص زمانی بیشتر شد که تنها چند ساعت پس از انتشار عمومی اطلاعات آن، تلاش‌های واقعی برای سوءاستفاده از آسیب‌پذیری شناسایی شد و دست‌کم یک مورد دسترسی موفق با سطح دسترسی Root در یک محیط آزمایشی گزارش شد.

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

آسیب پذیری SSHole چگونه کار می‌کند؟

SSH یا Secure Shell پروتکلی برای برقراری ارتباط رمزگذاری‌شده و مدیریت از راه دور سرورها و تجهیزات شبکه است. مدیران سیستم از این پروتکل برای ورود به سرورهای لینوکسی، اجرای دستورات، انتقال فایل و مدیریت سرویس‌های مختلف استفاده می‌کنند. آسیب پذیری SSHole در نحوه بررسی رمز عبور توسط سرویس OpenSSH و تعامل آن با کتابخانه استاندارد C به نام musl libc ایجاد شده است. در برخی سیستم‌های لینوکسی، حساب‌هایی که برای ورود با کلید SSH تنظیم شده‌اند و رمز عبور ندارند، با علامت «*» در فایل /etc/shadow مشخص می‌شوند. این علامت نشان می‌دهد که حساب نباید امکان احراز هویت با رمز عبور را داشته باشد.

مشکل زمانی ایجاد می‌شود که OpenSSH بدون پشتیبانی PAM روی سیستمی مبتنی بر musl اجرا شود. در چنین شرایطی، تابع crypt() در کتابخانه musl برای رمزهای عبور طولانی‌تر از ۲۵۶ بایت، علامت «*» را به‌عنوان خروجی خطا برمی‌گرداند. از آنجا که این مقدار با علامت ذخیره‌شده برای حساب‌های بدون رمز عبور یکسان است، OpenSSH ممکن است آن را به‌اشتباه یک تطابق معتبر تشخیص دهد و ورود مهاجم را بپذیرد.

استفاده ایمن از SSH به پیکربندی صحیح سرویس‌های مدیریتی و تنظیم اصولی دسترسی کاربران در زمان استقرار سرور وابسته است. انتخاب سیستم‌عامل مناسب، پیکربندی سرویس‌های شبکه، تنظیم روش‌های احراز هویت و استفاده از خدمات راه اندازی سرور از جمله مواردی هستند که باید مورد توجه قرار گیرند.

چگونگی آسیب پذیری SSHole

کدام نسخه‌ها و سیستم‌عامل‌ها در معرض آسیب پذیری SSHole هستند؟

آسیب‌پذیری CVE-2026-123158 سیستم‌هایی که از OpenSSH مبتنی بر کتابخانه musl libc و بدون PAM استفاده می‌کنند، در صورت برقرار بودن شرایط مشخصی در معرض این نقص امنیتی قرار دارند. برای سوءاستفاده از SSHole، شرایط زیر باید هم‌زمان وجود داشته باشند:

  • استفاده از نسخه‌های OpenSSH قدیمی‌تر از 10.6p2
  • استفاده از کتابخانه musl libc
  • غیرفعال بودن PAM در فرایند احراز هویت SSH
  • فعال بودن قابلیت PasswordAuthentication
  • وجود حداقل یک حساب کاربری با فیلد رمز عبور «*» و یک حساب محلی دیگر با هش رمز عبور SHA-256 یا SHA-512

چرا سرورهای Alpine Linux بیشتر در معرض آسیب پذیری SSHole هستند؟

Alpine Linux به‌صورت پیش‌فرض از musl libc استفاده می‌کند و بسته معمول OpenSSH Server آن نیز بدون PAM ساخته شده است. به همین دلیل این توزیع یکی از مهم‌ترین نمونه‌های تحت تأثیر آسیب پذیری SSHole محسوب می‌شود.

اطلاعیه امنیتی رسمی Alpine Linux نسخه‌های بررسی‌شده 3.16 تا 3.24 و شاخه Edge تحت تأثیر این نقص قرار داشته‌اند. همچنین سیستم‌های مبتنی بر OpenWrt ،Buildroot و Yocto و برخی ایمیج‌های کانتینری که سرویس OpenSSH را با شرایط آسیب‌پذیر اجرا می‌کنند، باید بررسی شوند.

در مقابل Red Hat اعلام کرده محصولات این شرکت از جمله RHEL تحت تأثیر این آسیب‌پذیری نیستند؛ زیرا نسخه‌های OpenSSH آن از glibc استفاده می‌کنند و به‌صورت پیش‌فرض با PAM اجرا می‌شوند. همچنین سیستم‌های متداول Debian، Ubuntu و Fedora با پیکربندی‌های رایج خود در معرض این سناریوی خاص قرار ندارند.

سرورهای Alpine Linux در معرض آسیب پذیری SSHole

سوءاستفاده مهاجمان از آسیب پذیری SSHole

یکی از مهم‌ترین جنبه‌های امنیتی SSHole فاصله زمانی کوتاه میان انتشار اطلاعات آسیب‌پذیری و شروع تلاش‌های مهاجمان برای بهره‌برداری از آن است. شرکت امنیت سایبری Previdian در ۶ نوامبر اعلام کرد نخستین تلاش شناسایی‌شده برای سوءاستفاده از این نقص، کمتر از ۹ ساعت پس از انتشار عمومی اطلاعات CVE انجام شده است. طبق گزارش این شرکت مهاجم با ارسال رمز عبور طولانی توانسته بود احراز هویت یک حساب آسیب‌پذیر را دور بزند و در یک Honeypot مبتنی بر Alpine Linux به دسترسی Root برسد. در این حمله مهاجم پس از ورود به محیط آزمایشی، دستورهایی مانند id، uname و hostname را برای شناسایی سیستم اجرا کرده بود.

گزارش‌های جدیدتر GreyNoise در ۸ نوامبر نیز ادامه فعالیت مهاجمان را تأیید می‌کنند. این سامانه در ردیاب اختصاصی SSHole، علاوه بر تلاش‌های احتمالی برای بهره‌برداری، فعالیت‌های پس از نفوذ را در محیط‌های پایش آسیب‌پذیر ثبت کرده است. در یکی از نمونه‌های مستند، مهاجم پس از دستیابی به دسترسی Root تلاش کرده بود یک عامل پایتونی برای برقراری ارتباط با سرور فرماندهی و کنترل (C2) نصب کند. این اطلاعات نشان می‌دهد که آسیب پذیری SSHole از مرحله یک نقص نظری عبور کرده و در حملات واقعی مورد استفاده قرار گرفته است.

چگونه آسیب پذیری SSHole را برطرف کنیم؟

تیم توسعه OpenSSH در ۵ نوامبر ۲۰۲۶ نسخه OpenSSH 10.6p2 را برای رفع آسیب‌پذیری CVE-2026-123158 منتشر کرد. هم‌زمان توسعه‌دهندگان Alpine Linux نیز بسته‌های اصلاح‌شده را برای تمام شاخه‌ها از نسخه 3.16 تا Edge منتشر کردند. البته که نصب به‌روزرسانی به‌تنهایی برای رفع خطر کافی نیست و مدیران سیستم باید چند اقدام تکمیلی را نیز انجام دهند.

1. به‌روزرسانی OpenSSH و راه‌اندازی مجدد سرویس SSH

اولین اقدام، نصب نسخه اصلاح‌شده OpenSSH از مخازن رسمی سیستم‌عامل است. کاربران Alpine Linux نیز باید بسته اصلاحی متناسب با شاخه مورد استفاده خود را نصب کنند. نکته مهم این است که نصب بسته جدید، فرایند در حال اجرای sshd را به‌صورت خودکار جایگزین نمی‌کند. در نتیجه حتی پس از به‌روزرسانی ممکن است نسخه آسیب‌پذیر همچنان به درخواست‌های اتصال پاسخ دهد.

2. غیرفعال‌کردن موقت احراز هویت مبتنی بر رمز عبور

در سیستم‌هایی که از musl libc استفاده می‌کنند و PAM در آن‌ها غیرفعال است، توسعه‌دهنده OpenSSH، دیمین میلر (Damien Miller)، توصیه کرده است که مدیران سیستم به سرعت قابلیت احراز هویت مبتنی بر رمز عبور را با تنظیم PasswordAuthentication no غیرفعال کنند یا در صورت نیاز دسترسی SSH را تا زمان رفع آسیب‌پذیری به‌طور موقت ببندند. این اقدام می‌تواند احتمال سوءاستفاده از آسیب‌پذیری را کاهش دهد؛ البته پیش از اعمال آن باید از عملکرد صحیح روش جایگزین احراز هویت مانند کلید SSH، اطمینان حاصل شود تا دسترسی مدیریتی به سرور از بین نرود.

3. بررسی لاگ‌ها و شناسایی دسترسی‌های غیرمجاز

پس از نصب پچ (Patch) بررسی لاگ‌های سیستم برای شناسایی ورودهای مشکوک اهمیت زیادی دارد. طبق توصیه SOCRadar مدیران سیستم باید فایل /var/log/messages را برای پیدا کردن پیام‌های Accepted password for بررسی کنند؛ به‌خصوص زمانی که این پیام‌ها به حساب‌هایی مانند alpine، root یا حساب‌هایی اشاره دارند که نباید امکان ورود با رمز عبور داشته باشند. بررسی فعالیت‌های انجام‌شده با ابزار doas، شناسایی کاربران تازه‌ساخته‌شده و بازبینی فایل‌های authorized_keys نیز می‌تواند به کشف دسترسی‌های غیرمجاز کمک کند. از آنجا که آسیب‌پذیری‌های امنیتی ممکن است در هر یک از اجزای زیرساخت فناوری اطلاعات ظاهر شوند، پشتیبانی شبکه از جمله بررسی مداوم وضعیت سرویس‌ها، کنترل دسترسی‌ها و نصب اصلاحیه‌های امنیتی باید به‌صورت مستمر انجام شود.

4. احتیاط در استفاده از کدهای PoC

پس از افشای آسیب پذیری SSHole، چند کد PoC برای نمایش نحوه سوءاستفاده از آن در GitHub منتشر شد. البته که شرکت Previdian هشدار داده است که اعتبارسنجی امنیتی این کدها تأیید نشده و برخی از آن‌ها ممکن است حاوی بدافزار باشند. بنابراین مدیران سرور و متخصصان امنیت نباید بدون بررسی منبع و اعتبار کدها، آن‌ها را روی سیستم‌های عملیاتی اجرا کنند. استفاده از نمونه‌کدهای تأییدنشده می‌تواند به‌جای کمک به ارزیابی امنیت، خود به مسیری برای آلوده‌شدن زیرساخت تبدیل شود.

آسیب پذیری SSHole چه هشداری برای امنیت سرورها دارد؟

آسیب پذیری SSHole نشان داد حتی ابزارهای پرکاربردی مانند OpenSSH که نقش مهمی در مدیریت و دسترسی از راه دور به سرورها دارند، ممکن است به نقطه‌ای برای نفوذ مهاجمان تبدیل شوند. امکان دور زدن احراز هویت و دسترسی غیرمجاز به حساب‌های کاربری، اهمیت محافظت از سرویس‌های مدیریتی، کنترل سطح دسترسی کاربران و شناسایی به‌موقع آسیب‌پذیری‌های امنیتی را بیش از گذشته نشان می‌دهد.

در چنین شرایطی حفظ امنیت زیرساخت سازمانی تنها به نصب وصله‌های امنیتی محدود نمی‌شود؛ بلکه ارزیابی مستمر وضعیت امنیتی شبکه، به‌روزرسانی تجهیزات و نرم‌افزارها، پایش ترافیک، بررسی لاگ‌ها، شناسایی رفتارهای مشکوک و مدیریت دسترسی‌ها نیز باید به‌صورت منظم انجام شود. اجرای این اقدامات در کنار استفاده از راهکارهای حفاظتی مناسب، احتمال نفوذ و گسترش حملات سایبری در زیرساخت سازمان را کاهش می‌دهد. در این راستا متخصصان فالنیک آماده‌اند تا با ارائه خدمات امنیت شبکه، به سازمان‌ها در شناسایی و مدیریت ریسک‌های امنیتی و تقویت حفاظت از زیرساخت شبکه کمک کنند.

خدمات امنیت شبکه توسط بهترین‌ها
متخصصان ما با اجرای بیش از 9 هزار پروژه موفق IT و به پشتوانه سه دهه تجربه در حوزه شبکه، امنیت شبکه شما را به بهترین نحو تامین می‌کنند. همین حالا با ما تماس بگیرید و ضمن استفاده از مشاوره رایگان متخصصان ما، شبکه‌ی خود را به دژی غیر قابل نفوذ تبدیل کنید.

5/5 - (1 امتیاز)
منبع
Helpnetsecurity
سپهراد فرزامی
من سپهراد فرزامی، نویسنده و کارشناس تولید محتوا هستم و در حوزه فناوری اطلاعات و تجهیزات شبکه و سرور فعالیت می‌کنم. تمرکز من بر تولید محتوای تخصصی، سئو و ارائه اطلاعات دقیق و کاربردی است. من تلاش می‌کنم که مفاهیم پیچیده فناوری را به زبانی ساده، روان و قابل‌فهم برای مخاطبان ارائه بدهم.

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا