Cisco Japan Blog
Share

脅威の動向:Snort IPS


2023年7月28日


この記事は、Cisco Security Business Group の Threat Intelligence Analyst である Ben Nahorney によるブログ「 Threat Trends: Snort IPS」(2023/6/13)の抄訳です。

この ThreatWise TV のエピソードでは、Brandon Stultz と Nick Mavis が Snort 3.0 の概要をわかりやすく説明しています。また、Snort シグネチャがトリガーされることの多い脆弱性の種類についても触れています。

Snort が Cisco Secure Firewall アプライアンスで検知しているものをシスコが調査したのは 1 年半ほど前のことです。サイバー脅威を取り巻く状況は急速に変化している可能性があります。そこで、こちらの ThreatWise TV のエピソードでも取り上げていますが、改めてデータセットを調べ、脅威環境がどのように変化したか確認することにしました。はたして何か変化はあったのでしょうか。データを深堀りして明らかにしたいと思います。

シスコのアプローチ

まず、データの調査方法について簡単に触れておきます。特に指定がない限り、2022 年 1 月から 12 月のデータを対象としています。前回と同様、あるルールが特定の組織でトリガーされた場合、その組織を 1 回だけカウントすることとします。こうすることで、頻繁にトリガーされるルールによるノイズを減らせるだけでなく、特定のルールに遭遇した組織の割合も把握できます(詳細については、下の「調査方法」のセクションを参照してください)。

次々に発生する Log4Shell のエクスプロイト

Nick と Brandon が述べているように、攻撃者は脆弱なシステムを見つけるために、ありとあらゆるものに Log4J のエクスプロイトを「まき散らして」おり、その結果が現れています。2022 年には、Log4J 関連のルールによるアラートが他のすべてのアラートを上回っただけでなく、調査した期間のどこをとっても、これほど多くの組織でトリガーされたルールやエクスプロイト試行は他にありませんでした。

Log4J は、いったいどのくらい広まっていたのでしょうか。2022 年は 72% の組織が、Log4J に対する Snort ルールによるアラートをファイアウォールで確認しました。もちろん、攻撃の量にはばらつきがあります。何百万ものアラートが確認された組織もあれば、ほんのわずかしか確認されなかった組織もあります。当然ながら、攻撃の量に影響する要因はいくつかありますが、2022 年には、標準的な組織で毎月約 110 件の Log4J のアラートが確認されました。つまり、1 日あたり 3 ~ 4 回エクスプロイトが試みられたということになります。

古くから確認されている脆弱性

その他に確認されたエクスプロイトを見ていると、まるで大ヒット曲のプレイリストを見ているような気がします。5 ~ 6 年前、さらには 9 年前には確認されていた脆弱性の多くが、前回データを調査したときにもエクスプロイトのリストに入っていました。PHPUnit や JBoss の脆弱性、さまざまなルータに存在する脆弱性、そして Shellshock の脆弱性は、いずれも繰り返し登場しています。

ルール 説明 CVE(該当する場合)
45749 PHPUnit における PHP のリモートコード実行の試み CVE-2017-9841
31976
31977
31978
32041
32042
32043
Bash CGI における環境変数インジェクションの試み CVE-2014-7169
CVE-2014-6278
CVE-2014-6277
CVE-2014-6271
34300 複数の D-Link 製品における HNAP SOAPAction ヘッダーへのコマンドインジェクションの試み CVE-2015-2051
46624 GPON ルータにおける認証バイパスとコマンドインジェクションの試み CVE-2018-10562
24343 JBoss における JMXInvokerServlet へのアクセスの試み CVE-2013-2185
CVE-2007-1036
44687 Netgear DGN1000 シリーズのルータにおける認証バイパスの試み
30790
30791
30792
30793
59416
Java クラスローダへのアクセスの試み CVE-2022-22965
CVE-2014-0114
CVE-2014-0094

