この記事の途中に、以下の記事の引用を含んでいます。
Android ‘Pixnapping’ attack can capture app data like 2FA codes
古い攻撃が最新Androidで蘇る!?「Pixnapping」攻撃とは
本記事では、Android端末を脅かす新たなセキュリティリスク「Pixnapping」攻撃の仕組みと、その深刻さ、そして今後私たちが意識すべき点について掘り下げます。
このPixnappingは、実は12年前にWebブラウザ向けに発表されていた「ピクセル盗み(ピクセルスティーリング)攻撃」の現代版と言えるものです。
なんと、2要素認証（2FA）のコードすら漏洩させうるということで、多くのAndroidユーザーや開発者に警鐘を鳴らす内容となっています。
「ピクセル盗み」がAndroidで再登場！具体的な手法と脅威レベル
まずPixnapping攻撃の主張部分を、記事からの引用を交えて紹介します。
“It allows a malicious Android application to access and leak information displayed in other Android apps or on websites. It can, for example, steal data displayed in apps like Google Maps, Signal, and Venmo, as well as from websites like Gmail (mail.google.com). It can even steal 2FA codes from Google Authenticator.“
「悪意のあるAndroidアプリが、他のAndroidアプリやウェブサイトに表示されている情報へアクセスし流出させることができる。たとえばGoogle MapsやSignal、Venmoのようなアプリ、さらにはGmailのようなウェブサイト上のデータも盗める。さらに、Google Authenticatorの2FAコードですら盗める。」
また、その技術的な仕組みについては、
“The attack works by accessing information about screen display pixels through a hardware side channel (GPU.zip), using a technique […] inspired by security researcher Paul Stone in 2013.”
と記されています。
つまり、GPU（グラフィックプロセッサ）のハードウェア的なスキマ（サイドチャネル）を突くという、従来のソフトウェア的な対策では防ぎづらい攻撃である――ということです。
サイドチャネル攻撃の怖さ：なぜソフトウェア更新だけでは防げないのか
ここで重要なのは、PixnappingがOSやアプリの機能的な穴だけでなく、「ハードウェア由来の副次的な情報漏えい」――すなわちサイドチャネルによる攻撃である点です。
サイドチャネル攻撃とは、コンピュータの本来意図しない「副産物」を利用して情報を盗む手法のこと。
たとえば消費電力・電磁波・アクセス時間・キャッシュの動きなどがそうです。
このPixnappingにおいては、
- Mali GPUの「データ依存圧縮」（GPU.zip）がピクセルごとに可変の処理時間を生む
- 不正アプリが「ぼかしAPI（blur API）」や「VSyncコールバック」などの仕組みを悪用し、その「遅延時間」から画素（ピクセル）単位で画面の色情報を予測
- 一字ずつ画素を解析し、例えばGoogle Authenticatorの2FAコードなどの「目に見える」情報までも復元
といったメカニズムが利用されます。
実はこうしたサイドチャネル攻撃の多くは、OSレベルやアプリごとの通常のアクセス権管理だけでは防げません。
なぜなら、それらは公式のAPIやグラフィック処理の「設計上の挙動」であり、外部から隠したつもりでも根本的に情報が漏れ続けてしまう可能性があるからです。
実証内容から見える本当の脅威：特権も不要、最新端末も対象
著者らの論文発表に基づくと、「Google Pixel 6, 7, 8, 9, Samsung Galaxy S25」など最新世代のAndroid端末で実際に攻撃が成立したとされています。
しかも…
“A malicious Android app implementing Pixnapping would not require any special permissions in its manifest file, the authors say.“
「Pixnappingを実装した不正アプリは、manifestファイルに特別なパーミッション（権限）を一切要求しない。」
これはつまり、従来のような「怪しいアプリには許可を与えない」だけでは、まったく防げないという意味です。
セキュリティの「常道」であるパーミッション制御の意義を根本から覆す事例と言えるでしょう。
さらに、2FAコードの漏洩速度は
“it only leaks 0.6 to 2.1 pixels per second, though the authors say that’s sufficient to recover Google Authenticator codes.“
「1秒あたり0.6〜2.1ピクセルと、漏えい速度は遅いが、それでもGoogle Authenticatorのコード復元には十分」
と評価されています。
攻撃に数十秒かかるとはいえ、目立たず静かに実行されれば十分に危険です。
Google対策は間に合うのか？そして、穴は塞げるか
今回の脆弱性CVEsはすでに管理されています（CVE-2025-48561）。
そしてGoogleも「9月と12月のAndroidセキュリティ・アップデートでパッチを配布する」と述べています。
しかし実態は…
“Google has tried to patch Pixnapping by limiting the number of blur API calls that an Android Activity is allowed to invoke. They note, however, that they discovered a workaround, presently still under embargo.“
「ぼかしAPIの呼び出し回数に制限を設けたが、執筆時点で既に迂回する手口が確認されている（詳細非公開）」
つまり、単純な部分修正ではザルであり、根本的な設計見直しが必要ということです。
また、記事の末尾には
“As for the GPU.zip side channel used by the Pixnapping framework, no vendors have announced plans to address it.“
「Pixnappingで利用されるGPU.zipサイドチャネルについて、どのメーカーも対策計画を発表していない」
と記載されており、設計そのものに手を加えない限り、完全な解決は極めて難しいことを示唆しています。
私たちにできる現実的な対策と、考えるべきリスク管理の軸
ここまで技術的な内容を中心に追ってきましたが、一般ユーザーや開発者にとって「では、どうすれば？」という部分を整理します。
一般ユーザーへのアドバイス
- 定期的な端末アップデート（Androidのセキュリティパッチ）は必須
- ただし、「最新にしたから絶対安心」とは現時点で断言できません
- アプリのインストール時、「無名、評価ゼロ、シンプルすぎる用途で広告多め」な物をなるべく避ける
- もし可能ならば、1端末1用途（2FA生成端末と常用端末を分離）といった物理的対策も有効
- より高い安全性が必要な場面では、「物理セキュリティキー(Yubikey等)」利用へ移行する
開発者・管理者側の留意点
- UI描画情報に依存した認証要素（表示2FAコード等）を不用意に一般アプリと同スレッドで展開しない工夫
- サイドチャネル耐性のある設計（たとえばランダムダミー描画、時間的揺らぎを導入する等）を検討
- OSSなどのセキュリティ・アップデート情報に迅速に目を通し、端末依存挙動も調べる
今回の件は、特に「ハードウェア由来の情報漏えい」の深刻さを再認識させました。
2018年の「Spectre/Meltdown」問題の時のように、根本からの設計変更を迫られる可能性も十分にあります。
結論：「画面を“見る”だけでは守れない」──ピクセルの裏に潜むセキュリティリスク
Pixnapping攻撃の最大の本質は、「OSやアプリの設計上、権限外からも画面情報が漏れる」という、従来の防御理論が通用しない新たな脅威です。
この記事で取り上げられた事例が、必ずしも今すぐすべてのAndroid端末に対して現実的な攻撃として広まるわけではありません。
しかし、これまで「不可視」とされてきたピクセル情報すら、工夫次第で盗まれうることが実証されたインパクトは大きいです。
今後は、アプリ権限や画面遷移だけでなく、「ハードウェア・アーキテクチャそのもの」に着目したセキュリティ設計が強く求められるでしょう。
私たちができる対策は限られるものの、アップデート習慣・アプリ選定の慎重さ・最新のセキュリティ動向へのアンテナ強化は不可欠です。
ピクセルの「色」だけで、そこに秘密が隠されていないか――
そんな先端的なサイバーリスクを念頭に置くこと。
それが、これからの時代を生きるITユーザー・開発者双方に求められる“当たり前”なのかもしれません。
categories:[security]
コメント