不正アクセスの内容と対策 ～ 基礎からしっかり！WordPressのセキュリティ対策ことはじめ (2/3)

公開日
更新日

はじめに

第2回目はWordPressへの攻撃の傾向、および脆弱性の概要と対策について触れます。実際どのような攻撃を受けているのか、またその内容を踏まえたうえでどのような対策を行うのかについて述べます。

本記事はWordPressを対象としていますが、根本的な部分においては他のCMSにも同様のことが言えますので、特にWEB制作に携わっている方にはご一読いただければ幸いです。

内容がやや難しい部分も含まれますが、今回もお付き合いください。

どのようにして攻撃されるか

よく見られる攻撃の傾向として、不特定多数のホストを広く浅く攻撃するといったものがあります。例えるならば、マンションの各部屋のドアを調べていき、ただ鍵がかかっていないものを探すように単純でありながら効率的な方法が多いです。

ここでは攻撃から防御することを目的として、どのようにして攻撃されているか、主なものについて触れてみます。

不正ログイン攻撃

不正ログイン攻撃とは、第3者が想定される認証情報を入力してログインできるか調べる攻撃であり、ブルートフォースアタック(Brute-force attack)とも呼ばれています。

試行を繰り返すため、非常に手間がかかるかと思われていますが、現在の計算機の処理能力では1秒間に数十から数百の試行を行うことができ、例えば数字のみ4桁のパスワードは、ほんの数秒の試行で完了していまいます。

具体例として、WordPressのダッシュボードを対象とした総当たり攻撃について触れてみます。

  1. ログイン用URLを特定する
    ダッシュボードへログインするURLはwp-login.phpとなるため、ここへログインするユーザ名とパスワードを送信します
  2. (管理者用ユーザ名を特定する)
    詳細については伏せますが、WordPressへ特定のリクエストを発行することにより、存在する管理者用ユーザ名を取得することができます。
  3. ユーザ名とパスワードを送信する
    パスワードを1文字単位で組み合わせを変えての総当りではなく、主に辞書攻撃と呼ばれている「ありがちなパスワード」にて試行しているようです。このパスワードについては、インターネットで調べると辞書データなどがすぐに見つかります。
  4. 返答されるHTTPヘッダを確認する
    ユーザ名とパスワードが一致した場合、WordPressは Status 302 としてLocation ヘッダにダッシュボードのURLを返信するため、これを確認して可否を判断します。(失敗時はStatus 200)
  5. ダッシュボードへログインする
    ログインした後は任意のコードを記述したり、任意のファイルを設置したり色々とすることができます。

このように非常に単純な攻撃ですが、管理者としてダッシュボードへログインできれば多くのことが実行できるため、広く行われているものとなります。また、これらを行うツールの作成も容易であり、逆にセキュリティスキャナを悪用することにより攻撃の難易度も低くなっています。

また、WordPressのパスワードのみではなく、サーバへ接続するFTPやコントロールパネルの接続情報も同様のことが言え、パスワードの使い回しなどをしていると芋づる式に漏洩するといった事象も増えているようです。

脆弱性を利用する

脆弱性とは、ソフトウェアの設計や実装の問題により発生するセキュリティ上の欠陥を指します。

この脆弱性については広い範囲となりますので、ここでは3つに分けてみます。

クライアントPC

アクセス元となるクライアントPCについては、様々な用途に使用されていることも多いため、複数の脆弱性を抱える可能性が高いです。マルウェアなどに感染させられることによって、不正なソフトウェアの設置や情報の流出が発生し、そこから2次的な問題が発生する可能性もあります。

WordPress本体

WordPress本体については中心となるプログラムであるため、脆弱性が発見された場合の影響範囲が広いことがあります。また、バージョンアップにともないプラグインやテーマが正しく動作しないことがあるため、更新の判断が行いにくいという問題も散見されています。

WordPressプラグイン・テーマ

WordPressには有用な多数のプラグインやテーマがありますが、これらについても脆弱性が含まれることがあります。WordPressに限ったことではありませんが、特に不特定多数のサードパーティ製のソフトウェアは品質基準が不定である傾向があり、また脆弱性が発見された時、確実に対応される保証が期待できないこともあります。
このため、脆弱性が長らく放置されたままのプラグインやテーマがあると、管理されていないので容易に攻撃しやすい、と判断される傾向もあります。

どのようにして対策するか

ここでは具体的なセキュリティ対策について触れてみます。

不正ログインへの対策を行う

まず不正ログインへの対策として、パスワードの設定について触れます。

複雑なパスワードを設定する

