مدونة الشاعر عبده عبده

Monday, April 13, 2020

How To Spoof PDF Signatures

One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

"How do PDF signatures exactly work?"

We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042, CVE-2018-18688, CVE-2018-18689.

Full results are available in the master thesis of Karsten Meyer zu Selhausen, in our security report, and on our website.

Digitally Signed PDFs? Who the Hell uses this?

Maybe you asked yourself, if signed PDFs are important and who uses them.
In fact, you may have already used them.
Have you ever opened an Invoice by companies such as Amazon, Sixt, or Decathlon?
These PDFs are digitally signed and protected against modifications.
In fact, PDF signatures are widely deployed in our world. In 2000, President Bill Clinton enacted a federal law facilitating the use of electronic and digital signatures in interstate and foreign commerce by ensuring the validity and legal effect of contracts. He approved the eSign Act by digitally signing it.
Since 2014, organizations delivering public digital services in an EU member state are required to support digitally signed documents, which are even admissible as evidence in legal proceedings.
In Austria, every governmental authority digitally signs any official document [§19]. In addition, any new law is legally valid after its announcement within a digitally signed PDF.
Several countries like Brazil, Canada, the Russian Federation, and Japan also use and accept digitally signed documents.
According to Adobe Sign, the company processed 8 billion electronic and digital signatures in the 2017 alone.

Crash Course: PDF and PDF Signatures

To understand how to spoof PDF Signatures, we unfortunately need to explain the basics first. So here is a breef overview.

PDF files are ASCII files. You can use a common text editor to open them and read the source code.

PDF header. The header is the first line within a PDF and defines the interpreter version to be used. The provided example uses version PDF 1.7.

PDF body. The body defines the content of the PDF and contains text blocks, fonts, images, and metadata regarding the file itself. The main building blocks within the body are objects. Each object starts with an object number followed by a generation number. The generation number should be incremented if additional changes are made to the object.

In the given example, the Body contains four objects: Catalog, Pages, Page, and stream. The Catalog object is the root object of the PDF file. It defines the document structure and can additionally declare access permissions. The Catalog refers to a Pages object which defines the number of the pages and a reference to each Page object (e.g., text columns). The Page object contains information how to build a single page. In the given example, it only contains a single string object "Hello World!".

Xref table. The Xref table contains information about the position (byte offset) of all PDF objects within the file.

Trailer. After a PDF file is read into memory, it is processed from the end to the beginning. By this means, the Trailer is the first processed content of a PDF file. It contains references to the Catalog and the Xref table.

How do PDF Signatures work?

PDF Signatures rely on a feature of the PDF specification called incremental saving (also known as incremental update), allowing the modification of a PDF file without changing the previous content.

As you can see in the figure on the left side, the original document is the same document as the one described above. By signing the document, an incremental saving is applied and the following content is added: a new Catalog, a Signature object, a new Xref table referencing the new object(s), and a new Trailer. The new Catalog extends the old one by adding a reference to the Signature object. The Signature object (5 0 obj) contains information regarding the applied cryptographic algorithms for hashing and signing the document. It additionally includes a Contents parameter containing a hex-encoded PKCS7 blob, which holds the certificates as well as the signature value created with the private key corresponding to the public key stored in the certificate. The ByteRange parameter defines which bytes of the PDF file are used as the hash input for the signature calculation and defines 2 integer tuples:
a, b : Beginning at byte offset a, the following b bytes are used as the first input for the hash calculation. Typically, a 0 is used to indicate that the beginning of the file is used while a b is the byte offset where the PKCS#7 blob begins.
c, d : Typically, byte offset c is the end of the PKCS#7 blob, while c d points to the last byte range of the PDF file and is used as the second input to the hash calculation.

According to the specification, it is recommended to sign the whole file except for the PKCS#7 blob (located in the range between a b and c).

Attacks

During our research, we discovered three novel attack classes on PDF signatures:

Universal Signature Forgery (USF)
Incremental Saving Attack (ISA)
Signature Wrapping Attack (SWA)

In this blog post, we give an overview on the attacks without going into technical details. If you are more interested, just take a look at the sources we summarized for you here.

Universal Signature Forgery (USF)

The main idea of Universal Signature Forgery (USF) is to manipulate the meta information in the signature in such a way that the targeted viewer application opens the PDF file, finds the signature, but is unable to find all necessary data for its validation.

