Log4Shell, вразливість Інтернету, нещодавно вразила мільйони машин. Причиною цього є Log4j, незрозуміла, але майже повсюдна частина програмного забезпечення.
Log4j використовується для реєстрації всіх дій, які відбуваються за лаштунками в різних комп’ютерних системах.
Він заснований на відкритій бібліотеці журналів, яка використовується підприємствами і навіть державними організаціями в більшості програм.
Оскільки це одна з найгірших дір у кібербезпеці, яку коли-небудь було виявлено, дуже важливо захистити свої системи від цієї вразливості. Але як?
Давайте детально розглянемо вразливість Log4j і всі можливі рішення для її усунення.
Що таке Log4j?
Log4j є з відкритим вихідним кодом фреймворк ведення журналів, що дозволяє розробникам програмного забезпечення записувати різні дані в своїх програмах. Це компонент проекту Apache Logging Services, який керується Apache Software Foundation.
Сотні веб-сайтів і програм використовують Log4j для виконання важливих операцій, таких як реєстрація даних для налагодження та інших цілей.
Коли ви вводите або натискаєте погане онлайн-посилання та отримуєте повідомлення про помилку 404, це частий приклад роботи Log4j. Веб-сервер, який запускає домен веб-посилання, до якого ви намагалися отримати доступ, повідомляє, що такої веб-сторінки не існує. Він також реєструє подію в Log4j для системних адміністраторів сервера.
У всіх програмах використовуються подібні діагностичні сигнали. У онлайн-грі Minecraft, наприклад, сервер використовує Log4j для реєстрації активності, такої як загальна використана оперативна пам’ять та інструкції користувача, надіслані на консоль.
Як виникає вразливість?
Пошуки – це нова функція, представлена в Log4j 2.0, яка допомагає включати додаткову інформацію в записи журналу. Одним із таких пошуків є пошук JNDI (Інтерфейс імен і каталогів Java), який є API Java для зв’язку зі службою каталогів.
Використовуючи цей підхід, внутрішні ідентифікатори користувачів можна зіставити з реальними іменами користувачів. Цей запит виявляє щойно виявлену вразливість RCE, оскільки одним із типів даних, що надаються сервером LDAP, є URI, що вказує на клас Java, який потім завантажується в пам’ять і запускається екземпляром Log4j.
Через слабкість перевірки вхідних даних бібліотеки Log4j можна впровадити довільний сервер LDAP з ненадійного джерела. Оскільки розробники припускають, що дані, надіслані в журнали, будуть оброблятися як звичайний текст, додаткова перевірка введених даних не проводиться, а небезпечні дані, введені користувачем, потрапляють у журнали.
Оператор журналу може виглядати так:
Зловмисник тепер вставить запит JNDI, який посилається на шахрайський сервер LDAP, у параметр URL-адреси. Пошук JNDI буде таким:
Бібліотека Log4j потім спілкується з цим сервером LDAP за адресою attacker.com, щоб отримати інформацію про каталог, включаючи значення для Java Factory і Java Codebase.
Ці два значення включають клас Java зловмисника, який потім завантажується в пам’ять і виконується екземпляром Log4j, завершуючи виконання коду.
Хто ризикує?
Уразливість Log4j надзвичайно широка, вона впливає на бізнес-додатки, вбудовані пристрої та їх підсистеми. До таких програм належать Cisco Webex, Minecraft і FileZilla FTP.
Однак це далеко не весь список. Недолік впливає навіть на місію вертольота Ingenuity Mars 2020, яка використовує Apache Log4j для запису подій.
Співтовариство безпеки склало a список уразливих систем. Важливо відзначити, що ці списки постійно оновлюються, тому, якщо певна програма чи система не представлені, не думайте, що це не впливає.
Вплив цієї вразливості цілком ймовірний, і навіть якщо специфічний технологічний стек не застосовує Java, керівники служби безпеки повинні очікувати, що це зроблять критичні системи постачальників, постачальники SaaS, постачальники хмарного хостингу та постачальники веб-серверів.
Як перевірити уразливість Log4j?
Перший крок – визначити, чи вже відбувся напад. Ви можете зробити це, перевіривши системні журнали на наявність фрагментів корисного навантаження RCE.
Якщо пошук за такими термінами, як «jndi», «ldap» або «$::», дає будь-які журнали, дослідникам безпеки слід детальніше з’ясувати, чи була це законна атака чи просто відбиток пальців.
Було виявлено багато нападів у дикій природі, які не доставляли жодного шкідливого корисного навантаження. Тим не менш, вони були проведені експертами з безпеки, щоб визначити, скільки програм було вразливими до цієї атаки.
Наступним кроком є використання бібліотеки Log4j для визначення всіх проектів. Якщо використовуються версії між 2.0-beta9 і 2.14.1, проект може бути вразливим.
З огляду на складність визначення, де існує ця вразливість, краще вважати, що проект є вразливим і що оновлення бібліотеки є найкращим шляхом для усунення небезпеки виконання коду.
Проект не є вразливим, якщо використовувана версія менша за 2.0-beta 9, хоча бібліотеку Log4j все одно слід оновити, оскільки версії в діапазоні 1.x застарілі і більше не отримують оновлень.
Якщо виявлено сприйнятливий проект, рекомендується перевірити його, щоб побачити, чи містить будь-яка інформація, зареєстрована за допомогою Log4j, інформацію, яку користувач може змінити. Прикладами цих даних є URL-адреси, параметри запиту, заголовки та файли cookie. Якщо один із них зареєструється, проект під загрозою.
Ці знання можуть допомогти вам глибше заглибитися в системні журнали та визначити, чи ваша веб-програма вже зазнала атаки.
Існують безкоштовні онлайн-інструменти, які можуть визначити, чи є веб-додаток уразливим. Однією з таких програм є Мисливець Log4Shell. Він відкритий і доступний на GitHub.
Якщо виявлено вразливу область коду в онлайн-додатку, корисне навантаження, надану розкритим інструментом, можна використати для введення його у веб-додаток. Інструмент тестування виявить з’єднання між вашим веб-додатком та їхнім сервером LDAP, якщо вразливість була використана.
Рішення для усунення вразливості Log4j
Першим кроком є оновлення Log4j, що ви можете зробити, використовуючи звичайні менеджери пакетів або завантаживши його безпосередньо з цього сторінка.
Також можна зменшити можливість використання уразливості, встановивши для змінної середовища FORMAT MSG NO LOOKUPS значення true. Однак цей контрзахід застосовний лише до версій Log4j, більших або рівних 2.10.
Тепер розглянемо альтернативні варіанти.
1. Обхідні шляхи для Log4j версії 2.17.0
Безумовно, настійно радимо використовувати Log4j версії 2.15.0 для захисту від Log4Shell, однак, якщо це неможливо, доступні інші рішення.
Версії 2.7.0 і новіші Log4j: Можна захистити від будь-якої атаки, змінивши формат подій, що реєструються, використовуючи синтаксис відсотка m nolookups для даних, наданих користувачем. Це оновлення вимагає редагування файлу конфігурації Log4j, щоб створити нову версію програми. Як наслідок, перед розгортанням цієї нової версії необхідно повторити етапи технічної та функціональної перевірки.
Log4j версії 2.10.0 і новіших версій: Також можна захиститися від будь-якої атаки, встановивши для параметра конфігурації log4j2.formatMsgNoLookups значення true, наприклад, під час запуску віртуальної машини Java з параметром -Dlog4j2». formatMsgNoLookups = true, Інший варіант — видалити клас JndiLookup з аргументу classpath, що видалить основний вектор атаки (дослідники не виключають можливості іншого вектора атаки).
Amazon Web Services надає гарячий патч, який «використовується на власний ризик». Були опубліковані й інші «техніки», такі як Logout4Shell, яка «використовує цю вразливість проти себе». Експерт з безпеки ставить під сумнів законність цього кроку, який передбачає «злом машини, щоб її виправити».
2. Проблему вирішено в Log4j v2.17.0.
Для версій вищих за 2.10: Log4j2.formatMsgNoLookups має бути встановлено на true.
Для версій від 2.0 до 2.10.0: виконайте таку команду, щоб видалити клас LDAP з Log4j.
Для Log4j2.formatMsgNoLookups потрібно встановити значення true в системних налаштуваннях.
Пом'якшення в JVM
Пом’якшення за допомогою параметрів JVM більше не є можливістю. Інші методи пом'якшення продовжують бути успішними. Якщо можливо, оновіть до Log4j версії 2.17.0. Існує посібник із міграції для Log4j v1.
Якщо оновлення неможливе, переконайтеся, що компоненти на стороні клієнта і сервера мають встановлені системні властивості -Dlog4j2.formatMsgNoLookups = true.
Зауважте, що Log4j v1 досяг свого кінця (EOL) і більше не отримуватиме виправлення помилок. Інші вектори RCE також сприйнятливі до Log4j v1. Тому ми закликаємо вас якнайшвидше оновити до Log4j 2.17.0.
3. Заходи пом'якшення
Поточні експлойти не можуть працювати, навіть якщо Log4j в деяких випадках сприйнятливий, наприклад, якщо на хост-машині працює версія Java вище, ніж 6u212, 7u202, 8u192 або 11.0.2.
Це пов’язано з кращим захистом віддаленого завантаження класу Java Naming and Directory Interface (JNDI) у поточних версіях, що необхідно для атаки.
Крім того, з версіями Log4j, більшими за 2.10, проблеми можна уникнути, установивши для системного значення formatMsgNoLookups значення true, надавши аргумент JVM -Dlog4j2.formatMsgNoLookups = true або видаливши клас JndiLookup зі шляху до класу.
Тим часом, поки уразливі випадки не будуть виправлені, уразливість можна усунути за допомогою наступних методів:
- Установіть для системної властивості log4j2.formatMsgNoLookups значення true для >=2.10.
- Встановіть для параметра середовища LOG4J FORMAT MSG NO LOOKUPS значення true для >=2.10.
- Видаліть JndiLookup.class із шляху до класів для версії 2.0-beta9 до 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Рекомендована найкраща практика — обмежити вихідний трафік до Інтернету лише відповідними портами.
Хоча більшість атак на місцях здійснюються через HTTP, уразливість може бути використана за допомогою будь-якого протоколу, який реєструє введені користувачем дані за допомогою Log4j.
Проте оновлення до log4j 2.17.0 є найкращим засобом, оскільки хтось може знайти додатковий підхід до проблеми. Крім того, багато видавців і виробників оголосили про покращення своїх послуг або програм.
4. Виправлення уразливості Log4Shell
Log4j є всюдисущим, особливо зараз, коли вразливість використовується. Підводячи підсумок, все, що вам потрібно зробити, це включити наступні символи в журнали, які перевіряє Log4j.
І це завантажить та виконає файл Java, розташований у кінці URL-адреси. Це настільки ж просто, як і драматично.
Як вам відомо, дуже важливо оновити log4j до версії >= 2.17.0, щоб усунути цю вразливість Log4Shell (CVE-2021-44228).
Якщо це неможливо:
Для програм, які використовують бібліотеку Log4j версії 2.10.0 і новіших, також можна захистити від будь-якої атаки, встановивши параметр конфігурації log4j2.formatMsgNoLookups у значення true, наприклад, під час запуску віртуальної машини Java з -Dlog4j2.formatMsgNoLookups = true варіант.
Інший варіант — видалити клас JndiLookup з аргументу classpath, що видалить основний вектор атаки (дослідники не виключають існування іншого вектора атаки).
примітки
Організації, які вагаються або не бажають вносити зміни в сприйнятливі системи (або які хочуть встановити додаткові засоби захисту), повинні подумати про:
- Переконайтеся, що весь трафік маршрутизується через iSensor/WAF/IPS. Це може перешкодити нападу отримати доступ до системи.
- Обмеження обсягу трафіку, який може досягати сприйнятливої системи. Якщо системі не потрібно підключатися до Інтернету, обмежте доступ лише до необхідних і надійних IPS та діапазонів.
- Зменшення дозволеного вихідного трафіку хоста. Оскільки ця атака діє шляхом підключення до шахрайського сервера, усі зайві IP-адреси та порти мають бути заблоковані на брандмауері.
- Якщо служба більше не потрібна, її слід вимкнути, доки не буде готово виправлення.
Висновок
Недоліки Log4j шокували нашу спільноту і нагадали всім нам, наскільки ми покладаємось на програмне забезпечення з відкритим кодом.
Log4j унікальний. Це не операційна система, не браузер і не програмне забезпечення. Швидше, це те, що програмісти називають бібліотекою, пакетом або модулем коду. Це лише одна ціль, тобто ведення запису про те, що відбувається на сервері.
Люди, які пишуть код, вважають за краще зосередитися на тому, що робить їхнє програмне забезпечення відмінним. Вони не зацікавлені в винаході велосипеда. В результаті вони покладаються на безліч існуючих бібліотек коду, таких як Log4j.
Модуль Log4j є похідним від Apache, найбільш широко використовуваного програмного забезпечення веб-сервера. Тому його можна виявити на мільйонах серверів. Отже, посилюються загрози безпеці.
Сподіваюся, наведені вище рішення допоможуть вам захистити ваші пристрої.
Слідкуйте за оновленнями HashDork, щоб отримати більше корисної інформації зі світу технологій.
залишити коментар