---
BGP Hijacking for Cryptocurrency Profit
Author: Pat Litke and Joe Stewart, Dell SecureWorks Counter Threat Unit
Date: 7 August 2014
Overview
The Dell SecureWorks Counter Threat Unit™ (CTU) research team discovered an unknown entity repeatedly hijacking networks belonging to Amazon, Digital Ocean, OVH, and other large hosting companies between February and May 2014. In total, CTU researchers documented 51 compromised networks from 19 different Internet service providers (ISPs). The hijacker redirected cryptocurrency miners' connections to a hijacker-controlled mining pool and collected the miners' profit, earning an estimated $83,000 in slightly more than four months.
Mining fundamentals
In cryptocurrency, "mining" is the act of validating transactions listed in the public ledger (also known as the block chain). When a transaction is initiated, it is placed in a queue where it is prioritized based on the date and time of submission, and the size of the affixed transaction "fee." Working from the top of the queue, miners cryptographically attempt to "find a block," which entails crunching numbers to satisfy a particular formula while simultaneously agreeing as network that the calculated results are valid. Mining is a generic activity; the mining pool dictates which cryptocurrency is mined.
Each time a miner finds a block, new bitcoins are created. The number of new coins that are created varies; as of this publication, 25 new coins are minted for every block found. The miners who contributed to finding the block are awarded a percentage of a "block reward," which amounts to the sum of the 25 newly created bitcoins plus the total of all fees from transactions in the block. The percentage is based on the miner's individual contribution to the discovery. This process allows miners to make money by using their computing resources to verify transactions for other users.
AddressesAddresses are "accounts" that can receive funds. In cryptocurrency, these addresses are long strings of numbers and letters that correlate to a "private key." The private key is first used to generate the address, and subsequently allows a user to transfer or "spend" currency. A user may receive currency without a private key, but must have the private key to spend the cryptocurrency.
StratumMiners begin the mining process by contacting a pool server, which sends information to the miner, tracks individual miners' work, and pays rewards accordingly. The pool server can send commands with the work to have a miner perform various tasks, such as reconnecting elsewhere for load balancing. Miners communicate with the network using the Stratum protocol, which is a JSON-based TCP connection. Once a TCP connection is established, JSON is transferred between the miner and the pool server, allowing communications to be easily monitored.
Hijacking discovery
On March 22, 2014, a user named "caution" posted a message in the bitcointalk.org forum indicating that suspicious activity was occurring on mining systems connected to the wafflepool.com mining pool (see Figure 1).
Figure 1. Bitcointalk.org forum message indicating suspicious activity. (Source: bitcointalk.org)
Several users in this forum and other cryptocurrency forums noticed similar activity — mining systems mysteriously redirected to an unknown IP address that answered with the Stratum protocol. Once connected to this IP address, miners continued to receive work but no longer received block rewards for their mining efforts. Hijackers harnessed miners' hashing power by redirecting legitimate mining traffic destined for well-known pools to a malicious server masquerading as the legitimate pool: Miners continuously connect to a legitimate pool for tasks.
The hijacker begins an attack
When miners attempt to connect to the legitimate pool, a new BGP route directs their traffic to a pool maintained by the hijacker.
This malicious pool sends each rerouted miner a client.reconnect command, instructing them to connect to a second pool maintained by the hijacker. By convincing the miners to connect to this second malicious pool rather than the original malicious pool, the hijacker filters out traffic that has already been hijacked so it is not hijacked again.
The hijacker ceases the attack. Miners that were redirected to the hijackers pool continue to see tasks and perform work, but are not compensated. Miners who were not redirected remain unaffected.
The hijacker repeats the process in short bursts, allowing the activity to continue unimpeded for months.
BGP fundamentals
Border Gateway Protocol (BGP) is an external routing protocol that connects networks on the Internet. Networks use BGP peering to become aware of other networks' existence. Unlike network routing protocols that can automatically initiate a connection from one network, both ends of BGP-connected networks (also known as a "peers") must be manually configured to communicate. This requirement ensures malicious networks cannot hijack traffic without human intervention from a legitimate network.
Figures 2, 3, and 4 show how threat actors used bogus BGP broadcasts to redirect traffic to the hijacker's server.
Figure 2. A broadcast of the malicious route in progress. Because AS3 is 'peered' with AS4, the malicious broadcast is accepted. AS3's broadcast is more specific than AS2's broadcast, so BGP prioritizes it above the AS2 broadcast. (Source: Dell SecureWorks)
Figure 3. Route to legitimate pool server before hijacking. (Source: Dell SecureWorks)
Figure 4. Route to malicious pool server after hijacking. (Source: Dell SecureWorks)
Timeline of hijacker's BGP announcements
Although public reports of hijacked miners began on March 22, 2014, CTU research into historical BGP route announcement data indicates that the hijacking attempts began on February 3. In total, CTU researchers documented 51 compromised networks at 19 different Internet service providers, including Amazon, Digital Ocean, OVH, and other large hosting companies. Appendix A contains a complete list of route hijacking incidents by date.
The data shows that the hijacker attempted to broadcast illegitimate routes for an entire week in February. That activity was apparently unnoticed in the cryptocurrency mining communities, which may suggest that the initial hijacks were not successful.
CTU researchers contacted a hijacked miner who lost profits over a period of a few weeks. Figure 5 charts the output of his mining activity over the time period in question. CTU researchers observed the correlation of hijacking events and the payouts normally received from his mining pool (called Hashfaster). The threat actor hijacked the mining pool, so many cryptocurrencies were impacted. The protocols make it impossible to identify exactly which ones, but CTU researchers have mapped activity to certain addresses.
Figure 5. Dogecoins earned by hijacked Hashfaster miner. The miner did not immediately notice the hijacks at the end of March, leading to a long gap in earnings. The hijacks in April were caught faster. (Source: Dell SecureWorks)
By adding a firewall rule to block traffic destined to the hijacker's mining server, the miner was able to reject the hijack on April 11. His payouts then resumed their regularity. Although the 8000 lost Dogecoins amounted to a few dollars, hijacking hundreds or thousands of small miners can be very lucrative.
Estimating the hijacker's earnings
The hijacker earned an estimated $83,000 in slightly more than four months. The graph in Figure 6 represents the estimated earnings for the five cryptocurrency addresses associated with the hijacker. This graph is incomplete due to a lack of data from March 29 to April 11, 2014. While Figure 6 does not prove that other payout addresses exist, it does strongly indicate that other currencies were being mined.
Figure 6. Estimated earnings for hijacker-controlled cryptocurrency addresses. No data was available between March 29 and April 11, 2014. (Source: Dell SecureWorks)
Dogecoin, HoboNickels, and Worldcoin
These three currencies were easy to extrapolate from the datasets because a central authority communicates with the clients. Correlating payouts to hijack events strongly suggests that the addresses in question belonged to the pool operator, who in this case happens to be the hijacker.
BitcoinDetermining the Bitcoin address was challenging due to the nature of the peer-to-peer protocol used by the decentralized P2Pool Bitcoin mining pool. CTU researchers examined all addresses from the respective pool server and compared them to addresses in the Stratum traffic. Matching hijack events with payouts revealed one address, charted in Figure 6.
AttributionAll malicious BGP announcements were traced to a single router at an ISP in Canada. The hijacker likely fits one of the following descriptions:
- A rogue employee of the ISP
- A rogue ex-employee of the ISP with an unchanged router password
- A malicious hacker
On May 9, 2014, the CTU research team provided the BGP evidence to the upstream ISP closest to the origin of the malicious activity. The malicious BGP announcements stopped three days later and have not resumed as of this publication. However, the ISP did not disclose details about the source of the malicious changes to the router's configuration.
Route hijacking mitigation
An estimated $2.6 million in cryptocurrency mining activity occurs each day. Every network administrator should prepare for the risk of narrowly-focused, malicious BGP hijacking incidents. ISPs should opt-in to the Resource Public Key Infrastructure (RPKI) service, which leverages the power of encryption to ensure that IP prefixes belonging to an ISP can only originate from specified ASNs.
From a cryptocurrency perspective, the easiest option for pool servers is to require miners to use the Secure Socket Layer (SSL) protocol. SSL prevents a system from being redirected to a different server, even if the IP address is the same. Miners should also implement server certificate validation. This validation ensures that the certificate the pool server sends when establishing the connection is valid and authorized for use with the connected domain, even if the domain's IP address changes.
ConclusionBGP peering requires that both networks be manually configured and aware of one another. Requiring human interaction for proper configuration makes BGP peering reasonably secure, as ISPs will not peer with anyone without a legitimate reason. These hijacks and miner redirections would not have been possible without peer-to-broadcast routes. Although BGP hijacking is possible, the overall threat is minimal.
Additional information
Litke, Pat and Stewart, Joe. "
Enterprise Best Practices for Cryptocurrency Adoption." Dell SecureWorks. January 27, 2014.
http://www.secureworks.com/resources/articles/featured_articles/enterprise-best-practices-for-cryptocurrency-adoptionLitke, Pat; Stewart, Joe; and Small, Ben. "
Cryptocurrency-Stealing Malware Landscape." Dell SecureWorks. February 26, 2014.
http://www.secureworks.com/cyber-threat-intelligence/threats/cryptocurrency-stealing-malware-landscape/---
Quelle:
http://www.secureworks.com/cyber-threat-intelligence/threats/bgp-hijacking-for-cryptocurrency-profit/