Instead of treating the missing information as an error, it shows that the contained signature is valid. For example, the attacker can manipulate the Contents or ByteRange values within the Signature object. The manipulation of these entries is reasoned by the fact that we either remove the signature value or the information stating which content is signed.
The attack seems trivial, but even very good implementations like Adobe Reader DC preventing all other attacks were susceptible against USF.

Incremental Saving Attack (ISA)

The Incremental Saving Attack (ISA) abuses a legitimate feature of the PDF specification, which allows to update a PDF file by appending the changes. The feature is used, for example, to store PDF annotations, or to add new pages while editing the file.

The main idea of the ISA is to use the same technique for changing elements, such as texts, or whole pages included in the signed PDF file to what the attacker desires.
In other words, an attacker can redefine the document's structure and content using the Body Updates part. The digital signature within the PDF file protects precisely the part of the file defined in the ByteRange. Since the incremental saving appends the Body Updates to the end of the file, it is not part of the defined ByteRange and thus not part of the signature's integrity protection. Summarized, the signature remains valid, while the Body Updates changed the displayed content.
This is not forbidden by the PDF specification, but the signature validation should indicate that the document has been altered after signing.

Signature Wrapping Attack (SWA)

Independently of the PDFs, the main idea behind Signature Wrapping Attacks is to force the verification logic to process different data than the application logic.

In PDF files, SWA targets the signature validation logic by relocating the originally signed content to a different position within the document and inserting new content at the allocated position. The starting point for the attack is the manipulation of the ByteRange value allowing to shift the signed content to different loctions within the file.

On a very technical level, the attacker uses a validly signed document (shown on the left side) and proceeds as follows:

Step 1 (optional): The attacker deletes the padded zero Bytes within the Contents parameter to increase the available space for injecting manipulated objects.
Step 2: The attacker defines a new /ByteRange [a b c* d] by manipulating the c value, which now points to the second signed part placed on a different position within the document.
Step 3: The attacker creates a new Xref table pointing to the new objects. It is essential that the byte offset of the newly inserted Xref table has the same byte offset as the previous Xref table. The position is not changeable since it is refer- enced by the signed Trailer. For this purpose, the attacker can add a padding block (e.g., using whitespaces) before the new Xref table to fill the unused space.
Step 4: The attacker injects malicious objects which are not protected by the signature. There are different injection points for these objects. They can be placed before or after the malicious Xref table. If Step 1 is not executed, it is only possible to place them after the malicious Xref table.
Step 5 (optional): Some PDF viewers need a Trailer after the manipulated Xref table, otherwise they cannot open the PDF file or detect the manipulation and display a warning message. Copying the last Trailer is sufficient to bypass this limitation.
Step 6: The attacker moves the signed content defined by c and d at byte offset c*. Optionally, the moved content can be encapsulated within a stream object. Noteworthy is the fact that the manipulated PDF file does not end with %%EOF after the endstream. The reason why some validators throw a warning that the file was manipulated after signing is because of an %%EOF after the signed one. To bypass this requirement, the PDF file is not correctly closed. However, it will be still processed by any viewer.

Evaluation

In our evaluation, we searched for desktop applications validating digitally signed PDF files. We analyzed the security of their signature validation process against our 3 attack classes. The 22 applications fulfill these requirements. We evaluated the latest versions of the applications on all supported platforms (Windows, MacOS, and Linux).

Authors of this Post

Vladislav Mladenov
Christian Mainka
Karsten Meyer zu Selhausen
Martin Grothe
Jörg Schwenk

Acknowledgements

Many thanks to the CERT-Bund team for the great support during the responsible disclosure.
We also want to acknowledge the teams which reacted to our report and fixed the vulnerable implementations.

IoT-Implant-Toolkit: A Framework For Implantation Attack Of IoT Devices

About IoT-Implant-Toolkit
IoT-Implant-Toolkit is a framework of useful tools for malware implantation research of IoT devices. It is a toolkit consisted of essential software tools on firmware modification, serial port debugging, software analysis and stable spy clients. With an easy-to-use and extensible shell-like environment, IoT-Implant-Toolkit is a one-stop-shop toolkit simplifies complex procedure of IoT malware implantation.

In MarvelTeamLab's research, they have succcessfully implanted Trojans in eight devices including smart speakers, cameras, driving recorders and mobile translators with IoT-Implant-Toolkit.

A demo GIF below:

IoT-Implant-Toolkit's Installation
Your must install ffmpeg and sox first:

