Anatomy of an attack: How Coinbase was targeted with emails booby-trapped with Firefox zero-days Coinbase chief information security officer Philip Martin this week published an incident report covering the recent attack on the cryptocurrency exchange, revealing a phishing campaign of surprising sophistication. The thwarted attack began with email messages on May 30 to more than a dozen Coinbase employees that appeared to …
Odd that they’d be willing to burn a zero-day but not bother with a custom payload. The CVEs appear not to be restricted to Mac versions of FF, so I would hazard a guess they assumed MacOS is less likely to run AV/HID...
Spawning a shell from the browser, Word, etc. is lazy-fu. With opsec like that, I would suggest they bought the exploit.
Great investigation and write up though. Good to see some people taking security seriously.
This is actually very scary stuff: if someone is specifically targeting you, there's a very high chance you'll be p0wned even if you are fully updated.
Corollary: if you feel like you can be targeted, you should 1) Sandbox your web browser/mail client in a VM (which is also not a panacea) or even use them on a separate PC in a separate network 2) Your networks must be monitored at all times for any unusual behaviour 3) Your PC must be monitored for any unusual behaviour (new processes, crashes (which often indicate exploitable software bugs), executable files, document files with macros, etc.) 4) Probably you have to set up security policies such a way only a very limited set of software is allowed to run.
I have a different idea.
Someone, or ones, are watching the official Firefox repo, identified a bug in a not yet released commit, and then sat on it, working out how to attack it. Then, once that new code was in the production codebase and deployed as another godawful auto-update, they were ready with their exploit.
I imagine that 5-eyes, and every other government, do the same thing.
One question to the commentards: How hard is it to submit a bad patch for Firefox to Mozilla?
This post has been deleted by its author
No. It means that the fixed code is made public only when the fixed builds are made available too. Nothing secret, but the brief window required to not expose users to zero day vulnerabilities.
Disclosing vulnerabilities before would be irresponsible - would you like it in the Linux kernel or other critical code?
So just monitor the commits with a hidden bug description? Looks quite stupid to me. Moreover you can also process changes with some automated tools to spot those that have greater chances of being security fixes.
Again, I really hope they have more than one repo and code is promoted to public ones cautiously, when it comes to security fixes. Remember how long it took to fix Spectre/Meltdown, despite the fact exploiting them is not trivial at all.
I'd disagree. Using any standard diff tool, you'd be able to review each commit, see the before-and-after changes, line-by-line, and if you are a reasonably competent programmer, work out what they are for. I would expect that the mitigation for a privilege escalation flaw would be reasonably easy to recognise, even without explanatory comments (which any programmer worth their salt should be adding anyway); certainly a lot easier than spotting the flaw it is intending to fix. You'd also expect it to be fairly easy to spot things like fixes for buffer-overruns, as there's only so many ways you can write code to check the size of a payload before writing it to memory.
For these reasons, I'd agree with the OP and hope that such fixes go into a non-public branch that only gets merged into the public master branch at the point it gets released.
I dont work in IT so please correct me if I'm wrong, but it says in the article that the attackers registered the website they used for the attack 2 days before the attack started. Since from my understanding, you need a credit card to register a website, and I can only imagine that they would have used a stolen credit card for that (I doubt anyone is stupid enough to use their actual credit card for that purpose!), then would it be a significant security increase if there was a 4-6 week wait from registering a website until allowing it to go live? 4-6 weeks allows someone enough time to check their credit card statement, see the fraudulent transaction and get it cancelled before the attackers have a chance to get the website live.
Anyone see a major flaw in this idea?
Apart from the fact that this would have a major braking effect on businesses, are you so sure it is necessary to use a credit card to register a .com domain? What about domain registrars that accept bitcoin? If a credit card is required, it isn't beyond the ken of criminals to use identity theft to get a credit card in someone's name without their knowledge. How would the victim check the statements if they never know they exist?
A 4-6 week delay on a new website is going to have a brake on business? Really? I can maybe see that on a fly-by-nighter style business, but any actual business I'm pretty certain would take at least 4 weeks just to decide on the font of their website. I do not see it having any effect personally.
Domain registrars that accept Bitcoin does defeat this solution, although I would still suggest a 4 week delay puts a brake on the ability of the miscreants to utilise zero days and the like, since the firms have a month to spot and patch the flaws.
As for the identity theft you speak of, it's always a risk true, but I would suggest its a significantly harder and more time consuming (and riskier) task for the miscreants than using a stolen card number.
The solution I proposed may not solve all of the problems you mentioned, but it raises the bar on the level of skill the miscreants need, increases the time until a zero day can be effectively exploited (hopefully allowing time for patching), and increases the risk that the buggers might do something to expose themselves. It's not a catch all solution, but removing the low hanging fruit is always a good thing...
I've seen (small(ish)) businesses that *printed their business cards* before registering the domain they wanted. Which they ended up having to change, because the domain they wanted was already registered and Not For Sale. I've seen others who managed to score the domain, but only as a "premium" domain for a ridiculous price. (Think $5-10K for a .com, of no obvious significant value. No idea if these continue to cost huge bucks on renewal.)
Never underestimate the ability of business to totally not get this Internet thingy.
Okay, supposing you do get some legislation that puts a 4-week delay on domain registration. Where? In the UK? In the US? Or are you going to get the global government to enact it everywhere at once?
The main point here is that if you try to enact something like that, which puts a nation's registrars at a competetive disadvantage, people are going to go somewhere else.
Add ot that you'd ave the technical issue of enforcement. What's to stop someone registering a domain with the US registrar (.com) and then hosting it in, say, Eritrea, or Bangaladesh, or Tuvalu? Is the country where the host is located going to respect rules laid down by a foreign government? I know the US is famous for "exporting justice", but even that is a stretch too far...
...to add to that, might I point out that your proposal would do nothing whatsoever to prevent the Bad Guys™ from registering a whole bunch of domains 4-6 weeks in advance, ready for when they are going to use them, each with separate false or stolen credentials, or done via proxies ("Make easy money working from home registering domain names for us"). From the sounds of it, this attack was well-planned by intellgient individuals, and such a restriction certainly wouldn't have stopped them. If they were state actors, their parent state would probably have given them the false identities to register the domain under anyway.
I would still suggest a 4 week delay puts a brake on the ability of the miscreants to utilise zero days and the like, since the firms have a month to spot and patch the flaws.
The nature of zero-day exploits means that theya re very unlikely to be spotted by the firms that created them. It would require continuous reivew of code that is already in production. No company I know of would have the budget to do that. In the case of open-source code it may be a little more likely, but even then you are relying on enthusiasts to do those post-facto code reviews for you to pick up the subtle bugs that weren't caught in the first round of reviews. By their very nature, those are going to be hard to find.
Ok I'm just going to summarise my answers here rather than answer your individual posts.
1) ICANN would need to be the one to mandate this, not any individual country, if ICANN mandated a 4 week delay from registration to go live than, the registrars would be responsible and would have to administer this at the risk of losing their registrar licence. No nation would need to get involved.
2) Where the site wants to be hosted is irrelevant. If it's on the registrar to police, then the page remains under registrar control until the 4 weeks has expired. Again at risk of losing their licence they will maintain this and it doesnt add any particular burden to anyone.
3) Zero days are found by security researchers as a rule, not by the company who created the software, this is often by watching the forums where these exploits are sold. A month of being able to watch and learn about a zero day before its able to be put into use, increases the likelihood of patching before the zero day can be exploited. This is not a guaranteed cure of course not, I never said it is, but the longer an exploit is out there, the more likely it is to be spotted and patched.
4) This would not be a solution against nation states or extremely well funded/skilled hackers, I said that in my previous post, but it WOULD go a long way to removing the less skilled hackers, the skiddies, etc, as it would raise the bar for what is needed to make a scheme like this work. Obtaining enough fake credentials to obtain a credit card in someone elses name is difficult (definitely not impossible for the skilled, but difficult). Obtaining a stolen credit card number is a piece of cake that any skiddie can do. By removing the low level attacks from the network, you allow your defenses to refocus on the really dangerous threats. This wouldnt remove those dangerous threats/effects, but it could remove the fog caused by lots of skiddie attacks and allow the more dangerous attacks to be spotted earlier.
5) Was there a 5? Anyway, I'll leave it there. It's been nice chatting with you Loyal. :)
3) Zero days are found by security researchers as a rule, not by the company who created the software, this is often by watching the forums where these exploits are sold. A month of being able to watch and learn about a zero day before its able to be put into use, increases the likelihood of patching before the zero day can be exploited. This is not a guaranteed cure of course not, I never said it is, but the longer an exploit is out there, the more likely it is to be spotted and patched.
Except, in this case, the zero-day exploit was found by the attackers, and was spotted because it had also been found by a security researcher. Since there's more moeny to be made from crime than there is from security research, I would expect the bad guys to be better funded, and to be able to find the exploits first. It's not uncommon for software vulnerabilities to go for years before being found, and for researchers to only uncover them after they have been exploited.
Waiting 4 weeks would create problems and not solve any.
Put simply, organizations sometimes have to make quick decisions, or keep decisions (like a merger) quiet until they're announced. Any waiting period complicates things and might signal competitors and investors.
Attackers have time to prepare before they attack. "Do I think I might attack someone in 2 months? What about 6 months? Next year? I do? *buy domains*"
All company PCs should be set up and administered only by the company IT person/department - especially in a company that holds valuable or sensitive data. Normal employees should not have the access rights to install any software at all except by asking the IT department to do it. No personal devices should be permitted on the company LAN (if necessary provide a safe alternative route to the Internet for personal devices).
I won't claim my shoppe is 100% locked down, but defences we have in place to address this sort of threat
- Exchange Online Safelinks to pass all links via MSFT's engine looking for malicious links
- All browser internet access proxied via ZScaler to block malicious payload downloads (SSL break/inspect on HTTPS)
- Exchange Online Protection drop all email attachments containing scripts and binaries
- EOP Safe Attachments open all other attachments in sandbox to look for malicious behaviour/zero day exploits
- Quarantine email that fails DMARC/SPF/DKIM checks
- Domain impersonation checking/phishing detection
- All users run least-privileged to block installers
- Windows Applocker to stop unsigned/unknown binaries running
- Client devices run standard build, no BYOD
- Anti-virus on client devices
Basic stuff really.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
