皆様はじめまして、新人エンジニアの小松と申します。
本日は最近起きたWordPressの脆弱性についての記事を書くことにします。
WordPress 4.7 / 4.7.1 における脆弱性
WordPressは豊富なプラグインや多彩な外見テーマのおかげでphpに詳しくなくとも手軽に編集できるのを強みとしているオープンソースのブログ／CMS プラットフォームです。しかしそんなWordPressで最近、ショッキングなニュースが話題となりました。
バージョン4.7, 4.7.1のWordPressに脆弱性があり、専門的な知識がなくても悪用することができる深刻なものでした。事態が事態だけにWordPress側もすぐにはその脆弱性を公表できませんでした。
その脆弱性を突かれるとどうなるかですが、攻撃側が容易にコンテンツを望むように改ざんできてしまいます。ブログサイトが台無しにされるだけでなく、悪意のある攻撃の踏み台にされる、そのブログサイトそのものに罠を埋め込むこまれるなど攻撃者の道具として悪事に加担させられる可能性もあります。
技術的な説明として徳丸氏のサイトより引用させていただきます。
>存在しないコンテンツが指定された場合、update_item_permissions_checkメソッドの様々なチェックをすべてくぐり抜け、メソッド最後のreturn文にて true が返されるところが恐ろしいですね。
しかし、この「存在しないコンテンツ」については、以下の update_item メソッドの 526行目にてエラーが返され、結果としては何もしない *はず* でした。
ところが、id=1A が指定された場合に、update_item_permissions_checkメソッドとupdate_itemメソッドの両方で呼ばれている get_post関数が受け取るパラメータを確認してみましょう。>update_item_permissions_checkでは、get_post(‘1A’)が呼ばれ、1AをIDとするコンテンツはないため、「コンテンツは存在しない」が返され、チェック結果は true となります（！）。
一方、update_itemメソッドは、$id を整数にキャストしているため、get_post(1)が呼ばれ、ID=1 のコンテンツが変更されることになります。これにより、本来権限のないコンテンツ ID=1 に対する更新ができてしまうことになります。
今回私は、実際に自らの手でWordPressの脆弱性を突いてみて結果を観測してみることとしました。
実験
用意したものはOracle VM VirtualBoxで立ち上げたCentos6.8にWordPressのバージョン4.7をサーバー側として設定
一方で攻撃側は、サーバー側と同じくOracle VM VirtulboxでKali Linux(amd64)を攻撃側として用意しました。
インジェクションに使うスクリプトはrubyなので、攻撃側にはrubyを使える環境に整える必要があります。（今回は攻撃者というイメージでKali Linuxを指定しましたが、rubyを使える環境であればほかのディストリビューションでも問題ありません。)
ローカルでWordPressのブログサイトを立ち上げればサーバー側は準備完了です。EXPLOIT DATABASEにて公開されているコードを攻撃側がスクリプトとして実行します。
|
1 |
# ruby スクリプト名.rb |
この後に対象のWordPressのURLを指定します。そしてその次にポストIDが問われますが、本来なら存在しないIDは弾くこの部分が存在しないIDを弾かずに通してしまいます。
従って、例えばここで
|
1 |
1 |
とだけ入力することで認証を通過し、標的となったサイトを改ざんするスクリプトのリクエストが通ってしまいます。
恐ろしいことに、たったこれだけで4.7または4.7.1バージョンのWordPressの改ざんは可能なのです。このシンプルかつ深刻な脆弱性は、バージョンを4.7.2にあげることで防ぐことができます。もしもご利用のWordPressのバージョンが未だに4.7または4.7.1でしたのなら即刻バージョンアップさせることを推奨します。
