3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「公開から数時間で攻撃開始」― React2Shellが突きつけた、シグネチャ型WAFの限界

Last updated at Posted at 2025-12-09

Check Point マーケティング 大植です。
12月になって「React2Shell」の脆弱性や、関連した攻撃の報告が相次いでいます。
年末の脆弱性の対策としては、ちょうど4年前の2021年12月、「Log4Shell」が世界中のセキュリティチームを震撼させたことを思い出した人も多いのではないでしょうか。
2025年、Webアプリケーションを取り巻くセキュリティ環境は、かつてないほど厳しい状況にあります。世界中で利用されるフレームワークやライブラリに潜む脆弱性は、公開から数時間で攻撃に悪用されるケースが増加しています。
本記事では、昨今発生したゼロデイ脆弱性の事例を振り返りながら、従来型WAF(Web Application Firewall)の限界と、機械学習を活用した次世代の防御テクノロジーについて解説します。

Webアプリ攻撃の深刻化: 公開から数時間で標的になる脅威

近年、Webアプリケーションを標的としたゼロデイ攻撃が相次いで発生しています。特に注目すべき事例を振り返ってみましょう。

React2Shell(CVE-2025-55182):2025年12月

2025年12月3日、世界で最も広く使用されているJavaScriptライブラリ「React」およびフレームワーク「Next.js」において、CVSSスコア最大の10.0という極めて深刻な脆弱性が公開されました。「React2Shell」(または「React4Shell」)と呼ばれるこの脆弱性は、React Server Components(RSC)のFlightプロトコルにおける安全でないデシリアライゼーションに起因し、認証なしでリモートコード実行が可能となるものでした。

AWSの脅威インテリジェンスチームによると、脆弱性公開からわずか数時間で、中国の国家関連脅威グループによる攻撃が確認されました。Wizの調査では、クラウド環境の39%が脆弱なバージョンのReactまたはNext.jsを使用しているとの報告があり、影響範囲の広さが浮き彫りになっています。

※なお、機械学習ベースのWAFを導入していた環境では、シグネチャ更新を待たずにこの攻撃を防御できた(ゼロデイ保護)と報告されています(Check Point Blogopen-appsec Blog)。

国内大手ISPのメールサービス侵害事件:2025年4月

2025年4月、国内大手インターネットサービスプロバイダーが、法人向けメールセキュリティサービスにおいて深刻な不正アクセス被害を受けたことを公表しました。

この事件の原因は、サービスで使用されていた商用Webメールシステムに存在していたゼロデイ脆弱性でした。CVSSスコア9.8という緊急レベルの脆弱性で、スタックベースのバッファオーバーフローにより、リモートから任意のコードが実行可能でした。

注目すべきは、この脆弱性が攻撃開始時点(2024年8月)では、ソフトウェア開発元すら把握していない「真のゼロデイ」状態だったことです。つまり、少なくとも8ヶ月以上にわたり、攻撃者だけがこの脆弱性を知り、密かに攻撃を続けていました。

歴史的教訓:Apache Struts2と国産ECパッケージの脆弱性

過去の事例からも、Webアプリケーション脆弱性の脅威は明らかです。2017年、Apache Struts2の脆弱性(CVE-2017-5638)により、米国Equifaxで約1億4,800万人分の個人情報が流出しました。日本国内でもチケット販売大手や国土交通省のサイトなど多くの組織が被害を受け、脆弱性公開からわずか1日で攻撃が始まったケースもありました。

また、国内で広く利用されているオープンソースのECサイト構築パッケージでも、2019年以降、決済画面を改ざんしてクレジットカード情報を窃取する「フォームジャッキング」攻撃が多発。経済産業省が注意喚起を発出する事態となり、2019年時点で約14万件のカード番号が漏洩したと報告されています。2021年にも緊急度「高」のクロスサイトスクリプティング脆弱性が発覚し、複数サイトでカード情報流出が確認されました。

従来型WAFの限界

これらの事例に共通するのは、従来型のWAFでは防御が困難だったという点です。現在市場に出回っている多くのWAFは、シグネチャベースの検知手法を採用しています。この方式では、新しい脆弱性が発見された場合、以下のプロセスを経る必要があります:

  • 脆弱性の発見・公開
  • 攻撃手法の分析
  • シグネチャの作成・テスト
  • シグネチャの配信・適用

この間に攻撃者は、公開された脆弱性情報をもとに攻撃を開始できます。React2Shellのように「公開から数時間で攻撃開始」というケースでは、シグネチャの作成・配信が間に合わないことは明らかです。

