GCP - local privilege escalation ssh pivoting

Підтримайте 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...).

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

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

Більше того, можливо додати userdata, що є скриптом, який буде виконуватись щоразу, коли машина запускається або перезавантажується, і до якого можна доступитися з кінцевої точки метаданих також.

Для отримання додаткової інформації перегляньте:

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

Більшість з наступних запропонованих дозволів надаються за замовчуванням обліковому запису Compute 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"

Посилання

Підтримати HackTricks

Last updated