Архив метки: vulnerability

Уязвимости подрядчиков - это ваши уязвимости

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

Уязвимости подрядчиков - это ваши уязвимости

Уязвимости подрядчиков - это ваши уязвимости. Есть масса публичных кейсов, когда подрядчика ломали и получали доступ к данным компаний-клиентов. А то и доступ непосредственно в их инфраструктуры! И что с этим делать? 🤔

Даже только по VM-ной части. Вы, как минимум теоретически, можете выстроить В СВОЕЙ КОМПАНИИ красивый и эффективный VM-процесс для 100% инфраструктуры. Но вы же не будете сами выстраивать VM-процесс у всех ваших подрядчиков? 🙂

Получается гарантировать безопасность подрядчиков следует как-то иначе: через выставление требований по ИБ к подрядчикам и контроль их выполнения (анкетирование, контроль периметра, внутренний аудит и т.п.).

🎞 У Алексея Лукацкого недавно был хороший вебинар про безопасность подрядчиков. Там ещё в раздатке были категории подрядчиков для компаний из разных отраслей: банки, IT-компании, ритейл, сельхоз, нефтянка. 👍

➡️ А завтра в 12:00 (МСК) об этом будут говорить в Код ИБ "Безопасная Среда". Собираюсь посмотреть. 👀

Централизация репортинга уязвимостей

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

Централизация репортинга уязвимостей

Централизация репортинга уязвимостей. Раз уж последний пост на эту тему набрал много реакции (хоть и отрицательных 😅) и даже породил дискуссию, я расписал как бы мог работать гипотетический государственный регулятор "Инициатива Нулевого Дня" ("ИНД"; отсылка к ZDI 🙂), контролирующий репортинг уязвимостей в продуктах вендоров из недружественных стран.

Исследователь, обнаруживший уязвимость в продукте вендора из недружественной страны, передаёт результаты ресёрча в ИНД. Эксперты ИНД проводят анализ и выносят решение:

🔹 Если уязвимость представляет интерес с точки зрения национальной безопасности, исследователь подписывает соглашение о неразглашении и ему выплачивается вознаграждение от ИНД. Вендор не уведомляется. Также как NSA годами использовали EternalBlue и не сообщали MS. 😉

🔹 Если уязвимость не представляет интереса, ИНД либо сообщает о ней вендору, либо даёт разрешение исследователю сообщить вендору самостоятельно. Уязвимость заводится в БДУ.

Сдай уязвимость государству! По поводу цитаты из заключения к отклонённому "закону о белых хакерах

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

Сдай уязвимость государству! По поводу цитаты из заключения к отклонённому закону о белых хакерах

Сдай уязвимость государству! По поводу цитаты из заключения к отклонённому "закону о белых хакерах":

"Кроме того, передача информации о выявленных недостатках программ для ЭВМ и (или) базы данных правообладателям, находящимся под юрисдикцией государств, совершающих недружественные действия в отношении Российской Федерации, не отвечает интересам обеспечения безопасности Российской Федерации."

Вполне справедливо. Более того, контакты российских исследователей с вендорами из недружественных стран (зачастую крупным гос. подрядчиками) в текущей непростой геополитической ситуации могут иметь признаки противоправной деятельности. 🤔 См. 275 УК РФ: "консультационная или иная помощь". А оно вам надо?

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

Основная проблема существующих отечественных ОС в том, что в абсолютном большинстве это всего лишь перелицованные зрелые западные Linux-дистрибутивы

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

Основная проблема существующих отечественных ОС в том, что в абсолютном большинстве это всего лишь перелицованные зрелые западные Linux-дистрибутивы

Основная проблема существующих отечественных ОС в том, что в абсолютном большинстве это всего лишь перелицованные зрелые западные Linux-дистрибутивы. 🤷‍♂️ Ведь задача, которая ставится перед их разработчиками - получить за минимальное время и с минимальными затратами решение с максимальной функциональностью. И заработать на этом. 👛