特筆すべき新しい脆弱性が、Spring4Shell という Java Spring フレームワークの脆弱性です。この脆弱性は 2022 年 4 月に公開されました。名前の付け方が Log4J と似ていて、広く使われているライブラリの欠陥だという点も同じですが、エクスプロイトに必要な条件がはるかに狭いため、Log4J と比較すると影響は限定的です。それにもかかわらず、Snort のテレメトリでは、攻撃者がこの脆弱性のエクスプロイトを実際に試みており、全組織のほぼ半数でこの脆弱性に対するアラートが確認されています。

新たなエクスプロイトの試みが増加

Log4J に対する頻繁なエクスプロイト試行と、Spring4Shell のエクスプロイト状況を確認した後、1 つの疑問が生じました。それは、前回データを調べたときよりも、新しい脆弱性に対するアラートの頻度が増えているのではないかということです。

この疑問に答えるために、2021 年と 2022 年の同じ期間(第 2 四半期と第 3 四半期)に、少なくとも 25% の組織でトリガーが確認されたルールを調べました。次に、その年と前年の CVE の数を数え、「新しい」CVE として分類しました。

では、新しい CVE が多かったのはどちらの時期でしょうか。2021 年は、
確認された CVE の 21% が新しいものでした。ところが、2022 年には新しい CVE が 30% に増加しています。このことから、攻撃者は以前よりも頻繁に新しいエクスプロイトを試していると考えられます。

Confluence、Apache HTTP Server、VMware、Microsoft Exchange などのアプリケーションで、新しい脆弱性が見つかっています。Spring フレームワークの脆弱性も新しい CVE の 1 つです。

ルール 説明 CVE(該当する場合)
59934
59948
Atlassian Confluence における OGNL 式インジェクションの試み CVE-2022-26134
30790
30791
30792
30793
59416
Java クラスローダへのアクセスの試み CVE-2022-22965
59388 Spring Cloud Gateway における Spring Expression Language インジェクションの試み CVE-2022-22963
59824 VMware Workspace ONE Access におけるサーバー側のテンプレート インジェクションの試み CVE-2022-22954
58722
58723
58724
58725
58726
58727
58728
58729
58730
58731
58732
58733
58734
58735
58736
58737
58738
58739
58740
58741
58742
58743
58744
58751
58784
58785
58787
58788
58795
58801
59246
Apache Log4j ロギングライブラリにおけるリモートコード実行の試み CVE-2021-45105
CVE-2021-45046
CVE-2021-44832
CVE-2021-44228
58276 Apache HTTP Server(httpd)におけるディレクトリトラバーサルの試み CVE-2021-42013
CVE-2021-41773
57907 Microsoft Exchange Autodiscover におけるサーバー側のリクエスト偽造(SSRF)の試み CVE-2021-34523
CVE-2021-34473
CVE-2021-31207
57244 Microsoft Exchange Server におけるサーバー側のリクエスト偽造(SSRF)の試み CVE-2021-26855
57720 VMware vSphere Client におけるリモートコード実行の試み CVE-2021-21985

MITRE ATT&CK

MITRE ATT&CK の戦術と手法をもう一度見ておきます。

戦術 組織の割合 確認された手法
(頻度の高い順)
初期アクセス
[TA0001]
91.0% 外部公開されたアプリケーションへの攻撃 [T1190]
Web 閲覧による感染 [T1189]
正当なアカウント [T1178]
実行
[TA0002]
76.7% ユーザーによる実行 [T1204]
共有モジュール [T1129]
ネイティブ API [T1106]
コマンドとスクリプトインタープリタ [T1059]
クライアント実行のためのエクスプロイト [T1203]
コマンドアンドコントロール [TA0011] 76.3% Web サービス [T1102]
非アプリケーション層プロトコル [T1095]
アプリケーション層プロトコル [T1071]
リモート アクセス ソフトウェア [T1219]
特権昇格
[TA0004]
58.0% 特権昇格のためのエクスプロイト
[T1086]
アクセストークンの改ざん [T1134]
正当なアカウント [T1078]
収集
[TA0009]
49.2% ローカルシステムのデータ [T1005]
オーディオキャプチャ [T1123]
検出
[TA0007]
43.3% ファイルとディレクトリの検出 [T1083]
ログイン情報へのアクセス
[TA0006]
40.7% OS ログイン情報のダンプ [T1003]
保護されていないログイン情報 [T1552]
防御の回避
[TA0005]
37.5% アクセストークンの改ざん [T1134]
正当なアカウント [T1078]
永続化
[TA0003]
36.5% 正当なアカウント [T1078]
サーバー ソフトウェア コンポーネント [T1505]
アカウント操作 [T1098]
ブラウザ拡張機能 [T1176]
システムプロセスの作成または変更 [T1543]
実行フローのハイジャック [T1574]
外部リモートサービス [T1133]
影響
[TA0040]
28.3% リソースのハイジャック [T1496]

