На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей

Добавить комментарий

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что у них лапки, и они будут обогащать ещё меньше уязвимостей

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей. Хотя, казалось бы куда уж меньше. 😏 Суть обращения, опубликованного NIST 15 апреля, в том, что из-за резкого роста числа CVE они меняют подход к ведению National Vulnerability Database: вместо анализа всех уязвимостей база переходит на риск-ориентированную модель. Полноценно обогащаться будут только приоритетные уязвимости:

🔥 уже эксплуатируемые (из каталога CISA KEV) - обещают обрабатывать за сутки
🏛️ относящиеся к ПО, используемому в госсекторе США (федеральным правительством)
🛠️ относящиеся к критическому ПО, определённому в Executive Order 14028

Остальные CVE останутся в базе, но получат низкий приоритет и будут долго оставаться без детального анализа. При этом NVD отказываются от дублирования CVSS-оценок (если CVSS пришёл от CNA, ему будут доверять, а свой CVSS рассчитывать не будут), будут реже перерабатывать записи, по которым изменилась ситуация, и фактически законсервируют накопившийся бэклог, чтобы сосредоточиться на наиболее опасных уязвимостях ценой снижения полноты и единообразия данных по остальным.

В целом, у меня такие новости вызывают сплошные фейспалмы. 🤦‍♂️ От NIST, которые, по-видимому, разогнали всех адекватных IT/ИБ-специалистов и превратились в синекуру для бюрократов, тратящих огромное финансирование непонятно на что. От CISA, которые не могут навести порядок в базовом ИБ-сервисе, критичном и для США, и для мира в целом. От американской администрации, которая тратит совершенно астрономические суммы на дикие геополитические прожекты, но совершенно не заботится о том, что происходит (разваливается) у них дома. MAGA? Лол, что? 😅

Ну а в практическом плане это означает, что если вы полагаетесь ТОЛЬКО на бесплатную NVD, то совершаете фатальную ошибку. Адекватность этой базы год от года стремительно снижается. Учитывайте альтернативные источники: Vulners, DBugs, VulnCheck, GCVE, БДУ ФСТЭК и прочие. Единственной мировой базы уязвимостей больше нет.

Ниже привожу полный перевод сообщения NIST.
Читать далее →

На сайте ФСТЭК 12 апреля выложили методический документ "Мероприятия и меры по защите информации, содержащейся в информационных системах"

Добавить комментарий

На сайте ФСТЭК 12 апреля выложили методический документ Мероприятия и меры по защите информации, содержащейся в информационных системах

На сайте ФСТЭК 12 апреля выложили методический документ "Мероприятия и меры по защите информации, содержащейся в информационных системах". Проект этого документа выкладывали в феврале.

Несколько упрощая и перефразируя п. 1.2, документ определяет как нужно защищать информацию (за исключением вопросов, связанных с криптографией):

🔹 в ИС, АСУ и сетях госорганов, ГУП, госучреждений и организаций, включая субъектов КИИ
🔹 в Тех. средствах, ПО и БД, используемых для создания и эксплуатации ГИС и иных ИС госорганов, доступ к которым предоставляется по сети
🔹 в ИТ-инфраструктурах общего назначения, обеспечивающих функционирование указанных ИС, а также обеспечивающих безопасность ЗОКИИ, принадлежащей органам (организациям)

Фактически это детализация 117-го приказа ФСТЭК и замена методического документа ФСТЭК России от 11 февраля 2014 года "Меры защиты информации в государственных информационных системах".

Документ объёмный, 255 страниц (по файлу в формате ods). Я посмотрел, в каких разделах встречается слово "уязвимости" в различных формах (звёздочками условно отметил частоту упоминания):

