По следам Log4shell. Разбираем две уязвимости, оставшиеся в тени

Ра­нее рекомен­дуемые меры пре­дос­торож­ности вро­де уда­ления клас­са JNDiLookup, для решения этих проб­лем не работа­ют. Надо обно­вить­ся до вер­сии с пат­чем при пер­вой же воз­можнос­ти, если ты еще исполь­зуешь ста­рые методы. Сис­темы, которые дают дос­туп к кон­фигам Log4J, пока оста­ются уяз­вимыми.

Log4J, Log4Shell и родственные уязвимости (CVE)

Ло­гиро­вание — это не прос­то какая‑то при­хоть, а нас­тоящая необ­ходимость в соф­те. В Java появил­ся API для логиро­вания еще с вер­сии 1.4 в 2002-м, но Log4J начал набирать популяр­ность с 1999-го и давал фору по фичам. Из всех вари­антов он стал самым популяр­ным и исполь­зует­ся во мно­жес­тве при­ложе­ний на Java.

В декаб­ре 2021-го в Log4J обна­ружи­ли кучу серь­езных уяз­вимос­тей. Самая кри­тич­ная откры­вала дорогу для уда­лен­ного выпол­нения кода.

Сю­да вхо­дят:

• CVE-2021-44228 (CVSS 10.0), так­же извес­тная как Log4Shell – поз­воля­ет выпол­нять lookup-выраже­ния в дан­ных, которые записы­вают­ся в логах, что рас­кры­вает уяз­вимость JNDI.
• CVE-2021-45046 (CVSS 10.0) – ког­да в нас­трой­ках логиро­вания исполь­зует­ся нес­тандар­тный пат­терн с Context Lookup (нап­ример, $${ctx:loginId}), зло­умыш­ленник, кон­тро­лиру­ющий вход­ные дан­ные Thread Context Map (MDC), может соз­дать вре­донос­ные дан­ные, исполь­зуя шаб­лон JNDI Lookup.
• CVE-2021-44832 (CVSS 6.6) – зло­умыш­ленник, име­ющий пра­во изме­нять файл кон­фигура­ции логиро­вания, может соз­дать вре­донос­ную кон­фигура­цию, исполь­зуя JDBC Appender с источни­ком дан­ных, ссы­лающим­ся на JNDI URI.
• CVE-2021-45105 (CVSS 5.9) – не защища­ет от некон­тро­лиру­емой рекур­сии при самос­сыла­ющих­ся зап­росах. Если в нас­трой­ках логиро­вания исполь­зует­ся нес­тандар­тный пат­терн с Context Lookup (нап­ример, $${ctx:loginId}), зло­умыш­ленник, кон­тро­лиру­ющий вход­ные дан­ные Thread Context Map (MDC), может соз­дать вре­донос­ные дан­ные с рекур­сивным зап­росом, что вызовет StackOverflowError и оста­новит про­цесс.

Эти четыре проб­лемы воз­никли из‑за алго­рит­ма поис­ка строк, который поз­волял зло­умыш­ленни­кам встра­ивать неп­роверен­ные дан­ные в при­ложе­ние и экс­плу­ати­ровать уяз­вимос­ти, похожие на SQL-инъ­екции. Самая опас­ная из них – воз­можность заг­рузки кода с уда­лен­ного сер­вера через JNDI и его выпол­нение. Да, ты уга­дал, речь о Log4Shell!

Зап­латки выходи­ли по гра­фику, пред­став­ленно­му в таб­лице.

На декабрь 2021 года в Apache рекомен­довали сле­дующие меры пре­дос­торож­ности для тех, кто не может обно­вить­ся (под­робнее смот­ри на ар­хивной стра­нице безопас­ности от янва­ря 2022 года):

• Проб­лемы с Log4Shell (CVE-2021-44228 и CVE-2021-45046) — уда­ли класс JndiLookup из classpath. Если у тебя вер­сия Log4j ниже 2.16.0, прос­то убе­ри JndiLookup из classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. Так­же обра­ти вни­мание на вари­ант с хот­патчем выше.

