未セットアップのWordPressの公開での放置は危険！ ～CTログを悪用した攻撃とその対策～
2022年05月26日 09時00分更新
はじめまして、KUSANAGIの開発チームの福田です。
「KUSANAGI」はWordPressをはじめとするCMSを高速に動作させる世界最速クラスの仮想マシンです。わたしたちは「KUSANAGI」を開発して皆様にご利用いただくほか、お客様のウェブサイトを「KUSANAGI」で運用しています。
この連載では、「KUSANAGI」の開発やお客様とのお話の中で感じた課題や実際の運用の中で得た知見などをお伝えしています。
今回は最近一部で話題となっていたWordPressが実行できる環境においてLet's Encryptの証明書を発行すると遠隔で任意のPHPコード実行がなされる恐れがあると一部で言われている点について解説したいと思います。
なぜ、Let's Encryptの証明書の発行で攻撃が成立するのか
WordPressは全世界のウェブサイトのうちおよそ43％で使われているといわれており、皆様の中でもこのCMSをご存知の方も多いかと思います。また、Let's Encryptを含め一般に信用されている（≒自己署名証明書でない）SSL/TLSを使用する場合においてはCertificate Transparencyに当該証明書が記録されていることがFirefoxを除く主要なブラウザーにおいて必要とされています（例：Chrome証明書の透明性ポリシー、Appleの証明書の透明性ポリシー）。従って、この攻撃の一部、または全部が多くの未セットアップのWordPressウェブサイトにおいて実行される恐れがあります。
この現象は2022年3月に入ってから特に報告が確認されています。また、この攻撃が一部成立すると/wp-includes/配下に.query.phpという不正なファイルが設置されることが現在知られています。また、当該ファイルが外部からアクセス可能なことにより、この攻撃が完全に成立すると、遠隔からコードを実行されてしまい、別のウェブサイトに対してDDoS攻撃をすることが報告されています。また、サイトによりますが、証明書発行からすぐに攻撃が成立することがあることが報告されています。
この攻撃、実はLet's Encryptの証明書を利用している環境のみで成立するかというと、そうではありません。Certificate Transparencyを利用しているため善意・悪意を問わず第三者に利用しているドメインを知られやすく、かつその証明書を発行するドメイン認証をほとんどの場合HTTP(S)越しで通信することにより行う場合が多いため外部からのアクセスがしやすいために成立の可能性が高いだけで、外部からWordPressのインストール画面さえアクセスできてしまえばほかの証明書を利用する環境、もしくはHTTPのみ利用している環境でも成立しえます。
なぜCertificate Transparencyを利用すると利用しているドメインを知られやすいかというと、これは仕様によりFQDNがログサーバにおいて強制的に公開されるためです。そもそもなぜFQDNが強制公開されるのかについては過去にあった事件やそれに対する対策が絡んでいます。過去に信頼されている認証局による証明書の不正発行があり、その結果そのような不正発行を防ぐべく以下のような技術を開発しました。
・発行された証明書を一般に公開されているログサーバに登録することによってログサーバによって検証された正当な証明書というお墨付きをもらうことでさらに信頼性を向上する
・公開されているログを抽出・監視することにより自社・自身が意図しない証明書の発行を防ぐことができるようにする
このうち、後者によりウェブサイトの運営者は証明書の不正発行を防ぐ、もしくは早期発見できるという利益を受けます。それはすなわち、善意・悪意を問わず第三者も証明書の発行情報を即座に確認できるのです。これは時として利益にもなりますが、不利益になることもあります。
この仕組みによって、攻撃者は大量、自動的かつ容易に利用されている・される予定のあるドメインのリストを収集できてしまうのです。
どのように不正なファイルを設置されるのか？
実際に上がってきている被害事例がまだ少ないのですが、現時点では上記の手段によって仕入れたドメインリストから、以下のように自動で攻撃を実行すると考えられています。なお、わずか14秒で攻撃が成立しているということも判明しています。
まず、トップページへアクセスしてみて、結果WordPressのインストーラー（DBセットアップ画面ではありません。wp-config.php設置完了後に表示されるインストール画面です）の画面が返ってきたら、インストーラーからは任意の管理者ユーザーを作成できるので、これを使って適当にインストールを実施し、またそのページからログインユーザーを作成する。そののちにログインをし、脆弱性のある、もしくは不正なプラグインをインストールする。そのプラグインを経由して、不正なファイル、つまりさきほどの.query.phpを設置する。この時点で攻撃が一部成立。そのうえで、その.query.phpに対して任意実行に使うコードをHTTP通信で投入する。これにより攻撃が完全成立。
これらから考えられることは、以下の条件において攻撃が成立するおそれがあるということです。
WordPressを使っていて、wp-config.phpが設置された状態だがまだインストールが終わっていない状態でCertificate Transparencyのログサーバに証明書情報が登録されるような操作をする（e.g.:, Let's Encryptで証明書発行）、もしくは悪意のある第三者にインストールされていない状態であるドメイン・サイトがあることを何かしらの手段で把握される。上記を満たしていれば攻撃が一部成立します。また、上記の条件を満たしたうえでかつ、「.」が頭に付くファイル名に外部からアクセスできて、かつその状態においてPHPが実行可能であればこの攻撃は完全に成立しえます。
攻撃を防ぐための対策は？
現時点においてWordPressコア開発チームはこの問題を認識しており、今後のリリースにおいて適切な時期に修正が入るとコメントしています。暫定的な対策としては、自己署名（オレオレ）証明書を利用するなどして利用するFQDNを外部に漏れないようにしたうえでWordPressをインストールしてセキュリティ対策をした後、SSL証明書を発行し当該サイトに差し替え適用する、もしくは「.」から始まるファイルへのアクセスを禁止する、またはその両方を実施することなどが考えられます。別の対策方法として、WordPressを設置する前の状態で証明書を取得してしまい、そのうえで外部からのアクセスを制限してからWordPressを設置し、インストール、セキュリティ対策を実施後にアクセス制限を外すなどの手法も考えられます。
特に筆者としておすすめしたいのは最初に説明しました証明書の差し替え手法、もしくは最後に説明したアクセス制限を活用してのインストールです。「.」が付くファイルへのアクセス制限のみであれば、今後「.」が付かないバージョンのファイルを設置する攻撃が起こりうるとも考えており、それであれば根本的に解決できる特定ファイル名へのアクセス制限以外の対策を利用するのが賢明であると考えています。
KUSANAGIにおいての対策、そして安全に利用するための工夫
なお、KUSANAGIにおいてはこの攻撃は現時点で観測されている攻撃形態に関しては完全には成立しないように配慮されていますが、念のためにWordPressのセットアップを完了する前にkusanagi sslやkusanagi provisionでLet's Encryptによる証明書を取得しないことをお勧めします。つまり、まずはHTTPのみでセットアップし、そのあとにkusanagi sslで証明書を取得することをお勧めします。また、サーバの設定に詳しい方は管理画面のページにBasic認証などをかけるのも効果的と考えられます。
まさかCTログを悪用して攻撃の元のリストを作成するなんて思いもよらなかった方もいらっしゃると思います。また、今後も多くの方が想定もしていなかったような攻撃経路が発生すると考えられます。WordPressに限らず、ソフトウェアを利用する上では仕組みを理解したうえで利用し、定期的にアップデート。設定などもきちんとして、安全に利用できるよう工夫するのが重要だと感じさせられる今回の一件です。