✳️✳️✳️✳️✳️ 3.3. Управление уязвимостями (КУ)
✳️✳️✳️✳️✳️ ЗКО.8 Выявление и устранение уязвимостей в контейнерной среде
✳️✳️✳️✳️ II. ФАКТОРЫ, ВЛИЯЮЩИЕ НА СОСТОЯНИЕ ЗАЩИТЫ ИНФОРМАЦИИ, СОДЕРЖАЩЕЙСЯ В ИНФОРМАЦИОННЫХ СИСТЕМАХ
✳️✳️✳️ 3.18. Обеспечение защиты информации при использовании искусственного интеллекта (ИИ)
✳️✳️ 3.4. Управление обновлениями (КО)
✳️✳️ 3.12. Обеспечение разработки безопасного программного обеспечения (БР)
✳️✳️ ЗИВ.4 Контроль целостности
✳️ 3.1. Выявление и оценка угроз безопасности информации (ВУ)
✳️ 3.19. Проведение периодического контроля уровня защищенности информации, содержащейся в информационных системах (ПК)
✳️ РСБ.2 Анализ событий безопасности и реагирование на них
✳️ ЗСВ.1 Доверенная загрузка средств виртуализации и виртуальных машин
✳️ ЗКО.2 Регистрация событий безопасности в контейнерных средах
✳️ ЗБД.3 Защита пользовательских данных
✳️ ЗБД.4 Контроль целостности

Ниже привожу полную структуру документа.
Читать далее →

Небольшой оффтоп про то, как я кардинально упростил себе подготовку MAX-постов

Добавить комментарий

Небольшой оффтоп про то, как я кардинально упростил себе подготовку MAX-постов

Небольшой оффтоп про то, как я кардинально упростил себе подготовку MAX-постов. Форматирование постов в MAX долгое время оставалось для меня весьма мучительной задачей. Судите сами: текстовую разметку (markdown) MAX пока не поддерживает, доступ к API для постинга пока есть только у юрлиц. Конечно, уже есть сервисы, предоставляющие услуги постинга (фактически обёртки над API), но они все какие-то мутные и просят денег буквально за каждый пост. Бесплатных ботов-конвертеров, аналогичных ТГ-шным пока нет. И чего с этим делать? Каждый раз форматировать пост ручками, используя редактор постов в приложении MAX? Ну, такое себе. Но решение, оказывается, всё время было рядом и было очень простым.

Всё началось с того, что я заметил: в веб-версии MAX форматированный текст можно копировать и вставлять без потери форматирования. 👀 А это значит, что веб-приложение MAX кладёт текст в буфер в форматированном виде. Что в свою очередь значит, что форматированный текст в таком же виде можно положить в буфер самостоятельно. 😉 Оказалось, что в Linux это можно сделать буквально вот так с помощью xclip:

cat post.html | xclip -selection clipboard -t text/html

Как-то специально заморачиваться с html не нужно. Если там используются простые теги (a, b, i, br) - всё работает. 🙂 Форматированный текст копируется в буфер и его достаточно вставить в веб-интерфейс MAX. 😇

Важно: это работает именно с веб-клиентом! Десктопный клиент хранит форматированный текст в буфере несколько иначе и там нужно больше танцев с бубном, чтобы достичь +- того же результата. Поэтому лучше работать именно с веб-клиентом.

А что если нам наоборот нужно копировать посты из MAX с сохранением форматирования? Это может быть полезно, если мы изначально пишем посты в MAX, а потом хотим выложить их куда-то ещё с сохранением форматирования. Всё аналогично. Копируем форматированный текст поста в веб-клиенте MAX и читаем буфер (в Linux) с помощью того же xclip:

xclip -selection clipboard -t text/html -o

Но есть проблема, что html-код там навороченный. Чтобы упростить его до простых тегов (a, b, i, br), я навайбкодил скриптик. В том же проекте доступны bash-обвязки, которыми я пользуюсь: HTML2MaxBuffer.sh, MaxBuffer2HTML.sh, show_all_buffers.sh.

Пользуйтесь и рекомендуйте друзьям, которым это может быть актуально.

Апрельский Microsoft Patch Tuesday

Добавить комментарий

Апрельский Microsoft Patch Tuesday

Апрельский Microsoft Patch Tuesday. Всего 167 уязвимостей, примерно в 2 раза больше, чем в марте. Есть одна уязвимость с признаком эксплуатации вживую:

