Въведение
Orca Security наскоро откри недостатък в дизайна на услугата Google Cloud Build, наречен „Bad.Build“. Този недостатък представлява сериозен риск за сигурността, тъй като позволява на атакуващите да изпълнят ескалация на привилегиите, предоставяйки им неоторизиран достъп до хранилищата с код на регистъра на артефактите на Google.
Последиците от тази уязвимост се простират до веригата за доставки на софтуер, тъй като нападателите могат да я използват, за да манипулират изображения на приложения със злонамерени намерения. Следователно, нищо неподозиращи потребители и клиенти, които инсталират подправените приложения, могат да станат жертва на инфекции.
Тази ситуация ни напомня за значителното въздействие, наблюдавано при минали атаки върху веригата за доставки, като например 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 да са от значение за целите на одита, предоставянето на достъп до тези регистрационни файлове от гледна точка на акаунта за услугата Cloud Build е ненужно.
Важно е обаче да се разбере, че този отговор не адресира директно уязвимостта в корена на регистъра на артефактите. В резултат на това векторът за ескалация на привилегиите и потенциалният риск от атака върху веригата за доставки останаха незасегнати. По същество, решението на Google ограничи проблема, но не го елиминира напълно, оставяйки организациите все още изложени на значителни рискове за веригата за доставки на софтуер.
В отговор на ситуацията, Google посъветва клиентите си да променят разрешенията на стандартния акаунт за услуга за изграждане на облаци, като премахнат всички идентификационни данни за права, които се отклоняват от Принципа на най-малките привилегии (PoLP). Тази мярка има за цел да подобри сигурността, като гарантира, че акаунтите имат само минимално необходимите привилегии за изпълнение на предвидените им задачи.
За да се защитите от тази атака за ескалация на привилегии, е необходимо да ограничите разрешенията, предоставени на акаунта за услуга за изграждане на облаци, и да бъдете внимателни при предоставянето им. cloudbuild.builds.create разрешение за всички потребители във вашата организация. Най-важното е, че трябва да знаете, че всеки потребител, на когото е предоставено cloudbuild.builds.create, също така косвено получава всички разрешения, предоставени на акаунта за услуга за изграждане на облак. Ако това е наред с вас, тогава може да не е нужно да се притеснявате за този вектор на атака, но все пак е силно препоръчително да промените разрешенията по подразбиране, предоставени на акаунта за услуга за изграждане на облак.
Google препоръчва това сбито, но не предоставя допълнителни подробности:
„Ако не планирате да извършите действие като част от процеса на изграждане, препоръчваме ви да отмените съответното разрешение от акаунта на услугата Cloud Build, за да спазвате принципа за сигурност с най-малки привилегии.“
История
Rhino Security Labs публикуваха информация за проблема с ескалацията на привилегиите и създадоха PoC Python скрипт за него.
Orca Security съобщиха своите открития на екипа по сигурността на Google.
Google проведе разследване и в отговор внедри частично решение.
Важно е обаче да се отбележи, че решението на Google не елиминира напълно открития вектор за ескалация на привилегиите (PE). Вместо това, то ограничи неговото въздействие, като ефективно го превърна в недостатък в дизайна, който все още излага организациите на по-широкия риск от атака срещу веригата за доставки. Следователно, екипите по сигурността са необходими допълнителни мерки, за да се предпазят от този продължаващ риск.
Заключение
Прекомерните привилегии, предоставени на акаунта по подразбиране в Google Cloud Build, могат да бъдат използвани от злонамерени лица за организиране на атака чрез използване на акаунт на разработчик, позволяващ създаването на облачна компилация. Нападателите могат да откраднат образ на контейнер, да го манипулират със злонамерено поведение и след това да го преместят в регистъра на артефактите, при атака срещу веригата за доставки на софтуер, която може да има опустошителни последици.
Отговорът на Google оставя работата по смекчаване на риска на организациите, използващи услугата Cloud Build, които трябва да отменят привилегиите, за да контролират риска. В бъдеще може да се поиска от Google да предостави допълнителна помощ за справяне с проблеми със сигурността на техните... CI/CD система.
Източници
- Работи по предназначение: Ескалация на привилегиите от RCE към IAM в GCP Cloud BuildЛаборатории за сигурност на Rhino.
- Bad.Build: Уязвимости на PE и RCE в Google Cloud BuildОрка Секюрити.
- Бюлетин за сигурностGoogle Облак.
Научете повече за платформата Xygeni, изтеглете информационния лист за платформата Xygeni
