Перейти к содержанию

Log4Shell: критическая уязвимость в библиотеке Apache Log4j | Блог Касперского


Рекомендуемые сообщения

В интернете появились новости о критической уязвимости CVE-2021-44228 в библиотеке Apache Log4j (уровень опасности 10 из 10 по шкале CVSS). Эта библиотека используется миллионами Java-приложений для регистрации сообщений об ошибках. Что еще хуже, злоумышленники уже активно используют эту уязвимость в атаках. Поэтому Apache Foundation рекомендует всем разработчикам обновить библиотеку до версии 2.15.0, а если это невозможно, воспользоваться одним из методов, описанных на странице Apache Log4j Security Vulnerabilities.

Чем опасна уязвимость CVE-2021-44228

Уязвимость CVE-2021-44228, также получившая названия Log4Shell и LogJam, относится к классу Remote Code Execution. Если злоумышленникам удастся проэксплуатировать ее на одном из компьютеров, то они смогут исполнять на нем произвольный код. Потенциально это позволит им захватить полный контроль над системой.

Что делает CVE-2021-44228 особенно опасной — это простота эксплуатации: успешную атаку через эту уязвимость может осуществить даже неопытный хакер. По словам исследователей, злоумышленникам достаточно заставить приложение записать в лог всего одну строку, в результате чего им удастся подгрузить в приложение собственный код из-за функции message lookup substitution.

В Интернете уже можно найти рабочие доказательства осуществимости (PoC) атак при помощи CVE-2021-44228. Поэтому неудивительно, что различные компании, работающие в сфере кибербезопасности, уже регистрируют массовое сканирование сети в поисках уязвимых приложений, а также атаки на ханипоты.

Обнаружена уязвимость исследователем Ченом Жаожуном (Chen Zhaojun) из Alibaba Cloud Security Team.

 

View the full article

Ссылка на сообщение
Поделиться на другие сайты
Quote

и как защитить серверы от атак?

Господи божечки, ну и рекомендация. Если речь про сервер, то действия выполняет не разработчик, а пользователь ПО, например админ. Он не может скачать новую версию "на страничке проекта". То есть скачать то может, но потом ему её себе в одно место вставить можно, больше ни на что это не годится. Устранять уязвимость должны авторы ПО, которые используют эту либу.

 

То есть последовательность действий такая:

1. Авторы ПО обновляют либу на новую версию

2. Выкладывают обновления

3. Потребители ПО подтягивают новую версию

 

А теперь какая последовательность действий  на самом деле:

1. Авторы ПО никогда ничего не обновят, потому что:

1.1. Кто-то уже просто умер

1.2. Кто-то забил на развитие этого ПО

1.3. Кто-то не может себе позволить такую роскошь, как обновление на нестабильные версии. Ведь релиз вышел меньше суток назад: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.15.0 (до этого были релиз кандидаты). Классно звучит - затаскивать либу, которая не прошла полный цикл тестирования и может разломать работу продукта. Сначала подождите, когда выйдет пару патчей на либу (её наспех делали). Затем ждите пару недель минимум, пока QA прогонят тесты ПО, в которую, наконец, затянут фикс. А потом ещё месяц-два, потому что будут найдены проблемы и их надо устранить

2. Админы до последнего не будут ставить апдейты ПО, потому что:

2.1. Они не знают, где используется эта либа

2.1.1. А ещё какой она вообще версии в тех ПО, в которых всё-таки используется

2.2. Боятся, что обновление ПО на серваке приведёт к выводу его из строя, потому что "работает - не трогай". Сюда же вот такое: обновление ПО занимает время и сервер будет недоступен к нормальному использованию, что означает остановку некоторых техпроцессов

