Liga Athenas: junho 2023

Clayton Alves Conrado

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

Youtube: https://www.youtube.com/c/ConsoleCowboys
URL: http://cclabs.io
http://consolecowboys.com

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 a user. 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 letting the 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.

Download the target code from the following link:

https://github.com/cclabsInc/BlockChainExploitation

Then lets open up an online ethereum development platform at the following link where we will begin analyzing and exploiting smart contracts in real time in the video below:

https://remix.ethereum.org

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.

Welcome back to the Linux Command Line Hackery series, this is Part-V of the series. Today we are going to learn how to monitor and control processes on our Linux box, so wrap your sleeves up and let's get started.

Command: ps
Syntax: ps [options]
Description: ps displays information about the currently running processes. Some of the common flags of ps are described briefly below
Flags:
-A or -e -> select all processes
-a -> select all processes except both session leaders and processes not associated with a terminal.
T -> select all processes associated with current terminal
-u <username or id> -> select all processes of a given user or userlist

Open up a terminal and type ps:

ps

what you'll see is a list of processes currently running in your terminal. One important thing to notice in the output is what's called as PID which stands for process ID. It is the number that uniquely identifies a process. Just keep that PID concept in mind we'll use it soon.

OK I know that's not really what you want to see rather you want to see all the processes that are currently running on your box. Don't worry we have flags to rescue, in order to see all the processes you can use the -e flag like this:

ps -e

Boom! you get a long list of processes currently running on your machine (don't stare at me like that, you asked and I gave you that). If you want to see processes of a particular user you can type the following command in your terminal:

ps -u bob

here "bob" is a username. This command will list all processes of the user with effective user name of bob.

You can do a full-format listing of the processes using the -f flag like this:

ps -fu bob

But the output of the ps command is a snapshot not really a live preview of what is going on in your box. I know your next question is going to be something like this, Isn't there a command in Linux that gives me a live updating information of the processes? Yes, there is a command called top that we'll learn about next.

Command: top
Syntax: top [options]
Description: top gives a dynamic real-time view of a running system. That is, it gives the up-to-date information about all the processes running on your Linux box (sounds fun!). Besides giving information about current processes and threads top also provides a brief system summary.

To start top just type this command:

top

and you'll get a nice and cute looking ugly display :). Well what the heck is going on here you might ask, right? What you get is information about what is going on with your computer. To see what more can you do with top just type <h> within the program window and you'll be given list of options that you can play with.

OK looking at what processes are going on in your box is cool but what if you want to terminate (or close) a process, is there a command line utility for that? Yes, there is and that's what we are going to look at next.

Command: kill
Syntax: kill [options] <pid> [...]
Description: kill is used to send a signal to process which by default is a TERM signal meaning kill by default sends a signal of termination to process (Cruel guy). To list the available signals we can use the -l or -L flag of the kill command.

To simply terminate a process we provide kill command a PID (process ID) and it will send the TERM signal to the process. So to kill a process first we'll list the running processes and then we'll keep the PID of the process in mind that we want to terminate. After that we'll issue the kill command with the PID that we just found.

ps -ax
kill 1153

the above command will send a TERM signal to the process whose PID is 1153, as simple as that.

We can also use our already learned skills to refine the output of ps command. Say we have a xterm terminal running on our box and we want to terminate it. By using ps command all alone we'll get a long listing of all processes running on our box. But we can limit the output of ps command to just those processes that we're interested in by piping ps command with the grep command like this:

ps -ax | grep xterm

wow! that's amazing, we're able to pull out only those results from the ps command that contained xterm in them. Isn't that a cool trick? But what is that vertical bar ( | ) doing in the middle, you may be thinking, right? Remember we learned about the input and output re-directors previously, the vertical bar (pipe in geeky terms) is another re-director whose task is to redirect the output of one command as input to another command. Here the pipe redirects the output of ps -ax command as input to grep command and of-course from the previous article you know that grep is used to search for a PATTERN in the given input. That means the above command searches for the xterm word in the output of ps -ax command and then displays just those lines of ps -ax command which contain xterm. Now get that PID and kill that process.

That's it for today, try these commands up on your own box and remember practice is gonna make you master the Linux command line. :)

Continue reading

Clayton Alves Conrado

In this tutorial series I'm going to walk you through the damn vulnerable web application (DVWA) which is damn vulnerable. Its main goal according to the creators is "to aid security professionals to test thier skills and tools in a legal environment, help web developers better understand the process of securing web applications and to aid both students & teachers to learn about web application security in a controlled class room environment."

I am going to install DVWA in docker so the prerequisite for this tutorial will be an installation of docker (Docker is not the only way to install DVWA but if you have docker already installed then it may be the easiest way to install DVWA).

To install DVWA in docker run your docker deamon if it's not running already and open a terminal or powershell and type:

docker rum --rm -it -p 8080:80 vulnerables/web-dvwa

It will take some time to pull the image from docker hub depending on your internet speed and after it is complete it will start the dvwa application. In the command we have mapped the image instance's port 80 to our hosts port 8080 so we should be able to access the web application from our host at http://localhost:8080

Now open your favorite web browser and go to http://localhost:8080
You should be prompted with a login screen like this:

login with these creds:
username: admin
password: password

After login you'll see a database setup page since this is our first run. Click on Create / Reset Database button at the bottom. It will setup database and redirect you to login page. Now login again and you'll see a welcome page.

Now click on DVWA Security link at the bottom of the page navigation and make sure the security level is set to Low. If it is not click on the dropdown, select Low and then click submit.

Now our setup is complete, so lets try a simple SQL attack to get a taste of whats about to come.

Click on SQL Injection in navigation menu.
You'll be presented with a small form which accepts User ID.
Enter a single quote (') in the User ID input field and click Submit.
You'll see an SQL error like this:

From the error message we can determine that the server has a MariaDB database and we can see the point of injection.
Since there are many quotes we are not able to determine the exact location of our injection. Lets add some text after our single quote to see exactly where our injection point is.
Now I am going to enter 'khan in the User ID field and click Submit.

Now we can see exactly where the point of injection is. Determining the point of injection is very important for a successful SQL injection and is sometimes very hard too, though it might not be that much useful here in this exercise.

Now lets try the very basic SQL Injection attack.
In the User ID field enter ' or 1=1-- - and click Submit.

We will explain what is going on here in the next article.

References:-
1. DVWA Official Website: http://www.dvwa.co.uk/

More information

segunda-feira, 5 de junho de 2023

Blockchain Exploitation Labs - Part 1 Smart Contract Re-Entrancy