Category Archives: blockchain

MobileGo (MGO) Is Up More Than 40% Since Thanksgiving

The last few weeks have been an extremely challenging time for crypto enthusiasts.  Major coins like Bitcoin (BTC) and Ethereum (ETH) have been demolished while many smaller alternative coins have done even worse.  Fortunately, there are still a few bright spots left in the market that traders may want to turn their attention toward.  One […]

The post MobileGo (MGO) Is Up More Than 40% Since Thanksgiving appeared first on Hacked: Hacking Finance.

Trail of Bits Blog: 10 Rules for the Secure Use of Cryptocurrency Hardware Wallets

Earlier this year, the Web3 Foundation (W3F) commissioned Trail of Bits for a security review and assessment of the risks in storing cryptocurrency. Everyone who owns cryptocurrency — from large institutions to individual enthusiasts — shares the W3F’s concerns. In service to the broader community, the W3F encouraged us to publish our recommendations for the secure use of hardware wallets: the small tamper-resistant peripherals that enable users to securely create and protect cryptocurrency accounts.

Whether your cryptocurrency holdings amount to a few Satoshis or a small fortune, you will find this post useful.

44917824762_dc1fa21afd_k

Today’s hardware wallets require diligent security procedures (Image credit: Gareth Halfacree)

The Advent of Hardware Wallets

In the early days of cryptocurrency, users simply generated their payment addresses (in cryptographic terms, their public/private key pairs) using the client software on a standard PC. Unfortunately, once cryptocurrency became a hot commodity, securely storing an account private key on a general-purpose computer — using a “software wallet” — became a liability. Software wallet files could be lost or deleted, and they were targeted for theft. Most users were unprepared for the hefty responsibility of securely and reliably storing their private keys. Partially, this drove the adoption of custodial storage services (such as at cryptocurrency exchanges).

Years of massive, unpunished thefts from these services convinced many users that they could never trust a third party with their cryptocurrency holdings the same way that they might trust a regulated bank holding fiat currency. So, in the past couple of years, hardware wallets have gained popularity as useful tools for protecting cryptocurrency accounts without relying on a custodial service.

A Foolproof Solution?

Hardware wallets are a kind of consumer-grade Hardware Security Module (HSM), with a similar purpose: a device that embodies a tamper-resistant vault, inside of which the user’s cryptographic identity (in this case, a cryptocurrency account) can be created and used without the private key ever leaving the device. Fundamentally, a hardware wallet only needs to take a transaction created on a host computer, sign it to make it valid, and output the signed transaction for the host computer to publish to the blockchain.

In practice, it’s not so simple. Users must properly initialize their wallets. Sometimes the devices have firmware updates. Then there’s the matter of recovery codes (also known as the BIP39 recovery phrase or seed words). Hardware wallets are a huge improvement over storing private keys on a sheet of paper in a fire safe, or in a directory on a laptop, but hardware wallets still carry risks. Users need to take some safety precautions. In the words of Bruce Schneier, “Security is a process, not a product.

10 Rules for the Secure Use of Cryptocurrency Hardware Wallets

1: Purchase the device from a trusted source, preferably direct from the vendor, new and unopened

