Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Major bank accidentally published a private package to the public NPM Registry

twitter.com

Post reply on HN
Print view View original

221–230 of 236 posts

Re: Major bank accidentally published a private package to the public NPM Registry

#221

Post by mnutt »

koolba wrote: post #141
mnutt wrote: post #121

To partially mitigate this issue, I scope all private packages to @corp-internal/ , then use a .npmrc directive to push all packages in @corp-internal/ to packagecloud.io. The @corp/ scope is used for open source packages, @corp-internal scope does not exist on the public npm registry so no chance of config issues causing mistaken pushes.

Do you own @corp-internal or is it otherwise blacklisted? What stops someone from creating that account and owning that org?

Yeah, it is registered but empty and has no real users so nobody can publish packages there.

Re: Major bank accidentally published a private package to the public NPM Registry

#222

Post by mfoy_ »

Ndymium wrote: post #188

A recent experience tells me this is a very easy mistake to do, though. I was using Yarn to publish a package to an internal package repository (so setting `private: true` was not an option). I did not know at the time that Yarn would not honor `publishConfig` in the `package.json` file, and it would also ignore the package's organisation set in `.yarnrc` (which is used to direct read operations to the internal repos…

Yeah, when I first started playing around with node I accidentally published one of my "hello world"-like apps to NPM's public registry. There was definitely no warning or indication of the severity of the action I was undertaking.

It's an easy mistake to make. What is concerning is that the bank didn't notice for three years... I feel like that should have been caught a lot sooner.

Re: Major bank accidentally published a private package to the public NPM Registry

#223

Post by xemdetia »

austincheney wrote: post #162
omouse wrote: post #73

Earlier quoted context omitted.

If this happens often, perhaps the user interface for npm publish needs to change? I mean, that's the only thing I can see mitigating this, with like a nice dialog that says "hey, are you REALLY REALLY sure and have you consulted lawyers on this???" Or something to that effect. Or maybe companies can just pony up for NPM Enterprise which fits their use case.

I work at a major bank and for the US Army. Both of those organizations are hyper sensitive about security for good reasons. Unfortunately that hyper sensitivity often results in really bad decisions and gross misunderstanding of software. Publishing software is not a security violation in greater than 98% of cases. The only valid exceptions are protections of trade secrets and cryptographic information. I am not cou…

I'm trying to understand your point. I agree with the basic premise that most pieces of code that end up not getting exposed are not sensitive, but building guardrails to ensure people who aren't security minded ask the right questions and get closer to 'default correct' ends up being a requirement in major banks/government organizations. The number of times someone has done something completely silly like include API keys in a public package or Git repo is reason enough to care. Being beholden on an external system being secure and up to standard ruins pretty much every category of a risk analysis, especially when you end up with gold like this article or the PHP PEAR hack.

Then there is always that part of the organization that isn't judicious about keeping packages up to date, and these kinds of package exposures expose their negligence.

Then there is the other piece of my systems being dependent on your systems in a sometimes inappropriate matter if precautions aren't taken. 'Oh I just added this dependency' is a quick way to an outage if rules aren't set.

Re: Major bank accidentally published a private package to the public NPM Registry

#224

Post by MaddAgent »

iooi wrote: post #46
zackbloom wrote: post #38

Earlier quoted context omitted.

They're running a business. They offer an inordinate amount of service totally free to millions of developers, and they make their actual client open-source for your pleasure. Is your argument they also have to go to the trouble of making their infrastructure easily self-hosted? How would they make the money to pay the lawyers to respond to the very legal threat this tweet is about without revenue?

Please, it's arbitrary to run a private PyPi repository, all you need is a web server and a certain folder structure. If you want, you can even host everything on a private S3 and use a tiny Nginx configuration to authenticate the requests on behalf of pip [1]. Private npm repositories are an entirely different beast, and like GP mentions, there is no great option here. [1] https://www.guido.nyc/pypi-s3/

https://cloudsmith.io/l/npm-repository/ - no?

Re: Major bank accidentally published a private package to the public NPM Registry

#225

Post by ndonnellan »

Ndymium wrote: post #188

A recent experience tells me this is a very easy mistake to do, though. I was using Yarn to publish a package to an internal package repository (so setting `private: true` was not an option). I did not know at the time that Yarn would not honor `publishConfig` in the `package.json` file, and it would also ignore the package's organisation set in `.yarnrc` (which is used to direct read operations to the internal repos…

This is bad design. I may have come close to doing this as well for the same reason. There is no reason why NPM should auto-register you when you attempt to publish (or auto-register when you attempt to sign in) other than to remove a few steps/friction to make it seem like a nice experience.

Explicit vs. Implicit : always choose explicit if accidents can cause people serious pain. npm login that is secretly npm "create account" is a serious anti-pattern. And npm publish -> npm login -> npm create account is a consequence of that.

Re: Major bank accidentally published a private package to the public NPM Registry

#226

Post by austincheney »

xemdetia wrote: post #223
austincheney wrote: post #162

Earlier quoted context omitted.

I work at a major bank and for the US Army. Both of those organizations are hyper sensitive about security for good reasons. Unfortunately that hyper sensitivity often results in really bad decisions and gross misunderstanding of software. Publishing software is not a security violation in greater than 98% of cases. The only valid exceptions are protections of trade secrets and cryptographic information. I am not cou…

