IBM настоятельно призывает клиентов как можно скорее исправить критическую уязвимость в своей платформе API Connect, которая может позволить удаленным злоумышленникам обходить аутентификацию.
Компания описывает API Connect как шлюз API полного жизненного цикла, используемый для «создания, тестирования, управления, защиты, анализа и социализации API».
Особо отмечается, что это способ «раскрыть потенциал агентного ИИ», обеспечивая центральную точку контроля доступа к сервисам ИИ через API. Платформа также включает API Agent, который автоматизирует задачи на протяжении всего жизненного цикла API с использованием ИИ.
Ключевым компонентом является настраиваемый портал самообслуживания, который позволяет разработчикам легко подключаться, а также находить и использовать различные типы API, включая SOAP, REST, события, ASyncAPIs, GraphQL и другие.
Уязвимость, отслеживаемая как CVE-2025-13915, затрагивает IBM API Connect версий с 10.0.8.0 по 10.0.8.5 и версию 10.0.11.0 и может предоставить несанкционированный доступ к открытым приложениям без какого-либо взаимодействия с пользователем.
Нарушение архитектурного допущения
«CVE-2025-13915 не следует воспринимать как обычную ошибку безопасности, — говорит Санчит Вир Гогия, главный аналитик Greyhound Research. — Это скорее момент, когда давнее архитектурное допущение наконец-то явно нарушается. Допущение простое и глубоко укоренившееся в корпоративном проектировании: если трафик проходит через API-шлюз, личность установлена и доверие обеспечено. Эта уязвимость доказывает, что это допущение может полностью провалиться».
Он отметил, что классификация уязвимости, соответствующая CWE-305, важна, поскольку исключает целый класс, по его словам, успокаивающих объяснений. «Это не украденные учетные данные. Это не неправильная конфигурация ролей. Это не ошибка разрешений, — сказал он. — Саму систему принудительной аутентификации можно обойти».
Когда это происходит, объяснил он, нижестоящие сервисы не просто сталкиваются с повышенным риском, они теряют основу, на которой строились их решения о доступе, потому что они не перепроверяют личность. Они никогда не были предназначены для этого; они наследуют доверие.
«Как только принудительное применение не удается вышестоящему сервису, унаследованное доверие становится незаслуженным, и уязвимость распространяется незаметно, — сказал он. — Этот класс уязвимостей согласуется с автоматизацией, широким сканированием и оппортунистическим зондированием, а не с тщательным нацеливанием».
Предоставлены временные исправления
IBM заявила, что проблема была обнаружена во время внутреннего тестирования, и предоставила временные исправления для каждой затронутой версии программного обеспечения, с подробностями об отдельных обновлениях для VMware, OCP/CP4I и Kubernetes.
Единственная мера по смягчению последствий уязвимости, предложенная в бюллетене безопасности IBM, звучит так: «Клиентам, которые не могут установить временное исправление, следует отключить самостоятельную регистрацию на своем портале разработчика, если она включена, что поможет минимизировать их подверженность этой уязвимости».
Компания также отмечает в своих инструкциях по установке исправлений, что переопределения образов, описанные в документе, должны быть удалены при обновлении до следующего выпуска или пакета исправлений.
Это, по словам Гогия, еще больше повышает риск. «Это не косметическая деталь, — отметил он. — Плоскости управления определяют истинность конфигурации, контроль жизненного цикла и операционные полномочия по всей платформе. Когда исправление затрагивает этот уровень, уязвимость находится близко к ядру управления, а не на изолированном краю шлюза. Это повышает как радиус поражения, так и риск исправления».
Это связано с тем, что ошибки в этих областях могут обернуться продолжительным воздействием или нестабильностью сервиса. «[Переопределения образов] также создают угрозу для управления: переопределения образов создают теневое состояние; если они не будут явно удалены позже, они будут сохраняться незаметно», — отметил он. «Со временем они выходят из поля зрения, владения и области аудита. Так временные исправления превращаются в долгосрочный риск».
Самый ценный результат: обучение
Он добавил, что операционные проблемы, связанные с исправлением, заключаются не столько в знании того, что нужно сделать, сколько в том, чтобы сделать это достаточно быстро, не нарушая работу бизнеса. И, по его словам, управление API теперь должно включать актуальные инвентаризации API, их версии, зависимости и точки воздействия, а также мониторинг поведения.
«Самый ценный результат здесь — не закрытие проблемы, — заметил Гогия. — Это обучение. Предприятия должны спросить, что бы произошло, если бы эта уязвимость использовалась незаметно в течение нескольких недель. Какие сервисы доверяли бы шлюзу безоговорочно? Какие журналы показали бы аномальное поведение? Какие команды заметили бы это первыми? Эти ответы показывают, видимы или невидимы допущения о доверии. Организации, которые остановятся на исправлении, упустят редкую возможность укрепить устойчивость до следующего сбоя плоскости управления».
Эта статья первоначально появилась на InfoWorld.
Всегда имейте в виду, что редакции некоторых изданий могут придерживаться предвзятых взглядов в освещении новостей.
8/9
Автор – Lynn Greiner
