Архивы автора: Александр Леонов

Об авторе Александр Леонов

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно и моих проектах можете прочитать здесь. Приглашаю подписаться на мой канал @avleonovrus "Управление Уязвимостями и прочее" в MAX или в Telegram. Вы можете обсудить мои посты или задать вопросы в группе ВКонтакте. And I invite all English-speaking people to another Telegram channel @avleonovcom.

Тут можно сказать - а какое нам дело до западных ИБ-вендоров, нам их запрещать не нужно, они же сами из России сбежали из-за санкций

Тут можно сказать - а какое нам дело до западных ИБ-вендоров, нам их запрещать не нужно, они же сами из России сбежали из-за санкций

Тут можно сказать - а какое нам дело до западных ИБ-вендоров, нам их запрещать не нужно, они же сами из России сбежали из-за санкций. Да, западные вендоры сбежали, а инсталляции их продуктов остались. И они либо вообще без лицензий используются, либо используются с лицензиями, закупаемыми через третьи страны. Даже в VM-ной сфере частенько слышу "а мы продолжаем на Nessus-ах работать". Это ведь не запрещено. 😏

И так повсеместно. В IT даже более выражено, чем в ИБ. Иностранный корпоративный софт все еще используют 72% российских компаний. И даже в регулируемом сегменте на отечественный софт перешли только 40-45% субъектов КИИ. 🤦‍♂️ А законодательный пушинг всё не усиливается. 🤷‍♂️

Какой уж там "технологический остров". Всё та же "технологическая колония" с чахлыми суверенными росточками, как правило на тех же западных стандартах и западном опенсурсе. Но некоторые агитируют и эти росточки растоптать, сохранив прямую "двухконтурную" зависимость от американского бигтеха. 🙄

Зачем запрещать продукты иностранных ИБ-вендоров?

Зачем запрещать продукты иностранных ИБ-вендоров?

Зачем запрещать продукты иностранных ИБ-вендоров? В той же статье про запрет в Китае западных ИБ-вендоров Reuters прямо пишут:

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

И продолжают, что "подозрения относительно происхождения и мотивов" к компании Kaspersky привели к удалению их ПО из сетей правительства США в 2017 году и запрету продаж на территории США в 2024 году.

Если американцы видят потенциальную угрозу своей национальной безопасности - тут же зачищают полянку для своих. 👌 Умные, хитрые, рациональные. Читайте то, что они транслируют для внутреннего потребления, а не экспортные благоглупости. 😉

По поводу запрета западных ИБ-вендоров в Китае

По поводу запрета западных ИБ-вендоров в Китае

По поводу запрета западных ИБ-вендоров в Китае. Пока все ссылаются только на Reuters. А они это формулируют так:

"Китайские власти сообщили отечественным компаниям о необходимости прекратить использование программного обеспечения по кибербезопасности, разработанного более чем дюжиной фирм из США и Израиля, по соображениям национальной безопасности, сообщили три человека, проинформированные по этому вопросу."

Эти три человека сообщили разные перечни вендоров, но если суммировать: Cato Networks, Check Point Software Technologies, Claroty, CrowdStrike, CyberArk, Fortinet, Imperva, McAfee, Mandiant, Orca Security, Palo Alto Networks, Rapid7, Recorded Future, SentinelOne, VMware, Wiz.

Список выглядит неполным и непоследовательным. Даже по VM-ной теме: где Tenable и Qualys? А глобально: где Microsoft и Cisco? 🤔

Но если это действительно так и ограничения коснутся ВСЕХ компаний в Китае, а не только госов и КИИ, то это очень круто и пример для подражания. 👍

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)?

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)?

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)? Понимая под АЗ детектирование уязвимостей в инфраструктуре организации третьей стороной. Для исполнителя критерии успеха: найти максимум уязвимостей с минимумом FP и FN. А для заказчика? 🤔 Обычно для него успехом считают отсутствие обнаруженных критичных уязвимостей. А если такие есть - их нужно срочно устранить или доказать, что они некритичные. 👌

