Архив рубрики: Темы

Про уязвимость Spoofing - Microsoft Exchange (CVE-2024-49040)

Про уязвимость Spoofing - Microsoft Exchange (CVE-2024-49040)

Про уязвимость Spoofing - Microsoft Exchange (CVE-2024-49040). Уязвимость из ноябрьского Microsoft Patch Tuesday. Некорректно сформулированная политика обработки хедера P2 FROM позволяет злоумышленнику сделать так, чтобы его email-адрес выглядел легитимным для жертвы (например, как адрес коллеги по работе). Что, естественно, значительно повышает эффективность фишинговых атак. 😏🪝 Уязвимости подвержены Exchange Server 2019 и Exchange Server 2016.

Первоначальные исправления для этой уязвимости, опубликованные 12 ноября, были через 2 дня отозваны. Их установка приводила к сбоям. Новые исправления были опубликованы Microsoft только 27 ноября.

👾 Kaspersky уже наблюдали попытки эксплуатации этой уязвимости. Об этом они написали в блогпосте от 26 ноября.

Отмодерировал сегодня секцию "Анализ защищённости и расследование инцидентов" на Код ИБ Итоги 2024

Отмодерировал сегодня секцию Анализ защищённости и расследование инцидентов на Код ИБ Итоги 2024

Отмодерировал сегодня секцию "Анализ защищённости и расследование инцидентов" на Код ИБ Итоги 2024. И выступил там же. 🙂 Осознал, что модерировать секцию гораздо сложнее, чем выступать в ней. Особенно, когда там не только общение по заготовленному списку вопросов, но и доклады. Когда просто участвуешь в секции с докладом, то выступил и сидишь-кайфуешь, изредка задавая вопросы и отвечая на них. А модератор до конца секции в напряжении. 😬 Нужно и дискуссию направлять, и аудитории давать высказаться, и следить за временем, чтобы его на все выступления хватило. ⌚️🤹 Большое спасибо организаторам, что заранее порезали время на слоты, а участникам за пунктуальность! 👍 По времени вписались идеально. 😇

🔹 В своём докладе я сделал экспресс-обзор текущего списка трендовых уязвимостей 2024 года. Скоро будет расширенная версия. 😉
🔹 Основной факт секции: 47% инцидентов ИБ связаны с необновлёнными активами.
🔹 Большой отклик получили темы про атаки через подрядчиков и инсайдеров. 🙂

Должен ли VM-щик в задаче на устранение уязвимости указывать конкретный патч, который нужно установить на хосте?

Должен ли VM-щик в задаче на устранение уязвимости указывать конкретный патч, который нужно установить на хосте?

Должен ли VM-щик в задаче на устранение уязвимости указывать конкретный патч, который нужно установить на хосте? Я думаю так:

🔻 Eсли есть простой способ отдавать такую информацию в IT, то нужно это делать. Например, если такие рекомендации выдаёт сканер уязвимостей.

🔻 Если же это требует трудоёмкого ресёрча, то заниматься этим не следует. Иначе это превратится в очередное "докажи-покажи". И вместо построения VM-процесса для повышения безопасности всей организации вы будете выяснять какая уязвимость какой KB-шкой закрывается. Такое себе. 😏

Важно не забывать, что если уязвимость детектируется на хосте, то это уже косяк IT. В идеале всё должно фикситься в рамках процесса безусловного регулярного патчинга. А сканы на уязвимости должны лишь подтверждать, что всё действительно регулярно обновляется. 🟢👍 Если IT внедрять такой процесс не готовы, то пусть возятся с исправлением конкретных продетектированных уязвимостей, включая поиск нужных патчей. 😉

Про уязвимость Elevation of Privilege - Windows Task Scheduler (CVE-2024-49039)

Про уязвимость Elevation of Privilege - Windows Task Scheduler (CVE-2024-49039)

Про уязвимость Elevation of Privilege - Windows Task Scheduler (CVE-2024-49039). Уязвимость из ноябрьского Microsoft Patch Tuesday. Для неё сразу были признаки эксплуатации вживую. Для эксплуатации уязвимости, аутентифицированный злоумышленник запускает на целевой системе специальное приложение. Атака может быть произведена из AppContainer - ограниченной среды, в которой приложения получают доступ только к специально предоставленным ресурсам. Однако, с помощью этой уязвимости, злоумышленник может поднять свои права до уровня Medium Integrity и получить возможность выполнять функции RPC, доступные только привилегированным учётным записям.

ESET сообщают, что с помощью этой уязвимости злоумышленники из RomCom исполняли зловредный код вне песочницы Firefox, а затем запускали скрытые PowerShell процессы для скачивания и запуска зловредного ПО с C&C серверов.

👾 На GitHub есть код бэкдора, эксплуатирующего эту уязвимость.

В следующий вторник Securitm проводит вебинар по выстраиванию вендоро-независимого Vulnerability Management процесса

В следующий вторник Securitm проводит вебинар по выстраиванию вендоро-независимого Vulnerability Management процесса

В следующий вторник Securitm проводит вебинар по выстраиванию вендоро-независимого Vulnerability Management процесса. Начало в 11:00. Собираюсь посмотреть и покомментировать. Судя по описанию, будут говорить про многосканерность:

