Александр ПивневЭксперт

26 августа «Открытая мобильная платформа» сообщила, что ОС «Аврора» версии 5.2.1 получила сертификат безопасности ФСТЭК России.

ОС «Аврора» — российская мобильная операционная система для смартфонов и планшетов. Разработчик — ООО «Открытая мобильная платформа».

В новости указано, что ФСТЭК подтвердил соответствие релиза 5.2.1 двум наборам требований: профилю защиты операционных систем типа «А» четвертого класса защиты и требованиям по безопасности информации, устанавливающим уровни доверия к СЗИ и средствам обеспечения безопасности ИТ. Уровень доверия — 4.

По сообщению компании, наличие сертификата позволяет использовать ОС «Аврора» в ГИС, ИСПДн, АСУ ТП и на объектах ЗОКИИ до 1 класса или уровня включительно.

Отдельно сказано про связку ОС «Аврора» с платформой управления «Аврора Центр»: она применяется для выполнения требований по использованию мобильных устройств в государственных информационных системах в соответствии с приказом ФСТЭК России №117 и методическим документом о составе и содержании мер защиты информации.

Релиз ОС «Аврора» 5.2.1.200 был опубликован для разработчиков 24 июня 2026 года. В сообщении о сертификации также указано, что в версии 5.2 было внесено более 3000 изменений.

Факт сам по себе простой: сертифицирована не абстрактная «мобильная платформа», а конкретный релиз — 5.2.1. Для проектов с регулируемыми системами это важная деталь: в документах, закупке, внедрении и эксплуатации должна сходиться именно версия продукта, условия сертификата и фактическая конфигурация устройств.

Источники: ОС «Аврора», 26 августа 2026; портал разработчика ОС «Аврора», релиз 5.2.1.200; CNews, 26 августа 2026

В сертификации Platform V SynGX интересен не сам факт «ещё один продукт получил сертификат».

Интересна роль этого продукта в инфраструктуре. Web server и reverse proxy обычно стоят на входе к веб-сервисам: рядом с TLS-терминацией, балансировкой, маршрутизацией запросов, логированием, публикацией внутренних приложений и иногда с собственной логикой обработки трафика. Ошибка или слабая эксплуатационная дисциплина в такой точке редко остаётся локальной.

4 августа СберТех сообщил, что Platform V SynGX получил сертификат ФСТЭК России по 4 уровню доверия. В новости отдельно указано, что продукт может применяться для защиты информации ограниченного доступа в ГИС, ИСПДн, объектах КИИ и АСУ ТП до 1-го класса защиты.

Сам продукт описывается как производительный веб- и обратный прокси-сервер для нагруженных сайтов и сервисов, основанный на Nginx. В функциональности заявлены метрики мониторинга, active health checks, интеграция с хранилищем секретов, балансировка нагрузки и возможность настраивать собственную логику обработки запросов.

Для практики я бы не сводил эту новость к простой формуле «сертификат есть — можно ставить». Сертификат даёт юридически и методически важную опору для применения в регулируемых системах. Но он не проектирует за нас схему публикации сервисов, не разделяет зоны, не описывает матрицу администрирования и не проверяет каждое правило маршрутизации после внедрения.

Что стоит проверить перед использованием такого компонента в проекте: точную версию и исполнение, условия действия сертификата, эксплуатационную документацию, состав поставки, модель обновлений, требования к ОС и окружению, схему журналирования, подключение к SIEM, порядок хранения секретов и процедуру изменения конфигурации.

Reverse proxy в защищаемой системе — это не просто «передний nginx». Это место, где техническое решение очень быстро становится организационным: кто имеет право менять правила, кто видит логи, кто отвечает за публикацию нового сервиса и кто подтверждает, что внешний доступ не расширился после очередного релиза.

Нормальная мысль здесь такая: сертификация СЗИ закрывает вопрос допустимости применения, но не заменяет проектирование и эксплуатационный контроль. Для ответственного по защите информации сертификат — это начало разговора с архитектором, а не финальная галочка в таблице.

Источники: СберТех, 4 августа 2026; IT-World, 4 августа 2026; СберТех о Platform V SynGX Community Edition, 3 апреля 2026

Меня в этой истории цепляет не сам факт «ещё одной Windows-уязвимости», а место, где она сработала: после обычной социальной инженерии.

