WordPress XML-RPC攻撃

XML-RPCの実行は、WordPressが誕生する前の時代に遡るものです。

ウェブ黎明期、接続速度が非常に遅かった頃、サイトへの投稿と配信は今よりもずっと手間と時間がかかっていました。多くの利用者は直接アプリ内で書くのではなく、オフラインで文章を作成し、後からウェブに投稿していました。しかし、その作業は決して快適とは言えませんでした。

当時の仕組みは、ブログ用のオフライン投稿エディタを使い、文章を作成後にブログへ接続して投稿するというものでした。この接続はXML-RPCを通じて行われました。XML-RPCの基本構造が整うと、初期のアプリでは同様の接続方法を利用し、利用者が他のデバイスからWordPressサイトへログインできるようになりました。

XMLRPCはWordPressよりも古い技術です。この仕組みは、サイトの応答速度の低下という問題を、利用者がオフラインで文章を作成し、後からサーバへ転送することで対処するために取り入れられました。WordPressは、xmlrpc.phpファイルを介して他のアプリと遠隔で接続することが可能です。

実際、熟練のエンジニアでさえ、この技術の仕組みや、発生しうる脆弱性を完全には理解していない場合があります。また、正常に動作するXMLRPC上で設定されたサイトやエンドポイントには注意が必要です。つまり、XMLRPCの動作やその脆弱性について把握しない限り、適切な設定を行うのは難しいということです。

WordPressは既にREST APIによって動作しているという意見もありますが、XMLRPCは依然として中核部分に存在しています。中には、XMLRPCを悪用して、サイトをさまざまなサイバー攻撃に晒す原因となる標準の脆弱性を見つけ出すプログラマーもいます。

さて、XMLRPCは一体何のために使用されているのでしょうか？この技術に伴う脆弱性とは何か、そしてどのように対策すれば良いのか、以下で詳しく解説します。

WordPress XMLRPCとは

簡単に言えば、XMLRPC (リモートプロシージャコール) は、利用者のクロスプラットフォーム通信を支援するために設計されたプロトコルです。このプロトコルは、HTTPを伝送手段、XMLをエンコーダとして方式を決定することを目的としていました。利用者はHTTPリクエストをサーバに送り、その後HTTPレスポンスを受け取ることで呼び出しを行います。XMLRPCはHTTPリクエストを用いて機能を呼び出し、それを使って特定の操作を実行し、固定されたメッセージを送信します。

このプロトコルとREST APIを比較することで、本題の理解が深まります。RESTはURL境界でリソースを取得するのに対し、RPCはリクエスト境界を用いて機能呼び出しのように動作します。

WordPressはXMLRPCプロトコルを用いて、サイトとの遠隔接続を実現しています。また、サイト運営やJetPack、WooCommerceなど特定のモジュールのサポートにもこのプロトコルが利用されています。xmlrpc.phpファイルの使用には脆弱性も存在しますが、完全に無効にするのが最適かどうかは疑問です。以下では、XMLRPCに伴う脆弱性とその対策方法について見ていきます。

WordPressのXML-RPCファイルの脆弱性とは

XMLRPCを利用すると、プログラマーはリモートプロシージャコール (RPC) を操作し、任意のデータ取得機能を実行できます。多くのWordPressサイトに存在するxmlrpc.phpファイルは容易に悪用され、細工されたXMLデータを送ることで、プログラマーが独自に作成したコードでサイトを乗っ取る可能性があります。

WordPressのXMLRPCがどのように脆弱であるかを確認するため、ここでは一般的なサイバー攻撃の種類を見ていきます。

ブルートフォース攻撃

ブルートフォース攻撃では、プログラマーが正しいユーザー名とパスワードを推測するため、様々な組み合わせを次々と試みます。多くのWordPressサイトでは、脆弱な管理者パスワードが使用されているか、不正アクセスを防ぐ追加のセキュリティ層が整っていないため、こうした攻撃により容易に侵入される恐れがあります。

一方で、強固なパスワードやreCaptcha、動的なIPブロックなどの対策を講じているサイトもありますが、XMLRPCを悪用する場合、必ずしもWordPressの管理画面にアクセスする必要はありません。

Kali Linuxの有名なツールであるWPSCANを使用して、全てのユーザー名とログイン情報のリストを作成します。その後、攻撃中にxmlrpc.phpファイルを利用し、パスワードを総当たりで試すのです。

POST/xmlrpc.php HTTP/1.1
Client Agent: Fiddler
Host: www.example.com
Content-Length: 164
<methodCall>
    <methodName>wp.getUsersBlogs</methodName>
    <params>
        <param><value>admin</value></param>
        <param><value>pass</value></param>
    </params>
</methodCall>

別の方法として、正しいパスワードが得られるまで、プログラマーは複数のパスワードパターンを送信することができます。

