Uhale系Androidフォトフレームが起動時にマルウェア取得 - SecureShield セキュリティニュースまとめ

Source:https://www.bleepingcomputer.com/news/security/popular-android-based-photo-frames-download-malware-on-boot/

🛡 概要

複数ブランドで流通するUhale系のAndroid搭載デジタルフォトフレームに、起動時に外部から不正コードを取得・実行する挙動を含む重大な脆弱性群が確認されています。モバイルセキュリティ企業Quokkaの調査では、中国にホスティングされたサーバからUhaleアプリ版4.2.0へ自動更新後、JAR/DEXをダウンロードし、以後の起動毎に動的ロードして実行する実装が観測されました。ダウンロードされた不正ペイロードはVo1dボットネットやMezmess系マルウェアと一致する痕跡があり、端末出荷時からSELinux無効・root化・AOSP test-keys署名など防御が解除された状態の個体も存在します。ベンダであるZEASN（現Whale TV）への通知に対する回答は公開時点で未確認とされています。

🔍 技術詳細

調査端末ではブート時にUhaleフレームがアップデートを確認し、新版（4.2.0）に更新・再起動後、アプリがJAR/DEXをアプリ領域へ保存し、以後の起動時にClassLoaderで動的読み込みして実行します。ダウンロード元は中国拠点のサーバで、パッケージ接頭辞、文字列、エンドポイント、配布ワークフロー、アーティファクト配置がVo1dおよびMezmess系と一致しています。一部機種はSELinux無効化、出荷時root、AOSP test-keys署名で、システム整合性が崩壊していました。更新処理ではファイル名を無検証でシェルに渡すためコマンドインジェクションが可能、WebViewはTLSエラー無視と混在コンテンツ許可で中間者攻撃やコンテンツ改ざんに脆弱、さらにTCPポート17802のファイルサーバが無認証で書込・削除を許可する実装が確認されています。sdkbin応答の復号にハードコードされたAES鍵DE252F9AC7624D723212E7E70972134Dが用いられており、複数モデルにAdups系アップデータや古いライブラリが含まれるなどサプライチェーンのリスクも指摘されています。

CVE-2025-58392 / CVE-2025-58397: 不適切なTrustManagerによりMITMで偽応答を受容、root権限でのRCEに至る恐れ（CVSS: 未公表）
CVE-2025-58388: アップデート処理のファイル名未サニタイズに起因するコマンドインジェクションで任意APKの遠隔導入（CVSS: 未公表）
CVE-2025-58394: 出荷時SELinux無効・root化・AOSP test-keys運用により初期状態で完全妥協（CVSS: 未公表）
CVE-2025-58396: 事前インストールアプリがポート17802で無認証ファイルサーバを公開し、ローカルネットから任意ファイルの書込/削除が可能（CVSS: 未公表）
CVE-2025-58390: WebViewがSSL/TLSエラーを無視し混在コンテンツ許可、表示データの介入・なりすましが可能（CVSS: 未公表）

なお、個々の端末がどの経路で初期感染（もしくは不正コード受領）に至ったかは未解明の点が残りますが、設計上の脆弱性が複合しリモートから持続的なコード実行が成立していることが問題の本質です。

⚠ 影響

企業ネットワークへ接続されたフォトフレームがボットネットに取り込まれると、DDoS加担、プロキシ悪用、内部スキャン、SMBや他IoTへの横展開の踏み台化が現実的です。ローカル無認証のファイルサーバ悪用により同一セグメントから設定やファイルが改ざんされる恐れがあり、MITM誘発の更新経路からはroot権限RCEが成立します。混在コンテンツ許可のWebViewはフィッシング・偽表示の温床となります。ブランドの多層OEM流通とアプリ配布規模（Google Play 50万+DL）はばく大な曝露につながります。

🛠 対策

短期: 当該機器を社内本番ネットから直ちに隔離し、来客/IoT用VLANへ収容。送信先制御で未知/高リスクASNへのHTTP/HTTPS通信を遮断し、ポート17802の入出力をフィルタ。
更新抑止: Uhaleアプリの自動更新・自己更新を無効化できない場合、機器の電源断・撤去を検討。ファームウェアの公式修正が出るまで運用を停止。
調達統制: 正規Androidイメージ、Google Playサービス、SELinux有効、鍵管理の適切なメーカーに限定。AOSP test-keys署名機器は調達禁止。
監視: DNS/HTTPでのJAR/DEX取得、未知CN/SNI、TLSエラー頻発をNDR/Firewallで検知。新規機器のDHCP指紋で自動隔離。
ハードニング: NACでMAC/OUIベースのプロファイル割当、東西トラフィック最小化、egress allowlistを実装。

📌 SOC視点

ネットワーク: ポート17802宛/発のトラフィック検知、HTTPでの.jar/.dex/.apk取得、User-AgentやHostの不審組合せ、TLSハンドシェイクで頻発する証明書検証失敗の可視化。
エンドポイント/MDM: 当該IoTはEDR非対応のため、MDM/EMMで同名パッケージのインストール検出（可能な場合）。Logcat取得ができる環境ではPackageManagerのsilent installイベント、BOOT_COMPLETEDレシーバ登録、DexClassLoaderのロード痕跡を確認。
脅威インテリジェンス: Vo1d/Mesmess関連IOCs（ドメイン、IP、パス、パッケージ接頭辞）を反映。TLS検証無効や混在コンテンツを示すHTTPヘッダ/レスポンスパターンをシグネチャ化。

📈 MITRE ATT&CK

T1195.002 供給網侵害（ソフトウェア供給網の妥協/Enterprise）: 出荷時root化・test-keys・サードパーティ更新基盤に依存する設計。
T1407 実行時の新規コード取得（Mobile）: 起動後にJAR/DEXを取得し動的ロード。
T1557 中間者（Enterprise）: 不安全なTrustManagerやTLS無視によりMITMで偽応答注入。
T1059.004 コマンド/スクリプト（Unixシェル）（Enterprise）: 未サニタイズ引数によりシェル経由で任意コマンド・APK導入。
T1210 リモートサービスの悪用（Enterprise）: 無認証のファイルサーバ（TCP 17802）を悪用しファイル操作。
T1547 ブート/ログオン自動実行（Enterprise, 類推）: BOOT_COMPLETED等で持続化（Androidではアプリの受信機と自動起動に相当）。

上記は観測された実装・挙動に基づく対応付けです。

🏢 組織規模別助言

小規模（〜50名）: 当該機器を社内LANに置かず、来客用Wi-Fiのみで運用。UTMのURLフィルタで未知国向け通信を遮断し、月次で機器一覧を棚卸。
中規模（50〜500名）: IoT/OT用セグメントを分離し、NACで自動収容。Firewallでegress allowlist、DNSセキュリティを導入。購買ワークフローにセキュリティ適合チェックリストを追加。
大規模（500名〜）: ゼロトラストセグメンテーション、NDR/UEBAで振る舞い検知、供給網リスク管理（ベンダセキュリティ審査、SBoM要求）を制度化。影響評価に基づく一斉リコール/隔離計画を準備。