Check Point 11 августа описала новую волну Operation Dream Job. Сценарий знакомый: под видом рекрутера жертве дают открыть материалы по вакансии. В этой кампании фигурировал SecurityPDF — изменённый PDF-просмотрщик, который открывал подготовленные документы и запускал новый бэкдор Troy.

Дальше начиналась уже не история про фишинг. Атакующие использовали CVE-2026-68820 в AFD.sys — это Windows-драйвер ядра, через который работают сетевые сокеты WinSock. Уязвимость давала локальное повышение привилегий до SYSTEM. Microsoft закрыла её в августовском Patch Tuesday 11 августа 2026 года.

Важная деталь: такая ошибка сама по себе не является «удалённым входом с интернета». Сначала нужен плацдарм на машине: вредоносный файл, троянизированная утилита, уже выполненный код. Но именно после этого локальная уязвимость становится очень ценной: можно подняться до уровня SYSTEM, поставить компонент глубже и попытаться ослепить EDR.

Поэтому я бы смотрел на этот кейс не только как на пункт в списке обновлений Windows. Для практики здесь два слоя проверки.

Первый — банальный, но обязательный: августовские обновления Windows на рабочих станциях и серверах. Особенно там, где пользователи работают с внешними файлами, подрядчиками, рекрутерами, инженерной документацией и почтой.

Второй — расследовательский: были ли в последние недели странные «просмотрщики PDF», job offer-документы, неожиданные переходы процессов в SYSTEM, попытки отключить видимость EDR, новые сервисы или следы DLL sideloading. Если машина уже успела попасть в цепочку до патча, одно обновление не доказывает, что инцидент закончился.

Здесь хороший практический вывод: social engineering и kernel LPE не живут в разных папках. Для атакующего это одна цепочка. Один человек открыл «вакансию», а разбирать потом приходится уже уровень ядра.

Источники: Check Point Research, 11 августа 2026; MSRC, CVE-2026-68820; NVD, CVE-2026-68820

У AI-инструментов есть неприятная привычка: их быстро поднимают для эксперимента, а потом они незаметно становятся частью рабочей инфраструктуры.

Свежий пример — Langflow. Это визуальный конструктор для AI-агентов и workflow: блоки, связи, вызовы API, куски Python-кода, интеграции с моделями и внутренними сервисами. Для разработки удобно. Для атакующего тоже, если такой сервис торчит в сеть и живёт на дефолтной конфигурации.

IBM описала CVE-2026-9198 в Langflow OSS 1.0.0–1.10.0. Цепочка выглядит грубо, но показательно: один endpoint выдавал superuser bearer token сетевому клиенту без аутентификации, другой endpoint для проверки кода выполнял переданный Python. В итоге на дефолтных развёртываниях получалось удалённое выполнение кода. CVSS — 9.8, исправление — переход на 1.10.1.

На этой неделе CISA добавила эту уязвимость в Known Exploited Vulnerabilities catalog: то есть речь уже не только о теоретическом баге из бюллетеня, а об эксплуатации вживую.

Что здесь важно для практики. Langflow и похожие low-code/AI-конструкторы часто появляются не через классический ввод системы в эксплуатацию, а как «мы быстро попробуем». Их запускают в Docker, на VM, в облаке, иногда с доступом к токенам, базам, внутренним API и файловым шарам. В инвентаризации ИБ такой узел может не светиться как критичный, хотя фактически он умеет выполнять код рядом с данными.

Я бы проверил не только наличие Langflow по названию. Имеет смысл посмотреть лабораторные серверы, dev/stage, контейнеры у команд разработки, внешние reverse proxy и правила доступа. Если Langflow есть — версия, доступность REST API, включён ли auto-login, какие секреты лежат в окружении, и были ли обращения к /api/v1/auto_login и /api/v1/validate/code.

AI-инструмент не становится безопасным от того, что его поставили «для эксперимента». Если он принимает запросы из сети и может запускать код, это уже сервер с последствиями.

Источники: IBM Security Bulletin, CVE-2026-9198; NVD, CVE-2026-9198; CISA KEV, CVE-2026-9198

RMM-консоль в плохой день превращается не в «ещё один сервер», а в пульт управления чужой инфраструктурой.

Свежий пример — N-able N-central. Это платформа для удалённого мониторинга и управления: через неё MSP и ИТ-команды видят машины клиентов, ставят патчи, запускают задачи и подключаются к рабочим станциям и серверам.