Однако организациям без работающего VM-процесса такое разовое латание дыр не особо поможет - через полгода в инфре снова будет адище. 😈 А организациям с работающим VM-процессом требование устранять уязвимости в пожарном режиме, игнорируя SLA по существующим задачам на устранение, внесёт неразбериху и может сломать VM-процесс. 🤷‍♂️

Имхо, по-хорошему, АЗ должен проверять не текущее состояние инфры (постоянно меняющееся), а состояние VM-процесса. С соответствующими критериями успеха. 😉

У Security Vision вышла новая версия Vulnerability Scanner

У Security Vision вышла новая версия Vulnerability ScannerУ Security Vision вышла новая версия Vulnerability ScannerУ Security Vision вышла новая версия Vulnerability ScannerУ Security Vision вышла новая версия Vulnerability Scanner

У Security Vision вышла новая версия Vulnerability Scanner. Прошлый релиз был в сентябре-октябре.

🔹 Реализовали построение графа достижимости уязвимостей на основе сетевой топологии инфраструктуры.

🔹 Улучшили карточки уязвимостей: добавили оценку вероятности эксплуатации (EPSS), данные об обнаружении уязвимых систем в публичном интернете (Shodan CVEDB и тренд по регистрации хостов в Shodan; отображается в тегах, как и EPSS), рекомендации по устранению уязвимостей от НКЦКИ.

🔹 Реализовали динамические группы активов на основе заданных критериев (типа ОС, версии, наличия уязвимостей, баннеров сервисов и т.д.).

Также добавили расчёт рекомендованных сроков устранения по методике оценки уровня критичности ФСТЭК (от 30.05.2025), улучшили экспертизу (расширили BlackBox, поддержали WMI-сканы Windows, Gentoo Linux, Modbus, устройства Palo Alto Networks), переработали управление сканами и журнал сканов.

Palo Alto Networks подробно пишут про RCE-уязвимость в трёх open-source AI/ML-проектах на Python

Palo Alto Networks подробно пишут про RCE-уязвимость в трёх open-source AI/ML-проектах на Python

Palo Alto Networks подробно пишут про RCE-уязвимость в трёх open-source AI/ML-проектах на Python. Уязвимость вызвана использованием библиотеки Hydra (разрабатывается экстремистской компанией Meta) для загрузки конфигураций из метаданных модели. Злоумышленник может внедрять произвольный код в метаданные модели, который будет автоматически выполнен в момент загрузки модифицированной модели уязвимыми проектами:

🔻 NeMo - фреймворк на базе PyTorch, разработан NVIDIA. CVE-2025-23304 исправлена в версии 2.3.2.

🔻 Uni2TS - библиотека PyTorch, используемая в Morai от Salesforce - foundation‑модели для анализа временных рядов. CVE-2026-22584 исправлена 31 июля 2025 года.

🔻 FlexTok - фреймворк на Python, позволяющий AI/ML‑моделям обрабатывать изображения; разработан исследователями Apple и VILAB@EPFL. Уязвимость исправлена без CVE в июне 2025 года.

👾 Признаков эксплуатации вживую пока нет.

Январский Microsoft Patch Tuesday

Январский Microsoft Patch Tuesday

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

🔻 InfDisc - Desktop Window Manager (CVE-2026-20805)

Также есть две уязвимости с публичными эксплоитами:

🔸 RCE - Windows Deployment Services (CVE-2026-0386)
🔸 EoP - Windows Agere Soft Modem Driver (CVE-2023-31096)

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

🔹 RCE - Microsoft Office (CVE-2026-20952, CVE-2026-20953), Windows NTFS (CVE-2026-20840, CVE-2026-20922)
🔹 EoP - Desktop Windows Manager (CVE-2026-20871), Windows Virtualization-Based Security (VBS) Enclave (CVE-2026-20876)
🔹 SFB - Secure Boot Certificate Expiration (CVE-2026-21265)

Отдельно хотелось бы выделить уязвимость, зарепорченную Positive Technologies:

🟥 EoP - Windows Telephony Service (CVE-2026-20931)

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