Connect with us

Ethereum News

Blochainbandit stole $54 million of Ethereum by guessing weak keys

Someone has been quietly pilfering Ethereum (ETH) cryptocurrency worth millions of dollars without anyone noticing or, apparently, caring. The discovery was made by researchers at Independent Security Evaluators (ISE) who decided to search Ethereum’s blockchain for evidence of a surprisingly simple weakness that might allow criminals to divert funds from user wallets. Wallets should be…

Blochainbandit stole $54 million of Ethereum by guessing weak keys

Someone has been quietly pilfering Ethereum (ETH) cryptocurrency worth millions of dollars without anyone noticing or, apparently, caring.

The discovery was made by researchers at Independent Security Evaluators (ISE) who decided to search Ethereum’s blockchain for evidence of a surprisingly simple weakness that might allow criminals to divert funds from user wallets.

Wallets should be protected by a randomly-generated 256-bit private key, which puts the probability of their discovery at around 1 in 2256 ­­- an unimaginably vast number.

Using a computer capable of generating 100 trillion keys per second, brute forcing such an address would take so long ISE researcher Adrian Bednarek compares it to tossing grain of sand on a beach and asking someone to find it.

That’s the theory of key generation. But the problem is how the principle appears to have been implemented by fallible software.

What if that key had accidentally been generated with a value of 1? It sounds highly unlikely, however, Bednarek’s hunch that this might have happened turned out to be correct. There had once been an incredibly weak Ethereum private key corresponding to this value, as well as many other trivial equivalents.

Querying this with Etherscan.io, which records transactions, Bednarek discovered that this key identified a wallet that had received 592 transactions, the currency from which had immediately been emptied as soon as it was received.

Expanding the same principle to look for other simple keys amidst 34 billion addresses, he discovered 732 responsible for 49,060 transactions dating back to 2015.

“Blockchainbandit”

All had been emptied, around a dozen to a single address that appeared to belong to an individual or group dubbed the “blockchainbandit” which had worked out how to exploit the weakness. Says Bednarek in his video explanation:

There is a guy who was going around siphoning money from some of the keys we had access to. It’s statistically improbable he’d have guessed those keys by chance.

After falls in the value of Ethereum, today these would be worth around $7.4 million although at January 2018’s Ethereum peak it would have been over $54 million.

As intriguing as this discovery sounds – blockchain wallets are being preyed on by nearly invisible thieves – the point here is how such a phenomenon was made possible in the first place.

ISE’s researchers aren’t certain but suggest several possibilities, starting with simple coding errors that cause very weak private keys (i.e. single-number values) to be generated by accident.

Another possibility were keys generated by blockchain ‘brainwallet’ software from weak passphrases. Explains Bendarek:

Let’s say you use the passphrase abc123 to generate a private key. Another person who uses abc123 will get the same private key.

Incredibly, some wallets were even allowing people to create private keys simply by leaving passphrase fields empty and hitting the return key.

One way to undo past errors (if not return stolen currency) would be an Ethereum hard fork of the type that happened in 2016 after the infamous attack on DAO that led to the loss of $50 million.

Another would be to scan cryptographic algorithms for key generation errors, something the research suggests has not been happening.

As impressive as the ISE research is, the shame is that it happened after the damage was done. It’s not big news that blockchains have flaws but finding ones that could lead to millions of dollars of theft surely shouldn’t be left to chance discovery.

Source

Continue Reading
Advertisement
Loading...
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Ethereum News

Microsoft’s Power Platform improvements include blockchain and more

Microsoft announced a bunch of features coming to its Power Platform at its Build 2019 developer conference today. A new Ethereum connector will be available for PowerApps and Flow, with the announcement that blockchain is coming to the Power Platform. It will allow users to deploy, create, interact with, and respond to different events using…

Microsoft’s Power Platform improvements include blockchain and more