For Debian-based distro users: sudo apt install sox ffmpeg
For Arch Linux-based user: sudo pacman -S sox ffmpeg

Then, open your Terminal and enter these commands:

Usage
Three commands supported:

list: list all plugins.
run: run a specific plugin with "run [plugin] [parameters]".
exit: to exit.

You might like these similar tools:

Download IoT-Implant-Toolkit

Blockchain Exploitation Labs - Part 3 Exploiting Integer Overflows And Underflows

In part 1 and 2 we covered re-entrancy and authorization attack scenarios within the Ethereum smart contract environment. In this blog we will cover integer attacks against blockchain decentralized applications (DAPs) coded in Solidity.

Integer Attack Explanation:

An integer overflow and underflow happens when a check on a value is used with an unsigned integer, which either adds or subtracts beyond the limits the variable can hold. If you remember back to your computer science class each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers.

If you go outside of the constraints of the number type you are using it may handle things in different ways such as an error condition or perhaps cutting the number off at the maximum or minimum value.

In the Solidity language for Ethereum when we reach values past what our variable can hold it in turn wraps back around to a number it understands. So for example if we have a variable that can only hold a 2 digit number when we hit 99 and go past it, we will end up with 00. Inversely if we had 00 and we subtracted 1 we would end up with 99.

Normally in your math class the following would be true:

99 + 1 = 100
00 - 1 = -1

In solidity with unsigned numbers the following is true:

99 + 1 = 00
00 - 1 = 99

So the issue lies with the assumption that a number will fail or provide a correct value in mathematical calculations when indeed it does not. So comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that does not check for safe values.

That comparison may very well be comparing the output of an over/under flowed value and be completely meaningless. The Require statement may return true, but not based on the actual intended mathematical value. This in turn will lead to an action performed which is beneficial to the attacker for example checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Lets go through a few examples.

Simple Example:

Lets say we have the following Require check as an example:
require(balance - withdraw_amount > 0) ;

Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously they don't have the money for this transaction correct?

This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above where we can hold 2 digits with an unsigned integer?

Let's do some math.
5 - 6 = 99

Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.

Because the following math returns true:
require(99 > 0)

Withdraw Function Vulnerable to an UnderFlow:

The below example snippet of code illustrates a withdraw function with an underflow vulnerability:

function withdraw(uint _amount){

    require(balances[msg.sender] - _amount > 0);
    msg.sender.transfer(_amount);
    balances[msg.sender] -= _amount;

}

In this example the require line checks that the balance is greater then 0 after subtracting the _amount but if the _amount is greater than the balance it will underflow to a value above 0 even though it should fail with a negative number as its true value.

require(balances[msg.sender] - _amount > 0);

It will then send the value of the _amount variable to the recipient without any further checks:

msg.sender.transfer(_amount);

Followed by possibly increasing the value of the senders account with an underflow condition even though it should have been reduced:

balances[msg.sender] -= _amount;

Depending how the Require check and transfer functions are coded the attacker may not lose any funds at all but be able to transfer out large sums of money to other accounts under his control simply by underflowing the require statements which checks the account balance before transferring funds each time.

Transfer Function Vulnerable to a Batch Overflow:

Overflow conditions often happen in situations where you are sending a batched amount of values to recipients. If you are doing an airdrop and have 200 users who are each receiving a large sum of tokens but you check the total sum of all users tokens against the total funds it may trigger an overflow. The logic would compare a smaller value to the total tokens and think you have enough to cover the transaction for example if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?

You have 10,000 tokens in your account
You are sending 200 users 499 tokens each
Your total sent is 200*499 or 99,800

The above scenario would fail as it should since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Lets do some more math and see how that changes the outcome.

You have 10,000 tokens in your account
You are sending 200 users 500 tokens each
Your total sent is 200*500 or 100,000
New total is actually 0

This new scenario produces a total that is actually 0 even though each users amount is 500 tokens which may cause issues if a require statement is not handled with safe functions which stop an overflow of a require statement.

Lets take our new numbers and plug them into the below code and see what happens:

1. uint total = _users.length * _tokens;
2. require(balances[msg.sender] >= total);
3. balances[msg.sender] = balances[msg.sender] -total;

