If you own a GitHub organization and are looking for what changes/controls you can apply to reduce the risk/impact of PAT token exfiltration (and subsequent abuse) like what occurred here, I listed a few at the end of https://blog.bored.engineer/github-canarytokens-5c9e36ad7ecf...
- Enable audit log streaming[1] on your enterprise including source IPs and API requests, even if it’s just going to an S3 bucket nobody looks at it, your incident response team will thank you later.
- Enforce the use of SSO on your GitHub organization[2], not just because SSO is good but because it forces an explicit authorization action[3] by users to grant an SSH key/PAT access to your organization resources, instead of granting access implicitly. That way the PAT created for someone’s weekend project won’t have access to your organization resources.
- Enforce an IP allowlist[4] for your organization from a set of known trusted VPN/corporate IPs. This is by-far the strongest control (and the most painful to rollout) as it will prevent stolen credentials (even if still valid) from being used by an attacker except on the intended systems where you (hopefully) have other visibility/alerting via EDR or related tooling.
- If you can, restrict access from personal access tokens[5] to your organization resources. Blocking classic PATs and enforcing a maximum expiration (ex: 3 months) on fine-grained PATs is a great way to reduce risk if you can’t eliminate PATs altogether[6].
- If you use GitHub enterprise (on-prem), configure collection of the raw HTTP access logs[7] in addition to native GitHub audit logs, it may prove critical during incident response.
The newer global node IDs (which can be forced via the 'X-Github-Next-Global-ID' header [1]) have a prefix indicating the "type" of object delimited by an underscore, then a base64 encoded msgpack payload. For most objects it contains just a version (starting at 0) followed by the numeric "databaseId" field, but some are more complex.
For example, my GitHub user [2] has the node ID "U_kgDOAAhEkg". Users are "U_" and then the remaining data decodes to: [0, 541842] which matches the numeric ID for my user accepted by the REST API [3].
You shouldn't rely on any of this implementation of course, instead just directly query the "databaseId" field from the GraphQL API where you need interoperability. And in the other direction the REST API returns the "node_id" field for the GraphQL API.
For folks who finds this interesting, you might also like [4] which details GitHub's ETag implementation for the REST API.
- Enable audit log streaming[1] on your enterprise including source IPs and API requests, even if it’s just going to an S3 bucket nobody looks at it, your incident response team will thank you later.
- Enforce the use of SSO on your GitHub organization[2], not just because SSO is good but because it forces an explicit authorization action[3] by users to grant an SSH key/PAT access to your organization resources, instead of granting access implicitly. That way the PAT created for someone’s weekend project won’t have access to your organization resources.
- Enforce an IP allowlist[4] for your organization from a set of known trusted VPN/corporate IPs. This is by-far the strongest control (and the most painful to rollout) as it will prevent stolen credentials (even if still valid) from being used by an attacker except on the intended systems where you (hopefully) have other visibility/alerting via EDR or related tooling.
- If you can, restrict access from personal access tokens[5] to your organization resources. Blocking classic PATs and enforcing a maximum expiration (ex: 3 months) on fine-grained PATs is a great way to reduce risk if you can’t eliminate PATs altogether[6].
- If you use GitHub enterprise (on-prem), configure collection of the raw HTTP access logs[7] in addition to native GitHub audit logs, it may prove critical during incident response.
[1]: https://docs.github.com/en/enterprise-cloud@latest/admin/mon... [2]: https://docs.github.com/en/enterprise-cloud@latest/authentic... [3]: https://docs.github.com/en/enterprise-cloud@latest/authentic... [4]: https://docs.github.com/en/enterprise-cloud@latest/organizat... [5]: https://docs.github.com/en/enterprise-cloud@latest/organizat... [6]: https://edu.chainguard.dev/open-source/octo-sts/overview/ [7]: https://docs.github.com/en/[email protected]/admin/moni...