CISA за начало сентября разом добавила в каталог активно эксплуатируемых уязвимостей семь новых записей, и список бьёт по неожиданному месту, по инструментам, которые лежат в основе современной разработки. Под удар попали Python-фреймворк Starlette, платформа оркестрации Kestra, шлюз для ИИ-моделей LiteLLM и телефонная система Sangoma Switchvox. По следам атак остаются обратные шеллы и майнеры криптовалюты. Если ваш стек собран из открытых компонентов, а он почти наверняка собран, эта новость про вас.

Что добавили в каталог

Каталог KEV — это не абстрактный список «опасных багов», а перечень уязвимостей, эксплуатацию которых уже видели вживую. Попадание туда означает простую вещь: рабочий эксплойт существует и применяется. В свежей порции оказались компоненты, которые обычно считают безобидной инфраструктурой. Starlette лежит в основе множества Python-бэкендов и API. Kestra оркестрирует конвейеры данных и фоновые задачи. LiteLLM проксирует запросы к языковым моделям и всё чаще стоит между приложением и ИИ. Switchvox отвечает за корпоративную телефонию.

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

Почему целятся именно в служебный стек

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

Вторая причина кроется в привилегиях. Служебные сервисы обычно стоят внутри сети, имеют доступ к базам, очередям, ключам и другим системам, потому что для этого их и разворачивали. Захватив оркестратор или шлюз, атакующий получает не изолированную коробку, а узел с широкими правами в самом центре инфраструктуры. Отсюда до данных и до продакшена ближе, чем от взломанного публичного сайта.

Обратные шеллы и майнеры — что это значит

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

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

Как найти теневую инфраструктуру

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

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

Первые шаги при подозрении на взлом

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

Обнаружив след компрометации, не ограничивайтесь удалением полезной нагрузки. Майнер или шелл — это симптом, а не болезнь. Нужно понять, как именно зашли, что ещё успели сделать и не осталось ли других точек закрепления. Изолируйте узел, соберите данные для разбора и только потом восстанавливайте из заведомо чистого состояния.

Это касается и тех, кто просто пользуется опенсорсом

Может возникнуть мысль, что всё это забота тех, кто пишет на Python или гоняет ИИ-конвейеры. На деле граница шире. Готовые решения, которые вы разворачиваете у себя, тоже собраны из этих же кирпичиков: под капотом коробочного продукта нередко работает тот самый веб-фреймворк или оркестратор, что попал в список. Вы можете не знать, что внутри вашей системы крутится уязвимый компонент, просто потому что его туда положил вендор. Поэтому инвентаризация должна учитывать не только то, что вы поставили сами, но и то, что приехало внутри стороннего софта. Спросить поставщика, какие открытые компоненты и какой версии он использует, это нормальная часть проверки, а не придирка.

Что делать командам разработки

• Провести инвентаризацию: какие открытые компоненты и служебные сервисы у вас развёрнуты, какие из них видны из интернета и когда обновлялись в последний раз.
• Немедленно обновить попавшие в KEV компоненты и убрать наружу торчащие панели и API, которым там не место.
• Проверять не только свой код, но и его окружение и зависимости — это аудит исходного кода, пентест API и оценка защищённости.
• Отдельно тестировать обвязку вокруг ИИ-сервисов, через которую к моделям и данным можно подобраться: пентест ИИ-агентов.

Вывод

Свежий список KEV — это карта того, куда сейчас реально бьют: не в громкие продукты, а в служебную инфраструктуру разработки, которую все привыкли считать безопасной. Открытый фреймворк, оркестратор, ИИ-шлюз: каждый из них полноценная дверь в вашу систему, если он выставлен наружу и не обновлён. Соберите инвентарь, закройте лишнее, обновите остальное и проверьте периметр глазами атакующего. Разбор методик и цен на тестирование есть и у коллег из SecurityLab.