GCP - local privilege escalation ssh pivoting
このシナリオでは、Compute Engine プロジェクト内の VM で 特権のないアカウントを侵害したと仮定します。
驚くべきことに、侵害した Compute Engine の GCP 権限を利用して、マシン内でローカル権限を昇格することができるかもしれません。クラウド環境では常に非常に役立つわけではありませんが、可能であることを知っておくことは良いことです。
スクリプトを読む
Compute Instances はおそらく、サービスアカウントを使用してアクションを実行するために いくつかのスクリプトを実行するために存在しています。
IAM が非常に細かくなっているため、アカウントはリソースに対する 読み取り/書き込み 権限を持っていても リスト権限を持っていない 場合があります。
これの素晴らしい仮想的な例は、instance82736-long-term-xyz-archive-0332893
というストレージバケットにバックアップを読み書きする権限を持つ Compute Instance です。
コマンドラインから gsutil ls
を実行すると何も返されませんが、サービスアカウントには storage.buckets.list
IAM 権限が不足しているためです。ただし、gsutil ls gs://instance82736-long-term-xyz-archive-0332893
を実行すると、ローカルのLinuxアカウントにはないデータへの平文アクセスが可能な完全なファイルシステムバックアップが見つかるかもしれません。
このバケット名をスクリプト(bash、Python、Rubyなど)の中で見つけることができるかもしれません。
カスタムメタデータ
管理者は、インスタンスおよびプロジェクトレベルで カスタムメタデータ を追加できます。これは単に 任意のキー/値ペアをインスタンスに渡す方法であり、環境変数や起動/シャットダウンスクリプトに一般的に使用されます。
さらに、ユーザーデータを追加することも可能で、これはスクリプトであり、マシンが起動または再起動されるたびに 実行され、メタデータエンドポイントからもアクセスできます。
詳細については、次を確認してください:
IAM 権限の乱用
以下の提案されたほとんどの権限は、デフォルトの Compute SA に与えられていますが、デフォルトのアクセススコープがそれらの使用を妨げています。ただし、cloud-platform
スコープが有効になっているか、compute
スコープが有効になっている場合、これらを 乱用できるかもしれません。
次の権限を確認してください:
ファイルシステム内のキーを検索
他のユーザーがボックス内で gcloud にログインし、その資格情報をファイルシステムに残していないかを確認してください:
これらが最も興味深いファイルです:
~/.config/gcloud/credentials.db
~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json
~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto
~/.credentials.json
より多くのAPIキーの正規表現
参考文献
最終更新