資訊安全新聞

當「可信工具」變成攻擊武器：
自動化流程中你從未察覺的 SSRF 與阻斷服務漏洞

摘要

現代軟體架構越來越依賴自動化處理流程，這類流程中經常使用本機端可信工具來處理不受信任的輸入。研究探討此類整合所帶來的安全影響，說明當信任邊界錯位時，獨立工具中功能正常的行為如何轉變為強大的攻擊能力的基礎。透過對 macOS textutil 、KeePassXC 的 KDF 參數以及 Node.js 檔案處理機制的詳細分析，我們證明「離線安全」或「有限成本處理」的假設往往是錯誤的。報告提供這些漏洞機制的技術深入剖析，並提出強健的緩解策略以實現安全的自動化。

當「可信工具」變成攻擊武器：自動化流程中你從未察覺的 SSRF 與阻斷服務漏洞 | 資訊安全新聞

1. 簡介：被動基礎設施的謬誤

安全研究傳統上專注於執行檔缺陷，例如記憶體毀損或身分驗證繞過。然而，有一類重要的漏洞是因為工具在跨信任邊界操作時的「正確」行為所引起 ^[1] 。被視為被動基礎設施的可信本機端工具，經常被整合到後端 worker、CI/CD 任務以及索引系統中。由於這些工具成熟且熟悉，工程師通常認為它們是確定性、離線且運算成本有限。

這種假設相當危險。一個工具在孤立環境下功能正常，但當攻擊者可控制的輸入影響其副作用時，就可能變成與安全相關的基礎功能。如近期技術報告所分析，即使是像 Meta 的 Llama Stack 這類現代框架，也曾因不安全地使用 pyzmq 等可信程式庫而面臨類似的整合風險 ^[3] 。

2. 案例研究 I：macOS textutil 中的網路活躍行為

macOS 上的 textutil 工具是用來轉換文件格式的標準工具。在許多自動化工作流程中，它被用來將 HTML 輸入正規化為純文字。然而，HTML 本質上是一種可引用遠端資源的豐富格式。

2.1 SSRF 基礎功能

當 textutil 處理包含遠端 <img> 或 <link> 標籤的 HTML 時，可能會嘗試提取這些資源以完成轉換程序。在後端環境中，這種行為會將本機轉換步驟轉變為伺服器端請求偽造 (SSRF) 基礎功能 ^[1] 。

2.2 程式碼分析：差異測試框架

下列 Python 腳本展示了僅包含本機內容的 HTML 與包含遠端參照的 HTML 之間的行為差異。此框架證實 textutil 在遇到特定 HTML 結構時會發起對外請求。

#!/usr/bin/env python3
import http.server
import socketserver
import subprocess
import threading
import time
from pathlib import Path
# Setup a local listener to capture outbound requests from textutil
PORT = 8765
hits = []
class CaptureHandler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        hits.append(self.path)
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"captured")
    def log_message(self, *args): pass
def start_server():
    with socketserver.TCPServer(("127.0.0.1", PORT), CaptureHandler) as httpd:
        httpd.serve_forever()
# Run server in background
threading.Thread(target=start_server, daemon=True).start()
time.sleep(0.5)
# Create malicious HTML with remote reference
malicious_html = Path("attack.html")
malicious_html.write_text(f'&lt;html&gt;&lt;body&gt;&lt;img src="http://127.0.0.1:{PORT}/leak"&gt;&lt;/body&gt;&lt;/html&gt;')
# Execute textutil conversion
subprocess.run(["/usr/bin/textutil", "-convert", "txt", "attack.html", "-output", "out.txt"])
if "/leak" in hits:
    print("[!] SSRF Primitive Confirmed: textutil fetched remote resource.")

3. 案例研究 II：透過 KDF 中繼資料耗盡資源

KeePassXC 等密碼管理器使用金鑰衍生函數 (Key Derivation Function, KDF) 來保護資料庫。高運算成本原本是用來抵禦離線暴力破解攻擊的防禦屬性。但當成本參數由輸入檔案本身控制時，就會產生潛在的阻斷服務 (DoS) 漏洞。

3.1 病理的 KDF 成本

針對 KeePassXC 的研究顯示，一個被刻意製作的 KDBX 檔案可以指定極高的轉換回合數。在需要程式化開啟或驗證資料庫的自動化環境中，攻擊者可藉此對處理主機施加顯著的 CPU 負載 ^[1] 。

輸入類型	轉換回合數	執行時間 (秒)	變慢倍數
基準 KDBX	1,000,000	~0.06秒	1倍
刻意製作的 KDBX	353,321,536	~7.50秒	125倍

4. 案例研究 III：Node.js 檔案攔截器中的型別混淆

整合第三方中介層經常會引入細微的型別驗證缺口。對某個流行的 Node.js 框架 (Framework X) 的分析顯示，其依賴 Multer 程式庫的 FileInterceptor ，因不當處理 multipart/form-data 而存在 DoS 漏洞 ^[2] 。

4.1 漏洞機制

當一個非檔案欄位使用了與預期檔案參數相同的名稱送出時， Multer 會以字串而非檔案物件填入 req.file 。如果攔截器未經型別檢查就嘗試存取檔案中繼資料 (例如 originalname )，將會觸發未處理的 TypeError ，導致 Node.js 程序 crash ^[2] 。

// Vulnerable Interceptor Logic
intercept(context, next) {
    const req = context.switchToHttp().getRequest();
    // If req.file is a string, the next line throws TypeError
    const fileName = req.file.originalname; 
    return next.handle();
}
// Secure Implementation (Patch)
intercept(context, next) {
    const req = context.switchToHttp().getRequest();
    // Explicit type and property validation
    if (req.file && typeof req.file === 'object' && 'fieldname' in req.file) {
        return next.handle();
    } else {
        throw new BadRequestException('Invalid file type');
    }
}

5. 技術綜合與緩解策略

上述案例的共同點是未能將可信工具視為主動處理器。要保護自動化流程的安全，組織必須超越以信譽為基礎的信任，轉為實作依行為判斷的控制。

5.1 架構防護措施

1. 沙箱與隔離 ：轉換與解析任務應在受限環境中執行 (例如無網路存取且有嚴格 CPU 配額的容器)。
2. 明確的參數限制 ：對於像 KeePassXC 這樣的工具，應用程式應在開始處理前強制執行 KDF 參數的最大值限制 ^[1] 。
3. 輸入淨化 ：傳遞給 textutil 等轉換工具之前，應先移除 HTML 輸入中帶有遠端參照的結構。
4. 嚴格的型別驗證 ：如 Node.js 案例所示，來自第三方中介層的所有輸入在存取屬性前，必須根據預期的結構描述進行驗證 ^[2] 。

5.2 緩解驗證：-noload 標記

對於 textutil ，有一個具體的緩解方式是以 -noload 標記來防止該工具在轉換過程中載入遠端資源。

# Secure conversion command
/usr/bin/textutil -noload -convert txt input.html -output output.txt

6. 結論

將可信工具轉變為攻擊能力的基礎，是現代自動化中信任邊界錯位的結果。無論是文件轉換器中的 SSRF 基礎功能、密碼管理器中的 DoS 攻擊向量，或是網頁框架中的程序 Crash，根本問題都相同：誤以為工具的行為是靜態且安全的。透過對所有剖析器採用「零信任」態度，並實施嚴格的資源與網路邊界，開發者可以建立能承受功能正常行為被惡意運用的強韌流程。

摘要