localhost サービス

127.0.0.1 で待ち受けるプロセスも、権限境界になり得る。待ち受けの見つけ方はネットワークと IPCを参照する。このページでは、見つけたサービスの接続権限と処理内容を調べる。

観察

ss -ant
ps auxww | grep -E '<port>|<service>'

127.0.0.1 上の root 権限のサービス、一般ユーザーの開発サーバ、HTTP 以外のプロトコルを使うサービス、管理 UI は、権限昇格や横移動の入口になり得る。

root の管理アプリが localhost だけで action を実行する。sudo が拒否されていても、この action が権限境界になる。
HTTP を話さない待受（OPC UA など）は専用 client が要る。curl が失敗しても到達不能ではない。
管理 UI のパラメータが、後段の command injection の入力になる。
root 権限で動く組み込み HTTP サーバが保存したファイルをスクリプトとして実行する設定なら、公開ディレクトリへの書き込みがコード実行につながる。
言語ランタイムの debug port（Node inspector の 9229 など）は、そのプロセスのユーザーでファイルを読む入口になる。所有 PID、cmdline、UID を残す。
外部プロトコルで入ったあと、次の境界が localhost の daemon と Unix socket になる。socket 側はUnix socket とファイルディスクリプタ。

仮説

低権限ユーザーから localhost service に接続できる。
service の実行ユーザーが現在のユーザーより高権限である。
Web API、独自プロトコル、ファイル保存、管理 action のどれかが、user-controlled input を高権限処理へ渡す。

確認方法

curl -i --max-time 3 http://127.0.0.1:<PORT>/
nc -vz 127.0.0.1 <PORT>
tr '\0' ' ' < /proc/<PID>/cmdline
ls -l /proc/<PID>/fd

目的: 到達性、プロトコル、実行ユーザー、公開ディレクトリまたは作業ディレクトリを確認する。
前提条件: service を詰まらせない。未知のバイナリプロトコルへ大量の手入力をしない。
出力の解釈: HTTP が返れば経路を列挙する。401 なら認証情報を探す。独自プロトコルなら実装コードか専用クライアントを探す。
失敗した場合の切り分け: tunnel の向き、IPv6 の bind、Basic auth、Cookie、protocol の違い、service の詰まり。
代替: SSH の -L、Meterpreter の portfwd、socat、/proc/net/tcp。
状態変更: curl と nc は接続ログを残す。POST や protocol command は状態変更になる。

結論の書き方

確認済み: <port> に現在ユーザーから接続でき、ps で <user> 実行と確認した。
推定: document root や UID から、<service> が対象ファイルを読める可能性がある。
未確認: socket owner、認証方式、実際に読めるファイル範囲は未確認。

localhost での待ち受けは、外部から直接接続できない設定を示す。同一ホスト、SSH トンネル、コンテナの共有ネットワークから接続できる場合がある。root や別ユーザーが動かすサービスは権限境界として扱う。

処理の中身は独自コードの信頼境界で、入力元から sink までつなぐ。