Category Archives: blockchain

You are who you say you are: Establishing digital trust with the blockchain

Over the last few years, blockchain use has gained popularity driven partly by the interest in cryptocurrency, but mostly with the growing understanding of what distributed ledger technology can enable through decentralization of trust. Most large companies have innovation teams looking at ways that blockchain technology can be applied, and many analyst firms, system integrators and other influencers have focused teams providing advice on applications of blockchain technology. I have spoken to experts at leading … More

The post You are who you say you are: Establishing digital trust with the blockchain appeared first on Help Net Security.

Trail of Bits Blog: 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.





Trail of Bits Blog

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.

What is Blockchain? Everything you need to know

Like much of the technology world, cryptocurrencies such as Bitcoin still rely on some form of database that are able to track large volumes of transactions and keep them secure.The

The post What is Blockchain? Everything you need to know appeared first on The Cyber Security Place.

California Enacts Blockchain Legislation

As reported on the Blockchain Legal Resource, California Governor Jerry Brown recently signed into law Assembly Bill No. 2658 for the purpose of further studying blockchain’s application to Californians. In doing so, California joins a growing list of states officially exploring distributed ledger technology.

Specifically, the law requires the Secretary of the Government Operations Agency to convene a blockchain working group prior to July 1, 2019. Under the new law, “blockchain” means “a mathematically secured, chronological and decentralized ledger or database.” In addition to including various representatives from state government, the working group is required to include appointees from the technology industry and non-technology industries, as well as appointees with backgrounds in law, privacy and consumer protection.

Under the new law, which has a sunset date of January 1, 2022, the working group is required to evaluate:

  • the uses of blockchain in state government and California-based businesses;
  • the risks, including privacy risks, associated with the use of blockchain by state government and California-based businesses;
  • the benefits associated with the use of blockchain by state government and California-based businesses;
  • the legal implications associated with the use of blockchain by state government and California-based businesses; and
  • the best practices for enabling blockchain technology to benefit the State of California, California-based businesses and California residents.

In doing so, the working group is required to seek “input from a broad range of stakeholders with a diverse range of interests affected by state policies governing emerging technologies, privacy, business, the courts, the legal community and state government.”

The working group is also tasked with delivering a report to the California Legislature by January 1, 2020, on the potential uses, risks and benefits of blockchain technology by state government and California businesses. Moreover, the report is required to include recommendations for amending relevant provisions of California law that may be impacted by the deployment of blockchain technology.

Blockchain startup creates a decentralized ‘Pirate Bay’ alternative

Cryptocurrency startup wants to build a decentralized and searchable torrent database that’s impossible to block

While anti-piracy agencies and mounting legal pressure have made many several pirated torrent websites close down its shutters, a new cryptocurrency startup has now come up with a novel idea to use blockchain technology to save and actively promote copyright content.

The project called “Quality Magnet Coin” (QMC) aims to build a large torrent magnet index that cannot be taken offline, censored, or blocked. The only thing QMC programmers want, they claim, is to make information “free and available to everyone.”

The startup will use QMC, a cryptocurrency, to create a decentralized database of torrent magnet links. Since the blockchain does not depend on a hosting service or domain name, it will be almost impossible to take down the torrent magnet links.

“While other existing services and plans are focusing on Pay-to-Seed, that is, paying for uploading the actual data of the files to people who are downloading, we are focused on the creation of a decentralized and searchable database of files to download. Think of it as a decentralized Pirate Bay,” the QMC team told TorrentFreak.

QMC would automatically update all existing torrent links, as well as add new ones. Further, besides keeping a record of all transactions on the blockchain, every user would also have a database of all available torrent magnets through the cryptocurrency. This is regularly synced with the decentralized network to actively update every working magnet file made available and also remove those that are often voted as ‘bad.’

QMC depends on its users to build the magnet database. To promote file sharing, the platform rewards users for sharing ‘good’ – i.e., working – magnet links. While submitting a link would cost the users 1 QMC, they can, however, get up to 5 QMC back after the end of month, for each magnet that is voted as good.

The cost of submitting a link concept will encourage people to share only working content and in turn, keep spammers at bay.

Although the project has just begun, it already has 25 working masternodes, reports TorrentFreak. Currently, only 10% of the masternode holders have to vote a working torrent as ‘good’ before making a payment.

The startup has made a software application called QMT that allows you to search for content at any given time. This includes working download torrent links to load magnets into any regular torrent client, along with a link to Instant.io that allows users to download or stream through WebTorrent.

Presently, there are over 5,000 magnet links in the magnet database. The QMC is currently “exploring partnerships with torrent sites” to expand it more quickly.

While there are claims that the QMC team is looking to actively promote copyright infringement, the QMC team emphasizes that the software and network itself is content neutral.

“We have no intention of copyright infringement, just like TRON doesn’t for that matter – even though they want to pay users for seeding torrents,” the QMC team told TorrentFreak pointing out at TRON’s recent acquisition of BitTorrent.

“We simply would like information to be free and available to everyone. Information is always silenced based on political views or other means of pressure and we want to change that. What our users choose to post is up to them.”

In order to promote anonymity, the cryptocurrency wallet has built-in support feature for the Tor network – a powerful anonymizing service – that users can enable in the configuration file.

The QMC wallet and QMT search tool are available on Windows, Mac, and Linux. The group has plans to release the iOS and Android versions next year. The startup also has future plans, such as an API to link torrent sites to the QMC database, and the option for private torrent trackers to accept payments in QMC.

