هکرها از یک حفره امنیتی خطرناک در لینوکس سوءاستفاده می‌کنند

هکرها سوءاستفاده از یک آسیب‌پذیری مهم در نرم‌افزار OpenSSH را آغاز کرده‌اند؛ نقصی که در بعضی پیکربندی‌های سیستم‌عامل لینوکس به مهاجم اجازه می‌دهد بدون دانستن رمز عبور واقعی، وارد حساب‌های کاربری شود و در مواردی حتی به سطح دسترسی مدیر سیستم برسد. آژانس امنیت سایبری و زیرساخت آمریکا، CISA، روز ۹ نوامبر ۲۰۲۶ با تأیید سوءاستفاده فعال از این حفره، آن را به فهرست آسیب‌پذیری‌هایی اضافه کرد که شرکت‌ها و سازمان‌ها باید با فوریت بیشتری برای رفع آن‌ها اقدام کنند.

این حفره امنیتی با شناسه CVE-2026-123158 و نام غیررسمی SSHole شناخته می‌شود. مشکل اصلی در تعامل OpenSSH با کتابخانه نرم‌افزاری musl ایجاد می‌شود و به‌خصوص می‌تواند بعضی سیستم‌های مبتنی بر توزیع سبک Alpine Linux را تحت تأثیر قرار دهد.

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

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

حفره SSHole چگونه شناسایی شد؟

OpenSSH یکی از نرم‌افزارهای مهم برای دسترسی امن و از راه دور به رایانه‌ها و سرورها است. مدیران شبکه معمولاً از این ابزار برای اتصال به سرورهای لینوکسی، انتقال فایل و اجرای دستورات مدیریتی استفاده می‌کنند.

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

اما امنیت ارتباط رمزگذاری‌شده تنها بخشی از ماجرا است. سرور باید بتواند تشخیص دهد شخصی که قصد ورود دارد واقعاً مجاز است یا خیر.

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

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

کشف این مشکل به پژوهشگر امنیتی Özgün Kültekin نسبت داده شده است. پس از افشای عمومی در ۵ نوامبر، پروژه OpenSSH و توسعه‌دهندگان Alpine Linux اصلاحیه‌هایی برای جلوگیری از سوءاستفاده منتشر کردند.

اما فاصله میان انتشار یک اصلاحیه و نصب آن روی تمام سرورهای آسیب‌پذیر می‌تواند فرصت مناسبی برای مهاجمان ایجاد کند.

به همین دلیل، تنها چند روز پس از افشای عمومی، گزارش‌هایی درباره تلاش برای بهره‌برداری از این حفره منتشر شد.

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

برای درک علت این نقص باید با دو بخش نرم‌افزاری آشنا شد: OpenSSH و musl.

OpenSSH مسئول ایجاد و مدیریت ارتباط امن از راه دور است. در مقابل، musl کتابخانه‌ای برای اجرای توابع پایه زبان برنامه‌نویسی C در سیستم‌های مبتنی بر لینوکس است.

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

بسیاری از توزیع‌های شناخته‌شده لینوکس از کتابخانه دیگری به نام glibc استفاده می‌کنند، اما Alpine Linux به دلیل طراحی سبک و نیاز کمتر به منابع، از musl بهره می‌برد.

Alpine به‌ویژه در محیط‌های کانتینری، برخی سرویس‌های ابری و تجهیزات کم‌مصرف استفاده می‌شود.

مشکل SSHole زمانی ایجاد می‌شود که OpenSSH در کنار musl و بدون استفاده از سازوکار احراز هویت PAM اجرا شود و تنظیمات حساب‌های کاربری نیز شرایط خاصی داشته باشند.

PAM مجموعه‌ای از ماژول‌ها است که در بسیاری از سیستم‌های لینوکسی برای مدیریت فرایند احراز هویت استفاده می‌شود.

در پیکربندی آسیب‌پذیر، نتیجه خاصی که کتابخانه musl هنگام پردازش ورودی نامعتبر برمی‌گرداند، ممکن است توسط OpenSSH به اشتباه تفسیر شود.

