plan b-going to market

bob

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.

Continue reading

bob

Hi,

I am a hacker, and I have successfully gained access to your operating system.
I also have full access to your account.

I've been watching you for a few months now.

The fact is that your computer has been infected with malware through an adult site that you visited.
If you are not familiar with this, I will explain.
Trojan Virus gives me full access and control over a computer or other device.
This means that I can see everything on your screen, turn on the camera and microphone, but you do not know about it.
I also have access to all your contacts and all your correspondence.

Why did your antivirus not detect malware?
Answer: The malware I used is driver-based, I update its signatures every 4 hours. Hence your antivirus is unable to detect its presence.
I made a video showing how you satisfy yourself in the left half of the screen, and the right half shows the video you were watching at the time.

With one mouse click, I can send this video to all your emails and contacts on your social networks.
I can also make public all your e-mail correspondence and chat history on the messengers that you use.

If you don't want this to happen, transfer $950 in Bitcoin equivalent to my Bitcoin address (if you do not know how to do this, just search "buy bitcoin" on Google).

My Bitcoin address (BTC Wallet) is: 15NCWERN56DQNf4WiPLR2txgiEF2np5Q2g

After confirming your payment, I will delete the video immediately, and that's it. You will never hear from me again.
I will give you 50 hours (more than 2 days) to pay. I will get a notice, when you open this email, and the timer will start.
Filing a complaint somewhere does not make sense because this email cannot be tracked like my Bitcoin address.

I never make any mistakes.
If I find that you have shared this message with someone else, the video will be immediately distributed.

Best regards!

bob

Hackerhubb.blogspot.comMore information

bob

Last year we presented How to Spoof PDF Signatures. We showed three different attack classes. In cooperation with the CERT-Bund (BSI), we contacted the vendors of affected PDF applications to inform them about the vulnerabilities and to support them in developing countermeasures. Most vendors reacted promptly and closed the reported vulnerabilities promptly.

One of those three attack classes was Incremental Saving Attacks (ISA). The proposed countermeasures aimed to distinguish PDF objects appended to the file via updates into dangerous and non-dangerous. In other words, black and whitelisting approaches were used.

Naturally, this countermeasure succeeds as long as the PDF update contains evil objects. So we came up with the idea to attack PDFs with only non-dangerous updates. We achieve this by adding invisible, malicious content when creating the PDF document (before it is signed) and to reveal them after signing.

Today, we present Shadow Attacks! Our evaluation of 28 PDF applications reveals that 15 of them, including Adobe Acrobat and Foxit Reader, are vulnerable.

We responsibly disclosed all affected vendors. Together with the CERT-Bund (BSI), we supported the vendors in developing suitable countermeasures. The attacks are documented in CVE-2020-9592 and CVE-2020-9596.

Full results are available in our vulnerability report and on our website.

What are PDF signatures used for and what is the legal status?

PDFs can be secured against manipulations by using digital signatures. This feature enables use-cases such as signing contracts, agreements, payments, and invoices. Regulations like the eSign Act in the USA or the eIDAS regulation in Europe facilitate the acceptance of digitally signed documents by companies and governments. Asian and South American countries also accept digitally signed documents as an equivalent to manually signed paper documents. Adobe Cloud, a leading online service for signing PDF documents, provided 8 billion electronic and digital signature transactions in 2019. The same year, DocuSign processed 15 million documents each day.

What could a Simple Signing Process look like?
The process of digitally signing a contract involves multiple entities and can look as follows: The PDF contract is prepared by the collaborators. The collaborators can be lawyers, designers, typewriters, or members of different companies. Finally, the contract is digitally signed.

PDF Structure and Signature Basics

A PDF consists of three parts: Body, Xref table, and Trailer

The PDF is a platform-independent document format. It starts with a Header, to set the version, and is followed by three main parts, as depicted in the figure.
The first part defines the PDF Body. It contains different objects, which are identified by its object number. The most important object is the root object, which is called the Catalog. In the figure, the Catalog has the object identifier 1 0. The Catalog defines the whole PDF structure by linking to other objects in the Body. In the example given, the Catalog links to form object AcroForm, to some PDF MetaData, and to actual PDF Pages. The latter can reference multiple Page objects, which in turn reference, for example, the actual Content, Font, and Images.
The second part of the PDF is the Xref table. It contains references to the byte positions of all objects used in the PDF Body.
The third part is the Trailer. It consists of two further references: one to the byte position at which the Xref table starts, and another link to the identifier of the root object (1 0).

