ASOS／官方：App 推送遭黑客騎劫變勒索信——第三方客戶通訊平台遭未授權存取，姓名及聯絡資料或外洩；稱信用卡及密碼未受影響，股價盤中挫逾一成

Key takeaway

英國網購時裝零售商 ASOS 於十月六日向倫敦證券交易所發出公告，確認當日英國時間約上午十時（香港時間約下午五時），有未經授權的通知經其 App 推送予客戶；公司正調查涉及「用作與客戶溝通的第三方平台」的未授權活動，並已即時限制通知平台的存取權限。ASOS 表示客戶姓名及聯絡資料等基本個人資料或已被存取，但相信信用卡資料及帳戶密碼未受影響，網站及 App 運作如常。

ASOS／官方：App 推送遭黑客騎劫變勒索信——第三方客戶通訊平台遭未授權存取，姓名及聯絡資料或外洩；稱信用卡及密碼未受影響，股價盤中挫逾一成

英國網購時裝零售商 ASOS 於十月六日向倫敦證券交易所發出公告，確認當日英國時間約上午十時（香港時間約下午五時），有未經授權的通知經其 App 推送予客戶；公司正調查涉及「用作與客戶溝通的第三方平台」的未授權活動，並已即時限制通知平台的存取權限。ASOS 表示客戶姓名及聯絡資料等基本個人資料或已被存取，但相信信用卡資料及帳戶密碼未受影響，網站及 App 運作如常。

推送內容直指 ASOS 的資料保障主任及 IT 團隊，聲稱已「完全攻陷 Snowflake 實例」並揚言不回應便會洩露資料，附上一個當日才開設的 Telegram 頻道連結。Snowflake 遭入侵之說暫未獲證實；ASOS 股價當日盤中一度急挫逾一成。事件顯示，品牌自家推送渠道一旦被騎劫，便可即時變成面向全體用戶的勒索告示。

ASOS／官方：App 推送遭黑客騎劫變勒索信——第三方客戶通訊平台遭未授權存取，姓名及聯絡資料或外洩；稱信用卡及密碼未受影響，股價盤中挫逾一成

本文以 ASOS 向倫敦證券交易所發出的監管公告（RNS 編號 8604X）為主要來源，並對照 BBC、The Register、Malwarebytes 及 FashionNetwork 的同日報道；來源真實性已驗證。以下整理事件經過、推送系統被濫用的技術原理，以及香港企業可以即時檢查的地方。

一、核心事件：自家 App 推送成了勒索告示

時間線與官方說法

  • 英國時間十月六日約上午十時：大批英國 ASOS App 用戶收到一則彈出通知，內容為「Dear ASOS DPO and IT, we have fully compromised the Snowflake instance. Engage with us, or we will leak it」，並附 Telegram 頻道連結。據 BBC 報道，發訊組織自稱「Xuanye Group」，其 Telegram 頻道當日才開設，只發過三則帖子。
  • 同日下午：ASOS 發出題為「Update regarding cyber incident」的監管公告，確認曾有未經授權的客戶通知發出，重點如下：
    • 正調查涉及其用作與客戶溝通的第三方平台的未授權活動；
    • 已即時限制通知平台的存取，並與內部及外部專家顧問以及所有相關當局合作；
    • 姓名及聯絡資料等基本個人資料或已被存取；
    • 不相信信用卡資料或帳戶密碼受影響；
    • 網站及 App 運作如常，營運未受干擾；
    • 公司持有大型環球保險商承保的網絡保安保險（包括業務持續保險），但現階段言之尚早，未能量化對營業的潛在影響。

尚未證實的部分

黑客聲稱攻陷的 Snowflake 是雲端數據平台，不少企業用來集中儲存和分析客戶數據。The Register 指出，單憑該則通知並不足以證明發訊者真的進入了 ASOS 的 Snowflake 環境或取得敏感客戶資料，該媒體已向 ASOS 及 Snowflake 查詢。截至本文發稿，ASOS 公告並無提及 Snowflake。

市場反應方面，The Register 及 MarketWatch 報道 ASOS 股價當日跌約一成至一成二，FashionNetwork 則指盤中最多曾跌逾百分之十四。

二、技術原理：為何「發推送」與「偷數據」是兩道不同的門

推送通知的典型鏈路

一間大型零售商的 App 推送，通常不是由工程師逐條發出，而是經以下鏈路：

  1. App 安裝時登記裝置推送憑證（Apple 的 APNs、Google 的 FCM），憑證會同步到企業的客戶數據系統；
  2. 客戶互動平台（Customer Engagement Platform） 按會員分群、購物紀錄觸發推送，例如「購物車提醒」「減價通知」；
  3. 數據倉庫／個人化引擎 提供分群名單及推薦結果，再回傳給互動平台；
  4. 互動平台以其持有的推送金鑰，經 APNs／FCM 把訊息送到用戶手機。

換言之，誰能登入互動平台的後台、或持有其可發送訊息的 API 金鑰，誰就能以品牌名義向全體用戶「廣播」。

