«Найбільший факап у джава світі за останні 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, скоріше за все, дозволила урядовим установам встановлювати шпигунські програми на телефони журналістів, адвокатів та активістів.
33 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівI know it might controversial but log4j can be re-written in Rust and vulnerabilities will go away.
It can’t
Коментар порушує правила спільноти і видалений модераторами.
A Proof-Of-Concept for the recently found CVE-2021-44228 vulnerability github.com/kozmer/log4j-shell-poc
Вже як 3 роки пишу не на джаві, але два чи три останні роки коли ще писав всі використовували logback ...
1) Бігдата і типу того. Там лог4дж багто де засів (наче в спарку та еластіку)
2) Купа кривавих ентерпрайзів, де просто загорнули логування в слф4дж і забили
3) Старі тули для ентерпрайзів (впевнений, що в якомусь продукті ІБМ точно є або на крайняк в якомусь БПМН тулі)
logback.qos.ch/news.html
Тут є досить непоганий список вендорів\продуктів, яких аффектить (і яких точно не аффектить) ця вразливість
www.techsolvency.com/...j-log4shell/#who-affected
Краще прочитати про проблему у багтрекері вашої ос, а не по цитатах з твіттеру
В крайньому випадку — у довіреної особи, що безпекою займається
1. Нічого критичного неможливо зробити на більш-менш свіжих версіях JDK (хіба що надрукувати версію джави чи PATH у своїх же логах).
2. Навіть там де вони сто років не оновлювались, вихідні коннекшни на невідомі URL і так повинні бути закриті з точки зору мережевої безпеки (JNDI вразливості досить часто з’являються в різних компонентах).
3. Profit.
P.S. Але CVE все одно найцікавіший з усього, що я бачив за свою кар’єру :)
oh, you sweet summer child
На усіх проектах, де я працював, саме так і було.
Якщо у вас це ще не так, і ви не розумієте навіщо це потрібно, мої співчуття.
А JNDI чи JMX вразливостей я теж бачив хтозна скільки від Struts до ActiveMQ, тому цього разу сюрприз лише в тому, де саме її знайшли.
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
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
___
І я все ще чекаю на приклади
Перша лінка — звичайне пояснення для юзерів, там усе про JNDI, через яке можна зробити виклик на зовнішній сервер.
Тобто без JndiLookup та з закритим outbound трафіком на ліві урл нічого критичного зробити вони не зможуть.
А лякати страшним словом CVE можете когось іншого.
Працював багато років на проектах з PCI-DSS, і декілька разів допомагав цю сертифікацію проходити. Займався в тому числі моніторингом CVE та їх усуненням.
Я так розумію, пояснення схеми атаки на систему з вимкненим JndiLookup в log4j та закритим вихідним трафіком тут не буде?
Пишіть з голови, якщо там щось є, а не кидайте статті для широкого загалу.
Доречі, в вашому ж посиланні:
:)
)
Тобто, знову чукча письменник?
У вашому ж посиланні написаний результат тих заходів, що я написав в самому першому коментарі:
Ще раз, якщо і це не прочитали:
Тобто, CVE в них було, атаки теж... а результату... ні?
Чому ж це? Заждіть, а може в них периметр налаштований з фаєрволами?
— Ні, синку, це фантастика. Мывсеумрем!
На цьому я піду займатись чимось більш корисним, ніж годувати pretend-to-be-security-specialist.
Таке
Помилка. Лінк не веде на 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
Кожен раз, коли джавісти будуть холіварити на тему вразливостей в інших мовах, нехай згадуть цю тему ))
www.cvedetails.com
The future is now