Pull to refresh

Comments 28

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

Но будите внимательны :)

Спасибо!

Уже исправлено.

1) -Dlog4j2.formatMsgNoLookups=true уже не работает.
2) Не для всех проектов можно использовать 2.16.0 поэтому есть 2.12.2

Не для всех проектов можно использовать вообще какую-либо другую версию, потому что вы далеко не всегда можете легко пересобрать код из исходников, а классы log4j вполне могут лежать запакованными в jar какого-то другого проекта. Т.е. только полное сканирование одним из доступных уже сканеров покажет, уязвима ли ваша система.

Скажем, в моем случае уязвимыми являются классы из hive-common версии 3.*. А они входят в состав большого продукта под названием Hadoop, и даже если он собственной сборки, собрать его не так просто и быстро, и я это сделать не могу. Поэтому на сегодня -Dlog4j2.formatMsgNoLookups=true чуть ли не единственный возможный вариант, не считая более экзотических пока решений. Ну благо, у нас интранет, и внешние атаки не имеют места.

Тем хуже. Откуда данный попадают в hadoop. есть ли гарантия, что не прилетит сообщение, которое сработает? По мне основная проблема этой уязвимости, что непонятно где и как это может аукнутся.


Как пример в одном стороннем компоненте индексатор почты сделан с помощью эластика с проблемной версией log4j.

Да, в целом все непонятно, если у вас не тупо веб приложение. Т.е. я например не знаю (ну, на самом деле это я просто исходники пока не смотрел), в каком месте и что Hive (где используется log4j2) вообще логирует. Но я гляжу в логи, и судя по ним — ничего такого, где были бы внешние данные. Оно практически вообще ничего не логирует. Т.е. я могу, например, подсунуть Hive запрос, где в комментариях или константах будет ${jndi}, только запросы не логируются.

Кроме того, чтобы оно «сработало», это должен быть атакующий внутри. А у атакующего внутри, как правило, есть более простые методы достать то, что можно достать такими способами атаки. Кроме того, внутри у него гораздо меньше шансов уйти незамеченным. Так что разница таки есть.

Но таки да, атака изнутри на что-то типа инфраструктуры, керберос там какой-нибудь, может быть не менее опасной. Она просто не такая простая.

Ну так и кипиш такой только от того, что ни кто не знает где стрельнет и надо выбирать тратить время на анализ или на обновление.

Ну атаки изнутри это гораздо опастнее и не факт, что легче ловится.

>и кто не знает где стрельнет
Конечно. С этим никто не спорит. Яж и не говорил, что внутренние атаки например невозможны, или что они потенциально безопаснее. Ни в коей мере. В этом случае просто одним вектором атак меньше. Но как раз изнутри, если у вас украдут данные из кербероса, или иной похожей инфраструктурной системы, то дальше уже украдут вообще все.

> не факт, что легче ловится.
в случае известного IP внутри интранета — конечно же легче. Не вот так чтобы прям совсем легко — но вычислить откуда что пришло, вполне вычислят. Для внешнего атакующего как — ну узнали вы, что он скажем из Бангладеш к вам зашел, и что? А тут вы будете знать как минимум машину, а как максимум — логин. То есть следы нужно будет заметать намного тщательнее.

Кроме того, чтобы оно «сработало», это должен быть атакующий внутри.

Строго говоря, нет. Вполне достаточно чтобы логирующиеся данные смогли просочиться. См. https://habr.com/ru/company/bizone/blog/595473/comments/#comment_23821537

Как пример in the wild: web server access log -> ELK/EFK + ошибка (несовпадение типа поля, слишком большое поле или ещё что-нибудь) и вы получили rce где-то в глубине своей инфраструктуры.

Мы про интранет говорили. Ну просочились, и чо будет-то? JNDI Lookup на внешний хост в интернете? Ну пусть попробует, чо.

Вы слишком самоуверены

Ну, если вы нет — огласите сценарий атаки, посмотрим вместе? Из моего интранета описанные публично сценарии невозможны — это просто физически изолированная сеть.

Физически от чего изолирована ваша сеть? Если вы работаете со сферическим конём в вакууме то да вам ничего бояться. Но мне что то не верится