複雑なパスワードとは、下記のような条件を満たしたものとなります。

  • 単語ではなく、意味のない文字列の羅列である
  • 英数文字記号が混在している
  • それなりに長い文字列である

意味のない文字列である必要性は、既存単語を用いた辞書攻撃への対策となります。
特に英数文字記号の混在、長い文字列といった条件については、覚えるのに負担が大きいため避けられる傾向があります。しかしながら、これらを満たしていないと複雑なパスワードとなりません。

下記の表は文字の種類ごとに1文字で表現できる数になります。

種類

文字数

累計数
数字(0-9)

10

10(10)
アルファベット(大文字)

26

36(10+26)
アルファベット(小文字)

26

62(10+26+26)
記号

34

96(10+26+26+34)

これらの数字、アルファベット(大文字)、アルファベット(小文字)、記号すべて組み合わせると、1文字で表現できる文字数は最大で96通りとなり、より複雑なパスワードとなります。

下記のグラフは4文字のパスワードを生成するときの文字種類ごとの処理時間です。(このパスワード生成処理についてはCore2Duo E7500を搭載した専用サーバでFreeBSD 9.3の環境にてC言語で実装したプログラムで行っています。)

パスワード生成時間

これはパスワード総当り攻撃のため、すべての組み合わせを生成する処理としており、文字の種類が増えるにしたがって、パスワード生成処理の時間が増加していることが分かります。このため、使用する文字の種類が多いものは複雑であり、パスワードの推測を行いにくいものであることが分かります。

次にパスワードの文字列長については、1文字増加する毎に組み合わせ数が増加するため、比例して複雑なパスワードとなります。

下記の表は文字列長毎のパスワードの組み合わせとなります。

文字列長

組み合わせ数

1

96

2

9,216

4

84,934,656

8

7,213,895,789,838,336

16

52,040,292,466,647,269,602,037,015,248,896

このようにパスワードの文字列長が増える度に組み合わせ数は96の累乗となり、それを求める計算量も合わせて増加するため、総当りによるパスワード試行の労力が高くなるとが分かります。

定期的にパスワードを変更する

これもよく言われる事項ですが、では定期的とは具体的にどのくらいの期間が適切と言えるのでしょうか。極端な話、ログインする度にパスワードを変更する、もしくは一度限り有効なワンタイムパスワードを用いる方が正しいのでしょうか。
定期的にパスワードを変更する目的としては、知らない間に第3者が不正利用している状態を継続させない、長期間に渡る攻撃への対策であると考えられます。

パスワードの使い回しをしない

複数のサービスへの登録時にすべて同一のパスワードを設定している場合、どこかひとつのパスワードが漏洩すると、芋づる式に不正ログインされてしまうといった事象が増えてきています。(パスワードリマインダによく使われる「秘密の答え」なども同様です)
パスワードの設定と管理については煩雑になりがちですので、必要に応じてパスワード管理のためのソフトウェアの導入を検討してみてください。近年ではWWWブラウザにパスワード管理機能があるものが多いため、これらを利用するのが手軽で良いかもしれません。

脆弱性の対応を行う

脆弱性の対応としては、基本的にソフトウェアの更新が主になります。全般的に問題が発生してからの対応ではなく、事象を想定して事前にできることをやっておく、といった考え方になります。

クライアントPC

一般的にクライアントPCのOSについては、ベンダから提供されているアップデートを適用する、アンチウイルスのソフトウェアを導入することが対策と言われています。しかしながら、ここ近年においてはいわゆるソーシャルハッキング的な手法も散見されつつあるため、日々の利用形態についても注意しておく必要があります。

不要なサイトへアクセスしない、出どころが不明なソフトウェアをインストールしないといったことも重要になってきています。まれに検索エンジンなどでソフトウェア名で検索した場合、無関係なサイトが表示されることもあり、そこから不要なものをインストールされることもあるため、必ず一時配布元や信頼できるミラーサイトであることを確認する必要があります。

また、近年においてはクラウドなどで仮想デスクトップのサービスがありますので、これらを特定の作業用途のみ使用するといった方法もあります。

WordPress本体

WordPress本体については、電子メールやダッシュボードより新しいバージョンの通知が行われ、そこから更新を実行することができます。

更新の確認

また、WordPress 3.7からマイナーリリースについては、自動的に更新されるようにされていますので、ダッシュボードより能動的にアップデートを行うのはメジャーリリースのみとなります。

