Blockchain. Changing the attackers aim

I was sat with my early morning coffee the other day doing some research on blockchain technology as you do. I was thinking about the future of penetration testing and what us testers are likely to see in the future.

I started thinking about our brand damage testing. This is as close to a real attack on a company as you will get, where a client gives us an open scope, where we conduct phishing assessments, social engineering, internal red teaming and so on. It was the red teaming that I thought most about with regards to blockchain.

A new challenge for an attacker?

An attacker on an internal network will start with no insider information, they will have nothing and will try to compromise the network, usually the goal is Domain Admin and exfiltrating important data.

With a basic blockchain, there is no connection to a Domain Admin user due to its distributed nature. Therefore, when businesses start rolling out their own blockchains, gaining a Domain Admin is not going to be that useful if data for various departments is stored on the blockchain encrypted.

What one needs to remember is that blockchain is not just for transacting money, which Bitcoin was built for. The future of this technology will be based on solutions such as the Ethereum, NEO, LISK and other coded application orientated blockchains, which can run distributed code. For example:

In the above image, we can see a blockchain that is running an internal information web application.

In this example the blockchain starts by importing three sets of data HR, IT and C-Level. The next two blocks are adding data to these repositories. The data for this web application is stored on the blockchain, so that’s HR, C-Level and IT data, using API calls to the website to display this data.

This is my personal vision for the future, this makes the company data distributed, auditable and immutable. The machines below the blockchain in the image are the miners that process the data in the blockchain. You can imagine the miners as being many machines within the organisation- servers, employee laptops, desktops and so on.

To access the web application, a user will have to sign in with their blockchain wallet, which is essentially a private key. Once signed in, the user will have full access to all data which is linked to their wallet (account), for example a HR administrator will see HR data.

Keys to the kingdom

An attacker may well have escalated themselves to Domain Administrator, but in this new world there isn’t a whole lot of data an attacker is going to be able to get, as it is stored within the blockchain. So how do they get this data from the blockchain?

A user’s private key is the key to the kingdom.

When an attacker gains Domain or Local Administrator account privileges, they go hunting. The current non-blockchain approach is to hop from machine to machine to find data, or dump password hashes, but with blockchain  the time will be spent looking for Wallet keys.

It’s all well and good when a wallet key is found, but you can’t use it right off the bat (well, you can if the private key doesn’t have a set password). But let’s say it does have a password. That means the attacker will need to crack the private key password, so it’s time introduce our old friend, HashCat.

HashCat. Teaching an old friend new tricks

Using HashCat is nothing new, attackers have been using it to crack passwords for years. However, it now supports a variety of blockchain wallets to attempt cracking; including Litecoin, Bitcoin and Ethereum. There hash cracking numbers are:

Bitcoin/Litecoin – 11300

Ethereum – 15700

At this point lets imagine an attacker has managed to gain Domain Admin account, they know the data is stored in the blockchain so they’ve gone hunting for Wallet Keys and found one for Ethereum- because the company uses a modified internal Ethereum blockchain to run their web application.

To crack the private key, an attacker will need to make the private key usable by Hashcat, so the hash needs to comply with the HashCat cracking format. I came across a tool in JohnTheRipper to do this called ethereum2john.py. Cheers John!

Using this python script, you can feed the wallet into it and it will produce a hash:

NB: This is a fresh Ethereum wallet so don’t try cracking it!

Using Hashcat mode 15700 mentioned above, the cracking process can begin.

Once cracked, an attacker would have an account in which they can login to the web application and view the sensitive data, just as they would today with a Domain account looking through SMB shares.

Really, this is just an extra step from what an attacker would already do and what we as testers do on an engagement, using the same techniques-  password cracking and pivoting machines looking for data.

How about totally forgetting about Domain Administrator because of this? An attacker may only need to gain one user or a Local Administrator to aim for a user with full access to all data on the blockchain Web Application. That is as close as you will get to Domain Administrator for the Blockchain: however data separation should be in place!

Conclusions

It’s likely that what I have covered regarding internal information web applications, based on blockchain, will happen.

But it won’t just be web applications, I also expect to see:

• Networks of IoT equipment verified by the blockchain.
• Authentication mechanisms secured by blockchain.

We will likely even see business-to-business data transactions via blockchain e.g  one business sending another business analytical data and charging based on data sent. The immutable and auditable nature of the blockchain helps with this charging model.

There is a whole host of possibilities for this technology and I expect to start seeing companies selling generic internal solutions very soon. This is not only going to change a testers job, but also take an attackers aim in a slightly new direction using a range of new techniques, as mentioned in my previous blog.

What should we be doing?

To guard against attacks such as this, here are some points to think about in your design:

• Use a strong blockchain wallet encryption algorithm to make password cracking slow
• Ensure users create a complex password for their private key
• Users should create a different Wallet password to their corporate account password
• Permissions to directories where Wallet Keys are stored should be very strict
• Users should only be able to access the information needed for the job they do
• As always, use different local administrator passwords for all machines!