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.
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
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.
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.
> 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.
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.
>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.
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.
> 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
> 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?
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
HN discussion: https://news.ycombinator.com/item?id=20283922