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

▲

panicinducer an hour ago | parent | next [-]

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.

	▲	ffsm8 3 minutes ago \| parent [-]
		I mean sure, but as long as you can deploy directly any permissions models are meaningless for an attacker? They can just be removed.

▲

benoau 2 hours ago | parent | prev | next [-]

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

▲

hirako2000 an hour ago | parent | next [-]

I also did that, for a team deploying smart contract on chain from local.

It took a couple months to get the pipeline out of their laptop.

Worth it, yes, as we found interesting things in there which explained why they were so reluctant to deploy upgrades.

	▲	pjc50 an hour ago \| parent [-]
		> as we found interesting things in there which explained why they were so reluctant to deploy upgrades .. backdoors which enabled the dev to deploy exploits of their own which wouldn't be visible through CI?

▲

jacekm 31 minutes ago | parent | prev [-]

TBH CI does not prevent this kind of mistakes. I've seen people triggering the wrong CI pipeline.

	▲	steve1977 a few seconds ago \| parent [-]
		I guess people triggering the pipeline is already part of the problem

▲

suzzer99 20 minutes ago | parent | prev | next [-]

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!

▲

eptcyka 31 minutes ago | parent | prev | next [-]

No such thing as deleting secrets. You decommission them and replace them. Deleting them off disk is impractical to do, at least sufficiently.

▲

AlexITC 2 hours ago | parent | prev | next [-]

I have saw companies doing social engineering as part of their intrution testing, I imagine fake interviews are (or will become) part of these.

▲

Aurornis an hour ago | parent | next [-]

I think it will remain uncommon. I agree it would be a good test, but companies and employees alike get very angry when pentesting gets too close to sensitive subjects.

Anyone who fell for it would not only get in trouble for poor security practice, they would reveal that they were job searching. That opens an entire can of worms that creates problems beyond the pentest. This also angers other employees who see it as a double-trap being sprung on employees.

Another major problem is that responsible employees who accept the fake interview but then use their personal laptop to do the interview will have their personal laptop compromised by the pentesters. Responsible testers will immediately abort, but some will try to use the personal laptop to pivot deeper which is a huge ick. It’s also really bad if the company is compromising personal laptops of people who are doing the right thing (switching to personal gear for interviews).

	▲	quaffcode an hour ago \| parent [-]
		The pentesters wouldn't have to actually pwn a laptop, just getting the employee to download and run anything could go in a report without having the file actually be malicious.

▲

thomc an hour ago | parent | prev | next [-]

Sometimes called "Full Spectrum Attack Simulation" where initial entry can include physical access or spear phishing. They can span months in elapsed time (not effort) so as to be more realistic. However there are still ethical and safety constraints and even phishing may not be able to use the (effective) technique of stressing the recipient too much or of course blackmail or coercing. So I think fake interviews may not be allowed in many cases, to protect the employees.

▲

shepherdjerred 24 minutes ago | parent | prev | next [-]

Is that even legal? Wouldn’t a fake job interview be, in a sense, tricking you into taking time off and working without pay?

▲

dylan604 2 hours ago | parent | prev | next [-]

It'll be hard to time a job opening receiving interviews to line up with intrusion tests in a way that people would not be on guard against it in a way not normal.

▲

philipwhiuk 2 hours ago | parent | prev [-]

Fake interviews would be a huge time sink and probably piss off your staff.

▲

hirako2000 an hour ago | parent [-]

They don't have to respond. It gives employers an even stronger signal they should be kept right?

▲

Aurornis an hour ago | parent [-]

Using pentesting to also test employee loyalty is a great way to get the entire company to hate working there.

	▲	optimalsolver an hour ago \| parent [-]
		Which is why it's going to happen.

▲

WesolyKubeczek 42 minutes ago | parent | prev [-]

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.