🔻 Spoofing - Microsoft SharePoint Server (CVE-2026-32201). По данным экспертов ZDI, уязвимости такого рода в SharePoint часто связаны с XSS-атаками. Атакующий может просматривать часть конфиденциальных данных и изменять раскрытую информацию, но не может нарушить доступ к ресурсу. Информации о масштабе атак пока нет, но откладывать установку исправления не следует, особенно если серверы SharePoint доступны из Интернет.

Формально уязвимостей с публичными эксплоитами пока нет. Однако есть одна уязвимость с серьёзным подозрением на наличие эксплоита.

🔸 EoP - Microsoft Defender (CVE-2026-33825). Недостаточная гранулярность контроля доступа в Microsoft Defender позволяет авторизованному злоумышленнику локально повысить привилегии. По данным Tenable и ZDI, хотя Microsoft не упоминала о наличии эксплоита, по описанию уязвимость похожа на zero-day уязвимость BlueHammer, для которой 3 апреля на GitHub появился публичный эксплоит. Исследователь Chaotic Eclipse, опубликовавший эксплойт, раскритиковал процесс раскрытия уязвимостей в Microsoft. По данным ZDI, проблема реальная, но эксплуатация пока нестабильна и не всегда надёжна.

Из остальных можно выделить:

🔹 RСE - Windows Active Directory (CVE-2026-33826). Успешная эксплуатация возможна только при наличии у атакующего учётной записи. Он должен отправить специально сформированный RPC-запрос на уязвимый RPC-хост, что приводит к выполнению кода. При этом Microsoft уточняют, что атакующий должен находиться в той же ограниченной доменной среде Active Directory, что и целевая система ("same restricted Active Directory domain as the target system").

🔹 RСE - Windows Internet Key Exchange (IKE) Service Extensions (CVE-2026-33824). По данным ZDI, уязвимость относится к классу wormable, то есть может использоваться для автоматического распространения между уязвимыми системами Уязвимость затрагивает системы с включённым IKE, то есть широкий круг целей. Microsoft рекомендуют блокировать UDP-порты 500 и 4500 на периметре сети, чтобы закрыть доступ извне. Однако внутренние атакующие всё ещё могут использовать уязвимость для перемещения внутри сети. Организациям, использующим IKE, следует как можно быстрее установить исправления.

🔹 RСE - Windows TCP/IP (CVE-2026-33827). По данным ZDI, уязвимость относится к классу wormable - по крайней мере на системах с включёнными IPv6 и IPSec. Состояние гонки (race condition) делает её эксплуатацию сложной, но такие уязвимости регулярно успешно эксплуатируются на Pwn2Own, поэтому на это препятствие полагаться не стоит. Если вы используете IPv6, стоит как можно быстрее протестировать и развернуть исправление до появления публичных эксплойтов.

🔹 EoP - Windows Push Notifications (CVE-2026-26167). По данным ZDI, в этом Microsoft Patch Tuesday несколько уязвимостей, приводят к выходу из песочницы (sandbox escape), включая уязвимости Windows Push Notifications, AFD для Winsock, Management Services и User Interface Core. Из них CVE-2026-26167 (Push Notifications) является наиболее примечательной, т.к. это единственная уязвимость с низкой сложностью атаки. Остальные требуют успешного преодоления состояния гонки (race condition) (AC:H).

🔹 Spoofing - Remote Desktop (CVE-2026-26151). Недостаточное предупреждение в интерфейсе о выполнении опасных операций в Windows Remote Desktop позволяет неавторизованному атакующему осуществлять spoofing в сети. Атакующий может проэксплуатировать уязвимость, убедив жертву открыть специально сформированный файл. Обнаружение этой уязвимости приписывается National Cyber Security Centre (NCSC) Великобритании.

🗒 Полный отчёт Vulristics

Как я "поборолся с инакомыслием" и стал звездой Хабра

Добавить комментарий

Как я поборолся с инакомыслием и стал звездой Хабра