以前もそうでしたが、Snort では、他のどの戦術よりも初期アクセスの戦術に対するアラートが多く確認されます。この大部分を Log4J が占めており、外部公開されたアプリケーションへの攻撃手法に該当します。Shellshock のエクスプロイトや、前述の新しい CVE の多くも同様です。

実行の戦術が、2 番目に多く確認されたアラートタイプでした。Spring4Shell は、Drupal、WordPress、Apache Struts などのアプリケーションのエクスプロイトと同様、この戦術に該当します。

前回データを調査したときよりも、コマンドアンドコントロールの戦術に対するアラートが増加しています。最も多く確認されたのは、Mirai、AveMaria、Remcos、Chopper などのよく知られた脅威です。

Snort カテゴリ

最後に、最もアラートが多かった Snort カテゴリをいくつか見てみます。

ルール width=”356″>ルールの説明 width=”204″>CVE(該当する場合)
58722
58723
58724
58725
58726
58727
58728
58729
58730
58731
58732
58733
58734
58735
58736
58737
58738
58739
58740
58741
58742
58743
58744
58751
58784
58785
58787
58788
58795
58801
59246
Apache Log4j ロギングライブラリにおけるリモートコード実行の試み CVE-2021-45105
CVE-2021-45046
CVE-2021-44832
CVE-2021-44228
30524 OpenSSL TLSv1.1 におけるハートビート読み取りオーバーランの試み CVE-2014-0160
60725
60726
Fortinet FortiOS および FortiProxy における認証バイパスの試み CVE-2022-40684
CVE-2022-40685

Log4J がこのリストのトップにくることには驚きませんが、Heartbleed のエクスプロイトと、Fortinet のアプリケーションの新たなエクスプロイトもこのカテゴリに入っています。

ルール ルールの説明 CVE(該当する場合)
45749 PHPUnit における PHP のリモートコード実行の試み CVE-2017-9841
34300 複数の D-Link 製品における HNAP SOAPAction ヘッダーへのコマンドインジェクションの試み CVE-2015-2051
46624 GPON ルータにおける認証バイパスとコマンドインジェクションの試み CVE-2018-10562
24343
24342
21516
21517
JBoss における JMXInvokerServlet へのアクセスの試み CVE-2013-2185
CVE-2007-1036
44687 Netgear DGN1000 シリーズのルータにおける認証バイパスの試み
58276 Apache HTTP Server(httpd)におけるディレクトリトラバーサルの試み CVE-2021-41773
CVE-2021-42013
57907 Microsoft Exchange Autodiscover におけるサーバー側のリクエスト偽造(SSRF)の試み CVE-2021-31207
CVE-2021-34523
CVE-2021-34473

前回取り上げた Web アプリケーションに対するエクスプロイトの多くが今も使用されています。一方、Apache HTTP Server と Microsoft Exchange Server に影響を与える 2 つの新しいエクスプロイトが、このカテゴリに加わりました。

ルール ルールの説明 CVE(該当する場合)
58992 User-Agent 文字列に既知の悪意のある文字列を使用 – Mirai
53856 Embedded.Exploit.Hoaxcalls 亜種のアウトバウンド接続
58115 Win.Trojan.AveMaria 亜種のアウトバウンド接続
47299 Win.Trojan.Remcos 亜種のアウトバウンド接続
37245 Win.Backdoor.Chopper Web シェルによる接続

