"You are not authorized" error from nuget.exe push after specifying apikey and providing credentials to prompt

Hi-

We recently updated our proget server (we love the product btw) from 3.2.1 to 3.7.6. I updated our old existing feed to the "new style" v3.3 feed via the "easy" way recommended in the docs. After an IIS reset, everything seemed fine, with the exception of permissions, which retained the users and customized groups from our old install, but did not seem to carry over the privileges associated with the groups. I rebuilt the privileges and ran into a problem:

When we push via nuget.exe (including the API key that is specced for the feed), we are prompted for credentials. This is normal so far. After supplying valid credentials for an account that is in a group with "Feeds_AddPackage" priveleges, we get the error:

Failed to process request. 'There was an error processing the request: You are not authorized to add a package to this feed. By default, ProGet is not configured to allow unauthenticated users to publish packages to a feed. You will need to either authenticate (by using "name:pass" as your API Key) or give the Anonymous User the Feeds_AddPackage privilege.'.

We don't want to give any permissions to anonymous users, and we're fine with both supplying the api key and being prompted for credentials (it's how our pushes worked before with the old version). If I give invalid credentials, it keeps prompting me, so it must be authenticating me at some point. The account in question can push via the website UI, so the permissions seem to be in place. I also tried with our admin account and got the same error.

Any idea about what could be wrong here?

thanks in advance!

Product: ProGet
Version: 3.7.6

Thanks for the report. Are you saying you have specified an API key for the feed and it still prompts for credentials? Can you remove that API key, and try using "username:password" as the key? If that works, then there's a bug, and I'll add that as a fix for the next version.

After further investigation, it seems the NuGet client (v3.1.0 at least) will send an authorization header with the credentials on a GET request immediately before a PUT request (i.e. the push command), but will not resend the credentials on that 2nd PUT request, so ProGet will authenticate the user as the Anonymous user, and that's why you're getting this error message.

This means there's a bug in the NuGet client. You can workaround it in ProGet by granting the Anonymous user the Feeds_AddPackage task for that feed (the API key will still be required), or by removing the feed's API key and using the -ApiKey username:password argument in the NuGet client (which was the original workaround when the v2.6 or older clients did not prompt for credentials).

This is really very BAD advice. Granting the anonymous user the ability to add a package to the feed ONLY requires the API key when attempting to do so using the nuget command line. Random users can still visit the URL in a web browser and click the "Add Package" button to manually upload a package--no API key is required to do this. This is a security hole. ProGet should not be offering this as a workaround as this isn't acceptable and defeats the entire purpose of setting up security on the feed.

Actually, there is nothing wrong with granting the Anonymous user the Feeds_AddPackage task. Although ProGet is not configured that way out of the box, it is typically installed on-prem, and many organizations do not need to secure their feeds internally.

Thus, there is no "security hole" in allowing "a random user" (i.e. an employee or contractor who has access to your network) permission to publish a package, since everything is already traceable and auditable.

It's the same reason you don't necessarily need to lock your desk drawers in your cubicle. It's not a "security hole" that a "random person" could just walk up and steal your belongings because they would already need access to the floor/building.

It is a hole, because if the anonymous user can "view" the feed, then they can add packages to the feed without an API key by simply going to the web interface.

The point of securing the feeds (and using an API key) is to prevent unauthorized users from adding packages. If I allow the anonymous user to add packages, then ANYONE on the network can add a package to my feed. If they add a package with the same name and a later version number with their own malicious code then developers could be using a package with unauthorized code.

Indicating that you can "trace" and "audit" something does not mean it is secure. That's an absolutely absurd statement. Saying I don't need to lock my desk drawer is akin to saying I don't need to lock my desktop computer because anyone in the building is already authorized to be there...do you seriously think any company that takes security seriously would allow for something like that??!?! You'd NEVER see anyone who takes security seriously have the attitude that we don't need to secure anything as long as we can possibly identify the perpetrator after the fact.

Your statement about security is a glaring indicator that Inedo doesn't take security seriously. I really hope that you don't speak for the company on this.

Actually we take security very seriously, and work with everyone from military/governments to garage startups. There is a tradeoff between security and practicality, and oftentimes the more "secure" you attempt to make things, the less secure it actually becomes.

The classic example is post-it notes taped to monitors because of preposterous password complexity/age requirements. In this case, you may end up with personal domain credentials hard-coded in scripts.

One of the best analogies I can offer you to better understand/implement proper security best practices in your organization is being on the other side of this airtight hatchway. In this case, the "attack vector" you describe is a non-concern, because most organizations have dozens of much simpler attack vectors -- sneaking into the server room for example -- that a malicious actor would use instead.

If your organization is not security-sensitive (i.e. most organizations), then a "trust but verify" policy is perfectly adequate. If you already have trusted access to access the network (i.e. that's the airtight hatchway), then adding cumbersome barriers will lead to less secure practices, which we do not recommend.

Again, I know of no organization where there is even a modicum of concern for security that would grant unfettered access to a system just because someone is already granted access to the network. Common sense doesn't allow for that. You're saying if you can get in, then we trust you. I'm sure your own organization, for example, doesn't grant domain admin privileges to every user on the network (because they make the assumption that if you're on the network then you are trusted). No...again, absurdity. Your hatch example is the firewall on a network. Once you get past the firewall and are on the network, there are still lots of security measures in place at any sane organization.

Practicality is about being able to secure at various levels of granularity. You protect the network. Then you also protect your applications. You are trying to tell ProGet users that protecting the network is enough, when in reality, that's not the case. If you really can't see that distinction you shouldn't be the voice of "security best practices according to Inedo"--every single person/group with any education and experience in properly securing an IT infrastructure will disagree with you. There's a well-known concept known as "The Principal of Least Privilege" (https://kb.iu.edu/d/amsv)...you're comments clearly indicate you have no background in security and don't understand this concept (and as such you should not be dispensing advice to users on anything security related).

And organizations which are not "security sensitive" are asking for trouble. And I've worked with DOD, NIH, and other government agencies and your idea of security is vastly different from theirs! There's mad security to get into the buildings, then floor level security, then two-factor security to log-in to a machine, then specialized application level security for various apps, etc....way beyond the simplistic (non-secure) approach that you are advocating here.

Perhaps you need a refresher on common sense security: http://www.commonsenseframework.org/

Thanks for the additional feedback! Do keep in mind that this was simply one possible work-around for a bug in the NuGet client that they fixed more than a year ago. Also do note that, when you grant a user Feeds_AddPackage to a user, they only have access to do that task. Which in this case, is very minimal. They do not become ProGet administrators, etc.

In Windows, you can actually configure all users to be "Domain Administrators" (or have "root" open in Linux). We offer the same flexibility in ProGet, and you can configure ProGet to be as secure or open as needed. This is actually a very common feature in software/vendor products and, like most software vendors, we empower users to decide how secure or open to make their instance based on their specific needs and requirements.

Unfortunately we can't offer specific advice to everyone on our forums on how to decide which policies suit them, but we do have some training and certification courses which offer lots of security topics (including awareness of the "security hole" you described, as well as lots of other potential attack vectors).

You seem to be quite passionate about organizational security (i.e. InfoSec), which is awesome! There's a ton of great sources out there, but I would highly recommend you follow Krebs on Security and Schneier on Security. Those are some great starting points which you can use to starting learning how to develop best practices in your own organization :)