search

slsa-framework / slsa

Supply-chain Levels for Software Artifacts
https://slsa.dev
Other
1.49k stars 216 forks source link

Publish list of OSS compromises and how SLSA can help #222

Open inferno-chromium opened 2 years ago

inferno-chromium commented 2 years ago

Some of the links we tracked in 2021 and 2020, i am guessing there are many more. We need find the right place to plug them in.

2021 https://github.com/faisalman/ua-parser-js/issues/536 https://jfrog.com/blog/malicious-pypi-packages-stealing-credit-cards-injecting-code/ https://www.bleepingcomputer.com/news/security/npm-package-steals-chrome-passwords-on-windows-via-recovery-tool/ https://blog.secure.software/third-party-code-comes-with-some-baggage https://www.bleepingcomputer.com/news/security/microsofts-halo-dev-site-breached-using-dependency-hijacking/ https://blog.sonatype.com/sonatype-catches-new-pypi-cryptomining-malware-via-automated-detection https://www.reddit.com/r/msp/comments/ocggbv/crticial_ransomware_incident_in_progress/h3u5j2e/https://news.sophos.com/en-us/2021/07/04/independence-day-revil-uses-supply-chain-exploit-to-attack-hundreds-of-businesses/ https://twitter.com/BRIAN_____/status/1392234974783279105?s=19 https://wwws.nightwatchcybersecurity.com/2021/04/25/supply-chain-attacks-via-github-com-releases/ https://brew.sh/2021/04/21/security-incident-disclosure/https://blog.ryotak.me/post/homebrew-security-incident-en/ https://www.neowin.net/news/linux-bans-university-of-minnesota-for-sending-buggy-patches-in-the-name-of-research/ https://blog.cocoapods.org/CocoaPods-Trunk-RCE/ https://about.codecov.io/security-update/https://arstechnica.com/gadgets/2021/04/backdoored-developer-tool-that-stole-credentials-escaped-notice-for-3-months/https://www.theregister.com/2021/04/26/hashicorp_reveals_exposure_of_private/https://www.bleepingcomputer.com/news/security/hashicorp-is-the-latest-victim-of-codecov-supply-chain-attack/ https://blog.sonatype.com/damaging-linux-mac-malware-bundled-within-browserify-npm-brandjack-attempt https://www.bleepingcomputer.com/news/security/phps-git-server-hacked-to-add-backdoors-to-php-source-code/ https://unit42.paloaltonetworks.com/malicious-cryptojacking-images/ https://michenriksen.com/blog/finding-evil-go-packages/ https://lwn.net/SubscriberLink/846272/4f8e060bdfc0e0de/ https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 https://www.welivesecurity.com/2021/02/02/kobalos-complex-linux-threat-high-performance-computing-infrastructure/ https://www.bleepingcomputer.com/news/security/heres-how-a-researcher-broke-into-microsoft-vs-codes-github/ https://www.ehackingnews.com/2021/01/perlcom-official-site-for-perl.html https://threatpost.com/discord-stealing-malware-npm-packages/163265/ https://www.theregister.com/2021/01/07/great_suspender_malware/

2020 https://www.zdnet.com/article/malicious-npm-packages-caught-installing-remote-access-trojans/ https://twitter.com/kengiter/status/1330209964812607494https://www.theverge.com/2021/4/22/22398156/university-minnesota-linux-kernal-ban-research https://www.zdnet.com/google-amp/article/npm-package-caught-stealing-sensitive-discord-and-browser-files/ https://jordan-wright.com/blog/post/2020-11-12-hunting-for-malicious-packages-on-pypi/ https://www.reddit.com/r/HobbyDrama/comments/jouwq7/open_source_development_the_great_suspender_saga/ https://www.reddit.com/r/HobbyDrama/comments/jo9wxn/open_source_development_the_fall_of_nano_defender/ https://www.zdnet.com/article/malicious-npm-package-opens-backdoors-on-programmers-computers/ https://blog.securityinnovation.com/repo-jacking-exploiting-the-dependency-supply-chain https://www.zdnet.com/article/three-npm-packages-found-opening-shells-on-linux-windows-systems/ https://www.zdnet.com/article/four-npm-packages-found-uploading-user-details-on-a-github-page/ https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain https://blog.reversinglabs.com/blog/mining-for-malicious-ruby-gems