Для решения воп­росов, свя­зан­ных с кон­тек­стом (CVE-2021-45046 и CVE-2021-45105):

• В кон­фиге жур­налиро­вания в раз­деле PatternLayout замени вызовы Context Lookups типа ${ctx:loginId} или $${ctx:loginId} на пат­терны Thread Context Map (%X, %mdc или %MDC).
• Ес­ли это не вари­ант, прос­то убе­ри вся­кие упо­мина­ния Context Lookups вро­де ${ctx:loginId} или $${ctx:loginId}, которые берут дан­ные из внеш­них источни­ков, таких как HTTP-заголов­ки или поль­зователь­ский ввод.

Строковая интерполяция и Java EE: точки пересечения

Од­на из фишек Log4J и про­чих Java-биб­лиотек — это замены свой­ств (они же под­ста­нов­ки). Они поз­воля­ют заменять плей­схол­деры вро­де ${xxx:yyy} на дру­гие зна­чения, ана­логич­но тому, как это про­исхо­дит в bash и про­чих язы­ках. В Log4J такие шту­ки добави­ли, что­бы упростить нас­трой­ку, и изна­чаль­но их исполь­зовали в кон­фигура­цион­ных фай­лах, а не в логиру­емых дан­ных. Эта фича была добав­лена в Log4J с вер­сией 2.0 в октябре 2010 года.

В какой‑то момент фичу изме­нили, что­бы поз­волить под­ста­нов­ки во вхо­дящих дан­ных, которые записы­вают­ся в лог (ско­рее все­го, это про­изош­ло в октябре 2011 года). Со вре­менем ста­ли добав­лять­ся новые клас­сы под­ста­новок. JNDI-под­ста­нов­ки были внед­рены в июле 2013-го. А код JNDI ведет свое начало от Java EE из 90-х.

Ес­ли же эту фичу исполь­зовать не по наз­начению, она может стать нас­тоящей голов­ной болью для безопас­ников. Виной все­му — нес­тыков­ка мно­жес­тва сис­тем, которые вооб­ще‑то не сто­ило бы друг с дру­гом соеди­нять:

• по­иск строк в кон­фиге;
• об­работ­ка вхо­дящих логов с небезо­пас­ными дан­ными;
• ста­рый Java EE/JNDI-код из 90-х.

Вот код из клас­са MessagePatternConverter, который обра­баты­вает вхо­дящие сооб­щения жур­нала. Как вид­но, он ищет сим­вол дол­лара и пере­адре­сует вызов клас­су StrSubstitutor.

В Log4J класс StrSubstitutor — это глав­ный вход для вся­ких lookup-фун­кций. Он опи­рает­ся на интерфейс StrLookup, который реали­зован мно­жес­твом клас­сов, каж­дый из которых тянет свой тип лукапа (боль­шинс­тво из них оби­тает в пакете org.apache.logging.log4j.core.lookup). Вся эта ком­пания под­клю­чает­ся через ар­хитек­туру пла­гинов, соз­давая кон­некты с дру­гими ком­понен­тами (кста­ти, кас­томные лукапы тоже под­держи­вают­ся). Один из методов поис­ка пре­дос­тавля­ет под­дер­жку Java Naming and Directory Interface (JNDI) — это реали­зова­но в клас­се JNDILookup.

Ни­же — интерфейс StrLookup и прос­той вари­ант поис­ка:

Этот код в клас­се JNDILookup прок­ладыва­ет мост меж­ду поис­ковыми опе­раци­ями и уста­рев­шим кодом JNDI (Java EE), который все еще таит­ся в нед­рах Java:

Уязвимость 1: отказ в обслуживании

Мно­гие типы стро­ково­го поис­ка в Log4J рекур­сивны и могут быть вло­жены друг в дру­га (код можешь пос­мотреть на GitHub).

Каж­дая вло­жен­ная фун­кция исполь­зует часть памяти сте­ка Java, которая отли­чает­ся от основной памяти (кучи), исполь­зуемой для боль­шинс­тва про­цес­сов. Нас­тра­ивает­ся эта память парамет­ром -Xss и в зависи­мос­ти от тво­ей ОС и вер­сии Java может варь­иро­вать­ся от одно­го мегабай­та до одно­го гигабай­та. Если перебор­щишь и пре­высишь этот лимит, тебя ожи­дает StackOverFlowError.