2 августа N-able выпустила hotfix 2026.3.1.7 для CVE-2026-18577. По описанию вендора, уязвимость затрагивала N-central до 2026.3.1.7 и позволяла удалённо получить административный доступ. Дальше атакующие использовали функцию Take Control, заходили на управляемые системы и в одном из сценариев регистрировали сервис Cloudflare tunnel, чтобы сохранить доступ уже после отзыва доступа к N-central.

Это неприятно именно из-за роли продукта. Когда ломают обычный сервер, масштаб понятен. Когда ломают RMM, под рукой оказываются скрипты, задания, удалённые сессии и доверие со стороны десятков или сотен endpoint'ов.

Я бы не ограничивался фразой «поставили хотфикс». Надо отдельно посмотреть, где стоит N-central, доступен ли он извне, кто мог логиниться в последние дни, были ли странные Take Control-сессии, особенно к доменным контроллерам и файловым серверам, и не появились ли неожиданные сервисы/туннели на управляемых машинах.

Для тех, у кого self-hosted, это ещё и вопрос дисциплины: hosted-инстансы вендор обновляет сам, а свой сервер остаётся на совести команды. Huntress 3 августа писала, что среди reachable self-hosted N-central ещё оставались непатченные серверы.

Хорошая RMM-система экономит часы работы. Но в модели угроз она должна жить как высокопривилегированный инструмент, а не как удобная веб-админка «для техподдержки».

Источники: N-able, 2 августа 2026; Huntress, обновление 3 августа 2026

Есть неприятный класс историй: вроде бы человек просто открыл письмо, а разбирать приходится уже серверную почту.

Proofpoint 29 июля написал про новую волну эксплуатации CVE-2026-42897 в Outlook Web Access. OWA — это веб-почта Exchange, тот самый доступ к почте через браузер в on-prem средах.

Суть не в том, что пользователь скачал вложение или перешёл по ссылке. Проблема в обработке HTML внутри письма: при открытии сообщения в OWA может выполниться JavaScript в контексте уже авторизованной веб-почты.

Дальше история становится совсем неудобной. В кампании, которую описывает Proofpoint, цепочка заканчивалась OWAReaper — браузерным имплантом внутри OWA. Он не выглядит как обычный файл на рабочей станции, поэтому переустановка ноутбука или смена пароля сами по себе не обязательно решают проблему, если след остался на стороне Exchange.

Меня здесь цепляет простая вещь: корпоративную почту часто воспринимают как канал доставки атаки. А в таких сценариях сама веб-почта становится местом исполнения. Это уже не только задача антиспама.

Я бы смотрел на это спокойно, но без отмахивания: есть ли ещё on-prem Exchange с OWA наружу, включены ли emergency mitigations Microsoft, применены ли актуальные обновления, и видны ли в логах странные действия именно в OWA, а не только на конечных устройствах.

Фраза «открыл письмо» звучит слишком буднично. Но для старого или плохо обслуживаемого веб-доступа к почте этого иногда уже хватает.

Источники: Proofpoint, 29 июля 2026; NVD, CVE-2026-42897

История со SmartConsole у Check Point неприятна не потому, что это ещё один громкий CVE.

SmartConsole — это админская консоль, через которую управляют политиками Check Point: правилами firewall, объектами, шлюзами, публикацией изменений. Проще говоря, пульт от охраны периметра.

22 июля Check Point выпустила Jumbo Hotfix для Security Management и Multi-Domain Management. Внутри — CVE-2026-16232: обход аутентификации в логине SmartConsole через application token.

Плохой сценарий выглядит довольно буднично: Management Server доступен из интернета, Trusted Clients не ограничены нормальным списком адресов, и кто-то извне получает токен, с которым можно зайти как администратор.

Check Point пишет, что такие атаки уже видели у небольшого числа клиентов. Smart-1 Cloud, по словам вендора, уже закрыт.

Вот почему я не люблю, когда management-интерфейсы живут «где удобно». У firewall может быть хорошая политика, но если наружу смотрит консоль, через которую эту политику меняют, периметр держится на честном слове.

Я бы здесь без героизма проверил три вещи: где стоит Management Server, кто реально может подключаться к SmartConsole, и нет ли в Audit Logs входов через application token. А потом — hotfix, если его ещё не поставили.

Это не красивая теория про management plane. Это обычная хозяйственная вещь: пульт от защиты не должен лежать у двери.

Источники: Check Point, 22 июля 2026; BleepingComputer, 23 июля 2026