專家怎樣解讀

資安公司 Horizon3 的 Dan Bird 向 BBC 表示，向 ASOS App 用戶發推送須取得公司的通知系統存取權，而該系統與黑客聲稱攻陷的 Snowflake 數據平台是分開的；如兩項說法都屬實，意味攻擊者取得的憑證可能「打開了不止一道門」。

Malwarebytes 則引述公開資料指，ASOS 曾被介紹為使用建基於 Snowflake 的個人化平台 Simon AI，並配合 Braze 觸發客戶通訊（包括推送）。需要強調：ASOS 公告只說「第三方平台」，並未點名涉事供應商，以上屬外界推斷。

與二零二四年 Snowflake 事件的對照

The Register 提到，二零二四年曾有一輪針對 Snowflake 客戶的大規模數據盜竊，受害者包括 Ticketmaster、Santander 及 AT&T 等；相關黑客其後承認入侵逾一百六十五個機構。當時事件的共同點是客戶帳戶未強制多重認證、憑證被盜後即可登入；Snowflake 之後推出可讓管理員強制要求多重認證的控制。今次 ASOS 事件是否同一手法，現時沒有官方證據。

三、日常應用場景：其他企業應檢查甚麼

1. 開發者與技術團隊

  • 推送金鑰最小權限：把「可發送訊息」的 API 金鑰與「只讀報表」金鑰分開；廣播級別的金鑰只放在伺服器端，限制來源 IP，並定期輪換。
  • 大規模廣播須雙人審批：針對全體或大分群的推送，加設審批流程及發送速率上限；異常時段、異常文案（例如包含外部 Telegram 連結）應自動攔截。
  • 一鍵停發開關：預先準備可即時撤銷推送憑證或暫停所有活動的程序，ASOS 今次公告提到「即時限制通知平台存取」，正是這類應變動作。

2. 企業與隱私敏感行業

  • SaaS 帳戶治理：行銷、客服、數據團隊使用的第三方雲端工具，往往未納入 IT 的單一登入及多重認證管理；離職員工、外判代理商帳戶亦常被遺漏。
  • 數據倉庫存取控制：為數據平台設定強制多重認證、網絡政策（只容許指定網段連線）及服務帳戶金鑰輪換，並監察大量匯出查詢。
  • 事故溝通預案：今次 ASOS 在推送發出後數小時內即發出監管公告，交代受影響資料類別及保險安排，有助穩定市場；上市公司應預先擬定類似範本。

3. 一般用戶

收到品牌 App 的異常通知，不要點擊內附連結；改以官方網站或 App 內設定查核，並留意之後冒充「事故跟進」的釣魚電郵或短訊。ASOS 指密碼未受影響，但若曾在其他網站重用同一密碼，仍建議一併更改。

4. 香港與亞洲市場視角

香港零售、銀行及電子錢包高度依賴 App 推送做推廣和交易提示。香港已推行「短訊發送人登記制」協助市民辨別真偽短訊，但 App 推送渠道的可信度，完全取決於企業自身及其第三方供應商的金鑰與帳戶管理。對香港企業而言，今次事件的教訓是：供應鏈中的行銷工具同樣屬於攻擊面，應納入風險評估、存取審計及事故演練；若涉及個人資料外洩，亦應按私隱專員公署的指引評估通報及通知受影響人士。

四、專業評價與潛在考量

優勢（ASOS 應對上值得參考之處）

  • 推送發出後同日即以監管公告確認事件，列明「可能受影響」與「相信未受影響」的資料類別；
  • 即時限制通知平台存取，阻止進一步濫發；
  • 主動交代保險及營運狀況，減少市場猜測。

需要留意的地方

  • 公告未說明涉事第三方平台、入侵途徑及受影響客戶人數；
  • 「姓名及聯絡資料或已被存取」意味用戶未來面對針對性釣魚的風險上升；
  • Snowflake 被攻陷的說法未證實，亦未排除；後續調查結果或會改變事件規模；
  • 推送渠道一旦失去用戶信任，關閉通知的用戶增加，會直接影響回購及推廣效益。

結語

ASOS 事件的特別之處，在於攻擊者沒有先私下勒索，而是直接用品牌自己的推送渠道向客戶「公開喊話」。這提醒所有擁有 App 的企業：推送平台、客戶數據倉庫和行銷 SaaS 都是核心系統的一部分，權限、金鑰及多重認證必須與主系統同一標準管理。後續值得留意 ASOS 會否公布調查結果及受影響人數，以及 Snowflake 方面的回應。

如需為香港企業檢視雲端帳戶、第三方 SaaS 權限及零信任存取架構，可參考 YSK Limited 的雲端遷移與網絡安全服務（https://ysk.hk/services/cloud-security）；如要重新設計 App 推送後台、加入審批流程及金鑰隔離，亦可了解香港 APP 開發服務（https://ysk.hk/services/app-development）。

參考來源

Related services & products

Related posts