近年では、この迅速性の課題を補うため、24時間体制のWAF運用代行サービスなども登場しています。セキュリティ専門家が常時監視し、新たな脅威に対してシグネチャを迅速に適用するというサービスです。しかし、その運用体制がどれほど迅速であっても、そもそもシグネチャが未定義のゼロデイ攻撃や、既存のシグネチャをわずかに変形させた亜種の攻撃に対しては、シグネチャ型のWAFは本質的に対応できません。

ゼロデイの脆弱性が潜んでいて、脆弱性が8ヶ月以上も公開されないまま攻撃が続いていたケースでは、どれだけ優秀な運用チームを揃えても、シグネチャベースの防御では検知すらできなかったのです。

既知から未知へ:脅威検知技術の進化

Webアプリケーション保護における「未知の脅威」への対応は、実はマルウェア検知の世界が先に歩んできた道でもあります。その歴史を振り返ることで、WAFの進化の方向性が見えてきます。

第1世代:シグネチャベース検知

1986年のブレインウイルス出現以降、アンチウイルスソフトは主にシグネチャ(パターンマッチング)方式で検知を行ってきました。既知のマルウェアからハッシュ値や特徴的なバイト列を抽出し、それと一致するファイルを検出する手法です。

この方式はシンプルで誤検知が少ない反面、定義ファイルに登録されていない「未知のマルウェア」は検出できません。

第2世代:ヒューリスティック検知

次に登場したのが、プログラムの動作パターンを分析してマルウェアか否かを判別する「ヒューリスティック検知」です。例えば、「システム領域を書き換える」「大量のファイルを暗号化する」といった、通常のプログラムでは行わない動作を検出します。

この方式により、シグネチャに登録されていない新種のマルウェアでも、その「振る舞い」から検出できるようになりました。ただし、誤検知が発生しやすく、また悪意ある動作が実行されるまで検知できないという課題がありました。

第3世代:機械学習による予測検知

現在主流となっているのが、機械学習を活用した検知手法です。膨大な量のマルウェアと正常なソフトウェアを学習データとして、それぞれの特徴(インディケーター)を自動抽出します。

教師あり学習では、「これはマルウェア」「これは正常」というラベル付きデータから、分類のための特徴を学習します。特にディープラーニング(深層学習)の登場により、人間が定義した特徴点に依存せず、AIが自ら特徴を発見する「汎化性能」が飛躍的に向上しました。これにより、過去に見たことのない新種のマルウェアでも、既知のマルウェアとの類似性から検出できるようになっています。

Webアプリケーション保護にAIを活用 (AI for Security)

マルウェア検知で培われた機械学習技術は、Webアプリケーション保護の領域にも応用できます。膨大な悪意あるリクエストと正常なリクエストを学習させることで、シグネチャに頼らずとも未知の攻撃パターンを検出できるようになります。

Webアプリケーションに対する攻撃手法は、「OWASP Top 10」として体系化されています。SQLインジェクション、クロスサイトスクリプティング(XSS)、認証の不備、セキュリティの設定ミスなど、これらの脅威は長年にわたりWebアプリケーションを脅かし続けています。従来のシグネチャ型WAFはこれらの既知の攻撃パターンには対応できますが、新たな亜種や未知の攻撃手法には後手に回らざるを得ません。AIを活用した防御は、この課題を根本から解決しようとするアプローチです。

Webトラフィック判定の難しさ

ただし、Webアプリケーション保護には、マルウェア検知とは異なる固有の課題があります。それは、「悪意あるリクエストか、正常なトラフィックか」の判断が非常に難しいという点です。

マルウェア検知では、「このファイルは悪意があるか否か」という比較的明確な二択で判定できます。しかしWebトラフィックでは、検索エンジンのクローラーのような正規のボット、APIを利用した自動化ツール、シングルページアプリケーションからの複雑なリクエストなど、一見すると異常に見えても正当なアクセスが数多く存在します。

単純に「通常と異なるパターン」を検出するだけでは、過検知(正常なアクセスを攻撃と誤判定)が多発し、ビジネスに支障をきたします。逆に、過検知を恐れて検知感度を下げれば、攻撃を見逃すリスクが高まります。この「セキュリティ品質」と「検出精度」のバランスが、Webアプリケーション保護における機械学習実装の最大の課題です。

2つのAIモデルによるアプローチ

この課題に対するひとつの解決策が、機械学習と教師なし学習を組み合わせたアプローチです。

