Live data from Hacker News

Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

medium.com

61–70 of 412 posts

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#61

I’m cackling at how great this is. This is what happens when you trust the internet forever and just scarf down any old thing at build time. Of course it’ll get exploited! That’s what evil people do.

Hey let's just sudo curl | bash what could possibly go wrong?

Not sure if serious, but I will point out this is significantly different. If I'm installing an application like homebrew or the Rust toolchain then I am explicitly giving them the right to code execution. It doesn't much matter whether they get it through the script on their website or the binaries downloaded from that website.

Random libraries, possibly pulled in by a dependency of a dependency of a dependency... not so much.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#62

I’m cackling at how great this is. This is what happens when you trust the internet forever and just scarf down any old thing at build time. Of course it’ll get exploited! That’s what evil people do.

Hey let's just sudo curl | bash what could possibly go wrong?

That's curl | sudo bash smh what an amateur

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#63

I'm surprised the reverse fully-qualified domain name (FQDN) model used by Java isn't more widely adopted. If you want to upload artifacts to the main repository (Maven Central) you first need to show ownership of a particular domain. For example, via a DNS TXT record (example [1]). Would make these kind of attacks a lot more difficult. [1] https://issues.sonatype.org/browse/OSSRH-61509

Javas FQDN model is actually pretty bad in practice. Domain names change quite often (I've seen many packages with a dead FQDN), and relying on the TXT record is going to be a security nightmare even worse than the username/password required by npm (since domains expire).

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#65
post #9

That is insane that any company allowed this to happen. ""That said, we consider the root cause of this issue to be a design flaw (rather than a bug) in package managers that can be addressed only through reconfiguration," a Microsoft spokesperson said in the email." No, npm has scopes for a reason, why would that not fix this issue?

GitHub could provide a default merge rule to prevent this attack

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#66

I’m cackling at how great this is. This is what happens when you trust the internet forever and just scarf down any old thing at build time. Of course it’ll get exploited! That’s what evil people do.

There are a lot of expensive things you can outsource. Responsibility isn't among those. Free software / open source propels engineering as you can share and leverage the results of collective efforts. However, at no point did the concept come with inherent guarantees about concerns such as security. esr defined 19 points for "good" open source software development in his seminal essay "The Cathedral and the Bazaar".…

Offtopic, but I found nowhere to actually ask this question. Does anybody know if ESR is still alive? His blog [1] has not been updated in months--and looking at his post dates, this seems really out of character--, he hasn't posted anything on twitter, or his usual channels.

[1] http://esr.ibiblio.org/

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#67
post #9

That is insane that any company allowed this to happen. ""That said, we consider the root cause of this issue to be a design flaw (rather than a bug) in package managers that can be addressed only through reconfiguration," a Microsoft spokesperson said in the email." No, npm has scopes for a reason, why would that not fix this issue?

Scopes were only introduced in NPM 2, and iirc it's still an optional feature. Companies that used NPM early on may have opted to never use those. But that's just NPM, it's an issue in all of the mentioned package managers.

true. simplest solution is just always prioritize internal over external.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#68

npm in particular has been problematic for a long time: https://naildrivin5.com/blog/2019/07/10/the-frightening-stat... https://techbeacon.com/security/check-your-dependencies-gith... https://thenewstack.io/npm-password-resets-show-developers-n...

Except this wasn't a problem with npm but rather with private registry implementations, and a setup with npm + Verdaccio is apparently actually one of the few configurations that isn't vulnerable to this problem.

Not that I didn't expect someone to immediately take the opportunity to complain about npm, of course, despite it having nothing to do with the problem at hand... as has become tradition in tech circles.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#70
post #50
post #14

To mitigate this kind of supply chain attacks for python, we have created following tool [1], that will check python packages on Artifactory instance you specify and create packages with the same name on the PyPi. [1] https://github.com/pan-net-security/artifactory-pypi-scanner

Uploading dummy packages to PyPi isn't the solution. It just pollutes PyPi and a nuisance to others. You have always been able to specify the `index-url` when installing packages using pip. This can also be added to `requirements.txt` files as well.

Yes, if you have packages on the artifactory the `index-url` is always a way to go. However, if you forget to specify `no-index`, you might not get what you wanted, see [1] for how packages are found. And it's easy to make such mistake when using local resources (you forget to set proxy or internal DNS, new developer is not familiar with the setup and does plain `pip install`, internal server is temporarily unreachable).

>It just pollutes PyPi and a nuisance to others. I agree, but so are the packages that are no longer maintained. You also reserve pakcage name if you decide to opensource it. Furthermore, by creating package you are leaking metadata about your organization, i.e. some functionality can be inferred from package names.

And sure you can train and try to enforce security awareness, but your people need to be right 100% of the time, while attackers need them to make only one mistake. Similar with namesquatting of the popular packages.

https://pip.pypa.io/en/stable/reference/pip_install/#finding...

Post reply on HN