inferno-chromium commented 2 years ago

This is another one - https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises

MarkLodato commented 2 years ago

One idea: add references to real-world attacks from https://slsa.dev/threats

jspeed-meyers commented 2 years ago

Thought I would add this dataset of all publicly known software supply chain compromises that I and others have been maintaining: https://github.com/IQTLabs/software-supply-chain-compromises

Perhaps this dataset should be moved to the governance of OpenSSF or SLSA? This way interested parties don't need to copy around a bunch of links but have a canonical dataset. I'd be glad to discuss if there is any interest.

Here also is a link to an article by myself and others that analyzes this dataset: https://www.usenix.org/system/files/login/articles/login_winter20_17_geer.pdf

Also, I like this idea of analyzing how SLSA can help with these compromises. Please let me know if I can be helpful with that as well.

david-a-wheeler commented 2 years ago

I really like the idea of capturing research on software supply chain attacks. I would also add the Backstabber's Knife Collection paper.

I think it might be better if the overall list of relevant compromises was in the main OpenSSF "Supply Chain Integrity" Working Group's GitHub repo. Basically, we could create a page or directory under https://github.com/ossf/wg-supply-chain-integrity and maintain it there. SLSA is part of that WG, but it's easy to imagine that other work will slot in.

I also like the idea of analyzing how SLSA can help. SLSA-specific analysis belongs, I think, within SLSA.

What do you think?

jspeed-meyers commented 2 years ago

@david-a-wheeler, thank you for the response. That sounds like a reasonable plan to me, though I have a modest amendment to propose. Adding @inferno-chromium, @MarkLodato, @trishankatdatadog, and @dlorenc if they have any suggestions, proposals or different opinions.

