У мережі було багато розмов про вразливість Log4J, що дозволяє зловмиснику ініціювати виконання довільного коду віддалено якщо у вас є можливість надсилати дані до програми, яка використовує бібліотеку log4j для реєстрації події.
Цей напад можна зробити без аутентифікаціїНаприклад, за допомогою сторінки автентифікації, яка реєструє помилки автентифікації.
Ця вада змусила компанії, що спеціалізуються на кібербезпеці, працювати над подією, і вказує на те, що кількість атак, які використовують цю недолік, зростає.
Члени Apache Software Foundation розробив виправлення щоб виправити вразливість, а це версія 2.15.0, на додаток до того, що були відомі можливі рішення для зниження ризиків.
Що таке Apache Log4j? Наскільки серйозна провина?
Для тих, хто ще не знає, наскільки серйозна проблема, можу сказати це 9 грудня виявлено вразливість в лдля запису бібліотеки log4j Apache.
Ця бібліотека широко використовується в проектах розробки додатків Java / J2EE, а також стандартні постачальники програмних рішень на основі Java / J2EE.
log4j містить механізм пошуку, який можна використовувати для запитів за допомогою спеціального синтаксису в рядку форматування. Наприклад, його можна використовувати для запиту різних параметрів, таких як версія середовища Java через $ {java: version} тощо.
Потім вказавши ключ jndi в рядку, механізм пошуку використовувати JNDI API. За замовчуванням всі запити виконуються з префіксом java: comp / env / *; однак автори реалізували можливість використання користувацького префікса за допомогою двокрапки в ключі.
Ось де криється вразливість: sijndi: ldap: // використовується як ключ, запит надходить на вказаний сервер LDAP. Також можна використовувати інші протоколи зв'язку, такі як LDAPS, DNS і RMI.
Таким чином, віддалений сервер, контрольований зловмисником, може повернути об’єкт на вразливий сервер, що може призвести до виконання довільного коду в системі або витоку конфіденційних даних.
Все, що зловмисник повинен зробити, це надіслати спеціальний рядок За допомогою механізму, який записує цей рядок у файл журналу і, отже, керується бібліотекою Log4j.
Це можна зробити за допомогою простих запитів HTTP, наприклад тих, які надсилаються через веб-форми, поля даних тощо, або за допомогою будь-якого іншого типу взаємодії за допомогою реєстрації на стороні сервера.
Тенабл охарактеризував вразливість як «найважливішу та критичну вразливість останнього десятиліття».
Доказ концепції вже опубліковано. Зараз ця вразливість активно експлуатується.
Серйозність уразливості є Максимум 10 за шкалою CVSS.
Ось список уражених систем:
- Apache Log4j версії від 2.0 до 2.14.1
- Apache Log4j версії 1.x (застарілі версії) підлягають спеціальному налаштуванню.
- Продукти, що використовують уразливу версію Apache Log4j - європейські національні сертифікати підтримують повний список продуктів та їх статус уразливості
CERT-FR рекомендує провести ретельний аналіз мережевих журналів. Наведені нижче причини можуть бути використані для виявлення спроби використання цієї вразливості під час використання в URL-адресах або певних заголовках HTTP як агента користувача
Наостанок варто згадати про це настійно рекомендується використовувати log2.15.0j версії 4 якомога швидше.
Однак у разі труднощів із переходом на цю версію можна тимчасово застосувати наступні рішення:
Для програм, які використовують бібліотеку log2.7.0j версії 4 і пізнішої, можна захистити від будь-якої атаки, змінивши формат подій, які будуть реєструватися за допомогою синтаксису% m {nolookups} для даних, які надасть користувач. .
Для цієї модифікації потрібно змінити файл конфігурації log4j для створення нової версії програми. Тому перед розгортанням нової версії потрібно повторити кроки технічної та функціональної перевірки.
Для програм, які використовують бібліотеку log2.10.0j версії 4 і новіших, також можна захистити від будь-якої атаки, змінивши параметр конфігурації log4j2.formatMsgNoLo