コンテンツにスキップ

すでにアクセスできるアプリ、ユーザー、サービスに関係する資格情報と設定を探す。ファイルシステム全体を無差別に検索しない。

設定ファイルの探索先は、プロセスと systemdで確認した EnvironmentFile と ExecStart、ファイルとディレクトリ権限で確認した読み取り可能な範囲から決める。

追加確認例:

ターミナルウィンドウ
env
printenv
history
grep -RniE 'pass(word)?|secret|token|key|credential' <TARGET_DIRECTORY>
find <TARGET_DIRECTORY> -maxdepth <N> -type f
  • 目的: アクセスできる範囲にある資格情報と設定を探す。
  • 前提条件: 理由のあるディレクトリに限定する。/ 全体は検索しない。
  • 何を確認しているか: .env、config.php、wp-config.php、EnvironmentFile、生成物のメタデータ、SSH 鍵、サービスの起動引数。
  • 期待される出力: DB の認証情報、Basic 認証情報、Flask の秘密鍵、SSH 秘密鍵、SMTP のパスワード。
  • 出力の解釈: 資格情報は「どのアカウントのものか」と「どこで使えるか」をセットで記録する。別のサービスでの再利用は、確認するまで推定に留める。
  • 失敗した場合の切り分け: ファイル権限、別ユーザーのホームディレクトリ、コンテナ内外のパス差、base64 / JSON / YAML、起動引数に含まれる資格情報を確認する。
  • 代替コマンド: grep -Rni --include='*.env' --include='*.conf' ..., find /opt/<app> -maxdepth 4 -type f -ls。
  • 状態変更: 読み取り専用。history や設定ファイルには秘密値が出る。writeup に掲載する場合は伏せる。

値そのものは書かない。アカウントと、最初に使った先がセットで残っていない記録は、再利用できたこととして扱わない。

  • PID 1 やサービスプロセスの環境変数に、別ユーザーとして SSH 接続するための資格情報がある。確認方法はプロセスと systemdにまとめた。
  • Web アプリの設定(wp-config.php や .env)のパスワードは、同じ文字列のログインユーザーへ再利用できるか、ログイン先を特定してから確認する。
  • アプリの DB から得たハッシュや平文は、SSH できるユーザーと対応づける。ハッシュは解析してから使う。
  • アプリが持つクラウドの資格情報は、内部 API やキューワーカーの実行権限とセットで記録する。コンテナ内の root 権限とは別に扱う。境界の確認はコンテナと名前空間を参照する。
  • systemd の EnvironmentFile と ExecStart は、localhost の管理 action がどの資格情報で動くかを示す。