機械学習モデルでは、何百万もの悪意あるリクエストと正常なリクエストを事前に学習し、攻撃の「インディケーター」(指標)を抽出します。例えばCloudGuard WAFでは、8,500以上のインディケーターを用いてリクエストのマッピングを行い、SQLインジェクション、クロスサイトスクリプティング、コマンドインジェクションなど、様々な攻撃パターンに共通する特徴を捉えます。これにより、シグネチャに登録されていない新しい攻撃手法でも検出が可能になります。

教師なし学習モデルは、保護対象の環境でリアルタイムに学習を行います。サイト特有のトラフィックパターンを継続的に学習してスコアリングし、そこから逸脱するリクエストを異常として検出します。これにより、環境ごとに異なる「正常」の定義に適応し、過検知を大幅に低減できます。

AIWAF.png

この2つのモデルを組み合わせることで、「既知の攻撃パターンとの類似性」と「その環境における異常性」の両面から判定を行い、高い検出精度と低い誤検知率の両立を目指します。実際、2024年12月に公開された比較テストでは、業界トップの精度を達成し、またLog4Shell、Spring4Shell、Text4Shellといった過去の重大なゼロデイ脆弱性に対して、シグネチャ更新なしで先制的な防御を実現した実績があります。

これからのWebトラフィックとセキュリティ

Webアプリケーションを取り巻く環境は、今後さらに複雑化していきます。

APIトラフィックの増加

SaaSやモバイルアプリケーションの普及に伴い、自動化のためのボットやAPIトラフィックが急増しています。従来の「人間がブラウザでWebページを閲覧する」モデルから、「プログラムがAPIを呼び出してデータを取得・操作する」モデルへとシフトしています。これに伴い、APIを標的とした攻撃も増加しており、API専用のセキュリティ対策が必要になってきています。

AIエージェントとMCPプロトコル

2025年に入り、AIエージェントと外部システムを接続するための標準プロトコル「MCP(Model Context Protocol)」が急速に普及しています。OpenAIやGoogleなどの主要ベンダーが自社製品にMCPを実装し、AIエージェントがファイルシステム、データベース、外部APIなどと連携できるようになりました。

しかし、この利便性は新たなセキュリティリスクをもたらしています。2025年5月にはAWSの名称を使ったMCPサーバーにコマンドインジェクション脆弱性(CVE-2025-5277)が報告されるなど、MCPサーバー実装の43%に基本的な脆弱性が存在するとの調査報告もあります。

MCPサーバーを介した攻撃では、プロンプトインジェクションにより、AIエージェントに意図しない操作を実行させたり、機密情報を外部に送信させたりすることが可能です。これは従来のWebアプリケーション攻撃とは異なる、新しい脅威カテゴリです。

変化するWebトラフィックへの備え

こうした変化を踏まえると、Webアプリケーションの保護も従来の発想だけでは追いつかなくなってきています。シグネチャに頼らないゼロデイ対策はもちろん、REST、GraphQL、gRPCといった多様なAPIプロトコルへの対応、正規ボットと悪意あるボットの見分け、そしてプロンプトインジェクションのような新しい攻撃手法への備えも視野に入れる必要があります。

同時に、過検知によってビジネスを止めてしまっては本末転倒です。高いセキュリティと低い誤検知率をいかに両立させるか。このバランスを取りながら、変化し続けるWebトラフィックに対応できる保護の仕組みを整えていくことが、これからの課題といえるでしょう。

おわりに

React2Shellや国内ISPの事件が示すように、ゼロデイ攻撃は「いつか起こるかもしれない脅威」ではなく、「今まさに起きている現実」です。特に国内ISPで発生した事例は、WAFの適用が不要と思われていた商用パッケージ製品にもゼロデイ脆弱性が潜む可能性を示しており、自社開発のアプリケーションだけでなく、Webインターフェースを持つあらゆるシステムが攻撃の標的となりえます。

さらに、AIエージェントやMCPの普及により、Webトラフィックの性質そのものが変化しつつあります。人間のブラウザアクセスだけでなく、AIエージェント同士の通信、プロンプトを含むリクエストなど、新しい形態のトラフィックに対応できる保護の仕組みを、今から準備しておくことが大切です。

自社のWebアプリケーションが「次のReact2Shell」の標的にならないために、今こそゼロデイおよびリアルタイム性を考慮したセキュリティ対策の見直しを検討してみてはいかがでしょうか。


参考情報

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?