Как я "поборолся с инакомыслием" и стал звездой Хабра. На прошлой неделе, 11 апреля, мой бывший коллега пришёл в комментарии к посту в ТГ-канале avleonovlive (это просто репост из официального канала Positive Technologies) с вопросами по поводу багбаунти мессенджера MAX. Вопросы можете посмотреть на скриншоте. Почему он в мой личный чатик такие вопросы пишет, а не адресует их непосредственно баг-баунти платформе или администрации мессенджера MAX, я не понял. Какой коммент он от меня по этому поводу ждёт, я тоже не понял. Поэтому, исходя из принципа "не корми тролля", я его коммент потёр, а автора забанил. И забыл об этом. Но бывший коллега не забыл. И вот вчера он выложил целый пост на Хабре (❗️) по поводу того, что я потёр его коммент в своём тг-чатике (минуточку, на 320 человек) и забанил его там! 😄 И этот пост отчаянно лайкают! Того и гляди в трендах будет! 🤣 И кто тут ньюсмейкер, а? 🤪

Ну а к вопросу, как же могу я, "нередко выступающий модератором в дискуссиях на конференциях по кибербезу", банить странные провокационные комменты в своём личном чатике. 🤔 Да вот как-то могу. 🤷‍♂️🙂 "И можно ли трактовать эту ситуацию иначе, чем борьба с инакомыслием?" Вполне можно. Я её трактую как модерирование собственного чатика по собственному усмотрению. Потому что это мой чатик, и я сам решаю, что там уместно писать, а что нет.

Но за ссылки на каналы ему большое спасибо, подписчиков прибавилось. 🙂👍

Про уязвимость Remote Code Execution - Adobe Reader (CVE-2026-34621)

Добавить комментарий

Про уязвимость Remote Code Execution - Adobe Reader (CVE-2026-34621)

Про уязвимость Remote Code Execution - Adobe Reader (CVE-2026-34621). Adobe Acrobat Reader (с 2003 по 2015 "Adobe Reader") - это бесплатная программа от компании Adobe для просмотра PDF-файлов. Доступны версии под Windows, macOS, Android, iOS. Уязвимость удаленного выполнения кода в Adobe Acrobat для Windows и macOS вызвана неправильной обработкой атрибутов прототипа объекта (CWE-1321 - "Prototype Pollution"). Эксплуатация уязвимости позволяет злоумышленнику добиться выполнения произвольного кода на системе при открытии жертвой специально подготовленного документа.

👾 Об уязвимости и существовании эксплоита 7 апреля сообщил исследователь Haifei Li, разработчик EXPMON - системы на основе песочницы для обнаружения файловых zero-day и труднообнаруживаемых эксплоитов. 26 марта некто отправил PDF образец yummy_adobe_exploit_uwu.pdf в публичный сервис EXPMON.

Сообщалось, что по результатам анализа образец ведет себя как начальный эксплоит (initial exploit) с возможностью сбора и передачи злоумышленнику различных типов информации, потенциально с последующим выполнением произвольного кода (RCE) и эксплоитами выхода из песочницы (SBX). Он использует zero-day в Adobe Reader, которая позволяет ему вызывать привилегированные API Acrobat. Было подтверждено, что эксплоит работал на актуальной версии Acrobat. Конкретно он вызывает API "util.readFileIntoStream()", позволяющий читать произвольные файлы (доступные для изолированного процесса Reader) в локальной системе. Таким образом зловред может собирать широкий спектр информации с локальной системы и красть данные локальных файлов. Вызов API "RSS.addFeed()" используется для отправки информации, собранной с локальной системы, на удалённый сервер и получения дополнительного JavaScript-кода для выполнения. Такой механизм позволяет злоумышленнику собирать пользовательскую информацию, красть локальные данные, выполнять продвинутый "фингерпринтинг" и развивать атаку. Если цель соответствует условиям атакующего, он может доставить дополнительный эксплойт для достижения RCE или SBX. Однако во время тестов исследователю не удалось получить указанный дополнительный эксплойт - сервер был доступен, но не отвечал. Это может быть связано с различными причинами. Например, локальные тестовые окружения могли не соответствовать специфическим критериям атакующего.

8 апреля на Virus Total был обнаружен ещё один образец зловредного файла, загруженный 28 ноября 2025 года, что показывает, что эта 0day/APT кампания продолжается как минимум 4 месяца.