Also Read- The Pirate Bay is Down- 10 Best Torrent Sites To Download Free Movie

If you want more information and background on the project, you can check out the Bitcoin Talk forums, or the website.

Whether or not will the startup be able to deliver its promises, only time will. On the other hand, if the project manages to get popular and worldwide acceptance, it could turn out to be a nightmare for the entertainment industry around the globe.

The post Blockchain startup creates a decentralized ‘Pirate Bay’ alternative appeared first on TechWorm.

In Blockchain, There is no Checkmate

During my time as a Chairman of NATO’s Intelligence Committee and advising government and private companies on cybersecurity, I have noticed the same hacker-shaped hole in the industry. For the

The post In Blockchain, There is no Checkmate appeared first on The Cyber Security Place.

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.

The Ethical Hacker Network: Webinar: Blockchain Hacking for Investigating Cryptocurrencies on Oct 24 2018

Register Now to Learn Blockchain Hacking Step-by-Step!

Nick Furneaux, forensics trainer, investigator & author of "Investigating Cryptocurrencies" takes you through a journey of code and tools to unpick the movement of illegal funds through the blockchain during this fascinating, FREE EH-Net Live! webinar on Wednesday October 24, 2018 at 1:00 PM US Eastern. Join us live to learn how to win free copies of his book!

The post Webinar: Blockchain Hacking for Investigating Cryptocurrencies on Oct 24 2018 appeared first on The Ethical Hacker Network.



The Ethical Hacker Network

A week in security (October 1 – 7)

Last week, Malwarebytes welcomed National Cybersecurity Awareness Month by renewing our pledge to do what we do best: offer the best protection for our customers and promote security awareness for all.

On Labs, we raised the question of whether it is a good idea to bring your own security or not, talked a little bit more about fileless malware, homed in on a malware campaign targeting Fortnite gamers, and looked into LoJack, a bootkit malware that has been targeting government entities.

Other cybersecurity news:

Stay safe, everyone!

The post A week in security (October 1 – 7) appeared first on Malwarebytes Labs.

Trust flourishes in blockchain

if implemented effectively, blockchain has the potential to transform the way we do business. After several years spent in the shadow of bitcoin, it’s time for blockchain, the technology on

The post Trust flourishes in blockchain appeared first on The Cyber Security Place.

Dash Price Analysis: DASH/USD Looking to Escape The Stubborn Block of Consolidation after BitGo Addition

DASH/USD is stuck within a chunky block of consolidation, as price action narrows further, subject to a breakout. BitGo adds DASH to its list of supported cryptocurrencies due its “instant payment” and “privacy payment” features. DASH/USD has been trading within a very mundane range, with price action continuing to narrow. It has been stuck within, […]

The post Dash Price Analysis: DASH/USD Looking to Escape The Stubborn Block of Consolidation after BitGo Addition appeared first on Hacked: Hacking Finance.

Stellar Price Analysis: XLM/USD Has the Potential for a Short-term Rally, Though Bearish Set-up Eyed

Stellar’s XLM potentially has further room for upside, within the short-term view. Danger still looms for XLM/USD, as the daily chart suggests of a bearish technical pattern set up. Steller’s native token XLM, has failed to commit to any sustained trend. This has been the case since the start of July. Bull rallies that have […]

The post Stellar Price Analysis: XLM/USD Has the Potential for a Short-term Rally, Though Bearish Set-up Eyed appeared first on Hacked: Hacking Finance.

Cardano Price Analysis: Imminent Breakout Anticipated, with Eyes on Another Bull Run

The Cardano (ADA) price has been showing some promising signs, following the project’s 1-year anniversary. ADA/USDT is near the end of a triangular pattern, which can also be perceived as a bullish pennant pattern. Cardano a few days ago celebrated its one-year anniversary. It is still very much a new project to hit the industry. […]

The post Cardano Price Analysis: Imminent Breakout Anticipated, with Eyes on Another Bull Run appeared first on Hacked: Hacking Finance.

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. We’ll post a sign up form on our Twitter and the Empire Hacking Slack one day ahead of time.

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.

Fork-free, Energy Efficient Red Belly Blockchain Hits 30,000 Transactions per Second

Red Belly fork-free Blockchain, previously showed transaction speed several times faster than Bitcoin and Ethereum, was subjected to a new experiment, hitting the ability to provide 30,000 transactions per second. This is reported by CSIRO’s Data61, the technology arm of Australia’s national science agency, which took part in the development, together with the Concurrent Systems Research Group at the University of Sydney.

3,000 Trx/Sec matching 14 regions

The experiment was deployed in 14 regions covered by Amazon Web Services’ network, including North America, South America, Asia Pacific, and Europe. With 1,000 machines maintaining a copy of the current state of the Blockchain and the balance of all accounts, the Blockchain demonstrated an average transaction delay of three seconds, which is comparable to the delay obtained during a test last year with 260 replicas located in a single region.

In comparison, mainstream blockchain technologies need minutes, with the Bitcoin Blockchain and the Ethereum network typically processing seven and 20 transactions per second respectively.

The experiment emphasizes the newly launched Blockchain’s scalability while retaining fast transaction speeds makes it ideal for the processing of financial transactions and microgrids that use peer-to-peer trading to transform the energy sector.

Fork-free, no double spending

In addition to high throughput, Red Belly differs from existing solutions with a number of advantages. It is fork-free as contrasted to Bitcoin selecting the longest branch from a forked chain or tree where multiple nodes add different blocks at the same point before learning of the presence of other blocks.

