淺談如何實現PDF簽名的欺騙攻擊
責編：gltian ｜2019-03-21 17:24:25前言
本文對PDF文件及其數字簽名機制進行了分析，并提出了三種針對PDF簽名的攻擊方式。
一年前，我們收到一份PDF合同，包含有數字簽名。我們查看文檔內容的時候，忽略了其“證書不可信”的警告。不禁令人心生疑惑：
“PDF簽名機制如何工作？”
我們對于類似xml和json信息格式的安全性非常熟悉了，但是似乎很少有人了解，PDF的安全機制是如何工作的。因此我們決定圍繞此問題展開研究。
時至今日，我們很高興的公布我們的研究成果。本篇文章中，我們簡要概述了PDF簽名的工作機理，重要的是我們揭示了三個新的攻擊方式，用于實現對PDF文檔數字簽名的欺騙。我們對22款PDF閱讀器進行測試評估，結果發現有21個是存在安全性風險的。我們還對8個在線驗證服務進行測試，結果發現有6個是易受攻擊的。
通過與BSI-CERT合作，我們聯系了所有的開發商，向他們提供PoC，并幫助修復漏洞。對每一種攻擊方式均取得了CVE：CVE-2018-16042,?CVE-2018-18688,?CVE-2018-18689。
完整的結果可參考Karsten Meyer zu Selhausen的論文，我們的研究報告或者我們的網站
究竟何人在用PDF簽名？
也許你會心生疑問：既然PDF簽名如此重要，那么究竟誰在使用？
事實上，也許你自己早就使用過PDF簽名。
你是否曾經打開過諸如Amazon、Sixt 或是 Decathlon 公司開具的發票？
這些PDF文件都是經過數字簽名保護的，以防止被篡改。
實際上，PDF簽名在我們身邊具有廣泛的應用。2000年，Bill Clinton總統頒布了一項聯邦法律，推廣在各州間和國際間數字簽名的使用，以確保合同的有效性和法律效力。他通過數字簽名簽署了此項法案。
自2014年起，在歐盟成員國內提供公共數字服務的組織必須支持數字簽名文檔，這些文檔甚至可以作為法律訴訟的證據。
在奧地利，每個政府機構都會對所有官方文檔進行數字簽名。此外，任何新頒布的法律只有在其文檔經過數字簽名后，才算在法律上生效。
像巴西、加拿大、俄羅斯和日本等國也都廣泛使用數字簽名文檔。
據Adobe官方聲稱，公司僅在2017年就處理了80億個數字簽名。
PDF文件及其簽名速覽
為更好的理解數字簽名欺騙，我們首先不得不解釋一些基本概念。首先對PDF文件進行概述。
PDF文件其本質是ASCII文件。利用普通的文本編輯器打開，即可觀察到源代碼。
- PDF header：header是PDF文件的第一行，定義了所需解釋器的版本。示例中的版本是PDF1.7.
- PDF body：body定義了PDF文件的內容，包括文件自身的文本塊、字體、圖片和其他數據。body的主體部分是對象。每個對象以一個對象編號開頭，后面跟一個代號（generation number）。如果對相應的對象進行了更改，則應該增加代號。
在所給示例中，Body包含4個對象：Catalog, Pages, Page, stream。Catalog對象是PDF文件的根對象，定義了文檔結構，還可以聲明訪問權限。Catalog對象應用了Pages對象，后者定義了頁數以及對每個Pages對象的引用信息。Pages對象包含有如何構建一個單獨頁面的信息。在給定的示例中，它包含一個單獨的字符串對象“hello world!”
- Xref table：包含文件內所有PDF對象的位置信息（字節偏移量）
- Trailer：當一個PDF文件讀入內存，將從尾到頭進行處理。這就意味著，Trailer是PDF文檔中首先處理的內容，它包含對Catalog和Xref table的引用。
PDF簽名依賴于PDF一項特定功能，稱之為增量存儲（也稱增量更新），其允許修改PDF文件而不必改變之前的內容。
從圖中觀察可知，原始的文檔和這里的文檔是一樣的。通過對文檔進行簽名，利用增量存儲來添加以下內容：一個新的Catalog，一個簽名對象，一個新的Xref table引用了新對象，和一個新的Trailer。其中，新Catalog通過添加對Signature對象的引用，來擴展舊Catalog。Signature對象（5 0 obj）包含有哈希和簽名文檔的密碼算法信息。它還有一個Contents參數，其包含一個16進制編碼的PKCS7 blob，該blob存有證書信息，以及利用證書中公鑰對應私鑰創建簽名值。ByteRange 參數指定了PDF文件的哪些字節用作簽名計算的哈希輸入，并定義了2個整數元組：
- a,b： 從字節偏移量a開始，后續的b個字節作為哈希運算的第一個輸入。通常，a取值為0表示起始位置為文件頭部，偏移量b則取值為PKCS#7 blob的起始位置。
- c,d：通常，偏移量c為PKCS#7 blob的結束位置，而c d則指向PDF文件的最后一個字節的范圍，用作哈希運算的第二個輸入。
根據相應的規范，建議對文件進行簽名時，并不計算PKCS#7 blob部分（位于b和c之間）。
攻擊方式
根據研究，我們發現了針對PDF簽名的三種新型攻擊方式：
- 通用簽名偽造（Universal Signature Forgery ，USF）
- 增量存儲攻擊（Incremental Saving Attack ，ISA）
- 簽名包裝攻擊（Signature Wrapping Attack ，SWA）
在本篇文章中，我們僅對各攻擊進行概述，并不闡述詳細的技術細節。如果讀者對此感興趣，可參考我們總結的資源。
通用簽名偽造的主體思想就是控制簽名中的原始數據信息，通過這種方式，使目標閱讀器程序在打開PDF文件尋找簽名時，無法找到其驗證所需的所有數據信息。
這種操作并不會導致將缺失的信息認定為錯誤，相反其會顯示簽名的驗證是有效的。例如，攻擊者控制Signature對象中的Contents或ByteRange的數值，對其控制操作的具體內容：我們要么直接移除簽名值，要么刪除簽名內容的起始位置信息。這種攻擊似乎微不足道，但即使是諸如Adobe Reader DC這樣優秀的開發程序，能夠阻止其他多種功能類型的攻擊，卻也容易遭受USF攻擊。
增量存儲攻擊濫用了PDF規范中的合法功能，該功能允許PDF文件通過追加內容來實現文件更新。這項功能很有用處，例如存儲PDF注釋或者在編輯文件時添加新的頁面。
ISA的主要思想是利用相同的技術來將簽名PDF文件中的元素更改為攻擊者所需內容，例如文本、或是整個頁面。
換而言之，一個攻擊者可以通過Body Updates重新定義文檔的結構和內容。PDF文件內的數字簽名可以精確保護ByteRange定義的文件內容。由于增量存儲會將Body Updates追加保存到文件的結尾，其不屬于ByteRange定義的內容，因此也就不受數據簽名的完整性保護。總而言之，簽名仍然有效，而Body Updates也更改了文件的內容。
PDF規范并沒有禁止此操作，但簽名驗證應指明已簽名的文檔已經被篡改。
獨立于PDF，簽名包裝攻擊的主體思想是迫使驗證邏輯處理與應用邏輯不同的數據。
在PDF文件中，SWA將原始的簽名內容重定位到文檔內的不同位置，并在已分配的位置處插入新的內容，以此來定位簽名驗證邏輯。攻擊的起始點是控制ByteRange值，使其允許簽名內容轉移到文件內的不同位置。
在技術層面上，攻擊者使用有效的簽名文檔（如圖所示），并按以下方式執行操作：
- step 1 （可選）：攻擊者刪除Contents參數內的零字節填充，以增加注入操作對象的可用空間。
- step 2：攻擊者通過操控c的值來定義新的
ByteRange [a b c* d]，使其指向文件中處于不同位置的第二個簽名部分。 - step 3：攻擊者創建指向新對象的新的Xref table，必須保持新插入的Xref table的字節偏移與前一個Xref table的相同。該位置不可更改，因為它是由已簽名的Trailer所引用的。正因如此，攻擊者可以在新的Xref table前增加一個填充塊（例如，可用空格），以此來填滿未用空間。
- step 4：攻擊者注入不受簽名保護的惡意對象。對這些對象而言，有多種不同的注入點。它們可以放置于惡意Xref table之前或之后。如果step 1沒有執行，則只能將其放置于惡意Xref table之后。
- step 5（可選）：一些PDF閱讀器需要在操控的Xref table之后加入Trailer，否則將無法打開PDF文件或者檢測到修改并提示錯誤信息。拷貝最后部分的Trailer，從而繞過其限制。
- step 6：攻擊者刪除在字節偏移c*處、由c和d定義的已簽名內容。當然，也可以選擇刪除封裝在流對象中的內容。值得注意的是，被操控的PDF文件并沒有以%%EOF結尾。一些驗證程序之所以會提示已簽名文件被修改，是由于簽名后面的%%EOF。為了繞過此需求，PDF文件無法正常關閉。但是，它仍然可以由其他閱讀器處理。
測試評估
在我們的測試評估階段，我們搜索了驗證PDF文件簽名的桌面應用程序。我們針對這3種攻擊方式，驗證了其簽名驗證流程的安全性。有22個應用程序滿足要求。我們在所有支持的平臺上（Windows, MacOS, and Linux），對這些應用程序的最新版本進行了評估，結果如下所示：
