BLACK HAT USA – Лас-Вегас – Виправляти вразливості безпеки в кращому випадку складно, але визначити пріоритетність помилок стало важче, ніж будь-коли раніше, завдяки оцінкам CVSS без контексту, брудним порадам постачальників і неповним виправленням, які залишати в адмінів помилкове відчуття безпеки.
Це аргумент, який Браян Горенц і Дастін Чайлдс, обидва з Zero Day Initiative (ZDI) компанії Trend Micro, висунули зі сцени Black Hat USA під час своєї сесії, "Розрахунок ризику в епоху невідомості: читання поміж рядків порад щодо безпеки».
З 10,000 року ZDI розкрила постачальникам понад 2005 XNUMX уразливостей у всій галузі. За цей час менеджер із комунікацій ZDI Чайлдс сказав, що він помітив тривожну тенденцію, якою є зниження якості виправлення та зменшення зв’язку навколо оновлень безпеки.
«Справжня проблема виникає, коли постачальники випускають несправні виправлення або неточну та неповну інформацію про ці виправлення, що може змусити підприємства неправильно розрахувати свій ризик», — зазначив він. «Несправні патчі також можуть бути благом для авторів, оскільки «n-days» набагато легше використовувати, ніж zero-days».
Проблема з оцінками CVSS і пріоритетом виправлення
Більшість команд з кібербезпеки не укомплектовані та перебувають під тиском, і мантра «завжди підтримувати всі версії програмного забезпечення актуальними» не завжди має сенс для відділів, які просто не мають ресурсів, щоб охопити водний рівень. Ось чому для багатьох адміністраторів визначення пріоритетності виправлень відповідно до їх рейтингу серйозності за загальною шкалою серйозності вразливості (CVSS) стало запасним варіантом.
Чайлдс зазначив, однак, що цей підхід є глибоко помилковим і може призвести до того, що ресурси витрачатимуться на помилки, які навряд чи коли-небудь будуть використані. Це тому, що існує безліч критичної інформації, яку не надає оцінка CVSS.
«Занадто часто підприємства дивляться не далі, ніж на базове ядро CVSS, щоб визначити пріоритет виправлення», — сказав він. «Але CVSS насправді не дивиться на можливість використання чи ймовірність використання вразливості в дикій природі. CVSS не повідомляє вам, чи існує помилка в 15 системах чи в 15 мільйонах систем. І не вказано, чи є він на загальнодоступних серверах».
Він додав: «І найголовніше, це не говорить про наявність помилки в системі, яка є критичною для вашого підприємства».
Таким чином, навіть незважаючи на те, що помилка може мати критичний рейтинг 10 із 10 за шкалою CVSS, її справжній вплив може бути набагато менш занепокоєним, ніж вказує ця критична позначка.
«Помилка неавтентифікованого віддаленого виконання коду (RCE) на сервері електронної пошти, як-от Microsoft Exchange, викличе великий інтерес у розробників експлойтів», — сказав він. «Неавтентифікована помилка RCE на сервері електронної пошти, як-от Squirrel Mail, ймовірно, не приверне стільки уваги».
Щоб заповнити контекстуальні прогалини, служби безпеки часто звертаються до консультацій постачальників, які, як зазначив Чайлдс, мають власну кричущу проблему: вони часто практикують безпеку через невідомість.
У повідомленні про виправлення Microsoft у вівторок бракує деталей
У 2021 році Microsoft прийняла таке рішення щоб видалити виконавчі резюме
з посібників з оновлень системи безпеки, натомість інформуючи користувачів, що оцінки CVSS будуть достатніми для встановлення пріоритетів – зміна, яку Чайлдс розкритикував.
«Ця зміна усуває контекст, необхідний для визначення ризику», — сказав він. «Наприклад, помилка розкриття інформації скидає довільну пам’ять або ідентифікаційну інформацію? Або для обходу функції безпеки, що обходиться? Інформація в цих публікаціях є суперечливою та різної якості, незважаючи на майже загальну критику змін».
Крім того, що Microsoft «видаляла або приховувала інформацію в оновленнях, які раніше створювали чіткі вказівки», тепер також складніше визначити основну інформацію про виправлення, наприклад, скільки помилок виправляється щомісяця.
«Тепер ви повинні порахувати себе, і це насправді одна з найважчих речей, які я роблю», - зазначив Чайлдс.
Крім того, інформація про те, скільки вразливостей піддається активній атаці або є загальновідомою, все ще доступна, але зараз прихована в бюлетенях.
«Як приклад, с Цього місяця виправлено 121 CVE, важко прокопатися в усіх, щоб знайти, які піддаються активній атаці», — сказав Чайлдс. «Замість цього люди тепер покладаються на інші джерела інформації, такі як блоги та статті в пресі, а не на те, що має бути достовірною інформацією від постачальника, щоб допомогти визначити ризик».
Слід зазначити, що Microsoft подвоївся на зміну. У розмові з Dark Reading із Black Hat USA корпоративний віце-президент Microsoft Security Response Center Аанчал Гупта сказав, що компанія свідомо вирішила обмежити інформацію, яку вона спочатку надає за допомогою своїх CVE, щоб захистити користувачів. Незважаючи на те, що Microsoft CVE надає інформацію про серйозність помилки та ймовірність її використання (а також про те, чи активно вона використовується), компанія розсудливо підійде до того, як вона опублікує інформацію про використання вразливостей, сказала вона.
Мета полягає в тому, щоб дати адміністраторам безпеки достатньо часу, щоб застосувати виправлення, не загрожуючи їм, сказав Гупта. «Якщо в нашому CVE ми надамо всі деталі того, як можна використовувати вразливості, ми будемо нульовими клієнтами», — сказала вона.
Інші постачальники практикують невідомість
Майкрософт навряд чи єдина, хто надає мізерні деталі в повідомленнях про помилки. Чайлдс сказав, що багато постачальників взагалі не надають CVE, коли випускають оновлення.
«Вони просто кажуть, що оновлення вирішує кілька проблем безпеки», — пояснив він. "Скільки? Яка суворість? Що таке експлуатація? Нещодавно один постачальник навіть сказав нам, що ми не публікуємо публічні поради з питань безпеки. Це сміливий крок».
Крім того, деякі постачальники розміщують консультації за системами оплати або контрактами на підтримку, ще більше приховуючи свій ризик. Або вони об’єднують кілька звітів про помилки в один CVE, незважаючи на загальну думку, що CVE представляє одну унікальну вразливість.
«Це може призвести до викривлення вашого розрахунку ризику», — сказав він. «Наприклад, якщо ви купуєте продукт і бачите 10 CVE, які були виправлені за певний проміжок часу, ви можете зробити один висновок щодо ризику від цього нового продукту. Однак, якби ви знали, що ці 10 CVE базувалися на понад 100 звітах про помилки, ви могли б дійти іншого висновку».
Плацебо Пластири Пріоритезація чуми
Окрім проблеми з розголошенням, служби безпеки також стикаються з проблемами самих виправлень. За словами Чайлдса, «плацебо-патчі», які є «виправленнями», які фактично не вносять ефективних змін у код, не є рідкістю.
«Тож ця помилка все ще існує, і її можна використовувати для загроз, за винятком того, що тепер їх про це повідомили», — сказав він. «Є багато причин, чому це може статися, але це трапляється – такі гарні помилки, що ми виправляємо їх двічі».
Також часто є неповні патчі; фактично в програмі ZDI від 10% до 20% помилок, які аналізують дослідники, є прямим результатом несправного або неповного патча.
Чайлдс використав приклад проблеми з переповненням цілого числа в Adobe Reader, що призвело до розподілу купи заниженого розміру, що призводить до переповнення буфера, коли в нього записується забагато даних.
«Ми очікували, що Adobe зробить виправлення, встановивши будь-яке значення над певною точкою як погане», — сказав Чайлдс. «Але це не те, що ми бачили, і протягом 60 хвилин після розгортання був патч-обхід, і їм довелося робити латки знову. Повтори не тільки для телешоу».
Як боротися з проблемами пріоритетності виправлень
Зрештою, коли справа доходить до визначення пріоритетів виправлень, ефективне керування виправленнями та обчислення ризиків зводиться до визначення цінних цілей програмного забезпечення в організації, а також до використання джерел сторонніх розробників для звуження того, які виправлення будуть найважливішими для будь-якого середовища, відзначили дослідники.
Однак питання спритності після розголошення інформації є ще одним ключовим напрямком, на якому організації повинні зосередитися.
За словами Горенка, старшого директора ZDI, кіберзлочинці не витрачають час на інтеграцію вульнів із великими поверхнями для атаки у свої набори інструментів для програм-вимагачів або набори експлойтів, прагнучи використати нові виявлені недоліки як зброю до того, як компанії встигнуть їх виправити. Ці так звані n-денні помилки — це котяча м’ята для зловмисників, які в середньому можуть перепроектувати помилку всього за 48 годин.
«Здебільшого нападаюча спільнота використовує n-денні вразливості, для яких доступні загальнодоступні виправлення», — сказав Горенц. «Для нас важливо зрозуміти під час розголошення, чи справді помилка буде використана як зброя, але більшість постачальників не надають інформації щодо можливості використання».
Таким чином, оцінки корпоративних ризиків мають бути достатньо динамічними, щоб змінюватися після розголошення, а групи безпеки повинні відстежувати джерела аналізу загроз, щоб зрозуміти, коли помилка інтегрована в набір експлойтів чи програм-вимагачів, або коли експлойт випущено в Інтернеті.
Додатково до цього важливий часовий графік для підприємств — це те, скільки часу потрібно для фактичного розгортання виправлення в усій організації та чи є ресурси для надзвичайних ситуацій, які можна задіяти в разі потреби.
«Коли відбуваються зміни в ландшафті загроз (ревізії патчів, публічні перевірки концепцій і випуски експлойтів), підприємствам слід перенаправляти свої ресурси на задоволення потреб і на боротьбу з останніми ризиками», — пояснив Горенц. «Не лише остання оприлюднена та названа вразливість. Спостерігайте за тим, що відбувається в ландшафті загроз, орієнтуйте свої ресурси та вирішуйте, коли діяти».
