Redis滿分漏洞解析
今天來講一個嚴重卻又沒這麼嚴重的 10 分滿分 Redis RCE 漏洞。
這兩天爆了一個名為 RedisShell 的漏洞 CVE-2025-49844，是個 CVSS 10 分滿分的 critical 漏洞。
CVSS 全名為 Common Vulnerability Scoring System，在資安界是個普遍的評估漏洞嚴重程度的標準，會將攻擊所需前提以及影響範圍列入考量，最後算出一個分數，會考量的範圍有：
- 從哪裡觸發漏洞，是透過網際網路，還是必須在同個網段，甚至是要實體接觸裝置等
- 攻擊複雜度，是否能夠穩定利用漏洞
- 所需權限，例如說有些漏洞要管理員身份才能觸發
- 是否需要使用者點擊或開啟檔案等互動來觸發
- 影響範圍，是侷限在該系統內還是能擴大範圍
- 對機密性（Confidentiality）、完整性（Integrity）以及可用性（Availability）造成的影響
這次 Redis 的漏洞由於是 RCE，遠端程式碼執行，因此 CIA 三個的影響都是 High，影響範圍也會擴大，畢竟能超過 Redis 的範圍，在該台主機上執行命令。
那為什麼我會說這個漏洞嚴重又沒這麼嚴重呢？10 分不就是最嚴重的嗎？
這個洞的成因是，Redis 在執行 Lua 時有問題，導致執行特定的 Lua 腳本可以觸發漏洞，跳脫 Lua sandbox 然後在主機上直接執行命令。
單看 Redis 的話，就是「只要能發送指令，就能 RCE」。
但若是以整體系統架構的層面來看，我們可以想的問題是：「攻擊者該怎麼對 Redis 發送指令？」，最簡單的當然是你 Redis 開在公網又沒 auth，直接被打進來。雖然這種機器確實很多，網路上可以找到一大堆，那會這樣做的群體可能也不會注意到這個最新的漏洞訊息 😆
一個稍微正常一點的系統，Redis 都放在內網裡面，那攻擊者要先打進來拿到某個主機的 RCE，才可以再往 Redis 那台打。但是對小一點的公司來說，第一個 RCE 就可以把他們打爆了，打 Redis 可能沒辦法打到更多東西。
我想說的是「對 Redis 發送指令」這個前提，在一般的環境下沒辦法輕鬆達成，但 CVSS 單看 Redis 本身，所以表現不出這點。10 分是沒問題的，但那是因為最高就是 10 分，Log4j 也是 10 分，甚至一個我覺得更嚴重的 Oracle E-Business Suite Pre-Auth RCE（CVE-2025-61882）也才 9.8 分，所以分數並不是一切。
不過我也可以想像得到，你站在另一個角度看分數這件事，就會不一樣了。
當你是個內部專門管 IT 資安的人，每天面對幾十個新的漏洞，哪有時間去看這些細節，當然是按照嚴重程度由大排到小，然後 critical 的就趕快修掉。做為風險控管的一環，這確實是個合理的做法。
同一個漏洞，在不同的前提之下會帶來不同的結果，之前才跟朋友聊到許多小公司在考慮攻擊面時，不會把橫向移動考慮進去，因為根本也不需要移動，你打下一台就整個系統淪陷了，所以「Redis 被打下來」這個風險是低的。但我也能想像到有些大公司內部分好幾個網路，這時候從 A 透過 Redis RCE 能打到 B 做橫向移動，這個就是很有價值的漏洞。
其實整體都還是風險管理的一部分，在「Redis 有個 10 分漏洞」的前提下，該考慮哪些風險、該怎麼處理等等，在不同框架底下會有不同做法。
但如果你問我該不該趕快修，我的建議是：修，都修。網路上也已經有人整理出簡單 PoC，可以看出這個洞的觸發方式。
評論