その結果、上記と似たレスポンスが返されます。レスポンスにはエラーコードと共に、認証情報が正しくないというメッセージが含まれ、プログラマーは正解するまで再試行できることが示されます。

HTTP/1.1 200 OK
Worker: nginx
Date: Sun, 26 May 2019 13:30:17 GMT
Content-Type: text/xml; charset=UTF-8
Association: keep-alive
X-Powered-By: PHP/7.1.21
Store Control: private, must-revalidate
Lapses: Sun, 02 Jun 2019 13:30:17 GMT
Content-Length: 403
<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
    <fault>
        <value>
            <struct>
                <member>
                    <name>faultCode</name>
                    <value><int>403</int></value>
                </member>
                <member>
                    <name>faultString</name>
                    <value><string>Incorrect username or password.</string></value>
                </member>
            </struct>
        </value>
    </fault>
</methodResponse>

このレスポンスはHTTP 200コードと、入力されたユーザー名およびパスワードが誤っているとのメッセージを返します。この手法ではreCaptchaやログイン制限を気にする必要がなく、正しい組み合わせが見つかるまで様々な認証情報を試し続けることが可能です。

ブルートフォース攻撃はサーバ資源を大量に消費し、パフォーマンスに問題を引き起こす恐れがあります。長時間の試行錯誤はサーバに過度の負担をかけ、正当な利用者へのアクセスを妨げる可能性があります。すなわち、こうした攻撃はサーバリソースに大きな影響を及ぼし、更なる負荷をもたらします。

DDoS攻撃

分散型サービス拒否攻撃（DDoS攻撃）は、サーバに毎秒数百～数千のリクエストを送りつける、非常に破壊力のあるサイバー攻撃です。これによりサーバは過負荷となり、正当な利用者へのアクセスが遮断されます。ここでは、プログラマーがxmlrpc.phpファイルに存在するpingback機能を悪用して攻撃を仕掛けます。

通常、攻撃者は何度も攻撃が可能で、応答に時間がかかるサイトのエンドポイントを狙います。単一の攻撃がサーバ資源に多大な影響を与える可能性があるため、XMLRPCはこうしたエンドポイントの特定に大きく関与しています。

攻撃者は既に管理している悪意あるサイトを利用してpingbackリクエストを生成し、大量のHTTP GETやPOSTリクエストでサーバを圧迫し、通常の通信を妨げます。やがてサーバはダウンしてしまいます。

まず、攻撃者はxmlrpc.phpファイルが有効かどうかを確認するため、以下のリクエストを送信します。

POST/xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Association: keep-alive
Content-Length: 175
<?xml version="1.0" encoding="utf-8"?>
<methodCall>
    <methodName>demo.sayHello</methodName>
    <params>
        <param>
        <value>admin</value>
        </param>
    </params>
</methodCall>

対象サイトでXMLRPCが有効であると確認した後、攻撃者は悪意あるサイトを用いてpingbackリクエストを対象に送り、大規模なDDoS攻撃を仕掛けるため、複数のホストから自動化されたリクエストを送信します。

POST/xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Association: keep-alive
Content-Length: 293
<methodCall>
    <methodName>pingback.ping</methodName>
    <params>
        <param>
        <value><string>http://173.244.58.36/</string></value>
        </param>
        <param>
        <value><string>https://example.com/blog/how-to-make-a-salad</string></value>
        </param>
    </params> WAF

「DDoS攻撃の対策方法」の記事も参考にするとよいでしょう。詳しく対策方法が説明されています。

クロスサイトポート攻撃

クロスサイトポート攻撃はよく見受けられる現象です。この攻撃では、攻撃者が悪意あるコードを仕込み、TCPポートやIPアドレスの情報を引き出します。WordPressの運用において、XMLRPCは基本的なWAFなどによるIP隠蔽を回避するため、pingback機能とともに使用されることがあります。

この攻撃では、攻撃者がpingback機能を利用して、対象サイト上の特定の投稿に対してIPアドレスが返されるよう仕向けます。攻撃者はスニッファーを使い、pingback送信用のエンドポイントと対象投稿の有効なURLを特定します。

その後、攻撃者はこのリクエストをサーバへ送信します。

<methodCall>
    <methodName>pingback.ping</methodName>
    <params><param>
        <value><string>http://<YOUR SERVER >:<port></string></value>
        </param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
        </value></param></params>
</methodCall>

もしレスポンスにエラーコードが含まれ、その値がゼロより大きければ、該当ポートは開いており、攻撃者はHTTPに直接データパケットを送り続けることが可能であることを意味します。

XMLRPC攻撃を防ぐ方法

ここまで、xmlrpc.phpファイルがクロスサイトポート攻撃、ブルートフォース攻撃、DDoS攻撃などのサイバー攻撃に対して脆弱であることが明らかになりました。従って、これらの脆弱性を防ぐための最も効果的な方法に注目する必要があります。

