漏洞攻擊
NVIDIA Riva 漏洞導致人工智慧驅動的語音及翻譯服務陷入危險
Trend Research 發現了 NVIDIA Riva 部署環境的組態設定錯誤，包括會讓這類環境暴露於風險的兩個漏洞：CVE-2025-23242 和 CVE-2025-23243。這些資安漏洞可能導致未經授權的存取、資源濫用，以及人工智慧推論服務遭到濫用或竊取，包括語音辨識與文字轉語音服務。
摘要：
- Trend Research 在多家企業的 NVIDIA Riva 雲端部署環境發現了 NVIDIA Riva API 端點暴露在外的情況。這些暴露在外的執行個體都採用無須認證的方式運作，因此有可能讓駭客輕易存取這些執行個體。我們發現了兩個導致這項風險的漏洞：CVE-2025-23242 和 CVE-2025-23243。
- Riva 部署環境的組態設定錯誤，導致駭客可以在未經授權的情況下存取 GPU 資源和 API 金鑰而不受限制。此外，暴露在外的 API 也會增加資料外洩、阻斷服務 (DoS) 攻擊以及系統中斷的風險。
- 若企業是使用其專屬的模型來提供 AI 驅動的服務，有可能因而面臨智慧財產遭竊的風險，尤其當模型或推論服務因組態設定錯誤而暴露在外時。
- 企業應檢查一下自己的部署環境，尤其是採用預設組態或是組態設定錯誤的雲端環境，因為這有可能導致 Riva 服務不小心暴露在外。同時，採用 Triton Inference Server 進階組態設定的企業也應確認一下自己的資安狀況，因為組態設定錯誤或過度暴露在外都可能造成資安風險，為駭客提供潛在的攻擊途徑。
- Trend Vision One™ Cloud Risk Management 能主動偵測雲端部署環境不小心暴露在網路上的情況。如需更多的最佳實務原則與詳細建議，請參閱本文末端的防範指引。
NVIDIA Riva 象徵 AI 語音辨識、翻譯及合成的一項劃時代突破，能讓企業將高效能模型整合至各種應用程式當中，包括：聽寫、語音助理，以及對話式 AI。
然而這套技術的建置卻也帶來了全新而獨特的資安挑戰。由於其部署架構的複雜性，再加上一層又一層錯綜複雜的 AI 模型和 API，創造了一個需要謹慎思考的龐大攻擊面。因此，企業若急於導入其進階語音辨識功能，有可能因而暴露於資安風險當中。
我們在多家採用雲端部署的企業發現到一個令人擔憂的現象，那就是他們的 NVIDIA Riva API 端點暴露在外。這是典型的資安疏失：在缺乏認證保護的環境下運作，使得任何駭客都能輕鬆存取。
這樣的問題很可能導致任何人都能免費存取其 Riva 服務，例如：使用其昂貴的硬體資源和付費的 API 金鑰。另一個可能的後果是底層的服務資訊曝光，使得它在套用進階組態設定時，很容易讓 Triton Inference Server 推論伺服器遭遇阻斷服務 (DoS) 與記憶體攻擊。
我們發現了兩個像這樣會讓服務暴露在外的漏洞：CVE-2025-23242 和 CVE-2025-23243。在與 Trend Zero Day Initiative™ (ZDI) 漏洞懸賞計畫共同負責任地揭露這些漏洞之後，目前漏洞已經獲得修正，揭露編號分別為：ZDI-25-145 和 ZDI-25-144。
要了解這些漏洞，我們得從 NVIDIA Riva Quick Start Guide 快速入門指南著手，我們遵照其教學的說明取得了一個 NGC 指令列工具程式，並下載了 QuickStart 資源。其初始化腳本會從 NVIDIA Artifact Registry 下載必要的容器映像與 AI 模型。請注意，要取得並使用這些模型，您需要適當的 GPU 硬體和有效的 API 金鑰。
一旦初始化完成，我們就能使用「bash riva_start.sh」這道指令來啟動 Riva 服務。成功啟動之後，Riva 伺服器就會監聽連接埠 50051 上的 gRPC 連線。由於它使用了第三方函式庫，因此就看不到底層的實作方式。它可當成一個方便的全功能套件，同時也是一套現成的複雜軟體解決方案。
容器對主機開放了數個連接埠，並且會監聽 0.0.0.0 這個位址 (代表全部的 IP)。這樣的網路設定等同於使用「docker --network host」這個參數，而且，如果沒有設定任何防火牆的話，那麼人人都可以存取。
Riva gRPC API 通訊協定出廠預設啟用了 gRPC 反射功能，讓每個人都能找出其服務的類型，並重新建構二進位通訊協定。這樣做本身並不是個問題，因為想要單靠資訊不透明來保持安全，並非一個很好的作法。只不過，服務一旦暴露在外，就會讓人很容易找到。Riva gRPC 通訊協定在 GitHub 上已有多個開放原始碼儲存庫，所以開發人員對它應該相當熟悉。
這也引起了一個問題：這些 gRPC 端點裝置是否安全？ 使用者在看過說明文件和手邊的範例之後，很可能以為該服務可以被設定得相當安全，只需透過修改 config.sh 腳本然後產生適當的憑證即可。
然而，就算在 NVIDIA QuickStart 套件的 config.sh 中設定了所有的憑證參數，gRPC 伺服器還是只會強制使用 TLS/SSL 連線，以及將用戶端與伺服器之間的流量加密而已。換句話說，您的確可以確認伺服器的身分，但卻沒有人會對用戶端進行查驗，所以每個人都能使用該服務。這樣的情況有可能給人一種虛假的安全感，但其實該服務卻是人人都能存取。
至於其他暴露在外的連接埠呢？ Riva 伺服器會與 Triton Inference Server 進行內部通訊。事實上，它只會將 API 請求轉換成 Triton Inference Server 能理解的語言。這些連接埠會因為容器組態設定的關係而讓 Triton Inference Server 二進位檔案暴露在外：
- REST API 端點 (預設 8000)
- gRPC API 端點 (預設 8001)
- HTTP 衡量指標 (metrics) 端點 (預設 8002) (僅 /metrics 端點)
這使得 REST 和 gRPC Triton Inference Server API 會開放給每個人都能使用。所以，就算 Riva 伺服器的 gRPC 端點受到妥善的保護，但只要將請求轉換成 Triton Inference Server 端點所需的形式，就能完全略過其保護機制。
值得注意的是，當 Triton Inference Server 設定了進階設定時，有些端點會帶來嚴重的資安風險，因為它們可能暴露出其內在的缺陷，以及前面揭露的漏洞。
也許很多企業會質疑這些對使用者來說算不算是資安問題，但我們首先必須了解問題的範圍和普遍程度。要回答這問題，我們必須說明我們一開始是如何發現這個問題的。我們之前就寫過一篇有關 gRPC 實作不安全的問題。
在進一步深入研究之後，我們發現有 54 個非重複的 IP 位址其 NVIDIA Riva 服務暴露在外，而且全都是雲端服務供應商的 IP 位址，這項發現促使我們對問題的根源進行了深入的了解。
資安最佳實務原則與建議
我們建議所有 Riva 服務的系統管理員都應檢查其組態設定，看看是否有服務不小心暴露在外的情況，同時也確定自己執行的是最新版的 Riva 框架。除了 NVIDIA 的最佳實務原則之外，您也可考慮採取以下資安措施：
- 建置一個安全 API 閘道，只將需要的 gRPC 或 REST API 端點暴露在外。如此有助於防範未經授權的存取，保護後端服務。
- 實施網路分割，限制唯有受信任的網路能夠存取 Riva 伺服器與 Triton Inference Server。這有助於縮小攻擊面，防止來自網際網路的未經授權存取。
- 要求使用嚴格的認證機制，並強制實施角色導向的存取控管，確保唯有經過授權的使用者和服務才能與 Riva API 互動。考慮採用零信任方法，例如具備身分感應的存取控管，確保唯有經過認證和授權的使用者和裝置才能與 Riva 服務互動。
- 檢查並修改容器設定來停用不必要的服務、移除未使用的連接埠，並且限制特權容器執行。如此可避免駭客利用暴露在外的服務或組態設定錯誤。
- 啟用 Riva 和 Triton Inference Server 的記錄檔與監控功能來偵測異常存取模式、異常活動或潛在的濫用。
- 考慮限制速率與 API 請求流量調節 (request throttling)，尤其當 gRPC 或 REST 端點暴露在外部網路、或整合至駭客可能試圖使用暴力破解或 DoS 攻擊的環境時。
- 讓 Riva 框架、Triton Inference Server 以及相依元件隨時保持更新來防範已知漏洞，同時防範新發現的漏洞攻擊手法。
趨勢科技防護
Cloud Risk Management 能主動偵測雲端部署環境不小心暴露在外部網路的情況，就如我們發現的狀況一樣。Cloud Risk Management 的 EC2-016 和 EC2-001 兩個 ID 就是可預防這類暴露的資安檢查範例。
- EC2-016 有助於確保 Amazon EC2 的預設資安群組會限制所有內送的公共流量，藉此強迫 AWS 使用者 (系統管理員、資源管理員等等) 建立客製化的資安群組來落實最低授權原則 (POLP)，而非使用預設的資安群組。
- EC2-001 有助於確保 Amazon EC2 的資安群組不會對內送流量開啟各種連接埠，藉此保護相關的 EC2 執行個體，防範阻斷服務 (DoS) 攻擊或暴力破解攻擊。Cloud Risk Management 強烈建議您在資安群組內只開放某些特定連接埠，視您的應用程式需求而定。