این اشتباه می‌تواند باعث شود سیستم در شرایط مشخص، یک تلاش ورود غیرمجاز را معتبر تشخیص دهد.

نکته مهم آن است که صرف نصب OpenSSH روی لینوکس برای آسیب‌پذیر بودن کافی نیست. ترکیب کتابخانه، وضعیت PAM و تنظیمات حساب‌ها باید بررسی شوند.

چرا این نقص می‌تواند خطرناک باشد؟

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

اما SSHole در بعضی پیکربندی‌ها امکان عبور از مرحله احراز هویت را فراهم می‌کند.

اگر حسابی با سطح دسترسی بالا در معرض این مشکل قرار داشته باشد، پیامدهای ورود غیرمجاز می‌تواند جدی باشد.

مهاجم ممکن است بتواند اطلاعات ذخیره‌شده را بررسی کند، تنظیمات سرویس را تغییر دهد یا نرم‌افزارهای دیگری روی دستگاه اجرا کند.

در برخی محیط‌ها نیز دسترسی به یک سرور می‌تواند راه را برای تلاش جهت ورود به قسمت‌های دیگر شبکه باز کند.

البته نتیجه نهایی به سطح دسترسی حساب آسیب‌پذیر وابسته است. ورود به یک حساب محدود الزاماً به معنی دسترسی کامل به تمام سیستم نیست.

با وجود این، نقص احراز هویت در سرویسی مانند SSH اهمیت ویژه‌ای دارد؛ زیرا این سرویس معمولاً برای مدیریت بخش‌های حساس زیرساخت استفاده می‌شود.

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

حملات واقعی از چه زمانی آغاز شدند؟

براساس گزارش‌های شرکت‌های امنیت سایبری، تلاش برای سوءاستفاده از SSHole اندکی پس از افشای عمومی آن آغاز شد.

شرکت Previdian اعلام کرده حسگرهای امنیتی آن در فاصله ۶ تا ۸ نوامبر، ۲۰ تلاش مرتبط با این آسیب‌پذیری را از ۱۳ نشانی IP متفاوت ثبت کرده‌اند.

این نشانی‌ها به ۹ کشور نسبت داده شده بودند.

البته محل جغرافیایی یک نشانی IP لزوماً محل واقعی مهاجم را مشخص نمی‌کند. مهاجمان می‌توانند از سرورهای اجاره‌ای، سامانه‌های آلوده یا زیرساخت‌های واسط در کشورهای دیگر استفاده کنند.

شرکت watchTowr نیز از مشاهده فعالیت‌هایی خبر داده که با شبکه‌های بات‌نت و استخراج غیرمجاز رمزارز ارتباط داشته‌اند.

بات‌نت شبکه‌ای از دستگاه‌های آلوده است که می‌توانند از راه دور تحت کنترل مهاجم قرار بگیرند.

چنین شبکه‌هایی ممکن است برای ارسال درخواست‌های مخرب، حملات اختلال سرویس یا فعالیت‌های غیرمجاز دیگر استفاده شوند.

گزارش این شرکت‌ها نشان می‌دهد SSHole از مرحله یک نقص تئوری یا آزمایشگاهی فراتر رفته است.

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

پژوهشگران GreyNoise چه چیزی پیدا کردند؟

شرکت امنیتی GreyNoise نیز در ۹ نوامبر اطلاعات تازه‌ای درباره حملات منتشر کرد.

این شرکت از شبکه‌ای از سامانه‌های آزمایشی برای مشاهده رفتار مهاجمان استفاده می‌کند. چنین سامانه‌هایی که با عنوان Honeypot یا تله امنیتی شناخته می‌شوند، برای جذب و ثبت فعالیت مهاجمان طراحی شده‌اند.

هدف از این روش آن است که پژوهشگران بدون در معرض خطر قرار دادن زیرساخت عملیاتی واقعی، بتوانند شیوه حمله و ابزارهای استفاده‌شده را بررسی کنند.

GreyNoise اعلام کرده گروهی از مهاجمان را با شناسه GT10 ردیابی کرده است.

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

