こんにちは
1年間大事に育てた観葉植物がこの冬で見事に枯れて泣きそうな尾崎です。
今日はワードプレスにあるxmlrpc.phpについてまとめてみようかなと思います。
AIが書いた記事ってなんか読む気失せますよね(僕だけかな?)
なのでこのAI時代に逆張りして、手書きで記事書いてみようかなと思います。
調べようと思った経緯
私が学生だった頃、需要0の個人ブログを開設したんですよね。
作って早々スパムコメントの嵐。そして見事にIDパスを盗まれて乗っ取られました。
なんて天才なハッカーがいるのだ!とか当時思ってましたけど、普通にadmin/passとかいうIDパス設定してたら素人でも乗っ取れますよね。
18歳の私。
もう少し頭を使え。
そんな経験もあり、WPサイトに対する攻撃方法とその防ぎ方を学んでいったわけです。
今回その中でも取り上げるのがこのxmlrpc.php
これなんのためにあるんや?と思っている人もいるはず。
ある事も知らない人もいるはず。
1つづつまとめていけたらなと思います。
xmlrpc.phpとは??
一言で言えば、xmlrpc.phpは
「外部のアプリケーションからWordPressを遠隔操作するための専用の出入り口(API)」
です。
コレだけ聞いても危険な香りがプンプンしますよね。
どうやら、WordPressがまだ黎明期だった頃に、スマホやら外部のエディタから記事を投稿したり、他のブログシステムと連携するために統一されたプロトコルが必要だったようです。
それがXML-RPCであり、その窓口となるのがxmlrpc.phpファイルだったみたいです。
ワードプレスの公式ドキュメントを見てみるとこんな作業ができるようです。
| カテゴリ | 主な操作(メソッド) | 具体的な内容 |
|---|---|---|
| 投稿 (Posts) | wp.newPost, wp.editPost | 新しい記事の投稿、既存記事の編集・削除。 |
| コメント (Comments) | wp.newComment | 特定の記事に対する新しいコメントの投稿。 |
| メディア (Media) | wp.uploadFile | 画像や動画などのファイルをWordPressにアップロード。 |
| ユーザー (Users) | wp.getUsers, wp.getProfile | ユーザーの一覧やプロファイル情報を取得。 |
| システム (System) | system.multicall | 複数の操作(メソッド)を一度のリクエストでまとめて実行。 |
| ピンバック | pingback.ping | 他のサイトからのリンクを通知。 |
当たり前ですけど、まあまあ何でも出来ますよね。
気になる方は以下のリンクをクリックしてみてみてください。
参考: WordPress Codex – XML-RPC WordPress API
何が危険なの?脆弱性トップ2
外部からWordPressサイトを編集できるだけで、IDパスワードが漏れなければ問題ないじゃない!
と思った方もいるはず。
私もそう思いましたから。
何がダメなのか。
一言で言えば超レガシーだからです。古すぎる。
ID/パスを毎回送信するような単純な認証や、何百ものID/パスを単一のリクエストにまとめて送信で来てしまうことで、レート制限を潜り抜けて総当たり攻撃ができてしまうんです。恐ろしい。
ちょっと詳しくまとめてみましょう。
脆弱性1:増幅された総当たり攻撃
一般的な総当たり攻撃では、/wp-login.phpを標的として行われます。
大体がBotを使って、使用率の高いIDパスを全て試すやり方。これはプラグインやサーバー側の設定でレート制限に引っかかりやすく、検知、ブロックできることが多いです。
18歳の私が設定したadmin/passとかいうクソみたいな設定をしている人はもうこの時点でアウトです。
それがxmlrpc.phpを使うとどうなるか?
xmlrpc.phpファイルにはsystem.multicallという関数があるんです。
この関数は元々開発者が、複数のコマンドを単一のHTTPリクエストにまとめて作業を効率化するために作成されたものです。が。コレが大問題。
複数のリクエストを単一のリクエストにまとめられるということは、何百何千ものID/パスを単一のリクエスト送信で検証することができるんです。そう。レート制限やプラグインの検知に引っかかりずらいんです。
表面上は500アクセスでも、1リクエストに500回分のコマンドがあれば250,000通り試されてしまうわけです。
脆弱性2:DDos攻撃の踏み台にされる
DDos攻撃は分かりますよね。
分からないあなた。そんな事もあっていいでしょう。
さまざまなソースから大量にアクセスしてサーバーを圧倒して使用不能にする攻撃です。
この、攻撃用のソースに使用されてしまう危険性があります。
ピンバック機能が悪用されてしまうんです。
攻撃者は攻撃対象になるサイトAのURLを設定し、xmlrpc.phpを通してリクエストを送信してしまう。
そうすると
攻撃者→我々のWPサイト→攻撃対象のサイトA
という流れでリクエストが飛びます。
人様に迷惑をかけてはいけない!!日本人ならば!!
代替手段:WordPress REST API
なら外部からWordPressサイト変更したい時どうすればいいんだYO!
大丈夫。
もう新しいのが出てるんです。
頭のいい人ありがとう。
WordPress REST APIです。
今回は軽く紹介くらいにしておきますが、必ずこちらを使ってくださいね。
| 比較項目 | WordPress REST API(モダン) | XML-RPC(レガシー) |
|---|---|---|
| データ形式 | JSON(軽量で高速) | XML(冗長で処理が重い) |
| 認証方式 | OAuth, Application Passwords, Cookie認証など、セキュアで多様な方式に対応 | 基本的にユーザー名とパスワードを毎回送信する単純な認証のみ |
| セキュリティ | nonceやトークンによるリクエスト検証、きめ細やかな権限管理が可能 | 認証情報が盗まれやすく、system.multicallによる総当たり攻撃の増幅リスクがある |
| パフォーマンス | 軽量なJSON形式のため高速に動作 | 重量なXML形式のため、通信量が多くなりがちで低速 |
| 柔軟性と拡張性 | 開発者が独自のAPIエンドポイントを簡単に追加できる | 定義済みの限られた操作しか実行できない |
| 開発の活発さ | WordPressコアの一部として活発にメンテナンス・機能改善が続いている | 新しい機能が追加されることはなく、レガシー機能として維持 されているのみ |
xmlrpc.phpは必要ない?無効化していい?
答えはYES
今すぐ無効化してください。
まさに100害あって1利なし。
過去のWEBサイトがxmlrpc.phpを前提に開発され、使い続けられている可能性があるため、後方相互性を維持するために今でもデフォルトで有効化されているようです。
まあアップデートを重ねる分にはいいんだけどさ。
新規でインストールした時くらい無効化しておいてくれよって思いますけどね。。。
自分のサイトで有効化されているか調べる方法
このサイトにURLを記載してチェックボタンを押すだけ。
この記事を読んでヤバイかもと思ったそこのあなた。
今すぐ確認してみましょう。
無効化する方法
・ワードプレス側のプラグインDisable XML-RPCをインストール後有効化する
・WAFでブロックする
・サーバー側で.htaccessに追記する
“`
# Block XML-RPC completely
<Files “xmlrpc.php”>
Require all denied
</Files>
“`
方法は検索すればたくさん出てくるので割愛しますが、一番楽なのはプラグインを入れる事かなと思います。
最後に
AI時代にAIを悪用する人なんて山ほどいるわけで、攻撃の手口も複雑化していくと思います。
こういった初歩的な部分から見直して、安全にWEBサイトを運営していきましょう〜!
さぁ!
記事を長々と記載して疲れたので町田商店のネギラーメン大盛りでも今日は食べるとします。
\ギットギトのニンニクまっしましが一番美味い/