First, it makes sense to have this dataset (i.e. https://github.com/IQTLabs/software-supply-chain-compromises) associated with the supply chain integrity group, if they're open to it!

Second, and this is the amendment, it would seem logical to me fork the current repo (https://github.com/IQTLabs/software-supply-chain-compromises) to the overall ossf GitHub group so that there would then be a ossf/software-supply-chain-compromises repo. The supply chain integrity working group page would then have a link to this dataset.

Third, the same section of the supply chain integrity group GitHub page that links to this dataset should also, like you mention, link to the Backstabber's Knife Collection dataset and paper. The one other similar effort that could also be mentioned is the dataset created by Trey Herr for the Breaking Trust project at the Atlantic Council:

Fourth, I agree that the SLSA-specific analysis, if it is done, should be done within SLSA.

Fifth, let me make sure my collaborators and IQT colleagues all support these actions. I think they unanimously will, but let me get back to you early next week.

Finally, if it's not clear from the dataset or paper about the dataset, this dataset is very much a work in progress and could stand to be improved on many dimensions. So if any party objects to aspects of the dataset small or large, object away! I'm sure it could be dramatically improved with the input of the OpenSSF community, which is why I think it should live here, should there be interest.

How does all of that sound?

kimsterv commented 2 years ago

adding another one to the list https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/

bureado commented 2 years ago

(Edit: this one mentioned above: Here's another decently sized and reasonably updated inventory that I have contributed to in the past: https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises)

I would be delighted to spend cycles combining the indices (as @david-a-wheeler says, possibly as part of one of OpenSSF's WG) but my current sense is that it would only make sense to have a single inventory if it's source-controlled, has a search interface and a taxonomy that we don't need to spend years agreeing on.

To me the biggest value would be to have serial identifiers for the supply chain breaches so we can reference them in other lines of work. That's where things start sounding NVD-like and where I think an OpenSSF-led effort might be helpful (again, as a contributor to other list of compromises, I've seen the value in having different language/artifact ecosystems weigh in, so that should remain a goal - and I'll make a point to post a link here to both the OpenSSF and CNCF supply chain WGs)

Otherwise, there's the risk of ending with a (very interesting) dump of doom which might have diminishing returns. Corollary of this is that SLSA might not need to reference every single incident to make the argument for the requirements and controls it has in v0.1. TLDR I think my current proposal reading this issue would be to graduate this issue to an OpenSSF effort, perhaps, and enable SLSA to reference incidents from such an index in future revisions of the spec(s) so that there's a common understanding of what kind of incidents are forefront in our common thinking. $self->2e-2.

jspeed-meyers commented 2 years ago

@bureado, I second your points and proposal. Let me know if, when, and how you think others (to include myself) can be of assistance.

trishankatdatadog commented 2 years ago

@bureado, I second your points and proposal. Let me know if, when, and how you think others (to include myself) can be of assistance.

Sounds good! Would both of you like to volunteer to head this?

inferno-chromium commented 2 years ago

I like the idea of this database becoming an openssf project (and SLSA pages can cross-link to incident which would be individual files in the newly created repo) and moving it out of repos such as https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises, https://github.com/IQTLabs/software-supply-chain-compromises It would be nice to have each incident in a yaml format that anyone can modify/append more info to it. I like the idea of a serial identifier as well for easy cross-reference. @jspeed-meyers @bureado - do you have cycles to lead this ? we can create a project and you can start adding information there

jspeed-meyers commented 2 years ago

@inferno-chromium and @trishankatdatadog, I do have cycles for this project. If @bureado is willing to co-lead it with me, I am glad to pitch in! @bureado, do you have time and interest for this?

inferno-chromium commented 2 years ago

@david-a-wheeler - are you ok with this as well. This was discussed in WG, so i think I can create a repo ? maybe something like ossf/oss-compromises or ossf/oss-incidents or any other name recommendations ?

bureado commented 2 years ago

Happy to collaborate with @jspeed-meyers and @inferno-chromium on this, and OK with starting something in ossf/*.

inferno-chromium commented 2 years ago

@bureado @jspeed-meyers @kimsterv @david-a-wheeler - since we all agree, can you provide a repo name that you want for this project (i like ossf/oss-compromises and next one is ossf/oss-incidents). since we discussed this in supply chain wg, I will go ahead and create the repo.

jspeed-meyers commented 2 years ago

I like ossf/oss-compromises but am willing to consider others. What do the rest of you prefer? Thank you, @inferno-chromium for keeping this moving.

inferno-chromium commented 2 years ago

@jspeed-meyers @bureado - ossf/oss-compromises private repository is created and you guys are added as contributors. It is good to think of a data structure format first for both easy editing and viewing first (yaml/json/md), present some examples in WG and then migrate all of the data over from various places (we can get community help in migration part).

jspeed-meyers commented 2 years ago

@bureado, perhaps you and I (and any interested parties) should synchronously meet and discuss data structure options?

jspeed-meyers commented 2 years ago

Friendly ping, @bureado.

bureado commented 2 years ago

@jspeed-meyers and thanks for the ping! I contacted @inferno-chromium on the OpenSSF Slack (same alias) but happy to connect elsewhere.

jspeed-meyers commented 2 years ago

Ah, that works! I'll go join now and find you two.

jspeed-meyers commented 2 years ago

@inferno-chromium, @MarkLodato, and @david-a-wheeler, I worked on a proof of concept blog post about how SLSA can help OSS compromises. link - https://blog.chainguard.dev/slsa-vs-software-supply-chain-attacks/ If expanded, this is the type of work that I think could constitute a "how SLSA could help" analysis.

sergiomarotco commented 2 years ago

maleware in node-ipc https://gist.github.com/MidSpike/f7ae3457420af78a54b38a31cc0c809c https://snyk.io/blog/peacenotwar-malicious-npm-node-ipc-package-vulnerability/