5 ms·

If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibili

by lrvick 6y ago

If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibility of OSS maintainers without tipping them off in advance, dangerous state actors -will- continue to do it and -not- tell anyone when they are successful. Punishing these researchers this harshly about bad manners is creating a chilling effect that will scare researchers away from evaluating potentially one of the single biggest vulnerabilities in our industry. To be honest if anyone went around anonymously trying to merge security exploits all across well used open source supply chains and always told everyone when they were successful immediately after and helped everyone become more vigilant in code review, I would call them a public servant even if they were almost universally hated for it. I don't think most people realize just how easy supply chain attacks are and how widely they are being exploited by very dangerous organizations. If something does not change fast to dramatically increase the level of scrutiny we give to code contributions, it is going to get much worse. I have gone very far in pentests. Planting malicious USB cables, modifying keyboard firmware, straight up taking unlocked laptops and walking off, sniping recently expired domains to do XSS attacks, obtaining password reset links for the email accounts of maintainers of highly depended on third party dependencies. Even with consent from high levels at orgs it still upsets unknowing people that are tricked at lower levels in the org. I don't apologize for this because it is my job. I have seen real and successful social engineering attacks by state actors up close and you would way prefer a security researcher with bad manners to break you of your your survivors bias over being hit by the real thing. The reality is big companies can afford to pay people like me. Open source projects by random solo maintainers that the security of almost everyone on the internet relies on... can't. We should be very thankful for people that risk public rebuke to do research like this in open source at minimal cost to the receiving organization.

squaresmile 6y ago
What's your suggestions on how oss maintainers can fend off state actor attacks? Always need two people to sign off on a patch? I strongly agree that supply chain attack is a huge deal and worse attacks will come to light eventually but what should be done at the level of oss maintainers? Like you said, I feel like Open source projects by random solo maintainers that the security of almost everyone on the internet relies on... can't do a lot of things.
- lrvick 6y ago
  Dual cryptographic sign off is exactly what I recommend and have been prototyping tools to make this easier: https://github.com/distrust-foundation/sig https://github.com/distrust-foundation/sig
luckylion 6y ago
> If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibility of OSS maintainers without tipping them off in advance, dangerous state actors -will- continue to do it and -not- tell anyone when they are successful. What's the result of that? Lots of known bad patches being sent in, wasting everyone's time, because now every researcher finds "do they spot my intentional bugs" as an easy way to get something published? There's no reason why you can't run these studies with their consent. Ask the maintainers. "But it will tip them off", yeah, in a "they would be aware that somebody might send faulty code at some point in the future" kind of way, which they certainly already are. To get consent, you don't need to tell them exactly when you will be sending it, who will be sending it, or what exactly it would be. If it did put them into permanent hyper-vigilance mode, then ... goal achieved?
- lrvick 6y ago
  This suggestion, if taken to it's logical conclusion in my mind, I should send an email to every open source project maintainer ever warning them that at some point in the future I might attempt to validate their 2FA settings or try to submit mildly malicious code to them to test their ability to do code review at some unknown date in the future. Maybe this helps to raise awareness, even though in reality I will do tests like this to a tiiiiny percentage of repos over the next decade. I don't really know what purpose this would serve other than making people realize everyone got the same message, and everyone going back to being just as complacent as they were... but now we technically informed it was going to happen so it is fine now? Do any security researchers ask permission before finding other vulnerabilities in random open source code? I have never observed this. I feel like this type of thing should be assumed to come from whitehats or blackhats always. I for one teach everyone around me that if they can compromise me, they can have the bitcoin private key I leave on my personal systems. They earned it, and I will see that outgoing transfer on that address as a canary. I have been compromised a couple of times in this game when multiple people colluded, and it only leveled up my opsec and threat model. Good. IMO we should double down and raise grants to offer as bug bounties for people that successfully get potentially malicious code past code review in majorly depended on open source projects. We need to encourage a -lot- of this behavior to train people.
pdimitar 6y ago
FWIW I completely agree with you but I see no way out. The Linux kernel project needs and deserves the best security methods but (a) likely can't afford the people and (b) bringing more money aboard might draw unmotivated people only after the paycheck which could objectively deteriorate the project's code quality. Dual cryptographic signoff still doesn't address any social issues (or I'm grossly misunderstanding it if it does). F. ex. a state actor can threaten or bribe two, five or thirty people into merging a harmful patch. So what can actually be done?
- lrvick 6y ago
  Most projects have virtually no accountability at all. Hundreds of people have blind push access to brew. Almost no one signs code. One bad commit and you backdoor every company in silicon valley that blindly executes the unsigned code from the brew repo. Pick a favorite Linux distro. All but a handful work the same way. Right now an low skill level malicious party just needs to phish one of the ~90% of maintainers that don't have strong (or any) 2FA enabled anywhere in a dependency graph while they are on vacation or are not paying attention to a project and sneak in a commit or two into history while notifications are turned off. Attacks just like this have happened in the wild and not gone noticed for months. How many have we still not noticed? It is insane we let it get to this point. I feel like we are in early 1900s medicine where only like 1/10000 doctors see the value in washing hands and tools. Dual cryptographic signatures on all code from author/maintainer plus signatures by security-only reviewers from a pool not known in advance before new releases would be a very high bar for an adversary to defeat and a high risk of exposure. I have helped deploy variations of this approach with clients/employers in the past, and will publishing more detailed recommendations along these lines publicly soon. If the remaining weaknesses in this threat model and posture became our worst attack surface, we are in dramatically better shape.
  - pdimitar 6y ago
    I agree it's insane but this is what the market optimizes for. I pushed for more security and better practices until I was fired from 3 companies. It's quite obvious that business only cares about PR; if a big security incident happens they are more interested in how to reduce liability and not how to prevent the problem in the first place [the next time around]. Until programmers become an elite clique with a huge barrier to entry and our own independent income -- completely disconnected from the interests of those who want to use our services -- then we have our hands tied and are at the mercy of the paycheck and its innate conflicts of interest with good craftsmanship.

