【ログイン画面の攻撃者目線】何を狙う？どう守る？｜CTF思考フレームワーク #01
安全に生きたい編集部
安全に生きたい
【SUID・sudoers深掘り編】GTFOBinsの裏側を読み解く｜CTF思考フレームワーク P02
安全に生きたい編集部
こんにちは、アンペンです！権限昇格ルートP02はSUID・sudoers深掘り編。P01でさらっと触れたSUIDバイナリとsudoの誤設定を、攻防両用のリファレンスGTFOBinsを軸に具体的に掘り下げます。「許可した一つの作業」が、なぜroot奪取の入口になるのか——その理屈と防ぎ方をセットで学びましょう。
ここで多くの人が引っかかる素朴な疑問——『findコマンドにsudoを許しただけで、なんでroot全部を取られるの？』。答えはちょっと意外で、“多くのコマンドは、内部から別のコマンドを呼び出せる”からです。つまり『この作業だけ許可』したつもりが、その道具が“別の何か”を呼べると、許可の枠を飛び越えてしまう。今日はその仕組み（シェルエスケープ）と、攻防どちらでも使える早見表GTFOBinsを軸に見ていきます。
findやvimにsudoを許可しただけで、なんでrootが取られるの？
多くのコマンドは『中から別のコマンドを呼ぶ』機能を持つからなんだ。findには-exec、vimには:!shがある。root権限で動くそれらからシェルを起動(シェルエスケープ)すれば、root shellが手に入る。どのバイナリがどう悪用できるかを集めたのがGTFOBins。守る側はこれを『与えてはいけないリスト』として使うんだ。
まず結論
SUID・sudoの悪用とは「root権限で動くバイナリからシェルエスケープしてroot shellを得ること」。多くのコマンドは内部から別コマンドやシェルを呼べるため(find -exec・vim :!sh等)、それがroot権限で動くと昇格の入口になる。どのバイナリがどう悪用できるかはGTFOBinsに集約され、攻撃側は悪用法、守る側は『与えてはいけないリスト』として使う。さらにsudoのenv_keep経由のLD_PRELOADやワイルドカードsudoルールも危険。守る側は『不要なSUIDを削除＋sudoは特定コマンドに限定＋シェルエスケープ可能なバイナリに権限を与えない＋env_resetを徹底＋sudoを最新に』。
この記事で分かること
- SUID/sudoがなぜroot奪取の入口になるのか(シェルエスケープ)
- GTFOBinsの読み方と、攻防両用での使い方
- sudo -lの出力をどう解釈するか
- env_keep経由のLD_PRELOADとワイルドカードの罠
- 守る側の「危険な権限を与えない」チェックリスト
📖 はじめてのWebセキュリティP02｜SUID・sudoers深掘り編
GTFOBinsを軸に、SUIDとsudoの悪用と防御を具体的に掘り下げる。 シリーズ一覧を見る →
⚠️ 大事なお約束
SUID/sudoの悪用は侵入後の権限昇格手法です。他人のサーバで試すのは不正アクセス禁止法に直結します。本記事の手順は自分で構築したVM・CTF・書面で許可された検証環境に限定してください。本記事の目的は防御側の理解です。「できる」と「やってよい」は全く別です。
Contents
なぜ「一つの許可」がrootになるのか
- SUIDの悪用:root所有のSUIDバイナリがシェルや別コマンドを呼べると、その子プロセスもroot権限。例:
find . -exec /bin/sh \; -quit - sudoの悪用:
sudo -lで許可されたコマンドがシェルエスケープ可能なら、そこからroot shell。例:sudo vim→:!sh - env_keep経由のLD_PRELOAD:sudoが環境変数を引き継ぐ設定だと、悪意ある共有ライブラリをロードさせてroot実行できる
- ワイルドカードの罠:sudoルールに
*があると、想定外の引数を注入して別の動作をさせられる - sudo自体の脆弱性:過去には
Baron Samedit(CVE-2021-3156)のような重大な脆弱性も。版数管理が重要
5つに共通する核心は、たった一つ——『root権限で動くものから、別のシェルを起こす』ことです。これをシェルエスケープと呼びます。vimの中から :!sh でシェルに抜ける、findの -exec で別コマンドを走らせる…どれも『そのコマンド本来の便利機能』を、root権限のまま悪用しているだけ。新しい穴を開けるのではなく、“もとからある扉”を別の用途に使う、というのがポイントです。
ここで覚える用語:GTFOBins
意味:Unix系バイナリの「本来の用途を超えた悪用法」をまとめた公開データベース。SUIDやsudoで許可されたバイナリからシェル昇格・ファイル読み書き・ネット転送する方法を一覧化しています。
例:sudo -lで(root) NOPASSWD: /usr/bin/findが見えたら、GTFOBinsでfindのsudo項を引く→sudo find . -exec /bin/sh \; -quitでroot shellが起動する、と分かる。
使いどころ:攻撃側は悪用法の早見表、守る側は『このバイナリにsudo/SUIDを与えると危ない』を判断する防御リストとして使います。両用リファレンスです。
たとえで理解する：代行印鑑の落とし穴
🖋️ たとえるなら、特定の書類だけ許した代行印鑑
SUIDやsudoは、社員に渡す『この作業だけ社長印を押していい』という代行印鑑に似ています。経理に「請求書にだけ社長印を」と渡したつもりが、その印鑑は物理的にはどんな書類にも押せてしまう。悪用する人は、請求書を装って白紙委任状(=root shell)に押印してしまうのです。これがシェルエスケープ。vimやfindのように『中から何でも呼べる』道具に代行権を渡すと、用途を逸脱されます。GTFOBinsは「どの代行印鑑が、どんな悪用に使えるか」の早見表。だから守る側は、渡す印鑑(権限)を最小限にし、何でも押せてしまう道具には最初から代行権を与えないのが鉄則です。
env_keepとLD_PRELOAD：環境変数の抜け道
SUID/sudoの直接悪用に加えて、見落としがちなのが環境変数の抜け道です。sudoは本来、安全のために環境変数をリセットしますが、設定で一部を引き継ぐようにしていると、そこが昇格経路になります。仕組みを知ると、なぜ「env_resetの徹底」が定番の守りなのかが腑に落ちます。
もう少しだけ噛み砕くと、LD_PRELOAD は『プログラムを動かす前に、指定した部品（ライブラリ）を先に読み込ませる』機能です。本来は開発で便利に使うもの。でも、sudoがこの設定を引き継いでしまうと、攻撃者が用意した“仕込み入りの部品”を、root権限のプロセスに先回りで読み込ませられる。だからsudoは原則『環境変数をリセット（env_reset）』して、こうした抜け道を塞ぐわけです。
ここで覚える用語:env_keepとLD_PRELOAD
意味:LD_PRELOADは、プログラム起動時に指定した共有ライブラリを先に読み込ませる仕組み。sudoのDefaults env_keep += LD_PRELOADのように環境変数が引き継がれると、悪意あるライブラリをroot実行のプロセスに割り込ませられます。
例:攻撃者が用意した.soをLD_PRELOADに指定してsudo実行→ライブラリの初期化コードがroot権限で走りroot shellを得る。
使いどころ:守る側はDefaults env_resetを徹底し、env_keepに保持する変数を必要最小限にします。安易なLD_PRELOAD/LD_LIBRARY_PATHの保持は厳禁です。
CTFでやってみよう：GTFOBinsで攻防を往復する
やってみよう / 自分のVM・CTFのみ
「許可した権限が、どう悪用され、どう塞ぐか」を手で往復する
対象は必ず自分で構築したVMかCTFです。攻撃→照合→修正の順で、SUID/sudoの危険と守りを体で覚えます。各ステップに「なぜやるか」を添えました。
find / -perm -4000 -type f 2>/dev/nullでSUID列挙 → なぜ:悪用候補を洗い出すため- 各SUIDバイナリ名を
GTFOBinsで照合 → なぜ:悪用可否を判定するため sudo -lで許可コマンドを確認 → なぜ:sudo経路を把握するため- 許可コマンドをGTFOBinsのsudo項で照合 → なぜ:シェルエスケープの可否を見るため
- sudoの
Defaults(env_keep/env_reset)を確認 → なぜ:LD_PRELOADの余地を見るため - ワイルドカード付きsudoルールがないか点検 → なぜ:引数注入の余地を見るため
- テスト環境で意図的に脆弱なSUID/sudoを作り再現 → なぜ:仕組みを実感するため
- 各経路を修正(SUID削除・sudoルール限定・env_reset) → なぜ:守りを手で確認するため
対象は必ず自分のVM・CTFのみ。他人のサーバでの試行は不正アクセスです。「できる」と「やってよい」は別です。
では守り方ですが、合言葉は『何でも呼べる道具には、特権を渡さない』。vim・find・less・awk・python——便利な道具ほど“中から別のものを呼ぶ力”を持っていて、それがそのままシェルエスケープの入口になります。だから権限を渡す前に、GTFOBinsで『この道具、悪用できる？』と一度引いてみる。次のチェックリストは、その判断を運用に落とし込んだものです。
守る側：危険な権限を与えない
SUID・sudoers堅牢化チェックリスト
- 不要なSUID/SGIDを削除:
find / -perm -4000で棚卸しし、必要最小限に - sudoは特定ユーザー・特定コマンドに限定:NOPASSWDとフルパス指定を徹底
- シェルエスケープ可能なバイナリに権限を与えない:
vim/find/less/awk/python等(GTFOBins掲載)に注意 - sudoersのワイルドカードを避ける:引数注入を防ぐため
*を使わない - env_resetを徹底:
env_keepを最小化し、LD_PRELOAD/LD_LIBRARY_PATHを保持しない - sudoを最新に:Baron Samedit等の既知CVEを塞ぐ
- visudoと構文チェック:編集は必ず
visudoで行い、変更を監査ログに残す - GTFOBinsを運用に組み込む:「与えてはいけないバイナリ一覧」として参照する
GTFOBinsは攻撃にも守りにも使える早見表なんだね。何でも呼べる道具に権限を渡さない、覚えたよ！
その視点が守りの核心だよ。次はP03、Windowsローカル権限昇格編。Linuxとは作法が変わって、サービスの設定ミス・レジストリ・MSIといったWindows特有の入口を扱うよ。
まとめ：シェルエスケープを許さない設計
今回のポイント
- SUID/sudoの悪用の核心はシェルエスケープ(root権限で別コマンドを呼ぶ)
- GTFOBinsは攻防両用——守る側は「与えてはいけないリスト」
env_keep経由のLD_PRELOADとワイルドカードも危険- 守りは不要SUID削除・sudo限定・危険バイナリに権限を与えない
- env_reset徹底・sudo最新化・visudo・監査で隙間を消す
今日の持ち帰りは『“この作業だけ”の許可が、なぜか全権限になる』。原因はシェルエスケープ——便利な道具の“別を呼ぶ力”です。守る側は、渡す権限を最小に絞り、何でも呼べる道具には最初から渡さない。GTFOBinsを“与えてはいけないリスト”として使えば、その判断はぐっと楽になります。
次はP03、Windowsローカル権限昇格編。Linuxとは作法が変わり、サービス・レジストリ・MSIといったWindows特有の入口を読み解きます。