Хо­тя в CVE-2021-45105 упо­мина­ются рекур­сивные зап­росы, счи­талось, что эта уяз­вимость воз­ника­ет лишь при нес­тандар­тных нас­трой­ках, где исполь­зуют­ся кон­текс­тные вызовы. Но, как ока­залось, проб­лему мож­но исполь­зовать и на стан­дар­тных нас­трой­ках, отпра­вив сис­теме вре­донос­ный пакет, который она попыта­ется залоги­ровать.

Этот баг пофик­сили, отклю­чив вызовы, но пре­дыду­щие вер­сии и любые сис­темы, исполь­зующие нас­трой­ки Log4J, оста­ются уяз­вимыми в стан­дар­тных кон­фигура­циях. Если отпра­вить рекур­сивный пей­лоад на уяз­вимую сис­тему, Log4J будет обра­баты­вать его до тех пор, пока у при­ложе­ния не закон­чится память сте­ка.

Раз­мер сте­ка в Java мож­но про­верить с помощью такой коман­ды:

Ата­ка про­водит­ся «всле­пую» и не тре­бует получе­ния никакой обратной свя­зи от сис­темы.

Раз­мер полез­ной наг­рузки, который может валить JVM, зависит от нас­трой­ки памяти сте­ка. Ниже перечис­лены раз­меры полез­ной наг­рузки, которые были про­тес­тирова­ны на JDK 17.

Пример эксплоита

Код для про­вер­ки воз­можнос­ти экс­плу­ата­ции:

При­мер пей­лоада:

В обыч­ной вер­сии внут­ренний поиск (${java:runtime}) вер­нет информа­цию о сбор­ке JVM, а внеш­ние поис­ки (${lower:xxx}) прев­ратят эту инфу в ниж­ний регистр. Вот так:

Но если у тебя Java с недос­татком памяти и уяз­вимой вер­сией Log4J, все нак­роет­ся мед­ным тазом при­мер­но так:

Уязвимость 2: утечка данных

Ока­залось, что JNDI-зап­росы — нас­тоящие бом­бы замед­ленно­го дей­ствия, но это все­го лишь один из мно­гих типов зап­росов, которые дос­тупны в Log4J. Исправ­ления для уяз­вимос­ти Log4Shell отклю­чают интерпо­ляцию зап­росов в логах, одна­ко в вер­сиях до 2.15 все еще дос­тупны все типы зап­росов.

Да­же сегод­ня в пос­ледних вер­сиях зап­росы мож­но исполь­зовать в кон­фигах — и это отно­сит­ся к самым све­жим вер­сиям Log4J (пос­коль­ку дос­туп к нас­трой­кам не вхо­дит в модель угроз про­екта). Более того, зап­росы оста­ются дос­тупны­ми, даже если класс JNDILookup уда­лен (это было рекомен­дован­ным спо­собом миними­зации угро­зы без обновле­ния биб­лиоте­ки).

В этих трех сце­нари­ях (вер­сии до 2.15, вер­сии с уда­лен­ным клас­сом JNDILookup и любые вер­сии с дос­тупом к кон­фигам) дру­гие типы зап­росов все еще активны и могут слить информа­цию о сис­теме.

В Log4J дос­тупны сле­дующие типы под­ста­новок (под­робнее мож­но почитать в до­кумен­тации):

Мно­гие дос­тупные фун­кции поис­ка воз­вра­щают такие дан­ные, как перемен­ные окру­жения, сис­темные свой­ства, Spring-парамет­ры, информа­ция о выпол­нении, сек­реты и тому подоб­ное. Такие шту­ки, как атри­буты выпол­нения, могут исполь­зовать­ся для началь­ной раз­ведки. Но есть нюанс: боль­шинс­тво из них не под­держи­вает под­ста­новоч­ные зна­ки — нуж­но точ­но знать имя перемен­ной или свой­ства, которое ты хочешь вытащить.

