Bitcoin Payment Processor BitPay Loses $1.8M in Phishing Hack
americanbanker.com
americanbanker.com
2. CFO enters his Google credentials on a random website
3. CEO takes CFO e-mail as valid without checking for the existence and verifying a PGP signature
4. CEO sends Bitcoin for an existing customer to a new address he got by e-mail rather than to the established one
On the positive side, the CEO eventually sought confirmation from the customer.
Sorry for your loss BitPay, but that's on you.
Of course, the fact that he's asked for a password while being already logged in on Gmail is also suspicious, but less so since other sites do that.
While I haven't see it reported whether or not they had 2fa enabled, we can hope that they had taken this very basic security measure.
Actually one of the best preventions against this is using a password manager. I was nearly caught by a phishing site once, and I only noticed because 1Password was refusing to autofill the password field.
That's correct, but the effect was the same as a system hack.
Come on.
I wouldn't touch insuring Bitcoin hot wallets with a twelve foot pole. Cold storage, maybe, but only if I had my experts set it all up and maintained control over all private keys.
But the loss limit, as with the Hartford policy, would be so low compared to the risk as to render it largely useless. I mean come on, I have a higher loss limit on my freakin car insurance than BitPay has to cover their hot wallet balance.
To date, as far as I am aware, insurers will only write policies to cover small losses on hot wallet balances. Most of the big exchanges and processors are probably well-capitalized enough that they could in effect self-insure against such a loss. And the larger magnitude risk of a deeper-level intrusion, or flat out physical robbery of the private key components for cold wallets, is not insurable.
Hell, the CEO shouldn't even be handling these transactions. I don't know of a single other place where the CEO would be this involved, especially if transfers of this size are "routine". This is just poor accounting top to bottom.
Keybase makes it pretty easy. You can see all of our keys here: https://keybase.io/coinbase
Once it's out its out, with normal transactions both parties can hold, revoke, and reverse a transaction this doesn't work with Bitcoin.
It doesn't matter into how many keys you split your private key it's still a single entity even if within the organization there will be more than 1 person needed to authorize it.
You'll find it's very hard to fool a bank or a financial institution to authorize a transaction in this manner, it's still is possible under some cases but then you'll need much more information to do it to the point of it being an "insider fraud" than just phishing.
Companies are still vulnerable to this sort of phishing you'll be surprised how many fake invoices are sent to large organizations and just how many of them end up being actually paid out. In most cases those invoices tend to fall under the "petty cash" category so they are often not very well checked and if you send out 500,000 invoices a year to companies even a small percentage of those being paid is still a nice take.
Now back to financial organizations, you can't just make a transfer from bank a to bank b and expect it to work there will be huge scrutiny on even fairly small sums, yet alone millions, the funds will also be frozen for a quite long period of time (2-3 business days at the least) and in many cases will not be liquid for at least another such period.
And most importantly regular bank transactions can be reversed and those which can't are insured.
Bitcoin exchanges seem to be too cool to adopt the same level of regulatory mandated processes that even the smallest financial institution has to adopt. And the fact that pretty much not a single Bitcoin exchange is insured against fraud and the fact that bitcoin transactions are for the most part "anonymous" and there is no way to revoke, or reverse them means that even the smallest case of fraud can bring down the entire exchange.
- Why was the Google Account of a CFO (of a financial organisation) not secured with 2fa (most likely) and if it was how could it be breached?
- Why did the CEO just sent the money ("an hour later" suggests that no much research could be done)?
- Why did he send it the second and third time and only then CC the "customer" company?
- Was there a paper trail of the fake purchase (order / confirmation / invoice etc) and if yes how could it be forged if no why didn't it exist?
I suppose there are some details missing in this article and the attack was probably sophisticated and well prepared, however this is something you have to prepare for.
If you are a financial service dealing with substantial amounts of money you have a red mark painted on your back at all times and since trust (in you, your organization and the whole bitcoin community) is one of your major assets an incident like must not to be taken lightly (I don't think it will)
You have for the most part armatures and an unregulated industry playing with millions without any checkpoints.