همچنین نشانه‌هایی از تلاش برای بررسی اطلاعات حساس و آماده‌سازی ابزارهای کنترل از راه دور مشاهده شده است.

این فعالیت‌ها از یک تلاش ساده برای آزمایش وجود آسیب‌پذیری فراتر هستند و نشان می‌دهند دست‌کم برخی مهاجمان برنامه مشخصی برای استفاده از دسترسی به‌دست‌آمده داشته‌اند.

با این حال، شناسه GT10 نام یک کشور یا سازمان شناخته‌شده نیست؛ بلکه برچسبی است که شرکت تحقیقاتی برای دسته‌بندی فعالیت مشاهده‌شده به کار برده است.

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

بدافزاری به نام TAC Agent

یکی از یافته‌های جالب پژوهشگران، مشاهده تلاش مهاجمان برای نصب ابزاری به نام TAC Agent بود.

این نرم‌افزار بر پایه Python ساخته شده و می‌تواند به‌عنوان عامل کنترل از راه دور فعالیت کند.

ابزارهای این‌چنینی ممکن است امکان دریافت فرمان، بررسی وضعیت سیستم، انتقال فایل و اجرای عملیات مختلف را برای مهاجم فراهم کنند.

GreyNoise گزارش داده که در بعضی حملات، مهاجمان ابتدا تلاش کرده‌اند محیط لازم برای اجرای Python را آماده کنند.

این رفتار نشان می‌دهد هدف مهاجمان فقط ورود کوتاه‌مدت به سیستم نبوده و آن‌ها برای مراحل بعدی نیز برنامه داشته‌اند.

در یکی از موارد بررسی‌شده، پژوهشگران مشاهده کردند که ابزار مخرب برای ارتباط با زیرساخت کنترل مهاجم تلاش کرده، اما آن ارتباط برقرار نشده است.

این جزئیات اهمیت دارد؛ زیرا نصب یک ابزار مخرب و برقرار شدن موفق ارتباط با سرور فرماندهی، دو مرحله متفاوت هستند.

همچنین در برخی قسمت‌های کد این ابزار، توضیحات و پیام‌هایی به زبان چینی مشاهده شده است.

با وجود این، زبان نوشته‌شده در کد برای تعیین هویت یا ملیت مهاجم کافی نیست. برنامه‌نویسان می‌توانند از کدهای آماده، ابزارهای ترجمه یا مدل‌های تولید کد استفاده کنند.

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

هشدار رسمی دولت آمریکا در ۹ نوامبر

اهمیت خبر جدید زمانی بیشتر شد که CISA در روز ۹ نوامبر آسیب‌پذیری SSHole را به فهرست Known Exploited Vulnerabilities اضافه کرد.

این فهرست که به اختصار KEV نامیده می‌شود، شامل نقص‌هایی است که شواهدی از سوءاستفاده واقعی از آن‌ها وجود دارد.

تفاوت مهمی میان وجود یک آسیب‌پذیری و ثبت آن در KEV وجود دارد.

بسیاری از ضعف‌های نرم‌افزاری ممکن است در آزمایشگاه شناسایی شوند، اما شواهدی از استفاده عملی مهاجمان علیه سامانه‌های واقعی وجود نداشته باشد.

در مقابل، قرار گرفتن یک نقص در فهرست KEV نشان می‌دهد نهاد امنیت سایبری آمریکا شواهد کافی برای تأیید سوءاستفاده فعال از آن را در اختیار دارد.

CISA در همان اطلاعیه چهار آسیب‌پذیری را به فهرست اضافه کرد که SSHole یکی از آن‌ها بود.

این نهاد برای دستگاه‌های غیرنظامی فدرال مشمول دستورالعمل مربوط، تاریخ ۱۲ نوامبر ۲۰۲۶ را به‌عنوان موعد اقدام تعیین کرده است.

البته این مهلت قانونی را نباید به تمام شرکت‌های خصوصی جهان تعمیم داد. با این حال، حضور یک نقص در KEV می‌تواند نشانه مهمی برای اولویت‌بندی اصلاحات امنیتی در سازمان‌ها باشد.

آیا تمام سرورهای لینوکسی در خطر هستند؟