The Blockchain eliminates the risks of double spending where an individual spends their money twice by initiating more than one transaction, researchers say.

Beyond that, It’s much more friendly to the environment because it requires much less electricity than blockchains maintained by proof of work and based on solving crypto puzzles, that requires massive amounts of energy. Red Belly is underpinned by a unique algorithm and offers performance that scales without an equivalent increase in electricity consumption.

“Real-world applications of blockchain have been struggling to get off the ground due to issues with energy consumption and complexities induced by the proof of work. The deployment of Red Belly Blockchain shows the unique scalability and strength of the next generation ledger technology in a global context,” Dr. Vincent Gramoli, senior researcher at CSIRO’s Data61 and head of Concurrent Systems Research Group at the University of Sydney said.

Being marked as a revolutionary solution for the global economy, Red Belly Blockchain has also attracted big-time investors. The company is currently in the middle of a Series A capital raise to help it commercialize, and Kosmos Capital, a VC firm specializing in blockchain investments, is the one leading the raise.

For more information on Red Belly Blockchain, visit redbellyblockchain.io.

The post Fork-free, Energy Efficient Red Belly Blockchain Hits 30,000 Transactions per Second appeared first on TechWorm.

Why Blockchain Is No Silver Bullet For Cyber Threats

What is blockchain? First, imagine a spreadsheet that’s reproduced thousands of times across a network of computers. Then imagine that this network is designed to regularly update this spreadsheet and

The post Why Blockchain Is No Silver Bullet For Cyber Threats appeared first on The Cyber Security Place.

Crypto Isn’t As Risky As It Used To Be, But Regulators Could Still Do More

During the summer, an agent at the US’s Drug Enforcement Administration, Lilita Infante, said the ratio of legal to illegal activity in bitcoin has inverted. Talking to Bloomberg, she said illegal

The post Crypto Isn’t As Risky As It Used To Be, But Regulators Could Still Do More appeared first on The Cyber Security Place.

EOS Price Analysis: EOS/USD Behavior Spells Potential Danger Following Voting Manipulation Allegations

EOS has been under fire of late, following reports of a leaked document from a Huobi employee. It indicates voter collusion between Huobi and Chinese EOS block producers. EOS/USD has been on the move lower, as the price remains within a bearish pennant pattern. Collusion Details Huobi is one of the largest crypto-exchanges in the […]

The post EOS Price Analysis: EOS/USD Behavior Spells Potential Danger Following Voting Manipulation Allegations appeared first on Hacked: Hacking Finance.

Tron Latest Update: Justin Sun Delivers Promising News On the Platform’s Development and Progress

Justin Sun conducted a live stream to update viewers on the latest happenings with the Tron network. TRX/USD edges over vital descending trend line, further cementing the current recovery trend. Tron’s Superiority vs. Other Blockchains Justin Sun, as promised via his Twitter account, held a live-steam to update the community where he providing pleasant insight […]

The post Tron Latest Update: Justin Sun Delivers Promising News On the Platform’s Development and Progress appeared first on Hacked: Hacking Finance.

Stellar Price Analysis: XLM/USD Marching Higher amid Launch of StellarX Decentralized Exchange

Stellar launches “StellarX”, the world’s first zero-fee decentralized exchange with fiat deposits. XLM/USD making strong progression, with indicators pointing to the upside, eyes on a potential reclaim of the $0.30 mark. The Stellar camp has built a new trading platform known as StellarX, which is decentralized boasting a zero-fee structure. The platform has been built […]

The post Stellar Price Analysis: XLM/USD Marching Higher amid Launch of StellarX Decentralized Exchange appeared first on Hacked: Hacking Finance.

TRusted Anonymous Data Exchange (TRADE) Threat Intelligence Sharing With Blockchain

Co-authored Yair Allouche.

Former U.S. Secretary of Defense Donald Rumsfeld once said, “See that the President, the Cabinet and staff are informed. If cut out of the information flow, their decisions may be poor, not made, or not confidently or persuasively implemented.”

As we saw with the discovery of the WireX malware, threat intelligence sharing is critical to discovering new threats. So what is inhibiting the smooth flow of the highest-value threat intelligence?

According to the Ponemon Institute, 60 percent of companies that belong to industry-specific threat sharing communities, such as the IT Information Sharing & Analysis Center (ISAC), do not share intelligence outside the organization due to fear of revealing a breach and the resulting liability from that disclosure. Inadvertently revealing a vulnerability or breach leaves companies open to reputational brand damage and the threat of legal action.

Smarter Threat Intelligence Sharing With TRADE

IBM’s security research lab in Be’er Sheva, Israel invented a new way to share threat intelligence that allows companies to control who has access to this data (without revealing the source of the information) and the quality of the anonymous information they consume (without knowing exactly which organization contributed the information).

TRusted Anonymous Data Exchange (TRADE) is an IBM Hyperledger Fabric (blockchain) network that allows members to exchange information by leveraging smart contracts to define the levels of trust and anonymity required to enable collaboration. A smart contract is used to enforce organizational requirements for attributes such as reputation and contribution levels to limit who has access to the threat intelligence information that members publish.

TRADE leverages existing threat intelligence exchange protocols — such as Trusted Automated Exchange of Intelligence Information (TAXII) and Structured Threat Information Expression (STIX) — that are integrated with operational workflows. Each time a member of the networks contributes, accesses or enriches threat information, the transaction is recorded on the blockchain. This way, a full history of the information flow is immutably recorded and can be audited if necessary at a later date.

