Live data from Hacker News

Coinbase: Responding to Firefox 0-days in the wild

blog.coinbase.com

31–40 of 97 posts

Re: Coinbase: Responding to Firefox 0-days in the wild

#31

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.

Re: Coinbase: Responding to Firefox 0-days in the wild

#32
post #27

> 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 resear…

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... [0]: http…

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.

Re: Coinbase: Responding to Firefox 0-days in the wild

#33

> 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 resear…

The same chance of getting two movies with the same premise (Armageddon and Deep Impact, White House Down and Olympus Has Fallen)

Re: Coinbase: Responding to Firefox 0-days in the wild

#34

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.

Re: Coinbase: Responding to Firefox 0-days in the wild

#36

> 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 resear…

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.

Re: Coinbase: Responding to Firefox 0-days in the wild

#37
post #9

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?

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.

Re: Coinbase: Responding to Firefox 0-days in the wild

#38

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.

Re: Coinbase: Responding to Firefox 0-days in the wild

#39

Remember, not your keys, not your bitcoin. Stay off coinbase.

> 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...

Re: Coinbase: Responding to Firefox 0-days in the wild

#40

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.

Post reply on HN