2022.10.11

ラボ環境で観測したログイン試行攻撃の傾向から考える対策

著者：MBSD-SOC

監視

MBSD-SOCではセキュリティ製品の機能検証やサービス企画のために、様々なラボ環境を運用しています。今回はラボ用ブログサイトの管理画面へのアクセス試行の傾向を確認し、どのような対策を取れるか考えました。

ラボ環境の準備

ラボ環境を準備する際に、不審なリクエストが着弾しやすくなるようにと考え、以下の点を工夫しました。

辞書にある汎用的な言葉を使ったドメインを取得し、ネイキッドドメインでサイトを公開
WordPressで構築し、管理画面(wp-login)を公開
レスポンスからWordPressバージョンやPHPバージョンなどが分かるようにした
WordPressのREST APIは公開したままにした
記事投稿者の表示がWordPressのログインユーザ名となるように設定した

図:記事投稿者として表示されているユーザ名でそのままログイン可能に

また、セキュリティ面の考慮もしています。

他所に影響させないため、xmlrpcはサーバ側で無効化し、危険なリクエストはWAFでブロック
思わぬ脆弱性の影響を受けないため、プラグインの使用は必要最低限とした
サーバからのアウトバウンド通信を必要な通信先に限定
パスワードを厳しく設定 (長さ・複雑性・ランダム文字列)
IPアドレス直接指定によるアクセスを不可とする (WAFをバイパスさせない)

図:構成イメージ

アクセスの傾向

今回はある3ヶ月間のアクセス傾向を集計しました。期待したとおり、公開後すぐにwp-loginへのリクエストが来ていました。
(※本記事の集計結果からは筆者自身によるアクセスを除外しています)

傾向(1): まず、サイト公開から24時間以内にスキャンと思われるリクエストを観測しました。このスキャン元にはWordPressのユーザ名が収集されたものと推測されます。

"GET / HTTP/1.1"
"GET //wp-includes/wlwmanifest.xml HTTP/1.1"
"GET //?author=1 HTTP/1.1"
"GET //?author=2 HTTP/1.1"
"GET //wp-json/wp/v2/users/ HTTP/1.1"
"GET //wp-json/oembed/1.0/embed?url=https://example.com/ HTTP/1.1"

サイト公開から48時間以内にはwp-loginへのログインブルートフォースを観測しました。送信元IPは最初のスキャンとは異なりますが、リクエスト先のパスをダブルスラッシュで指定している点やUser-Agentも同一であったことから、同じツールを使用していた可能性もあるかと想像しています。
(※念のため、全てのログイン試行が失敗していることを確認済みです)

"GET / HTTP/1.1"
"GET //wp-includes/wlwmanifest.xml HTTP/1.1"
"GET //wp-login.php HTTP/1.1"
"GET //?author=1 HTTP/1.1"
"GET //?author=2 HTTP/1.1"
"GET //wp-json/wp/v2/users/ HTTP/1.1"
"POST //wp-login.php HTTP/1.1"
・・・以降つづく

以降、wp-loginへのログイン試行は断続的に発生していました。

図:WPログインログを時系列に集計

傾向(2): ログイン試行されたユーザ名を集計しました。1位は記事投稿の際に使用したユーザ名、2位は実際に存在するユーザ名ですが記事投稿では使用していないユーザです。いずれもスキャンなどによって分かる情報であり、下調べした上でのログイン試行が多かったものと推測されます。

表:ログイン試行ユーザ

送信元IPを、"横軸:登場日数"と"縦軸:登場日あたりの平均ログイン試行回数"のグラフに■マークでプロットしました。

傾向(3):1日しか登場しない送信元は、一度に大量のログイン試行をしている傾向が見受けられます。また、傾向(4): 複数日に渡って登場する送信元は、1日あたりのログイン試行回数が少ない傾向が見受けられます。送信元や試行間隔を分散したログイン試行の可能性が考えられると思います。(プロットした■マークが重なってしまっていて少し見にくくなってしまいました。ご容赦ください・・・。)

図:送信元IPを登場日数と平均ログイン試行回数でプロット
※縦軸は見やすさのため対数軸にしています

