Bugoon は WordPress を使っていません。PHP も動いていません。それでも、サーバーには毎日のように /wp-login.php へのアクセスが届きます。

本番サーバーのログを6日分集計したところ、存在しないページへのアクセスは約5,000件ありました。この記事では、その中身と、誰が何を探しているのかを紹介します。最後に、自分のサイトで同じ確認をする方法もまとめます。

6日で約5,000件、すべて「存在しないページ」

集計の対象は、10月18日から23日までのエラー応答です。結果は次のとおりでした。

4,998件が 404（ページが見つからない）、2件が 400（リクエストの形式が不正）
中身を返した応答（200）は0件
多い日は1日2,484件、少ない日でも390件

10月18日の昼前には、1時間で1,901件が集中しました。すべて同じツールからのアクセスです。よく使われるファイル名の一覧を上から順に試す、辞書型スキャンと呼ばれる手口です。

何を探しているのか

届いたパスを種類ごとに分けると、次のようになりました。

WordPress と PHP 関連: 1,697件
.env などの設定ファイルや認証情報: 1,436件
.git フォルダ: 117件
バックアップファイル: 35件
API の仕様書（Swagger など）: 15件
Java の管理用画面（actuator）: 8件

WordPress の管理画面

最も多かったのは /wp-login.php で、106件ありました。/wp-admin/install.php や /xmlrpc.php も続きます。

相手は、こちらが WordPress かどうかを確かめていません。インターネット上のサイトを片端から試し、当たったところだけを攻撃します。使っていないから安全、ではなく「使っていなくても届く」と考えてください。

.env とその派生形

.env は、データベースのパスワードや外部サービスの鍵をまとめて書く設定ファイルです。開発では便利ですが、公開すべきものではありません。

目立ったのは、名前の派生形の多さです。

/.env.bak、/.env.backup、/.env.old
/.env.local、/.env.production、/.env.prod、/.env.development
/api/.env、/backend/.env、/laravel/.env

この一覧は、実際に起きた事故の記録とも読めます。作業中にコピーした .env.bak を消し忘れた。本番用の .env.production を公開フォルダに置いた。そうした事故が過去にあったから、攻撃側の一覧に名前が載っています。

ほかに /.aws/credentials（AWS の鍵）や /credentials.json も探されていました。

.git フォルダ

/.git/config や /.git/HEAD も繰り返し届きます。.git は、Git がソースコードの変更履歴を保存するフォルダです。

これが公開されていると、ソースコード全体を復元されるおそれがあります。過去に一度だけ書いてすぐ消したパスワードも、履歴には残っています。

自分のサイトで確認する方法

次のコマンドで、主なパスが中身を返していないかを確かめられます。example.com は自分のドメインに置き換えてください。

for p in /.env /.env.bak /.env.production /api/.env /.git/config /.git/HEAD /phpinfo.php; do
  printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' https://example.com$p)" "$p"
done

すべて 404 なら、ひとまず安心です。200 が返るものがあれば、中身を開いて確認してください。

ただし、200 でも安全な場合があります。存在しないページに、トップページを返す設定のサイトです。この場合は、応答の中身がトップページと同じかどうかで見分けます。

どの工程で防ぐか

この種の事故は、サーバーを監視して見つけるより、作る段階で防ぐほうが確実です。

実装: 秘密の値はファイルに置かず、秘密情報の管理サービスから読み込む
ビルド: 公開するフォルダに .env や .git が入っていないかを自動で調べる
リリース前: 上のコマンドを確認項目に加え、本番の URL に対して実行する

Bugoon では、秘密の値をファイルとして配布していません。また、アプリが定義していないパスはすべて 404 を返します。今回の約5,000件も、中身を返したものはありませんでした。

まとめ

使っていない仕組みへの攻撃も、毎日届く
探されるファイル名の一覧は、過去の事故の一覧でもある
確認はコマンド1つで済む。リリース前の確認項目に入れておく

今後は、こうした探索の件数を日々の監視に組み込むことも検討しています。いつもと違う動きに、早く気づく手がかりになるかもしれません。

WordPress を使っていないのに、毎日 WordPress の脆弱性を突かれている話