Establishing Trust Without Coverage Gaps or Delays

There are two common models for establishing trust in threat intelligence sharing communities today. The first is based on a trusted third party, and the second is point to point based on trust established through personal relationships. Both of these models have drawbacks that are addressed by TRADE. The third-party model introduces the trusted third party as a bottleneck, delaying the spread of crucial threat intelligence. Trust based on personal relationships inherently has coverage and scalability gaps. Using blockchain permits TRADE to mimic the peer-to-peer trust model, but without coverage gaps or delays.

Another Ponemon Institute study noted that the value of threat intelligence diminishes within minutes, so timely dissemination of this information is crucial to stopping attackers before they can cause widespread damage. TRADE allows threat analysts to quickly get the freshest data out to their peers, referred to as coalition members, without risk to the organization.

How TRADE Ensures Data Reliability With Karma

When threat intelligence is shared anonymously and organizations can opt in to information sharing coalitions at will, how do you avoid the “free rider” problem? What is the incentive for threat analysts to share data in a world where no one knows whether or not they are sharing? TRADE solves this problem by rewarding karma for information shared. To receive and consume threat intelligence data, organizations must spend the karma they’ve earned.

But if organizations are incented to contribute threat intelligence so they can then consume threat intelligence, what prevents them from anonymously contributing low-value data? In TRADE, each coalition member can gain or lose reputation based on the quality of the data they contribute. When a member spends karma to receive threat intelligence data that turns out to be flawed or misrepresented, he or she can rate the contribution.

Organizations can earn karma discounts for acquiring future threat intelligence by providing a rating for the information they received. If an organization’s reputation falls too low because it submitted low-quality data, they will not be able to access critical threat intelligence. This feature of TRADE ensures data reliability by isolating violators and cheaters.

Enabling Threat Intelligence to Move Freely

Western novelist Louis L’Amour wrote, “Knowledge is like money: to be of value it must circulate, and in circulating it can increase in quantity and, hopefully, in value.” It’s our hope that TRADE will allow threat intelligence to circulate more freely, leading to an increase in high-quality information that organizations can use to protect themselves from the latest threats.

The post TRusted Anonymous Data Exchange (TRADE) Threat Intelligence Sharing With Blockchain appeared first on Security Intelligence.

Exploring the Fundamentals of Blockchain

While the concepts of cryptocurrency and blockchain have been around for years, it wasn’t until Bitcoin’s recent and dramatic explosion in value that these terms became mainstream. Once the digital

The post Exploring the Fundamentals of Blockchain appeared first on The Cyber Security Place.

Bitcoin Core Team fixes a critical DDoS flaw in wallet software

Bitcoin Core Software fixed a critical DDoS attack vulnerability in the Bitcoin Core wallet software tracked as CVE-2018-17144.

The Bitcoin Core team urges miners to update client software with the latest Bitcoin Core 0.16.3 version as soon as possible.

“A denial-of-service vulnerability (CVE-2018-17144) exploitable by miners has been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of the vulnerable versions to 0.16.3 as soon as possible,” states the security advisory.

The flaw affected the Bitcoin Core wallet software and could have been exploited by attackers to crash Bitcoin Core nodes running software versions 0.14.0 to 0.16.2.

The CVE-2018-17144 vulnerability is critical because by coordinating an attack through the Bitcoin miners it was possible to bring down the entire blockchain either by overflooding the block with duplicate transactions, resulting in blockage of transaction confirmation from other people or by flooding the nodes of the Bitcoin P2P network and saturating the bandwidth.

The bug seems to have been introduced in March 2017, but no one apparently has exploited the flaw in live attacks.

The flaw potentially affects all recent versions of the BTC system, but anyway, experts pointed out that a coordinated Distributed Denial of Service (DDoS) attack against Bitcoin blockchain is very expensive.

It has been estimated that a successful DDoS attack on the BTC network would cost miners 12.5 bitcoins ($80,000).

Bitcoin Core

According to the change log of the latest version, the Bitcoin Core team also patched minor issues related to RPC and other APIs, to invalid error flags, to the consensus and documentation.

“If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac) or `bitcoind`/`bitcoin-qt` (on Linux).” continues the note.

“The first time you run version 0.15.0 or newer, your chainstate database will be converted to a new format, which will take anywhere from a few minutes to half an hour, depending on the speed of your machine.”

Pierluigi Paganini

(Security Affairs – Bitcoin Core, DDoS)

The post Bitcoin Core Team fixes a critical DDoS flaw in wallet software appeared first on Security Affairs.

‘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.

Hackers steal $60 million from Japan’s Zaif cryptocurrency exchange

By Waqas

Zaif is the 35th largest cryptocurrency exchange by turnover. Hackers have stolen a whopping $60 million (6.7 billion yen) worth of cryptocurrency from Zaif, the 35th largest cryptocurrency exchange dealing in Bitcoin, Bitcoin Cash, and Monacoin. The exchange is owned by Tech Bureau, Corp. based in Nishi-Ku, Osaka, Japan. The hack attack took place on September 14th after hackers gained […]

This is a post from HackRead.com Read the original post: Hackers steal $60 million from Japan’s Zaif cryptocurrency exchange

Rattle – an Ethereum EVM binary analysis framework

Most smart contracts have no verified source code, but people still trust them to protect their cryptocurrency. What’s more, several large custodial smart contracts have had security incidents. The security of contracts that exist on the blockchain should be independently ascertainable.

Ethereum VM (EVM) Bytecode

Ethereum contracts are compiled to EVM – the Ethereum Virtual Machine. As blocks are mined, EVM is executed and its resulting state is encoded into the blockchain forever. Everyone has access to this compiled EVM code for every smart contract on the blockchain — but reviewing EVM directly isn’t easy.

EVM is a RISC Harvard-architecture stack machine, which is fairly distinct in the world of computer architectures. EVM has around 200 instructions which push and pop values from a stack, occasionally performing specific actions on them (e.g. ADD takes two arguments of the stack, adds them together, and pushes the result back to the stack). If you’re familiar with reverse polish notation (RPN) calculators, then stack machines will appear similar. Stack machines are easy to implement but difficult to reverse-engineer. As a reverse-engineer, I have no registers, local variables, or arguments that I can label and track when looking at a stack machine.

For these reasons, I created Rattle, a framework which turns the stack machine into an infinite-register SSA form.

Rattle

Rattle is an EVM binary static analysis framework designed to work on deployed smart contracts. Rattle takes EVM byte strings, uses a flow-sensitive analysis to recover the original control flow graph, lifts the control flow graph into an SSA/infinite register form, and optimizes the SSA – removing DUPs, SWAPs, PUSHs, and POPs. Converting the stack machine to SSA form removes 60%+ of EVM instructions and presents a much friendlier interface to those who wish to read the smart contracts they’re interacting with.

Demo

As an example, we will analyze the infamous King of Ether contract.

First in Ethersplay, our Binary Ninja plug-in for analyzing Ethereum Smart Contracts:

Figure 1: The King of Ether contract as disassembled by Ethersplay

In Ethersplay, we can see there are 43 instructions and 5 basic blocks. The majority of the instructions are pure stack manipulation instructions (e.g. PUSH, DUP, SWAP, POP). Interspersed in the blocks are the interesting instructions (e.g. CALLVALUE, SLOAD, etc.).

Now, analyze the contract with Rattle and observe the output for the same function. We run Rattle with optimizations, so constants are folded and unneeded blocks are removed.

$ python3 rattle-cli.py --input inputs/kingofether/KingOfTheEtherThrone.bin -O

The Rattle CLI interface generates graphviz files for each function that it can identify and extract.

Figure 2: The King of Ether contract as recovered by Rattle

As you can see, Rattle optimized the numberOfMonarchs() function to only 12 instructions. Rattle eliminated 72% of the instructions, assigned registers you can track visually, and removed an entire basic block. What’s more, Rattle recovered the used storage location and the ABI of the function.

Rattle will help organizations and individuals study the contracts they’re interacting with and establish an informed degree of trust to the contracts’ security. If your contracts’ source code isn’t available or can’t be verified, then you should run Rattle.

Get Rattle on our GitHub and try it out for yourself.

Contract upgrade anti-patterns

A popular trend in smart contract design is to promote the development of upgradable contracts. At Trail of Bits, we have reviewed many upgradable contracts and believe that this trend is going in the wrong direction. Existing techniques to upgrade contracts have flaws, increase the complexity of the contract significantly, and ultimately introduce bugs. To highlight this point, we are releasing a previously unknown flaw in the Zeppelin contract upgrade strategy, one of the most common upgrade approaches.

In this article, we are going to 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. In a follow-up blog post, we will detail a method, contract migration, that achieves the same benefits with few of the downsides.

An overview of upgradable contracts

Two ‘families’ of patterns have emerged for upgradable smart contracts:

  • Data separation, where logic and data are kept in separate contracts. The logic contract owns and calls the data contract.
  • Delegatecall-based proxies, where logic and data are kept in separate contracts, also, but the data contract (the proxy) calls the logic contract through delegatecall.

The data separation pattern has the advantage of simplicity. It does not require the same low-level expertise as the delegatecall pattern. The delegatecall pattern has received lots of attention recently. Developers may be inclined to choose this solution because documentation and examples are easier to find.

Using either of these patterns comes at considerable risk, an aspect of this trend that has gone unacknowledged thus far.

Data separation pattern

The data separation pattern keeps logic and data in separate contracts. The logic contract, which owns the data contract, can be upgraded if required. The data contract is not meant to be upgraded. Only the owner can alter its content.

Figure 1: High-level overview of the data separation upgrade pattern

When considering this pattern, pay special attention to these two aspects: how to store data, and how to perform the upgrade.

Data storage strategy

If the variables needed across an upgrade will remain the same, you can use a simple design where the data contract holds these variables, with their getters and setters. Only the contract owner should be able to call the setters:

contract DataContract is Owner {
  uint public myVar;

  function setMyVar(uint new_value) onlyOwner public {
    myVar = new_value;
  }
}

Figure 2: Data storage example (using onlyOwner modifier)

You have to clearly identify the state variables required. This approach is suitable for ERC20 token-based contracts since they only require the storage of their balances.

If a future upgrade requires new persistent variables, they could be stored in a second data contract. You can split the data across separate contracts, but at the cost of additional logic contract calls and authorization. If you don’t intend to upgrade the contract frequently, the additional cost may be acceptable.

Nothing prevents the addition of state variables to the logic contract. These variables will not be kept during an upgrade, but can be useful for implementing the logic. If you want to keep them, you can migrate them to the new logic contract, too.

Key-value pair

