Експерти з ІТ-безпеки коментують прогалину безпеки log4j, для якої BSI оголосив червоний рівень попередження. Оцінку ситуації дають експерти Barracuda Networks, Radar Cyber Security і ForeNova.
Джонатан Таннер, старший дослідник безпеки в Barracuda Networks
Джонатан Таннер, старший дослідник безпеки Barracuda Networks: «Оскільки ця вразливість дозволяє віддалено виконувати код, ризики досить високі» (Зображення: Barracuda Networks).
Як компанії можуть визначити цю вразливість у своїй технології та які ризики можуть виникнути, якщо її не усунути?
«Спочатку ви повинні перевірити, чи використовується версія log4j до 2.15.0, також у залежностях. І Maven, і Gradle — обидва інструменти керування збірками на основі Java — надають можливість роздрукувати все дерево залежностей для проекту. Таким чином можна визначити, чи використовується вразлива версія log4j чи ні. Навіть з версією 2.15.0 або новішою переконайтеся, що для системної властивості formatMsgNoLookups не встановлено значення «true».
Єдина причина, чому ця версія не є вразливою, полягає в тому, що вона встановила значення за замовчуванням із true на false. У деяких версіях log4j цю властивість можна легко встановити на false вручну, щоб зменшити вразливість. Якщо програмі не потрібен LDAP як частина її законного використання, можна також заблокувати весь трафік LDAP за допомогою брандмауера або фільтра веб-програми, щоб запобігти доступу до віддаленого коду в разі використання вразливості.
Однак вони лише перевіряють, чи може log4j використовувати цю вразливість RCE чи ні. Набагато складніше питання про те, чи справді система вразлива до атаки, без жодного тесту на вразливості, як у HeartBleed. Щоб скористатися цією вразливістю, зловмиснику потрібно буде виконати атаку з ін’єкцією журналу. Пошук таких є набагато складнішим процесом, але в основному будь-яке місце, де реєструються дані користувача (або потенційного зловмисника), може бути вразливим до цієї атаки.
Отже, щоб перевірити фактичний RCE, потрібно спробувати знайти спосіб зробити запит JNDI LDAP у журналах із самого контексту користувача (наприклад, через веб-сайт або API, якщо потенційно постраждала програма є веб-програмою). Оскільки ця вразливість дозволяє віддалено виконувати код, ризики досить високі. Зловмисник потенційно може проникнути в мережу та спробувати отримати звідти доступ до важливих ресурсів і даних».
Яку роль у цій вразливості відіграв відкритий вихідний код і які головні міркування безпеки для організацій, які використовують такі інструменти, як log4j?
«Оскільки log4j є дуже популярною бібліотекою з відкритим вихідним кодом, кількість уразливих додатків, безумовно, була більшою. Загалом будь-яке програмне забезпечення може бути вразливим до атак, і популярне програмне забезпечення з відкритим кодом часто має велику екосистему, яка шукає та усуває загрози безпеці. Незважаючи на те, що програмне забезпечення з відкритим кодом займає більшість заголовків, коли виявляються серйозні вразливості, це не означає, що воно пропорційно менш безпечне (насправді, воно, мабуть, набагато безпечніше, ніж власний код або менш популярні бібліотеки). Широке розповсюдження лише збільшує ймовірність того, що вразливості будуть знайдені, а не обов’язково ймовірність їх існування.
Шукаючи бібліотеки з відкритим вихідним кодом, компаніям слід вибирати великі, авторитетні та добре підтримувані проекти, такі як log4j, з наведених вище причин. Звичайно, все ще можуть бути вразливості, але спільнота з більшою ймовірністю знайде та виправить ці вразливості, а також переконається, що код вільний від помилок, які можуть спричинити вразливості, ніж у менших проектах.
Навіть для тих, чиї програми не вразливі до CVE-2021-44228 або хто взагалі не використовує log4j для журналювання, ця вразливість, безперечно, є тривожним сигналом про те, що ін’єкція журналу є потенційним методом, який можуть використати зловмисники. Варто перевірити, чи всі дані користувача, які реєструються, належним чином очищаються в кожній програмі, незалежно від того, яка система реєстрації чи навіть мова програмування використовується. У той час як інші форми ін’єкцій є набагато більш поширеними та є центром інтересу, ін’єкції журналів все ще є формою ін’єкційних атак і, отже, підпадають під топ-10 уразливостей OWASP».
Як компанії можуть визначити цю вразливість у своїй технології та які ризики можуть виникнути, якщо її не усунути?
«Спочатку вам потрібно перевірити, чи використовується версія log4j до 2.15.0, також у залежностях. І Maven, і Gradle — обидва інструменти керування збірками на основі Java — надають можливість роздрукувати все дерево залежностей для проекту. Таким чином можна визначити, чи використовується вразлива версія log4j чи ні. Навіть з версією 2.15.0 або новішою переконайтеся, що для системної властивості formatMsgNoLookups не встановлено значення «true». Єдина причина, чому ця версія не є вразливою, полягає в тому, що вона встановила значення за замовчуванням із true на false.
У деяких версіях log4j цю властивість можна легко встановити на false вручну, щоб зменшити вразливість. Якщо програмі не потрібен LDAP як частина її законного використання, можна також заблокувати весь трафік LDAP за допомогою брандмауера або фільтра веб-програми, щоб запобігти доступу до віддаленого коду в разі використання вразливості. Однак вони лише перевіряють, чи може log4j використовувати цю вразливість RCE чи ні. Набагато складніше питання про те, чи справді система вразлива до атаки, без жодного тесту на вразливості, як у HeartBleed.
Щоб скористатися цією вразливістю, зловмиснику потрібно буде виконати атаку з ін’єкцією журналу. Пошук таких є набагато складнішим процесом, але в основному будь-яке місце, де реєструються дані користувача (або потенційного зловмисника), може бути вразливим до цієї атаки. Отже, щоб перевірити фактичний RCE, потрібно спробувати знайти спосіб зробити запит JNDI LDAP у журналах із самого контексту користувача (наприклад, через веб-сайт або API, якщо потенційно постраждала програма є веб-програмою).
Оскільки ця вразливість дозволяє дистанційно виконувати код, ризики у разі появи вразливості досить високі. Зловмисник потенційно може проникнути в мережу та спробувати отримати звідти доступ до важливих ресурсів і даних».
Більше на Barracuda.com
Лотар Хенслер, операційний директор Radar Cyber Security
Лотар Хенслер, головний операційний директор Radar Cyber Security: «Цю вразливість відносно легко використовувати, атаки можна легко приховати» (Зображення: Radar Cyber Security).
що все-таки сталося
«Минулими вихідними було виявлено вразливість у модулі log4j2 Apache.org, і їй швидко було присвоєно оцінку CVSS 10, найвищий рівень критичності. Такі органи влади, як Федеральне відомство з інформаційної безпеки (BSI), швидко підвищили свою оцінку ризику, яка спочатку була помаранчевою, до червоної».
Що робить цю вразливість такою особливою?
«Уразливості відносно легко використовувати, атаки можна легко приховати (обфускація). Крім того, оборонні заходи нелегко реалізувати. Однією з причин цього є те, що всі стратегії пом’якшення можуть мати ризики та побічні ефекти для програм, уражених уразливістю. Проте оцінки в експертних групах дуже динамічні, як наслідок, також існують різні погляди на стратегії пом’якшення».
Що саме зробив Radar Cyber Security?
«На вихідних ми спочатку проаналізували ситуацію з даними щодо реагування на інциденти, оцінили вплив, використали різні джерела інформації з міжнародних платформ, таких як Computer Emergency Response Teams (CERTs), і розробили стратегію боротьби з цією загрозою. Нарешті в понеділок вранці ми розіслали всім нашим клієнтам пораду щодо безпеки. Наш Центр кіберзахисту (CDC) переведено в режим підвищеної готовності.
Тепер він приділяє особливу увагу виникненню вразливості в модулі log4j2, не нехтуючи загальним станом безпеки. Ми оновили модулі виявлення, щоб перевірити використання цієї вразливості та повідомити наших клієнтів. Це варіюється від керування вразливістю до класичних служб SIEM та окремих інструментів аналізу мережі. Паралельно ми почали аналіз власних систем. Після першого сканування у першого клієнта протягом дуже короткого часу було виявлено два критичні інциденти. Інші спеціальні служби аналізують, чи конкретно клієнти постраждали від цієї вразливості. У крайніх випадках може знадобитися вимкнути системи».
Більше на RadarCS.com
Пол Сміт, директор професійних послуг ForeNova
Пол Сміт, директор із професійних послуг у ForeNova: «Уразливість нульового дня в log4j є надзвичайно небезпечною, оскільки її можна використати безпосередньо без явного перезавантаження шкідливого коду» (Зображення: ForeNova).
«Уразливість нульового дня в широко використовуваній бібліотеці Java log4j є надзвичайно небезпечною, оскільки вразливість може бути використана безпосередньо без явного перезавантаження шкідливого коду. Але станеться це негайно чи ні, можна буде побачити лише тоді, коли буде надто пізно. Кінцева точка може бути скомпрометована, але ще не в полі зору хакерів. Саме зараз стає очевидною необхідність для малих і середніх компаній думати про виявлення та реагування мережі та виявлення та реагування кінцевих точок разом як комплексну стратегію захисту. EDR перевіряє, чи встановлено зловмисне програмне забезпечення, і організовує захист на кінцевій точці.
Побачте минуле з NDR
За допомогою NDR ви також можете побачити в журнальних даних ретроспективно, до яких систем хакери намагалися отримати доступ ззовні. NDR також бачить типовий трафік, що виникає в результаті такої спроби доступу, як-от зв’язок із серверами C2C, сканування портів і певний трафік. NDR також дозволяє блокувати та сегментувати мережі або карантин систем – захід, який необхідно вжити у разі сумнівів. Таке рішення NDR, як NovaComand, також аналізує дані телеметрії з кінцевих точок. NovaCommand випустила патч і оновила правила виявлення такої атаки. NovaCommand також запускає інші рішення сторонніх розробників, щоб блокувати та сегментувати уражені системи та розділи мережі».
Більше на ForeNova.com
Статті по темі