Уязвимости Black Hat в службе SAP Core AI создали шлюз к личным данным клиентов, включая код и учебные материалы, пока они не были исправлены в начале этого года.
Об этом сообщают специалисты по поиску уязвимостей из Wiz, которые ответственно раскрыли подробности о пяти ранее не зарегистрированных и впоследствии исправленных ошибках в Core AI, получивших название SAPwned.
Отчет был опубликован перед конференцией Black Hat, на которой специалисты по информационной безопасности представят свои выводы в докладе «Изоляция или галлюцинация? Взлом поставщиков инфраструктуры ИИ ради развлечения и веса».
SAP исправила уязвимости в мае, через несколько месяцев после того, как Wiz сообщил немецкой компании-разработчику программного обеспечения ERP об уязвимостях.
Команда Wiz заявила в отчете, что эксплуатация всего лишь одного упущения в разрешениях была всем, что потребовалось команде, чтобы получить доступ к внутренней сети SAP, среди прочих деталей. Команда заявила, что начала с передачи файла Argo Workflow в Core AI для создания Kubernetes Pod; пока ничего необычного. Wiz отмечает, что он мог выполнять произвольный код в своем Pod, но отсутствие доступа к сети через прокси-сервер Istio делало его довольно бесполезным.
Однако, похоже, получить этот сетевой доступ было несложно. SAP отключила настройки, которые были явно опасны, но, по-видимому, его контроллер допуска пропустил параметры shareProcessNamespace и runAsUser. Первый можно было использовать, чтобы Pod разделял имя sidecar и получал токен доступа Istio, а затем последний использовался для запуска всего, как исходящего от этого поставщика.
Wiz заявил, что оттуда он получил доступ к экземпляру Grafana Loki и его данным, размещенным на AWS, включая журналы и информацию о Pod клиентов, шесть экземпляров AWS Elastic File System (EFS), которые содержали данные обучения и код клиентов, и сервер Helm. Исследователям, по-видимому, не нужно было находить здесь никаких дополнительных учетных данных или эксплойтов, поскольку все, по-видимому, было просто оставлено открытым, согласно отчету.
Wiz говорит, что по умолчанию EFS и Helm находятся на определенных портах (которые были в SAP Core AI); Кроме того, в хранилище AWS обычно используется общедоступная конфигурация по умолчанию. Специалисты по информационной безопасности заявили, что шесть экземпляров EFS в совокупности предоставили «огромное количество данных ИИ».
Особую обеспокоенность вызвал сервер Helm, говорят исследователи, добавляя, что, как и хранилище EFS, он содержал множество данных клиентов, а также сборки и образы программного обеспечения. Этого достаточно, но Wiz заявил, что также обнаружил, что сервер Helm был открыт для операций чтения и записи, то есть злоумышленник мог провести атаку на цепочку поставок, заменив хорошие сборки и образы на те, которые были заполнены вредоносным ПО.
Доступ на запись также означал, что они могли установить пакет Helm для создания Pod с правами администратора, предоставляя неограниченный доступ практически ко всему, к чему прикасалось AI Core. Это, по сути, наихудший сценарий для кибербезопасности.
К счастью, представитель SAP сообщил The Registerчто «ни данные клиентов SAP, ни системы не были затронуты этими уязвимостями».
Команда Wiz стремилась предупредить техническое сообщество, «что модели ИИ и процедуры обучения по сути являются кодом». Исследователь безопасности Wiz Хилаи Бен-Сассон сказал нам, что когда модели и процедуры ИИ «поступают из ненадежного источника, с ними следует обращаться как с таковыми, а их выполнение должно быть надлежащим образом изолировано от любых других активов».
Бен-Сассон добавил: «Конкретные уязвимости, которые мы обнаружили, возникли из-за неправильно настроенных служб во внутренней сети. Однако первопричиной была возможность для злоумышленников запускать вредоносные модели ИИ и процедуры обучения на инфраструктуре SAP. Это позволило нам получить первоначальный доступ к общей сети».
«Похоже, что большое доверие было оказано компоненту брандмауэра, который должен был отделять ненадежные вычисления клиентов от конфиденциальных внутренних служб. Однако, как только мы смогли обойти продукт брандмауэра, мы сразу же получили свободный доступ к внутренней сети. Правильная изоляция должна основываться на нескольких «барьерах безопасности», ряде препятствий, которые должен преодолеть злоумышленник. Предыдущая настройка службы содержала только один барьер безопасности, «единственную линию обороны». Как только эта линия нарушена, возможность скомпрометировать внутренние службы становится намного проще».
SAP не потребовалось много времени, чтобы разобраться с первоначальным исправлением. Wiz сообщил об ошибках в конце января, и примерно через три недели вышел патч, исправляющий эксплойт Istio.
Однако к концу февраля исследователи заявили, что нашли две новые ошибки, которые снова предоставили доступ к внутренней сети. К середине мая SAP устранила все уязвимости.
Бен-Сассон сказал The Reg: «Для SAP имело бы смысл отдать приоритет исправлению уязвимости обхода брандмауэра, поскольку все остальные уязвимости, о которых мы сообщили, зависели от нее. Это могло бы позволить им быстро и эффективно устранить весь поток атак, а затем продолжить устранение остальных проблем. Это передовая практика в отрасли. Команда безопасности SAP была очень профессиональна в своих сообщениях и держала нас в курсе исправлений, которые они развернули, чтобы мы могли их проверить».
«Наше исследование SAP AI Core демонстрирует важность глубокой защиты», — говорит Виз. «Главным препятствием безопасности, с которым мы столкнулись, была Istio, блокирующая наш трафик от попадания во внутреннюю сеть. Укрепление этих внутренних служб могло бы минимизировать влияние этой атаки и понизить ее с полного захвата службы до незначительного инцидента безопасности». ®
