Как защититься от уязвимости Log4Shell

В популярной библиотеке жур­налиро­вания Log4j, которая является частью общего проекта «Apache Logging Project», обнаружили критическую уяз­вимость Log4Shell. В этой статье я расскажу, как защититься от уязвимости Log4Shell.

Еще по теме: Способы эксплуатации уязвимости Log4j

Уязвимость Log4Shell

В декаб­ре 2021 года программисты Apache Software Foundation выкатили экс­трен­ное обновле­ние безопас­ности, исправ­ляющее критическую уяз­вимость (CVE-2021-44228) в биб­лиоте­ке жур­налиро­вания Log4j. Сроч­ность выпуска обновления объ­ясня­лась тем, что хакеры уже начали выкладывать в откры­тый дос­туп PoC-экс­пло­иты, объ­ясняя, что эксплуатировать уязвимость мож­но уда­лен­но, при­чем для это­го не нужны осо­бые знания и тех­ничес­кие навыки.

Уязвимость получила наз­вание Log4Shell и по шкале оценки уязвимостей наб­рала десять из десяти воз­можных балов. Баг Log4Shell позволяет уда­лен­ное выпол­нение про­изволь­ного кода (RCE), при­чем вре­донос может попасть в сис­тему раз­личными спо­соба­ми, ведь для реализации ата­ки дос­таточ­но, что­бы необходимая запись ока­залась в логах.

Изначально уязвимость была обна­руже­на при поиске багов на сер­верах Minecraft, но биб­лиоте­ка Log4j при­сутс­тву­ет прак­тичес­ки во всех кор­поратив­ных при­ложе­ниях и серверах Java. Она присутствует в каждом корпоративном про­дук­те, выпущен­ным Apache Software Foundation, вклю­чая:

• Apache Flink
• Apache Flume
• Apache Struts
• Apache Druid
• Apache Solr
• Apache Dubbo
• Apache Kafka

Так­же Log4j часто используют в про­ектах с открытым исходным кодом, в таких как: Redis, Ghidra, Elasticsearch, Elastic Logstash.

Получается, что, ком­пании, исполь­зующие какой-нибудь из перечисленных выше про­дук­тов, могут быть косвенно уяз­вимы перед подобного рода ата­кой, не имея об этом представления. Специалисты ИБ предупреждают, что уязвимости Log4Shell могут быть подвержены такие гиганты как: Amazaon Apple, Twitter, Steam, Cloudflare, Baidu и т.д.

Прин­цип работы уязвимости Log4Shell очень простой: баг вынуж­дает при­ложе­ния и сер­веры работающие на Java, где исполь­зует­ся Log4j, сох­ранять в логе специальную стро­ку. Ког­да сервер или при­ложе­ние обра­ботают лог, стро­ка зас­тавит сис­тему скачать и выполнить вре­донос­ный скрипт залитый на какой-нибудь сайт. Это может привести к полному зах­вату уяз­вимого сервера или при­ложе­ния, со всеми вытекающими.

К боль­шому сожале­нию, из‑за пов­семес­тной рас­простра­нен­ности Log4j ИБ‑экспер­ты уве­рены, что проб­лема Log4Shell име­ет все шан­сы стать не прос­то худ­шей уяз­вимостью 2021 года, но и самой боль­шой голов­ной болью пос­ледней пятилет­ки.

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

Защита от уязвимости Log4Shell

Луч­ший вари­ант, разуме­ется, — обно­вить Log4j до пос­ледней акту­аль­ной вер­сии: на дан­ный момент это вер­сия 2.16. Для удобс­тва адми­нис­тра­торов спе­циалис­ты из ком­пании Huntress Labs под­готови­ли бес­плат­ный ска­нер (ссылка удалена про причине удаления сайта), который ком­пании могут исполь­зовать для оцен­ки сво­их собс­твен­ных сис­тем на уяз­вимость.

Эк­спер­ты ком­пании Cybereason и вов­се пред­ложили «вак­цину» от Log4Shell, получив­шую наз­вание Logout4Shell. «Вак­цина» пред­став­ляет собой скрипт, уда­лен­но экс­плу­ати­рующий баг для отклю­чения нуж­ных нас­тро­ек в уяз­вимом экзем­пля­ре Log4Shell. По сути, пей­лоад в дан­ном слу­чае без­вре­ден и отклю­чает параметр trustURLCodebase на уда­лен­ном сер­вере для сни­жения рис­ков.

Спе­циалис­ты Cybereason объ­ясня­ют, что угро­зу мож­но смяг­чить, уста­новив для парамет­ра log4j2.formatMsgNoLookups зна­чение true или уда­лив класс JndiLookup.

Кро­ме того, если на сер­вере Java runtimes >= 8u121, то по умол­чанию уста­нов­лено зна­чение false для парамет­ров:

Это тоже поз­воля­ет сок­ратить рис­ки.

Списки уязвимых

С обна­руже­ния уязвимости Log4Shell прош­ло слиш­ком мало вре­мени, и, если учесть огромный охват проб­лемы, исчерпы­вающий спи­сок того, что уяз­вимо, а что нет, по‑преж­нему недос­тупен даже для таких пра­витель­ствен­ных агентств, как CISA.

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

Ана­лити­ки CISA так­же собира­ют из откры­тых источни­ков реак­ции и рекомен­дации про­изво­дите­лей и тоже пуб­лику­ют спи­сок извес­тных пат­чей и уяз­вимых решений на GitHub.

Еще по теме: Уязвимости в сервисах совместной разработки

Полезные ссылки:

• Гайд CISA по исправ­лению уяз­вимос­ти
• Хе­ши уяз­вимых вер­сий Log4j
• Об­разцы мал­вари и пей­лоадов, рас­простра­няющих­ся через Log4Shell
• Ин­дикато­ры ком­про­мета­ции