Wordpress_CVE-2019-9787

Docker と WordPress の自動インストールを使用して、この問題を再現してみてください。

CVE-2019-9787 CSRF の PoC WordPress バージョン 5.1 まで

CVE-2019-9787 の潜在能力を完全に示すには、nginx/iframe-post.html にあるコメントよりも、もっと厄介なコードが必要でしょう。私のコードでは、WordPress の wp_filter_post_kses() の欠陥は使用していません。

テスト目的以外では使用しないでください。

bash を使用したインストール：

リポジトリをコピーします：

git clone https://github.com/matinciel/Wordpress_CVE-2019-9787.git

ディレクトリに移動します

cd Wordpress_CVE-2019-9787

インストールを起動します。docker 18.02.0 以上が必要です（docker -v で確認）

make autoinstall

インストール完了後：

WordPress（デフォルトの管理者アカウント: ログイン名: wordpress / パスワード: wordpress）。 http://localhost でアクセスできます。

セキュリティ問題を再現したい場合：

攻撃者側

1. WordPress にアクセスします（wordpress としてログインしないでください）。http://localhost
2. 「Hello world!」投稿にコメントを残します（「1 Comment」リンクをクリック）。 コメントには次のような内容を含めます（URL だけで十分です）：

私のブログにアクセスしてください：http://localhost:6060

WordPress 所有者（管理者または編集者ロールが必要）

1. http://localhost/wp-admin にアクセスして、WordPress の「バックエンド」にログインします。 ログイン名: wordpress パスワード: wordpress
2. コメントセクションに承認待ちのコメントが表示されるので、リンクをクリックします。
3. http://localhost/wp-admin に戻り、コメントタブをクリックします。何も操作しなくても、新しいコメントがすでに承認されているはずです。

制限事項：

1. iframe 内の悪意のあるコードは、投稿 ID=1（Hello World!）でのみ動作します。
2. 「ハッキングされた」コメントがすでに承認されている場合、再び機能しません。
3. コメントの承認には nonce 保護は不要のようです（他のチュートリアルでは、プラグインやテーマのアクションを使いたいから必要かもしれません）。
4. 前述のとおり、CVE-2019-9787 の潜在能力を完全に示すには、nginx/iframe-post.html にあるコメントよりも、もっと厄介なコードが必要でしょう。私のコードでは、WordPress の wp_filter_post_kses() の欠陥を使用していません。

アンインストール / 再試行 / リフレッシュ：

サービスを停止するには

docker-compose down

すべてのコンテナとそのボリュームを削除するには、次を使用します

docker rm -vf $(docker ps -a -q)

すべてのイメージを削除するには

docker rmi -f $(docker images -a -q)

リポジトリの削除を忘れないでください

cd .. sudo sudo rm -Rf Wordpress_CVE_2019-9787

この作成にコピー/フォークした元プロジェクト：

WordPress の自動インストール用： https://github.com/kassambara/wordpress-docker-compose

CVE の概念実証（WordPress の自動インストールなし）用： https://github.com/rkatogit/cve-2019-9787_csrf_poc

これらのページをこのページにリンクする（公式な）方法があれば教えてください。2 番目のリポジトリのフォークを使用していますが、自分が何をしているのかよく分かっていませんでした :-)