パブリッククラウドのハニーポット観測結果: 脆弱なSSH、Samba、Postgres、RDPを数百台デプロイして攻撃アクティビティを分析

This post is also available in: English (英語)

概要

「安全でない状態で公開されたサービス」はクラウド環境では最もよく見られる設定ミスの1つで、これらのサービスはインターネットから発見でき、同一インフラ内のクラウドワークロードに大きなリスクをもたらす可能性があります。REvilやMespinozaなどの悪名高いランサムウェアグループは、公開サービスを悪用して被害環境への初期アクセスを行うことで知られています。そこでUnit 42のリサーチャーは、パブリッククラウドで公開されているサービスに対する攻撃への理解を深めるべく、グローバルにデプロイされた320ノードからなるハニーポットインフラを利用することにしました。

これら320のハニーポットインフラに、リモートデスクトッププロトコル(RDP)、セキュアシェルプロトコル(SSH)、サーバーメッセージブロック(SMB)、Postgresデータベースの複数のインスタンスをデプロイしたところ、これらハニーポットの80%が24時間以内に侵害され、100%が1週間以内に侵害されたことを確認しました。とりわけ目についた発見は以下のようなものです。

• 最も攻撃の多かったアプリケーションはSSHで、攻撃者数、侵害イベント数が他の3つのアプリケーションに比べて非常に多くなっていました。
• 最も攻撃の多かったSSHハニーポットでは1日で169回の侵害が発生していました。
• 各SSHハニーポットは平均して1日に26回侵害を受けていました。
• ある脅威アクターは単独で30秒以内にグローバルに80台あるPostgresハニーポットの96%を侵害していました。
• 攻撃元IPアドレスの85%はその日1日しか観測されませんでした。この数字は「攻撃者が同じIPを再利用して攻撃を仕掛けることはほとんどないのでレイヤー3のIPベースのファイアウォールは効果がない」ということを示しています。今日作成された悪意のあるIPのリストは、明日には古くなっている可能性があります。

脆弱性対策の進捗は、日単位ないし月単位で計測されるのがふつうですので、攻撃者が数分で私たちのハニーポットを見つけ出し、侵害可能であるという事実は衝撃的でした。今回の調査では、安全でない状態で公開されているサービスのリスクが明らかになり、セキュリティ問題を迅速に緩和し、パッチを適用することの重要性が改めて浮き彫りになりました。設定ミスや脆弱性のあるサービスがインターネット上に公開されれば、攻撃者はものの数分でそのサービスを発見・侵害してしまうので、セキュリティ修正が間に合うタイミングは本当に限られています。このタイミングを逸することはできません。

Prisma Cloudは、クラウドネイティブ環境のリスクに優先順位を与えつつ、アプリケーションのライフサイクル全体にわたり脆弱性や設定ミスを特定して防止することができます。VM-Seriesファイアウォールは、仮想化環境における悪意のある活動の検知と防御に役立ちます。

方法論

2021年7月から2021年8月にかけて、Unit 42のリサーチャーは、北米(NA)、アジア太平洋(APAC)、ヨーロッパ(EU)に320台のハニーポットを設置しました。この調査では、これらのハニーポットインフラで観測された攻撃の日時、頻度、発信元について分析しています。

これらハニーポットのインフラには、SSH、Samba、Postgres、RDPの4種類のアプリケーションを等しくデプロイし、弱い認証情報を持つアカウント(たとえばadmin:admin、guest:guest、admin:password)をいくつか意図的に設定しておきました。これらのアカウントには、サンドボックス環境でアプリケーションへの限定的アクセスを許可してあり、各ハニーポットは、侵害イベントの検出時 (脅威アクターがいずれかの認証情報を用いて認証に成功し、アプリケーションにアクセスできるようになった場合) にリセットされ、再デプロイされます。

ハニーポットの一部では既知のスキャナIPリストをブロックし、ネットワークスキャントラフィックのブロック効果を分析しました。そのさいのファイアウォールポリシーは、観測されたネットワークスキャントラフィックに基づき、1日1回更新します。アプリケーションや日数にもよりますが、各ファイアウォールポリシーでは、600〜3,000の既知のスキャナIPアドレスがブロックされています。

ハニーポットログの全ログは、単一Elasticsearchクラスタに集約しました。1台のコントローラサーバーでログを継続的に監視し、各ハニーポットの健康状態をチェックします。侵害イベント検出時や、仮想マシンが無応答になったときには、このコントローラで仮想マシンとアプリケーションを再デプロイしました。図1は、ハニーポットインフラのアーキテクチャを示したものです。

攻撃パターン

図2〜図5は攻撃の日時、頻度、発信元を分析した結果を示しています。なおここでは「最初の侵害までにかかる時間」を「アプリケーションが最初に侵害されるまでの無傷な状態であった時間」と定義しています。図2は、320ある全ハニーポットの「最初の侵害までにかかる時間」の平均 (単位: 分) を示したものです。この「最初の侵害までにかかる時間」とは要するに「攻撃者がインターネット上で新しいサービスを発見して侵害するまでにかかる時間」のことで、これは「公開されてしまったサービスに関するセキュリティアラートを受け取ってから攻撃を受けるまで」にIT管理者に許された対応時間と似たものになります。

