Backdoor in public repository used new form of attack to target big firms:
A backdoor that researchers found hiding inside open source code targeting four German companies was the work of a professional penetration tester. The tester was checking clients' resilience against a new class of attacks that exploit public repositories used by millions of software projects worldwide. But it could have been bad. Very bad.
[...] A few weeks later, a different researcher uncovered evidence that showed that Amazon, Slack, Lyft, Zillow, and other companies had been targeted in attacks that used the same technique. The release of more than 200 malicious packages into the wild indicated the attack Birsan devised appealed to real-world threat actors.
Dependency confusion exploits companies' reliance on open source code available from repositories such as NPM, PyPI, or RubyGems. In some cases, the company software will automatically connect to these sources to retrieve the code libraries required for the application to function. Other times, developers store these so-called dependencies internally. As the name suggests, dependency confusion works by tricking a target into downloading the library from the wrong place—a public source rather than an internal one.
To pull this off, hackers scour JavaScript code, accidentally published internal packages, and other sources to discover the names of internally stored code dependencies by the targeted organization. The hackers then create a malicious dependency and host it on one of the public repositories. By giving the malicious package the same name as the internal one and using a higher version number, some targets will automatically download it and update the software. With that, the hackers have succeeded in infecting the software supply chain the targets rely on and getting the target or its users to run malicious code.
Previously:
Open-Source Security: It's Too Easy to Upload 'Devastating' Malicious Packages, Warns Google
Dependency Yanked Over Licensing Mishap Breaks Rails Worldwide
More Than 75% of All Vulnerabilities Reside in Indirect Dependencies
Related Stories
More than 75% of all vulnerabilities reside in indirect dependencies:
The vast majority of security vulnerabilities in open-source projects reside in indirect dependencies rather than directly and first-hand loaded components.
"Aggregating the numbers from all ecosystems, we found more than three times as many vulnerabilities in indirect dependencies than we did direct dependencies," Alyssa Miller, Application Security Advocate at Snyk, told ZDNet in an interview discussing Snyk's State of Open Source Security for 2020 study.
The report looked at how vulnerabilities impacted the JavaScript (npm), Ruby (RubyGems), Java (MavenCentral), PHP (Packagist), and Python (PyPI) ecosystems.
Snyk said that 86% of the JavaScript security bugs, 81% of the Ruby bugs, and 74% of the Java ones impacted libraries that were dependencies of the primary components loaded inside a project.
[...] Snyk argues that companies scanning their primary dependencies for security issues without exploring their full dependency tree multiple levels down would release or end up running products that were vulnerable to unforeseen bugs.
So dear Soylentils, how do you track vulnerabilities in libraries that you use in your projects and do you scan beyond direct dependencies?
Previously:
(2020-05-16) Nine in Ten Biz Applications Harbor Out-of-Date, Unsupported, Insecure Open-Source Code, Study Shows
A 15 year old XML file created a stir in the Ruby on Rails world today as it was discovered that freedesktop.org.xml which is GPL 2 licensed was included improperly in the mimemagic project which was MIT licensed. The author accepted this notification as valid, pulled prior versions, and switched licenses but as this was a dependency of Rails it promptly got the attention of programmers worldwide that rely on the Rails gem for their applications.
Since Rails itself is MIT licensed this makes for a difficult day of sorting out licensing options for many people.
Open-source security: It's too easy to upload 'devastating' malicious packages, warns Google:
Google has detailed some of the work done to find malicious code packages that have been sneaked into bigger open-source software projects.
The Package Analysis Project is one of the software supply chain initiatives from the the Linux Foundation's Open Source Security Foundation (OpenSSF) that should help automate the process of identifying malicious packages distributed on popular package repositories, such as npm for JavaScript and PyPl for Python. It runs a dynamic analysis of all packages uploaded to popular open-source repositories. It aims to provide data about common types of malicious packages and inform those working on open-source software supply chain security about how best to improve it.
[...] "Despite open-source software's essential role in all software built today, it's far too easy for bad actors to circulate malicious packages that attack the systems and users running that software."
[...] Attackers distribute malicious packages on npm and PyPl often enough that it's something OpenSSF, which Google is a member of, decided it needed to be addressed.
(Score: -1, Offtopic) by Anonymous Coward on Thursday May 19 2022, @04:58AM
(clicks heels together)
(Score: 4, Insightful) by inertnet on Thursday May 19 2022, @07:30AM (2 children)
One day the world will find itself in complete chaos because someone (or rather some group) manages to break a good portion of servers worldwide. It's almost inevitable, given how things work nowadays. This attack is a good example of how easy it is to infiltrate critical systems.
(Score: 2) by FatPhil on Thursday May 19 2022, @09:19AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by maxwell demon on Friday May 20 2022, @12:25PM
For example by deleting 11 lines of code. [youtube.com]
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Mojibake Tengu on Thursday May 19 2022, @07:41AM (1 child)
Damned Okina Matara, she deliberately puts doors on the back of everything these days...
Respect Authorities. Know your social status. Woke responsibly.
(Score: 2) by PinkyGigglebrain on Thursday May 19 2022, @05:36PM
I bet she is working with Yukari-sama, it would explain all the gaps in security we've been hearing about lately..
I just hope Reimu can resolve this incident before things get too far out of hand.
"Beware those who would deny you Knowledge, For in their hearts they dream themselves your Master."
(Score: 4, Insightful) by darkfeline on Thursday May 19 2022, @07:49AM (4 children)
https://research.swtch.com/vgo-principles [swtch.com]
https://research.swtch.com/vgo-mvs [swtch.com]
I don't know why other languages still pull the latest version of dependencies. It's clearly a stupid design choice, and it's been clearly a stupid design choice for years now.
Go is also the only language/standard toolchain that I know that has a transparent, auditable/immutable, global hash of all public package versions in existence to make it impossible for an attacker to replace a published package with a compromised version. https://research.swtch.com/tlog [swtch.com]
I'm willing to bet a month's subscription, in the next few years we will see a news article or widespread attack using this exact attack vector, and I will be back pointing out how rsc/Go had already solved this problem.
Join the SDF Public Access UNIX System today!
(Score: 3, Insightful) by FatPhil on Thursday May 19 2022, @09:12AM (2 children)
Trust should be implemented as default-no, not default-yes, and definitely never always-yes.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1, Interesting) by Anonymous Coward on Thursday May 19 2022, @05:02PM (1 child)
Ingress auditing does not matter, really. Your internal code could well end up depending on some corner case that no one else is using and no one made a test for. When that breaks, it is for *your internal* tests to catch that happening. And this is why "default-no"; any new version of a package should pass those internal tests first, before being allowed to be used by production code.
(Score: 2) by FatPhil on Friday May 20 2022, @10:33AM
However, to be honest, it's quite a clever little hack. I didn't think of it because I not just only pull packages from repos which I know have active ingress auditing (and in fact their own package maintainers), but I perform my own ingress auditing too. Half of the time when I look at a perl package I want, I'll realise that I don't need the 500 lines of OO bullshit, I only need 10 of them, the ones that actually do the work, and I'll just rip that bit out, maybe even optimise it a bit for my specific case, and not bother installing the package. There's already too much bloat in the world. ``require bloatyshite;'' isn't just one extra line of code.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by FatPhil on Thursday May 19 2022, @11:20AM
"Stop"? So he did use to beat his wife?
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves