How We Secure Our Digital Signature Validation in PDF

By Apryse | 2021 Sep 24

6 min

Background

Copied to clipboard

In their March 2020 report, titled "Vulnerability Report: Attacks Bypassing the Signature Validation in PDF," the research team of Mainka et al. revealed a series of vulnerabilities in PDF-based digital signatures.

Cited in the report is a previous 2019 analysis of 22 commercial applications. This found 21 vulnerable to one or more of three severe weaknesses in PDF-based digital signature validation published at https://pdf-insecurity.org/. The March 2020 study demonstrates how attackers can exploit these weaknesses to change document appearances or add vulnerabilities⁠—and still have manipulated content pass validation.

At the inception of our signature validation solution, we took the possibility of such weaknesses very seriously. At the same time, we didn’t want to limit what developers could do with our technology. Thus we built our validation and Modification Detection and Prevention (MDP) verification from the ground up using a different and more strenuous approach. We call this approach "secure by default”, detailed in a lengthy September 2020 article on our blog.

Summarized quickly: secure by default is an approach whereby the Apryse SDK disallows every change upfront and then only allows changes back in selectively based on a list of safe actions curated by our engineers. Such a "strong" approach to verification and MDP ensures less uncertainty third parties could prospect for weaknesses, such as those published on pdf-insecurity.org.

In contrast, many other vendors don't bother with MDP verification. They instead leave it to the customer. Or they support MDP but take an easier-to-implement and permissive approach, restricting only known dicey actions while ignoring other actions deemed not worth investigating.

Putting Apryse to the Test

Copied to clipboard

We looked at vulnerabilities discovered by researchers and at the associated test corpus available at pdf-insecurity.org. And after careful evaluation, we determined the Apryse SDK not vulnerable (and never was vulnerable) to any of these weaknesses.

Under our secure-by-default design, an attacker shouldn't be able to change random referenced objects arbitrarily. This prevents (among other things) document structure attacks reliant on modifying objects such as Pages, Page, Catalog, and Contents within a PDF document.

Regarding Specific Vulnerabilities

Copied to clipboard

Here is a detailed account of vulnerabilities discussed by Mainka et al. and how they are solved with the Apryse SDK.

Vulnerabilities in Section 5.3

1. Hiding page content via incremental saves

The first vulnerability referenced in the report consists of hiding page content by changing Page objects via PDF’s incremental save feature (see section 2.2.7 "Incremental Update" in the PDF Reference Manual. Using incremental save, a third-party could insert new content or changes by writing to the end of the file, outside the encrypted envelope created with the signature digest.

The Apryse SDK MDP verification is not vulnerable to the first item. An attacker is not allowed to create or modify pages without detection under our MDP design. Any violation of these privileges would invalidate signatures.

2. Changing the overlay from an image to Metadata

A second vulnerability consists of changing the type of an overlay from an image to Metadata. For example, suppose a validator program detects changes by looking at object types, and object types are changed so they no longer fall into categories screened for changes. In that case, a reader program will fail to detect modifications.

Additionally, a reader program that decides whether to display overlays based on object type will no longer display important information during review and signing. But the document may be changeable later (under the nose of a less-strict MDP verifier) by changing the object type to display previously hidden content.Thus the signer would have authorized content they never saw!

The Apryse SDK is not vulnerable here either. It disallows changes to referenced objects with no reason to change, so the image object will be detected as a change to an existing object and disallowed.

Vulnerabilities in Section 5.4:

1. Changing objects referenced by a Field Dictionary

This vulnerability involves changing objects referenced by a Field dictionary (e.g., BBox). Apryse SDK is not vulnerable as it only allows AP, sometimes flags, and V to change on fields in incremental saves (for signing additional signatures), if allowed by the permissions.

2. Adding or changing fonts

Another vulnerability consists of adding or changing fonts, on the assumption that verifiers won’t check this. The Apryse SDK does not allow any referenced objects to change except if required by a PDF workflow and allowed by permissions.

Further Considerations on Section 5

The Apryse SDK is not vulnerable to vulnerabilities described in section 5 as each requires modification of the reference to the document catalog dictionary (Root) from the trailer. We will detect this change. And you can entirely mitigate these attacks with the precaution of saving documents using remove_unused mode before applying the first signature with the Apryse SDK as follows:

// You have an unsigned document. You save with e_remove_unused to clean it up of shadow (unreferenced) objects before saving.
doc.Save(output_path + "tiger_withApprovalField_output.pdf", SDFDoc::e_remove_unused, 0);
// Now, you can sign the document more securely.

Considerations on Section 7

In section 7, the research team recommends several countermeasures to previously discussed vulnerabilities. Each involves reporting unusual changes in the save of the document.

The Apryse SDK already has these countermeasures in place, as it flags e_invalidated_by_disallowed_changes and e_has_allowed_changes as possible codes within its MDP verification reporting.

To make it easy to find which of or if any changes are unsigned, we also offer an API to fetch the ByteRanges to which a signature applies:

const std::vector<Common::ByteRange> byteranges = digsigfield.GetByteRanges();
	// Caller is responsible for sanity-checking the byteranges before using them...
	if (byteranges.size() != 2)
	{
	throw std::exception();
	}
	// ...

Other Advanced Considerations

Copied to clipboard

In addition, the group of researchers also described a signature wrapping attack, as outlined in older articles and in the test corpus at pdf-insecurity.org. The Apryse SDK is not vulnerable to the wrapping attack during verification with documents signed with the Apryse SDK.

The reason for this is as follows: the attack consists of adding another ByteRange inside the padding after the CMS in the Contents entry of the digital signature dictionary. This technique may cause alternatives to verify a modified signature against a different range of bytes.

However, with the Apryse SDK, we only use the first ByteRange entry found, and if you use our signing, the ByteRange will be written before Contents. The Apryse SDK signing also mitigates any possible wrapping vulnerability in other validators because we put less padding after CMS (only 64 bytes) than many other processors (which add as much as 10 MiB). We thus make it difficult to put anything significant after the CMS data.

Finally, regarding the class of “universal signature forgery” attacks described earlier by the same research group: the Apryse SDK is not vulnerable to those either, representing a large portion of their test corpus to which we are not vulnerable, as mentioned above. These attacks consist of the introduction of various edge case or illegal values into signature dictionaries, which we check for rigorously and disallow in our secure-by-default verification code.