このカテゴリは、前回このデータを調査したときと比べてアクティビティが増えています。60% 近くの組織で CNC トラフィックに対するアラートが確認されており、前回の 49% から増加しました。

まとめ

では、これらの分析によって、Snort が検知している攻撃に関して何がわかるのでしょうか。

Log4J が及ぼした影響から目を背けることはできません。2022 年には、この一連のエクスプロイトが他を圧倒しました。またデータが示しているように、攻撃者が何年も前の脆弱性をいまだに展開していることを考えると、Log4J はこの先何年も存在し続けるでしょう。

Log4J によって自信を得たのか、攻撃者は過去の脆弱性よりも新しい脆弱性を利用しようとしているようです。古いエクスプロイトの試みが多く見られるのは確かですが、新しいエクスプロイトに対するアラートが増えていることから、行動が変化している可能性があります。つまり、セキュリティ態勢を強化するうえでは、脆弱性評価が一層重要な部分を占めるようになるでしょう。

ほぼ間違いなく、ここで取り組むべき最も重要な戦術と手法は、一般公開されているアプリケーションに対する最初のアクセスの試みに対処することです。確かに、優れたファイアウォールを設置することで、このような攻撃の多くにアラートを発することができます。ただ同じくらい重要なのが、アプリケーションにパッチを適用し続けることと、一般に公開するものとしないものを注意深く評価することです。サービスを公開する必要がないのであれば、敢えて公開してリスクを負う必要はありません。

Snort と Cisco Secure Firewall の利用

Snort はオープンソースの侵入防御システム(IPS)であり、ルールを使用して悪意のあるネットワークアクティビティを検出します。Snort ルールとして配布されるものには、コミュニティルールセットSnort サブスクライバルールセットの 2 種類があります。前者は Snort コミュニティによって開発されたものであり、後者は Talos Intelligence によって開発および承認されたものです。どちらのルールセットも Talos によって QA が実施されています。

シスコは、Cisco Secure Firewall で Snort 検出エンジンと Snort サブスクライバルールセットを活用しています。Cisco Secure Firewall ポートフォリオは、進化を続ける複雑な脅威からネットワークをより強力に保護します。シスコ製品を利用すれば、俊敏性と統合性の両方を兼ね備えたセキュリティ基盤に投資していることになります。これにより、強力なセキュリティ態勢を構築できます。

次期 Cisco Secure Firewall 4200 アプライアンスと OS バージョン 7.4 は、性能、セキュリティ、接続性の水準を高めます。4 倍のスループット向上を実現し、1 ラックユニットで最大 200GE のインターフェイスをサポートすることで、脅威をより迅速に検出します。Cisco Secure Firewall 4200 シリーズは、優れた可視性によって脅威の検出を高速化し、設置面積を抑えながら大規模な企業やキャンパス、データセンターを保護するための俊敏性を提供します。

調査方法

ほとんどの点で、2021 年 10 月に初めて Snort のデータを調査したときと
同じ方法を使用しています。製品のテレメトリは、Cisco Secure Firewall のデータをオプトインで共有している企業から入手しています。分析に先立ち、データを匿名化して集計しています。

この分析では、Snort の標準テキストルールと共有オブジェクトルールを調査しています。いずれのルールも Talos が提供したものです。これらのルールのうち、Snort FAQ に記載されているポリシー 1 ~ 3 に関するルールをフィルタにかけています。ほとんどの展開でこれらのポリシーのいずれかが利用されているため、大多数の組織が直面している状況をより明確に把握でき、誤検出をほぼ取り除くこともできます。


ぜひお客様のご意見をお聞かせください。以下から質問やコメントを投稿し、ソーシャルネットワークで Cisco Secure の最新情報を入手してください。

Cisco Secure ソーシャルメディア

Instagrampopup_icon
Facebookpopup_icon
Twitterpopup_icon
LinkedInpopup_icon

 

Tags:
コメントを書く