پاسخ کوتاه منفی است.

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

OpenSSH روی سیستم‌عامل‌ها و توزیع‌های متعددی استفاده می‌شود، اما SSHole فقط در شرایط مشخصی قابل بهره‌برداری است.

Red Hat اعلام کرده محصولات این شرکت تحت تأثیر نقص موردنظر قرار نمی‌گیرند؛ زیرا OpenSSH در Red Hat Enterprise Linux از glibc و تنظیمات احراز هویت متفاوت استفاده می‌کند.

این شرکت تأکید کرده مشکل به ترکیب OpenSSH، کتابخانه musl و نبود PAM مربوط است.

همچنین استفاده از Alpine Linux به‌تنهایی اثبات نمی‌کند یک دستگاه آسیب‌پذیر است.

مدیر سیستم باید بررسی کند چه نسخه‌ای از OpenSSH نصب شده، کدام کتابخانه برای اجرای آن استفاده می‌شود و تنظیمات احراز هویت چگونه هستند.

وجود اصلاحیه نصب‌شده نیز اهمیت دارد.

از سوی دیگر، ممکن است دستگاه‌هایی که مدت‌هاست به‌روزرسانی نشده‌اند یا از نسخه‌های قدیمی نرم‌افزار استفاده می‌کنند، همچنان در معرض خطر باشند.

این مسئله به‌ویژه برای تجهیزات توکار یا سامانه‌هایی اهمیت دارد که سازنده آن‌ها به‌روزرسانی امنیتی منظم ارائه نمی‌کند.

چرا Alpine Linux در گزارش‌ها بیشتر مطرح شده است؟

Alpine Linux به دلیل حجم کم و سادگی ساختار خود در بسیاری از محیط‌های نرم‌افزاری محبوب است.

این توزیع معمولاً در ساخت ایمیج‌های کانتینری استفاده می‌شود؛ محیط‌هایی که برنامه و وابستگی‌های موردنیاز آن را در بسته‌ای قابل اجرا قرار می‌دهند.

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

مزیت استفاده از سیستم‌عامل سبک آن است که بسته نرم‌افزاری می‌تواند کوچک‌تر باشد و منابع کمتری مصرف کند.

اما معماری سبک و کتابخانه‌های متفاوت ممکن است رفتار بعضی برنامه‌ها را در مقایسه با توزیع‌های متداول تغییر دهد.

در مورد SSHole، همین تفاوت در تعامل OpenSSH با musl اهمیت پیدا کرده است.

البته همه کانتینرهای Alpine سرویس SSH فعال ندارند. در بسیاری از معماری‌های مدرن، اصلاً نیازی نیست سرور SSH داخل هر کانتینر اجرا شود.

بنابراین تعداد زیاد دانلودهای Alpine را نمی‌توان معادل تعداد سامانه‌های آسیب‌پذیر دانست.

همچنین وجود یک کتابخانه آسیب‌پذیر در یک بسته نرم‌افزاری به معنی قابل سوءاستفاده بودن آن از طریق اینترنت نیست؛ شرایط اجرای نرم‌افزار و دسترسی شبکه نیز اهمیت دارند.

مدیران سرورها چه اقداماتی باید انجام دهند؟

مهم‌ترین توصیه شرکت‌های امنیت سایبری، بررسی نسخه OpenSSH و نصب اصلاحیه‌های ارائه‌شده از سوی سازنده سیستم‌عامل است.

پروژه OpenSSH نسخه 10.6p2 را برای رفع مسیر سوءاستفاده منتشر کرده و Alpine Linux نیز بسته‌های اصلاح‌شده را برای شاخه‌های مختلف خود ارائه داده است.

نکته مهم آن است که مدیر سیستم نباید فقط شماره نسخه اصلی OpenSSH را ملاک قرار دهد.

بعضی توزیع‌های لینوکس اصلاحیه‌های امنیتی را به نسخه‌های قدیمی‌تر منتقل می‌کنند؛ روشی که با عنوان Backport شناخته می‌شود.