ServiceNow — это не «просто сервис для заявок». В крупных компаниях через такие платформы проходят инциденты, согласования, CMDB, доступы, интеграции с почтой, каталогами и внутренними системами.

Поэтому история с CVE-2026-6875 неприятна не только из-за оценки 9.5. NVD описывает её как удалённое выполнение кода в ServiceNow AI Platform: при определённых условиях неаутентифицированный пользователь может выполнить код внутри платформы. ServiceNow пишет, что обновления для hosted-инстансов уже развернуты, а self-hosted-клиентам и партнёрам выданы патчи. При этом исследователи Defused сообщили о попытках эксплуатации; ServiceNow отдельно уточняет, что пока не видит подтверждения эксплуатации hosted-инстансов.

Практический вывод простой: SaaS, ITSM и low-code-платформы нельзя относить к категории «это где-то у вендора, нас не касается». Если через систему идут права, процессы и интеграции, она становится частью контура безопасности.

Что я бы проверил в такой ситуации:

• кто реально владеет платформой со стороны ИБ, а не только со стороны эксплуатации;
• какие инстансы hosted, self-hosted или партнёрские;
• применены ли нужные патчи и на какой версии сейчас система;
• какие интеграции имеют доступ к AD, почте, SIEM, Jira, Git и внутренним API;
• есть ли логи подозрительных запросов и изменений после даты раскрытия уязвимости.

Самая опасная привычка — считать бизнес-платформу «не инфраструктурой». Для атакующего это может быть очень удобный вход: много связей, много доверия и часто не самый жёсткий контроль.

Источники: NVD, CVE-2026-6875; BleepingComputer, 20 июля 2026

Самое сложное в больших обновлениях — не нажать «установить всё».

В июльском Patch Tuesday Microsoft закрыла рекордный набор уязвимостей. BleepingComputer пишет о 570 исправлениях, среди них 59 критических, 145 уязвимостей удалённого выполнения кода и три zero-day. Две из этих zero-day уже использовались в атаках.

Когда в одном выпуске сотни CVE, главный риск для компании — утонуть в списке и отложить всё «до нормального окна». На практике так обычно и появляется хвост из уязвимых серверов, забытых рабочих мест и систем, которые никто не решается перезагрузить.

Я бы смотрел на такой выпуск не как на новость про рекорд, а как на проверку процесса обновлений.

Минимальный порядок действий:
• отделить реально эксплуатируемые уязвимости от просто важных;
• проверить, есть ли в контуре затронутые роли: AD, SharePoint, SQL Server, RDP, DHCP, WSUS и внешние сервисы;
• согласовать короткое окно для критичных узлов, а не ждать общего планового обслуживания;
• после установки проверить факт обновления, а не только «задача закрыта»;
• отдельно посмотреть системы, которые давно не перезагружались или выпали из WSUS/EDR.

Большой Patch Tuesday — это не повод для паники. Это хороший тест: есть ли у компании инвентаризация, приоритизация и человек, который отвечает за доведение обновлений до конца.

Источник: BleepingComputer, 14 июля 2026; Microsoft Security Update Guide

Уязвимости на периметре всегда неприятнее обычных рабочих станций. Особенно когда это VPN-шлюз: он смотрит наружу и одновременно является входом во внутреннюю сеть.

SonicWall предупредила об активной эксплуатации двух уязвимостей в SMA1000: CVE-2026-15409 и CVE-2026-15410. Первая — критическая SSRF в интерфейсе Work Place, вторая — инъекция команд в консоли управления после аутентификации администратора.

Здесь важен не только конкретный вендор. Логика шире: внешние шлюзы, VPN, админ-панели и другие точки входа нельзя патчить «когда дойдёт очередь». Для них нужен отдельный короткий цикл: быстро проверить применимость, поставить hotfix, посмотреть признаки компрометации и только потом закрывать задачу. В этой истории обходных мер, кроме hotfix, нет.

На практике я бы смотрел на такие вещи:
• какие VPN и внешние панели реально торчат наружу;
• кто владелец каждого узла и кто принимает решение о простое;
• есть ли тестовый путь для срочных hotfix;
• проверяются ли логи и IOC после установки исправления;
• меняются ли пароли и токены, если есть признаки компрометации.

Самое опасное в периметре — привычка считать его «один раз настроенным». Внешний вход в сеть должен жить в режиме постоянного контроля, иначе маленькая уязвимость на границе быстро становится большой проблемой внутри.

Источник: BleepingComputer, 14 июля 2026