Synology NAS 中招 C3RB3R:一年半的修補落差,2FA 擋不住的 .L0CK3D
十月二十八至二十九日,一批對外開放的 Synology NAS 在數小時內被同一支勒索程式加密,檔案尾碼換成 .L0CK3D,每個資料夾留下一封 read-me3.txt。社群在半天內貼出至少四篇求助,Synology 於二十九日發聲明。被指名的漏洞,並不是這一週大家都在講的那一個。
事件:C3RB3R 與 .L0CK3D
最早個案在十月初出現,360 反勒索團隊稱自十月起陸續接到求助,社群的大規模回報則集中在二十八至二十九日。加密程式常駐名稱被觀察為 libgld,逐檔以 ChaCha8 加密,金鑰用樣本內嵌的 RSA-2048 公鑰包裹;它跳過二十七個系統目錄以維持系統運作,一百八十七種副檔名採全檔加密,其餘按大小選擇性處理。
勒索信寫著六位裝置 ID,指向 Tor 自助站,允許免費試解密一個不大於 1,024 KB 的檔案。同一台機器上的 Hyper Backup 與 USB 備份,只要路徑可寫入,一併被加密。目前沒有公開的通用解密工具,No More Ransom 未收錄。

規模沒有可靠數字。Synology、Censys、Shodan、Shadowserver、Fofa 都沒有公布具方法論的裝置計數;任何「數千台」的說法都缺來源。行為者歸因同樣未確認,無廠商或政府機關指名,C3RB3R 這個家族名稱本身也有爭議。
入口之爭:三個說法
先排除一個流行但錯誤的名字。部分媒體把這次寫成 PHP2Shell(CVE-2026-109618/109619),但 Synology 二十九日的聲明指向 SA-24:20,360 指向 SA-26:13,兩者都不是 PHP2Shell;那是同期、獨立的 PHP 套件問題,與本波勒索沒有證實的關聯。
Synology 的說法最直接:攻擊者利用一個 2024 年 12 月已修補的漏洞,打的是跑舊版 DSM 的機器,即 CVE-2024-10441。若成立,這是被拖了一年半以上的修補落差。Tom’s Hardware 報導的單一 DS918+ 個案與此吻合:管理介面外露、約十八個月未更新,日誌指向同一個漏洞。
360 反勒索團隊不同意。它把入口指向 2026 年 9 月 18 日修補的 CVE-2026-13639 與 CVE-2026-13684,屬於典型的 1-day:公告出了,機器沒更新,攻擊在一週後到來。
Solar 應變團隊的現場記錄最難安置:一名受害者的 DSM 已是 7.4.1-90080 Update 1。他們沒有認定 DSM 本體存在 0day,只說不能排除新漏洞、套件、容器或憑證洩漏。三家講的可能是同一波攻擊裡的不同個案,也可能有一條還沒被看見的路徑。這一段,答案是「未能確定」。
兩個 9.8、兩次「無緩解」
兩份公告的形狀幾乎一樣。SA-24:20 於 2024 年 11 月 5 日發布,CVE-2024-10441 為 CVSS 9.8,官方緩解措施欄寫的是 None,只能更新:7.2.2-72806-1、7.2.1-69057-6、7.2-64570-4、7.1.1-42962-7、6.2.4-25556-8。
SA-26:13 於 2026 年 9 月 18 日發布,一次修八個漏洞,其中兩個同為 9.8,緩解措施同樣是 None,修復線為 7.4-90075、7.3.2-86009-4、7.2.2-72806-9、7.2.1-69057-12。共同點不是技術,而是時間:修補一直存在,差的只是有沒有人裝。

為何 2FA 也擋不住
兩個入口都在登入之前。CVE-2024-10441 是系統外掛服務的輸出編碼與轉義不當,未經驗證的遠端攻擊者即可執行指令;CVE-2026-13639 是登入邏輯熵不足,攻擊者不需要成功登入,就能讀寫任意檔案。第二階段再從檔案寫入走到 libgld。
兩步都不經過帳號驗證,所以 2FA、強密碼、停用預設 admin、自動 IP 封鎖全部失效——它們守的是登入,而攻擊發生在登入之前。多份受害者回報正是如此:四項都開了,資料照樣被加密。真正有效的控制只有一個,把 DSM 從網際網路上拿走;其餘都是縱深。
香港用家實際要做什麼
第一步是別相信「已是最新」。用 SSH 執行 cat /etc.defaults/VERSION 讀實際 build 號,再對上面的修復線;「Update N」的後綴可能仍低於安全修復線,部分 2025 年前的機型就算顯示已最新,安全性更新仍要手動裝。更新後輪替管理員密碼,並使既有工作階段失效。
第二步是縮小暴露面:移除路由器上指向 5000/5001 與 SMB 的連接埠轉送、關掉 UPnP、停用 QuickConnect,遠端存取改用 VPN。也要檢查 IPv6,多個個案是經由沒有防火牆的 IPv6 直連管理介面進來的。順手關掉 SSH、Telnet 與沒在用的套件,並查看 Container Manager 有沒有對外映射的容器。
第三步是判斷有沒有中。檔案出現 .L0CK3D 或 read-me3.txt、程序列表有 libgld、Log Center 有異常登入與大量檔案修改、出現非預期的管理員帳號或 cron 排程,任何一項都當成已入侵。若正在加密,不要關機、不要重開、不要重裝 DSM:先拔網路線隔離,再以 kill -STOP 凍結程序並傾印記憶體保存金鑰。重開會毀掉唯一可行的免費復原路徑。復原優先用 Btrfs 快照,並把 Snapshot Replication 設成不可變、有鎖定期;RAID 與同機 Hyper Backup 不算備份。
常見問題
DSM 顯示已是最新,還要更新嗎?要。系統的「最新」看的是更新通道,不是安全修復線;請以 build 號比對公告版本。
開了 2FA 為何仍被加密?因為入口在登入之前。CVE-2024-10441 與 CVE-2026-13639 都是未經驗證即可觸及的漏洞,2FA 保護的是登入之後的動作,擋不到登入前的檔案寫入。
有解密工具嗎?沒有公開的通用工具,No More Ransom 未收錄,Emsisoft 與 Dr.Web 實測失敗。唯一已知例外是在加密程序仍在執行時凍結並取出記憶體金鑰,屬個案,不是工具。
香港與台灣有官方警示嗎?截至十月三十日,HKCERT 與 TWCERT/CC 都未就這次事件發出公告;香港只有媒體報導。若要追官方口徑,直接看 Synology 的 SA-24:20 與 SA-26:13。
這波攻擊沒有新奇的手法,只有一段被拉得太長的時間。真正決定損失的,不是 ChaCha8 或 RSA-2048,而是那台機器在事發當晚,還在不在網際網路上。
分類:Technology
標籤:2FA · C3RB3R · CVE-2024-10441 · NAS · Synology · 勒索軟體





