c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
Community Rules
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities [email protected] [email protected] [email protected] [email protected] [email protected]
Notable mention to [email protected]
Anybody that got bit by this, there's a drop in replacement at step-security/changed-files
They also have a good write-up of the incident https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised that shows how to tell if you were hit.
Sounds like the exploit is really just consolidating the unencrypted secrets that were stored by devs in public logs. Or am I missing something?
Devs, secure your secrets. Encrypt your secrets. Ensure secrets don't show in plain text in your logs. Audit your third party usage.
That's not how it worked. Secured secrets were read from the context where they are used and printed to logs (albeit run through base64 twice). E.g. here's the API key for the automation to use the API but it's not just used, it's also printed.
The prevention to this situation has nothing to do with secrets and everything to do with pinning 3rd party actions to specific commits. Release versions are not immutable.
I'm very glad that the compromise didn't reach out with the secrets, so private repos got hit with a switch and not a 2x4.
Thank you for the clarification.
As I understand it, the exploit was leaking the secrets from the place in the CI pipeline where they were supposed to be, into the public logs.
And then I store the encryption key in another repo to ensure the compliance checkmark gets checked? (/s)