Microsoft announced a bunch of features coming to its Power Platform at its Build 2019 developer conference today. A new Ethereum connector will be available for PowerApps and Flow, with the announcement that blockchain is coming to the Power Platform. It will allow users to deploy, create, interact with, and respond to different events using a “low-code approach”. It’s available in public preview now.

The PowerApps Component Framework will allow developers to build components for apps that are reusable. It’s already in public preview for model-driven apps and will be available later this year for canvas apps. There are also new Visual Studio extensions for this that are in private preview.

The PowerApps embedding SDK does exactly what it sounds like, allowing developers to embed their PowerApps app into an existing UI. It also lets you embed the PowerApps maker experience into an app. The SDK is currently in public preview.

There are new quality checkers for PowerApps, such as App Checker and Solution Checker. The former will find errors, performance issues, and accessibility guidance, while the latter checks up on all of the related components. They’re generally available now.

There’s a new Unified Lifecycle Management for PowerApps and Flow, allowing your apps to “be included in the same enterprise-grade solution system that underpins Dynamics 365 applications”. This will be generally available in June.

Microsoft also announced that support for Python is coming to Power BI. You can use Python visuals in Power BI reports, and you can use scripts in your dataset. This is now generally available.

There’s a new Azure services connector for both PowerApps and Flow, letting users view all of their Azure services in one place. This is also generally available.

Finally, there are some improvements to Power BI. Power BI Embedded lets you use AI with a drag-and-drop experience, and Power BI Template allows you to have ISVs offer analytics to customers that use Power BI. The former will be generally available in June, while the latter is available now.

Source

Continue Reading

Ethereum News

Ethereum Smart Contracts Exploitation Using Right-To-Left Override Character

We demonstrate how Right-To-Left-Override tricks can be applied to deceive users and auditors of smart contracts, and discuss mitigation techniques. During the 2019 RSA conference in San Francisco, we presented our work with XM Cyber, analyzing potential security quirks and oddities in Solidity, a popular language for writing Ethereum smart contracts. One of the demonstrated…

Ethereum Smart Contracts Exploitation Using Right-To-Left Override Character

We demonstrate how Right-To-Left-Override tricks can be applied to deceive users and auditors of smart contracts, and discuss mitigation techniques.

During the 2019 RSA conference in San Francisco, we presented our work with XM Cyber, analyzing potential security quirks and oddities in Solidity, a popular language for writing Ethereum smart contracts. One of the demonstrated techniques utilized a Right-To-Left-Override character to modify the behavior of a smart contract covertly. By inserting this character at strategic locations within a block of code, a malicious entity is able to change the underlying functionality of the code while misleading a naive reader.

We are pleased to announce that we have added automatic detection of this technique to Slither so that a warning will be displayed when auditing smart contracts.

For those of you who did not attend our presentation, following is a quick overview:

Right-To-Left-Override character is a special Unicode character (U+202E) that allows the use of right-to-left (RTL) characters inside a text that is normally rendered left-to-right (LTR).

When the text renderer notices the RTLO character, it switches its rendering mode to display all following characters as RTL.

RTLO has been used in phishing attacks for years, where attackers inserted the RTLO character in the middle of filenames of attachments to try and deceive users into thinking the attachment is safe.

For example, if we rename a malicious .exe file to: “Testu202excod.exe” then on the one hand the system will treat it as an executable file, but on the other it will be displayed as “Testexe.docx”, which appears to be a legitimate docx file.


Test[u202e]xcod.exe is an exe file with word-like icon

Test[u202e]xcod.exe is an exe file with word-like icon

In smart contracts, code is the source of trust, and it is fundamental to the trust model that anyone will be able to verify and audit the source code of a smart contract.

In fact, unlike in the enterprise security world, there are no compensating controls of any kind, as the axiom is that the source code is more trustworthy than any other mechanism. Therefore, if you are capable of abusing the mechanisms used to understand and analyze the code of the smart contracts, you will have defeated the security stack in its entirety.