「最初の侵害までにかかる時間」はアプリケーションによって異なりますが、おおよそではそのアプリケーションを標的とする攻撃者数に反比例します(図4参照)。攻撃者数が増えるほど、そのアプリケーションが最初に侵害されるまでにかかる時間は短くなります。

「平均侵害インターバル」は、「あるアプリケーションで侵害イベントが発生した後、次に同じアプリケーションに対する侵害イベントが発生するまでに経過した平均の時間」を指しています。図3は、30日間の各ハニーポットアプリケーションの「平均侵害インターバル」を示したものです。

インターネット上にある脆弱なサービスは、複数の異なる攻撃者によって何度も侵害されるのがふつうです。被害者のリソースを奪い合って、ほかのサイバー犯罪者グループ (RockeやTeamTNTなど) が残したマルウェアやバックドアを排除しようとすることもよくあります。このため、「平均侵害インターバル」は「ある攻撃者がべつの攻撃者が現れるまでに侵害システム上で持つことのできる時間」と似たものとなります。「最初の侵害までにかかる時間」同様、アプリケーションの「平均侵害インターバル」も、そのアプリケーションを標的とする攻撃者数に反比例して短くなります。

図4は、この30日間に各ハニーポットで観測されたユニークな攻撃元IPアドレス数の平均を示したものです。この数は、各ハニーポットに対する侵害回数も表しています。なお、この数字はグローバルに観測された攻撃元IPアドレスの数ではありません。攻撃元IPアドレスの大半は、ハニーポットのほんの一部にしか到達しないため、グローバルで観測される攻撃元IP数はこの数よりずっと多くなります。私たちの検証では、複数のハニーポットに到達した攻撃元IPは18%にすぎませんでした。

図5は、「ある特定の攻撃元IPアドレスが何日間繰り返し観測されたか」を日数ごとにグループ化して示したものです。今回調査した30日間では、攻撃元IPアドレスの85％は特定のある1日にしか観測されませんでした。 この数字は「攻撃者が同じIPを再利用して攻撃を仕掛けることはほとんどないのでレイヤー3のIPベースのファイアウォールは効果がない」ということを示しています。今日作成された悪意のあるIPのリストは、明日には古くなっている可能性があります。

ファイアウォールの有効性

先のネットワークスキャン活動の調査では、毎日70万以上のスキャナIPが確認されました。私たちは「ネットワークスキャントラフィックを積極的にブロックすれば攻撃者によるハニーポット発見を防ぎ攻撃回数を減らせるか」に興味を持ちました。この仮説を検証するため、48台のハニーポットからなる検証グループを作り、既知のネットワークスキャナからのIPをブロックするファイアウォールポリシーを適用しました。このファイアウォールポリシーは、過去30日間に特定のアプリケーションを毎日スキャンしていたIPをブロックするものです。図6は、各ハニーポットで観測された攻撃数を「対照群(ファイアウォールなし)」と「実験群(ファイアウォールあり)」で比較したものですが、これら2つのグループ間に大きな差は見られませんでした。このことから、既知のスキャナIPをブロックしても攻撃軽減効果は薄いということがわかります。

地域による影響

私たちは「地理的に異なる場所にデプロイされたサービスの攻撃方法には差異があるか」にも興味を持ちました。図7は各ハニーポットで観測された攻撃数を地理的な分布別で比較したものですが、異なる場所にデプロイされたSamba、Postgres、RDPの各ハニーポットに有意な差は見られませんでした。ただし、SSHハニーポットへの攻撃の集中度合いは、地域によって大きく異なることがわかりました。APACに設置されたハニーポットに対するSSH攻撃件数は、NAのそれと比べて50％、EUでは263％も多くなっていました。また図8に示すように、これらの数字は攻撃発信元と興味深い相関関係がありました。攻撃元IPアドレスの50％はAPACから、20％はNAから、10％以下はEUから発信されています。このことから、「APAC地域に設置されたSSHサービスは、他の地域と比べて攻撃されやすい」ということがわかります。

結論

パブリッククラウドで安全でないサービスが公開されるという問題はとりたてて珍しくもありませんが、クラウドインフラの管理がアジャイルであるがゆえに、こうした設定ミスの作り込みと複製もそれだけ急速に行われてしまいます。今回の調査では、こうした設定ミスのもたらすリスクやその深刻さが強調される結果となりました。脆弱なサービスがインターネット上に公開されれば、いつもスキをうかがっている攻撃者にはわずか数分で発見・攻撃されてしまいます。インターネットに向けられたこうしたサービスの大半が、なんらかのクラウドワークロードに接続されていることから、1つのサービス侵害は、クラウド環境全体の侵害にもつながりかねません。

ただしこうした設定ミスは、クラウドネイティブなアプローチを使えば防止・修正も難しくありません。システム管理者がとれる戦略としては以下のようなものがあります。

• 特権ポートがオープンにされないようガードレールを作る。たとえば、AWS Service Control PoliciesやAzure Firewall Managementを使用する。
• 監査ルールを作成してオープンポートと公開サービスをすべて監視する。たとえば、AWS Config、Checkov、またはCloud Security Posture Management ツールを使用する。
• 自動応答/修復ルールを作成しておき、設定ミスを自動修正する。たとえば、AWS Security HubやPrisma Cloud Automated Remediationなどがその候補となる。
• VM-Series次世代ファイアウォールやWAFなどをアプリケーションの前段に導入して悪意のあるトラフィックをブロックする。