Maltese cryptocoin broker Foris DAX MT Ltd, better known by its domain name Crypto.com, experienced a multi-million dollar “bank robbery” earlier this month.
According to a brief security report published yesterday, 483 customers experienced ghost withdrawals totalling just over 4800 Ether tokens, just over 440 Bitcoin tokens, and just over $66,000 in what are listed only as “other cryptocurrencies”.
Using approximate conversion rates for 17 January 2022 (ETH1=$3300 and BTC1=$43,000), which is when the spurious transactions were spotted, puts the total loss due to this heist at about $35,000,000.
What went wrong?
Crypto.com claims that “all accounts found to be affected were fully restored”, which we assume to mean that customers with phantom withdrawals were reimbursed by Crypto.com itself.
Details of how the crooks pulled off the attack aren’t given in the report, which says simply that “transactions were being approved without the 2FA authentication control being inputted by the user.”
What the report doesn’t explain, or even mention, is whether 2FA codes were entered by someone – albeit not by customers themselves – in order to authorise the fraudulent withdrawals, or whether the 2FA part of the authentication process was somehow bypassed entirely.
This means we can’t easily tell how or why the 2FA process didn’t work properly, though several possible explanations spring to mind.
If you’re interested in looking at how your own 2FA system might fail, you will need to consider a long list of possibilities, including:
- A fundamental flaw in the underlying 2FA system. For example, an SMS-based system of one-time numeric codes that was based on a defective random generator might produce guessable sequences that could allow attackers to predict the right code to enter for some or all users.
- A breach of the 2FA authentication database. For example, an app-based code generator system typically relies on a shared secret known as a seed, which can’t be stored as a hash like a regular password. Both client and server must have access to the plaintext of the seed at login time, so a server-side breach could give an attacker the details needed to compute the one-time code sequences for some or all users.
- Poor coding in the online login process. A badly-configured authentication server might inadvertently allow the client-side login request to manipulate the configuration settings used, for example by including undocumented HTTP headers or adding special URL parameters that unexpectedly override existing security precautions.
- Weak internal controls to detect risky behaviour by support or IT staff. For example, overly helpful (or wilfully corrupt) insiders might not be subjected to peer review, or second sign-off, for critical account changes. This is how the infamous Twitter hack of 2020 happened: high-profile accounts such as Joe Biden, Elon Musk, Barack Obama, Bill Gates, Apple and others were taken over due to helpful support staff allowing the attackers to alter the email addresses used to secure those accounts.
- Fail-open behaviour in the authentication process. Access control system sometimes need to fail closed, for example so that no one can sneak in if the system breaks, and sometimes need to fail open, for example so that no one gets locked in during an evacuation emergency. Unexpected reasons for a system to break can lead to incorrect failure modes that leave the system incorrectly configured, such as unlocked for everyone when it should be shut down entirely.
What happened next?
Crypto.com claims that it has “migrated to a completely new 2FA infrastructure”, apparently out of “an abundance of caution”.
We’ve never quite understood what the words “an abundance of caution” are supposed to mean, given that cybersecurity overreactions can be as costly and as counterproductive as underreactions, but it seems to be a must-say phrase in contemporary breach reports, as if thoughtfully taking appropriate precautions is no longer good enough.
After all, if the root cause of your 2FA failure was reason (1) above – an intrinsic shortcoming in the 2FA system itself – then making a root-and-branch change by swapping it for a whole new 2FA technology seems appropriate.
But if the root cause was reason (5) above – support staff too easily able to authorise account resets – then changing the underlying 2FA technology might make little or no difference.
What to do?
- If you’re a Crypto.com customer, you’ll need to re-configure your account to use the new system. Notably, there’s apparently now a 24-hour sunrise period for adding new accounts for balance transfers. This is intended to add extra time for you to spot, or to be warned about, unexpected account changes attempted by crooks.
- If you’re looking at adding 2FA to your own online services, don’t just test the obvious parts of the system. Make sure you consider all points of interaction with the rest of your system, and consider hiring penetration testers to probe for unexpected types of failure.
- If you’re in PR or marketing, make the whole company practise how it will react if a breach should occur. This doesn’t imply you are expecting to fail. But it does mean that if you get caught out, the legally and morally necessary process of communicating with your unfortunate customers won’t suck up planning time that would be better spent on researching and properly fixing the problem.