MyGetUcsb PowerShell Module

MyGet.org makes a great product, as written about many other places (Hanselman, Channel 9). However they don’t have a prebuilt toolset to automate tasks for working with MyGet. It’s a bit ironic that MyGet doesn’t publish their own nuget packages.

So, MyGetUcsb is a small PowerShell wrapper around their REST Management API. It’s not a complete implementation of their API, and it doesn’t work “right out of the box”.

• Not a full implementation
  
• It only implements the functions that were necessary to setup user accounts in the way our department needed them to be setup.
  
• Doesn’t work “right out of the box”
  
• The security system is implemented to use a private instance of Secret Server. You’ll need to replace the code that retrieves the API Key with your implementation.
  
• Unsupported and No Plans to Work On
  
• The implementation was just to solve a problem/need that our department had. There’s no plans to support or improve the project in the future. But, feel free to use it as a reference project to build from.

Surprisingly, the Enterprise package (with limited SSO integration) still requires all team members to have MyGet Accounts. All team members must maintain their passwords for MyGet. It’s important they store their MyGet username/password information securely as it’s needed to use the feeds.

To use the module is pretty straight forward. This is an example that will query AD to pull some user information. Convert the information into user objects and then populate MyGet with the account information.

npm Revoking All Tokens Was A Good Call

A week or so ago an ESLint project maintainer’s npmjs key was compromised. The compromised account was then used to upload alterations into some popular ESLint npm packages. The end goal of the altered code was to capture more credentials from open source package maintainers; presumably to create a truly malicious alteration at a future date.

A few things were interesting about the whole event. One of the first things that struck me was the quick and uniform responsiveness of the community. Looking through npmjs’ timeline and the initial bug report, it looks like the attacker published the malicious package at 3:40 AM PST on 7/12/2018. And the initial bug report came in around 4:17 AM PDT. That is an amazing turn around time of 27 minutes. It seemingly supports the open source mantra that “many eyes make a shallow problem”.

The response of the package maintainers and their community members was also fantastic. By 4:59 AM PDT (42 minutes after the report) they had determined that something was seriously wrong and they needed to (a) unpublish the package and (b) had already communicated with downstream sources that they needed to remove all references to the package. This wasn’t done by one person struggling to grapple with the situation, but everyone that was looking at the issue was seeing if they could inform other groups that a serious problem was occurring and action needed to be taken.

What really struck me was that npm’s administrators determined the correct course of action was to revoke all npmjs tokens created between 7/10/2018 at 5:00 PM PDT and 7/12/2018 at 5:30 AM PDT. npm’s administrators looked at the situation and instead of focusing on just the accounts that they knew to be compromised, they just said we don’t know who to trust right now. They had a reasonable expectation that something very wrong happened in that time frame and they weren’t going to take any chances with it. It was a really big decision, and I’m sure some people were really inconvenienced by it. But it was a well calculated move that took into consideration both security and scope. It was a good call.

Two things still bug me about the whole incident:

1. How did the package maintainer’s credentials become compromised?
2. What if the malicious update didn’t cause a compilation error? How long would it have gone undetected? Can many eyes make a shallow problem if there’s no problem to be seen?

The weird thing about this incident is that it reminds me of a blog post from January 2018, “I’m harvesting credit card numbers and passwords from your site. Here’s how.”. In the (hopefully fictitious) blog post it outlines how a small piece of malicious code could potentially be added into an open source project and get put into production use. If you take many of the reasonable claims that blog author makes and add to them the idea that a package maintainers publishing key is compromised, it would take the first set of eyes out of the equation. And those eyes are arguably the most important. The blog post posits truly cryptic code to get the pull request accepted. But, what if the attacker didn’t need to make the code overly cryptic, because the attacker had the ability to accept and publish?

I don’t know.

The one thing I take away from this is that the community acted very responsibly and swiftly; and that’s something to respect and strive to replicate.

Apigee–API Key from Query String or HTTP Header

Apigees’ API Proxy samples are a great way to get started, but many usage scenario aren’t available as a sample. A somewhat common scenario is wanting to check for an API Key in multiple places. In this exapmle, the proxy will need to be able to check for a API Key that is present as a query string parameter or an HTTP header. This allows the Gateway to adhere to Postel’s Law by allowing the client to determine what’s the best way to transmit the information to the service.

That’s all a fancy way of saying: Let’s make it easy check if the API Key is passed in as a Header or a Query String.

Unfortunately, with Apigee, it’s not so easy to check both of them. In this example, we’ll use a Javascript Policy to check if the API Key exists in the query string. If it does, the value will be copied into a header variable. After that, a normal Verify API Key Policy will be used to check the header value.

Hopefully, in a future post, I can reimplement this using only Apigee Policies and without using Javascript. There is a performance penalty that comes with using Javascript in Apigee and I would like to see just how severe that penalty can be.

Here is a Shared Flow that will do just the two steps mentioned above:

And, now for the Javascript. Which is a combination of a Policy and a .js file. This one does all the heavy lifting:

Finally, use the standard Verify API Key policy to check the header value: