-
Похожий контент
-
От KL FC Bot
Среди уязвимостей, на которые компания Microsoft обратила внимание последним вторничным патчем от 12 ноября, была CVE-2024-49040 в Exchange. Ее эксплуатация позволяет атакующему создавать письма, которые в интерфейсе жертвы будут отображаться с вполне легитимным адресом отправителя. Казалось бы, уязвимость была исправлена, но, как выяснилось, уже 14 ноября Microsoft временно приостановила распространение апдейта для Exchange. Тем временем мы уже наблюдали попытки эксплуатации этой уязвимости. Пока случаи единичные, похожие на проверку работоспособности эксплойта. Поэтому мы в отделе развития методов фильтрации контента «Лаборатории Касперского» добавили во все решения для защиты электронной почты механизм, выявляющий попытки использования CVE-2024-49040 для спуфинга.
В чем проблема уязвимости CVE-2024-49040
CVE-2024-49040 — это уязвимость с CVSS-рейтингом 7,5 актуальная для Exchange Server 2019 и Exchange Server 2016, классифицируемая как «важная». Суть ее заключается в некорректно сформулированной политике обработки хедера P2 FROM. Благодаря ей злоумышленник может задать это поле таким образом, что в нем, по сути, будет указано два электронных адреса: один реальный, который требуется скрыть от жертвы, а другой — легитимный, который, наоборот, жертве требуется показать. В результате Microsoft Exchange корректно проверит адрес отправителя, но получателю покажет совершенно другой адрес, который не будет вызывать у пользователя никаких подозрений (например, внутренний адрес сотрудника той же компании).
Патчем от 12 ноября Microsoft добавила новую функцию, которая выявляет хедеры P2 FROM, не соответствующие стандарту интернет-сообщений RFC 5322, что должно было исправить ситуацию. Однако, согласно посту в блоге Microsoft, у некоторых пользователей начались проблемы с правилами потока обработки почты, которые иногда переставали работать после переустановки обновления. Поэтому раздача обновления была приостановлена и будет возобновлена после доработки.
View the full article
-
От KL FC Bot
Наши эксперты из Global Research and Analysis Team (GReAT) обнаружили два вредоносных пакета в The Python Package Index (PyPI), популярном репозитории софта для программирования на Python. Согласно описанию, пакеты представляли собой библиотеки для работы с популярными языковыми моделями. Однако, на самом деле они имитировали заявленную функциональность при помощи демоверсии ChatGPT, а основной их целью была установка зловреда JarkaStealer.
Пакеты были доступны для скачивания больше года и, судя по статистике репозитория, за это время они были скачаны более 1700 раз пользователями из более чем 30 стран.
Что за пакеты и для чего они использовались
Вредоносные пакеты были загружены в репозиторий одним автором и отличались друг от друга только названием и описанием. Первый назывался gptplus и якобы позволял реализовать доступ к API GPT-4 Turbo от OpenAI; второй — claudeai-eng и, согласно описанию, по аналогии обещал доступ к API Claude AI от компании Anthropic PBC.
В описаниях обоих пакетов были примеры использования, которые объясняли, как создавать чаты и посылать сообщения языковым моделям. Но в действительности операторы этой атаки встроили в код механизм взаимодействия с демо-прокси ChatGPT, чтобы убедить жертву в работоспособности пакета. А содержавшийся, тем временем, в пакетах файл __init__.py декодировал содержавшиеся внутри данные и скачивал из репозитория на GitHub файл JavaUpdater.jar. Если на машине жертвы не обнаруживалась Java, то он также скачивал и устанавливал среду выполнения для Java (JRE) из Dropbox. Сам jar-файл содержал зловред JarkaStealer, который использовался злоумышленниками для компрометации среды разработки и незаметной эксфильтрации похищенных данных.
View the full article
-
От KL FC Bot
Плохие новости для компаний, использующих сайты на базе WordPress с механизмом двухфакторной аутентификации, реализованным через плагин Really Simple Security. Недавно обнаруженная в этом плагине уязвимость CVE-2024-10924 позволяет постороннему человеку аутентифицироваться на сайте под видом легитимного пользователя. Поэтому плагин рекомендуется обновить как можно быстрее.
Чем опасна уязвимость CVE-2024-10924
Как бы иронично это ни звучало, но уязвимость CVE-2024-10924 в плагине с названием Really Simple Security имеет CVSS-рейтинг 9.8 и классифицируется как критическая. По сути это ошибка в механизме аутентификации, из-за которой атакующий может залогиниться на сайте как любой из зарегистрированных на нем пользователей, с полными его правами (даже админскими). В результате это может привести к перехвату контроля над сайтом.
На GitHub уже появились доказательства возможности эксплуатации этой уязвимости. Более того, судя по всему, ее применение можно автоматизировать. Исследователи из Wordfence, обнаружившие CVE-2024-10924, назвали ее самой опасной уязвимостью, обнаруженной ими за 12 лет работы в сфере безопасности WordPress.
View the full article
-
От KL FC Bot
В ноябрьском вторничном обновлении Microsoft исправила 89 уязвимостей в своих продуктах, причем две из них активно эксплуатируются. Особый интерес вызывает одна из них, CVE-2024-43451, позволяющая атакующим получить доступ к NTLMv2-хешу жертвы. Казалось бы, она имеет не особенно пугающий рейтинг по шкале CVSS 3.1 — 6,5 / 6,0. Однако при этом ее эксплуатация требует минимального взаимодействия от пользователя, а существует она благодаря движку MSHTML, наследию Internet Explorer, который теоретически отключен, деактивирован и больше не используется. Но при этом уязвимости подвержены все актуальные версии Windows.
Чем опасна уязвимость CVE-2024-43451
CVE-2024-43451 позволяет злоумышленнику создать файл, который, попав на компьютер жертвы, позволит атакующему украсть NTLMv2-хеш. NTLMv2 — это протокол сетевой аутентификации, который используется в средах Microsoft Windows. Получив доступ к NTLMv2-хешу, злоумышленник может провернуть атаку типа pass-the-hash и попытаться аутентифицироваться в сети, выдав себя за легитимного пользователя, но не имея при этом его реальных учетных данных.
Разумеется, для этого недостаточно одной CVE-2024-43451 — для полноценной атаки ему придется воспользоваться дополнительными уязвимостями, но чужой NTLMv2-хеш изрядно облегчит жизнь атакующего. На данный момент дополнительных сведений об атаках, в которых CVE-2024-43451 применяется на практике, у нас нет, но в описании уязвимости четко говорится, что уязвимость публична, эксплуатируема и попытки эксплуатации выявлены.
View the full article
-
От KL FC Bot
В какой-то момент ИБ-департамент крупной компании неизбежно задумывается о внедрении или замене SIEM-системы и сталкивается с задачей оценки бюджета, необходимого для ее внедрения. Но SIEM — это не легковесный продукт, который можно развернуть в имеющейся инфраструктуре. Практически все решения этого класса требуют дополнительного оборудования, так что для их работы придется приобретать аппаратное обеспечение (или арендовать его).
Поэтому для расчетов бюджета необходимо представлять себе предполагаемую конфигурацию оборудования. В этом посте мы попробуем рассказать о том, как архитектура SIEM влияет на требования к аппаратной составляющей, а также предоставим примерные параметры, на которые стоит ориентироваться, чтобы определить предварительную стоимость необходимого оборудования.
Оценка потока информации
По своей сути SIEM-система собирает данные о событиях с источников и на основании корреляции этих данных выявляет угрозы для безопасности. Поэтому, прежде чем прикидывать, какое железо необходимо для работы системы, стоит оценить, а какой, собственно, объем информации эта система будет обрабатывать и хранить. Для того чтобы понять, какие источники потребуются, следует выделить наиболее критичные риски и определить источники данных, анализ которых поможет в выявлении и анализе угроз, связанных с этими рисками. Такая оценка нужна не только для расчета необходимого аппаратного обеспечения, но и для оценки стоимости лицензии. Например, стоимость лицензии на нашу систему KUMA (Kaspersky Unified Monitoring and Analysis Platform) напрямую зависит от количества событий в секунду (Events Per Second, EPS). И еще один важный аспект — при выборе SIEM-системы важно проверить, как именно вендор считает количество событий для лицензирования. Мы, например, учитываем количество EPS после фильтрации и агрегации, причем мы считаем среднее количество событий за последние 24 часа, а не их пиковые значения, но так поступают далеко не все.
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти