Coinbase: Responding to Firefox 0-days in the wild
blog.coinbase.comThis was the original article that talked about this attempt: https://robertheaton.com/2019/06/24/i-was-7-words-away-from-...
HN discussion: https://news.ycombinator.com/item?id=20283922
Coinbase should be hiring pentesters and giving them employee level access - even access to commit and deploy code.
Any insider shouldn't be able to steal more than the hot wallet, and even that should be hard.
I actually wouldn't put much effort into border security. At coinbases level of risk, evildoers will have no qualms bribing an employee to install a backdoor in their machine.
Given how quickly coinbase managed to respond to an advanced attacker I think they know what they're doing.
Insider threat is also really difficult. Working from a point of "I don't trust my employees" is very painful for many reasons.
> Working from a point of "I don't trust my employees" is very painful for many reasons.
It’s probably the hardest problem to solve in general, but it’s exactly what a well designed separation of duties is supposed to address.
I have never even heard of an internal site-wide pentest that failed.
I'm guessing Coinbase hiring a pentester and giving them 'employee level access' would be a needless formality?
People do internal pentests even though everyone knows the pentesters will win; you still learn something from the experience.
You’ll never be able to prevent privileged insiders, or their accounts, from being able to cause damage. But I have worked with organisations where internal tests were not able to compromise the most critical assets, and where the outcome of the tests was those assets become even more well protected. Which is really the best outcome you could be hoping for with these kinds of engagements, imo.
Of course, I was just being cute.
To me it shouldn't be a question of whether you trust your employees - obviously it makes for a better working relationship if you do, but I think there's a more fundamental issue here, which is "I don't trust my system"
If you fully trust the system you're building (and that trust is well-placed, meaning you can _prove_ the lack of significant exploits/vulnerabilities) then you should have no issue allowing others to try and poke holes in it
The usual caveat is that untrusted employees with sufficient access could potentially wreak havoc, but I would argue that if you really trust your system, and define the boundaries of your system well enough (i.e. to also encapsulate the issuance and management of all permissions relating to the system), then you can effectively limit the ability of malicious actors to break things or otherwise amass control
Why do you believe that is not the case?
The trouble is finding someone to bribe who won’t suddenly start buying new things.
The bribe is so that you are now a party to the crime and less likely to try and turn them in after the fact. The threats to your life and the lives of your family is actually what gets the job done.
To follow through on that though, what makes you think that would be anything noticeable? Suddenly a coinbase employee buys a cool car or other new toy... So what? Nobody would think that was exceptional.
I think this is why investigations require low levels of evidence to start, but high levels of evidence to end.
Just because it isn’t exceptional doesn’t mean that it isn’t worth looking into. People who are greedy are impulsive and are unlikely to hide an inflow of cash.
Theft isn't restricted to impulsive people though. It's mostly restricted to people who think they'll get away with it. Clever and cautious people may actually be able to.
Uh.
Yes.
But things don’t disappear do they?
I read this as putting people's behaviors under scrutiny because "just in case". You could use your reasoning to expand the surveillance state, etc. I cannot say I like the idea.
the problem is finding security pundits that know that crime can force people to do things in other ways than money...
> CVE-2019–11707 was simultaneously discovered by Samuel Groß of Google’s Project Zero and the attacker.
At least another time in the last week I read on other threads on HN or related links that vulnerability were found almost the same time by independent people.
Here we have a researcher from Google’s Project Zero and the attacker.
How do you explain these coincidences?
What is the chance that some prominent researchers being targeted and their systems are actually exploited?
This is not an uncommon phenomenon and not specific to vuln research. It happens all the time in mathematics, the sciences... [0]
Far more likely: there is a related cause that made two people think to try the same thing at approximately the same time. Someone publishes a new JIT type confusion bug, someone realizes "oh man it never occurred to me that X could trigger bug type Y", they start digging, and...
Thanks for the comment. I think where I read of the other synchronous discovery was hinting to what you wrote but I deliberately wanted to hear about the probability of researchers being compromised.
Maybe this is not the case but if somebody has powerful means, knowledge on how do successful targeted attacks, and access to the right 0 days, it would make sense that can use their resources to find other 0 days in this way.
The article clearly states that the attackers and the researchers use very different ways of triggering the vulnerability. It is a coincidence.
The same chance of getting two movies with the same premise (Armageddon and Deep Impact, White House Down and Olympus Has Fallen)
1) The cause in your example may be (a) something in the current events triggered ideas about those story lines.
At the same time it can be that (b) people in Hollywood talk with each others about stories they want to put on the screen.
Or it can be (c) that studio A has inside intelligence in studio B looking for interesting stories to be made in a movie.
2) It is similar to 2 startup companies starting tackling similar new problems. It may be because of (a) a new enabling technology came up or a change in the landscape that unlocks the new opportunity.
Or because (b) the loop: entrepreneurs talk to investors -> investors talk with each others -> repeat
Or because (c) entrepreneur A knows that entrepreneur B is up to something and find a way to spy on them to find what they are up to.
3) In the case discussed above, it may be (a) a new discovered bug on public forum leads to similar bugs being discovered, (b) researchers talking to each others in their circles, (c) a powerful entity getting access to the researcher's "secrets".
The difference between (a), (b) and (c) causes is that (a) causes happen in public places. (b) causes happen in private circles. (c) it is not a result of deliberate communication, it is stolen IP.
That is already a meaningful distinction. Now the questions is how often a, b, and c happen in the different context and how do they impact the outcome of the projects in the respective fields.
In all examples, timing is one of the keys to be successful.
The difference between (1), (2) and (3) is how legal or ethical the "exploiter" of the IP is abler to get the IP and their tolerance to risk.
It seems that in our case(3) (c) is more likable than in the other cases considering the actors involved and their modus operandi.
> Project Zero and the attacker. How do you explain these coincidences?
Project Zero buys 0days on darknet? Google has unlimited cash, so technically possible.
>We collected IOCs from the host in question and started hunting broadly in our network. We did not see any of the IOCs anywhere else in our environment, and blacklisted all the IOCs that we had at that time.
Can someone explain what they mean by IOCs?
Remember, not your keys, not your bitcoin. Stay off coinbase.
For the average person, using Coinbase with 2FA is going to be better than managing their own private key. Even if their hot storage was penetrated, which is unlikely, they have insurance and other means of making sure that customer deposits are unaffected.
I know a lot more people that have lost crypto because they lost their keys than people who lost it on Coinbase.
Better take all my cash out of the bank then and put it under my mattress.
> A criminal gang operating in India kidnapped and tortured cryptocurrency traders in recent weeks before demanding 80 bitcoins as ransom, police say. Three men had been held captive for 15 days inside a high-rise building and were beaten or tortured... Not even their family members were aware of the abduction. The victims had lost all hope because they had no access to anyone
https://www.newsweek.com/cryptocurrency-traders-abducted-tor...
Im confused why this is a response to the parent.
It's the same argument as this xkcd: https://xkcd.com/538/
Though granted it confuses keys for passwords.
I find this info is interesting
> The attackers went through a qualification process and multiple rounds of emails with potential victims, making sure they were high-payoff targets before they directed victims to the page containing the exploit payload.
It's a well-prepared plan combining social engineering and technical exploits
This point to an actual use of the cryptocurrency - exploiting a 0 day against someone who might have a crypto wallet means you can actually directly make money off exploits. Prior to crypto, having a 0 day wasn't equal with ability to make blackhat money with it...
> This point to an actual use of the cryptocurrency - exploiting a 0 day against someone who might have a crypto wallet means you can actually directly make money off exploits. Prior to crypto, having a 0 day wasn't equal with ability to make blackhat money with it...
Why would that be the case when it is not illegal to sell exploits?
Selling exploits requires credibility, escrow, and deep contacts. Selling bitcoin is a lot easier.
Ah so you mean leveraging the exploit for financial gain by using it (ransomware) versus selling. That makes a ton of sense!
Banking malware has existed for a while.
Banking has insurance against fraud and transactions are generally reversible.
> transactions are generally reversible
Not really. If your account is compromised you may indeed get your money back from the bank's insurance (although in some countries that is less likely than others). However, the criminal behind the malware will probably have got at least some of the money.
International transfers are not generally reversible. Cash withdrawals are not reversible. Even electronic transfers to another bank in the same country (maybe this varies by country) are only reversible if the money has not been withdrawn.
And then there have been cases of actual bank systems being compromised so that criminals can just increase the balance of accounts directly.. And cashpoints (atms) being compromised.
At the very least, it's a lot harder for criminals to cash out of compromised bank accounts in a way that doesn't lead law enforcement directly to them.
Interesting to me that the attackers were well equipped in their phish and 0days, but then opted to drop fairly detectable RATs.
Yeah, they could have moved processes before execing the shell. Detecting "Firefox + Shell" is quite easy and standard, even in existing SIEMs.
Detecting "arbitrary program + shell" is at least moderately more difficult.
It's the attacker's dilemma though. They only need to trip one alarm to trigger IR.
The biggest fail here was that 32 bit program warning, which probably alerted the employee.
Notice that they didn't actually have an alert for Firefox+Shell, they detected that later by inspecting the audit logs.
> We detected the attacker at this stage, based on a number of behaviors (e.g. Firefox shouldn’t spawn a shell).
They explicitly state it was one of the behaviors they detected as suspicious.
Very likely that they bought the exploit and did the rest themselves, so, their skill at phishing, exploiting and RATing won't be correlated.
I was thinking the same thing. The RAT they used is well known in underground skiddie forums; it's known for being expensive and shitty.
This is among the critical differences between MtGox and Coinbase.
"We're not run by idiots"?
Well, sure, I suppose that's step zero. But there's a lot more work required beyond that in order to survive continuous attacks.
That doesn't explain listing Bitcoin Cash (Bcash) - an altcoin that shares its mining algorithm with Bitcoin but only has a very small amount of hash rate backing it. Any small Bitcoin miner can decide at any moment to switch to mining Bitcoin Cash and cause block reorgs or mine blocks with no transactions at all.
A similar event actually happened with another asset they offer - Ethereum Classic.
https://cointelegraph.com/news/ethereum-classic-51-attack-th...
Much of this is because of forks - since they offered Bitcoin before the BCH fork (and presumably ETH before the ETC fork), all of their customers who owned one of these before the fork also own the new currency. So they have to support custody for the currencies anyway (unless they want to deal with angry customers saying "What happened to my BCH! Rightfully I own it"), and if they don't support trading they'll get angry customers that say "Why can't I sell my BCH?!?". (This is aggravated by potentially needing to send that BCH off to another exchange, potentially not in the U.S, with worse regulatory compliance, in order to sell.) So most of the work needed to support it has to be done anyway to remain in legal compliance, and it's a small amount of additional work for a large benefit to support trading.
That doesn't explain the favoritism for BCH over the multitude of other forks (some worth $50-$100 per token) though. Why no Bitcoin Gold listing?
Sure enough, there are angry customers accusing Coinbase of stealing their Bitcoin Gold:
https://www.reddit.com/r/CoinBase/comments/7jtlgz/coinbase_s...
IIRC BCH and ETC forked before BTG. They probably did two of them and then asked themselves "Why are we doing this again?"
Huh, I would've thought that since people will pay over 300 usd for one Bitcoin Cash coin (according to 3 web sites I just sampled), there would always be plenty of miners competing for them.
BCH is and will be mined proportionately to its price; since its price is far lower than BTC it also has far lower security.
OK, but I would've guessed that the reward for hijacking BCH's blockchain would be proportionally lower.
And please keep in mind the context of my first comment: I was replying to the assertion that the mere fact that Coinbase continues to let its customers trade in BCH is evidence that Coinbase is run by idiots.
The thing with those silly altcoints is that there really isn't much market liquidity. Even if you were able to steal a large number of them, any attempt to convert them into something useful (i.e. dollars) with crash the price.
Yeah, it's cheap to attack BCH but there's little benefit to doing so. Whether that makes BCH safe to trade or a reckless shitcoin is a matter of opinion.
The infrastructure to carry out that attack against BCH would cost around a billion dollars in mining equipment and power. Not exactly what you would call a small miner. BCH also has rolling 10 block checkpoints so max you could reorg would be 10 blocks or < 2 hours of transactions.
In reality there is nowhere you could rent this hashpower and miners that do have it would never risk the legal, social and monetary consequences to rollback 2 hours of transactions.
That infrastructure exists already. It just takes a pool's operations to be compromised (in whatever manner you devise) in order to redirect its hash rate. Keep in mind we're talking about small Bitcoin pools here. Not even the larger ones.
"We didn't literally start out with trading cards."
That's not a great one, Nintendo started out as a playing card company after all. Where you start is quite irrelevant. It's where you end up that matters, and I think MtGox demonstrates that quite clearly.
I don't hold MtGox's origins against them (plus I'm a MtG fan).
But Nintendo didn't pivot from playing cards to guarded stagecoaches, they stayed in the entertainment focus and evolved over a century into electronics. The stakes were always low.
Pretty low bar honestly, even if they had pivoted to stagecoaches it’s hard to knock them if they’d been successful. The ends are more important. Gox was really stupid though.
We didn't implement ssh server in php
this gave me a good laugh
Does it a help in this case if one runs the browser in a sandbox? E.g. in docker?
They can then break out from the browser, but only get to docker with that exploit, and it's unlikely they have a docker exploit too at hand, is it?
They can then break out from the browser, but only get to docker with that exploit, and it's unlikely they have a docker exploit too at hand, is it?
If you are running Firefox on X11 (which most Linux users probably still do), you do not need to escape Docker. You can make screenshot, capture keystrokes, and send keystrokes, all through the X11 socket.
(Furthermore, you do not need a Docker exploit, a Linux kernel exploit can be enough to break out of a container. This is one of the reasons for e.g. gVisor to implement syscalls in userland and in a safer language.)
Using VMs as e.g. Qubes OS does is probably a bit safer than a Docker container.
> If you are running Firefox on X11 (which most Linux users probably still do), you do not need to escape Docker. You can make screenshot, capture keystrokes, and send keystrokes, all through the X11 socket.
Also, this is why Wayland is much more restrictive about these types of operations. People love to complain that "I could do thing with X without special privileges" but the world has moved on since X was designed and it absolutely has not kept up.
People are totally right to complain about basic features being left out, not not having a standard secured low-overhead video recording and screenshotting is simply stupid and harmful for Linux.
I don't know how effective it is, but firejail can use xpra or xephyr to firewall X.
As I understand it, Docker isn't intended to be, and shouldn't be relied on as, a security sandbox.
It creates boundaries, but, like a typical suburban garden fence, they aren't hardened security boundaries.
You've got two cases here: breaking out of default Docker config, or breaking out of kernel namespaces. The first one is very common now and really well tested. The second one is definitely security sandbox worthy. Docker also integrates with selinux and seccomp.
Basically what I'm saying is, it's very much a security boundary. It's far from a decorative fence.
Breaking out of a docker container with default settings is hard. You would be making the headlines if you could do so.
Now breaking out of a docker container with --privileged or even just CAP_SYS_ADMIN is much easier.
There was a CVE in February [0][1] that escaped out of Docker's default settings. runc has a few of these over the last few years, it isn't inconceivable that there are more to be found.
Docker does do a decent job of setting some sensible defaults - but it isn't a security sandbox and they don't market it as such.
[0] https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-fr...
The very fact that there's a CVE for breaking out of docker shows that it's a big deal :)
Having two 0-days for one of the most popular browsers tells me they probably have access to whatever they want.
For high value targets, probably. For average spear phising I don't think they spend more resources to break out from docker.
Since default docker runs linux, running the browser in a linux docker can be enough, because they usually have windows exploits.
One of the benefits to ex. firejail is precisely that a Firefox exploit does not compromise ex. ~/.ssh
Docker is not intended as or very useful for security isolation - especially for GUI applications. I would suggest a VM if you want to isolate your browser.
> exploit code was delivered from a separate domain, analyticsfit[.]com
They paid some registrar for the domain. Can police request payment details? Can someone buy domain on stolen credit card?
Those attacks would not work if they did not enable JavaScript on every website by default.
Those attacks would not work if everyone stopped using computers.
I keep JS off by default* and it's teriffic. Using a browser with it enabled is tedious, slow and distracting in addition to the obvious heka-less-secure.
its almost like the NSA designed all programming languages to insure that it would be impossible to make a perfect program
I find the explanation of "to err is human" far more likely.
I see my colleague making a web app that forces the browser into 100% CPU on scroll, just to animate a shrinking nav bar. Also a page that wont settle in for 15 seconds until assets from Google Fonts downloaded and all scripts have run. So I secretly pray for a draconian anti-js order imposed on us, even though my minimal Vue scripts will go away.
This was mentioned in a previous HN thread and I thought it was a brilliant idea.
By default, browsers should throttle websites. Throttle their CPU and their ram usage, and websites can then ask for permission to be unthrottled.
We have very capable computers now. But the web feels just as slow. Some negative pressure against bloat is sorely sorely needed.
No sane man will hurt his users intentionally. It won't happen.