メジャーバージョンアップしたことによって発生する動作の不良については、下記のような対応を行います。ただし、これらはWordPress特有の対策ではなく、一般的なソフトウェアのバージョンアップ時のものとなります。

  • 動作を検証する環境を用意する
    いきなり本番環境にてアップデートを行った結果、何らかの動作不良が発生してしまった場合、原因の特定が難しくなってしまいます。また、閲覧者に対して「壊れている」状態のサイトを見せてしまうことにより、あまり良いとは言えない心象を与えるといった問題も発生してします。
    このため、事前に公開対象を限定した検証環境(いわゆるステージング)でアップデートを行い動作の確認を行い、問題が確認されなければ本番環境もダッシュボードからアップデートを実施します。
    しかしながら、検証環境の構築については「本番環境と同一であること」が必要であり、WordPressに限らず複雑な作業となります。今回は触れませんが、個人的には仮想化技術を用いて閉じられた同一環境を構築する方法を用いています。
  • データベースのバックアップを行う
    WordPressは画像以外のコンテンツのデータやプラグインの設定内容などをデータベースへ格納しています。このため、公開ディレクトリに設置されているファイルのバックアップだけではなく、データベースにあるデータのバックアップも必要となります。
    このデータベースのバックアップを取得する方法はいくつかありますが、phpMyAdminやmysqldumpコマンド用いる方法が望ましいです。
    また、データベースから特定のデータのみを抽出するのが難しいようであれば、少なくともダッシュボードからコンテンツのエクスポートだけは行っておくことを推奨します。これはWordPressが完全に破壊してしまい新規に構築する必要が発生したときに最低限コンテンツのデータがあれば、インポートすることによりサイトを仮復旧することができるためです。

WordPressプラグイン・テーマ

プラグインやテーマに関しては、適切なバージョンへアップデートを行うことが基本的な対策となります。しかしながら、ほとんどが第3者による作成されたものとなり、対応状況が不明瞭となる場合があるため、やや難しいといった問題があります。

このため、特にプラグインは導入を選定する段階において、まずは開発状況を確認する必要があります。特に長い期間更新されていないものについては、開発が放棄されているか、代替となる他のプラグインに移行している可能性が高いため、選定から外すといったことも必要になります。また、導入後についても同様の対応が必要となります。

プラグインやテーマのアップデート状況についてはダッシュボードから更新を確認します。脆弱性情報の詳細についてはWordPressのセキュリティ診断ツールであるWPScanが提供しているWPScan Vulnerability Databaseを参照すると良いです。

▼WPScan Vulnerability Database
https://wpvulndb.com/

Vulnerability Database

主に下記3項目を確認します。

  • Latest WordPress Vulnerabilities
    直近のWordPress本体の脆弱性が表示されています。
  • Latest Plugin Vulnerabilities
    直近のプラグインで脆弱性があったものが表示されています。
  • Latest Theme Vulnerabilities
    直近のテーマで脆弱性があったものが表示されています。

また、APIを利用して個別の脆弱性情報を取得することができます。例えば、下記のように使用しているプラグインのスラグ名を指定して、専用のAPIへリクエストを発行すると、JSON形式で脆弱性情報を取得することができます。

% fetch -q -o - https://wpvulndb.com/api/v2/plugins/commentator | jq '.'
{
  "commentator": {
    "latest_version": null,
    "last_updated": null,
    "popular": false,
    "vulnerabilities": [
      {
        "id": 8363,
        "title": "Commentator <= 2.5.2 - Reflected Cross-Site Scripting (XSS)",
        "created_at": "2016-01-13T17:55:05.000Z",
        "updated_at": "2016-01-13T17:55:16.000Z",
        "published_date": "2016-01-13T00:00:00.000Z",
        "references": {
          "url": [
            "http://permalink.gmane.org/gmane.comp.security.oss.general/18569",
            "http://codecanyon.net/item/commentator-wordpress-plugin/6425752"
          ]
        },
        "vuln_type": "XSS",
        "fixed_in": "2.5.3"
      }
    ]
  }
}

まとめ

今回は「こうすべきだ」だけではなく「何故こうすべきなのか」まで含めたため、少し難しい内容となりましたが、WordPressにおける攻撃の傾向、および脆弱性の概要と対策について触れました。

特に不正ログインの対策については、多くの項目があるため労力がかかるものとなっています。これはWordPressに限ったことではなく、現行のパスワード認証方式にすべて共通して言えることです。

また、運営を続けていくうちに対応が億劫になってしまい、本来は順守すべきルールから外れてしまうことも多々あるようです。このような時は、代替となるものを検討するなど柔軟に対応できるようにするのもセキュリティ対策とも言えるかもしれません。

次回は具体的な例としてWordPressのプラグインを用いたセキュリティ対策と不正アクセスを受けた時の対応について取り上げます。