エグゼクティブサマリ
WordPress 4.7と4.7.1のREST APIに、認証を回避してコンテンツを書き換えられる脆弱性が存在する。攻撃は極めて容易で、その影響は任意コンテンツの書き換えであるため、重大な結果を及ぼす。対策はWordPressの最新版にバージョンアップすることである。 本稿では、脆弱性混入の原因について報告する。はじめに
WordPress本体に久しぶりに重大な脆弱性が見つかったと発表されました。こんな風に書くと、WordPressの脆弱性なんてしょっちゅう見つかっているという意見もありそうですが、能動的かつ認証なしに、侵入できる脆弱性はここ数年出ていないように思います。そういうクラスのものが久しぶりに見つかったということですね。
- WordPress、更新版で深刻な脆弱性を修正 安全確保のため情報公開を先送り
- Make WordPress Core
- Content Injection Vulnerability in WordPress 4.7 and 4.7.1 - Sucuri Blog
WordPressではこの問題について、「セキュリティ問題は常に公開されるべきというのがわれわれのスタンスだが、今回のケースでは、何百万というWordPressサイトの安全を保証するため、意図的に公開を1週間先送りした」と説明している。
この間にSucuriをはじめとするセキュリティ企業と連携し、攻撃が発生した場合でも各社のファイアウォールで防御できる態勢を確立。自動更新を通じてWordPressの更新版が行き渡り、できるだけ多くのユーザーが保護されるのを待ってから、情報を公開したという。
WordPress、更新版で深刻な脆弱性を修正 安全確保のため情報公開を先送りより引用
脆弱性のサマリは下記となります。
| 対象バージョン | WordPress 4.7.0 および 4.7.1 |
|---|---|
| 影響 | コンテンツの改ざん |
| 攻撃の認証要否 | 不要 |
| 攻撃の難しさ | 極めて容易 |
| 対策 | WordPressのアップデート(4.7.2にて修正) |
認証なしにリクエスト一発でコンテンツを改ざんできるため、影響は極めて深刻です。対象バージョンをお使いの方は、即刻アップデートすることをお勧めします。
攻撃の様子
PoCは複数公開されています。以下、一部を伏字にした形で攻撃の手順を説明します。以下に攻撃前のコンテンツを示します。WordPressをインストールした直後であることが分かります。
このサイトに対して、以下のリクエストを送信します。一部伏字にしています。
上記から分かるように、認証不要で、攻撃に特別な情報も必要とせず、極めて容易にコンテンツが改ざんできるため、深刻な脆弱性であることがわかります。
脆弱性の原因
脆弱性の原因は、前述のSucuri Blogにて解説されていますが、この記事だと少し分かりにくいので解説を試みます。WordPressでは以前からREST APIがプラグインとして用意されていましたが、WordPress 4.7以降で WordPress Coreにバンドルされました。今回の脆弱性は、このREST APIにあります。
以下の説明において、攻撃目標は、認証を回避して、id=1のコンテンツを改変することとします。WordPressのREST APIの内部では、以下の2つのメソッドが動きます。
- update_item_permissions_check (権限の確認)
- update_item (コンテンツの変更)
wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php (Ver 4.7.1)
497: public function update_item_permissions_check( $request ) {
498: $post = get_post( $request['id'] );
499: $post_type = get_post_type_object( $this->post_type );
500: if ( $post && ! $this->check_update_permission( $post ) ) {
501: return new WP_Error( 'rest_cannot_edit', __( 'Sorry, you are not allowed to edit this post...
502: }
503: if ( ! empty( $request['author'] ) && get_current_user_id() !== $request['author'] &&
! current_user_can( $post_type->cap->edit_others_posts ) ) {
504: return new WP_Error( 'rest_cannot_edit_others', __( 'Sorry, you are not allowed to update ...
505: }
506: if ( ! empty( $request['sticky'] ) && ! current_user_can( $post_type->cap->edit_others_posts ) ) {
507: return new WP_Error( 'rest_cannot_assign_sticky', __( 'Sorry, you are not allowed to make ...
508: }
509: if ( ! $this->check_assign_terms_permission( $request ) ) {
510: return new WP_Error( 'rest_cannot_assign_term', __( 'Sorry, you are not allowed to assign ...
511: }
512: return true;
513: }
ここで、idとして以下のようなパラメータを指定した場合のそれぞれの返り値を示します。
| コンテンツの性質 | 返り値 |
|---|---|
| 存在しないコンテンツ | true |
| 存在し権限のあるコンテンツ | true |
| 存在し権限のないコンテンツ | false |
存在しないコンテンツが指定された場合、update_item_permissions_checkメソッドの様々なチェックをすべてくぐり抜け、メソッド最後のreturn文にて true が返されるところが恐ろしいですね。
しかし、この「存在しないコンテンツ」については、以下の update_item メソッドの 526行目にてエラーが返され、結果としては何もしない *はず* でした。
523: public function update_item( $request ) {
524: $id = (int) $request['id'];
525: $post = get_post( $id );
526: if ( empty( $id ) || empty( $post->ID ) || $this->post_type !== $post->post_type ) {
527: return new WP_Error( 'rest_post_invalid_id', __( 'Invalid post ID.' ), array( 'status' => 404 ) );
528: }
529: $post = $this->prepare_item_for_database( $request );
530: if ( is_wp_error( $post ) ) {
531: return $post;
532: }
ところが、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 4.7.2での改修内容
WordPress 4.7.2では、代わりに、get_postメソッドがget_post関数のラッパーとして作成され、権限チェックと更新の両方から呼ばれるようになりました。527: public function update_item_permissions_check( $request ) {
528: $post = $this->get_post( $request['id'] );
529: if ( is_wp_error( $post ) ) {
530: return $post;
531: }
get_postメソッドの冒頭は下記のとおりです。
318: protected function get_post( $id ) {
319: $error = new WP_Error( 'rest_post_invalid_id', __( 'Invalid post ID.' ), array( 'status' => 404 ) );
320: if ( (int) $id <= 0 ) {
321: return $error;
322: }
323: $post = get_post( (int) $id );
324: if ( empty( $post ) || empty( $post->ID ) || $this->post_type !== $post->post_type ) {
325: return $error;
326: }
$id を整数にキャストすることと、「存在しないコンテンツ」に対してエラーを返すようになりました。どちらか一方でも先の攻撃は防げるはずですが、とくに「存在しないコンテンツ」に対するチェックがいいですね（元々そうすべき内容ではありますが）。
教訓
この脆弱性は権限チェックの間違いの典型例です。チェックと更新とで、異なる入力を用いているわけですから、両者の不整合がチェック漏れの原因になります。WordPress 4.7.2のソースを見ても、使用する度に int にキャストしている箇所があります。これは潜在的にバグや脆弱性の原因です。以下のいずれかにすべきであると考えます。
- 入力値のバリデーションにて数値以外のものをエラーとする（推奨）
- 入力時に整数にキャストし、以降の処理では一貫してキャスト後の値を用いる
まとめ
WordPress 4.7.1までのREST APIに存在した脆弱性について説明しました。Sucuriはこの脆弱性をPrivilege Escalation （権限昇格）としています。しかし、Privilege Escalation だと一般ユーザーが特権を悪用できるように感じますが、実際には認証しなくても権限が悪用できるため、「アクセス制御の欠落」の方がより適切であるように思います。前述のように、極めて危険な脆弱性であるため、当該バージョンのWordPressをお使いのサイトは、至急のアップデートを推奨します。
【HASHコンサルティング広告】
HASHコンサルティング株式会社では、WordPressを用いたウェブサイトのセキュリティ強化支援サービスを提供しています。詳しくは以下を参照下さい。WordPressサイトのセキュリティ強化支援 | HASHコンサルティング株式会社
0 件のコメント:
コメントを投稿