• 解決済 Eiichi Uchibori

    (@eucreate)


    4.9.8にアップしたところ、Webページ改ざんされました。

    WAF対応のサーバーのバージョンを4.9.8にししばらくしたら、
    ログが残っていたので、見てみたところ、
    %2fwp%2djson%2foembed%2f1%2e0%2fembed%3furl%3dhttp%3a%2f%2fwww%2eexample%2ecom%2farchives%2f34%27%29%20UNION%20ALL%20SELECT%20NULL%2cNULL%2cNULL%2cNULL%2cNULL%2cNULL%2cNULL%2cNULL%2cNULL%2cNULL%2d%2d%20DhKz
    %2fwp%2djson%2foembed%2f1%2e0%2fembed%3furl%3dhttp%3a%2f%2fwww%2eexample%2ecom%2farchives%2f34%27%20ORDER%20BY%201%2d%2d%20WPrJ
    等のSQLインジェクション攻撃のようです。

    WAFが無い,無効,適切な設定でない場合は、
    .htaccessの書き換えや、PHPファイル等の書き換え、不正なファイルの作成等の改ざんが行われるようです。

    なお、4.9.7では問題無いようです。

15件の返信を表示中 - 1 - 15件目 (全19件中)
  • トピック投稿者 Eiichi Uchibori

    (@eucreate)

    全てURLエンコードしてありますが、
    %2fwp%2djson%2foembed%2f1%2e0%2fembed%3f

    /wp-json/oembed/1.0/embed?
    です。

    Takahashi Fumiki

    (@takahashi_fumiki)

    @eucreate

    興味深いですね。たしかにそのログはSQLインジェクションですが、成功したかどうかはそれだけだとわかりませんね。また、SQLインジェクションで被害が出るのはコンテンツの書き換えですが、拝見する限り、ファイルパーミッションを奪首されているので、別の理由のような気がします。

    特にプラグインの脆弱性によって、ファイル書き込み権限を奪首されるケースはいくつかあります。まずは古いプラグインを利用していないかどうか、チェックしてみてはいかがでしょうか。

    コマンドラインツールで改ざん検知もできます。 https://capitalp.jp/2017/12/12/wp-cli-starts-checksum-command-test/

    また、仮に脆弱性だった場合は本家に報告するのがよいと思います。 https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/

    トピック投稿者 Eiichi Uchibori

    (@eucreate)

    @takahashi_fumiki 様、アドバイスありがとうございます。

    次のトピックスに詳細を載せました。

    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    トピック投稿者 Eiichi Uchibori

    (@eucreate)

    実際に被害にあったのは、知り合いのクライアント様で、アップデートの際はファイルのバックアップは指示しました。
    クライアント様は、すべてのファイルを一旦バックアップしたそうです。
    あとは、アップデート後はプラグインを最新に更新し、使用していないプラグインは削除することも指示をして、そちらも実行したそうです。

    改ざん後は、データベース接続確率エラーで接続できなくなり、ファイルを調べたところ、以前はなかったPHPファイルが増えており、WordPressで管理しているindex.phpは書き換えられていたそうです。
    https://www.eu-create.net/documents/wp1/image001.jpg
    また、WordPress以外のフォルダーにも、PHPファイルになっている物は内容が下記のような記述が追加されていたそうです。
    https://www.eu-create.net/documents/wp1/image002.jpg
    さらに、バックアップに使用したフォルダ内にも、本来はZIPファイルのみでしたが、ファイルが追加されていたそうです。
    https://www.eu-create.net/documents/wp1/image003.jpg
    あとは、WordPress管理外の.htaccessファイルにコードの追加もされていたそうです。
    https://www.eu-create.net/documents/wp1/image004.jpg
    攻撃に遭ったと思われる(同一の書き方の)ログは、
    https://www.eu-create.net/documents/wp1/log1.txt
    です。(一応重要な部分は「*」を使い伏せさせて頂いています。)

    証拠としていただけたのは以上になります。
    ちなみに、クライアント様のサーバーはWAFはありません。
    また、現在のWordPressのバージョンは4.9.7です。
    4.9.7では改ざんの被害は現在のところありません。

    他にも何かアドバイスいただける方がいれば、よろしくお願いいたします。

    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    Takahashi Fumiki

    (@takahashi_fumiki)

    @eucreate

    被害の状況を見るに、MySQLインジェクションではなく、ローカルファイルインクルージョンだと思われます。
    あくまで推測ですが、利用しているプラグインやテーマに脆弱性が存在していて、攻撃者によって好きなファイルを配置することができてしまっているのではないでしょうか。
    htaccessを見るに、スパムサイトへリダイレクトされる仕組みになっていますが、他の攻撃結果と整合性がないことから、よく知られた脆弱性を突かれた感じがします。

    4.9.7にダウングレードすることが解決策になるかどうかは現時点ではわかりません。

    なんにせよ、プラグインorテーマの名前+脆弱性で検索してみると、何か分かるかもしれません。
    “plugin-name vulnerability” とかで調べるとわかりやすいかと。

    トピック投稿者 Eiichi Uchibori

    (@eucreate)

    @takahashi_fumiki 様、アドバイスありがとうございます。

    WAF非対応のサーバーで4.9.8にアップデートした私の契約しているサーバーで
    被害に遭わなかったサーバーがあったのを思い出したので、
    そちらのサーバーのログファイルを解析してみましたところ、
    4.9.8にアップデート後に同じSQLインジェクションを突いたログが同様に見つかりました。

    以下、今までの情報を整理したものです。
    (1)被害者は、それまではプライグインのアップデート等はしていなかったそうです
    (2)被害者は、4.9.8にアップデート後に、プラグインやテーマもアップデート(使用テーマは既存のものではなくオリジナルテーマ)
    (3)被害者は、バックアップデータから復元後、4.9.7に更新してもらい、再度プラグインやテーマもアップデート
    (4)被害後はFTP,サーバーの管理画面,WordPressのパスワードを変更
    (5)4.9.7以前のWordPressには「/wp-json/oembed/1.0/embed?url=~」の記述があっても、攻撃パラメーターは無い
    (6)4.9.8からのWordPressには「/wp-json/oembed/1.0/embed?url=~」の記述には攻撃パラメーターが付く(SQLが絡まない記述も存在する)
    (7)4.9.8インストール後3日以内に攻撃がある
    (8)4.9.8でサーバー側で対策済みで攻撃不可の場合、以降攻撃が無くなる
    (9)4.9.8でWAF無効の場合でも改ざん被害が無い場合がある(冒頭の文章の通り)
    (10)被害に遭わなかったサーバーでは4.9.8のリリース後8月4日に自動アップデートでアップデートされています

    知り合いに確認していただいたところ、
    被害者のサーバーは、
    大塚商会アルファメールプレミア 50Gプラン
    サーバーバージョン1
    を利用しているそうです。
    Apache 2.2
    PHP 5.3.3(CGI版かモジュール版かは不明)
    MySQL 5.0.45
    WAF機能無し
    ※上記スペックはサイトからの推測です。

    被害に遭わなかったサーバー(私の契約しているサーバー)
    Plesk Onyx 17.8
    Apache 2.2.15
    PHP 5.6.38(FastCGI)
    MySQL 5.6.41
    WAF機能未インストール

    WordPressの構造は詳しくないので間違っているかもしれませんが、
    REST APIが「/wp-includes/rest-api」内のファイルだとすると、
    処理方法や記述方法が4.9.7以前のものより変更されているようです。

    また推論になりますが、以前もREST APIについては脆弱性問題がありましたし、
    今回の更新でまたWordPress側が何らかの脆弱性を作り出した可能性もあります。

    以上を踏まえると、あくまでも推測ですが、
    (1)サーバーの設定によっては改ざんが出来てしまう(どのような設定で防げるかは不明)
    (2)クラッカーや悪意のあるハッカーはベータ版の時点で、何らかの脆弱性を発見していた可能性がある
    (3)リリース後、実行しサーバー等で対策済みの場合は、攻撃が無意味なので以降攻撃はしない(何らかの組織的な攻撃?)
    と考えられます。

    そうなると、
    (1)サーバーの設定に何らかのセキュリティーホールがある場合は、
    4.9.8のREST APIに何らかのバグが存在すると仮定した場合、
    サーバー側の対策が不明な場合は、REST APIを無効にする他に方法はないかと思います。
    (無効にした場合、いくつかのプラグインに影響が出る可能性はありますが。)
    ・.htaccessに7行追加するだけでWordPressのREST API無効化
    https://masshiro.blog/disable-rest-api/
    ・WordPressのREST APIを無効化しつつ特定プラグインは動作するようにカスタマイズする方法
    https://nelog.jp/deny-restapi-except-plugins
    (2)サーバーでWAF機能があれば有効にしておく
    以上が、あくまでも推測ですが、今回私の導き出した答えです。

    他にも何かアドバイスいただける方がいれば、よろしくお願いいたします。

    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    Takahashi Fumiki

    (@takahashi_fumiki)

    @eucreate

    アクセスログ(ですよね?)に残っていたSQLインジェクションの痕跡が実際の被害の原因であるというのをなぜそんなに確信されているのでしょうか? 私のサイトにもSQLインジェクションやディレクトリトラバーサルの痕跡はみられますが、実際の被害はありません。
    実際にやってみて、同じ被害が出るか試してみて再現性を担保するとより確信が深まるのではないでしょうか。

    被害の実態は「ファイルの改ざん・追加」ですので、そうした攻撃を行う場合はまた別の脆弱性があることが多いです。ぜひ、1つ前のアドバイス通り、利用プラグインのチェックをオススメします。

    トピック投稿者 Eiichi Uchibori

    (@eucreate)

    皆様に報告が遅くなり申し訳ございません。

    @takahashi_fumiki

    アクセスログ(ですよね?)に残っていたSQLインジェクションの痕跡が実際の被害の原因であるというのをなぜそんなに確信されているのでしょうか? 私のサイトにもSQLインジェクションやディレクトリトラバーサルの痕跡はみられますが、実際の被害はありません。

    はい、アクセスログです。
    以前も書いたように、私も依頼してきた知り合いも、お客様のWordPressに関する情報は入手できません。また、WordPressでの構築は別の会社がしたそうです。
    (お客様の規定や構築した会社との契約により)
    なので、各種アクセスログを解析するしかありません。

    実際にやってみて、同じ被害が出るか試してみて再現性を担保するとより確信が深まるのではないでしょうか。

    お客様のレンタルサーバーは古いスペックのサーバーです。
    現在は、新しいスペックサーバーの契約で法人向けのサーバーなので、個人での契約はできません。

    被害の実態は「ファイルの改ざん・追加」ですので、そうした攻撃を行う場合はまた別の脆弱性があることが多いです。ぜひ、1つ前のアドバイス通り、利用プラグインのチェックをオススメします。

    上記で書いたように、利用プラグインのチェックは不可能です。
    なので、私は@takahashi_fumiki 様の最初のアドバイス通り、本家に報告いたしました。

    最後に、本家に報告する上で、さらにログを精査したところ、以下のことがわかりましたのでご報告しておきます。
    ・最初は普通通りの処理でアクセス
    ・この時点で、サーバー上に何らかのセキュリティーホールがあれば攻撃がされる。
    (Webサイトの改ざん等が可能になる)
    ※FTPでの侵入やデータベースの改ざんはありません。
    ・攻撃ができない場合は約1分間に約230回のSQLインジェクション攻撃(恐らくブラインドSQLインジェクション攻撃)が行われる。
    ・4.9.8のリリース直後から、4.9.8のWordPressの対して3日以内に攻撃が始まる。
    という事がわかりました。

    以上です。

    あとは本家の技術者達が、何か解決策を見つけてくれると私は信じています。
    皆様に被害が出ないことを祈ります。

    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。

    こんにちは

    ここは日本ローカルのサポートフォーラムで、いわゆる「本家」ではありません。

    WordPressコアの不具合報告は Takahashi Fumiki さんが回答されているところです。

    また、仮に脆弱性だった場合は本家に報告するのがよいと思います。 https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/

    もちろん重大な不具合であればこのフォーラムを見てる誰かが上記本家に報告する場合もあるかと思います。
    しかし再現性が無くエビデンスも無い(環境もプラグインも不明では再現テストを行うこともできません)、また他に同様な報告も上がっていないので、調査するように開発者を説得することができないことから、誰か親切な人が本家に報告してくれることも無いと思います。

    WordPress4.9.8 の脆弱性だと確信がおありなら、ご自身で本家に報告されてみるしかないと思います。

    なんと無責任な、と思われるかもしれませんが、ここはサポートフォーラムですし、みなボランティアですので、提供された情報では時間をかけて調査することは難しいと思います。

    トピック投稿者 Eiichi Uchibori

    (@eucreate)

    @munyagu

    そうですね。
    そちらのページも拝見し、セキュリティー関連の事はWordPress HackerOne pageでという事でしたので、現在はそちらに詳細レポートを作成してやり取りしております。
    お気遣いありがとうございます。

    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    トピック投稿者 Eiichi Uchibori

    (@eucreate)

    皆様にご報告いたします。

    この件に関して、回答を頂きました。

    WordPressのデフォルトテーマではこのような問題は起きないそうです。

    被害に遭ったお客様のWordPressはデフォルトテーマではなく、オリジナルで作成したテーマを使用しているそうなので、その中に何らかの脆弱性がある可能性があるのではないかという事でした。

    また、合わせて以下についてもご報告させていただきます。
    セキュリティー関連の脆弱性等の報告はWordPress HackerOne pageへ報告することになっていますが、それ以前にフォーラム等(こちらのフォーラムも含む)に詳細をレポートすることは、WordPress HackerOne page上、やはりポリシー違反となるという事を改めてお叱りを受けました。
    自分自身のWordPressへの無知で未熟さ上、皆様に助けを求めた結果、このような事になり大変反省しております。
    私は、担当していただいた方に改めて感謝と反省の念を投稿しました。

    こちらでアドバイスいただいた @takahashi_fumiki 様、 @munyagu 様にも感謝申し上げます。

    以上、ありがとうございました。

    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    • この返信は6年、 3ヶ月前にEiichi Uchiboriが編集しました。
    トピック投稿者 Eiichi Uchibori

    (@eucreate)

    皆様にご報告です。

    本件について、
    条件は不明ですが、サーバーの仕様等によって
    被害を受ける場合があるようです。

    IPAにも報告いたしましたが、残念ながら
    「脆弱性として確認が出来ないため取扱いを終了する」
    との回答でした。
    その後、警察のセキュリティー対策の部署にも相談しましたが、
    「IPAもそのような判断をしたという事で、
    もし被害を受けたサーバーを利用している場合は、
    バージョンアップは控えた方が良いのでは無いか」
    という回答でした。

    尽力いたしましたが、お役に立てず誠に申しわけありませんが、
    あしからずご理解のほどお願い申し上げます。

    Takahashi Fumiki

    (@takahashi_fumiki)

    @eucreate

    お疲れ様でした。また報告もとても参考になります。
    基本的に脆弱性の指摘については、

    – 再現性があること
    – 必要な情報が過不足なく提供されること
    – パブリックな場所で書かず、専用の窓口を利用すること

    などが最低条件になります。今回はクライアントからの相談ということだったかと思いますが、たとえばクライアントであったとしても、上記の情報がないとなんの診断もできない(たとえていうなら、「患者がいないのに診療する」みたいなことでしょうか)ということを前提に対応されるとよいかもしれないですね。

    トピック投稿者 Eiichi Uchibori

    (@eucreate)

    @takahashi_fumiki

    色々とありがとうございました。
    また、色々と勉強になりました。
    改めて心よりお礼申し上げます。

    トピック投稿者 Eiichi Uchibori

    (@eucreate)

    せっかくの機会ですので、お伺いいたします。
    皆様はこういった問題の場合は、ある程度仲間と組んで検証等しているのでしょうか?
    私は、仲間はおりませんので、今回は仮想環境を作成し、約2か月間サーバーの設定を色々と変更し、ひたすらに再現性の検証を行ってきましたが、ご存知の通り突き止める事はできませんでした。
    やはり、今後は私のような仲間を持たない開発者では、無理なのでしょうか?

15件の返信を表示中 - 1 - 15件目 (全19件中)
  • トピック「SQLインジェクションでの改ざん」には新たに返信することはできません。