BLACK HAT USA – لاس وگاس – پیگیری وصله‌های آسیب‌پذیری امنیتی در بهترین حالت چالش برانگیز است، اما اولویت‌بندی باگ‌هایی که باید روی آنها تمرکز کرد دشوارتر از همیشه شده است، به لطف نمرات CVSS فاقد زمینه، توصیه‌های مبهم فروشنده، و رفع‌های ناقص. ادمین ها را با احساس امنیت کاذب رها کنید.
این استدلالی است که برایان گورنک و داستین چایلدز، هر دو با طرح Trend Micro's Zero Day Initiative (ZDI)، از صحنه Black Hat USA در طول جلسه خود بیان کردند.محاسبه ریسک در عصر ابهام: خواندن بین خطوط مشاوره امنیتی"
ZDI از سال 10,000 بیش از 2005 آسیب‌پذیری را برای فروشندگان در سراسر صنعت فاش کرده است. در طول آن زمان، مدیر ارتباطات ZDI Childs گفت که او متوجه روند نگران‌کننده‌ای شده است که کاهش کیفیت وصله و کاهش ارتباطات پیرامون به‌روزرسانی‌های امنیتی است.
وی خاطرنشان کرد: «مشکل واقعی زمانی ایجاد می‌شود که فروشندگان وصله‌های معیوب، یا اطلاعات نادرست و ناقص در مورد آن وصله‌ها را منتشر می‌کنند که می‌تواند باعث شود شرکت‌ها ریسک خود را اشتباه محاسبه کنند.» وصله‌های معیوب نیز می‌توانند برای نویسندگان مفید باشند، زیرا استفاده از «n-days» بسیار آسان‌تر از روز صفر است.»
مشکل با امتیازات CVSS و اولویت وصله
اکثر تیم‌های امنیت سایبری کمبود کارکنان و تحت فشار هستند، و شعار «همیشه تمام نسخه‌های نرم‌افزار را به‌روز نگه دارید» برای بخش‌هایی که به سادگی منابع لازم برای پوشش آب‌نما را ندارند، همیشه منطقی نیست. به همین دلیل است که اولویت‌بندی وصله‌هایی که باید با توجه به رتبه‌بندی شدت آنها در مقیاس شدت آسیب‌پذیری رایج (CVSS) اعمال شوند، برای بسیاری از مدیران تبدیل به یک جایگزین شده است.
با این حال، چایلدز خاطرنشان کرد که این رویکرد عمیقاً ناقص است و می‌تواند منجر به صرف منابع برای باگ‌هایی شود که بعید است هرگز مورد سوء استفاده قرار گیرند. این به این دلیل است که اطلاعات مهمی وجود دارد که امتیاز CVSS ارائه نمی کند.
او گفت: «در اغلب موارد، شرکت‌ها برای تعیین اولویت وصله‌سازی به هسته اصلی CVSS نگاه نمی‌کنند. اما CVSS واقعاً به قابلیت بهره برداری یا اینکه آیا یک آسیب پذیری احتمالاً در طبیعت مورد استفاده قرار می گیرد یا خیر. CVSS به شما نمی گوید که آیا این اشکال در 15 سیستم وجود دارد یا در 15 میلیون سیستم. و نمی گوید که آیا در سرورهای قابل دسترسی عمومی است یا خیر.
او افزود: «و مهمتر از همه، نمی گوید که آیا این اشکال در سیستمی که برای شرکت خاص شما حیاتی است وجود دارد یا خیر.»
بنابراین، حتی اگر یک اشکال ممکن است دارای رتبه‌بندی بحرانی 10 از 10 در مقیاس CVSS باشد، تأثیر واقعی آن ممکن است بسیار کمتر از آن چیزی باشد که برچسب مهم نشان می‌دهد.
او گفت: «اشکال اجرای کد از راه دور تأیید نشده (RCE) در سرور ایمیل مانند Microsoft Exchange، علاقه زیادی را از سوی نویسندگان اکسپلویت ایجاد خواهد کرد. "یک اشکال RCE احراز هویت نشده در سرور ایمیل مانند Squirrel Mail احتمالاً توجه زیادی را به خود جلب نخواهد کرد."
برای پر کردن شکاف‌های زمینه‌ای، تیم‌های امنیتی اغلب به توصیه‌های فروشنده روی می‌آورند – که به گفته چایلدز، مشکل آشکار خود را دارد: آنها اغلب امنیت را از طریق ابهام انجام می‌دهند.
مایکروسافت پچ سه‌شنبه مشاوره‌ها فاقد جزئیات هستند
در سال 2021، مایکروسافت این تصمیم را گرفت برای حذف خلاصه های اجرایی
از راهنماهای به‌روزرسانی امنیتی، به جای آن به کاربران اطلاع می‌دهد که امتیازات CVSS برای اولویت‌بندی کافی است - تغییری که Childs آن را محکوم کرد.
او گفت: «تغییر زمینه ای را که برای تعیین ریسک لازم است حذف می کند. برای مثال، آیا یک اشکال افشای اطلاعات، حافظه تصادفی یا PII را تخلیه می‌کند؟ یا برای دور زدن ویژگی امنیتی، چه چیزی در حال دور زدن است؟ اطلاعات موجود در این نوشته‌ها با وجود انتقادات تقریباً جهانی از این تغییر، متناقض و با کیفیت متفاوت است.
علاوه بر این که مایکروسافت «اطلاعات را در به‌روزرسانی‌هایی که قبلاً راهنمایی‌های واضحی را تولید می‌کردند حذف می‌کرد یا پنهان می‌کرد»، اکنون تعیین اطلاعات اولیه Patch Tuesday، مانند تعداد باگ‌هایی که هر ماه وصله می‌شوند، دشوارتر است.
چایلدز خاطرنشان کرد: "اکنون باید خودت را بشماری، و این در واقع یکی از سخت ترین کارهایی است که انجام می دهم."
همچنین، اطلاعات مربوط به تعداد آسیب‌پذیری‌هایی که تحت حمله فعال هستند یا به طور عمومی شناخته شده‌اند، هنوز در دسترس است، اما اکنون در بولتن‌ها مدفون شده است.
«به عنوان مثال، با 121 CVE در این ماه وصله شده استچایلدز گفت، به نوعی سخت است که همه آنها را جستجو کنیم تا ببینیم کدام یک مورد حمله فعال هستند. در عوض، مردم در حال حاضر به منابع دیگر اطلاعات مانند وبلاگ ها و مقالات مطبوعاتی، به جای اطلاعات معتبر از فروشنده برای کمک به تعیین ریسک، تکیه می کنند.
لازم به ذکر است که مایکروسافت تغییر را دو برابر کرده است. در گفتگو با Dark Reading در Black Hat USA، معاون شرکتی مرکز پاسخگویی امنیتی مایکروسافت، Aanchal Gupta، گفت که این شرکت آگاهانه تصمیم گرفته است اطلاعاتی را که در ابتدا با CVE های خود ارائه می دهد محدود کند تا از کاربران محافظت کند. او گفت در حالی که مایکروسافت CVE اطلاعاتی را در مورد شدت باگ و احتمال سوء استفاده از آن (و اینکه آیا به طور فعال مورد بهره برداری قرار می گیرد) ارائه می دهد، این شرکت در مورد نحوه انتشار اطلاعات سوء استفاده از آسیب پذیری عاقلانه عمل خواهد کرد.
گوپتا گفت، هدف این است که به مقامات امنیتی زمان کافی برای اعمال وصله بدون به خطر انداختن آنها داده شود. او می‌گوید: «اگر در CVE خود، تمام جزئیات مربوط به نحوه استفاده از آسیب‌پذیری‌ها را ارائه دهیم، مشتریان خود را روز صفر خواهیم کرد.
فروشندگان دیگر ابهام را تمرین می کنند
مایکروسافت در ارائه جزئیات ناچیز در افشای باگ ها به سختی تنها نیست. Childs گفت که بسیاری از فروشندگان وقتی یک به‌روزرسانی را منتشر می‌کنند، اصلاً CVE ارائه نمی‌کنند.
او توضیح داد: "آنها فقط می گویند که به روز رسانی چندین مشکل امنیتی را برطرف می کند." "چند تا؟ شدتش چیه؟ قابلیت بهره برداری چیست؟ ما حتی اخیراً یک فروشنده داشتیم که به طور خاص به ما گفت، ما توصیه های عمومی در مورد مسائل امنیتی منتشر نمی کنیم. این یک حرکت جسورانه است.»
علاوه بر این، برخی از فروشندگان توصیه هایی را پشت دیوارهای پرداخت یا قراردادهای پشتیبانی قرار می دهند و ریسک آنها را بیشتر پنهان می کنند. یا، با وجود این تصور رایج که یک CVE نشان دهنده یک آسیب پذیری منحصر به فرد است، چندین گزارش باگ را در یک CVE واحد ترکیب می کنند.
او گفت: «این ممکن است منجر به انحراف در محاسبه ریسک شما شود. به عنوان مثال، اگر به خرید یک محصول نگاه کنید و 10 CVE را ببینید که در مدت زمان معینی وصله شده اند، ممکن است به یک نتیجه از خطر این محصول جدید برسید. با این حال، اگر می دانستید که آن 10 CVE بر اساس بیش از 100 گزارش اشکال هستند، ممکن است به نتیجه متفاوتی برسید.
دارونما وصله های اولویت بندی طاعون
فراتر از مشکل افشا، تیم های امنیتی نیز با مشکلاتی در مورد خود وصله ها مواجه هستند. به گفته چایلدز، «وصله‌های پلاسبو»، که «اصلاحاتی» هستند که در واقع هیچ تغییر مؤثری در کد ایجاد نمی‌کنند، غیرمعمول نیستند.
او گفت: "بنابراین این اشکال هنوز وجود دارد و برای عوامل تهدید قابل استفاده است، با این تفاوت که اکنون آنها از آن مطلع شده اند." دلایل زیادی وجود دارد که چرا ممکن است این اتفاق بیفتد، اما این اتفاق می افتد - اشکالات بسیار خوبی هستند که ما آنها را دو بار وصله می کنیم.
همچنین اغلب وصله هایی وجود دارد که ناقص هستند. در واقع، در برنامه ZDI، 10٪ تا 20٪ کامل از اشکالاتی که محققان تجزیه و تحلیل می کنند، نتیجه مستقیم یک پچ معیوب یا ناقص است.
Childs از مثال مشکل سرریز اعداد صحیح در Adobe Reader استفاده کردند که منجر به تخصیص پشته کمتر می‌شود، که وقتی داده‌های زیادی روی آن نوشته می‌شود، منجر به سرریز بافر می‌شود.
چایلدز گفت: «ما انتظار داشتیم که Adobe با قرار دادن هر مقداری روی یک نقطه خاص، مشکل را برطرف کند. اما این چیزی نیست که ما دیدیم، و در عرض 60 دقیقه پس از عرضه، یک بای پس وصله وجود داشت و آنها مجبور شدند دوباره وصله کنند. تکرارها فقط برای برنامه های تلویزیونی نیستند.»
نحوه مبارزه با مشکلات اولویت بندی پچ
در نهایت وقتی نوبت به اولویت‌بندی وصله‌ها می‌رسد، مدیریت مؤثر وصله‌ها و محاسبه ریسک به شناسایی اهداف نرم‌افزاری با ارزش بالا در سازمان و همچنین استفاده از منابع شخص ثالث برای محدود کردن این که کدام وصله‌ها برای هر محیطی مهمتر هستند، خلاصه می‌شود. محققان خاطرنشان کردند.
با این حال، موضوع چابکی پس از افشای اطلاعات یکی دیگر از حوزه‌های کلیدی است که سازمان‌ها باید روی آن تمرکز کنند.
به گفته گورنک، مدیر ارشد ZDI، مجرمان سایبری وقت خود را برای ادغام بدافزارها با سطوح حمله بزرگ در مجموعه ابزارهای باج‌افزار یا کیت‌های بهره‌برداری خود تلف نمی‌کنند و قبل از اینکه شرکت‌ها زمان لازم را برای اصلاح آن داشته باشند، به دنبال سلاح‌هایی هستند که به تازگی فاش شده‌اند. این باگ‌های به‌اصطلاح n-day برای مهاجمانی که به طور متوسط می‌توانند یک باگ را در کمتر از 48 ساعت مهندسی معکوس کنند، بسیار مفید هستند.
گورنک گفت: «در بیشتر موارد، جامعه تهاجمی از آسیب‌پذیری‌های روز n استفاده می‌کند که دارای وصله‌های عمومی در دسترس هستند. "برای ما مهم است که در هنگام افشا متوجه شویم که آیا یک باگ واقعاً به سلاح تبدیل می شود یا خیر، اما اکثر فروشندگان اطلاعاتی در مورد قابلیت بهره برداری ارائه نمی دهند."
بنابراین، ارزیابی ریسک سازمانی باید به اندازه کافی پویا باشد تا بتواند پس از افشای اطلاعات را تغییر دهد، و تیم‌های امنیتی باید منابع اطلاعاتی تهدید را زیر نظر بگیرند تا بفهمند چه زمانی یک باگ در یک کیت بهره‌برداری یا باج‌افزار ادغام می‌شود یا زمانی که یک سوءاستفاده آنلاین منتشر می‌شود.
علاوه بر آن، یک جدول زمانی مهم برای شرکت‌ها این است که چقدر طول می‌کشد تا یک پچ در سراسر سازمان منتشر شود و آیا منابع اضطراری وجود دارد که می‌توان در صورت لزوم از آنها استفاده کرد.
گورنک توضیح می‌دهد: «زمانی که تغییراتی در چشم‌انداز تهدید رخ می‌دهد (بازبینی اصلاحیه‌ها، اثبات مفاهیم عمومی و انتشار اکسپلویت)، شرکت‌ها باید منابع خود را برای رفع نیاز و مبارزه با آخرین خطرات تغییر دهند. «نه فقط آخرین آسیب‌پذیری منتشر شده و نام‌گذاری شده. به آنچه در چشم انداز تهدید می گذرد توجه کنید، منابع خود را جهت دهی کنید و تصمیم بگیرید که چه زمانی اقدام کنید.
