Введение
Orca Security недавно обнаружила недостаток дизайна в сервисе Google Cloud Build под названием Bad.Build. Этот недостаток представляет серьезную угрозу безопасности, поскольку позволяет злоумышленникам выполнить повышение привилегий, предоставляя им несанкционированный доступ к репозиториям кода Google Artifact Registry.
Последствия этой уязвимости распространяются на цепочку поставок программного обеспечения, поскольку злоумышленники могут использовать ее для манипулирования образами приложений со злыми намерениями. Следовательно, ничего не подозревающие пользователи и клиенты, устанавливающие подделанные приложения, могут стать жертвами инфекций.
Эта ситуация напоминает нам о значительном воздействии, которое наблюдалось в прошлых атаках на цепочки поставок, таких как SolarWinds, 3CX и MOVEit, подчеркивая далеко идущие последствия подобных нарушений безопасности.
Как это работает?
Google Облачная сборка выступает как непрерывная интеграция/непрерывная поставка (CI/CD) сервис, предлагаемый в экосистеме Google Cloud. Он играет важную роль в облачных приложениях, бесперебойно взаимодействуя с другими важными сервисами, такими как Artifact Registry и App Engine.
Данная уязвимость возникает из-за проблемы с чрезмерными привилегиями. В частности, «logging.privateLogEntries.list” действие непреднамеренно позволяет отнести журналы аудита к непредусмотренной роли, а именно: “роли/cloudbuild.builds.builder".
К сожалению, эта роль по умолчанию назначена учетной записи службы облачной сборки. Эта ситуация представляет собой серьезный риск, поскольку журналы аудита содержат конфиденциальную информацию, раскрывающую все разрешения, связанные с проектом. Этот непреднамеренный доступ дает злоумышленникам возможность выдавать себя за учетную запись облачной сборки, тем самым получая информацию о том, какие действия могут выполняться различными учетными записями Google. Следовательно, это открывает двери для горизонтального перемещения и повышения привилегий, что представляет собой чрезвычайно опасную уязвимость безопасности.
Для олицетворения учетной записи службы сборки требуется только Cloudbuild.builds.create разрешение, которое есть у многих предопределенных ролей и которое предоставляется разработчикам в любом разумном объеме CI/CD среда с использованием Cloud Build. Так что если у вас есть доступ к одной из таких учетных записей разработчика, создание файла конфигурации сборки, настроенного на заказ, фактически запустит команда чтения журнала gcloud, в котором будут перечислены разрешения.
Но на этом проблема не заканчивается: Учетная запись службы Google Cloud Build имеет высокие привилегии, со множеством действий для взаимодействия с реестром артефактов Goggle.
Используя уязвимость, которая позволяет выдавать себя за учетную запись службы Cloud Build по умолчанию, злоумышленники получают возможность подделывать изображения, хранящиеся в реестре артефактов Google, путем внедрения вредоносного кода. Следовательно, любые приложения, созданные на основе этих скомпрометированных образов, становятся уязвимыми к потенциальным последствиям, включая атаки типа «отказ в обслуживании» (DoS), кражу данных и распространение вредоносного ПО.
Серьезность ситуации возрастает, когда эти измененные приложения предназначены для развертывания в средах клиентов, будь то on-premise или полу-SaaS. Это расширяет риск за пределы инфраструктуры организации-поставщика, что приводит к атаке на цепочку поставок, которая проникает и ставит под угрозу среды клиентов. Такие атаки похожи на предыдущие инциденты, наблюдавшиеся при нарушениях цепочки поставок программного обеспечения, такие как нарушение SolarWinds. Последствия такой атаки могут быть серьезными, вызывая широкомасштабный ущерб и затрагивая несколько организаций в цепочке поставок
Похожий PoC по повышению привилегий был Лаборатория безопасности Rhino, который по-другому использовал чрезмерные привилегии учетной записи Cloud Build по умолчанию.
Почему это опасно?
Серьезность этой уязвимости заключается в том, что злоумышленники могут воспользоваться реестром артефактов и внедрить в артефакты вредоносный код. В результате любые приложения, созданные на основе этих скомпрометированных образов, становятся уязвимыми к различным неблагоприятным последствиям.
Эти эффекты включают возможность атак типа «отказ в обслуживании», кражу данных и распространение вредоносного ПО. Более того, если эти скомпрометированные приложения впоследствии развертываются on-premise или в полу-SaaS-среде риск выходит за рамки организации-жертвы и влияет также на ее клиентов. Этот сценарий напоминает атаку на цепочку поставок, произошедшую в инциденте SolarWinds, подчеркивая потенциальные последствия как для организации, так и для ее клиентской базы.
-
Рекомендация Ксигени
Примените принцип наименьших привилегий
- Датчик кислорода отслеживает действия пользователей в системах, где он развернут, и передает их нашей основной платформе, которая выявляет необычное поведение или отклонения от нормальных шаблонов, например необычные login время или место, передача больших объемов данных или изменения в правах доступа пользователей, выходящие за рамки моделируемого «нормального» поведения пользователя.
Политики и аудит Xygeni реализуют лучшие практики в области контроля доступа, требований многофакторной аутентификации и приложений с ролевыми разрешениями для ограничения доступа пользователей к критически важным системам и данным.
Эти инструменты отслеживают действия пользователей, такие как изменения кода, доступ к системе или передачу данных, и сравнивают их с предопределенными политиками и моделями поведения. Они также отмечают подозрительные действия, такие как несанкционированный доступ, чрезмерные привилегии или необычные схемы передачи данных..
Как была устранена уязвимость
Уведомив команду безопасности Google об уязвимости, они приняли меры, отозвав разрешение logging.privateLogEntries.list у учетной записи службы Cloud Build по умолчанию. Они признали, что, хотя журналы аудита setIamPolicy важны для целей аудита, предоставление доступа к этим журналам с точки зрения учетной записи службы облачной сборки не является необходимым.
Однако важно понимать, что этот ответ не затрагивал напрямую корневую уязвимость в реестре артефактов. В результате вектор повышения привилегий и потенциальный риск атаки на цепочку поставок остались неизменными. По сути, исправление Google ограничило проблему, но не устранило ее полностью, в результате чего организации по-прежнему подвергаются значительным рискам в цепочке поставок программного обеспечения.
В ответ на ситуацию Google посоветовал своим клиентам изменить разрешения учетной записи службы Cloud Build по умолчанию, удалив все учетные данные, которые отклоняются от принципа наименьших привилегий (PoLP). Эта мера направлена на повышение безопасности, гарантируя, что учетные записи имеют только минимально необходимые привилегии для выполнения намеченных задач.
Чтобы защититься от этой атаки повышения привилегий, необходимо ограничить разрешения, предоставленные учетной записи службы Cloud Build, и быть осторожным, предоставляя Cloudbuild.builds.create разрешение всем пользователям в вашей организации. Самое главное, вам нужно знать, что любой пользователь, которому предоставлено Cloudbuild.builds.create, также косвенно предоставляются все разрешения, предоставленные учетной записи службы Cloud Build. Если вас это устраивает, то, возможно, вам не нужно беспокоиться об этом векторе атаки, но все же настоятельно рекомендуется изменить разрешения по умолчанию, предоставленные учетной записи службы Cloud Build.
Google рекомендует это кратко, но не дает более подробной информации:
«Если вы не планируете выполнять какое-либо действие в рамках процесса сборки, мы рекомендуем отозвать соответствующее разрешение у учетной записи службы Cloud Build в целях соблюдения принципа безопасности наименьших привилегий».
Лента
Однако важно отметить, что средство защиты Google не полностью устранило обнаруженный вектор повышения привилегий (PE). Вместо этого он ограничил его влияние, фактически превратив его в конструктивный недостаток, который по-прежнему подвергает организации более широкому риску атаки на цепочку поставок. Следовательно, командам безопасности необходимы дополнительные меры для защиты от этого сохраняющегося риска.
Заключение
Чрезмерные привилегии, предоставленные учетной записи Google Cloud Build по умолчанию, могут быть использованы злоумышленниками для организации атаки с использованием учетной записи разработчика, позволяющей создавать облачную сборку. Злоумышленники могут украсть образ контейнера, исказить его вредоносным поведением, а затем отправить его в реестр артефактов в ходе атаки на цепочку поставок программного обеспечения, которая может иметь разрушительные последствия.
Ответ Google оставляет работу по смягчению последствий для организаций, использующих службу Cloud Build, которым необходимо отозвать привилегии для контроля риска. Можно попросить Google предоставить дополнительную помощь в будущем для решения проблем безопасности с их CI/CD системы.
Референсы
- Работа по назначению: повышение привилегий RCE до IAM в облачной сборке GCP. Лаборатории безопасности Rhino.
- Bad.Build: уязвимости PE и RCE в Google Cloud Build. Орка Безопасность.
- Бюллетень по безопасности. Гугл Облако.
Узнайте больше о платформе Xygeni, загрузив техническое описание платформы Xygeni.
