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

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