傾向(5): 調査期間のうち、送信元IPごとに最初に観測した日付と最後に観測した日付を比較して生存期間を確認し、グラフにプロットしました。生存期間が1日(=1度しか登場していない送信元)のものが最も多いですが、平均では約26日間生存、最長で87日間生存している送信元も見受けられました。(思ったより長く感じます)

図:送信元IPの生存期間をプロット
※縦軸は見やすさのため対数軸にしています

考察

本件はスキャンなどにより予めユーザのリストが判明した状況でのブルートフォース攻撃であり、不特定多数の利用者が存在する会員向けWebサービスとは状況が異なります。

本検証のような特定の人間しかアクセスしない管理画面であれば、ユーザ名/パスワードを類推しにくい複雑なものに設定しておくとか、そもそも管理画面を外部公開しない又はIPアドレスなどを指定して許可リストを構成する事が手っ取り早いです。

不特定多数の利用者が存在する会員向けWebサービスでは、アプリケーション側での対応(多要素認証、ログイン試行回数の制限、CAPTCHAなど)や、SIEMなどでログイン状況のモニタリングをすることが第一と考えます。その一方で、以下のようなジレンマもあるものと想像します。

自動化されたログインを弾くための機能(CAPTCHAなど)の使用やログイン試行回数の制限などを設けたいが、利用者の利便性を損ねたくない。
対策を緩くしてしまうと、利用者が簡単なパスワードを設定してしまったり、パスワードの使い回しなどをしてしまうことで、ブルートフォース攻撃やリスト型攻撃の被害を受けてしまう可能性がある。

図:CAPTCHAのイメージ。最近は上記のようなCAPTCHAはあまり見かけなくなってきましたが。。。

このような観点から、プラスアルファ的な対策を取るために、WAFなどのセキュリティ製品での対応も選択肢の一つになってくると思われます。

傾向(3)からは単一の送信元が短期間に多数のログイン試行を観測しているケースを確認できましたが、傾向(4)より全体としては送信元および試行間隔を分散した試行がほとんどであったことから、単純な閾値ベースのルールで防げるログイン試行は限定的と考えられます。コストはかかりますが、高機能WAFなどに実装されている自動化されたログイン試行の対策(Bot対策ソリューションなど)を活用することが有効になってくると考えます。
傾向(5)からは不審なログイン試行を数日～数週間にわたり継続している多数の送信元の存在を確認できましたので、IPアドレスでのブロック対応も部分的には効果があるかもしれません。ブロックリストへの登録を自動化したり、コミュニティなどで共有されているインテリジェンスフィードを使用するのも良いかもしれません。
ただし、レジデンシャルプロキシなどと呼ばれるサービスを悪用するなど、クリーンなIPを使用することで、ブロックリストなどによる対策を回避するケースもあると言われているので、IPでの対応はいたちごっこになるのが容易に想像できます。
(参考：The Cloudflare Blog: Cleaning up bad bots (and the climate))

検証

今回はクラウドフレアのBot Management機能を用いた対策を試してみました。wp-loginの場合はログインの仕組みが比較的シンプルですので、以下のような条件でボットによるログイン試行を検知するルールを設定しました。

URLパス：/wp-login.php
リクエストメソッド：POST
クラウドフレアによりボット判定されたリクエスト
クラウドフレアの検証済みボットではない(※)
※クラウドフレアにより識別された検索エンジンなどの正規ボット(クローラー)のこと。正規ボットがPOSTでリクエストしてくることは無いと思いますが、念のため正規ボットからのリクエストを許可するように構成しておくと、より安心です。

図:ルール設定イメージ

検証結果

以下の図は、緑:ログイン試行回数(WPログインログより)、青:ボット機能によるログイン試行検知数を表したグラフです。それぞれの検知件数が概ね同数であることから、多くのログイン試行をボット検知用ルールで検知できていることが分かりました。(※検証の都合上、ボット検知用ルールで検知したログイン試行をブロックせずに検知モードに設定していたため、最終的にはログイン試行に至っています。)