alt Hacker NewsA lot of people are focusing on how irresponsible the engineer was about using the work computer. That's obviously an issue but the bigger failure mode to me is the Engineer C's container deployment token.
That's a huge red-flag. In a company of this size, the deployments should be via CI only. CI isn't just to increase the speed and reliability of deployments but also to provide a clean room to build the software! Even if it's a token that was copied and pasted temporarily, the systems in place should not have to require this type of 1. copy 2. paste 3. remember-to-delete the token from my PC.
Also, Binance should be paying for intrusion testing. Better to pay a trusted company to do this kind of thing instead of letting North Korea show you how it's done. I don't think this exact exploit path would have been found but I bet the intrusion testing would have figured out another way to use Engineer C's token.
Replies
> Even if it's a token that was copied and pasted temporarily, the systems in place should not have to require this type of 1. copy 2. paste 3. remember-to-delete the token from my PC.
One of the first things I did in my last job was shift processes like this off my team's computers, aside from the security ramifications all it takes is one dumb mistake, one up-arrow too many, one didn't-read-the-whole-line, and now you're doing something to production by accident!
> Better to pay a trusted company to do this kind of thing instead of letting North Korea show you how it's done.
but enterprises usually prefer the latter, I guess it's more convenient since it bypasses the bureaucratic processes?
The article says that a software engineer interviewed with the North Koreans and the NKs then gained access to engineer A's machine (which had the deployment token) and then finally passed that token to run on engineer C's machine (who apparently did deployments). They knew of the team makeup from their first (caught) attempt.
That unlettered (npi) engineer who downloaded and ran the interview software on his or her machine is what the human weak link here. Let's call them Engineer F. Seems like this person was specifically selected from the dev team.
I don't even leave deploy tokens on my laptop for personal side projects. It isn't difficult to setup CI deploys, if nothing else the extra upfront cost let's me be lazy and have a consistent deploy pipeline.
No such thing as deleting secrets. You decommission them and replace them. Deleting them off disk is impractical to do, at least sufficiently.
100% this. I can deploy to our sandbox environment directly, but only our CI/CD has the permissions to build/deploy to our master environment. And the stuff I work on is 1000x less impactful than $billions in crypto!
Yes. The situation improves considerably if, when making server changes or retrieving data, programmers are required to enter a code generated from a hardware TOTP token isolated from both PCs and smartphones.
Every service provider system should be designed with the assumption that programmers' PCs and smartphones may be compromised.
I have saw companies doing social engineering as part of their intrution testing, I imagine fake interviews are (or will become) part of these.
What if I plant a hook on the engineer’s laptop that will slightly modify their commits in such a way that eventually I smuggle malicious code over? First, exfiltrate the code over to me, learn from previous commits, start poisoning. Stamped by the CI, no less. In the days of slop PRs thousands of lines each shouldn’t be even too hard.
The point is that at some point you do need to open the door and let the code in.
Nobody in the entire company should have access to move $billions in crypto, much less a random engineer, even if they're part of the deploy process.