拾う攻撃と、狙う攻撃 ― 43万回のスキャンを調べた、その先で見つかったもの

今朝、43万回を超える不審なアクセスについて記事を書きました。

JPCERT/CCが公表した不審なIPアドレスをきっかけに、自分が管理するサーバーのログを7か月分調べたものです。

そこで見つかったのは、1,015個のIPアドレスから43万5,064回に及ぶ、Webシェルを探すようなアクセスでした。

攻撃者は必ずしも自分で侵入する必要はない。

誰かが過去に侵入して残した裏口を、インターネット上で探して回ればよい。

今朝の記事では、そうした攻撃の実態を紹介しました。

しかし、記事を書いたあとで考えました。

この攻撃だけでは、最近相次いでいる企業への不正アクセスを説明しきれない。

最近の事案では、特定のアプリケーションやAPI、認証機能、管理画面が問題になっています。

既に置かれたWebシェルを探す行為と、特定製品の弱点を狙う行為では、目的が違います。

ならば、ほかの攻撃パターンもログに残っているはずです。

そこで、もう一度調べてみました。

1. 大量のスキャンは、何を探していたのか

今朝の記事で扱ったアクセスは、Webシェルや設定ファイルなど、既に存在するものを探す動きが中心でした。

例えば、次のようなファイルです。

• .env ― APIキーやパスワードなどが保存されることのある設定ファイル
• .git/config ― Gitリポジトリの設定情報
• shell.php ― Webシェルに使われることのあるファイル名
• config.php.bak ― 設定ファイルのバックアップ

これらのアクセスには共通点があります。

相手のサーバーで何の製品が動いているか、詳しく知らなくても試せることです。

存在しなければ404が返る。認証が必要なら401や403が返る。

しかし、ファイルが公開されていれば、そのまま取得できる可能性があります。

鍵を壊すのではありません。

落ちている鍵を拾って回る。

このタイプのスキャンが、インターネット上で大量に行われていました。

2. 鍵をかけられた裏口は、スキャンに映らない

ここで、拾う攻撃について、一つ補足しておきます。

拾う攻撃は、「裏口が開いたまま放置されている」ことを前提にしています。

しかし、裏口が存在しても、外部からのスキャンでそのまま使えるとは限りません。

侵入に成功した攻撃者が、自分の置いた裏口にパスワードをかけたり、別の侵入者が入れないようにしたりすることは考えられます。あとから来る相手に、足場を横取りされないためです。

そうなっていれば、外から裏口の名前を試しても、認証を要求されたり、アクセスを拒否されたりすることがあります。パスワード保護されたWebシェルでもHTTP応答が返る場合があるためです。

つまり、Webシェルを探すスキャンが空振りしたからといって、そのサーバーに裏口が存在しないと断定することはできません。

裏口が存在しない場合もあれば、アクセスが制限されている場合もあります。

今回のログだけでは、その区別まではできません。

3. 攻撃者が探していた製品と、管理者が確認すべきこと

今朝と同じ問題意識で、手元のサーバー群のログを、今度はファイル名ではなくURLの構造から見直しました。Webシェル探しが目立ったサーバーとは別に、APIを返すサーバーのログも含めて確認しています。

すると、特定の製品や機能を狙ったと考えられるアクセスが見つかりました。代表的なものを並べます。

製品への関連付けは、観測URLから判断した候補です。URLへのアクセスだけでは、その製品の稼働や脆弱性の悪用は確認できません。

ここで、特定のCVE番号を無理につけないことを選びました。GeoServerの /geoserver/web/ は公式ドキュメントにも記載された管理画面のパスです。一方、認証やセッション関連のAPIパスは、複数の製品で似た名前が使われる可能性があるため、製品名を断定しないほうがよいものもあります。

ただし、公式資料と照合すると、次の3つはパスが一致し、製品名を明記できます。

• Bitget:注文APIのパスが公式API資料と一致します。
• Metabase:パスワード再設定APIが公式資料と一致します。
• SonicWall:認証APIのパスが公式資料と一致します。

もっとも、特定製品のパスを試したことと、その製品の脆弱性を突こうとしたことは別です。

実際に、APIを返すあるサーバーの約7週間分のログを集計すると、7種類の製品・機能に対して、合わせて281回のアクセスがありました。

最も多かったのはGeoServerの管理画面(115回・41個のIP)でした。暗号資産取引APIは回数こそ多いものの、送信元は3個のIPに集中し、約2か月にわたって断続的に続いていました。広く浅く投げる相手と、少数で粘る相手が混在しています。別のサーバーでも、顔ぶれはほぼ同じでした。

観測された応答は301・401・404で、200はありませんでした。さらに、サーバーの構成を確認したところ、一覧に挙げた製品はいずれも稼働していませんでした。

それでも、製品固有のURLを探すアクセスが繰り返されていたのです。

今回、私の管理するサーバーで観測した製品探索の一覧です。これらの製品に脆弱性があると確認したわけではありません。しかし、使っている製品が含まれていたら、管理画面やAPIが外部に公開されていないか、最新の修正が適用されているか、一度確認してください。

4. 拾う攻撃と、狙う攻撃

二つを並べると、違いが分かりやすくなります。

重要なのは、どちらも最初から人間が一台ずつ操作する必要はないことです。

特定製品のURLを調べる行為も、自動化できます。

