• J
  • No Comments

The Attack on Binance

The first major hack of Binance occurred yesterday. 7,074 BTC were stolen from Binance’s hot wallet. In a press release, Changpeng Zhao, Binance’s CEO stated :

We have discovered a large scale security breach today, May 7, 2019 at 17:15:24. Hackers were able to obtain a large number of user API keys, 2FA codes, and potentially other info. The hackers used a variety of techniques, including phishing, viruses and other attacks. We are still concluding all possible methods used. There may also be additional affected accounts that have not been identified yet.

Much of what I am suggesting are based on assumptions of how the events unraveled. I aim to address the best security practices that organizations should have in place. This all assumes that everything Binance stated is true as well. There isn’t much information about the attack available yet. For various reasons Binance has not disclosed the exact points of penetration. If there are still security vulnerabilities, Binance would want to correct these before disclosing what the definitive issues were. Binance also does not want to alert the attackers, if the attackers are still inside their network infrastructure, that Binance knows how they breached the network. This would allow for the attacker to play a game of cat and mouse and further their unwanted stay.

From the security release and from CZ’s AMA that followed a few hours later, he mentioned that every account should change their API keys as well as 2FA keys. This would lead me to believe that this breach could have affected the seed generation for both the API keys and 2FA keys. This centralized creation of keys will always be a point of vulnerability. Technology in the recent years has allowed for end-users to be able to create and manage these keys. If created client-side, the new risk would then shift to making sure the user properly uses/stores these keys.

Notes for Binance

Binance supports SMS and TOTP for 2FA. SMS 2FA is broken and the security vulnerabilities around using SMS as 2FA have been discussed in great depth. It is completely broken. TOTP suffers from DNS-jacking attacks. There is also the concern that the TOTP seed is generated server-side. If the attackers were able to penetrate Binance and obtain access to that seed, then they could potentially have access to every end-user’s 2FA generation seed.

FIDO2 and Hardware tokens with keys generated client-side would help to diminish these attacks. User error is still a large concern and this looks to be the largest culprit for the attack. The attackers did not immediately attempt to extract the BTC once they had a single account. They instead chose to pick a more optimal time to extract the funds. The attackers then were able to withdraw the more than 7,000 BTC in one transaction. Previously, I wrote a post when Binance had successfully stopped an attack similar to this by halting a large withdrawal before it could fully execute. This previously mentioned security incident occurred around May 2018. Binance was not able to stop it this time.

Binance has separate fund (titled the SAFU fund) for hacks like this, but if a large portion of this attack is due to user error. Binance can’t afford to always be on the hook for the poor security skills of its end-user (This of course hinges on the fact that it was end-user control issues, like Binance stated). Binance should implement mandatory security measures.This becomes an issue with convenience but as we see in this space and the security space in general, you cannot have both. You can only have either convenience or security.

Bitcoin Re-organization?

An issue that was mentioned as a possible solution is a re-organization of the BTC chain. There was outcry from the crypto community for various reasons. I won’t address the philosophical issues that come from this question. I come at this question from the perspective of a security researcher. There would need to be a strong reason for the mining network to collude long enough to execute a re-org. CZ stated that it was just an idea that was “brought up by the community”. The bitcoin network is strong enough and large enough that it would be very difficult to get a consensus on the network.

The miners might not be incentivized enough to plot revenge on the hackers of Binance for monetary gain alone. The incentive motive might not be enough to get enough miners on board. The Nakamoto Consensus creates barriers for these kinds of attacks and shows that the true decentralized nature of the network doesn’t allow for individuals, corporations, or enterprises to just reset the ledger. For clarification, CZ did state that it was just an idea he was just informed about and it doesn’t seem like they are pursuing this route. CZ tweeted:

After speaking with various parties, including @JeremyRubin, @_prestwich, @bcmakes, @hasufl, @JihanWu and others, we decided NOT to pursue the re-org approach. Considerations being:

pros: 1 we could “revenge” the hackers by “moving” the fees to miners; 2 deter future hacking attempts in the process. 3. explore the possibility of how bitcoin network would deal with situations like these.

cons: 1 we may damage credibility of BTC, 2 we may cause a split in both the bitcoin network and community. Both of these damages seems to out-weight $40m revenge. 3 the hackers did demonstrate certain weak points in our design and user confusion, that was not obvious before. cons: 4 While it is a very expensive lesson for us, it is nevertheless a lesson. it was our responsibility to safe guard user funds. We should own up it. We will learn and improve. As always, thank you for your support!

What Now?

For the user that was affected by this hack. kudos to you that Binance had enough forward thought to prepare for this event. The breach could have been much worse as well. It’s not to say that 7,074 BTC is a small amount, but as history has shown us, when large scale hacks hit exchanges, it tends to leave the exchanges in a poor financial state. If you are using exchanges to store your assets, then I’m sure what ever I am writing here won’t change your mind.

You shouldn’t be storing your assets for long-term on the exchange. Only keep the exact amount of crypto on the exchange that you can afford to lose. It isn’t a matter of IF the exchange will get hacked. It’s a matter of WHEN. Every single thing exposed on the internet is vulnerable, but it comes down to how difficult it is to break into your container/infrastructure. If you are a large instituional holder, you should look to maintain control/ownership of your private keys. There is always the risk of insider threat, even if you fully trust your service, if you do not possess your keys, you do not have a proper claim to the asset.