Incremental Updates and Digitally Signing a PDF

The content of a PDF may be updated for different reasons, for example, by adding review comments or by filling out PDF forms. From a technical perspective, it is possible to add this new content directly into the existing PDF Body and add new references in the Xref table. However, this is not the case according to the PDF specification. Changes to a PDF are implemented using Incremental Updates. An Incremental Update adds new objects into a new PDF Body, which is directly appended after the previous Trailer as shown in the figure to the right. To adequately address the new objects, a new Xref table and Trailer are also appended as well for each Incremental Update. Summarized, a PDF can have multiple Bodies, Xref tables, and Trailers, if Incremental Update is applied.

For protecting the integrity and the authenticity of a PDF, digital signatures can be applied. For this purpose, a Signature object is created and appended to the PDF by using Incremental Update. It is also possible to sign a PDF multiple times (e.g., a contract), resulting in multiple Incremental Updates. The Signature object contains all relevant information for validating the signature, such as the algorithms used and the signing certificate. Once a PDF containing a PDF Signature is opened, the viewer application automatically validates the signature and provides a warning if the content has been modified.

Shadow Attacks

The main idea of the attacks is that the attackers prepare a PDF document containing invisible content. Afterward, the document is sent to a signing entity like a person or a service which reviews the document, signs it and sends it back to the attackers. Despite the integrity protection provided by the digital signature, the attackers can make modifications to the document and change the visibility of the hidden content. Nevertheless, the manipulation is not detected. The digital signature remains valid. Finally, the attackers send the modified signed document to the victim. Although the document is altered, the signature validation is successful, but the victims see different content than the signing entity.

Do the Attacks match a Real-World Scenario?

Of course! In companies and authorities, relevant documents like contracts or agreements are often prepared by the employees who take care of most of the details and technicalities. The document is then signed by an authorized person after a careful review. Another scenario is the signing process of a document within a consortium. Usually, one participant creates the final version of the document, which is then signed by all consortium members. Considering the given examples, an employee or consortium member acting maliciously can hide invisible shadow content during the editing. Consequentially, this content will be signed later.

Additionally, multiple cloud signing services like Adobe Cloud, DocuSign, or Digital Signature Service exist. Among other functionalities, such services receive a document and sign it. This process can also be used also to sign shadow documents.

Different Attack Classes of Shadow Attacks

Shadow Attacks can be divided into the three attack classes Hide, Replace, and Hide-and-Replace, as shown in the figure below. Each class offers the possibility of taking a significant influence on the content of a signed PDF document. In the following, we describe the functionality of the individual classes in more detail.

Shadow Attack: Hide

The concept of this class of shadow attacks is to hide the content relevant for the victims behind a visible layer. For example, the attackers can hide the text "You are fired!" behind a full-page picture showing "Sign me to get the reward!". Once the attackers receive the signed document, they manipulate the document in such a way that the picture is no longer rendered by the viewer application. Hide attacks have two advantages from the attackers' perspective:

Many viewers show warnings if new visible content is added using an Incremental Update. However, they do not warn in most cases if content is removed.
The objects are still accessible within the PDF. In the example above, the text "You are fired!" can still be detected by a search function. This might be important if an online signing service is used and it reviews the document by searching for specific keywords. We identified two variants of this attack class.

Hiding Content via Page.
This attack variant uses an Incremental Update to create a new Page object. It contains all previously used objects except for the overlay, for example, the image. This attack variant is depicted on the left side of figure above.

Hiding Content via Xref.
If the viewer application does not accept changes to PDF structuring objects, such as Page, Pages, or Contents, the second attack variant can be applied. This variant directly affects the overlay object. The simplest method for this is to create an Incremental Update, which only updates the Xref table by setting the overlay object to free. However, making this change is interpreted as a dangerous in many viewers (e.g., Adobe) and an error or a warning is thrown. For this reason, we use another approach: we use the same object ID within the Incremental Update, but we define it as a different object type. For example, we change the overlay type Image to XML/Metadata.
When opening this manipulated document, the overlay is hidden because Metadata cannot be shown. Since adding Metadata to a signed PDF using Incremental Update is considered harmless, the signature remains valid.

Shadow Attack: Replace