4. for(uint i=0; i < users.length; i++){
5. balances[_users[i]] = balances[_users[i]] + _value;

Same statements substituting the variables for our scenarios values:

1. uint total = _200 * 500;
2. require(10,000 >= 0);
3. balances[msg.sender] = 10,000 - 0;

4. for(uint i=0; i < 500; i++){
5. balances[_recievers[i]] = balances[_recievers[i]] + 500;

Batch Overflow Code Explanation:

1: The total variable is 100,000 which becomes 0 due to the 5 digit limit overflow when a 6th digit is hit at 99,999 + 1 = 0. So total now becomes 0.

2: This line checks if the users balance is high enough to cover the total value to be sent which in this case is 0 so 10,000 is more then enough to cover a 0 total and this check passes due to the overflow.

3: This line deducts the total from the senders balance which does nothing since the total of 10,000 - 0 is 10,000. The sender has lost no funds.

4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 as this does not trigger an overflow condition. Thus sending out 100,000 tokens without reducing the senders balance or triggering an error due to lack of funds. Essentially creating tokens out of thin air.

In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.

Lab Follow Along Time:

We went through what might have been an overwhelming amount of concepts in this chapter regarding over/underflow scenarios now lets do an example lab in the video below to illustrate this point and get a little hands on experience reviewing, writing and exploiting smart contracts. Also note in the blockchain youtube playlist we cover the same concepts from above if you need to hear them rather then read them.

For this lab we will use the Remix browser environment with the current solidity version as of this writing 0.5.12. You can easily adjust the compiler version on Remix to this version as versions update and change frequently.
https://remix.ethereum.org/

Below is a video going through coding your own vulnerable smart contract, the video following that goes through exploiting the code you create and the videos prior to that cover the concepts we covered above:

Download Video Lab Example Code:

Download Sample Code:

CC Labs GitHub

//Underflow Example Code:

//Can you bypass the restriction?

//--------------------------------------------

pragma solidity ^0.5.12;

contract Underflow{
   mapping (address =>uint) balances;

   function contribute() public payable{
        balances[msg.sender] = msg.value;
   }

   function getBalance() view public returns (uint){
return balances[msg.sender];
   }

   function transfer(address _reciever, uint _value) public payable{
   require(balances[msg.sender] - _value >= 5);
   balances[msg.sender] = balances[msg.sender] - _value;

       balances[_reciever] = balances[_reciever] + _value;
   }

}

This next video walks through exploiting the code above, preferably hand coded by you into the remix environment. As the best way to learn is to code it yourself and understand each piece:

Conclusion:

We covered a lot of information at this point and the video series playlist associated with this blog series has additional information and walk throughs. Also other videos as always will be added to this playlist including fixing integer overflows in the code and attacking an actual live Decentralized Blockchain Application. So check out those videos as they are dropped and the current ones, sit back and watch and re-enforce the concepts you learned in this blog and in the previous lab. This is an example from a full set of labs as part of a more comprehensive exploitation course we have been working on.

Related news

S2 Dynamic Tracer And Decompiler For Gdb

Decompiling is very useful for understanding srtipped binaries, most dissasemblers like IDA or Hopper have a plugin for decompiling binaries, generating a c like pseudocode.

Static analysis, is very useful in most of cases, specially when the binary is not so big, or when you just have an address where to start to analyze. But some algorithms will be learned in less time by dynamic analysis like tracing or debugging.

In cookiemonsters team, we are working on several tracers with different focus, but all of them mix the concept of tracing and decompiling to generate human-readable traces.

S2 is my tracer & decompiler plugin for gdb, very useful for ctfs.

Some of the features are:

- signed/unsigned detecion
- conditional pseudocode (if)
- syscall resolution
- unroll bucles
- used registers values
- mem states
- strings
- logging

The code:

https://bitbucket.org/sha0coder/gdb_automatization/

Continue reading

Saturday, April 11, 2020

Grav-StuG Kickstarter Inbound!

Just 48 hours away from the launch of the Grav-Sug Kickstarter!

Wednesday, April 8, 2020

For The Glory Of... Austro-Hungary?

I picked up some Austro-Hungarian Aeronef cheap at the start of the year on eBay. My buddy Matt and I intend on playing some games with them. He has, in fact, procured the age old enemies of the Austro-Hungarians, the Japanese. We're likely going to bash a few rule sets together into something that's quick and fun.

I've got a few more things left to build (battleships, fixed wings and a carrier) but this is the lion's share of them. Just a simple base, wash and drybrush. I've got a few details left to do but I don't think I'm going to go full orange Eldar on these.

Saturday, March 28, 2020

[KKB]Retro Dining Room

DOWNLOAD