A key-value pair system is an alternative to the simple data storage solution described above. It is more amenable to evolution but also more complex. For example, you can declare a mapping from a bytes32 key value to each base variable type:

contract DataContract is Owner {
  mapping(bytes32 => uint) uIntStorage;

  function getUint(bytes32 key) view public returns(uint) {
    return uintStorage[key];
}

  function setUint(bytes32 key, uint new_val) onlyOwner public {
    uintStorage[key] = new_val;
  }
}

Figure 3: Key-Value Storage Example (using onlyOwner modifier)

This solution is often called the Eternal Storage pattern.

How to perform the upgrade

This pattern offers several different strategies, depending on how the data are stored.

One of the simplest approaches is to transfer the ownership of the data contract to a new logic contract and then disable the original logic contract. To disable the previous logic contract, implement a pausable mechanism or set its pointer to 0x0 in the data contract.

Figure 4: Upgrade by deploying a new logic contract and disabling the old one

Another solution involves forwarding the calls from the original logic contract to the new version:

Figure 5: Upgrade by deploying a new logic contract and forwarding calls to it from the old one

This solution is useful if you want to allow users to call the first contract. However, it adds complexity; you have to maintain more contracts.

Finally, a more complex approach uses a third contract as an entry point, with a changeable pointer to the logic contract:

Figure 6: Upgrade by deploying a proxy contract that calls a new logic contract

A proxy contract provides the user with a constant entry point and a distinction of responsibilities that is clearer than the forwarding solution. However, it comes with additional gas costs.

Cardstack and Rocket-pool have detailed implementations of the data separation pattern.

Risks of the data separation pattern

The simplicity of the data separation pattern is more perceived than real. This pattern adds complexity to your code, and necessitates a more complex authorization schema. We have repeatedly seen clients deploy this pattern incorrectly. For example, one client’s implementation achieved the opposite effect, where a feature was impossible to upgrade because some its logic was located in the data contract.

In our experience, developers also find the EternalStorage pattern challenging to apply consistently. We have seen developers storing their values as bytes32, then applying type conversion to retrieve the original values. This increased the complexity of the data model, and the likelihood of subtle flaws. Developers unfamiliar with complex data structures will make mistakes with this pattern.

Delegatecall-based proxy pattern

Like the data separation method, the proxy pattern splits a contract in two: one contract holding the logic and a proxy contract holding the data. What’s different? In this pattern, the proxy contract calls the logic contract with delegatecall; the reverse order.

Figure 7: Visual representation of the proxy pattern

In this pattern, the user interacts with the proxy. The contract holding the logic can be updated. This solution requires mastering delegatecall to allow one contract to use code from another.

Let’s review how delegatecall works.

Background on delegatecall

delegatecall allows one contract to execute code from another contract while keeping the context of the caller, including its storage. A typical use-case of the delegatecall opcode is to implement libraries. For example:

pragma solidity ^0.4.24;

library Lib {

  struct Data { uint val; }

  function set(Data storage self, uint new_val) public {
    self.val = new_val;
  }
}

contract C {
  Lib.Data public myVal;

  function set(uint new_val) public {
    Lib.set(myVal, new_val);
  }
}

Figure 8: Library example based on delegatecall opcode

Here, two contracts will be deployed: Lib and C. A call to Lib in C will be done through delegatecall:

Figure 9: EVM opcodes of a call to Lib.set (Ethersplay output)

As a result, when Lib.set changes self.val, it changes the value stored in C’s myVal variable.

Solidity looks like Java or JavaScript, which are object-oriented languages. It’s familiar, but comes with the baggage of misconceptions and assumptions. In the following example, a programmer might assume that as long as two contract variables share the same name, then they will share the same storage, but this is not the case with Solidity.

pragma solidity ^0.4.24;

contract LogicContract {
  uint public a;

  function set(uint val) public {
    a = val;
  }
}

contract ProxyContract {
  address public contract_pointer;
  uint public a;

  constructor() public {
    contract_pointer = address(new LogicContract());
  }

  function set(uint val) public {
    // Note: the return value of delegatecall should be checked
    contract_pointer.delegatecall(bytes4(keccak256("set(uint256)")), val);
  }
}

Figure 10: Dangerous delegatecall usage

Figure 11 represents the code and the storage variables of both of the contracts at deployment:

Figure 11: Memory illustration of Figure 10

What happens when the delegatecall is executed? LogicContract.set will write in ProxyContract.contract_pointer instead of ProxyContract.a. This memory corruption happens because:

  • LogicContract.set is executed within the context of ProxyContract.
  • LogicContract knows only one state variable: a. Any store to this variable will be done on the first element in memory (see the Layout of State Variables in Storage documentation).
  • The first element for ProxyContract is contract_pointer. As a result, LogicContract.set will write theProxyContract.contract_pointer variable instead of ProxyContract.a (see Figure 12).
  • At this point, the memory in ProxyContract has been corrupted.

If a was the first variable declared in ProxyContract, delegatecall would have not corrupted the memory.

Figure 12: LogicContract.set will write the first element in storage: ProxyContract.contract_pointer

Use delegatecall with caution, especially if the called contract has state variables declared.

Let’s review the different data-storage strategies based on delegatecall.

Data storage strategies

There are three approaches to separating data and logic when using the proxy pattern:

  • Inherited storage, which uses Solidity inheritance to ensure that the caller and the callee have the same memory layout.
  • Eternal storage, which is the key-value storage version of the logic separation that we saw above.
  • Unstructured storage, which is the only strategy that does not suffer from potential memory corruption due to an incorrect memory layout. It relies on inline assembly code and custom memory management on storage variables.