"Какой выбрать сканер - подороже или сэкономить, нужно использовать один сканер или несколько?"

Мне кажется ответ на этот вопрос неразрывно связан с темой эффективной оценки реализованных в сканере методов детектирования уязвимостей. Очень интересно как коллеги из Securitm эту тему будут раскрывать.

Ещё один интересный для меня вопрос:

"Нужно ли разносить в отдельные процессы управление уязвимостями инфраструктуры, периметра, облачных сред и приложений компании?"

Тут у меня нет однозначного ответа. Я обычно говорю, что это сильно зависит от конкретной организации. Возможно коллеги смогут доказать, что всё это хорошо уживается в рамках единого процесса автоматизированного с помощью Securitm. Посмотрим. 😉

➡️ 10.12.24 11:00 Регистрация

Про уязвимость Elevation of Privilege - needrestart (CVE-2024-48990)

Про уязвимость Elevation of Privilege - needrestart (CVE-2024-48990)

Про уязвимость Elevation of Privilege - needrestart (CVE-2024-48990). 19 ноября Qualys выпустили бюллетень безопасности про 5 уязвимостей повышения привилегий в утилите needrestart (CVE-2024-48990, CVE-2024-48991, CVE-2024-48992, CVE-2024-10224 и CVE-2024-11003), используемой по умолчанию в Ubuntu Server, начиная с версии 21.04.

Утилита needrestart запускается автоматически после операций пакетного менеджера APT, таких как установка, обновление или удаление пакетов. Она определяет требуется ли перезагрузка для системы или ее служб. Таким образом гарантируется, что службы используют последние версии библиотек, без снижения аптайма.

Все 5 уязвимостей позволяют обычному пользователю стать root-ом. Для всех у Qualys есть приватные эксплоиты. Публичный эксплоит есть пока только для одной, связанной с переменной окружения PYTHONPATH. ⚡️ Он доступен на Github с 20 ноября.

Обновляйте needrestart до версии 3.8 или отключайте "interpreter scanning" в needrestart.conf.

5 моментов про отечественные Linux-дистрибутивы

5 моментов про отечественные Linux-дистрибутивы

5 моментов про отечественные Linux-дистрибутивы. Каждый раз, когда появляется новость про российский Linux-дистрибутив в комментарии приходят хейтеры с криками "Bolgenos!". Типа это ненастоящий дистрибутив. Вот есть какие-то настоящие, а этот нет. Имею сказать следующее:

1. Даже тот самый мемный BolgenOS Дениса Попова по прошествии лет выглядит как вещь, которая вполне имела право на существование в качестве учебного проекта несколько странноватого, но вполне безобидного 16летнего парня. 🤷‍♂️ Ну сделал он сборку Ubuntu с нескучными обоями и переименованными приложениями (где-то вроде даже копирайты затер 😱). Ну сняли про него дурацкий репортаж на региональном ТВ. Это был повод для травли, вот серьёзно?

2. Если какие-то люди собрали очередной Linux-дистрибутив, допустим, на основе Debian, используют его сами и собираются его кому-то продавать, то они в своём праве. Даже если они (о ужас!) не собирают сами пакеты, а продают ванильный Debian с налепленным своим логотипом. Вот даже тогда. Насколько мне известно, ничто сейчас не запрещает это делать. Ни российское законодательство, ни требования регуляторов, ни даже опенсурсные лицензии.

3. Если с этим Linux-дистрибутивом можно комфортно и относительно безопасно (в смысле оперативного исправления уязвимостей, отсутствия явных закладок, обновления с российских серверов) работать, то в общем-то и норм. Если вдруг почему-то нельзя, то это хорошая тема для предметного обсуждения. Ну ещё неплохо бы бюллетени безопасности в формате OVAL, чтобы уязвимости было удобно детектировать. 😇

4. Если маркетинг компании, которая выпустила Linux-дистрибутив, позволяет себе в официальной коммуникации писать, что это какая-то уникальная отечественная ОС, разработанная с нуля, то это, имхо, скверно и достойно порицания. Но на сам дистрибутив это никак не влияет.

5. Я не верю в какие-то прям "хорошие Linux-дистрибутивы". Это ВСЕГДА переупакованный ЧУЖОЙ код от апстримов. В этом отношении прилетела ли ко мне программная закладка непосредственно от разработчика (например, XZ Utils или самого Торвальдса) или от Debian-ов мне, как потребителю, как-то пофигу. В возможности всерьёз контролировать апстрим я не верю. Если вы так здорово закладки можете выявлять, почему вы тогда Linux-овые уязвимости не выявляете? Сотни Linux-овых уязвимостей исправляются каждый месяц, что же вы их не выявляете сами раньше разработчиков? 😏 Использование Linux и опенсурсного софта это всегда некоторый компромисс функциональных возможностей и безопасности. Лучше бы, конечно, своё ядро. Лучше бы, конечно, чтобы и системные компоненты свои. И прикладной софт свой. А раз этого всего нет и не ожидается, то и чего щёки надувать, что вы принципиально лучше тех самых "болгеносов"? 😏