文章目錄
最近看資安新聞，有一種才剛看懂上一件，下一件又來了的感覺。
PHP 漏洞、憑證出問題、套件被塞進惡意程式，接著是個資外洩、平台停止營運，月底還有交易所的大筆資產遭竊。我原本想挑幾件分別寫，整理到後來，都想說要不要乾脆等到爆到一個段落我再來寫？不然一直跟不上。
PHP 那次連日本首相高市早苗都發文提醒盡快修補，日本財務省也暫停部分網站內容與服務，進行檢查和更新。平常比較常看到的是「建議儘速更新」，這次卻是有些服務先停下來，等處理好再開。
攻擊者不一定需要先拿到你的密碼#
這次被稱為 PHP2Shell 的漏洞，出在 PHP 本身。攻擊者可能透過特製的 HTTP 請求，包括檔案上傳形式的請求，在受影響的環境裡讀取敏感記憶體，甚至讓伺服器執行攻擊者的程式，不必先登入網站。不過，要把漏洞組合成能成功利用的攻擊，仍然需要不少技術與測試，不是隨便送個請求就一定能打進去。
不過也就是說，不一定要有人誤點附件、洩漏密碼，或網站自己寫了一個很明顯的漏洞。伺服器只是照平常的方式接收網路請求，就可能碰上問題。
我平常主要寫 JavaScript，很容易覺得 PHP 已經離自己有點遠。但 WordPress、Drupal、Joomla，以及維基百科使用的 MediaWiki，背後都有 PHP。W3Techs 在十月下旬的統計顯示，在能辨識伺服器端語言的網站中，約 69% 使用 PHP。這不是說近七成網站都能被直接攻破，而是它底下承載的網站，真的比我平常感覺到的多。
PHP 在 10 月 21 日發布修補。同一天，GitLab 也發布緊急安全更新，其中一項漏洞可能讓未登入的攻擊者在受影響的自架 GitLab 上執行程式碼。從網站執行環境，到存放程式碼與執行 CI/CD 的平台，都得確認。
「我們不是用 PHP」可以排除一個問題，但還不能讓人鬆一口氣。
有些問題，出在我們原本信任的地方#
十月另一件讓我印象很深的事，是 eMudhra 的憑證事件。
Mozilla 公告，八張中繼憑證所對應的私鑰遭到破解。這些金鑰可能被用來簽出假冒的 HTTPS 憑證；如果攻擊者還能攔截連線，就可能冒充網站、讀取或修改流量。Mozilla 因此緊急透過憑證撤銷機制封鎖它們，Google 也採取了封鎖與移除信任的措施。
網站有 HTTPS，平常是我們很基本的要求。我原本是還蠻相信這套機制的，很多功能也是假設在 HTTPS 都正常運作的情況下，現在可能都要重新考慮他的安全性了。
LiteLLM 則讓我想到另一種很熟悉的信任：更新套件。
10 月 21 日，它的發布流程遭到入侵，惡意的 1.107.0 版本被送上 PyPI 和容器映像倉庫，包含竊取憑證等惡意功能。官方公告甚至指出，GitHub 上對應的原始碼標籤並沒有那些惡意檔案，遭污染的是發布出去的成品。
看完這兩件事，我比較難再把部署想成「程式打包完，傳上去就好」。中間經過的每一個服務、帳號與自動化流程，都在替最後那份程式背書。
網站沒有壞，損失也可能已經發生#
台灣的 91APP 事件，又把這件事拉得很近。
依照 10 月 29 日公布的調查，攻擊者經由第三方工具進入內網，再入侵訂單資料庫。公司以最大可能影響範圍通知，涵蓋 1,329 家品牌、約 479.8 萬名消費者；這不代表每個人的資料都已遭竊取。
對消費者來說，這不只是資料庫裡幾筆紀錄被別人複製出去。姓名、電話、地址和買過什麼，可能讓後續詐騙變得更像真的。網站恢復正常，也不會讓已經被複製出去的資料自動消失。坦白說我自己在9月就收到詐騙email了，我很確定那是詐騙，因為他拿的訂單是我5月的，要我解除分期付款甚麼的，但是準確的訂單資料還是讓我疑惑了一下才判斷是資料被偷。
月底的幣安事件，損失則直接反映在資產上。依照 11 月 3 日的初步報告，約 63.4 億美元的數位資產受到影響。讓我特別注意的是，公司表示，暫停提款仍不足以阻止所有未授權轉移，因為攻擊者建立的部分鏈上授權，獨立於一般提款流程之外。
原來「先關掉」也得知道要關哪裡。介面停了、某個服務停了，不代表已經發出去的權限跟著失效。
Zeabur 則是另一種後果。兩次資安事件後，團隊重新評估維運投入與責任，宣布逐步結束平台營運。使用者除了處理事件影響，還要搬服務、備份資料，重新安排原本已經運作的專案。
這幾件事原因不同，但都讓我覺得，服務出事之後，真正麻煩的部分常常才要開始。
AI 讓我在意的，是它把中間的工作加快了多少#
這個月很容易看到「AI 攻擊」幾個字。但我不太想把所有事件都丟進同一個解釋裡，好像加上 AI，就能說明為什麼會出事。
比較具體的例子是 PHP。
PHP Foundation 說明，部分問題的跡象早在 2024 年就已被發現，但當時沒有找到明確的利用路徑，修補也牽涉相容性、效能與資源不足等困難。後來的研究才讓完整影響變得清楚。
Wiz 的研究則描述，AI 協助研究者串接漏洞、反覆測試，並把攻擊方式調整到不同應用上。這裡值得注意的，是原本很複雜、需要大量研究的工作，變得更容易完成。
我自己的判斷是，這會讓一些「理論上有問題，但應該很難利用」的假設，越來越不可靠。
研究者能更快證明漏洞，攻擊者也可能更快準備利用方式。但公司這邊，還是得找出誰負責、確認系統用了什麼、安排測試、取得更新權限，再把服務重啟。
但中間一定還是會有速度差。
寫程式的工具一直在加速，處理事故的流程卻未必跟著變快。有時候甚至只是要確認一台舊主機歸誰管，就先花掉半天。
我自己的感想#
我還是喜歡方便的部署工具。能少處理一些伺服器設定，早點把想做的東西放上線，對小專案來說很有吸引力。
但這個十月過後，我會想在部署成功之外，多確認幾件很普通的事：
- 出現漏洞時，我能不能很快知道自己有沒有用到？
- 如果要緊急更新，我知道怎麼做，也有辦法確認它成功了嗎？
- 金鑰或權限出了問題，我能不能撤銷，而不只是把程式退回上一版？
尤其最後一點，我的小工具網站都沒有產值，也沒有敏感資料，但是 token 被盜用，服務費用爆增，就真的談得上損失了，而且最近才看到有人就是發生這樣的事情，還是會擔心發生在自己身上。