Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

«Найбільший факап у джава світі за останні 10 років» — у Java Apache Log4j виявили нову Zero-day вразливість

У популярній серед розробників бібліотеці логування Java Apache Log4j виявили вразливість нульового дня, яка легко експлуатується і дозволяє зловмисникам отримати повний контроль над вразливими серверами. Про це повідомляє LunaSec.

Що відомо про нову вразливість

«На днях стався найбільший факап у джава світі за останні 10 років? Вже дуже скоро десятки тисяч серверів не вийдуть онлайн. Наші сервери вже просканило з десяток сканерів», — написав співзасновник компанії Blynk Дмитро Думанський у Facebook.

Зокрема експлойт CVE-2021-44228 класифікують як серйозний і назвали «Log4Shell». Він дозволяє виконувати віддалений код без автентифікації (RCE) шляхом реєстрації певного рядка, оскільки користувач, який запускає програму, використовує бібліотеку логування Java.

Хто постраждав

Вразливість зачепила всі системи і служби, що використовують бібліотеку логування Java, Apache Log4j між версіями 2.0 та 2.14.1, включаючи багато служб і програм, написаних на Java. Ось приклади того, що вразливе.

Також до цього експлойту вразливі багато різних сервісів: хмарні сервіси, такі як Steam, Apple iCloud та програми, як-от Minecraft. Загалом будь-хто, хто використовує Apache Struts, може бути вразливим. Тут зібрані відгуки від постраждалих організацій.

До того ж було показано, що проста зміна імені iPhone викликає вразливість на серверах Apple.

Згодом стало відомо, що версії JDK, пізніші за 6u211, 7u201, 8u191 і 11.0.1, не піддаються впливу вектору атаки LDAP. У цих версіях для com.sun.jndi.ldap.object.trustURLCodebase встановлено значення false, тобто JNDI не може завантажувати віддалений код за допомогою LDAP.

Як фіксять проблему

Тим часом багато проєктів із відкритим кодом, як-от сервер Minecraft, Paper, уже почали виправляти використання log4j2.

Тимчасовий фікс: JAVA_OPTS="-Dlog4j.formatMsgNoLookups=true" або оновити версії Log4j до log4j-2.15.0-rc1. Однак уже знайдено спосіб обходити захист, доданий у випуску log4j-2.15.0-rc1.

Водночас запропоновано нове оновлення log4j-2.15.0-rc2 із повним захистом від уразливості. У коді виділяється зміна, пов’язана з відсутністю аварійного завершення у разі використання некоректно оформленого JNDI URL.

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


Раніше міжнародна компанія рішень для хмарної безпеки Wiz виявила серйозну вразливість у Microsoft Azure, яка зачіпає віртуальні машини Linux.

Перед цим компанія Apple випустила набір нових оновлень для iOS, macOS і watchOS, щоб виправити помилку, яка, як вважають дослідники безпеки з Citizen Lab, скоріше за все, дозволила урядовим установам встановлювати шпигунські програми на телефони журналістів, адвокатів та активістів.

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Коментар порушує правила спільноти і видалений модераторами.

A Proof-Of-Concept for the recently found CVE-2021-44228 vulnerability github.com/kozmer/log4j-shell-poc

Вже як 3 роки пишу не на джаві, але два чи три останні роки коли ще писав всі використовували logback ...

коли ще писав всі використовували logback ...

1) Бігдата і типу того. Там лог4дж багто де засів (наче в спарку та еластіку)
2) Купа кривавих ентерпрайзів, де просто загорнули логування в слф4дж і забили
3) Старі тули для ентерпрайзів (впевнений, що в якомусь продукті ІБМ точно є або на крайняк в якомусь БПМН тулі)

Тут є досить непоганий список вендорів\продуктів, яких аффектить (і яких точно не аффектить) ця вразливість

www.techsolvency.com/...​j-log4shell/#who-affected

Краще прочитати про проблему у багтрекері вашої ос, а не по цитатах з твіттеру

В крайньому випадку — у довіреної особи, що безпекою займається

1. Нічого критичного неможливо зробити на більш-менш свіжих версіях JDK (хіба що надрукувати версію джави чи PATH у своїх же логах).
2. Навіть там де вони сто років не оновлювались, вихідні коннекшни на невідомі URL і так повинні бути закриті з точки зору мережевої безпеки (JNDI вразливості досить часто з’являються в різних компонентах).
3. Profit.

P.S. Але CVE все одно найцікавіший з усього, що я бачив за свою кар’єру :)

вихідні коннекшни на невідомі URL і так повинні бути закриті

oh, you sweet summer child

На усіх проектах, де я працював, саме так і було.
Якщо у вас це ще не так, і ви не розумієте навіщо це потрібно, мої співчуття.

А JNDI чи JMX вразливостей я теж бачив хтозна скільки від Struts до ActiveMQ, тому цього разу сюрприз лише в тому, де саме її знайшли.

Нічого критичного неможливо зробити на більш-менш свіжих версіях JDK

Here you go — twitter.com/...​tatus/1470361495405875200