In this attack class, specific content of the PDF document is to be exchanged. The first variant uses the visual properties of text fields for this purpose. The second variant is based on a fatal misconception that fonts cannot be used for manipulation purposes.
Replace via Overlay.
This attack targets an interactive feature in PDFs: interactive forms. Forms support different input masks (e.g., text fields, text areas, radio/selection buttons) where users dynamically enter new content and store it in the PDF document. The main idea of the attack is to create a form, which shows one value before (PDF1) and after signing (PDF2), as illustrated on the leftside in the figure below. After the attackers manipulate the PDF and create PDF3, different values are shown in the form (and can be seen on the right side of the figure below). The attack abuses a special property of PDF text fields. A text field can show two different values: the real field value and an overlay value which disappears as soon as the text field is selected. The real value of a form field is contained in an object key named /V. The content of the overlay element is defined within a /BBox object. The /BBox object is comparable to the hint labels known from HTML forms; for example, the hint username to indicate that the username should be entered into a specific login field. In contrast to HTML, in PDF there is no visual difference between the hint and the actual value.

In summary, we can say that this variant allows attackers to manipulate the contents of the text fields for the visible layer arbitrary. As shown in the figure above, this can be used, for example, to maliciously redirect a payment.

Replace via Overwrite.

The main idea of this variant is to append new objects to the signed document which are considered harmless but directly influence the presentation of the signed content. As shown in figure of the three attack classes, the attackers prepare a shadow document that defines a font and includes its description into the document. The font is used for the presentation of specific content. After the document is signed, the attackers append a new font description and overwrite the previous description. The definition of new fonts is considered harmless, because of that, the applications verifying the signature do not show any warning regarding the made changes. For instance, the (re)definition of fonts does not change the content directly. However, it influences the view of the displayed content and makes number or character swapping possible.

Shadow Attack: Hide-and-Replace

In this attack class, the attackers create a shadow PDF document that is sent to the signers. The PDF document contains a hidden description of another document with different content. Since the signers cannot detect the hidden (malicious) content, they sign the document. After signing, the attackers receive the document and only append a new Xref table and Trailer. Within the Xref table, only one change takes place: the reference to the document Catalog (or any other hidden object), which now points to the shadow document.

In fact, the document contains two independent content paths. One path to show the signer harmless content, and one path with malicious content that replaces the first content after it is signed and activated by the attackers. The figure above visually illustrates the described relationships once again.
This attack variant is the most powerful one since the content of the entire document can be exchanged, including text content, forms, fonts, and annotations. The attackers can build a complete shadow document influencing the presentation of each page and each object.

Evaluation

Overall, 15 out of 28 PDF viewing applications were vulnerable to at least one presented attack. Surprisingly, for 11 PDF viewers, all three attack classes were successful. The Table shows that some applications have limited vulnerabilities. These applications respond to any type of Incremental Update with a post-signature modification note, including modifications that are allowed due to the specification. We have evaluated the latest (at the time of evaluation) available versions of the applications on all supported desktop platforms: Windows, macOS, and Linux.

Evaluation results.

Authors of this Post

Simon Rohlmann
Christian Mainka
Vladislav Mladenov
Jörg Schwenk

Acknowledgments

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

Related links

plan b-going to market

Wednesday, May 31, 2023

Blockchain Exploitation Labs - Part 3 Exploiting Integer Overflows And Underflows

Integer Attack Explanation:

Simple Example:

Withdraw Function Vulnerable to an UnderFlow:

Transfer Function Vulnerable to a Batch Overflow:

Batch Overflow Code Explanation:

Lab Follow Along Time:

Download Video Lab Example Code:

Conclusion:

Continue reading

Your account is hacked. Your data is stolen. Learn how to regain access.

Hackerhubb.blogspot.com

Shadow Attacks: Hiding And Replacing Content In Signed PDFs

What are PDF signatures used for and what is the legal status?

PDF Structure and Signature Basics

Shadow Attacks

Do the Attacks match a Real-World Scenario?

Different Attack Classes of Shadow Attacks

Shadow Attack: Hide

Shadow Attack: Replace

Shadow Attack: Hide-and-Replace

Evaluation

Authors of this Post

Acknowledgments

Subscribe via email

Subscribe Now: Feed Icon

About us

Blog Archive

Our Current Projects

Welcome

FEEDJIT Live Traffic Feed

5:00 pm mixer

site visitors