Relatedly: https://github.com/pypa/pypi-legacy/issues/644#issuecomment-...
Also http://evilpackage.fatezero.org/ / https://github.com/fate0/cookiecutter-evilpy-package
That one has neutered the call-home code by now, though.
Malicious software libraries found in PyPI posing as well known libraries
41–50 of 254 posts
Re: Malicious software libraries found in PyPI posing as well known libraries
#42Earlier quoted context omitted.
More needs to be done by package managers to warn end users. One scenario that worries me is where apps age and use popular trusted dependancies (e.g. gems on Github). When those gems stop being maintained but need to be updated to work (say with latest OSX) - it's common to quickly look at the latest forks available and select the one that now works correctly - but without a detailed inspection of the new code it's…
Package managers are providing (in the most case) a free service, so it's hard to see a strong case for them providing more services here. The problem is one of scale. npm has over 500,000 packages, so no manual review will address their scale over the whole repository. Until the developer market shows that they'll pay for a more secure service (e.g. package signed, reviews done etc) I doubt much will change.
If there was a business/enterprise offering with extra security I'm sure they'd have a long list of people who would sign up and happily pay for it.
Re: Malicious software libraries found in PyPI posing as well known libraries
#43This isn't, in any way, a new problem. I did a presentation on this topic for OWASP AppSecEU 2015 ( https://www.youtube.com/watch?v=Wn190b4EJWk&list=PLpr-xdpM8w... ) and when doing the research for that I encountered cases of repo. attacks and compromise. IME the problem will continue unless the customers (e.g. companies making use of the libraries hosted) are willing to pay more for a service with higher levels of a…
I'm sure companies would pay for it. The service needs to be part of the main package service, not some third party.
Re: Malicious software libraries found in PyPI posing as well known libraries
#44"Success of the attack relies on negligence of the developer" How about package manager managers accept their enourmous responsabilty? urllib vs urllib2, one is a virus? Sorry but that is not "negligence of the developer"
The least they can do is create an alias system for common libs or disallow some lib names.
Another easy thing to implement would be a popularity check: "This package was only installed nnn times. Did you mean xxx, or do you want to proceed with the installation of yyy by author dev@g00gle.com?"
Email verification is a must.
Re: Malicious software libraries found in PyPI posing as well known libraries
#45Earlier quoted context omitted.
Package managers are providing (in the most case) a free service, so it's hard to see a strong case for them providing more services here. The problem is one of scale. npm has over 500,000 packages, so no manual review will address their scale over the whole repository. Until the developer market shows that they'll pay for a more secure service (e.g. package signed, reviews done etc) I doubt much will change.
If there was a business/enterprise offering with extra security I'm sure they'd have a long list of people who would sign up and happily pay for it.
Those service already exit, e.g. https://www.sourceclear.com/ whilst I hope they're doing well, I don't think they've made significant in-roads into the volume of people using open source software library repo's.
Re: Malicious software libraries found in PyPI posing as well known libraries
#46I think a more Linux-like approach to package repos is better - a curated package repository run by volunteers in maintainership roles. Then you have a human being verifying the upstream and keeping malware out, and get more consistency across packages as a bonus. If you want your package added it's as simple as sending an email and provides a new avenue for people to contribute to the success of the ecosystem as pac…
Maybe you're right, but I see one possible downside that is quite important.
I have encountered the case "the package has an important bugfix but is not yet published on PyPI" way more than once or twice.
With the intermediate maintainers, that's going to get worse.
I believe namespaces and signatures are the way to go. With a special privileged namespace for the curated widely known packages (e.g. SciPy or Django) - a little like it's on the Docker Hub, where curated mainstream images are just "debian" or "python" but anyone can upload e.g. "jdoe/debian" if they need some customization.
Re: Malicious software libraries found in PyPI posing as well known libraries
#47It looks like the code phones home to a server in China: IP: 121.42.217.44 Decimal: 2032851244 Hostname: 121.42.217.44 ASN: 37963 ISP: Hangzhou Alibaba Advertising Co.,Ltd. Organization: Hangzhou Alibaba Advertising Co.,Ltd. Services: None detected Type: Broadband Assignment: Static IP Blacklist: Click to Check Blacklist Status Continent: Asia Country: China cn flag State/Region: Zhejiang City: Hangzhou Latitude: 30.…
When you go this adress http://121.42.217.44:8080/
"Hi bro :)
Welcome Here!
Leave Messages via HTTP Log Please :)"
Re: Malicious software libraries found in PyPI posing as well known libraries
#48This isn't, in any way, a new problem. I did a presentation on this topic for OWASP AppSecEU 2015 ( https://www.youtube.com/watch?v=Wn190b4EJWk&list=PLpr-xdpM8w... ) and when doing the research for that I encountered cases of repo. attacks and compromise. IME the problem will continue unless the customers (e.g. companies making use of the libraries hosted) are willing to pay more for a service with higher levels of a…
I'm sure companies would pay for it. The service needs to be part of the main package service, not some third party.
Interesting if you think that npm/Rubygems/PyPI are leaving a load of money on the table, why do you think they haven't introduced those services so far...
Re: Malicious software libraries found in PyPI posing as well known libraries
#49Earlier quoted context omitted.
Maybe most of those 500,000 packages simply shouldn't be trusted. There's a precedent for curated subsets of package ecosystems. Stackage for Haskell is an example, although it doesn't have security as the primary goal. I don't think we should focus on actual audits of packages. Just checking that packages seem basically credible seems like a better approach because it's doable.
Credibility is an easier check but still tricky. Many of the package are uploaded by anonymous or pseudonymous authors, so there's no easy way to even tie that to an IRL identity, let alone check for credibility. I'd agree that a curated small package repository would be a better way to address the problem, but the market doesn't seem very interested in that as a solution.
I think it might just not have happened yet. The npm community can be pretty creative and enthusiastic!
I don't think IRL identities are necessary for what I imagine. It's more like establishing a basic set of packages that have been around, have communities of committers, reverse dependencies, etc.
Maybe we would even make a starting assumption that the transitive closure of dependencies originating with a set of high profile packages are "approved".
I'm thinking aloud but I think there could be a reasonably pragmatic way to get this started...
Re: Malicious software libraries found in PyPI posing as well known libraries
#50Earlier quoted context omitted.
More needs to be done by package managers to warn end users. One scenario that worries me is where apps age and use popular trusted dependancies (e.g. gems on Github). When those gems stop being maintained but need to be updated to work (say with latest OSX) - it's common to quickly look at the latest forks available and select the one that now works correctly - but without a detailed inspection of the new code it's…
Package managers are providing (in the most case) a free service, so it's hard to see a strong case for them providing more services here. The problem is one of scale. npm has over 500,000 packages, so no manual review will address their scale over the whole repository. Until the developer market shows that they'll pay for a more secure service (e.g. package signed, reviews done etc) I doubt much will change.
It always worries me when I install a well-known or large package from npm and it ends up downloading dozens of dependencies maintained by disparate and unaccountable github users.