Sunday, November 4, 2018

Blockchain Exploitation Labs - Part 1 Smart Contract Re-Entrancy

Why/What Blockchain Exploitation?

In this blog series we will analyze blockchain vulnerabilities and exploit them ourselves in various lab and development environments. If you would like to stay up to date on new posts follow and subscribe to the following:
Twitter: @ficti0n

As of late
I have been un-naturally obsessed with blockchains and crypto currency. With
that obsession comes the normal curiosity of “How do I hack this and steal all
the monies?”

However, as usual I could not find any actual walk thorough or solid examples of actually exploiting real code live. Just theory and half way explained examples.

That
question with labs is exactly what we are going to cover in this series, starting with
the topic title above of Re-Entrancy attacks which allow an attacker to siphon
out all of the money held within a smart contract, far beyond that of their own
contribution to the contract.

This will
be a lab based series and I will show you how to use demo the code within
various test environments and local environments in order to perform and
re-create each attacks for yourself.

Note: As usual this is live ongoing research and info will be released as it is coded and exploited.

If you are
bored of reading already and just want to watch videos for this info or are only here for the demos and labs check out the
first set of videos in the series at the link below and skip to the relevant
parts for you, otherwise lets get into it:

Background
Info:

This is a
bit of a harder topic to write about considering most of my audience are
hackers not Ethereum developers or blockchain architects. So you may not know
what a smart contract is nor how it is situated within the blockchain
development model. So I am going to cover a little bit of context to help with
understanding.I will cover the bare
minimum needed as an attacker.

A Standard
Application Model:

In client
server we generally have the following:

Front End
- what the user sees (HTML Etc)

Server
Side - code that handles business logic

Back End -
Your database for example MySQL

A Decentralized Application Model:

Now with a
Decentralized applications (DAPP) on the blockchain you have similar
front end server side technology however

Smart contracts are
your access into the blockchain.

Your smart contract
is kind of like an API

Essentially DAPPs
are Ethereum enabled applications using smart contracts as an API to the blockchain
data ledger

DAPPs can be banking
applications, wallets, video games etc.

A blockchain is a trust-less peer to peer decentralized database or ledger

The back-end is distributed across thousands of nodes in its entirety on each node.
Meaning every single node has a Full “database” of information called a
ledger.The second difference is that
this ledger is immutable, meaning once data goes in, data cannot
be changed. This will come into play later in this discussion about smart
contracts.

Consensus:

The
blockchain of these decentralized ledgers is synchronized by a consensus mechanism you may be familiar with
called “mining” or more accurately, proof of work or optionally Proof of stake.

Proof of stake is simply staking large sums of coins which are at risk of loss if one
were to perform a malicious action while helping to perform consensus of data.

Much like proof of stake, proof of work(mining) validates hashing calculations to come to a consensus but instead of loss of coins there is a loss of energy, which costs money, without reward if malicious actions were to take place.

Each block
contains transactions from the transaction pool combined with a nonce that
meets the difficulty requirements.Once
a block is found and accepted it places them on the blockchain in which more then half of the network must reach a consensus on.

The point
is that no central authority controls the nodes or can shut them down. Instead
there is consensus from all nodes using either proof of work or proof of stake.
They are spread across the whole world leaving a single centralized jurisdiction as an impossibility.

Things to
Note:

First
Note: Immutability

So, the
thing to note is that our smart contracts are located on the blockchain

And
the blockchain is immutable

This means
an Agile development model is not going to work once a contract is deployed.

This means
that updates to contracts is next to impossible

All
you can really do is create
a kill-switch or fail safe functions to disable and execute some actions if
something goes wrong before going permanently dormant.

If you don’t include
a kill switch the contract is open and available and you can't remove it

Second
Note:Code Is Open Source

Smart
Contracts are generally open source

Which
means people like ourselves are manually bug hunting smart contracts and
running static analysis tools against smart contract code looking for bugs.

When
issues are found the only course of action is:

Kill the
current contract which stays on the blockchain

Then deploy a whole new version.

If there is no
killSwitch the contract will be available forever.

Now I know
what you're thinking, these things are ripe for exploitation.

And you would be
correct based on the 3rd note

Third
Note: Security in the development process is lacking

Many
contracts and projects do not even think about and SDLC.

They rarely add
penetration testing and vulnerability testing in the development stages if at
all

At best there is a
bug bounty before the release of their main-nets

Which usually get
hacked to hell and delayed because of it.

Things are
getting better but they are still behind the curve, as the technology is new
and blockchain mostly developers and marketers.Not hackers or security testers.