We were able to adapt the RTLO trick to the ecosystem of smart contracts, and defeat the “trust in code” concept.

Let’s take a look at a simple example:

contract GuessTheNumber
{
    uint _secretNumber;
    address payable _owner;
    event success(string);
    event wrongNumber(string);

    constructor(uint secretNumber) payable public
    {
        require(secretNumber <= 10);
        _secretNumber = secretNumber;
        _owner = msg.sender;    
    }

    function getValue() view public returns (uint)
    {
        return address(this).balance;
    }

    function guess(uint n) payable public
    {
        require(msg.value == 1 ether);

        uint p = address(this).balance;
        checkAndTransferPrize(n , p,msg.sender);
    }

    function checkAndTransferPrize(uint p, uint n, address payable guesser) internal returns(bool)
    {
        if(n == _secretNumber)
        {
            guesser.transfer(p);
            emit success("You guessed the correct number!");
        }
        else
        {
            emit wrongNumber("You've made an incorrect guess!");
        }
    }

    function kill() public
    {
        require(msg.sender == _owner);
        selfdestruct(_owner);
    }
}

This is a straight-forward implementation of a “guess the number” game. The game master instantiates the contract with a secret number in the range of 1 to 10, and locks in a prize. Players can try to “guess” the secret number by invoking the “guess()” function, costing them 1 ETH. If their guess is correct, they expect to be paid the entire value of the contract.

Let’s assume that we have created an instance of the GuessTheNumber contract where the secret number is 3 and the prize is 11 ETH. Our claim is that this game is unwinnable.

The problem lies with that line:

checkAndTransferPrize(n , p,msg.sender);

By inserting a RTLO character right after the “the prize” comment, we are able to reverse the order of parameters passed to checkAndTransferPrize() so that n (the guessed number) is the first parameter and p (the prize) is the second.

gif-of-line-with-rtlo-being-typed.gif

If we remove the RTLO and LTRO characters hidden in the text we will get:

checkAndTransferPrize(n , p,msg.sender);

Then, because the prize is always larger than 10, and the secret number is smaller or equal to 10, the game is unwinnable by definition.

function checkAndTransferPrize(uint p, uint n, address payable guesser) internal returns(bool)
    {
        if(n == _secretNumber)

This is of course, one simple example of how this technique can be exploited, but due to its generic nature, it can be used in a variety of malicious ways.

As of March 2019, no source code verification or auditing tool was successful at alerting to this type of attack. The following is a screenshot from etherscan confirming our malicious code is valid:

etherscan-source-code-is-verified.png

In addition, here’s an audit report from Slither, a popular static analysis tool for Solidity:


No warnings regarding the RTLO character

No warnings regarding the RTLO character

Albeit simple in nature, this technique has potentially devastating results as it can completely alter the business logic behind a contract and is not a common issue for developers or auditors to look out for.

In a recent real world scenario, we were contracted to identify potential security flaws in the workflow of a smart contract development team, intent on open sourcing their platform. We demonstrated how easy it was to deceive the development team using this technique to approve and merge a malicious pull request created by us. This pull request used the RTLO technique and introduced an exploitable vulnerability to one of the main contracts, that would have enabled an attacker to fully drain the contract.

Due to the severity of the findings and the potential negative effect on the community, we have decided to enhance the capabilities of Slither so that it will automatically report a contract as suspicious if:

  • It contains a RTLO character
  • It contains any character which is not part of the ASCII table

These mitigations have been made available as of Slither version 0.6.3.

We have also documented this technique in the SWC Registry.

As a final word, if you write software to present smart contract code, we encourage you to alert viewers to the existence of such characters to avoid abuse.

Source

Continue Reading

Crypto Live Prices

  • USD
  • EUR
  • GPB
  • AUD
  • JPY
Advertisement
Loading...
Advertisement
Advertisement

Trending

Copyright © 2018 Crypto141.com