2.3. Ждут инструмент, который бы им сказал, какое же ПО уязвимо, чтобы решить, можно ли его безболезненно обновить или же обновление будет запланировано на длинные выходные, если это возможно

 

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

Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Похожий контент

    • KL FC Bot
      От KL FC Bot
      В сентябре 2022 года компания Trellix опубликовала отчет об уязвимости в модуле tarfile. Это стандартная библиотека языка программирования Python, воспользоваться которой может любой желающий. Уязвимость позволяет записать в произвольную папку на жестком диске произвольный файл, а в некоторых случаях может приводить к выполнению вредоносного кода. Особенность данного исследования заключается в том, что проблема в Tarfile была обнаружена в августе 2007 года, почти ровно 15 лет назад! Но тогда ее не посчитали опасной. Давайте разберемся, почему так вышло и с какими проблемами в результате могут столкнуться разработчики софта на Python и пользователи этих программ.
      Tarfile в деталях
      Tarfile содержит код для работы с архивами формата tar. Этот формат широко используется в Unix-подобных операционных системах, а его история началась очень давно — в 1979 году. Tar — это простой способ упаковать большое количество файлов и папок. Изначально данная функциональность требовалась для удобной записи резервных копий на магнитную ленту. Теперь же в архивах tar может применяться и сжатие файлов, хотя это не обязательно. Модуль tarfile отвечает за создание и распаковку таких архивов, он используется разработчиками программ на языке Python как готовый инструмент для подобных задач.
      Уязвимость в tarfile достаточно простая, она исчерпывающе описана в оригинальном багрепорте за август 2007 года. Это даже не совсем уязвимость: просто tarfile в точности воссоздает структуру папок, содержащуюся в архиве, при его распаковке. В том числе если имя файла в архиве представляет собой что-то вроде «../../../../../etc/passwd». Если распаковать такой архив от имени администратора системы, файл passwd запишется вовсе не в директорию, в которой расположен сам архив. Отрабатывая указатели «..», распаковщик сначала дойдет до корневой директории, а потом перезапишет файл passwd в директории etc. В Linux это будет означать стирание штатного файла с данными всех пользователей системы.
       
      View the full article
    • KL FC Bot
      От KL FC Bot
      Помните знаменитую поговорку капитана Врунгеля? «Как вы яхту назовёте, так она и поплывёт». Даже сейчас, проходя мимо какого-нибудь яхт-клуба, можно изрядно повеселиться, читая имена некоторых плавсредств.
      И всё же с именем для яхты определиться легче, чем с названием продукта в сфере ИБ. Ведь яхта – объект с очевидным функционалом. Даже дети знают, что делает яхта. А сколько всего делает современная система кибер-защиты и чем одна отличается от другой? Тут даже целым абзацем не объяснишь, а уж одним названием – тем более.
      Наверное, именно поэтому наша компания до сих пор ассоциируется у многих с антивирусом. На самом деле, ловля зловредов на основе антивирусных баз – лишь одна из наших технологий безопасности, за 25 лет мы придумали много других. Просто слово «антивирус» даёт очень понятную метафору, оттого и держится в памяти народной.
      Но что делать, если хочется рассказать про сложную многофункциональную защиту для корпоративных IT-инфраструктур? Здесь мы неизбежно попадаем в мир странных слов из трёх букв (иногда из четырёх). Аббревиатуры с каждым годом множатся, удержать в голове все расшифровки становится всё сложней. Давайте же устроим небольшую экскурсию по этим магическим ИБ-заклинаниям.
      От EPP до XDR
      Начнём с той яхты, которую многие до сих пор зовут «антивирусом». Более точное название этого класса продуктов – «защита рабочих станций» или «безопасность конечных точек» (Endpoint Protection, Endpoint Security). Ведь как сказано выше, не один только антивирус стоит на защите рабочей станции. Иногда это разнообразие технологий даже называют «платформой»: так и звучит солиднее, и модное слово из трёх букв получается – EPP (Endpoint Protection Platform).
      Однако это пока история про безопасность отдельных машин. По сути, концепция из 90-х. Для защиты распределённой инфраструктуры понадобятся дополнительные методы. Надо собирать данные со всей сети и анализировать их так, чтобы выявлять не только отдельные инциденты, но и целые цепочки атак, которые не ограничиваются одной рабочей станцией. Да и реагировать на угрозы нужно тоже на уровне всей сети, а не только на одном компьютере.
      В начале 2000-х появляется класс продуктов SIEM. Буквально – система управления информацией и событиями безопасности. То есть инструмент для сбора и анализа всей ИБ-телеметрии от различных устройств и приложений. И не только за сегодняшний день: хорошая SIEM позволяет делать ретроспективный анализ, сопоставляя события из прошлого и выявляя атаки, которые растянуты во времени на многие месяцы или даже годы.
      Итак, мы уже работаем с целой сетью. Вот только в аббревиатуре SIEM нет «защиты». Защиту делают продукты EPP, но они не видят сетевые явления – например, легко могут пропустить затяжную многоступенчатую атаку (APT).
       
      View the full article
    • KL FC Bot
      От KL FC Bot
      Мы наблюдаем новую кампанию по массовой рассылке вредоносных писем по сотрудникам компаний с приложенным шпионским зловредом Agent Tesla. От множества аналогов эту рассылку отличает неожиданный уровень внимания злоумышленников к деталям — на этот раз послание злоумышленников действительно можно принять за реальное деловое письмо с приложенными документами. Цель — заставить получателя открыть приложение и запустить вредоносный файл.
      Особенности вредоносной почтовой рассылки
      Начнем с того, что злоумышленники как прикрытия используют реально существующие компании, снабжая свои письма реальными логотипами и легитимно выглядящими подписями. Английский язык в письмах не идеален, но, чтобы этот факт не смущал получателя, в качестве фирмы-отправителя обычно выбирают резидентов каких-то не англоговорящих стран — то Болгарии, то Малайзии.
      Злоумышленники рассылают свой архив от имени множества компаний, меняя при этом и текст. То они запрашивают у сотрудников различных организаций цены на товары, перечисленные в приложенном архиве, то пытаются узнать, есть ли перечисленный товар в наличии, но, скорее всего, мы не видели все варианты «наживок». Главное — убедить жертву посмотреть, что за товары интересуют этого псевдоклиента. То есть авторы рассылки уделили достаточно много внимания подготовке, что нехарактерно для таких массовых кампаний — в прошлом подобные приемы чаще встречались в целевых атаках.
      Пример письма злоумышленников с запросом цен и архивом с Agent Tesla
       
      View the full article
    • KL FC Bot
      От KL FC Bot
      В официальном магазине Google Play нередко под видом безобидных приложений прячутся всевозможные зловреды. К сожалению, даже многочисленные проверки площадки не всегда могут отследить их до публикации. Одна из самых популярных разновидностей таких зловредов — трояны-подписчики, которые скрытно от пользователя оформляют от его имени подписки на платные услуги. Мы уже писали о наиболее распространенных семействах таких троянов. В этом посте расскажем еще об одном. За схожесть и, вероятно, общие корни с уже известным Joсker это семейство получило название Harly (созвучно тому, как зовут соратницу знаменитого злодея из комиксов).
      Немного о троянах Harly
      С 2020 года в Google Play было обнаружено более 190 приложений, зараженных Harly. Судя по нижней границе данных по количеству скачиваний приложения в магазине, суммарно его установили более 4,8 миллиона раз. При этом реальное число скачиваний может быть намного больше.
      Примеры приложений, содержащих зловред, в Google Play
       
      View the full article
    • KL FC Bot
      От KL FC Bot
      Мы давно заметили, что многие сказки на самом деле являются завуалированными отчетами о киберинцидентах или рассказами о технологиях информационной безопасности. Судя по всему, старинные сказители пытались заложить у потомков правильные подходы к защите информации с древнейших времен. Особенно интересно с этой точки зрения смотреть на народные сказания — в них изначальные сюжеты лучше всего описывают работу безопасников прошлого, без лишних художественных приемов и приукрашиваний, свойственных авторским сказкам.
      К сожалению, хакасские сказки дошли до меня в несколько искаженном виде — во-первых, мне они доступны только в переводе, а во-вторых, в переводе, изданном в советские времена, когда было принято акцентировать внимание читателя на вопросах классовой борьбы. Но несмотря на это, в них все еще можно обнаружить описания интересных происшествий и вычитать полезные советы по кибербезопасности!
      Вот несколько хакасских сказок, которые практически прямым текстом объясняют суть некоторых киберугроз и рассказывают, как им противостоять.
      Как мальчик заставил Смерть на себя работать
      Вот сюжет хакасской сказки «Как мальчик заставил Смерть на себя работать»: молодой человек, странствующий в поисках правды, встречает Смерть в образе дряхлого старика с волчьими зубами. Смерть регулярно ходит к богам, чтобы узнать, кого ему следует съесть следующим. Мальчик вызывается помочь старику и сам бегает к богам по железной лестнице на небо. Но ему каждый раз становится жалко скармливать Смерти реальные цели, поэтому он подменяет ответ — то посылает его три года грызть древесную кору, то жевать водоросли.
      Совершенно очевидно, что древние авторы этой сказки постарались объяснить потомкам концепцию атаки MitM (Man-in-the-middle): в то время как Смерть считает, что работает напрямую с сервером богов, в реальности в обмен информацией вмешивается мальчик. Богам он доставляет реальный запрос, а вот в ответе подменяет адрес цели.
      Судя по всему, изначально сказка рассказывала о том, как некий древнехакасский специалист по информационной безопасности пытался обезвредить инструмент для атак типа «отказ в обслуживании» (DoS). Не в силах справиться с источником атаки, он делает все возможное для того, чтобы минимизировать ущерб.
       
      View the full article
×
×
  • Создать...