那份能通過所有檢查的檔案
檔案安全處理流程是建立在一個鮮少受到質疑的假設之上：每個檔案只有一種類型。偵測器會為其命名，而政策則據此進行路由。隨後，每個下游引擎都會依據該類型對檔案進行分析：包括防惡意軟體、沙箱檢測及淨化處理。
多格式檔案打破了這項假設。單一位元組流可以同時是一個完全有效的 GIF檔案，也是一个完全有效的 Java 存檔。同樣的伎倆也適用於既是 JPEG 檔案又是 RAR 存檔的檔案，或是攜帶完整 ZIP 檔案（其內容延伸至邏輯結尾之後）的 PDF 檔案。每個面向單獨來看都符合標準，因此沒有任何單一格式解析器會偵測到任何異常。
一張圖片中的多語言達人：經典的 GIF+JAR 組合。兩個解析器、兩個入口點、一個檔案，而且每個面都完全有效。
其安全影響非常明確：管道會根據偵測到的類型對檔案進行掃描，而 其他格式則會毫髮無損地通過。當網頁應用程式將同時具備圖片與腳本特性的檔案傳回時，該檔案便會轉變為儲存型 XSS。隱藏在圖片外殼下的壓縮檔，能將其有效載荷繞過內容過濾器。基於此概念建構的攻擊鏈——從經典的 GIF+JAR 組合到借助隱寫術的漏洞利用傳遞——已為人所知近二十年。 由於每個圖像在獨立檢查時均屬無害，因此反惡意軟體引擎對此仍大多束手無策。
引擎如何找到第二張臉
我們的檔案結構驗證引擎將多語言偵測作為預處理步驟，在任何格式處理器運作之前，對每個被掃描的檔案進行處理。此設計基於三個核心理念。
- 掃描整個資料流。掃描器會將整個檔案與一組格式魔術簽名清單進行比對。即使檔案已被偵測出類型，只要資料流中的任何位置出現第二種格式，系統仍會標示其確切偏移量。這包括附加在 PDF 檔案結尾標記之後，或隱藏在影像像素資料後方的簽名。
- 了解格式何時才真正結束。 Container 等格式在技術上允許在內部包含其他檔案。ZIP 檔案中的圖片即屬普通內容。偵測器會根據各容器自身的結構，判定其真正的結束點。PDF 的尾部、ZIP 的中央目錄，以及 OLE（物件連結與嵌入）複合檔案的區塊配置，皆標示著該邊界。PDF 的解析機制會考量增量更新。 唯有位於該結構之外的簽名，才被視為第二個邊界。正是這個結構性邊界，區分了真正的多格式判定與針對每個普通壓縮檔的誤報。
- 在提出指控前請先確認。引擎會從資料流中擷取每個候選面，並在回報前透過我們的「檔案類型」引擎獨立重新辨識。被辨識為非結構化資料的候選面將被剔除。若判定為「成立」，表示在該偏移量處確實存在第二種格式。僅憑零散的魔法位元組，絕不會產生此結果。
此為真實範例：一個 PDF 檔案內嵌了 JPG 與 PNG 檔，並在其邏輯結尾之後附加了 ZIP 與 TIFF 檔案。鑑定結果明確列出 ZIP 與 TIFF 檔案，但對內嵌的圖片則未作說明。
結果會報告每個面及其偏移量。例如，上傳的單一 .gif 檔案會被識別為偏移量為 0 的 GIF89a，同時在資料流更深處被識別為 ZIP 壓縮檔。其餘處理方式則由政策決定：報告此發現，或直接封鎖該檔案，並附上列出所有匹配項目的說明。
從偵測到剖析
偵測僅是解決方案的一半，因為「多語種」的訣竅在於，每個面看起來都無害。偵測完成後，引擎會將檔案拆解。每個經確認的面都會被匯出為獨立的物件（例如polyglot_part_1.pdf、polyglot_part_2.zip 等），並附上其格式、偏移量及大小。引擎會將每個物件交還給MetaDefender Core™工作流程，以便根據其真實性質進行完整處理。
我們已在實際運作中的MetaDefender Core™ 執行個體上對此進行了端到端的驗證。
引擎將一個秘密夾帶 Word 文件（PDF+JAR+DOCX 多格式檔案）的 PDF 樣本，拆分為其 PDF 層面與 ZIP 層面。由於 JAR 和 DOCX 都是 ZIP 容器，因此一個 ZIP 層面即可滿足兩項規格要求。隨後，檔案類型引擎將該層面識別為 DOCX，並由Deep CDR™ 技術對其進行個別淨化處理。這個隱藏層面最終受到與其原本旨在規避的處理方式相同的處理。
精準度才是最難的部分
「魔術位元組」在無害的檔案中本就會自然出現，因此真正的工程投入在於避免「狼來了」的誤報。相機照片會嵌入攜帶自身 JPEG 簽名的 EXIF 縮圖；Office 文件則會將圖片嵌入其容器結構中；Media 檔案中隨機包含看似壓縮標頭的位元組序列。 偵測邏輯會排除那些已被合法結構涵蓋的位元組，而這種強化措施正持續針對各種格式逐一擴展。若某個偵測器會將每張相機照片都標記為可疑，該偵測器便會被關閉；而一個被關閉的偵測器，根本無法保護任何人。
經由真正的多語者驗證
我們將真實的多語言樣本透過配備「檔案結構驗證」引擎的MetaDefender Core™ 即時部署環境進行測試。所有樣本均被成功偵測，且每個面都被精確定位到其對應的位元組偏移量：
範例 | 找到的面（偏移量） | 結果 |
將 Word 文件隱藏於 PDF 中（PDF、JAR 與 DOCX 整合為單一檔案） | PDF @ 0 · ZIP @ 34,016 | 已擷取人臉；透過 Deep CDR™ 技術對隱藏的 DOCX 檔案進行了清理 |
GIF 圖像中隱藏了一個壓縮檔和第二張圖片 | GIF89a @ 0 · ZIP @ 25,214 · TIFF @ 154,270 | 已偵測到 |
Office 文件中隱藏的 PDF 檔案 | OLE @ 0 · PDF @ 73,217 | 已偵測到 |
將 PDF 隱藏於 JPEG 檔案中 | 三張臉，PDF 附件 @ 26,830 | 已偵測到 |
《PoC‖GTFO》第 3 期，這本以 PDF+ZIP 多語言格式製作的安全研究小誌，大小為 26 MB | PDF @ 25 · ZIP @ 12,224,072 | 偵測到：完整掃描在 12 MB 深度處發現第二張臉 |
包含 GZIP 資料流和 Java 存檔的 GIF 檔案 | GIF89a @ 0 · GZIP @ 427,764 · ZIP @ 937,265 | 被封鎖 |
PDF 內嵌了一張 JPG 和一張 PNG 圖片，並附加了一個 ZIP 檔案和一個 TIFF 檔案 | PDF @ 0 · ZIP @ 204,849 · TIFF @ 257,395 | 遭封鎖；嵌入的圖片未被正確通報 |
最後一行顯示了「拒收規則」的運作情形：判定結果指明附加的 ZIP 和 TIFF 檔案，並忽略 PDF 內的圖片。容器解析器將這些檔案視為 PDF 本身的內容。MetaDefender Core™ 針對該檔案產生的結果 JSON（節錄）：
fsv_output_files清單正是上述所描述的「解剖」過程的實例：將三個面切出後，作為獨立物件交還給工作流程。
以下是MetaDefender Core™ 中各項範例結果的螢幕截圖：
適用範圍與設定
今日的涵蓋範圍包含攻擊者實際會組合使用的各種檔案格式：PDF、ZIP、OLE 複合檔案、PNG、GIF、JPEG、TIFF、RAR、GZIP 以及 7z。
結構性容器結尾解析功能適用於各種容器格式。此功能採用「配置優先」的設計：偵測、封鎖及完整檔案掃描皆為政策開關，因此操作人員可針對每個部署環境，在「可視性」與「強制執行」之間進行選擇。
底線
一個包含兩個有效面（face）的檔案，會讓任何將其歸類為單一類型的處理流程失效，而單一類型偵測正是大多數掃描堆疊的基礎。結構化多語言偵測透過找出每個面並證明每個面皆可解析，來彌補此缺口。如此一來，政策便能在任何應用程式選錯解釋器之前，先將該檔案封鎖。
目前已支援對常見攻擊格式的偵測。其餘壓縮檔格式的「容器結尾解析」功能，則已列入後續開發計畫中。
了解「檔案結構驗證」如何處理在您的環境中傳輸的各種檔案格式。