by lrvick 6y ago

squaresmile 6y ago

What's your suggestions on how oss maintainers can fend off state actor attacks? Always need two people to sign off on a patch? I strongly agree that supply chain attack is a huge deal and worse attacks will come to light eventually but what should be done at the level of oss maintainers? Like you said, I feel like Open source projects by random solo maintainers that the security of almost everyone on the internet relies on... can't do a lot of things.

lrvick 6y ago
Dual cryptographic sign off is exactly what I recommend and have been prototyping tools to make this easier: https://github.com/distrust-foundation/sig https://github.com/distrust-foundation/sig

luckylion 6y ago

> If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibility of OSS maintainers without tipping them off in advance, dangerous state actors -will- continue to do it and -not- tell anyone when they are successful. What's the result of that? Lots of known bad patches being sent in, wasting everyone's time, because now every researcher finds "do they spot my intentional bugs" as an easy way to get something published? There's no reason why you can't run these studies with their consent. Ask the maintainers. "But it will tip them off", yeah, in a "they would be aware that somebody might send faulty code at some point in the future" kind of way, which they certainly already are. To get consent, you don't need to tell them exactly when you will be sending it, who will be sending it, or what exactly it would be. If it did put them into permanent hyper-vigilance mode, then ... goal achieved?

lrvick 6y ago
This suggestion, if taken to it's logical conclusion in my mind, I should send an email to every open source project maintainer ever warning them that at some point in the future I might attempt to validate their 2FA settings or try to submit mildly malicious code to them to test their ability to do code review at some unknown date in the future. Maybe this helps to raise awareness, even though in reality I will do tests like this to a tiiiiny percentage of repos over the next decade. I don't really know what purpose this would serve other than making people realize everyone got the same message, and everyone going back to being just as complacent as they were... but now we technically informed it was going to happen so it is fine now? Do any security researchers ask permission before finding other vulnerabilities in random open source code? I have never observed this. I feel like this type of thing should be assumed to come from whitehats or blackhats always. I for one teach everyone around me that if they can compromise me, they can have the bitcoin private key I leave on my personal systems. They earned it, and I will see that outgoing transfer on that address as a canary. I have been compromised a couple of times in this game when multiple people colluded, and it only leveled up my opsec and threat model. Good. IMO we should double down and raise grants to offer as bug bounties for people that successfully get potentially malicious code past code review in majorly depended on open source projects. We need to encourage a -lot- of this behavior to train people.

pdimitar 6y ago

FWIW I completely agree with you but I see no way out. The Linux kernel project needs and deserves the best security methods but (a) likely can't afford the people and (b) bringing more money aboard might draw unmotivated people only after the paycheck which could objectively deteriorate the project's code quality. Dual cryptographic signoff still doesn't address any social issues (or I'm grossly misunderstanding it if it does). F. ex. a state actor can threaten or bribe two, five or thirty people into merging a harmful patch. So what can actually be done?

lrvick 6y ago
Most projects have virtually no accountability at all. Hundreds of people have blind push access to brew. Almost no one signs code. One bad commit and you backdoor every company in silicon valley that blindly executes the unsigned code from the brew repo. Pick a favorite Linux distro. All but a handful work the same way. Right now an low skill level malicious party just needs to phish one of the ~90% of maintainers that don't have strong (or any) 2FA enabled anywhere in a dependency graph while they are on vacation or are not paying attention to a project and sneak in a commit or two into history while notifications are turned off. Attacks just like this have happened in the wild and not gone noticed for months. How many have we still not noticed? It is insane we let it get to this point. I feel like we are in early 1900s medicine where only like 1/10000 doctors see the value in washing hands and tools. Dual cryptographic signatures on all code from author/maintainer plus signatures by security-only reviewers from a pool not known in advance before new releases would be a very high bar for an adversary to defeat and a high risk of exposure. I have helped deploy variations of this approach with clients/employers in the past, and will publishing more detailed recommendations along these lines publicly soon. If the remaining weaknesses in this threat model and posture became our worst attack surface, we are in dramatically better shape.
- pdimitar 6y ago
  I agree it's insane but this is what the market optimizes for. I pushed for more security and better practices until I was fired from 3 companies. It's quite obvious that business only cares about PR; if a big security incident happens they are more interested in how to reduce liability and not how to prevent the problem in the first place [the next time around]. Until programmers become an elite clique with a huge barrier to entry and our own independent income -- completely disconnected from the interests of those who want to use our services -- then we have our hands tied and are at the mercy of the paycheck and its innate conflicts of interest with good craftsmanship.