5 ms·

No mention why this temp token had rights to do things like create a new deployments and generate artifact attestations? For their fix, they disabled debug log

No mention why this temp token had rights to do things like create a new deployments and generate artifact attestations? For their fix, they disabled debug logs...but didn't answer if they changed the temp tokens permissions to something more appropriate for a code analysis engine.

declan_roberts 2y ago
I think we all know this old story. The engineer building it was getting permission denied so they gave it all the permissions and never came back and right-sized.
- azemetre 2y ago
  What's the over/under that said engineer could solve two medium leetcodes in under and hour?
- setr 2y ago
  Does any RBAC system actually tell you the missing permissions required to access the object in question? It’s like they’re designed to create this behavior
  - levkk 2y ago
    Not usually, that's considered an potential attack vector I believe. You're looking to minimize information leakage.
  - Normal_gaussian 2y ago
    Yes. Most auth systems do to the developer - GCP & AWS IAM give particularly detailed errors; nearly every feature/permission system I have implemented did. However, it wouldn't be unusual for the full error to be wrapped or swallowed by some lazy error handling. Its a bit of a PITA but well worth it to translate to a safe and informative user facing error. as a nit; RBAC is applied to an object based permissions system rather than being one. Simply, RBAC is a simplification of permission management in any underlying auth system.
    - 8note 2y ago
      ive never seen aws give a useful error where i could say which resources need a handshake of permissions, or which one of the two needs the permission granted, or which permission needs to be granted.
      - milch 2y ago
        AWS throws errors that look like `arn:aws:iam:... is not authorized to call "$SERVICE_NAME:$API_NAME" on resource arn:aws:$SERVICE_NAME:...`. I think it's more complicated when you go cross account, and the receiving account doesn't have permissions set up (if the calling account doesn't have it set up you get the same error). In any case you would still find that information in the CloudTrail logs of the receiving account
        hobs 2y ago
        Right, you can go to cloudtrail and probably get it, but I have definitely ran into things like service says you do not have access to resource or it does not exist - randomly providing the account some other tangentially related permission magically fixes it, I've found sometimes trying the UI and the API will give different errors to help, and neither is particularly more useful than the others.
        deleted 2y ago
        [deleted]
        bshacklett 2y ago
        assuming you can get the cloud trail message sometimes there’s more information that you can decode using the STS service: https://docs.aws.amazon.com/cli/latest/reference/sts/decode-authorization-message.html https://docs.aws.amazon.com/cli/latest/reference/sts/decode-...
        donavanm 2y ago
        Look in to the AWS IAM “service description files” aka SDF. Thats exposed via the console Policy Builder or Policy Evaluator logic. The SDF _should_ encode all the context (eg resource attributes, principal metadat) that goes in to the authz decision. The most common opaque issue youll see is where one action has other required resources/actions. Eg a single action attaching an ebs volume requires permission on both instance and volume and _maybe_ kms key with permissions across those services.
  - UltraSane 2y ago
    AWS has a neat feature to analyze cloudtrail logs to determine needed permissions.
  - Uvix 2y ago
    Azure’s RBAC system usually tells you this, at least when accessing the Azure management APIs. (Other APIs using RBAC, like the Azure Storage or Key Vailt ones, usually aren’t so accommodating. At least by their nature there’s usually only a handful of possible permissions to choose from.)
Elucalidavah 2y ago
> For their fix, they disabled debug logs For their quick fix, hopefully not for their final fix.
arccy 2y ago
just goes to show how lax microsoft is about their security. nobody should trust them.
stogot 2y ago
The 2023 Microsoft hack (that CISA completely called them out for poor security) also was similar to this. Their blog post that tried to explain what happened left so many unanswered questions
beaugunderson 2y ago
Temporary action tokens have full write by default; you have to explicitly opt for a read-only version. > Read and write permissions > Workflows have read and write permissions in the repository for all scopes. If you read this line of the documentation (https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token https://docs.github.com/en/actions/security-for-github-actio...) you might think otherwise: > If the default permissions for the GITHUB_TOKEN are restrictive, you may have to elevate the permissions to allow some actions and commands to run successfully. But I can confirm that in our GitHub organization "Read and write permissions" was the default, and thus that line of documentation makes no sense.
Pathogen-David 2y ago
If the GitHub Actions temporary token does not have workflow-defined permissions scope, it defaults either to a permissive or restricted default scope based on the repository's setting. This setting can also be configured at the organization level to restrict all repos owned by the org. Historically the only choice was permissive by default, so this is unfortunately the setting used by older organizations and repos. When a new repo is created, the default is inherited from the parent organization, so this insecure default tends to stick around if nobody bothers to change it. (There is no user-wide setting, so new repos owned by a user will use the restricted default. I believe newly created orgs use the better default.) [0]: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token https://docs.github.com/en/actions/security-for-github-actio...

declan_roberts 2y ago

I think we all know this old story. The engineer building it was getting permission denied so they gave it all the permissions and never came back and right-sized.

azemetre 2y ago
What's the over/under that said engineer could solve two medium leetcodes in under and hour?
setr 2y ago
Does any RBAC system actually tell you the missing permissions required to access the object in question? It’s like they’re designed to create this behavior
- levkk 2y ago
  Not usually, that's considered an potential attack vector I believe. You're looking to minimize information leakage.
- Normal_gaussian 2y ago
  Yes. Most auth systems do to the developer - GCP & AWS IAM give particularly detailed errors; nearly every feature/permission system I have implemented did. However, it wouldn't be unusual for the full error to be wrapped or swallowed by some lazy error handling. Its a bit of a PITA but well worth it to translate to a safe and informative user facing error. as a nit; RBAC is applied to an object based permissions system rather than being one. Simply, RBAC is a simplification of permission management in any underlying auth system.
  - 8note 2y ago
    ive never seen aws give a useful error where i could say which resources need a handshake of permissions, or which one of the two needs the permission granted, or which permission needs to be granted.
    - milch 2y ago
      AWS throws errors that look like `arn:aws:iam:... is not authorized to call "$SERVICE_NAME:$API_NAME" on resource arn:aws:$SERVICE_NAME:...`. I think it's more complicated when you go cross account, and the receiving account doesn't have permissions set up (if the calling account doesn't have it set up you get the same error). In any case you would still find that information in the CloudTrail logs of the receiving account
      - hobs 2y ago
        Right, you can go to cloudtrail and probably get it, but I have definitely ran into things like service says you do not have access to resource or it does not exist - randomly providing the account some other tangentially related permission magically fixes it, I've found sometimes trying the UI and the API will give different errors to help, and neither is particularly more useful than the others.
        deleted 2y ago
        [deleted]
        bshacklett 2y ago
        assuming you can get the cloud trail message sometimes there’s more information that you can decode using the STS service: https://docs.aws.amazon.com/cli/latest/reference/sts/decode-authorization-message.html https://docs.aws.amazon.com/cli/latest/reference/sts/decode-...
        donavanm 2y ago
        Look in to the AWS IAM “service description files” aka SDF. Thats exposed via the console Policy Builder or Policy Evaluator logic. The SDF _should_ encode all the context (eg resource attributes, principal metadat) that goes in to the authz decision. The most common opaque issue youll see is where one action has other required resources/actions. Eg a single action attaching an ebs volume requires permission on both instance and volume and _maybe_ kms key with permissions across those services.
- UltraSane 2y ago
  AWS has a neat feature to analyze cloudtrail logs to determine needed permissions.
- Uvix 2y ago
  Azure’s RBAC system usually tells you this, at least when accessing the Azure management APIs. (Other APIs using RBAC, like the Azure Storage or Key Vailt ones, usually aren’t so accommodating. At least by their nature there’s usually only a handful of possible permissions to choose from.)

Elucalidavah 2y ago

> For their fix, they disabled debug logs For their quick fix, hopefully not for their final fix.

arccy 2y ago

just goes to show how lax microsoft is about their security. nobody should trust them.

stogot 2y ago

The 2023 Microsoft hack (that CISA completely called them out for poor security) also was similar to this. Their blog post that tried to explain what happened left so many unanswered questions

beaugunderson 2y ago

Temporary action tokens have full write by default; you have to explicitly opt for a read-only version. > Read and write permissions > Workflows have read and write permissions in the repository for all scopes. If you read this line of the documentation (https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token https://docs.github.com/en/actions/security-for-github-actio...) you might think otherwise: > If the default permissions for the GITHUB_TOKEN are restrictive, you may have to elevate the permissions to allow some actions and commands to run successfully. But I can confirm that in our GitHub organization "Read and write permissions" was the default, and thus that line of documentation makes no sense.

Pathogen-David 2y ago

If the GitHub Actions temporary token does not have workflow-defined permissions scope, it defaults either to a permissive or restricted default scope based on the repository's setting. This setting can also be configured at the organization level to restrict all repos owned by the org. Historically the only choice was permissive by default, so this is unfortunately the setting used by older organizations and repos. When a new repo is created, the default is inherited from the parent organization, so this insecure default tends to stick around if nobody bothers to change it. (There is no user-wide setting, so new repos owned by a user will use the restricted default. I believe newly created orgs use the better default.) [0]: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token https://docs.github.com/en/actions/security-for-github-actio...