От интернета, естественно. Более того, у нас все порты и лишние IP по умолчанию закрыты.
>Но мне что то не верится
У нас PCI DSS :) Можно конечно не верить, но внешний аудит проходили.

не надо мне рассказывать про аудиты.

Я предпочитаю верить что моя система уязвима и патчить её чем наоборот

Я с этим даже спорить не буду. Я знаю что моя система уязвима. Но одно дело — реальные сценарии атаки, а другое — научная фантастика. Патчить лучше от реальных.

Вот у вас есть реальный сценарий? У меня пока нет. Я просмотрел доступные логи, и понял, что ничего из внешних данных у меня не логируется. И разумеется, каждый может ошибаться — но на сегодня я скорее считаю, что для нашего проекта реальной опасности нет.
Вот я честно не понимаю одной простой вещи: в моей практике java никогда не торчала голой ж., пардон, tomcat-ом в интернет. То есть, снаружи всегда был apache htpd (раньше) или nginx (сегодня), а порой и специальные железные балансировщики от IBM, где внутри возможно тоже nginx, но это не точно. И они, блин, никогда не были уязвимы для log4shell, потому что в них нету log4j. И не будут никогда. Все что будет — это будет в их логах, без каких либо утечек.

А tomcat, или там Spring Boot, или что угодно, уже стоит внутри, так же точно, как и СУБД, или скажем Кафка, или что там у нас еще есть в нашей инфраструктуре. При этом стоит он на другом хосте, и закрыт файрволом, и правила этого файрвола говорят, что нечего этому Spring Boot делать за пределами нашей интрасети. Т.е. можно сто раз ему подсунуть ${jndi:...}, дальше этого же хоста оно не уйдет — пакеты по сети туда не будут ходить. Да до него собственно и не дойдет это все уже — потому что внешние данные из дикой природы скорее всего будут уже санированы до попадания сюда, а даже если не будут — см. п.1

Вот для меня это настолько обычно и привычно, что прямо удивляет — а что, кто-то делает не так? А зачем? Из лени, по дурости, или есть еще какие-то причины?

По неопытности ещё может быть. Но и лень с дуростью тоже весьма распространены.

идеальный мир далеко не так идеален.

Зловреду нет необходимости выходить в интернет. Если он может все что угодно на твоём хосте - это большая проблема, например зашифровать твои данные.

Имеющиеся способы эксплуатации (этой конкретной дырки) предполагают, что код зловреда будет взят с внешнего хоста. Поэтому там как раз JNDI — в нем и лежит код. Внедрить во внутренней сети такого — ну, конечно можно, просто в интернете если кто-то такое сделал — его сложно взять за жабры. А в интранете это намного проще — понятно где искать, все IP записаны, логи в эластике и т.д. Более того, часто по умолчанию все физические доступы на уровне сети закрыты, а не открыты — то есть, вариантов куда можно внедрить зловред, не так много. И человек, которые это сможет сделать, скорее всего найдет способы нагадить и попроще.

Ну то есть, в общем случае вы правы конечно. Просто это уже другая история.

Просто вы говорите про джава вэб. Но эта уязвимость отлично работает и для стандалоун джава - например, было продемонстрировано, как выполняется код машине пользователя, у которого запущен Майнкрафт. Я как человек, который пострадал от ransomware - скажу, что это не очень приятно. А так вы правы - если в сети нет доступов наружу, то нет и проблемы.

>Просто вы говорите про джава вэб.
Я так говорю просто потому что это самый типовой и понятный сценарий, описанные атаки. Там ясно, откуда могут появиться данные, которые запишутся в лог. Но там же и понятно, как закрыть дырку. Файрволом, например — потому что нашему веб приложению нечего делать на каком-то там IP адресе в интернете.

В случае же прочих вариантов пока все достаточно мутно.
Есть еще неплохой на мой взгляд вариант исправления. Написать (или скачать в интернете готовый) javaagent, который прицепится к JVM (статически при старте, или даже динамически), и модифицирует байт код нужных классов log4j, чтобы они ничего не делали. Если вы не используете сами эти подстановки log4j, типа jndi, вам этого хватит.

Причем, этот вариант работает для всех версий log4j, по крайней мере теоретически.

А потом вы натыкаетесь на проект где какой-то добрый человек сделал shade+relocate для org.apache.logging..

Sign up to leave a comment.

Articles

Change theme settings