9 апреля исследователь Gi7w0rm сообщил о признаках эксплуатации уязвимости в реальных атаках, в которых использовались зловредные документы на русском языке с приманками, связанными с нефтегазовой отраслью России. По всей видимости в таргетированных атаках на российские организации.

13 апреля уязвимость была добавлена в CISA KEV.

⚙️ Бюллетень безопасности Adobe был опубликован 12 апреля. Уязвимы версии Acrobat DC 26.001.21367 и более ранние, Acrobat Reader DC 26.001.21367 и более ранние, Acrobat 2024 24.001.30356 и более ранние. Уязвимость исправлена в Acrobat DC 26.001.21411, Acrobat Reader DC 26.001.21411, Acrobat 2024 Windows: 24.001.30362/Mac: 24.001.30360.

Adobe рекомендует пользователям уязвимых версий обновить свои приложения через "Help > Check for Updates", что запускает автоматическое обновление. В качестве альтернативы пользователи могут загрузить установщик Acrobat Reader с официального портала Adobe.

В бюллетене отмечается, что Adobe известно об эксплуатации уязвимости CVE-2026-34621 вживую.

🛠 Публичных эксплоитов пока не наблюдается.

💡 К PDF-файлам, полученным из непроверенных или неожиданных источников, следует всегда относиться с осторожностью и открывать их в изолированных (sandboxed) средах. 😉

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver

Добавить комментарий

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver. Такой конвейер работает без участия вендоров уязвимого ПО и особенно полезен для регистрации уязвимостей в продуктах вендоров, которые по каким-то причинам совсем не инициируют регистрацию CVE или делают это со значительной задержкой (например, в случае некоторых вендоров из Китая).

Схема процесса:

🔎 Обнаружение эксплуатации: Shadowserver Foundation фиксируют, что для конкретной уязвимости наблюдается эксплуатация вживую, при этом CVE-идентификатор у уязвимости отсутствует.

🧪 Проверка информации: VulnCheck валидируют информацию и подтверждают, что для уязвимости ранее действительно не было зарегистрировано CVE.

📚 Сбор источников: собираются все релевантные публичные источники по уязвимости, включая, при наличии, патчи и репорты CERT-ов, государственных агентств и записи из альтернативных баз уязвимостей.

🆔 Публикация CVE: после подтверждения уязвимости ей присваивается CVE-идентификатор с привязкой к году первоначального раскрытия (например, CVE-2021-4473, если уязвимость была раскрыта в CNVD в 2021 году). В качестве CNA выступают сами VulnCheck.

📡 Распространение: опубликованный CVE-идентификатор передаётся обратно в Shadowserver для использования в детектировании, а также добавляется в VulnCheck KEV. Дополнительно рассылаются уведомления подписчикам по email и Slack.

VulnCheck приводят примеры заведённых по такому процессу уязвимостей:

🔻 CVE-2026-22679 - уязвимость удалённого выполнения команд без аутентификации в Weaver (Fanwei) E-cology 10.0. Первые признаки эксплуатации зафиксированы Shadowserver Foundation 31.03.2026.

🔻 CVE-2021-4473 - уязвимость внедрения команд в Tianxin Internet Behavior Management System. Первые признаки эксплуатации зафиксированы Shadowserver Foundation 01.06.2024.

Итого. В таком процессе уязвимости фиксируются и оформляются на основе наблюдаемой эксплуатации и threat intelligence без обязательного участия вендора ПО. При этом регулятор, отвечающий за ведение базы уязвимостей, не перегружается операционной работой конвейера по сбору данных и заведению новых идентификаторов. 👍

🇷🇺 В российском контексте подобный подход можно было бы использовать для ускоренного заведения уязвимостей в БДУ ФСТЭК по факту их эксплуатации без активного участия в процессе регулятора и вендоров уязвимого ПО. Но для этого нужно фактически выдать некоторым российским Vulnerability Intelligence организациям полномочия по заведению идентификаторов БДУ, фактически аналогичные CNA, что, конечно, имеет свои плюсы и минусы. 🤔