I'm trying to understand your point. I agree with the basic premise that most pieces of code that end up not getting exposed are not sensitive, but building guardrails to ensure people who aren't security minded ask the right questions and get closer to 'default correct' ends up being a requirement in major banks/government organizations. The number of times someone has done something completely silly like include AP…

> The number of times someone has done something completely silly like include API keys in a public package or Git repo is reason enough to care.

Agreed, but that is not a publication problem. That is a separation of concerns violation which indicates a host of other problems from the lack of code review to incomplete security testing to various ad hoc or integrity violations.

External systems have no bearing on the validity and completeness of your organizations internal security controls. It doesn't matter how incomplete, insecure, or unqualified NPM is to serve a given set of code. The problem isn't NPM or the publication to NPM. The problem is the contents that comprise the publication in question. A good security audit would ask why any certain content is available for publication in violation of internal policy regardless of what that content is.

For example if you accidentally publish to NPM code containing a bunch of user PII the problem is why PII was resident in the code in the first prior to publication. The fact that such PII is exposed is now a different second problem demanding a different resolution. You could make the argument that halting and regulating all publications would solve that problem. That is incorrect, because the PII is still exposed within your organization outside of a controlled environment and can still be leaked to the public by various other means.

> Then there is always that part of the organization that isn't judicious about keeping packages up to date, and these kinds of package exposures expose their negligence.

That is dependency management whether or not you own the packages in question. Dependencies need to be appropriately managed for a variety of security reasons. Exposing poor dependency management advertises a vulnerability, but the vulnerability is there anyways and a dedicated malicious attacker will exploit it the same either way.

---

The bottom line is that hiding your security problems by "not publishing" is not a valid security control. That is the dreaded security by obfuscation and it works both ways. By hiding the vulnerability you also hide the exploitation from visibility.

Re: Major bank accidentally published a private package to the public NPM Registry

#227

Post by iooi »

JdeBP wrote: post #191
iooi wrote: post #46

Earlier quoted context omitted.

Please, it's arbitrary to run a private PyPi repository, all you need is a web server and a certain folder structure. If you want, you can even host everything on a private S3 and use a tiny Nginx configuration to authenticate the requests on behalf of pip [1]. Private npm repositories are an entirely different beast, and like GP mentions, there is no great option here. [1] https://www.guido.nyc/pypi-s3/

Potential users should be aware that the quoting in the shell commands on that page is faulty and requires attention.

Can you give an example? Not sure what you're referring to.

Re: Major bank accidentally published a private package to the public NPM Registry

#228

Post by anticensor »

JeremyBanks wrote: post #28
y4mi wrote: post #26

Earlier quoted context omitted.

Thats only true for the US and the countries adhering to US copyright. It's not universally true

It's not "US copyright", it's several international copyright treaties, which 90% of all nations have agreed to: https://en.m.wikipedia.org/wiki/Berne_Convention The few exceptions are where copyright essentially doesn't exist at all. Where it does, this is how it works.

DPRK only recognises foreign copyrights, and have no concept of IP for its own works (because everything is done to superior order, there is no creativity allowed). Micronesia does not have copyright, but has even stricter regime of creative works, amounting to a patent-like protection.

Re: Major bank accidentally published a private package to the public NPM Registry

#229

Post by gpm »

delfinom wrote: post #160
gpm wrote: post #151

Earlier quoted context omitted.

The banks employee granted NPM a (probably) valid license to distribute the code (quoted below - from the tos). Submitting a DMCA request claiming requires claiming under penalty of perjury that no such license exists. That's (probably) incorrect, any lawyer reasonably knows that a license would have been granted, and as such (probably) criminal. Unfortunately (?) this sort of perjury is never prosecuted in practice.…

They can't make the argument that the bank employee had no legal right to grant NPM a license as the bank owns the copyright and not the employee?

Unlikely, npm has a reasonable belief that a bank employee entering into a contract with them has the right to do so, and that is generally sufficient for the contract to be binding on the bank.

Re: Major bank accidentally published a private package to the public NPM Registry

#230

Post by sh4dow »

Ndymium wrote: post #188

A recent experience tells me this is a very easy mistake to do, though. I was using Yarn to publish a package to an internal package repository (so setting `private: true` was not an option). I did not know at the time that Yarn would not honor `publishConfig` in the `package.json` file, and it would also ignore the package's organisation set in `.yarnrc` (which is used to direct read operations to the internal repos…

These days, I would never run publish myself in a corporate environment. A script that is triggered on pushing tags should take of that to precisely avoid such human errors. And of course changes to this script have to be reviewed.

Also, a .rc file (package manager chosen by the team) with a private registry that refuses to publish unless done automatically by the pipeline set in the root of every project.

The only reason I find it understandable how it could happen at a major bank (these days, they should have a sizeable team that takes care of security measures like I described) is that this was 3 years ago. Publishing to private registries was relatively new back then, so people didn't have proper publishing workflows yet.

I mean... I guess mistakes can still happen. But on a scale of 1-10, I would find such a mistake far less excusable today considering the circumstances. Small, inexperienced team, maybe constant deadline pressure - more excusable. Duh...

Post reply on HN