See ZeppelinOS for a more thorough review of these approaches.

How to perform an upgrade

To upgrade the code, the proxy contract needs to point to a new logic contract. The previous logic contract is then discarded.

Risks of delegatecall

In our experience with clients, we have found that it is difficult to apply the delegatecall-based proxy pattern correctly. The proxy pattern requires that memory layouts stay consistent between contract and compiler upgrades. A developer unfamiliar with EVM internals can easily introduce critical bugs during an upgrade.

Only one approach, unstructured storage, overcomes the memory layout requirement but it requires low-level memory handling, which is difficult to implement and review. Due to its high complexity, unstructured storage is only meant to store state variables that are critical for the upgradability of the contract, such as the pointer to the logic contract. Further, this approach hinders static analysis of Solidity (for example, by Slither), costing the contract the guarantees provided by these tools.

Preventing memory layout corruption with automated tools is an ongoing area of research. No existing tool can verify that an upgrade is safe against a compromise. Upgrades with delegatecall will lack automated safety guarantees.

Breaking the proxy pattern

To wit, we have discovered and are now disclosing a previously unknown security issue in the Zeppelin proxy pattern, rooted in the complex semantics of delegatecall. It affects all the Zeppelin implementations that we have investigated. This issue highlights the complexity of using a low-level Solidity mechanism and illustrates the likelihood that an implementation of this pattern will have flaws.

What is the bug?

The Zeppelin Proxy contract does not check for the contract’s existence prior to returning. As a result, the proxy contract may return success to a failed call and result in incorrect behavior should the result of the call be required for application logic.

Low-level calls, including assembly, lack the protections offered by high-level Solidity calls. In particular, low-level calls will not check that the called account has code. The Solidity documentation warns:

The low-level call, delegatecall and callcode will return success if the called account is non-existent, as part of the design of EVM. Existence must be checked prior to calling if desired.

If the destination of delegatecall has no code, then the call will successfully return. If the proxy is set incorrectly, or if the destination was destroyed, any call to the proxy will succeed but will not send back data.

A contract calling the proxy may change its own state under the assumption that its interactions are successful, even though they are not.

If the caller does not check the size of the data returned, which is the case of any contract compiled with Solidity 0.4.22 or earlier, then any call will succeed. The situation is slightly better for recently compiled contracts (Solidity 0.4.24 and up) thanks to the check on returndatasize. However, that check won’t protect the calls that do not expect data in return.

ERC20 tokens are at considerable risk

Many ERC20 tokens have a known flaw that prevents the transfer functions from returning data. As a result, these contracts support a call to transfer which may return no data. In such a case, the lack of an existence check, as detailed above, may lead a third party to believe that a token transfer was successful when it was not, and may lead to the theft of money.

Exploit scenario

Bob’s ERC20 smart contract is a proxy contract based on delegatecall. The proxy is incorrectly set due to human error, a flaw in the code, or a malicious actor. Any call to the token will act as a successful call with no data returned.

Alice’s exchange handles ERC20 tokens that do not return data on transfer. Eve has no tokens. Eve calls the deposit function of Alice’s exchange for 10,000 tokens, which calls transferFrom of Bob’s token. The call is a success. Alice’s exchange credits Eve with 10,000 tokens. Eve sells the tokens and receives ethers for free.

How to avoid this flaw

During an upgrade, check that the new logic contract has code. One solution is to use the extcodesize opcode. Alternatively, you can check for the existence of the target each time delegatecall is used.

There are tools that can help. For instance, Manticore is capable of reviewing your smart contract code to check a contract’s existence before any calls are made to it. This check was designed to help mitigate risky proxy contract upgrades.

Recommendations

If you must design a smart contract upgrade solution, use the simplest solution possible for your situation.

In all cases, avoid the use of inline assembly and low-level calls. The proper use of this functionality requires extreme familiarity with the semantics of delegatecall, and the internals of Solidity and EVM. Few teams whose code we’ve reviewed get this right.

Data separation recommendations

If you need to store data, opt for the simple data storage strategy over key-pairs (aka Eternal Storage). This method requires writing less code and depends on fewer moving parts. There is simply less that can go wrong.

Use the contract-discard solution to perform upgrades. Avoid the forwarding solution, since it requires building forwarding logic that may be too complex to implement correctly. Only use the proxy solution if you need a fixed address.

Proxy pattern recommendations

Check for the destination contract’s existence prior to calling delegatecall. Solidity will not perform this check on your behalf. Neglecting the check may lead to unintended behavior and security issues. You are responsible for these checks if relying upon low-level functionality.

If you are using the proxy pattern, you must:

  • Have a detailed understanding of Ethereum internals, including the precise mechanics of delegatecall and detailed knowledge of Solidity and EVM internals.
  • Carefully consider the order of inheritance, as it impacts the memory layout.
  • Carefully consider the order in which variables are declared. For example, variable shadowing, or even type changes (as noted below) can impact the programmer’s intent when interacting with delegatecall.
  • Be aware that the compiler may use padding and/or pack variables together. For example, if two consecutive uint256 are changed to two uint8, the compiler can store the two variables in one slot instead of two.
  • Confirm that the variables’ memory layout is respected if a different version of solc is used or if different optimizations are enabled. Different versions of solc compute storage offsets in different ways. The storage order of variables may impact gas costs, memory layout, and thus the result of delegatecall.
  • Carefully consider the contract’s initialization. According to the proxy variant, state variables may not be initializable during construction. As a result, there is a potential race condition during initialization that needs to be mitigated.
  • Carefully consider names of functions in the proxy to avoid function-name collision. Proxy functions with the same Keccak hash as the intended function will be called instead, which could lead to unpredictable or malicious behavior.