Что­бы про­читать информа­цию из этих зап­росов, нужен дос­туп к логам. Таким обра­зом, зло­умыш­ленник не смо­жет про­вер­нуть ата­ку всле­пую. Ситу­ации, ког­да дос­туп воз­можен, это, нап­ример, сооб­щения об ошиб­ках или облачные/SAAS-при­ложе­ния, где поль­зовате­ли могут смот­реть логи.

Пример эксплуатации

В таб­лице — при­меры полез­ных наг­рузок.

Код для про­вер­ки экс­пло­ита:

В обновлен­ной вер­сии такой лукап работать не будет: по умол­чанию все зап­росы отру­бают­ся, так что на выходе получишь толь­ко сле­дующее сооб­щение:

В уяз­вимой вер­сии Log4J мож­но с помощью спе­циаль­ного лукапа вытащить инфу о сис­теме:

Ответ производителя

Apache и про­ект Log4J зас­ветили эту проб­лему еще в сен­тябре 2022-го с выходом вер­сии Log4J 2.19 — через обновле­ние стра­ницы безопас­ности (вот архив со стра­ницы безопас­ности и ап­дейт в Git). Раз­работ­чики Log4J соч­ли это частью CVE-2021-45046 и CVE-2021-44228, а так­же учтенной в прош­лых релизах, так что новых CVE уяз­вимос­тям не выдава­ли и код не меняли. На момент написа­ния этой статьи (июнь 2025-го) опи­сания CVE еще не пол­ностью обновле­ны в базе NVD/CVE, но уже есть на стра­нице безопас­ности Log4J. А вот пре­дыду­щая инфа о том, как убрать класс JNDILookup, с этой стра­нице исчезла.

Уязвимые версии и способы защиты

Под уда­ром ока­зались сле­дующие вер­сии Log4J:

• Все вер­сии Log4J v2 до v2.15, кро­ме v2.12.2-4 (Java 7) и v2.3.1-2 (Java 6).
• В v2.15, v2.12.2 (Java 7) и v2.3.1 (Java 6) поиск в логах по умол­чанию отклю­чен, но его мож­но акти­виро­вать сно­ва. Если сно­ва вклю­чить поиск или исполь­зовать кон­текс­тные поис­ки (CVE-2021-45046), то эти вер­сии уяз­вимы.
• Вер­сии от v2.16+, v2.12.3+ (Java 7) и v2.3.2 (Java 6) оста­ются уяз­вимыми, ес­ли пре­дос­тавлен дос­туп к кон­фигура­цион­ным фай­лам.
• Log4J v1 не под­вержен уяз­вимос­ти, кро­ме слу­чаев, ког­да исполь­зует­ся JMSAppender (см. CVE-2021-4104).

Поль­зовате­лям сто­ит обно­вить­ся до вер­сии, которая пол­ностью отклю­чает обра­щения к логам — это v2.16+, v2.12.3 (для Java 7) или v2.3.2 (для Java 6). Так­же не забудь обно­вить инс­тру­мен­ты вро­де WAF и IDS-сис­тем, что­бы они отсле­жива­ли подоз­ритель­ные шаб­лоны и быс­тро выяв­ляли такие проб­лемы.

Ес­ли ты не можешь обно­вить­ся, то преж­ние рекомен­дации раз­работ­чика не спа­сут от этих багов. И хотя теоре­тичес­ки мож­но отка­тить сущес­тву­ющие пат­чи, что­бы отклю­чить лукапы, это­го луч­ше не делать. Про­чие пуб­личные зап­латки, вро­де упо­мяну­того выше Java hotpatch agent, эти проб­лемы тоже не реша­ют.

Дос­туп к кон­фигам Log4J луч­ше в кор­не пре­сечь — лукапы все еще работа­ют в кон­фигах, и это может стать лазей­кой для атак. Прав­да, с фев­раля 2023 года, как заяви­ли в Apache, наход­ки, свя­зан­ные с дос­тупом к кон­фигура­ции Log4J, боль­ше не счи­тают­ся уяз­вимос­тями. Но это не зна­чит, что мож­но рас­сла­бить­ся!