インターネット全体に広く投げることもできます。

したがって、「拾う攻撃は無差別、狙う攻撃は標的型」と単純に分類するのは正確ではありません。

違うのは、探しているものです。

この違いによって、攻撃者が必要とする情報も、その後の攻撃も変わります。

5. 小さなサイトには、違う景色があった

今回、もう一つ比較してみたものがあります。

自分が管理している、用途の違う小さなサイトです。

一つは、現在ほとんど動かしていない静的なサイト。もう一つは、小規模なアプリケーションです。

これらにも、不審なアクセスは来ていました。

同じように製品を動かしていないサイトでも、アクセスの種類には違いがありました。

APIを返すサーバーでは、7種類の製品・機能に対するアクセスを確認しました。一方、静的サイトなどでは、一般的なファイル探索が中心でした。

この違いが何によって生じるのかは、まだ分かりません。

少なくとも、攻撃者が事前に製品の存在を確認してからアクセスしているとは限らないことが分かります。

6. 入口が見つかると、次は何が起きるのか

例えば、あるスキャナーが特定製品のAPIにアクセスしたとします。

返ってきたのが404なら、その場所には目的の機能が存在しない可能性があります。

一方、その製品に特有の応答やエラーメッセージが返ってくれば、スキャナーは製品の存在を推定できます。

さらにバージョンや設定まで分かれば、既知の脆弱性と照合することも可能です。

そこから実際の攻撃へ進むことは十分考えられます。

ただし、今回のログだけでは、製品固有のパスへのアクセスが、その後の侵害につながったことまでは確認できません。

製品を探すアクセスと、脆弱性を悪用するアクセスは区別する必要があります。

この点については、JPCERT/CCが10月8日に公表し、9日に更新した「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」も参考になります。

そこでは、既知の脆弱性を探して悪用するケースだけでなく、APIへの不正な操作、盗まれたAPIキーの利用、Webシェルの設置といった、異なる攻撃の類型が整理されています。

今回観測された製品探索は、その中の「既知の製品・機能を探す段階」に相当する可能性があります。ただし、これらのアクセスと、JPCERT/CCが把握する侵害事案との関連は確認できていません。

今回の製品固有パスを探すアクセスは、これまで考えてきた「鍵・鍵穴・地図」の構図のうち、「鍵穴」を探す行為と考えることができます。

7. IPアドレスより、何を探しているか

今朝の記事では、43万回を超えるアクセスの98%がMicrosoft Azureから発信されていたことを紹介しました。

しかし、別の種類の探索では、異なるホスティング事業者やVPSからのアクセスも見つかりました。

同じ攻撃者が使い分けているのか、別々の集団による活動なのかは分かりません。

IPアドレスの登録国も、操作している人物の所在地を示すものではありません。

ここで重要なのは、送信元だけを見ていても攻撃の目的は分からないということです。

あるIPはWebシェルを探している。

別のIPは特定製品の管理画面を探している。

さらに別のIPは、APIに対して不正なリクエストを送るかもしれません。

送信元IPアドレスを遮断する対策には意味があります。しかし、IPアドレスが変われば、同じ探索は続けられます。

一方、アクセス先のURLやリクエストの特徴を見れば、何を探しているのかを推測できます。

攻撃者がどこから来たかだけでなく、何を探しに来たか。

ログを見るうえで、こちらも重要です。

8. 見つけられても、使わせない

では、防御する側は何をすべきでしょうか。

製品名やバージョンを不用意に公開しないことは、攻撃者に手掛かりを与えないための一つの対策です。

しかし、それだけでは不十分です。

製品固有のURLは、公開情報やソフトウェアの仕様から推測できる場合があります。

攻撃者は製品を特定できなくても、既知のパスを片っ端から試せます。

だから、見つからないことを前提とした防御では危険です。

必要なのは、入口が知られても、その先で不正な操作ができない構成です。

管理画面や内部APIは、そもそも外部に公開する必要があるのか。

公開APIでは、認証だけでなく、操作対象ごとの権限確認が行われているか。

認証情報が盗まれても、利用できる権限や期間を限定できているか。

そして、攻撃が始まったとき、その変化に気づけるか。

Webシェルを探す大量スキャンにも、製品を探すアクセスにも、共通する守りがあります。

不要なファイルや機能を公開せず、既知の脆弱性を修正し、APIの認可を確認することです。

JPCERT/CCも、APIごとのアクセス制御、レート制限、最小権限、不要な管理機能の公開停止などを推奨しています。

9. 自分が何を公開しているか

今朝は、43万回を超えるアクセスから、Webシェルを探す攻撃の実態を紹介しました。

今回は別のログを調べ、7種類の製品・機能を探す281回のアクセスを確認しました。

GeoServer、Fortinet、SonicWall、QNAP、Bitget、Metabaseなどです。

しかし、私のサーバーでは、これらの製品を一つも動かしていません。

それでも探しに来ていました。

攻撃者は、製品が存在すると分かってから来るとは限りません。存在するかどうかを確かめるために、アクセスしているのです。

自社では使っていない製品を探すアクセスだから、問題ない。それで終わらせず、使っている製品に対しては何が来ているのか、ログを確認してほしいと思います。

攻撃者は、こちらが何を動かしているかを探しています。守る側も、自分たちの公開しているものを正確に把握する必要があります。