Для того чтобы отечественные ОС стали по-настоящему отечественными, необходимо менять подход. Исходить из того, что западные опенсурсные компоненты - зло. Они нашпигованы закладками (иногда под видом уязвимостей 😏). Для того чтобы минимизировать риски, связанные с этими закладками, необходимо минимизировать и количество зависимостей. А для этого нужно хотя бы поддерживать актуальный реестр зависимостей.

Тогда постепенно можно будет избавляться от наиболее сомнительных зависимостей, переходить на отечественные аналоги и форки. Тем самым формируя по-настоящему отечественные операционные системы. Которых (сюрприз-сюрприз!) сейчас нет. 🌝

Про уязвимость Remote Code Execution - Internet Shortcut Files (CVE-2025-33053)

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

Про уязвимость Remote Code Execution - Internet Shortcut Files (CVE-2025-33053)

Про уязвимость Remote Code Execution - Internet Shortcut Files (CVE-2025-33053). Уязвимость из июньского Microsoft Patch Tuesday. Эта уязвимость сразу имела признаки эксплуатации вживую. Эксплуатация уязвимости позволяет удалённому злоумышленнику выполнить произвольный код при открытии жертвой специального .url-файла, доставленного, например, в ходе фишинговой атаки.

🔹 Уязвимость зарепортили исследователи из компании Check Point. В день июньского Microsoft Patch Tuesday (10 июня) на их сайте были опубликованы технические детали. Уязвимость эксплуатировалась APT-группой Stealth Falcon как минимум с марта 2025 года. Эксплуатация уязвимости приводила к загрузке и запуску вредоносного ПО (Horus Agent) с WebDAV-сервера злоумышленника.

🔹 Эксплоиты для уязвимости доступны на GitHub с 12 июня.

Результаты опроса R-Vision: около 80% компаний считают качество сканирования ключевым критерием выбора VM-решений

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

Результаты опроса R-Vision: около 80% компаний считают качество сканирования ключевым критерием выбора VM-решений

Результаты опроса R-Vision: около 80% компаний считают качество сканирования ключевым критерием выбора VM-решений. В опросе приняли участие 83 респондента. Это были ИБ-cпециалисты различного уровня (от линейных сотрудников до CISO), работающие в компаниях разного размера (от SMB до Enterprise) и из различных отраслей (финансы, промышленность, ИТ, ГОСы, нефтегаз, ритейл, транспорт, телекомы, энергетика).

Результаты выглядят вполне адекватно:

🔹 Чем крупнее компания, тем более зрелый там VM-процесс.

🔹 Главный критерий выбора VM-решений - широкое покрытие ОС и приложений. Также важны скорость, стабильность и минимизация фолзов.

Хочется надеяться, что как можно больше VM-вендоров ознакомятся с результатами этого опроса и начнут уделять приоритетное внимание разработке правил детектирования уязвимостей и тестированию качества их работы. 🙏 То есть той базовой функциональности, без которой все остальные "высокоуровневые" фичи не имеют никакого смысла. 🤷‍♂️😉

Про уязвимость Remote Code Execution - Roundcube (CVE-2025-49113)

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

Про уязвимость Remote Code Execution - Roundcube (CVE-2025-49113)

Про уязвимость Remote Code Execution - Roundcube (CVE-2025-49113). Roundcube - популярный веб-клиент для работы с электронной почтой (IMAP) с открытым исходным кодом. Эксплуатация уязвимости позволяет аутентифицированному злоумышленнику выполнить произвольный код на сервере Roundcube Webmail. Причина уязвимости - Deserialization of Untrusted Data (CWE-502).

🔹 1 июня вендор выпустил исправленные версии 1.6.11 и 1.5.10. В течение 48 часов патч был проанализирован злоумышленниками и сообщения о продаже эксплойта появились в даркнете.

🔹 3 июня эксперты PT SWARM воспроизвели уязвимость.

🔹 С 5 июня публичные эксплоиты доступны на GitHub.

🔹 6 июня Кирилл Фирсов, исследователь, зарепортивший эту уязвимость, опубликовал подробный write-up. В нём он утверждает, что уязвимость присутствовала в коде 10 лет и что есть признаки её публичной эксплуатации.

🔹 16 июня появились сообщения об успешной атаке на немецкого почтового хостинг-провайдера с использованием этой уязвимости.