در چنین شرایطی، ممکن است یک نسخه از نظر شماره قدیمی به نظر برسد، اما اصلاح امنیتی لازم را دریافت کرده باشد.

به همین دلیل بهتر است وضعیت آسیب‌پذیری از طریق اطلاعیه رسمی توزیع مورد استفاده بررسی شود.

پس از نصب اصلاحیه نیز لازم است سرویس آسیب‌پذیر با روش مناسب دوباره راه‌اندازی شود تا نسخه اصلاح‌شده واقعاً جایگزین فرایند در حال اجرا شده باشد.

در مواردی که امکان به‌روزرسانی فوری وجود ندارد، غیرفعال کردن ورود با رمز عبور می‌تواند یکی از راهکارهای موقت کاهش خطر باشد.

اما این تغییر باید با دقت انجام شود؛ زیرا تنظیم نادرست احراز هویت ممکن است دسترسی قانونی مدیران به سرور را مختل کند.

همچنین محدود کردن دسترسی شبکه به سرویس SSH و استفاده از روش‌های مدیریتی امن می‌تواند سطح مواجهه با حملات اینترنتی را کاهش دهد.

بررسی نشانه‌های نفوذ پس از نصب اصلاحیه

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

به همین دلیل شرکت‌های امنیتی توصیه کرده‌اند مدیران سامانه‌های احتمالاً آسیب‌پذیر، سوابق ورود و تغییرات غیرمنتظره را نیز بررسی کنند.

برای مثال، ورود موفق غیرمنتظره به حساب‌هایی که نباید با رمز عبور قابل دسترسی باشند می‌تواند نشانه‌ای برای بررسی بیشتر باشد.

اضافه شدن کلیدهای دسترسی ناشناس، تغییر سرویس‌های هنگام راه‌اندازی یا نصب نرم‌افزارهایی که مدیر سیستم آن‌ها را نمی‌شناسد نیز نیازمند بررسی است.

البته وجود یک فایل یا فرایند غیرمعمول به‌تنهایی اثبات نمی‌کند سیستم از طریق SSHole آلوده شده است.

ارزیابی باید با توجه به سابقه فعالیت، تنظیمات و اطلاعات ثبت‌شده در سامانه انجام شود.

در صورت مشاهده شواهد معتبر نفوذ، صرف تغییر رمز عبور ممکن است کافی نباشد. ممکن است لازم باشد کلیدهای دسترسی بازبینی شوند، اطلاعات حساس محافظت شوند و سلامت سیستم از طریق فرایند پاسخ به حادثه ارزیابی شود.

برای سازمان‌هایی که زیرساخت مهم دارند، ثبت دقیق زمان نصب اصلاحیه و نتیجه بررسی‌های امنیتی نیز اهمیت دارد.

اهمیت این حمله برای آینده امنیت سرورها

ماجرای SSHole نشان می‌دهد یک نقص امنیتی مهم الزاماً از اشتباه پیچیده در الگوریتم‌های رمزنگاری ناشی نمی‌شود.

گاهی مشکل در نحوه ارتباط دو جزء نرم‌افزاری ایجاد می‌شود که هرکدام به‌تنهایی وظیفه مشخصی دارند.

OpenSSH برای مدیریت ارتباط امن طراحی شده و musl توابع پایه موردنیاز برنامه‌ها را ارائه می‌کند. اما تفاوت در تفسیر نتیجه یک تابع می‌تواند پیامد امنیتی جدی ایجاد کند.

این موضوع اهمیت آزمایش نرم‌افزارها در ترکیب‌های مختلف را نشان می‌دهد.

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

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

در این پرونده، اصلاحیه از ۵ نوامبر در دسترس بود، اما تا ۹ نوامبر شواهد متعددی از تلاش برای حمله منتشر شد و CISA نیز سوءاستفاده فعال را تأیید کرد.

هنوز اطلاعات معتبری درباره تعداد کل سازمان‌های قربانی، میزان خسارت اقتصادی یا هویت قطعی عاملان اصلی منتشر نشده است.

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

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

منبع: CISA، Ars Technica، BleepingComputer، SecurityWeek، Red Hat، GreyNoise