xmlrpc.phpファイルの状態を確認する際、利用者がよく採用する方法は以下の通りです。

XMLRPCを完全に削除する

XMLRPCファイルを削除することで、多くの問題を回避できます。これにより、アクセスしようとする者には404エラーが返されます。ただし、この方法は、WordPress更新のたびにファイルが再生成される欠点があります。

XMLRPCを無効にする

もう一つの有効な方法は、xmlrpc.phpファイルを無効にすることです。これは、.htaccessファイルに以下のコードブロックを追加することで実現可能です。WordPressのデフォルトの.htaccessルールが適用される前に設定する必要があります。

<Files xmlrpc.php>
    request allow, deny
    deny from all
</Files>

これにより、xmlrpc.phpファイルを利用する全てのアプリや管理機能が無効になります。XML-RPC経由でのアクセスを許可したい場合は、IPアドレスをホワイトリストに追加できます。以下のコマンドを入力してください。

<Files xmlrpc.php>
    <RequireAny>
        Require IP 1.1.1.2
        Require IP 2001:db8::/32
    </RequireAny>
</Files>

XMLRPCを無効にすることの利点

• このプロトコルを無効にすることで、XMLRPCがサイバー攻撃に悪用されるリスクを完全に排除できる。
• 長期的にサーバのパフォーマンス向上と資源消費の削減が期待できる。

XMLRPCを無効にすることの欠点

XMLRPCを無効にするということは、同様のリモートアクセスを利用するアプリのアクセスも制限されることを意味します。

また、カスタムアプリの旧コードが動作しなくなる可能性があります。

セキュリティプラグインの導入

WordPress利用者は、サイトのパフォーマンスに大きな影響を与えずに追加機能を実現するため、しばしばセキュリティプラグインに頼ります。XMLRPCの攻撃からサイトを守ると謳うプラグインも数多く存在します。追加機能を求めてこれらのプラグインの導入を検討することも可能ですが、実際には最適な解決策とは言えません。

これらの理由から、単にプラグインを導入するだけでなく、サイトを守るための別の対策を検討すべきです。

• セキュリティプラグインはアプリ層で対策を施すものであり、実際にサーバ全体を攻撃から守るわけではない。
• プラグインはサイトに負荷となるコードを追加し、パフォーマンス低下やTTFBの増加を招く恐れがある。
• 場合によっては、プラグイン自体が攻撃者に悪用され、間接的なサイトアクセスを許す可能性がある。
• 継続的な管理が必要なため、運用負荷が増加する。

以上の点から、これまで紹介した方法はいずれもXMLRPCプロトコルに対する最適な解決策とは言えないことが分かります。

Accelerated DomainsはXML-RPC脆弱性の問題にどのように対応するか

Accelerated Domainsは、パフォーマンス、セキュリティ、スケーラビリティの問題に効果的に対処するよう設計されています。Accelerated Domainsは、XMLRPCに関連する攻撃を含む様々なサイバー攻撃を防ぐエンタープライズレベルのセキュリティを提供します。

Accelerated Domainsの高度なセキュリティエンジンはサーバの前段に配置され、約40%の着信HTTPトラフィックを除去します。継続的なデータ処理による高度な挙動解析により、最も巧妙なサイバー攻撃も初期段階で検知可能です。しかも、サイトのパフォーマンスに影響を与えることなく機能し、全体の効率を向上させます。

Accelerated Domainsはプロアクティブなセキュリティエンジンを備え、DDoS攻撃からサイトを積極的に守ります。適切なレート制限があるため、過酷なDDoS攻撃にも耐えることができます。また、一つのソースからのリクエストを検知・制限する効果的な防御機能により、ブルートフォース攻撃からも保護されます。

利点

• Accelerated DomainsはXMLRPCの多くの脆弱性に対応しているため、XMLRPCを無効にする必要がない。
• xmlrpc.phpに依存する他のプラグインやツールを引き続き利用できる。
• サーバ側の設定変更も不要で、.htaccessファイルの修正も必要ない。
• セキュリティプラグインの導入が不要となる。

欠点

• 大規模な導入にはサーバ側の設定が必要となる。

結論

総じて、XMLRPCはサイトへの遠隔投稿に伴うさまざまな問題の解決策として採用されました。しかし、このプロトコルはWordPressサイトの所有者にとって、広範な影響を及ぼす脆弱性も抱えています。

サイトを守るためには、xmlrpc.phpファイルを完全に無効にする必要があるかもしれません。ただし、遠隔投稿やJetpackプラグインに必要な機能が求められる場合は、それらの機能を考慮した代替の対策を講じることが推奨されます。

技術の進歩に伴い、XMLRPCはWordPress APIに統合され、セキュリティを損なうことなく遠隔アクセスとパフォーマンスの両立が可能になると期待されます。その間、Accelerated Domainsやセキュリティファイアウォールなどを活用して、サイトを守るのが賢明です。