攻撃者は AI でアプリを解析 — 「中身は見られる」前提の守り方

攻撃者は AI に何をさせていたの?

JPCERT/CC は 10 月 8 日、国内で相次いだ不正アクセスと個人情報の漏えいについて注意を呼びかけました。続く 10 月 15 日には、攻撃元のサーバーを調べた結果を公表しています。

報告によると、攻撃者は AI を使い、すでに知られている弱点の洗い出しや、API を通じた攻撃をしていました。サーバーには Android アプリの配布ファイル(APK)が複数ありました。アプリの中身を調べる解析ツールの関連ファイルも見つかっています。

攻撃者は、アプリから分かった API に対し、サーバーに外部への通信を代わりにさせる手口(SSRF)が通じないかを調べていました。日本以外の地域向けのサービスも標的になっていたとしています。

どの AI が使われたかは公表されていません。一部は「考えられる」という推定の表現です。katsuno 氏の投稿はこの点を明記しており、読み手が話を大きく受け取らずに済みます。なお、JPCERT/CC が確認したのは調べた攻撃元サーバーでの AI の利用までで、個々の漏えい事案の侵入経路と結び付けたものではありません。

「AI らしい」攻撃は、どう見えたの?

投稿が並べて紹介したのが、サイバーセキュリティクラウドの 10 月 9 日の報告です。9 月 18 日から 10 月 8 日の通信を調べ、約 40 分に 1,200 件を超えるアクセスを複数回確認しました。接続元の住所にあたる IP アドレスは、326 個を使い分けていました。

動きにも特徴がありました。まず不正な命令文で認証をすり抜けられないか試し、駄目なら事前に作ったアカウントでログインします。ポイント制度のあるサイトでは、他人のポイントを盗めないか探っていました。

一通り試すと深追いせずに引き上げ、応答を見ながら手口を変えていました。同社は AI エージェントかそれに近い仕組みの可能性があるとしつつ、「AI の利用を直接示す痕跡を確認したものではありません」と書いています。

AI が関わる経路は 1 つではない?

投稿は、AI が漏えいに関わる仕組みを 3 つに分けています。攻撃側の高速化、従業員が AI に個人情報を入れること、AI をだます指示(プロンプトインジェクション)です。この整理は、打ち手を考えるときにそのまま使えます。

2 つ目の例が、協会けんぽ兵庫支部の 9 月 30 日の公表です。特定保健指導を委託した事業者で、作業者が個人情報を含むデータを、許可されていない個人用の生成 AI にアップロードしました。データは直後に削除され、被害は確認されていません。

委託先は再発防止策として、許可のない生成 AI の業務利用禁止の徹底を挙げました。AI の管理体制について、外部の認証を取ることも掲げています。

被害はなぜ取引先にまで広がるの?

投稿のもう 1 つの鋭い指摘は、委託先のシステムを通じて被害が広がる構図です。佐川急便の問い合わせサービスへの不正アクセスでは、横須賀市などが情報流出のおそれを公表しました。

スカラコミュニケーションズの、よくある質問を載せるシステム「i-ask」では、同じサーバーにある利用企業のデータベースが狙われました。対象は最大 5 社、最大 71 万 3,126 件です。大和証券やシチズン時計などが影響を公表しています。

件数の読み方にも、投稿は気を配っています。ブックオフの最大約 643 万件は会員番号の件数で、人数ではありません。タイムズカーでは、退会した人を含む約 660 万件のアカウント情報が取得されました。GMO リサーチ&AI の「infoQ」では、611 件、286 万 9,500 円相当のポイントがギフトコードに不正に交換されています。

「解析されても壊れない作り」とは何?

投稿は、アプリの解析そのものは止められないとして、「解析されても壊れない作り」と「悪用の段階で気づく仕組み」を守りの柱に挙げました。JPCERT/CC の推奨とも方向が合います。

JPCERT/CC が挙げる対策は 4 つです。API の認証に使う秘密の鍵や、長く有効な認証情報をアプリに埋め込まないこと。アプリ側の工夫に頼らず、サーバー側で本人確認と権限の確認をすること。回数の制限と、異常な通信の監視。外部の宛先を取りに行く API では、行き先を制限することです。

NICT も 10 月 13 日、同じ型の攻撃に注意を呼びかけました。公開したアプリは解析される前提で設計し、裏側のサーバーの安全を確保することが大切だとしています。

SYNCON の視点 — 日本の非エンジニア経営層は何を盗むべきか

盗むべきは、katsuno 氏の「確認済みと推定を分ける」姿勢です。AI の攻撃と聞くと、新しい防御製品を探したくなります。しかし公的機関が勧めるのは、秘密をアプリに置かない、サーバー側で本人を確かめる、回数を制限するという基本です。AI が変えたのは、その基本の抜けが見つかる速さです。

月曜からできることは 3 つあります。1 つ目は、アプリや会員サイトの開発会社に「アプリに秘密の鍵を入れていないか」「サーバー側で権限を確かめているか」を尋ねることです。2 つ目は、退会者の情報を持ち続ける理由を見直すこと。3 つ目は、委託先も含めて業務で使ってよい生成 AI を決め、契約に書くことです。

要点まとめ

• JPCERT/CC は 10 月 15 日、攻撃元のサーバーで、攻撃者が AI を使っていたことを確認したと公表しました。どの AI かは未公表です
• 手口は、アプリを分解して API を見つけ、弱点を突くものです。アプリの中の秘密は守りになりません
• 約 40 分に 1,200 件を超えるアクセスという観測もあります。ただし AI の直接の痕跡ではないと明記されています
• 委託先の作業者が個人用の生成 AI に個人情報を入れる事故も起きています。使ってよい AI を決めるのは経営の仕事です
• 守りの基本は、秘密をアプリに置かない、サーバー側で本人と権限を確かめる、回数を制限して監視することです