حفرهٔ SharePoint فعالانه سوءاستفاده می‌شود؛ نصب وصله پایان بررسی نیست

در ۲۵ سپتامبر ۲۰۲۶، CISA آسیب‌پذیری CVE-2026-65660 در Microsoft SharePoint Server را به فهرست نقص‌های مورد سوءاستفادهٔ شناخته‌شده افزود و مهلت اقدام نهادهای فدرال آمریکا را ۲۸ سپتامبر تعیین کرد؛ گزارش The Hacker News امتیاز CVSS برابر با ۸٫۸ و عبارت مایکروسافت، «reliable evidence of observed attacks»، را نیز نقل می‌کند. این نقص تزریق کد می‌تواند به مهاجمی که دسترسی معتبر دارد امکان اجرای کد از راه شبکه بدهد.

یک روز پیش از ثبت آن در فهرست CISA، تحلیل Previdian از ۱۲ درخواست بهره‌برداری علیه یک سرور تلهٔ SharePoint در ۲۴ سپتامبر خبر داد: درخواست‌ها در دو مرحله فرستاده شدند و صفحه‌های AddGallery.aspx و designgallery.aspx را هدف گرفتند. این عدد به همان ترافیک ثبت‌شده مربوط است، نه شمار سرورهای سازمانی نفوذشده. برای مدیر سروری که پیش از نصب وصله در معرض دسترسی بوده، کار با تأیید بیلد تازه تمام نمی‌شود؛ فعالیت حساب‌ها و آثار اجرای کد در دورهٔ پیش از اصلاح نیز باید بررسی شود.

مسیر حمله به دسترسی سرور چگونه وابسته است؟

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

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

کدام نسخه‌های SharePoint باید بررسی شوند؟

هشدار مرکز امنیت سایبری کانادا نسخه‌های پیش از 16.0.5565.1001 را در SharePoint Enterprise Server 2016، پیش از 16.0.10417.20198 را در SharePoint Server 2019 و پیش از 16.0.19725.20522 را در SharePoint Server Subscription Edition آسیب‌پذیر می‌داند. این آستانه‌ها برای شناسایی سرورهای درگیر به کار می‌آیند؛ مدیر باید بستهٔ مناسب هر شاخه را نصب کند و کامل‌شدن مراحل نصب و پیکربندی را در تمام سرورهای استقرار تأیید کند. ثبت موفقیت یک تغییر در سامانهٔ مدیریت وصله، به‌تنهایی بیلد واقعی هر سرور را نشان نمی‌دهد.

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

محدودسازی دسترسی مستقیم از اینترنت و دسترسی به SharePoint Central Administration می‌تواند سطح مواجهه را کاهش دهد. بازبینی حساب‌های غیرضروری و استفاده از احراز هویت چندعاملی برای مدیران نیز به کنترل مسیرهای دسترسی کمک می‌کند. این اقدامات باید همراه با اصلاح نرم‌افزار انجام شوند، چون مشکل تزریق کد در بیلد آسیب‌پذیر همچنان باقی می‌ماند.

در ترافیک ثبت‌شده چه نشانه‌هایی دیده شد؟

درخواست‌های مشکوک به AddGallery.aspx و designgallery.aspx با پارامتر DisplayMode=Edit فرستاده شدند؛ برخی مسیرها بخش تکراری /_layouts/ داشتند و درخواست‌ها در فاصلهٔ کوتاه از یک مبدأ می‌رسیدند. کنار هم قرار گرفتن مسیر، پارامتر، زمان و وضعیت احراز هویت سرنخ دقیق‌تری از نام صفحه به‌تنهایی می‌دهد. وجود یک درخواست به یکی از این صفحه‌ها، بدون بررسی زمینهٔ آن، به معنای موفقیت حمله نیست.

در به‌روزرسانی تحلیل این فعالیت، مسیر /_layouts/15/sphealth.aspx به‌عنوان نام یک وب‌شل مرتبط مطرح شد. جست‌وجوی این مسیر در کنار تغییرات فایل‌ها، فعالیت فرایندها و رویدادهای ابزار امنیتی میزبان مفید است؛ نبودن همین نام مشخص برای کنار گذاشتن احتمال نفوذ کافی نیست. نام wt3k3sij.dll نیز در بارِ مرحلهٔ دوم دیده شد، اما در آن بررسی نوشته‌شدن فایلی با این نام روی سرور مشاهده نشد؛ بنابراین جست‌وجوی صرفِ فایل با این نام دامنهٔ بررسی را بیش از حد تنگ می‌کند.

نمونهٔ ثبت‌شده یک تلاش علیه سرور تله بود و موفقیت همان زنجیره در یک نصب عملیاتی را ثابت نمی‌کند. در عین حال، جزئیات درخواست‌ها به مدیران امکان می‌دهد لاگ‌های IIS و SharePoint را برای فعالیت مشابه در بازهٔ پیش از وصله مرور کنند. لاگ‌های احراز هویت و امنیت میزبان نیز برای تشخیص این‌که درخواست مشکوک به اجرای فرایند یا تغییر دسترسی رسیده است، باید با همان خط زمانی سنجیده شوند.

پس از وصله چه چیزی هنوز باید روشن شود؟

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

1. بیلدها را تأیید کنید. نسخهٔ هر سرور را با آستانهٔ مربوط به همان شاخه بسنجید و کامل‌شدن نصب و پیکربندی به‌روزرسانی را ثبت کنید. سرورهای بیرون از موجودی معمول یا قابل دسترسی از اینترنت را نیز وارد بررسی کنید.
2. مسیرهای دسترسی را بازبینی کنید. دسترسی مستقیم به سرور و رابط‌های مدیریتی را به مسیرهای لازم محدود کنید. حساب‌های بلااستفاده، دسترسی‌های تازه و تنظیم مشاهدهٔ ناشناس را با نیاز واقعی استقرار تطبیق دهید.
3. لاگ‌های پیش از وصله را مرور کنید. درخواست‌های غیرمعمول در IIS و SharePoint را با ورود حساب‌ها، فعالیت مدیریتی و هشدارهای امنیت میزبان در یک خط زمانی قرار دهید. بررسی محدود به رویدادهای پس از به‌روزرسانی ممکن است آغاز رخداد را از دید پنهان کند.
4. آثار ماندگاری را دنبال کنید. تغییرات بی‌مجوز در وب‌پارت‌ها و پیکربندی، افزایش امتیاز حساب‌ها، دسترسی مشکوک به کلیدهای IIS، اجرای فرایندهای غیرمعمول و نشانه‌های وب‌شل را بررسی کنید. هر یافته باید به حساب و زمان مرتبط شود تا دامنهٔ دسترسی ایجادشده معلوم شود.

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

بیشتر بخوانید:

• ChatGPT یا Perplexity برای تحقیق؛ تعداد منبع بیشتر مساوی دقت بیشتر نیست