security: analyze dependencies for malicious behavior

[varunsh-coder]

This PR

1. Adds harden-runner GitHub Action to the workflow.
2. Sets the token permission for the workflow to contents: read. This is a security best practice and gets you are higher Scorecard score. You can use https://app.stepsecurity.io to automate some of the fixes, such as pinning actions to commit SHA...

harden-runner GitHub Action detects hijacked dependencies and compromised build tools. It correlates outbound traffic with each step of the workflow so you can see what processes are calling what endpoints. This is the analysis when run on a fork: https://app.stepsecurity.io/github/varunsh-coder/DefinitelyTyped/actions/runs/1928867032

You can restrict traffic to the allowed endpoints for future runs which will block calls that compromised dependencies typically make, and an annotation will be shown in such cases. You do not need to grant any permission or install any App to use this, and the action (and agent the action uses) are open source.

Information on how harden-runner could have detected past package hijacks can be found here: https://github.com/step-security/supply-chain-goat. Do share feedback to improve the harden-runner GitHub Action developer experience. Thanks!

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change.
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm test <package to test>.

Select one of these and delete the others:

If adding a new definition:

• The package does not already provide its own types, or cannot have its .d.ts files generated via --declaration
• If this is for an npm package, match the name. If not, do not conflict with the name of an npm package.
• Create it with dts-gen --dt, not by basing it on an existing project.
• Represents shape of module/library correctly
• tslint.json should contain { "extends": "@definitelytyped/dtslint/dt.json" }, and no additional rules.
• tsconfig.json should have noImplicitAny, noImplicitThis, strictNullChecks, and strictFunctionTypes set to true.

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: <>
• If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.

If removing a declaration:

• If a package was never on Definitely Typed, you don't need to do anything. (If you wrote a package and provided types, you don't need to register it with us.)
• Delete the package's directory.
• Add it to notNeededPackages.json.

[typescript-bot]

@varunsh-coder Thank you for submitting this PR! I see this is your first time submitting to DefinitelyTyped 👋 — I'm the local bot who will help you through the process of getting things through.

This is a live comment which I will keep updated.

This PR touches some part of DefinitelyTyped infrastructure, so a DT maintainer will need to review it. This is rare — did you mean to do this?

0 packages in this PR (and infra files)

• Infra files
  • .github/workflows/CI.yml

Code Reviews

There aren't any other owners of this package, so a DT maintainer will review it.

You can test the changes of this PR in the Playground.

Status

• ✅ No merge conflicts
• ✅ Continuous integration tests have passed
• 🕐 A DT maintainer needs to approve changes which affect DT infrastructure (.github/workflows/CI.yml)

Once every item on this list is checked, I'll ask you for permission to merge and publish the changes.

---

Diagnostic Information: What the bot saw about this PR

{
  "type": "info",
  "now": "-",
  "pr_number": 59091,
  "author": "varunsh-coder",
  "headCommitOid": "6323f8d65ef5f734e6889b97534df79e3d95ad39",
  "mergeBaseOid": "772aa755179639b32de9c6bb8c2154a6bfadb2b8",
  "lastPushDate": "2022-03-03T15:32:57.000Z",
  "lastActivityDate": "2022-03-03T15:39:55.000Z",
  "hasMergeConflict": false,
  "isFirstContribution": true,
  "tooManyFiles": false,
  "hugeChange": false,
  "popularityLevel": "Well-liked by everyone",
  "pkgInfo": [
    {
      "name": null,
      "kind": "edit",
      "files": [
        {
          "path": ".github/workflows/CI.yml",
          "kind": "infrastructure"
        }
      ],
      "owners": [],
      "addedOwners": [],
      "deletedOwners": [],
      "popularityLevel": "Critical"
    }
  ],
  "reviews": [],
  "mainBotCommentID": 1058169291,
  "ciResult": "pass"
}

[typescript-bot]

🔔 @varunsh-coder — there are no owners, but it would still be good if you find someone to review this PR in the next few days, otherwise a maintainer will look at it. (And if you do find someone, maybe even recruit them to be a second owner to make future changes easier...)

[RyanCavanaugh]

Thanks for the (automated??) PR, but this isn't something we'd like to add to the actions at this time.

[varunsh-coder]

Thanks for the (automated??) PR, but this isn't something we'd like to add to the actions at this time.

Hi @RyanCavanaugh it was not automated :). I had created it manually. No problem. Request you to please share feedback though, e.g. what are your concerns in adding it, that will be really helpful. Thanks!

[RyanCavanaugh]

I don't see how this meaningfully improves the security posture of a project, and it increases the surface area in the process by virtue of being another component.

How does someone hijack a dependency?

• At its source -> this does nothing
• Editing our package-lock.json -> someone capable of doing this can equally modify CI.yml and disable this

Once the dependency is hijacked, how does this help?

• Inflitration is N/A since a different dependency is already loaded
• Almost all of these actions still need access to github.com or api.github.com, or other endpoints with writeable channels, and I can still secretly exfiltrate data through posting comments to a private repo using an auth token on that channel. A dependency asking for network access to those domains would almost certainly be allowed. For example, the vscode-write-access attack would not have been mitigated by monitoring network traffic, since the malicious traffic still went to github.com

[varunsh-coder]

Thanks @RyanCavanaugh for the comments. I should have provided more clarity when creating PR. There are different scenarios.

In this case, my intent was to detect hijacked/ malicious dependencies as was the case in these past incidents (listed below). The scenario being that as part of normal dependency version updates in the package.json/ package-lock.json file, a new version of one of the dependency packages may be compromised. Or it may be that someone accidentally uses a typo-squatted library in the package.json.

In all these cases, an immediate outbound call was made, typically to an IP address, as part of the npm install step. My thinking was that that request would get blocked, and show up an as annotation in the workflow, and someone will take notice of it before publishing a package that uses the hijacked dependency.

1. Compromise of NPM packages coa and rc
2. Compromise of ua-parser-js
3. The klow / klown / okhsa incident
4. NPM nukes NodeJS malware opening Windows, Linux reverse shells
5. HardHat typosquatting issue

For the scenario of vscode-write-access attack, and increase surface area, I had set the token permissions to contents: read, so even if the token was compromised in this particular workflow, it would have limited value.

JFYI, since you have good knowledge of these past attacks, also wanted to share this issue where we are trying to investigate setting node policy to restrict API access for dependencies. The analysis on past incidents that I shared above was done as part of this issue. Request you to please share ideas on this as well.