А ви самі зрозуміли, що там пишуть? (окрім «ой, воно навіть в JDK8 відтворюється!!!»)
І як це спрацює без вихідних коннекшнів, або доступу до локальної файлової системи.
Так, все це як вектор атаки може потенційно бути використано.
Але вже такого класу вразливості з’являються десятками кожного місяця.
Саме тому потрібні усі інші заходи забезпечення безпеки.

Так. Там пишуть що Ваш комент хибний і вводить в оману.

я бачив за свою кар’єру

Ви в іт пару тижнів?

Достатньо, щоб не дивуватись черговій JNDI вразливості і розуміти ризики, а не вестись на клікбейт.

Ну профі поставили маркування grave
Але я впевнений, що ви більш досвідчений за хто знайшов цю уразливість і за тих хто її фіксить

Відмінність від попердніх тільки в тому, що log4j багато де використовується.
Але якраз з досвіду, треба завжди розраховувати на те, що JNDI вразливість у вас ВЖЕ Є і її можуть використувати.
І приймати заходи заходи безпеки виходячи з цього.
Можете спитати про це у тих профі, на яких ви так бездумно посилаєтесь.

І приймати заходи заходи безпеки виходячи з цього.

Які наприклад?

А спробуйте для різноманіття, наприклад, почитати найперший комент у цьому треді.

Спробував
1 — це не правда
2 — це ухилення від проблеми, а не вирішення

То

Які наприклад?

А можна трохи більш аргументовано?
1. Що саме Ви зможете зробити з вимкненим JNDI в інтерполяторі (JndiLookup в цих версіях JDK відсутній за замовчуванням, в 11 я навіть спеціально перевіряв на цьому тижні).

2. Це — обов’язковий захід безпеки для захисту від такого (і не тільки такого) класу вразливостей:
newbedev.com/...​k-traffic-with-a-firewall

І прикро, що це треба комусь ще пояснювати.
Хоча нічого дивного в нашому світі ІТ: набігло досвідчених «JavaScript, HTML/CSS»-розробників чисто поржати, що «в джаві вашій-то теж дирка!»

1

Нічого критичного неможливо зробити на більш-менш свіжих версіях JDK

blog.cloudflare.com/...​erability-cve-2021-44228
It is CVE-2021-44228 and affects version 2 of Log4j between versions 2.0-beta-9 and 2.14.1
mvnrepository.com/...​g.log4j/log4j-core/2.14.1
Date (Mar 12, 2021)

_

для захисту від такого

Для ускладнення проникнення

_

Хоча нічого дивного в нашому світі ІТ: набігло досвідчених

Замість копіпасти не актуальних даних з мого профайлу, краще вкажіть на ваші досягнення на ctf

___
І я все ще чекаю на приклади

І приймати заходи заходи безпеки виходячи з цього.
blog.cloudflare.com/...​erability-cve-2021-44228
It is CVE-2021-44228 and affects version 2 of Log4j between versions 2.0-beta-9 and 2.14.1
mvnrepository.com/...​g.log4j/log4j-core/2.14.1
Date (Mar 12, 2021)

Перша лінка — звичайне пояснення для юзерів, там усе про JNDI, через яке можна зробити виклик на зовнішній сервер.
Тобто без JndiLookup та з закритим outbound трафіком на ліві урл нічого критичного зробити вони не зможуть.
А лякати страшним словом CVE можете когось іншого.

Замість копіпасти не актуальних даних з мого профайлу, краще вкажіть на ваші досягнення на ctf

Працював багато років на проектах з PCI-DSS, і декілька разів допомагав цю сертифікацію проходити. Займався в тому числі моніторингом CVE та їх усуненням.

Я так розумію, пояснення схеми атаки на систему з вимкненим JndiLookup в log4j та закритим вихідним трафіком тут не буде?
Пишіть з голови, якщо там щось є, а не кидайте статті для широкого загалу.

Доречі, в вашому ж посиланні:

Details of actual attempted exploitation we are seeing blocked by our firewall service are in a separate blog post.

:)

Я так розумію
І приймати заходи заходи безпеки виходячи з цього.
тут не буде?

)

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

Details of actual attempted exploitation we are seeing blocked by our firewall service are in a separate blog post.

Ще раз, якщо і це не прочитали:

blocked by our firewall service

Тобто, CVE в них було, атаки теж... а результату... ні?
Чому ж це? Заждіть, а може в них периметр налаштований з фаєрволами?
— Ні, синку, це фантастика. Мывсеумрем!

На цьому я піду займатись чимось більш корисним, ніж годувати pretend-to-be-security-specialist.

Зокрема експлойт CVE-2021-44228CVE-2021-44228

Помилка. Лінк не веде на nvd.nist.gov/...​uln/detail/CVE-2021-44228

www.debian.org/security/2021/dsa-5020
Chen Zhaojun of Alibaba Cloud Security Team discovered a critical security vulnerability in Apache Log4j, a popular Logging Framework for Java. JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From version 2.15.0, this behavior has been disabled by default.

ebat_ti_loh.jpg

Кожен раз, коли джавісти будуть холіварити на тему вразливостей в інших мовах, нехай згадуть цю тему ))

— two random unpaid folk maintain the code
— a random requested the vuln/feature in 2013
— major IT and security vendors rely on that code
— problem was publicised by teens in Minecraft video game
— scope of problem still unclear days later

Підписатись на коментарі