Concluding remarks

We strongly advise against the use of these patterns for upgradable smart contracts. Both strategies have the potential for flaws, significantly increase complexity, and introduce bugs, and ultimately decrease trust in your smart contract. Strive for simple, immutable, and secure contracts rather than importing a significant amount of code to postpone feature and security issues.

Further, security engineers that review smart contracts should not recommend complex, poorly understood, and potentially insecure upgrade mechanisms. Ethereum security community, consider the risk prior to endorsing these techniques.

In a follow-up blog post, we will describe contract migration, our recommended approach to achieve the benefits of upgradable smart contracts without their downsides. A contract migration strategy is essential in case of private key compromise, and helpful in avoiding the need for other upgrades.

In the meantime, you should contact us if you’re concerned that your upgrade strategy may be insecure.

Threat Report: Don’t Join Blockchain Revolution Without Ensuring Security

On May 19 researchers discovered a series of vulnerabilities in the blockchain-based EOS platform that can lead to remote control over participating nodes. Just four days prior, a mining pool server for the IOT platform HDAC was compromised, impacting the vast majority of miners. In January the largest-ever theft of cryptocurrencies occurred against the exchange Coincheck, resulting in the loss of US$532 million in NEM coin. Due to its increased popularity and profitability cybercriminals have been targeting all things blockchain. McAfee Advanced Threat Research team analysts have now published the McAfee Blockchain Threat Report to explain current threats against the users and implementers of blockchain technologies.

What is Blockchain?

Even if you have not heard of blockchain, you have likely heard of cryptocurrencies, namely Bitcoin, the most popular implementation. In late 2017 Bitcoin reached a value of $20,000 per coin, prompting a lot of interest in the currency—including from cybercriminals. Cryptocurrencies are built on top of blockchain, which records transactions in a decentralized way and enables a trusted “ledger” between trustless participants. Each block in the ledger is linked to the next block, creating a chain. Hence, the system is called a blockchain. The chain enables anyone to validate all transactions without going to an outside source. From this, decentralized currencies such as Bitcoin are possible.

Proof-of-work blockchain. Source: https://bitcoin.org/bitcoin.pdf.

Blockchain Attacks

Attackers have adopted many methods targeting consumers and businesses. The primary attack vectors include phishing, malware, implementation vulnerabilities, and technology. In a phishing scheme in January, Iota cryptocurrency lost $4 million to scams that lasted several months. Malware authors often change their focus. In late 2017 to early 2018 some have migrated from deploying ransomware to cryptomining. They have been found using open-source code such as XMRig for system-based mining and the mining service Coinhive.

Source: McAfee Labs

Implementation vulnerabilities are the flaws introduced when new technologies and tools are built on top of blockchain. The recent EOS attack is one example. In mid-July 2017 Iota suffered an attack that essentially enabled attackers to steal from any wallet. Another currency, Verge, was found with numerous vulnerabilities. Attackers exploiting the vulnerabilities were able to generate coins without spending any mining power.

Known attacks against the core blockchain technology are much more difficult to implement, although they are not unheard of. The most widely known attack is the 51% attack, or majority attack, which enables attackers to create their own chains at will. The group 51 Crew targeted small coins, including Krypton, and held them for ransom. Another attack, known as a Sybil attack, can allow an attacker to completely control a targeted victim’s ledger. Attempts have been made for larger scale Sybil attacks such as one in 2016. 

Dictionary Attacks

Blockchain may be a relatively new technology but that does not mean that old attacks cannot work. Mostly due to insecure user behavior, dictionary attacks can leverage some implementations of blockchain. Brain wallets, or wallets based on weak passwords, are insecure, yet people still use them. These wallets are routinely stolen, as was the case with the nearly BTC60 stolen from the following wallet:

This wallet recorded two transactions as recently as March 5, 2018. One incoming and one outgoing transaction occurred within roughly 15 minutes. Source: https://blockchain.info.

Exchanges Under Attack

The biggest players, and targets, in blockchain are cryptocurrency exchanges. Cryptocurrency exchanges can be thought of as banks in which you users create accounts, manage finances, and even trade currencies including traditional ones. One of the most notable incidents is the attack against Mt. Gox between 2011‒2014 that resulted in $450 million of Bitcoin stolen and led to the liquidation and closure of the company. Coincheck, previously mentioned, survived the attack and began reimbursing victims for their losses in March 2018. Not all recent exchanges fared so well. Bitcurex abruptly closed and led to an official investigation into the circumstances; Youbit suffered two attacks, leading the company into bankruptcy.

An advertisement for the shuttered Polish exchange Bitcurex.

Conclusion 

Blockchain technologies and its users are heavily targeted by profit-driven cybercriminals. Current attackers are changing their tactics and new groups are entering the space. As more businesses look to blockchain to solve their business problems and consumers increasingly rely on these technologies, we must be diligent in understanding where the threats lie to achieve proper and tailored risk management. New implementations must place security at the forefront. Cybercriminals have already enjoyed successes against the users and implementations of blockchain so we must prepare accordingly.

The post Threat Report: Don’t Join Blockchain Revolution Without Ensuring Security 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.