Avoid any unnecessary supply-chain risk. Buying a device directly from the manufacturer (e.g., Ledger or Trezor) rather than from a reseller minimizes the risk of acquiring a counterfeit or a device tampered by a middleman. At least one malicious eBay reseller has reportedly devised clever schemes to defraud buyers even while selling them genuine and unopened products (see rule #3).

2: Never use a pre-initialized hardware wallet

If a user accepts a pre-initialized hardware wallet, they are putting their cryptocurrency into a wallet that is potentially just a copy of a wallet controlled by an attacker. Ensure that you (and only you) properly initialize your hardware wallet before use. Follow the initialization instructions from your hardware wallet vendor’s website (for example, the instructions for a Ledger brand wallet; instructions for a Trezor wallet).

IMG_4723

The kind of prompt you want to see, new out of the box (Ledger Nano S pictured)

3: Never use a pre-selected set of recovery words, only ones generated on-device

Never accept pre-selected recovery words. Always initialize a hardware wallet from a clean slate with on-device generation of new random recovery words. Anyone that knows the recovery words has complete control over the wallet, the ability to watch it for activity, and the ability to steal all of its coins. Effectively, the words are the secret key.

In December 2017, a hardware wallet reseller reportedly packaged a counterfeit scratch-off card in the box with each device delivered to their customers. The scratch-off card revealed a list of recovery words, and the card instructed the buyer to set up their device using a recovery step, rather than initializing it to securely generate a new set of words. This was a clever scam to trick users into using a pre-configured wallet (see rule #2).

fake-ledger-scam-768x1151 (source Reddit)

Beware reseller frauds like this one: official-looking pre-selected recovery words (Image credit: Ledger, Reddit user ‘moodyrocket’)

4: Prefer a device that is able to provide an attestation of its integrity

While resetting or initializing a device ought to be sufficient, there is hypothetically still a risk of buying a counterfeit or tampered hardware wallet. Before you buy one, confirm that you’ll be able to verify the provenance, authenticity, or integrity of the new hardware wallet. Look for software provided by the device maker that can interrogate a Secure Element on the device and provide an attestation of the device’s integrity. Follow the verification instructions from the vendor of your wallet (for example, Ledger’s instructions to use secure element attestation to check device integrity). There are, however, still gaps in the attestation capabilities of today’s wallets. Users ought to continue to demand better and more complete attestation.

5: Test your recovery words

Data protection 101 is “always test your backup”: in this case, your backup is the set of recovery words. Using a spare hardware wallet device, use the recorded recovery words to initialize the test wallet. Eliminate any doubt that the recorded words can successfully recover the original wallet’s state. After testing the correctness of the recovery words, reset/wipe this test device. Do not use a general-purpose computer or software wallet to verify the recovery words. Follow the instructions from your vendor for performing a recovery dry-run to test your seed words (the steps for Trezor wallet users and the steps for Ledger users).

6: Protect your recovery words separately and equally to the hardware wallet. Do not take a picture of them. Do not type them into anything.

Write the recovery words by hand — do not type them into a computer or photograph them to be printed — and then laminate the paper (preferably archival-quality acid-free paper for long-term storage). Store it in an opaque tamper-evident sealed envelope (example) for assurance that it has not been viewed without authorization. Remember that the device’s PIN code is no protection against an attacker with physical access if the recovery words are stored alongside the device. Do not store them together.

IMG_4726

Write the words down, but don’t take a photo like this one!

7: Verify the software you use to communicate with the hardware wallet; understand that a backdoored desktop UI is part of your threat model

Hardware wallets rely on desktop software for initiating transactions, updating the hardware wallet’s firmware, and other sensitive operations. Users of cryptocurrency software should demand reproducible builds and code-signed executables to prevent tampering by an attacker post-installation. The advantage of code-signing, relative to manual verification with a tool like GPG, is that code signatures are automatically verified by the operating system on every launch of the application, whereas manual verification is typically only performed once, if at all. Even verifiable software, though, can still be subverted at runtime. Recognize that general-purpose computing devices are exposed to potentially risky data from untrusted sources on a routine basis.

8: Consider using a high assurance workstation, even with a hardware wallet

By dedicating a workstation to the single task of operating the hardware wallet, it can be locked down to a greater degree because it is not used for day-to-day tasks, nor exposed to as many potential sources of compromise. Consider operating your hardware wallet only from an immutable host PC configuration. This workstation would be offline only, and dedicated to the task of transaction creation and signing using the hardware wallet. First, lock down the system’s firmware configuration (e.g., restrict boot devices, disable network boot, etc.) to ensure the integrity of the boot process. Then, the boot media can be protected either by Secure Boot using a TPM-backed encrypted SSD / hard drive, or — for true immutability — by burning and verifying a trusted OS image onto a write-once DVD-R media and storing the DVD-R in a tamper-evident bag alongside the hardware wallet.

9: Consider a M-of-N multi-signature wallet with independently stored devices

Multi-signature” refers to requiring more than one key to authorize a transaction. This is a fantastic protection against a single point-of-failure. Consider creating a multi-signature wallet with keys generated and kept in hardware wallets stored in physically separate locations. Note that if the devices will be in the custody of different individuals, carefully consider how to coordinate and make decisions to spend from the wallet. For added paranoia, the hardware wallets could be of different device brands. Then, even in the unlikely case that an employee at one of the hardware wallet manufacturers were to have successfully backdoored their devices, they would still only control one of the keys in your multi-signature wallet.

10: Consider manually verifying the generation of a new multi-signature address

Related to rules #7 and #8, note that multi-signature wallets are created by “joining” several private key-holders into a single address defined by a script. In the case of Bitcoin, this is called a P2SH address (“pay-to-script hash”). This part of the address creation is done in a the desktop software UI using public keys, and not on the hardware wallet. If a compromised workstation provides the script basis during the generation of a new P2SH address, then the attacker may be able to join or control the multi-sig wallet. For example, attacker-controlled or -subverted desktop software could secretly turn a 2-of-3 wallet into a 2-of-5 wallet with two additional public keys inserted by the attacker. Remember, a hardware wallet does not entirely preclude the need to secure the host that interfaces with it.

More Secure, More Usable Solutions Still Needed

This discussion of risks and recommendations in regards to cryptocurrency hardware wallets illustrates the challenges for the broader security industry in attempting to design other kinds of fixed-function devices for private key protection. For instance, U2F tokens and Secure Enclaves.

For well over a decade, security researchers have promoted the goal of “usable security.” Usable security is simply the idea that secure computing should be easy to do right, and hard to do wrong. Compare the usability of a modern secure messaging client, for example, with the cumbersome and error-prone key management required to use GPG. Getting usability right is the difference between protecting a few thousand technologists and protecting tens of millions of regular users.

Avoid complacency. Demand safer, better designed devices that aren’t prone to traps and mistakes. The best hardware wallet should be a little bit boring! We hope that in the future, safe and usable hardware wallets will be a commodity device that we can take for granted.

Until then, we will continue doing our part to build security awareness independently and in collaboration with organizations like the W3F. If you work for a company that creates hardware wallets, we welcome you to contact us for help protecting your users.









Trail of Bits Blog

10 Rules for the Secure Use of Cryptocurrency Hardware Wallets

Earlier this year, the Web3 Foundation (W3F) commissioned Trail of Bits for a security review and assessment of the risks in storing cryptocurrency. Everyone who owns cryptocurrency — from large institutions to individual enthusiasts — shares the W3F’s concerns. In service to the broader community, the W3F encouraged us to publish our recommendations for the secure use of hardware wallets: the small tamper-resistant peripherals that enable users to securely create and protect cryptocurrency accounts.

Whether your cryptocurrency holdings amount to a few Satoshis or a small fortune, you will find this post useful.

44917824762_dc1fa21afd_k

Today’s hardware wallets require diligent security procedures (Image credit: Gareth Halfacree)

The Advent of Hardware Wallets

In the early days of cryptocurrency, users simply generated their payment addresses (in cryptographic terms, their public/private key pairs) using the client software on a standard PC. Unfortunately, once cryptocurrency became a hot commodity, securely storing an account private key on a general-purpose computer — using a “software wallet” — became a liability. Software wallet files could be lost or deleted, and they were targeted for theft. Most users were unprepared for the hefty responsibility of securely and reliably storing their private keys. Partially, this drove the adoption of custodial storage services (such as at cryptocurrency exchanges).

Years of massive, unpunished thefts from these services convinced many users that they could never trust a third party with their cryptocurrency holdings the same way that they might trust a regulated bank holding fiat currency. So, in the past couple of years, hardware wallets have gained popularity as useful tools for protecting cryptocurrency accounts without relying on a custodial service.

A Foolproof Solution?

Hardware wallets are a kind of consumer-grade Hardware Security Module (HSM), with a similar purpose: a device that embodies a tamper-resistant vault, inside of which the user’s cryptographic identity (in this case, a cryptocurrency account) can be created and used without the private key ever leaving the device. Fundamentally, a hardware wallet only needs to take a transaction created on a host computer, sign it to make it valid, and output the signed transaction for the host computer to publish to the blockchain.

In practice, it’s not so simple. Users must properly initialize their wallets. Sometimes the devices have firmware updates. Then there’s the matter of recovery codes (also known as the BIP39 recovery phrase or seed words). Hardware wallets are a huge improvement over storing private keys on a sheet of paper in a fire safe, or in a directory on a laptop, but hardware wallets still carry risks. Users need to take some safety precautions. In the words of Bruce Schneier, “Security is a process, not a product.

10 Rules for the Secure Use of Cryptocurrency Hardware Wallets

1: Purchase the device from a trusted source, preferably direct from the vendor, new and unopened

Avoid any unnecessary supply-chain risk. Buying a device directly from the manufacturer (e.g., Ledger or Trezor) rather than from a reseller minimizes the risk of acquiring a counterfeit or a device tampered by a middleman. At least one malicious eBay reseller has reportedly devised clever schemes to defraud buyers even while selling them genuine and unopened products (see rule #3).

2: Never use a pre-initialized hardware wallet

If a user accepts a pre-initialized hardware wallet, they are putting their cryptocurrency into a wallet that is potentially just a copy of a wallet controlled by an attacker. Ensure that you (and only you) properly initialize your hardware wallet before use. Follow the initialization instructions from your hardware wallet vendor’s website (for example, the instructions for a Ledger brand wallet; instructions for a Trezor wallet).

IMG_4723

The kind of prompt you want to see, new out of the box (Ledger Nano S pictured)

3: Never use a pre-selected set of recovery words, only ones generated on-device

Never accept pre-selected recovery words. Always initialize a hardware wallet from a clean slate with on-device generation of new random recovery words. Anyone that knows the recovery words has complete control over the wallet, the ability to watch it for activity, and the ability to steal all of its coins. Effectively, the words are the secret key.

In December 2017, a hardware wallet reseller reportedly packaged a counterfeit scratch-off card in the box with each device delivered to their customers. The scratch-off card revealed a list of recovery words, and the card instructed the buyer to set up their device using a recovery step, rather than initializing it to securely generate a new set of words. This was a clever scam to trick users into using a pre-configured wallet (see rule #2).

fake-ledger-scam-768x1151 (source Reddit)

Beware reseller frauds like this one: official-looking pre-selected recovery words (Image credit: Ledger, Reddit user ‘moodyrocket’)

4: Prefer a device that is able to provide an attestation of its integrity

While resetting or initializing a device ought to be sufficient, there is hypothetically still a risk of buying a counterfeit or tampered hardware wallet. Before you buy one, confirm that you’ll be able to verify the provenance, authenticity, or integrity of the new hardware wallet. Look for software provided by the device maker that can interrogate a Secure Element on the device and provide an attestation of the device’s integrity. Follow the verification instructions from the vendor of your wallet (for example, Ledger’s instructions to use secure element attestation to check device integrity). There are, however, still gaps in the attestation capabilities of today’s wallets. Users ought to continue to demand better and more complete attestation.

5: Test your recovery words

Data protection 101 is “always test your backup”: in this case, your backup is the set of recovery words. Using a spare hardware wallet device, use the recorded recovery words to initialize the test wallet. Eliminate any doubt that the recorded words can successfully recover the original wallet’s state. After testing the correctness of the recovery words, reset/wipe this test device. Do not use a general-purpose computer or software wallet to verify the recovery words. Follow the instructions from your vendor for performing a recovery dry-run to test your seed words (the steps for Trezor wallet users and the steps for Ledger users).

6: Protect your recovery words separately and equally to the hardware wallet. Do not take a picture of them. Do not type them into anything.

Write the recovery words by hand — do not type them into a computer or photograph them to be printed — and then laminate the paper (preferably archival-quality acid-free paper for long-term storage). Store it in an opaque tamper-evident sealed envelope (example) for assurance that it has not been viewed without authorization. Remember that the device’s PIN code is no protection against an attacker with physical access if the recovery words are stored alongside the device. Do not store them together.

IMG_4726

Write the words down, but don’t take a photo like this one!

7: Verify the software you use to communicate with the hardware wallet; understand that a backdoored desktop UI is part of your threat model

Hardware wallets rely on desktop software for initiating transactions, updating the hardware wallet’s firmware, and other sensitive operations. Users of cryptocurrency software should demand reproducible builds and code-signed executables to prevent tampering by an attacker post-installation. The advantage of code-signing, relative to manual verification with a tool like GPG, is that code signatures are automatically verified by the operating system on every launch of the application, whereas manual verification is typically only performed once, if at all. Even verifiable software, though, can still be subverted at runtime. Recognize that general-purpose computing devices are exposed to potentially risky data from untrusted sources on a routine basis.

8: Consider using a high assurance workstation, even with a hardware wallet

By dedicating a workstation to the single task of operating the hardware wallet, it can be locked down to a greater degree because it is not used for day-to-day tasks, nor exposed to as many potential sources of compromise. Consider operating your hardware wallet only from an immutable host PC configuration. This workstation would be offline only, and dedicated to the task of transaction creation and signing using the hardware wallet. First, lock down the system’s firmware configuration (e.g., restrict boot devices, disable network boot, etc.) to ensure the integrity of the boot process. Then, the boot media can be protected either by Secure Boot using a TPM-backed encrypted SSD / hard drive, or — for true immutability — by burning and verifying a trusted OS image onto a write-once DVD-R media and storing the DVD-R in a tamper-evident bag alongside the hardware wallet.

9: Consider a M-of-N multi-signature wallet with independently stored devices

Multi-signature” refers to requiring more than one key to authorize a transaction. This is a fantastic protection against a single point-of-failure. Consider creating a multi-signature wallet with keys generated and kept in hardware wallets stored in physically separate locations. Note that if the devices will be in the custody of different individuals, carefully consider how to coordinate and make decisions to spend from the wallet. For added paranoia, the hardware wallets could be of different device brands. Then, even in the unlikely case that an employee at one of the hardware wallet manufacturers were to have successfully backdoored their devices, they would still only control one of the keys in your multi-signature wallet.

10: Consider manually verifying the generation of a new multi-signature address

Related to rules #7 and #8, note that multi-signature wallets are created by “joining” several private key-holders into a single address defined by a script. In the case of Bitcoin, this is called a P2SH address (“pay-to-script hash”). This part of the address creation is done in a the desktop software UI using public keys, and not on the hardware wallet. If a compromised workstation provides the script basis during the generation of a new P2SH address, then the attacker may be able to join or control the multi-sig wallet. For example, attacker-controlled or -subverted desktop software could secretly turn a 2-of-3 wallet into a 2-of-5 wallet with two additional public keys inserted by the attacker. Remember, a hardware wallet does not entirely preclude the need to secure the host that interfaces with it.

More Secure, More Usable Solutions Still Needed

This discussion of risks and recommendations in regards to cryptocurrency hardware wallets illustrates the challenges for the broader security industry in attempting to design other kinds of fixed-function devices for private key protection. For instance, U2F tokens and Secure Enclaves.

For well over a decade, security researchers have promoted the goal of “usable security.” Usable security is simply the idea that secure computing should be easy to do right, and hard to do wrong. Compare the usability of a modern secure messaging client, for example, with the cumbersome and error-prone key management required to use GPG. Getting usability right is the difference between protecting a few thousand technologists and protecting tens of millions of regular users.

Avoid complacency. Demand safer, better designed devices that aren’t prone to traps and mistakes. The best hardware wallet should be a little bit boring! We hope that in the future, safe and usable hardware wallets will be a commodity device that we can take for granted.

Until then, we will continue doing our part to build security awareness independently and in collaboration with organizations like the W3F. If you work for a company that creates hardware wallets, we welcome you to contact us for help protecting your users.

Security Tokens and STOs: A New Financial Frontier

There were a lot of promises during the 2017 ICO boom. Brand new start-ups offering utility tokens that had no utility, on a blockchain that was not needed. 2018 was a wake-up call for the cryptocurrency community. An indication that the ICO status quo was not written in stone and that valid alternatives needed to […]

The post Security Tokens and STOs: A New Financial Frontier appeared first on Hacked: Hacking Finance.

As Bitcoin Selloff Intensifies, Overstock CEO Doubles Down on Blockchain

Bitcoin’s month of pain intensified on Sunday, as prices briefly fell below $3,500 for the first time since September 2017. The panic sale hit the market at a time when Lightning Network is registering record capacity and institutional investors are lining up to trade physically-backed bitcoin futures at the beginning of next year. Amid the apparent […]

The post As Bitcoin Selloff Intensifies, Overstock CEO Doubles Down on Blockchain appeared first on Hacked: Hacking Finance.

Blockchain and Real Estate: An Industry Overview

Blockchain is going to change nearly every industry under the sun, but the effect will not always be the same. The big strengths of blockchain technology are efficiency, security, and transparency, and each industry will be affected in a slightly different manner. Real estate is one example of an industry that presents a huge opportunity […]

The post Blockchain and Real Estate: An Industry Overview appeared first on Hacked: Hacking Finance.

Return of the Blockchain Security Empire Hacking

Remember last December’s Empire Hacking? The one where we dedicated the event to sharing the best information about blockchain and smart contract security? Let’s do that again, and let’s make it a tradition; a half-day mini conference focused exclusively on a single topic every December. On December 12, please join us at Buzzfeed’s NYC offices to hear 10 excellent speakers share their knowledge of blockchain security in an event that will assuredly expand your abilities.

Dinner will be served. We will congregate at The Headless Horseman afterwards to continue the conversation and for some holiday cheer.

Due the the nature of this event, we’ll be charging attendees $2.00 for entry. Only registered guests will be permitted to attend.

Reserve a spot while you can.

Talks will include:

Anatomy of an Unsafe Smart Contract Programming Language

This talk dissects Solidity: the most popular smart contract programming language. Various examples of its unsafe behavior are discussed, demonstrating that even an experienced, competent programmer can easily shoot themselves in the foot. These serve as a cautionary tale of how not to create a programming language and toolchain, particularly one that shall be trusted with hundreds of millions of dollars in cryptocurrency. The talk is concluded with a retrospective of how some of these issues could have been avoided, and what we can do to make smart contract development more secure moving forward.

Evan Sultanik is a security engineer from Trail of Bits.

Asset Insecurities: Evaluating Digital Asset Security Fundamentals

Spend a couple minutes learning about digital asset security ecosystem problems as faced at Coinbase scale. This will be a jaunt through insecure supply chain, the difference between a protocol white paper and the actual implementation, and a couple other things that’ll bite you if you’re not paying attention.

Shamiq herds cryptokitties, security engineers and developers at Coinbase as Head of Application Security. In his spare time, he loves to eat cheese and chocolate.

Designing the Gemini dollar: a regulated, upgradeable, transparent stablecoin

A regulated stablecoin requires important design decisions. How can you make your contracts upgradeable when many rely on them? How can you manage keys that protect the underlying assets? And how can you do this all completely transparently? In this talk, we explain the design decisions that went into the Gemini dollar, and compare and contrast with other possible implementations.

Brandon Arvanaghi is a security engineer at Gemini Trust.

Property testing with Echidna and Manticore for secure smart contracts

Property-based testing is an incredibly simple and powerful tool for bug discovery, but despite its efficacy, it’s almost unheard of in the smart contract development community. This talk will introduce the concept of property-based testing, discuss strategies for picking good properties and testing them thoroughly, then go into how to apply these ideas to smart contracts specifically. We’ll discuss the use of both Manticore and Echidna for testing, and look at real bugs these tools can find in production code.

JP Smith is a security engineer from Trail of Bits.

Contract upgrade risks and remediations

A popular trend in smart contract design is to promote the development of upgradable contracts. Existing techniques to upgrade contracts have flaws, increase the complexity of the contract significantly, and ultimately introduce bugs. We will detail our analysis of existing smart contract upgrade strategies, describe the weaknesses we have observed in practice, and provide recommendations for contracts that require upgrades.

Josselin Feist is a security engineer at Trail of Bits.

Failures in On-Chain Privacy

Many, including Satoshi, believed cryptocurrencies provided privacy for payments. In reality, cryptocurrency is Twitter for your bank account. Worse, the current set of decoy transaction–based approaches commonly believed to provide privacy—including coinjoin and cryptonote/Monero—provide fundamentally flawed privacy protections. Where did we go wrong? This talk covers how to critically evaluate the privacy provided by any proposed protocol for payment privacy. Through a series of thought experiments, it outlines three plausible attacks on existing decoy-based schemes. These issues show the unintuitive nature of privacy protections, as well as the need to both evaluate protocols in the context of real world threats, and use approaches with formal and peer reviewed privacy guarantees such as Zcash.

Ian Miers is a post-doctoral associate at Cornell Tech.

Secure Micropayment Protocols

Sending cryptocurrency micropayment transactions that must be confirmed on a blockchain is impractical today due to transaction fees that can exceed the value being sent. Instead, we can use micropayment protocols that only rely on the blockchain for settlement and disputes to minimize on-chain fees. In this talk, we will describe and compare different approaches to constructing secure micropayment protocols on top of Ethereum including probabilistic micropayments and payment channels. Furthermore, we will highlight the difficulties and considerations in implementing these types of protocols given the increased reliance on correct and timely client behavior to prevent the loss of funds.

Yondon Fu is a software engineer and researcher at Livepeer.

How To Buidl an Enterprise-Grade Mainnet Ethereum Client

The byzantine environment of the Ethereum mainnet is fraught with challenges for aspiring hackers seeking to publish a compatible client. This talk highlights the trials and tribulations of implementing a client capable of handily dispatching the adversarial events and actors of the sprawling P2P ecosystem that comprises the Ethereum blockchain’s world-wide compute network. The uniquely modular nature of the Pantheon codebase and it’s suitability for enterprise application will be treated in detail. The session will conclude with a brief sketch of the road ahead for Pantheon with an eye towards the Ethereum Enterprise Alliance and the forthcoming updates that comprise the broad strokes of the Ethereum 2.0 specification.

S. Matthew English is a PegaSys protocol engineer and Pantheon core dev.

Simple is hard: Making your awesome security thing usable

If the security assumptions of blockchain systems fail even a little, they provide very little value. They also have a high barrier to entry and are hard to use. But wait, people already don’t use security tools — how isn’t this the worst of all possible worlds? We’ll talk about some precedents from infosec history and how we might be able to avoid “Your elections are fine as long as you use The New PGP on The Blockchain” in favor of helping people build cool things that really do solve longstanding problems in novel ways.

Patrick Nielsen and Amber Baldet are founders of Clovyr.

We’re look forward to seeing you there!

Workshop: Smart-Contract Security Analysis (December 11)

On December 11th, the day prior to Empire Hacking, we’ll be hosting a security training for Ethereum smart contract developers.

In this day-long training, JP Smith will share how we conduct our security reviews; not just our tools or tricks, but the whole approach. In addition to that knowledge, we’ll share our school of thought regarding assessments. Far too often, we encounter the belief that audits deliver a list of bugs and, consequently, the ability to say “Our code has been audited!” (and therefore “Our code is safe!”). That’s just part of the picture. Audits should also deliver an assessment of total project risk, guidance on architectural and development lifecycle, and someone to talk to. That’s the framework attendees will come away with.

Register for the day-long training.

Trail of Bits @ Devcon IV Recap

We wanted to make up for missing the first three Devcons, so we participated in this year’s event through a number of talks, a panel, and two trainings. For those of you who couldn’t join us, we’ve summarized our contributions below. We hope to see you there next year.

Using Manticore and Symbolic Execution to Find Smart Contract Bugs

In this workshop, Josselin Feist showed how to use Manticore, our open-source symbolic execution engine. Manticore enables developers not only to discover bugs in their code immediately, but also to prove that their code works correctly. Josselin led 120 attendees through a variety of exercises with Manticore. Everyone left with hands-on formal methods that will help them ensure that their smart contracts follow their specifications.

Get the workshop’s slides and exercises

Blockchain Autopsies

In this lightning talk, Jay Little recovered and analyzed 30,000 self-destructed contracts, and identified possible attacks hidden among them. 2 million contracts have been created on Ethereum’s mainnet yet few holding any value have been destroyed. These high-signal transactions are difficult to find; many are not available to a fully synchronized Ethereum node. In order to achieve this feat, Jay created new tools that re-process blockchain ledger data, recreate contracts with state, and analyze suspect transactions using traces and heuristics.

Filtering deployment mistakes, DoS attacks, and spam to identify suspect self-destructs

Get Jay’s slides

Current State of Security

In this panel, Kevin Seagraves facilitated a discussion about Ethereum’s current security posture. What was the biggest change in Ethereum security in the last year? How is securing smart contracts different from traditional systems? How should we think about the utility of bug bounties? Hear what this panel of experts had to say:

Security Training

In this day-long training, JP shared how we conduct our security reviews; not just our tools or tricks, but the whole approach. In addition to that knowledge, we tried to impart our school of thought regarding assessments. Far too often, we encounter the belief that audits deliver a list of bugs and, consequently, the ability to say “Our code has been audited!” (and therefore “Our code is safe!”). That’s just part of the picture. Audits should also deliver an assessment of total project risk, guidance on architectural and development lifecycle, and someone to talk to.

We’re running the training again on December 11th in New York. Reserve yourself a seat.

Devcon Surprise

Instead of going to Devcon, Evan Sultanik stayed home and wrote an Ethereum client fuzzer. Etheno automatically seeks divergences among the world’s Ethereum clients, like the one that surfaced on Ropsten in October. Etheno automatically identified that same bug in two minutes.

We’re glad that we attended Devcon4, and look forward to participating more in future events.

How contract migration works

Smart contracts can be compromised: they can have bugs, the owner’s wallet can be stolen, or they can be trapped due to an incorrect setting. If you develop a smart contract for your business, you must be prepared to react to events such as these. In many cases, the only available solution is to deploy a new instance of the contract and migrate your data to it.

If you plan to develop an upgradable contract, a migration procedure will spare you the dangers of an upgradability mechanism.

Read this blog post for a detailed description of how contract migration works.

You need a contract migration capability

Even a bug-free contract can be hijacked with stolen private keys. The recent Bancor and KICKICO hacks showed that attackers can compromise smart contract wallets. In attacks like these, it may be impossible to fix the deployed smart contract, even if the contract has an upgradability mechanism. A new instance of the contract will need to be deployed and properly initialized to restore functionality to your users.

Therefore, all smart contract developers must integrate a migration procedure during the contract design phase and companies must be prepared to run the migration in case of compromise.

A migration has two steps:

  1. Recovering the data to migrate
  2. Writing the data to the new contract

Let’s walk through the details, costs and operational consequences.

How to perform the migration

Step 1: Data recovery

You need to read the data from a particular block on the blockchain. To recover from an incident (hack or failure), you need to use the block before the incident or filter the attacker’s actions.

If possible, pause your contract. It is more transparent for your users, and prevents attackers from taking advantage of users who are not aware of the migration.

The recovery of data will depend on your data structure.

For public variables of simple types (such as uint, or address), it is trivial to retrieve the value through their getters. For private variables, you can either rely on events or you can compute the offset in memory of the variable, then use the getStorageAt function to retrieve its value.

Arrays are easily recovered, too, since the number of elements is known. You can use the techniques described above.

The situation is a bit more complex for mappings. Keys of a mapping are not stored. You need to recover them to access the values. To simplify off-chain tracking, we recommend emitting events when a value is stored in a mapping.

For ERC20 token contracts, you can find the list of all the holders by tracking the addresses of the Transfer events. This process is difficult. We have prepared two options to help: in the first, you can scan the blockchain and retrieve the holders yourself; in the second, you can rely on the publicly available Google BigTable archive of the Ethereum blockchain.

If you are not familiar with the web3 API to extract information from the blockchain, you can use ethereum-etl, which provides a set of scripts to simplify the data extraction.

If you don’t have a synchronized blockchain, you can use the Google BigQuery API. Figure 1 shows how to collect all the addresses of a given token through BigQuery:

SELECT from_address FROM `bigquery-public-data.ethereum_blockchain.token_transfers` AS token_transfers WHERE token_transfers.token_address = 0x41424344
Union DISTINCT
SELECT to_address FROM `bigquery-public-data.ethereum_blockchain.token_transfers` AS token_transfers WHERE token_transfers.token_address = 0x41424344'

Figure 1: Using Google BigQuery to recover the addresses present in all Transfer events of the token at address 0x41424344

BigQuery provides access to the block number, so you can adapt this query to return the transactions up to a particular block.

Once your recover all the holder’s addresses, you can query the balanceOf function offline to recover the balance associated to each holder. Filter accounts with an empty balance.

Now that we know how to retrieve the data to be migrated, let’s write the data to the new contract.

Step 2: Data writing

Once you collect the data, you need to initiate your new contract.

For simple variables, you can set the values through the constructor of the contract.

The situation is slightly more complex and costly if your data cannot be held in a single transaction. Each transaction is included in a block, which limits the total amount of gas that can be used by its transactions (the so-called “GasLimit”). If the gas cost of a transaction approaches or exceeds this limit, miners won’t include it in a block. As a result, if you have a large amount of data to migrate, you must split the migration into several transactions.

The solution is to add an initialization state to your contract, where only the owner can change the state variables, and users can’t take any action.

For an ERC20 token, the process would take these steps:

  1. Deploy the contract in the initialization state,
  2. Migrate the balances,
  3. Move the contract’s state to production.

The initialization state can be implemented with a Pausable feature and a boolean indicating the initialization state.

To reduce the cost, the migration of the balances can be implemented with a batch transfer function that lets you set multiple accounts in a single transaction:

/**
* @dev Initiate the account of destinations[i] with values[i]. The function must only be called before
* any transfer of tokens (duringInitialization). The caller must check that destinations are unique addresses.
* For a large number of destinations, separate the balances initialization in different calls to batchTransfer.
* @param destinations List of addresses to set the values
* @param values List of values to set
*/
function batchTransfer(address[] destinations, uint256[] values) duringInitialization onlyOwner external{
require(destinations.length == values.length);

uint256 length = destinations.length;
uint i;

for(i=0; i < length; i++){
balances[destinations[i]] = values[i];
emit Transfer(0x0, destinations[i], values[i]);
}
}

Figure 2: An example of a batchTransfer function

Migration concerns

When migrating a contract, two major concerns arise:

  1. How much will the migration cost?
  2. What is the impact on exchanges?

Migration cost

The recovery of data is done off-chain and therefore is free. Ethereum-etl can be used locally. Google‘s BigQuery API offers sufficient free credit to cover its usage.

However, each transaction sent to the network and each byte stored by the new contract has a cost.

Using the batchTransfer function of Figure 2, the transfer of 200 accounts costs around 2.4M gas, which is $5.04 with an average gas price (10 Gwei) at the time of this article (use ETH Gas Station to recalculate this figure for today’s prices). Roughly speaking, you need $0.025 to migrate one balance.

If we look at the number of holders for the top five ERC20 tokens ranked by their market cap, we have:

Token Holders Cost of Migration
BNB 300,000 $7,500
VEN 45,000 $1,200
MKR 5,000 $125
OMG 660,000 $16,500
ZRX 60,000 $1,500

If you migrate additional information (such as the allowance), the cost will be higher. Even so, these amounts are low in comparison to the amount of money that these tokens represent, and the potential cost of a failed upgrade.

Exchanges

The deployment of a new contract may have operational consequences. For token-based contracts, it is important to collaborate with exchanges during a migration to be sure that the new contract will be listed and the previous one will be discarded.

Fortunately, previous token migration events (such as Augur, Vechain, and Tron), showed that exchanges are likely to cooperate.

Contract Migration versus Upgradable Contracts

In our previous blog post, we discussed a trend in smart contract design: the addition of an upgradability mechanism to the contract.

We saw several drawbacks to upgradeable contracts:

  • Detailed low-level expertise in EVM and Solidity is required. Delegatecall-based proxies requires the developer to master EVM and Solidity internals.
  • Increased complexity and code size. The contract is harder to review and is more likely to contain bugs and security issues.
  • Increased number of keys to handle. The contract will need multiple authorized users (owner, upgrader). The more authorized users, the larger the attack surface.
  • Increased gas cost of each transaction. The contract becomes less competitive than the same version without an upgrade mechanism.
  • They encourage solving problems after deployment. Developers tend to test and review contracts more thoroughly if they know that they can’t be updated easily.
  • They reduce users’ trust in the contract. Users need to trust the contract’s owner, which prevents a truly decentralized system.

A contract should have an upgradable mechanism only if there is a strong argument for it, such as:

  • The contract requires frequent updates. If the contract is meant to be modified on a regular basis, the cost of regular migration may be high enough to justify an upgradability mechanism.
  • The contract requires a fixed address. The migration of a contract necessitates the use of a new address, which may break interactions with third parties (such as with other contracts).

Contract migrations achieve the benefits of an upgrade with few of the downsides. The main advantage of an upgrade over a migration is a cheaper cost of the upgrade. However, this cost does not justify all the drawbacks.

Recommendations

Prepare a migration procedure prior to contract deployment.

Use events to facilitate data tracking.

If you go for an upgradable contract, you must also prepare a migration procedure, as your keys can be compromised, or your contract can suffer from incorrect and irreversible manipulation.

Smart contracts bring a new paradigm of development. Their immutable nature requires users to re-think the way they build applications and demands thorough design and development procedures.

Contact us if you need help in creating, verifying, or applying your migration procedure.

In the meantime, join our free Ethereum security office hours if you have any questions regarding the security of your contract.

Slither – a Solidity static analysis framework

Slither is the first open-source static analysis framework for Solidity. Slither is fast and precise; it can find real vulnerabilities in a few seconds without user intervention. It is highly customizable and provides a set of APIs to inspect and analyze Solidity code easily. We use it in all of our security reviews. Now you can integrate it into your code-review process.

We are open sourcing the core analysis engine of Slither. This core provides advanced static-analysis features, including an intermediate representation (SlithIR) with taint tracking capabilities on top of which complex analyses (“detectors”) can be built. We have built many detectors, including ones that detect reentrancy and suicidal contracts. We are open sourcing some as examples.

If you are a smart-contract developer, a security expert, or an academic researcher, then you will find Slither invaluable.

Built for continuous integration

Slither has a simple command line interface. To run all of its detectors on a Solidity file, this is all you need: $ slither contract.sol

You can integrate Slither into your development process without any configuration. Run it on each commit to check that you are not adding new bugs.

Helps automate security reviews

Slither provides an API to inspect Solidity code via custom scripts. We use this API to rapidly answer unique questions about the code we’re reviewing. We have used Slither to:

  • Identify code that can modify a variable’s value.
  • Isolate the conditional logic statements that are influenced by a particular variable’s value.
  • Find other functions that are transitively reachable as a result of a call to a particular function.

For example, the following script will show which function(s) in myContract write to the state variable myVar:

# function_writing.py
import sys
from slither.slither import Slither

if len(sys.argv) != 2:
print('python.py function_writing.py file.sol')
exit(-1)

# Init slither
slither = Slither(sys.argv[1])

# Get the contract
contract = slither.get_contract_from_name('myContract')

# Get the variable
myVar = contract.get_state_variable_from_name('myVar')

# Get the functions writing the variable
funcs_writing_myVar = contract.get_functions_writing_to_variable(myVar)

# Print the result
print('Functions that write to "myVar": {}'.format([f.name for f in funcs_writing_myVar]))

Figure 1: Slither API Example

Read the API documentation and the examples to start harnessing Slither.

Aids in understanding contracts

Slither comes with a set of predefined “printers” which show high-level information about the contract. We included four that work out-of-the-box to print essential security information: a contract summary, a function summary, a graph of inheritance, and an authorization overview.

1. Contract summary printer

Gives a quick summary of the contract, showing the functions and their visibility:

Figure 2: Contract Summary Printer

2. Function summary printer

Shows useful information for each function, such as the state variables read and written, or the functions called:

Figure 3: Function Summary Printer

3. Inheritance printer

Outputs a graph highlighting the inheritance dependencies of all the contracts:

Figure 3: Function Summary Printer

4. Authorization printer

Shows what a user with privileges can do on the contract:

Figure 4: Authorization Printer

See Slither’s documentation for information about adding your own printers.

A foundation for research

Slither uses its own intermediate representation, SlithIR, to build innovative vulnerability analyses on Solidity. It provides access to the CFG of the functions, the inheritance of the contracts, and lets you inspect Solidity expressions.

Many academic tools, such as Oyente or MAIAN, advanced the start of the art when they were released. However, each academic team had to invent their own framework, built for only the limited scope of their particular area of interest. Maintenance became a challenge quickly. In contrast, Slither is a generic framework. Because it’s capable of the widest possible range of security analyses, it is regularly maintained and used by our open source community.

If you are an academic researcher, don’t spend time and effort parsing and recovering information from smart contracts. Prototype your new innovations on top of Slither, complete your research sooner, and ensure it maintains its utility over time.

It’s easy to extend Slither’s capabilities with new detector plugins. Read the detector documentation to start writing your own.

Next steps

Slither can find real vulnerabilities in a few seconds with minimal or no user interaction. We use it on all of our Solidity security reviews. You should too!

Many of our ongoing projects will improve Slither, including:

  • API enhancements: Now that we have open sourced the core, we intend to provide the most effective static analysis framework possible.
  • More precise built-in analyses: We plan to make several new layers of information, such as value tracking, accessible to the API.
  • Toolchain integration: We plan to combine Slither with Manticore, Echidna, and Truffle to automate the triage of issues.

Questions about Slither’s API and its core framework? Join the Empire Hacking Slack. Need help integrating Slither into your development process? Want access to our full set of detectors? Contact us.

Introduction to Verifiable Delay Functions (VDFs)

Finding randomness on the blockchain is hard. A classic mistake developers make when trying to acquire a random value on-chain is to use quantities like future block hashes, block difficulty, or timestamps. The problem with these schemes is that they are vulnerable to manipulation by miners. For example, suppose we are trying to run an on-chain lottery where users guess whether the hash of the next block will be even or odd. A miner then could bet that the outcome is even, and if the next block they mine is odd, discard it. Here, tossing out the odd block slightly increases the miner’s probability of winning the lottery. There are many real-world examples of “randomness” being generated via block variables, but they all suffer from the unavoidable problem that it is computationally easy for observers to determine how choices they make will affect the randomness generated on-chain.

Another related problem is electing leaders and validators in proof of stake protocols. In this case it turns out that being able to influence or predict randomness allows a miner to affect when they will be chosen to mine a block. There are a wide variety of techniques for overcoming this issue, such as Ouroboros’s verifiable secret-sharing scheme. However, they all suffer from the same pitfall: a non-colluding honest majority must be present.

In both of the above scenarios it is easy for attackers to see how different inputs affect the result of a pseudorandom number generator. This led Boneh, et al. to define verifiable delay functions (VDF’s). VDF’s are functions that require a moderate amount of sequential computation to evaluate, but once a solution is found, it is easy for anyone to verify that it is correct. Think of VDF’s as a time delay imposed on the output of some pseudorandom generator. This delay prevents malicious actors from influencing the output of the pseudorandom generator, since all inputs will be finalized before anyone can finish computing the VDF.

When used for leader selection, VDF’s offer a substantial improvement over verifiable random functions. Instead of requiring a non-colluding honest majority, VDF-based leader selection only requires the presence of any honest participant. This added robustness is due to the fact that no amount of parallelism will speed up the VDF, and any non-malicious actor can easily verify anyone else’s claimed VDF output is accurate.

VDF Definitions

Given a delay time t, a verifiable delay function f must be both

  1. Sequential: anyone can compute f(x) in t sequential steps, but no adversary with a large number of processors can distinguish the output of f(x) from random in significantly fewer steps
  2. Efficiently verifiable: Given the output y, any observer can verify that y = f(x) in a short amount of time (specifically log(t)).

In other words, a VDF is a function which takes exponentially more time to compute (even on a highly parallel processor) than it does to verify on a single processor. Also, the probability of a verifier accepting a false VDF output must be extremely small (chosen by a security parameter λ during initialization). The condition that no one can distinguish the output of f(x) from random until the final result is reached is essential. Suppose we are running a lottery where users submit 16-bit integers and the winning number is determined by giving a seed to a VDF that takes 20 min to compute. If an adversary can learn 4 bits of the VDF output after only 1 min of VDF computation, then they might be able to alter their submission and boost their chance of success by a factor of 16!

Before jumping into VDF constructions, let’s examine why an “obvious” but incorrect approach to this problem fails. One such approach would be repeated hashing. If the computation of some hash function h takes t steps to compute, then using f = h(h(...h(x))) as a VDF would certainly satisfy the sequential requirement above. Indeed, it would be impossible to speed this computation up with parallelism since each application of the hash depends entirely on the output of the previous one. However, this does not satisfy the efficiently verifiable requirement of a VDF. Anyone trying to verify that f(x) = y would have to recompute the entire hash chain. We need the evaluation of our VDF to take exponentially more time to compute than to verify.

VDF Candidates

There are currently three candidate constructions that satisfy the VDF requirements. Each one has its own potential downsides. The first was outlined in the original VDF paper by Boneh, et al. and uses injective rational maps. However, evaluating this VDF requires a somewhat large amount of parallel processing, leading the authors to refer to it as a “weak VDF.” Later, Pietrzak and Wesolowski independently arrived at extremely similar constructions based on repeated squaring in groups of unknown order. At a high level, here’s how the Pietrzak scheme works.

  1. To set up the VDF, choose a time parameter T, a finite abelian group G of unknown order, and a hash function H from bytes to elements of G.
  2. Given an input x, let g = H(x) evaluate the VDF by computing y = g2T

The repeated squaring computation is not parallelizable and reveals nothing about the end result until the last squaring. These properties are both due to the fact that we do not know the order of G. That knowledge would allow attackers to use group theory based attacks to speed up the computation.

Now, suppose someone asserts that the output of the VDF is some number z (which may or may not be equal to y). This is equivalent to showing that z = v2(T/2) and v = g2(T/2). Since both of the previous equations have the same exponent, they can be verified simultaneously by checking a random linear combination, e.g., vr z = (gr v)2(T/2), for a random r in {1, … , 2λ}(where λ is the security parameter). More formally, the prover and verifier perform the following interactive proof scheme:

  1. The prover computes v = g2(T/2) and sends v to the verifier
  2. The verifier sends a random r in {1, … , 2l} to the prover
  3. Both the prover and verifier compute g1 = gr v and z1 = vr z
  4. The prover and verifier recursively prove that z1 = g12(T/2)

The above scheme can be made non-interactive using a technique called the Fiat-Shamir heuristic. Here, the prover generates a challenge r at each level of the recursion by hashing (G,g,z,T,v) and appending v to the proof. In this scenario the proof contains log2 T elements and requires approximately (1 + 2/√T) T.

Security Analysis of Pietrzak Scheme

The security of Pietrzak’s scheme relies on the the security of the low order assumption: it is computationally infeasible for an adversary to find an element of low order in the group being used by the VDF. To see why finding an element of low order breaks the scheme, first assume that a malicious prover Eve found some element m of small order d. Then Eve sends zm to the verifier (where z is the valid output). The invalid output will be accepted with probability 1/d since

  1. When computing the second step of the recursion, we will have the base element g1 = gr v, where v = g2T/2 m, and need to show that g1T/2 = vr(zm)
  2. The m term on the left hand side is mT/2
  3. The m term on the right hand side is mr+1
  4. Since m has order d, these two will be equal when r+1 = T/2 mod d, which happens with probability 1/d

To see a full proof of why the low order assumption is both necessary and sufficient to show Pietrzak’s scheme is sound, see Boneh’s survey of recent VDF constructions.

The security analysis assumes that one can easily generate a group of unknown order that satisfies the low order assumption. We will see below that there are not groups currently known to satisfy these constraints that are amenable to a trustless setup, i.e., a setup where there is no party who can subvert the VDF protocol.

For example, let’s try to use everyone’s favorite family of groups: the integers modulo the product of two large primes (RSA groups). These groups have unknown order, since finding the order requires factoring a large integer. However, they do not satisfy the low order assumption. Indeed, the element -1 is always of order 2. This situation can be remedied by taking the quotient of an RSA group G by the subgroup {1,-1}. In fact, if the modulus of G is a product of strong primes (primes such that p-1/ 2 is also prime), then after taking the aforementioned quotient there are no elements of low order other than 1.

This analysis implies that RSA groups are secure for Pietrzak’s VDF, but there’s a problem. To generate an RSA group, someone has to know the factorization of the modulus N. Devising a trustless RSA group selection protocol–-where no one knows the factorization of the modulus N–-is therefore an interesting and important open problem in this area.

Another avenue of work towards instantiating Pietrzak’s scheme involves using the class group of an imaginary quadratic number field. This family of groups does not suffer from the above issue where selection requires a trusted third party. Simply choosing a large negative prime (with several caveats) will generate a group whose order is computationally infeasible to determine even for the person who chose the prime. However, unlike RSA groups, the difficulty of finding low-order elements in class groups of quadratic number fields is not well studied and would require more investigation before any such scheme could be used.

State of VDFs and Open Problems

As mentioned in the previous section, both the Pietrzak and Wesolowski schemes rely on generating a group of unknown order. Doing so without a trusted party is difficult in the case of RSA groups, but class groups seem to be a somewhat promising avenue of work. Furthermore, the Wesolowski scheme assumes the existence of groups that satisfy something called the adaptive root assumption, which is not well studied in the mathematical literature. There are many other open problems in this area, including constructing quantum resistant VDFs, and the potential for ASICs to ruin the security guarantees of VDF constructions in practice.

As for industry adoption of VDF’s, several companies in the blockchain space are trying to use VDF’s for consensus algorithms. Chia, for example, uses the repeated squaring technique outlined above, and is currently running a competition for the fastest implementation of this scheme. The Ethereum Foundation also appears to be developing a pseudorandom number generator that combines RANDAO with VDF’s. While both are very exciting projects that will be hugely beneficial to the blockchain community, this remains a very young area of research. Take any claim of security with a grain of salt.

As Search Engines Blacklist Fewer Sites, Users More Vulnerable to Attack

Turns out, it’s a lot harder for a website to get blacklisted than one might think. A new study found that while the number of bot malware infected websites remained steady in Q2 of 2018, search engines like Google and Bing are only blacklisting 17 percent of infected websites they identify. The study analyzed more than six million websites with malware scanners to arrive at this figure, noting that there was also a six percent decrease in websites being blacklisted over the previous year.

Many internet users rely on these search engines to flag malicious websites and protect them as they surf the web, but this decline in blacklisting sites is leaving many users just one click away from a potential attack. This disregard of a spam attack kit on search engine results for these infected sites can lead to serious disruption, including a sharp decline in customer trust. Internet users need to be more vigilant than ever now that search engines are dropping the ball on blacklisting infected sites, especially considering that total malware went up to an all-time high in Q2, representing the second highest attack vector from 2017-2018, according to the recent McAfee Labs Threats Report.

Another unsettling finding from the report was that incidents of cryptojacking have doubled in Q2 as well, with cybercriminals continuing to carry out both new and traditional malware attacks. Cryptojacking, the method of hijacking a browser to mine cryptocurrency, saw quite a sizable resurgence in late 2017 and has continued to be a looming threat ever since. McAfee’s Blockchain Threat Report discovered that almost 30,000 websites host the Coinhive code for mining cryptocurrency with or without a user’s consent—and that’s just from non-obfuscated sites.

And then, of course, there are just certain search terms that are more dangerous and leave you more vulnerable to malware than others. For all of you pop culture aficionados, be careful which celebrities you digitally dig up gossip around. For the twelfth year in a row, McAfee researched famous individuals to assess their online risk and which search results could expose people to malicious sites, with this year’s Most Dangerous Celebrity to search for being “Orange is the New Black’s” Ruby Rose.

So, how can internet users protect themselves when searching for the knowledge they crave online, especially considering many of the most popular search engines simply aren’t blacklisting as many bot malware infected sites as they should be? Keep these tips in mind:

  • Turn on safe search settings. Most browsers and search engines have a safe search setting that filters out any inappropriate or malicious content from showing up in search results. Other popular websites like iTunes and YouTube have a safety mode to further protect users from potential harm.
  • Update your browsers consistently. A crucial security rule of thumb is always updating your browsers whenever an update is available, as security patches are usually included with each new version. If you tend to forget to update your browser, an easy hack is to just turn on the automatic update feature.
  • Be vigilant of suspicious-looking sites. It can be challenging to successfully identify malicious sites when you’re using search engines but trusting your gut when something doesn’t look right to you is a great way of playing it safe.
  • Check a website’s safety rating. There are online search tools available that will analyze a given URL in order to ascertain whether it’s a genuinely safe site to browse or a potentially malicious one infected with bot malware and other threats.
  • Browse with security protection. Utilizing solutions like McAfee WebAdvisor, which keeps you safe from threats while you search and browse the web, or McAfee Total Protection, a comprehensive security solution that protects devices against malware and other threats, will safeguard you without impacting your browsing performance or experience.

To keep abreast of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post As Search Engines Blacklist Fewer Sites, Users More Vulnerable to Attack appeared first on McAfee Blogs.

Ethereum security guidance for all

We came away from ETH Berlin with two overarching impressions: first, many developers were hungry for any guidance on security, and second; too few security firms were accessible.

When we began taking on blockchain security engagements in 2016, there were no tools engineered for the work. Useful documentation was hard to find and hidden among many bad recommendations.

We’re working to change that by: offering standing office hours, sharing our aggregation of the best Ethereum security references on the internet, and maintaining a list of contact information for bug reporting.

We want to support the community to produce more secure smart contracts and decentralized apps.

Ethereum security office hours

Once every other week, our engineers will host a one-hour video chat where we’ll take all comers and answer Ethereum security questions at no cost. We’ll help guide participants through using our suite of Ethereum security tools and reference the essential knowledge and resources that people need to know.

Office hours will be noon Eastern Standard Time (GMT-5) on the first and third Tuesdays of the month. Subscribe to our Ethereum Security Events calendar for notifications about new sessions. We’ll also post a sign up form on our Twitter and the Empire Hacking Slack one day ahead of time to help solicit for topics to cover.

Crowdsourced blockchain security contacts

It’s a little ironic, but most security researchers have struggled to report vulnerabilities. Sometimes, the reporting process itself puts unnecessary burden on the reporter. The interface may not support the reporter’s language. Or, as Project Zero’s Natalie Silvanovich recently shared, it may come down to legalities:

“When software vendors start [bug bounties], they often remove existing mechanisms for reporting vulnerabilities…” and “…without providing an alternative for vulnerability reporters who don’t agree or don’t want to participate in [a rewards] program for whatever reason.”

We routinely identify previously unknown flaws in smart contracts, decentralized applications, and blockchain software clients. In many cases, it has been difficult or impossible to track down contact information for anyone responsible. When that happens, we have to leave the vulnerability unreported and simply hope that no one malicious discovers it.

This is not ideal, so we decided to do something about it. We are crowdsourcing a directory of security contacts for blockchain companies. This directory, Blockchain Security Contacts, identifies the best way to contact an organization’s security team so that you can report vulnerabilities directly to those who can resolve them.

If you work on a security team at a blockchain company, please add yourself to the directory!

Security contact guidance

The directory is just the first step. Even with the best of intentions, many companies rush into bug bounties without fully thinking through the legal and operational ramifications. They need guidance for engaging with security researchers most effectively.

At a minimum, we recommend:

Ethereum security references

Over the course of our work in Blockchain security, we’ve curated the best community-maintained and open-source Ethereum security references on the internet. These are the references we rely on the most. They’re the most common resources that every team developing a decentralized application needs to know about, including:

  • Resources for secure development, CTFs & wargames, and even specific podcast episodes
  • Security tools for visualization, linting, bug finding, verification, and reversing
  • Pointers to related communities

This is a community resource we want to grow as the community does. We’re committed to keeping it up to date.

With that all said, please contact us if you’d like help securing your blockchain software.

‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues

As we look over some of the key issues from the newly released McAfee Labs Threats Report, we read terms such as voice assistant, blockchain, billing fraud, and cryptojacking. Although voice assistants fall in a different category, the other three are closely linked and driven by the goal of fast, profitable attacks that result in a quick return on a cybercriminal’s investment.

One of the most significant shifts we see is that cryptojacking is still on the rise, while traditional ransomware attacks—aka “shoot and pray they pay”—are decreasing. Ransomware attacks are becoming more targeted as actors conduct their research to pick likely victims, breach their networks, and launch the malware followed by a high-pressure demand to pay the ransom. Although the total number of ransomware samples has fallen for two quarters, one family continues to spawn new variants. The Scarab ransomware family, which entered the threat landscape in June 2017, developed a dozen new variants in Q2. These variants combined make up more than 50% of the total number of Scarab samples to date.

What spiked the movement, starting in fall 2017, toward cryptojacking? The first reason is the value of cryptocurrency. If attacker can steal Bitcoins, for example, from a victim’s system, that’s enough. If direct theft is not possible, why not mine coins using a large number of hijacked systems. There’s no need to pay for hardware, electricity, or CPU cycles; it’s an easy way for criminals to earn money. We once thought that CPUs in routers and video-recording devices were useless for mining, but default or missing passwords wipe away this view. If an attacker can hijack enough systems, mining in high volume can be profitable. Not only individuals struggle with protecting against these attacks; companies suffer from them as well.

Securing cloud environments can be a challenge. Building applications in the cloud with container technology is effective and fast, but we also need to create the right amount of security controls. We have seen breaches in which bad actors uploaded their own containers and added them to a company’s cloud environment—which started to mine cryptocurrency.

New technologies and improvements to current ones are great, but we need to find the balance of securing them appropriately. Who would guess to use an embedded voice assistant to hack a computer? Who looks for potential attack vectors in new technologies and starts a dialog with the industry? One of those is the McAfee Advanced Threat Research team, which provides most of the analysis behind our threats reports. With a mix of the world’s best researchers in their key areas, they take on the challenge of making the (cyber) world safer. From testing vulnerabilities in new technologies to examining malware and the techniques of nation-state campaigns, we responsibly disclose our research to organizations and the industry. We take what we learn from analyzing attacks to evaluate, adapt, and innovate to improve our technology.

The post ‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues appeared first on McAfee Blogs.

How the Rise of Cryptocurrencies Is Shaping the Cyber Crime Landscape: Blockchain Infrastructure Use

UPDATE (May 31, 2018): A section of the post on commonly used OpenNIC IPs has been removed to avoid any implication that the OpenNIC IPs are inherently malicious, which is not the case.

Introduction

Cyber criminals have always been attracted to cryptocurrencies because it provides a certain level of anonymity and can be easily monetized. This interest has increased in recent years, stemming far beyond the desire to simply use cryptocurrencies as a payment method for illicit tools and services. Many actors have also attempted to capitalize on the growing popularity and subsequent rising price of cryptocurrencies by conducting various operations aimed at them, such as malicious cryptocurrency mining, collection of cryptocurrency wallet credentials, extortion activity, and the targeting of cryptocurrency exchanges.

Coinciding with the rising interest in stealing cryptocurrencies, distributed ledger technology (DLT), the technology that underpins cryptocurrencies, has also provided cyber criminals with a unique means of hosting their malicious content. This blog covers the growing trend of cyber criminals using blockchain domains for malicious infrastructure.

Blockchain Infrastructure Use

Traditionally, cyber criminals have used various methods to obfuscate malicious infrastructure that they use to host additional payloads, store stolen data, and/or function as command and control (C2) servers. Traditional methods include using bulletproof hosting, fast-flux, Tor infrastructure, and/or domain generation algorithms (DGAs) to help obfuscate the malicious infrastructure. While we expect cyber criminals to continue to use these techniques for the foreseeable future, another trend is emerging: the use of blockchain infrastructure.

Underground Interest in Blockchain Infrastructure

FireEye iSIGHT Intelligence has identified eCrime actor interest in cryptocurrency infrastructure-related topics dating back to at least 2009 within underground communities. While searches for certain keywords fail to provide context, the frequency of specific words, such as blockchain, Namecoin, and .bit, show a sharp increase in conversations surrounding these topics beginning in 2015 (Figure 1).


Figure 1: Underground keyword mentions

Namecoin Domains

Namecoin is a cryptocurrency based on the Bitcoin code that is used to register and manage domain names with the top-level domain (TLD) .bit. Everyone who registers a Namecoin domain is essentially their own domain registrar; however, domain registration is not associated with an individual's name or address. Rather, domain ownership is based on the unique encrypted hash of each user. This essentially creates the same anonymous system as Bitcoin for internet infrastructure, in which users are only known through their cryptographic identity. Figure 2 illustrates the Namecoin domain name generation process.


Figure 2: Namecoin domain creation process

As Namecoin is decentralized, with no central authority managing the network, domains registered with Namecoin are resistant to being hijacked or shut down. These factors, coupled with the comparative anonymity, make Namecoin an increasingly attractive option for cyber criminals in need of supporting infrastructure for their malicious operations.

Navigating to Namecoin Domains

Domains registered with Namecoin use the TLD .bit, and are not managed by standard DNS providers. Consequently, a client will be unable to establish a connection to these blockchain domains unless additional configurations are made. According to the Namecoin wiki, individuals can take one of the steps shown in Figure 3 to browse .bit domains.


Figure 3: Options for navigating to Namecoin domains outlined on Namecoin wiki

These options are not ideal for cyber criminals, as downloading the entire blockchain onto an infected host would require significant space and bandwidth, and routing their malicious traffic through an unknown third party could result in their traffic being blocked by the resolver. As a result, many have configured their malware to query their own privately managed Namecoin-compatible OpenNIC DNS (Figure 4), or to query other compatible servers they've purchased through underground infrastructure offerings. Bulletproof hosting providers, such as Group 4, have capitalized on the increased demand for .bit domains by adding support to allow malicious actors to query compatible servers.


Figure 4: Blockchain domain support advertised on OpenNIC website

Underground Advertisements for Namecoin Support

The following underground advertisements relating to the use of .bit domains have been observed by researchers over the past several years. These posts range from actors offering .bit compatible modules or configuration updates for popular banking Trojans to .bit infrastructure offerings.

Sample Advertisement #1

Figure 5 shows an advertisement, observed in late 2015, posted by the actor "wachdog" in a popular Russian-speaking marketplace. The actor advertised a small utility (10 KB in size) that is compatible with both Windows and Android operating systems, and would allow for the communication to and from .bit domains.

Advertisement Translated Text:

The code is written in C+ for WinAPI or Java for Android. It can be used for small stealth applications to access .bit domains.

The registration of new domain costs 0.02 NMC, update of a record - 0.005 NMC.

So, the price for domain registration and update will be approximately 0.0072$ and 0.0018$.

The code works in all Windows starting from XP, it doesn't require additional libraries, admin privileges, it doesn't download a lot of data. The size of compiled code is 10 KB. It's easy to write it in asm, paskal, c#, java etc. It also works for Android (all versions).

You should download the Namecoin wallet, credit it with the minimum amount of NMC and register your own domain using the wallet. IP of C&C can be linked to the domain also using the wallet (one of many, everything works as for normal DNS). Create a build of your software locked to .bit domain. In case the IP of your server is listed, just change the DNS record and assign your domain a new IP for just for 0.005 NMC. No need in new rebuild or registration of new domains. .bit domain cannot be taken, botnet cannot be stolen.

Price:

Technology + code in C: $300 USD

Technology + code in C + code in Java for Android: $400 USD
Payment methods: BTC, PerfectMoney

Figure 5: Actor "wachdog" advertises utility to connect to .bit domains in late 2015

Sample Advertisement #2

In late 2017, actor "Discomrade" advertised a new HTTP distributed denial of service (DDoS) malware named "Coala" on a prominent Russian-language underground forum (Figure 6). According to the advertisement, Coala focuses on L7 (HTTP) attacks and can overcome Cloudflare, OVH, and BlazingFast DDoS protections. The original posting stated that the actor was working on adding support for .bit domains, and later updated the forum post to specify that Coala was able to support .bit domain communications.

Advertisement Translated Text:

Coala - Http DDoS Bot, .net 2.0, bypass cloudflare/ovh/blazi...
The sale resumed.

I changed my decision to rewrite the bot from the scratch on native language.
I'm looking forward to hearing any ideas / comments/ questions you have about improving this DDoS bot.
I updated and enhanced the bot using your previous comments and requests (changed communication model between server and bot, etc)

I added the following features/options/abilities:

- to customize the HTTP-headers (user-agent, cookie, referrer)
- to set task limits
- to count the number of bots used for particular task
- to read the answer from a server
- to use async sockets
- to set the number of sockets per timeout
- to set the number of HTTP-requests per socket
- to set custom waiting time
- to set an attack restart periods
- to count the requests per second for particular task

I removed the feature related to DDoS attacks against TOR sites because of its improper functioning and AV detects.

Currently I am working on .bit domains support.

The price: $400
 

Figure 6: Discomrade advertising Coala DDoS malware support for .bit domains

Sample Advertisement #3

The AZORult malware, which was discovered in mid-2016, is offered in underground marketplaces by the actor "CrydBrox." In early 2017, CrydBrox offered an updated variant of the AZORult malware that included .bit support (Figure 7).

Advertisement Translated Text:

 AZORult V2

[+] added .bit domains support
[+] added CC stealing feature (for Chrome-based browsers)
[+] added passwords grabbing from FTP-client WinSCP
[+] added passwords grabbing from Outlook (up to the last version)
[+] fixed passwords grabbing from Firefox and Thunderbird
[+] added the feature to examine what privileges were used to run stealer
[+] provided encrypted communication between management panel and the stealer
[+] added AntiVirtualMachine, AntiSandbox, AntiDebug techniques
[+] fixed logs collection feature (excluded info about file operations)
[+] accelerated the work of stealer process
[+] removed .tls section from binary file
[+] added ability to search logs by cookies content (in management panel)
[+] added the view of the numbers of passwords/CC/CoinsWallet and files in logs to management panel
[+] added the commenting feature to logs
[+] added viewing of the stats by country, architecture, system version, privileges, collected passwords
[+] added new filters and improved of old filters

There are 4 variants of the stealer:
AU2_EXE.exe - run and send the report
AU2_EXEsd.exe - run, send the report and remove itself
AU2_DLL.dll - collect info after the load into the process, send data and return the control to the process
AU2_DLLT.dll - after the loading of the DLL into the process it creates the separate thread for stealer work
*DLL versions successfully work with all popular bots.
The size – 495 KB, packed with UPX – 220 KB

The prices:
1 build - $100
rebuild - $30
 

Figure 7: CrydBrox advertising AZORult support for .bit domains

Namecoin Usage Analysis

Coinciding with malicious actors' increasing interest in using .bit domains is a growing number of malware families that are being configured to use them. Malware families that we have observed using Namecoin domains as part of their C2 infrastructure include:

  • Necurs
  • AZORult
  • Neutrino (aka Kasidet, MWZLesson)
  • Corebot
  • SNATCH
  • Coala DDoS
  • CHESSYLITE
  • Emotet
  • Terdot
  • Gandcrab Ransomware
  • SmokeLoader (aka Dofoil)

Based on our analysis of samples configured to used .bit, the following methods are commonly used by malware families to connect to these domains:

  • Query hard-coded OpenNIC IP address(es)
  • Query hard-coded DNS server(s)

AZORult

The AZORult sample (MD5: 3a3f739fceeedc38544f2c4b699674c5) was configured to support the use of .bit communications, although it did not connect to a Namecoin domain during analysis. The sample first checks if the command and control (C2) domain contains the string ".bit" and, if so, the malware will query the following hard-coded OpenNIC IP addresses to try to resolve the domain (Figure 8 and Figure 9):

  • 89.18.27.34
  • 87.98.175.85
  • 185.121.177.53
  • 193.183.98.154
  • 185.121.177.177
  • 5.9.49.12
  • 62.113.203.99
  • 130.255.73.90
  • 5.135.183.146
  • 188.165.200.156


Figure 8: Hard-coded OpenNIC IP addresses - AZORult


Figure 9: AZORult code for resolving C&C domains

CHESSYLITE

The analyzed CHESSYLITE sample (MD5: ECEA3030CCE05B23301B3F2DE2680ABD) contains the following hard-coded .bit domains:

  • Leomoon[.]bit
  • lookstat[.]bit
  • sysmonitor[.]bit
  • volstat[.]bit
  • xoonday[.]bit

The malware attempts to resolve those domains by querying the following list of hard-coded OpenNIC IP addresses:

  • 69.164.196.21
  • 107.150.40.234
  • 89.18.27.34
  • 193.183.98.154
  • 185.97.7.7
  • 162.211.64.20
  • 217.12.210.54
  • 51.255.167.0
  • 91.121.155.13
  • 87.98.175.85

Once the .bit domain has been resolved, the malware will issue an encoded beacon to the server (Figure 10).


Figure 10: CHESSYLITE sample connecting to xoonday.bit and issuing beacon

Neutrino (aka Kasidet, MWZLesson)

The analyzed Neutrino sample (MD5: C102389F7A4121B09C9ACDB0155B8F70) contains the following hard-coded Namecoin C2 domain:

  • brownsloboz[.]bit

Instead of using hard-coded OpenNIC IP addresses to resolve its C2 domain, the sample issues DnsQuery_A API calls to the following DNS servers:

  • 8.8.8.8
  • sourpuss.[]net
  • ns1.opennameserver[.]org
  • freya.stelas[.]de
  • ns.dotbit[.]me
  • ns1.moderntld[.]com
  • ns1.rodgerbruce[.]com
  • ns14.ns.ph2network[.]org
  • newton.bambusoft[.]mx
  • secondary.server.edv-froehlich[.]de
  • philipostendorf[.]de
  • a.dnspod[.]com
  • b.dnspod[.]com
  • c.dnspod[.]com

The malware is configured to run through the list in the aforementioned order. Hence, if a DnsQuery_A call to 8.8.8.8 fails, the malware will try sourpuss[.]net, and so on (Figure 11). Through network emulation techniques, we simulated a resolved connection in order to observe the sample's behavior with the .bit domain.


Figure 11: Modified 8.8.8.8 to 8.8.8.5 to force query failure

Monero Miner

The analyzed Monero cryptocurrency miner (MD5: FA1937B188CBB7fD371984010564DB6E) revealed the use of .bit for initial beacon communications. This miner uses the DnsQuery_A API call and connects to the OpenNIC IP address 185.121.177.177 to resolve the domain flashupd[.]bit (Figure 12 and Figure 13).


Figure 12: Code snippet for resolving the .bit domain


Figure 13: DNS request to OpenNIC IP 185.121.177.177

Terdot (aka ZLoader, DELoader)

The analyzed Terdot sample (MD5: 347c574f7d07998e321f3d35a533bd99) includes the ability to communicate with .bit domains, seemingly to download additional payloads. It attempts resolution by querying the following list of OpenNIC and public DNS IP addresses:

  • 185.121.177.53
  • 185.121.177.177
  • 45.63.25.55
  • 111.67.16.202
  • 142.4.204.111
  • 142.4.205.47
  • 31.3.135.232
  • 62.113.203.55
  • 37.228.151.133
  • 144.76.133.38

This sample iterates through the hard-coded IPs in attempts to access the domain cyber7[.]bit (Figure 14). If the domain resolves, it will connect to https://cyber7[.]bit/blog/ajax.php to download data that is RC4 encrypted and expected to contain a PE file.


Figure 14: DNS requests for cyber7.bit domain

Gandcrab Ransomware

The analyzed Gandcrab ransomware sample (MD5: 9abe40bc867d1094c7c0551ab0a28210) also revealed the use of .bit domains. Unlike previously mentioned families, it spawns a new nslookup process via an anonymous pipe to resolve the following blockchain domains:

  • Bleepingcomputer[.]bit
  • Nomoreransom[.]bit
  • esetnod32[.]bit
  • emsisoft[.]bit
  • gandcrab[.]bit

The spawned nslookup process contains the following command (as seen in Figure 15):

  • nslookup <domain>  a.dnspod.com


Figure 15: GandCrab nslookup process creation and command

Emercoin Domains

FireEye iSIGHT Intelligence researchers have identified other blockchain domains being used by cyber criminals, including Emercoin domains .bazar and .coin. Similar to the Namecoin TLD, all records are completely decentralized, un-censorable, and cannot be altered, revoked, or suspended.

Navigating to Emercoin Domains

Emercoin also maintains a peering agreement with OpenNIC, meaning domains registered with the Emercoin's EMCDNS service are accessible to all users of OpenNIC DNS servers. Current root zones supported by EMCDNS are shown in Table 3.

Zone

Intended Purpose

.coin

digital currency and commerce websites

.emc

websites associated with the Emercoin project

.lib

from the words Library and Liberty - that is, knowledge and freedom

.bazar

marketplace

Table 3: Emercoin-supported DNS zones (Emercoin Wiki)

Users also have the option of installing compatible browser plugins that will navigate to Emercoin domains, or routing their traffic through emergate[.]net, which is a gateway maintained by the Emercoin developers.

Emercoin Domain Usage

FireEye iSIGHT Intelligence has observed eCrime actors using Emercoin domains for malicious infrastructure, albeit to a lesser extent. Examples of these operations include:

  • Operators of Joker's Stash, a prolific and well-known card data shop, frequently change the site's URL. Recently, they opted for using a blockchain domain (jstash[.]bazar) instead of Tor, ostensibly for greater operational security.
  • Similarly, the following card shops have also moved to .bazar domains:
    • buybest[.]bazar
    • FRESHSTUFF[.]bazar
    • swipe[.]bazar
    • goodshop[.]bazar
    • easydeals[.]bazar
  • In addition to the hard-coded Namecoin domain, the aforementioned Neutrino sample also contained several hard-coded Emercoin domains:
    • http://brownsloboz[.]bazar
    • http://brownsloboz[.]lib
    • http://brownsloboz[.]emc
  • FireEye iSIGHT Intelligence identified a Gandcrab ransomware sample (MD5: a0259e95e9b3fd7f787134ab2f31ad3c) that leveraged the Emercoin TLD .coin for its C2 communications (Figure 16 and Figure 17).


Figure 16: DNS query for nomoreransom[.]coin


Figure 17: Gandcrab POST request to nomoreransom[.]coin

Outlook

While traditional methods of infrastructure obfuscation such as Tor, bulletproof, and fast-flux hosting will most likely continue for the foreseeable future, we assess that the usage of blockchain domains for malicious infrastructure will continue to gain popularity and usage among cyber criminals worldwide. Coinciding with the expected increase in demand, there will likely be an increasing number of malicious infrastructure offerings within the underground communities that support blockchain domains.

Due to the decentralized and replicated nature of a blockchain, law enforcement takedowns of a malicious domain would likely require that the entire blockchain be shut down – something that is unfeasible to do as many legitimate services run on these blockchains. If law enforcement agencies can identify the individual(s) managing specific malicious blockchain domains, the potential for these takedowns could occur; however, the likelihood for this to happen is heavily reliant on the operational security level maintained by the eCrime actors. Further, as cyber criminals continue to develop methods of infrastructure obfuscation and protection, blockchain domain takedowns will continue to prove difficult.