Комментарии 28
Я понимаю, что ваш блог это сплошные переводы и не считаю это чем-то плохим. Но настолько явный гуглтранслейт с переводом устоявшихся терминов, которые переводить не надо - откровенное издевательство.
1) -Dlog4j2.formatMsgNoLookups=true уже не работает.
2) Не для всех проектов можно использовать 2.16.0 поэтому есть 2.12.2
Скажем, в моем случае уязвимыми являются классы из hive-common версии 3.*. А они входят в состав большого продукта под названием Hadoop, и даже если он собственной сборки, собрать его не так просто и быстро, и я это сделать не могу. Поэтому на сегодня -Dlog4j2.formatMsgNoLookups=true чуть ли не единственный возможный вариант, не считая более экзотических пока решений. Ну благо, у нас интранет, и внешние атаки не имеют места.
Тем хуже. Откуда данный попадают в hadoop. есть ли гарантия, что не прилетит сообщение, которое сработает? По мне основная проблема этой уязвимости, что непонятно где и как это может аукнутся.
Как пример в одном стороннем компоненте индексатор почты сделан с помощью эластика с проблемной версией log4j.
Кроме того, чтобы оно «сработало», это должен быть атакующий внутри. А у атакующего внутри, как правило, есть более простые методы достать то, что можно достать такими способами атаки. Кроме того, внутри у него гораздо меньше шансов уйти незамеченным. Так что разница таки есть.
Но таки да, атака изнутри на что-то типа инфраструктуры, керберос там какой-нибудь, может быть не менее опасной. Она просто не такая простая.
Ну так и кипиш такой только от того, что ни кто не знает где стрельнет и надо выбирать тратить время на анализ или на обновление.
Ну атаки изнутри это гораздо опастнее и не факт, что легче ловится.
Конечно. С этим никто не спорит. Яж и не говорил, что внутренние атаки например невозможны, или что они потенциально безопаснее. Ни в коей мере. В этом случае просто одним вектором атак меньше. Но как раз изнутри, если у вас украдут данные из кербероса, или иной похожей инфраструктурной системы, то дальше уже украдут вообще все.
> не факт, что легче ловится.
в случае известного IP внутри интранета — конечно же легче. Не вот так чтобы прям совсем легко — но вычислить откуда что пришло, вполне вычислят. Для внешнего атакующего как — ну узнали вы, что он скажем из Бангладеш к вам зашел, и что? А тут вы будете знать как минимум машину, а как максимум — логин. То есть следы нужно будет заметать намного тщательнее.
Кроме того, чтобы оно «сработало», это должен быть атакующий внутри.
Строго говоря, нет. Вполне достаточно чтобы логирующиеся данные смогли просочиться. См. https://habr.com/ru/company/bizone/blog/595473/comments/#comment_23821537
Как пример in the wild: web server access log -> ELK/EFK + ошибка (несовпадение типа поля, слишком большое поле или ещё что-нибудь) и вы получили rce где-то в глубине своей инфраструктуры.
Вы слишком самоуверены
Физически от чего изолирована ваша сеть? Если вы работаете со сферическим конём в вакууме то да вам ничего бояться. Но мне что то не верится
У нас PCI DSS :) Можно конечно не верить, но внешний аудит проходили.
не надо мне рассказывать про аудиты.
Я предпочитаю верить что моя система уязвима и патчить её чем наоборот
Вот у вас есть реальный сценарий? У меня пока нет. Я просмотрел доступные логи, и понял, что ничего из внешних данных у меня не логируется. И разумеется, каждый может ошибаться — но на сегодня я скорее считаю, что для нашего проекта реальной опасности нет.
А tomcat, или там Spring Boot, или что угодно, уже стоит внутри, так же точно, как и СУБД, или скажем Кафка, или что там у нас еще есть в нашей инфраструктуре. При этом стоит он на другом хосте, и закрыт файрволом, и правила этого файрвола говорят, что нечего этому Spring Boot делать за пределами нашей интрасети. Т.е. можно сто раз ему подсунуть ${jndi:...}, дальше этого же хоста оно не уйдет — пакеты по сети туда не будут ходить. Да до него собственно и не дойдет это все уже — потому что внешние данные из дикой природы скорее всего будут уже санированы до попадания сюда, а даже если не будут — см. п.1
Вот для меня это настолько обычно и привычно, что прямо удивляет — а что, кто-то делает не так? А зачем? Из лени, по дурости, или есть еще какие-то причины?
По неопытности ещё может быть. Но и лень с дуростью тоже весьма распространены.
идеальный мир далеко не так идеален.
Зловреду нет необходимости выходить в интернет. Если он может все что угодно на твоём хосте - это большая проблема, например зашифровать твои данные.
Ну то есть, в общем случае вы правы конечно. Просто это уже другая история.
Просто вы говорите про джава вэб. Но эта уязвимость отлично работает и для стандалоун джава - например, было продемонстрировано, как выполняется код машине пользователя, у которого запущен Майнкрафт. Я как человек, который пострадал от ransomware - скажу, что это не очень приятно. А так вы правы - если в сети нет доступов наружу, то нет и проблемы.
Я так говорю просто потому что это самый типовой и понятный сценарий, описанные атаки. Там ясно, откуда могут появиться данные, которые запишутся в лог. Но там же и понятно, как закрыть дырку. Файрволом, например — потому что нашему веб приложению нечего делать на каком-то там IP адресе в интернете.
В случае же прочих вариантов пока все достаточно мутно.
Причем, этот вариант работает для всех версий log4j, по крайней мере теоретически.
А потом вы натыкаетесь на проект где какой-то добрый человек сделал shade+relocate для org.apache.logging..
Против лома нет приема. Хотя в целом агент — это пожалуй единственный вариант, который хотя бы может такое поискать.
Log4Shell/Leak4J — чрезвычайно опасная уязвимость в log4j2