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に与えられていますが、デフォルトのアクセススコープが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キーの正規表現
参考
Last updated