Forth Note:Potential Data Exposure via Future Broken Crypto

If sensitive data is
placed on the blockchain it is there forever

Which means that if
a cryptographic algorithm is broken anything which is
encrypted with that algorithm is now accessible

We all know that
algorithms are eventually broken!

So its always
advisable to keep sensitive data hashed for integrity on the blockchain but not actually stored on
the blockchain directly

Exploitation of Re-Entrancy Vulnerabilities:

With a bit
of the background out of the way let's get into the first attack in this
series.

Re-Entrancy
attacks allow an attacker to create a re-cursive loop within a contract by
having the contract call the target function rather than a single request from
auser. Instead the request comes from
the attackers contract which does not let the target contracts execution
complete until the tasks intended by the attacker are complete. Usually this
task will be draining the money out of the contract until all of the money for
every user is in the attackers account.

Example
Scenario:

Let's say
that you are using a bank and you have deposited 100 dollars into your bank
account.Now when you withdraw your
money from your bank account the bank account first sends you 100 dollars
before updating your account balance.

Well what
if when you received your 100 dollars, it was sent to malicious code that
called the withdraw function again not lettingthe initial target deduct your balance ?

With this
scenario you could then request 100 dollars, then request 100 again and you now
have 200 dollars sent to you from the bank. But 50% of that money is not yours.
It's from the whole collection of money that the bank is tasked to maintain for
its accounts.

Ok that's
pretty cool, but what if that was in a re-cursive loop that did not BREAK until
all accounts at the bank were empty?

That is
Re-Entrancy in a nutshell.So let's
look at some code.

Example
Target Code:

function withdraw(uint
withdrawAmount) public returns (uint) {

1.require(withdrawAmount <=
balances[msg.sender]);

2.require(msg.sender.call.value(withdrawAmount)());

3.balances[msg.sender] -=
withdrawAmount;

4.return balances[msg.sender];

}

Line 1:
Checks that you are only withdrawing the amount you have in your account or
sends back an error.

Line 2:
Sends your requested amount to the address the requested that withdrawal.

Line 3:
Deducts the amount you withdrew from your account from your total balance.

Line 4.
Simply returns your current balance.

Ok this
all seems logical.. however the issue is in Line 2 - Line 3.The balance is being sent back to you before
the balance is deducted. So if you were to call this from a piece of code which
just accepts anything which is sent to it, but then re-calls the withdraw
function you have a problem as it never gets to Line 3 which deducts the
balance from your total. This means that Line 1 will always have enough money
to keep withdrawing.

Let's take
a look at how we would do that:

Example
Attacking Code:

function attack() public payable {

1.bankAddress.withdraw(amount);

}

2.function () public payable {

3.if (address(bankAddress).balance
>= amount) {

4.bankAddress.withdraw(amount);

}

}

Line 1:
This function is calling the banks withdraw function with an amount less than
the total in your account

Line 2:
This second function is something called a fallback function. This function is
used to accept payments that come into the contract when no function is
specified. You will notice this function does not have a name but is set to
payable.

Line
3:This line is checking that the target
accounts balance is greater than the amount being withdrawn.

Line
4:Then again calling the withdraw
function to continue the loop which will in turn be sent back to the fallback
function and repeat lines over and over until the target contracts balance is
less than the amount being requested.

Review the diagram above which shows the code paths between the target and attacking code. During
this whole process the first code example from the withdraw function is only
ever getting to lines 1-2 until the bank is drained of money. It never actually
deducts your requested amount until the end when the full contract balance is lower then your withdraw amount. At this point it's too late and there is no
money left in the contract.

Setting up
a Lab Environment and coding your Attack:

Hopefully
that all made sense. If you watch the videos associated with this blog you will
see it all in action.We will now analyze code of a simple smart contract banking application. We will interface with this contract via our own smart contract we code manually and turn into an exploit to take advantage of the vulnerability.

Coding your Exploit and Interfacing with a Contract Programmatically:

The rest of this
blog will continue in the video below where we will manually code an interface to a full smart contract and write an exploit to take advantage of a Re-Entrency Vulnerability:

Conclusion:

In this smart contract exploit writing intro we showed a vulnerability that allowed for re entry to a contract in a recursive loop. We then manually created an exploit to take advantage of the vulnerability. This is just the beginning, as this series progresses you will see other types of vulnerabilities and have the ability to code and exploit them yourself. On this journey through the decentralized world you will learn how to code and craft exploits in solidity using various development environments and test nets.