GCP - local privilege escalation ssh pivoting

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

У цьому сценарії ми будемо припускати, що ви зламали обліковий запис без привілеїв всередині віртуальної машини в проекті Compute Engine.

Дивовижно, дозволи GPC віртуальної машини, яку ви зламали, можуть допомогти вам підняти привілеї локально всередині машини. Навіть якщо це не завжди буде дуже корисно в хмарному середовищі, важливо знати, що це можливо.

Прочитайте скрипти

Екземпляри обчислень, ймовірно, там для виконання деяких скриптів для виконання дій з їх службовими обліковими записами.

Оскільки IAM настільки деталізований, обліковий запис може мати привілеї на читання/запис ресурсу, але немає привілеїв на перегляд.

Чудовим гіпотетичним прикладом цього є екземпляр обчислення, який має дозвіл на читання/запис резервних копій у сховище з назвою instance82736-long-term-xyz-archive-0332893.

Виконання gsutil ls з командного рядка нічого не повертає, оскільки службовий обліковий запис не має дозволу IAM storage.buckets.list. Однак, якщо ви виконали gsutil ls gs://instance82736-long-term-xyz-archive-0332893, ви можете знайти повну резервну копію файлової системи, що надає вам доступ до даних у відкритому тексті, якого не вистачає вашому локальному обліковому запису Linux.

Можливо, ви зможете знайти цю назву сховища всередині скрипта (у bash, Python, Ruby...).

Користувацькі метадані

Адміністратори можуть додавати користувацькі метадані на рівні екземпляра та проекту. Це просто спосіб передачі довільних пар ключ/значення в екземпляр, і часто використовується для змінних середовища та скриптів запуску/вимкнення.

Більше інформації дивіться:

Зловживання дозволами IAM

Більшість запропонованих дозволів надаються за замовчуванням обліковому запису обчислювального SA, єдине, що забороняє використання цих SA, це обмеження доступу за замовчуванням, проте, якщо увімкнено область обмеженого доступу cloud-platform або просто область обмеженого доступу compute, ви зможете зловживати ними.

Перевірте наступні дозволи:

Пошук ключів у файловій системі

Перевірте, чи інші користувачі увійшли в gcloud всередині коробки та залишили свої облікові дані в файловій системі:

sudo find / -name "gcloud"

Ось найцікавіші файли:

  • ~/.config/gcloud/credentials.db

  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json

  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto

  • ~/.credentials.json

Додаткові регулярні вирази для ключів API

TARGET_DIR="/path/to/whatever"

# Service account keys
grep -Pzr "(?s){[^{}]*?service_account[^{}]*?private_key.*?}" \
"$TARGET_DIR"

# Legacy GCP creds
grep -Pzr "(?s){[^{}]*?client_id[^{}]*?client_secret.*?}" \
"$TARGET_DIR"

# Google API keys
grep -Pr "AIza[a-zA-Z0-9\\-_]{35}" \
"$TARGET_DIR"

# Google OAuth tokens
grep -Pr "ya29\.[a-zA-Z0-9_-]{100,200}" \
"$TARGET_DIR"

# Generic SSH keys
grep -Pzr "(?s)-----BEGIN[ A-Z]*?PRIVATE KEY[a-zA-Z0-9/\+=\n-]*?END[ A-Z]*?PRIVATE KEY-----" \
"$TARGET_DIR"

# Signed storage URLs
grep -Pir "storage.googleapis.com.*?Goog-Signature=[a-f0-9]+" \
"$TARGET_DIR"

# Signed policy documents in HTML
grep -Pzr '(?s)<form action.*?googleapis.com.*?name="signature" value=".*?">' \
"$TARGET_DIR"

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Last updated