It’s time to give a status update on the Suspicious File / Vulnerable Wallet incident, which we first announced as a critical warning in November of 2017, with a later update on December 17th. We’ll provide a brief summary in a moment, but here’s the current status:
Of about 77.5 BTG that were Evacuated for safety, more than 75% have been returned to their rightful owners!
We’re glad to be able to report this progress, and we appreciate the patience and understanding of the victims we’ve worked with.
Background
Ok, here’s a recap of what happened, followed by the additional news we’re sharing today.
A malicious third party (“The Thief”) managed to insert a doctored version of our Windows Core Wallet Installer onto our GitHub site back in November of 2017, and a few people downloaded it before we found out and locked things back down. The planted wallet software appeared to work normally, except for one thing: any newly created wallets had super-weak encryption. They were Vulnerable to theft.
The Thief’s plan was clear: if Vulnerable addresses were getting created, and people put their BTG in them, those addresses would appear on the blockchain (the act of putting coin into a wallet puts the address on the blockchain). The Thief could watch for Vulnerable wallets to appear and wait for BTG to accumulate in those wallets – perhaps a lot of BTG – and when they were ready, they could snatch the contents.
But, since we figured this out (with the help of security experts), we were able to snatch the coins before The Thief could! We watched for coins to be deposited in Vulnerable addresses, and then Evacuated those coins into a safe address for holding until the rightful owners could be identified. We’ve been working on getting those coins back to people, ever since.
The Thief surely hoped that their phony software would be downloadable for a long time, and that a lot of Vulnerable wallets would be created…. but because we were alerted to the problem quickly and were very vocal with our warnings, very few such wallets got created and funded – only about 30 of them. After the evacuations, we set about trying to find the victims… but, as you can imagine, it’s just about impossible to track down an individual based solely on their wallet address – we really rely on people to reach out to us or to mention their address on Social Media. That’s why we published all the affected addresses back in our December update.
Today
So that’s the summary – here’s the news: we got a total of just under 77.5 BTG into our safe wallet address, and have returned more than 75% of them! Of course, that means we still have some coins to return. Anyone who is the rightful owner of one of the addresses in the December post should reach out to our support staff so that we can work with them. Confirming the rightful owner of a wallet can be slow and frustrating, but we need to be sure we’re not giving the coins back to the wrong people. We still hope we get to return all the Evacuated funds, no matter how long it takes. Note to all the frauds out there: the evacuated wallet address with the largest sum has already been returned to the rightful owner; stop asking!!!
Also, now that we’re releasing all the details of how this scheme worked, it’s possible for someone to stage a phony “theft.” Although the phony software was only briefly downloadable and no Vulnerable wallets have appeared for a long time, our detailed technical description below could enable someone to re-construct a weak wallet and “steal” their own funds and try to make a claim with us! It’s important to note that we will only be returning coins which actually made it into our safe custodial address. While it may seem obvious, it bears saying: we can only return coins we actually took.
But when we do get in contact with the rightful owner of any of the evacuated coins, we’re happy, because it gives us the chance to make the owners happy by safely giving them their coins.
Happy People
This happens when coins are returned! Here are a couple of quotes from such people, used with their permission:
“Amazing news! All of my BTG’s has returned to me, and now I am fully happy!
I want to thank you personally and the whole Bitcoin Gold team for the prompt actions taken to correct the situation with the compromised Bitcoin Core file posted on your website. These actions deprived the attacker of the opportunity to steal my (and not only my) BTG’s. And I’m very pleased that your team consists of such honest and good people!”
And another:
“I am very grateful to you for the return of my coins…
In general, after I saw the outgoing transaction from my wallet, I did not even hope to return the coins.
You revived my belief in the honesty of this project and in the honesty of the development team.”
How did we do this?
A lot of people have been wanting to know more about how the wallets were “vulnerable,” and how we (and The Thief) are “spotting” the wallets. Down below, you’ll see a full wallet report and analysis from h4x3rotab, our Lead Developer, but here’s a plain-English explanation, for the less-technical:
When a new wallet address is being created, the software starts with a “random seed.” The security of that wallet will be dependent on that seed. The longer the seed, the harder it would be for an attacker’s computer to “guess” it. Good wallet software, like ours, builds a seed that’s 32 bytes (256 bits) long. If you have a 256-bit seed that’s random, you have 2^256 possible starting numbers. For someone to “guess” that number they’d have to try up to 2^256 times. That’s such a huge number that it’s unimaginable for most people. In Scientific Notation, it’s 1.15792E+77, but if you wrote it out as a regular number, it’s:
115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936
To get a rough idea of the scale of that number: it’s vastly larger than the number of atoms in the entire Milky Way Galaxy (which includes hundreds of billions of stars like our own sun.) The fastest computer today, running continuously, could take millions of years to go through all those numbers!
But The Thief sabotaged the code for the random seed so that it only includes 2^40 staring numbers. That means only 1,099,511,627,776 possible answers. One trillion possibilities is still a lot, and the results still look random, but it’s no longer incalculable! But it gets even weaker than that… The way the Thief did it, most of that is based on the time of creation – and we knew that all of these Vulnerable wallets were created within a particular range of dates. Knowing the dates, the list of possible private keys gets even smaller – only a couple of billion. That’s definitely something we can calculate.
And calculate is what h4x3rotab did – writing code to figure out all the possible private keys that could come from this sabotaged seed in the relevant date range, and running that against all the wallets we saw appearing on the BTG blockchain to find the few that were Vulnerable. We kept tabs on the funds going into those wallets, and eventually Evacuated those funds for safety, as we previously announced. This is almost certainly what The Thief intended to do, but they probably weren’t expecting us to do it, first!
The timing of the Evacuation was a little dicey. If any of the Vulnerable balances became very large, we would have Evacuated the funds sooner than we did, but we also had to evacuate them all at once: if the Thief realized we were on to their plan, they might steal the contents of the other addresses. At the same time, we didn’t want to Evacuate the funds prematurely, while we still saw new vulnerable addresses showing up on the blockchain – that would just set up a race between our team and the Thief, trying to snatch new Vulnerable wallets as they appeared – and it would be a toss-up, each time. But, soon enough, the rate of new Vulnerable wallets appearing on the blockchain dropped off, and we made our best guess at when to secure the funds to prevent the Thief from getting them. At the time, we also made a PDF of our intentions and recorded it using a timestamp service, so that we could later be transparent about the whole thing. (The PDF and files necessary to validate the timestamp appear at the very bottom of this post.)
Summing up today’s post:
- after analyzing the phony software, we calculated the possible Vulnerable wallets
- we watched for these wallets to appear and then evacuated the contents for safety
- we’ve been working with victims that come forward to return their funds to them
- and now we’ve published all the details
Closing Words
We’ll forever regret that this incident ever happened. Though the security for our systems is vastly improved since then, we can never go back and undo what happened. But, given some of the other events we’ve all seen in the news, we’re lucky that this was an incident of manageable size. It gives us some consolation that we’ve been able to return most of the funds, and we still have hope of returning the rest.
We’ll keep watching and working to return these funds, and to help our community stay safe however we can.
Sincerely,
The Bitcoin Gold Organization
#1CPU1VOTE
Below, you’ll find a more robust technical analysis; a similar version has been recently published on our GitHub.
Bitcoin Gold Windows Wallet Analysis
Abstract
The Windows installer file on the BTCGPU release page (the Bitcoin Gold project) was replaced by an unknown party. Further investigation indicated that the installer file didn’t contain any virus or trojan, nor upload anything via internet. However, the private key generation process of the wallet was intentionally weakened, which would theoretically allow an independent attacker to reconstruct the private keys generated by the phony software. The Bitcoin Gold team took action to protect all such wallets in danger as soon as the technical details of the scheme were identified.
Now that the majorify of the affected coins have been returned to their owners, and no current activity is seen in any Vulnerable wallets, we’ve decided it’s time to share the technical details with the community.
The problem
We first became aware of the problem we saw GitHub issue #231. With the assistance of GitHub support, we determined that the unknown party had planted different versions of the Bitcoin Gold Windows installer which were downloadable by the public between November 21, 2017, 09:39 UTC, and November 25, 2017, 22:30 UTC.
There were two known version of installer uploaded by the unknown party. Here are their sha256 checksums:
- 20171121: 0ccbae26914fc36973c5b74f0c031ba324bcffc7bbb188e752498573345215d5
- 20171126: 8e9d4cb73116beb173d6079792d474ba29488c6de30a05d2d77bff7850c80b0d
The checksum of the official installer is:
53e01dd7366e87fb920645b29541f8487f6f9eec233cbb43032c60c0398fc9fa
These installers were presumed to be shipped with some form of malware and a strong warning was issued to the community on November 26th.
As publicly stated, the malicious files were taken down, security protocols were enhanced to avoid a similar problem, and investigations proceeded.
Investigation
No virus, trojan, or uploading
We began by uploading these installers and the files extracted from them to VirusTotal, which found no known virus or trojan.
We also sent the unknown installers to security experts to analyze.
Weakened private key
We performed a BinDiff and reverse engineered all the installer and the binaries files inside. The installers themselves, and most of the binaries, had not been modified. Affected binaries included:
bgoldd.exe: The daemon of Bitcoin Gold Core client.bitcoin-qt.exe: The GUI of Bitcoin Gold core client.bgold-cli.exe: The command line tool to control the daemon.
Though three files are affected, the diff shows that the only modified function is
CKey::MakeNewKey.
The CKey::MakeNewKey (code) is used to generate private keys from entropy, 32 bytes of random numbers (256 random bits).
We found that in the vulnerable wallet, the private keys are not generated by 32 bytes of strong random numbers. Instead, the 32 bytes entropy has been replaced by:
sha256([4 bytes: timestamp (in sec)] + [1 byte: random number] + [27 bytes: constants])
The safety of private key relies on the fact that there are nearly 2^256 possible private keys in total. In order to crack a wallet by brute force, an attacker has to try all of them in theory, which will take millions of years with modern hardware. So the strength of the crypto algorithm heavily depends on the random number generator.
However, in the vulnerable wallet, the entropy is a function of timestamp and a 1-byte random number, which means the number of the possible private keys is reduced from 2^256 to 2^40. The range of possible keys has been reduced by a factor of 2^216. To make it worse, as victims can only generate a private key after downloading the software, the timestamp must be later than the Nov 21st, 2017.
A weak wallet means that the attacker can reconstruct its private key.
Conclusion
Though the vulnerable wallet software didn’t appear to spread viruses, trojans, or upload private keys to the internet, all the new wallets created by the vulnerable wallet software have weak private keys and can be reconstructed by an attacker. The details about how to exploit are described next.
Exploit
All Bitcoin Gold (as well as Bitcoin) addresses are derived from public keys, which are ultimately derived from private keys. If we can generate all the possible private keys, then it’s trivial to check if the corresponding addresses are on the blockchain and have coins inside. The only problem is how large the search space is.
Given the private key is a function of timestamp and a 1-byte random number, the search space is:
key_space = (timestamp_to - timestamp_from) * 256
In practice, Bitcoin utilizes a technology called “Hierarchical Deterministic wallet” (HD wallet). Instead of generating private keys for all the addresses you use, it can derive unlimited private keys from a single master key. The derived key can be expressed by a function:
derived_key = bip43_derive(masterkey, internal_or_not, id)
where internal_or_not can be 0 or 1, id increases from 0. Depending on the search depth, id will usually range from 0 to 200.
Putting all these things together, the search space is:
search_space = (timestamp_to - timestamp_from) * 256 * 2 * search_depth
Assuming the timestamp is ranged from Nov 21th to Nov 30th and the search depth is 20, the search space is just under 7 billion. It takes half a day to check the generated private keys for corresponding balances in the Bitcoin Gold blockchain with a modern computer.
What we did to protect users
- We timestamped the actions we were about to take on OpenTimestamp.org.
- Used the methods described above to scan for and track all the Vulnerable wallets.
- Swept the money from the Vulnerable wallets to a safe address before they could be hacked by the hacker.
- Monitored for the mention of all Vulnerable wallet addresses on social media and through Google.
- Reached out the victims to return the money.
- After a few days, when we found there were no new vulnerable wallets appearing on the blockchain, and no incoming coins to vulnerable wallets, we announced the actions we had taken and published the wallets addresses so that victims could contact us.
- Finally, with the majority of the funds returned, we revealed the technical details of the exploit.
Our initial Evacuation Notice was timestamped Dec 3 02:34:01.612396 2017 GMT using freeTSA.org; interested parties can download the PDF, TSQ, and TSR files here to confirm for themselves.