[CircleCI Security Alert] Rotate any secrets stored in CircleCI

please help me understand - how is it possible that unencrypted environment variables fell into the hands of an attacker?

1 Like

CircleCI is now doing this on their side - see their blog updates.

GitHub OAuth: We are currently rotating all GitHub OAuth tokens on behalf of customers. We expect this process to be complete by 00:00 UTC on Jan 7, 2023. We will update here when this process is done. Customers who wish to rotate their own GitHub OAuth tokens may follow the directions below.

1 Like

Thanks to the CircleCI team for keeping us updated in this thread.

One thing Iā€™d like to understand the implications of, following-up on Step 6 of the updated instructions:

Regarding Project SSH keys:

6. Project SSH keys:
  1. Go to Project Settings > SSH Keys.
  2. Delete the Deploy Key and add it again.
  3. If you were using any additional keys, then those need to be deleted and recreated.
  4. Note: We recommend this for all projects (ā€œgo to Project Settingsā€), orgs (ā€go to Organization 
  Settingsā€), and users (ā€œgo to User Settingsā€).

Would the actor(s) who maliciously gained access to the Deploy SSH Keys also know the GitHub (or any other applicable VCS) org and project name/alias that the key is associated with?

Currently trying to understand the risks of someone accessing private source code, and I imagine knowing the github.com/$ORG_NAME/$REPO_NAME would be key to leveraging the Deploy SSH Keys.

@squaringthecircle,
Whether you retrieved them via the UI or the CircleCI API, the value of environment variables is always masked.

Also, by default the secrets-masking feature is enabled for all projects, so the values canā€™t be printed out in a build job; unless we specifically disable said feature; we can do so on a per-project basis, and upon your explicit request.

@jscheel,
This is likely how you understood it, but I want to make sure this topic really clear.

The GitHub tokens weā€™ve rotated are the OAuth tokens; the one that are initially automatically created by the CircleCI-GitHub integration when a user signed up to CircleCI via GitHub.

These are not the GitHub personal access tokens you might have created yourself under your GitHub account; we have no access to these.

Unless you stored any GitHub personal access tokens as an environment variable in a CircleCI project or context, you donā€™t specifically need to rotate them; although it is good practice to do so regularly.

 

Do we need to rotate this secret?

Yes.
 

How do we rotate this secret in the CircleCI plugin in Jira? The secret appears to be hardcoded and I canā€™t see how to regenerate it.

You need to uninstall the ā€œCircleCI for Jiraā€ app in your Jira instance; this will automatically revoke the authentication in your projectā€™s ā€œJira Integrationsā€ section.

Next, you need to re-install the ā€œCircleCI for Jiraā€ app; doing so will generate a new token (in Jira) that you can then add to your projectā€™s ā€œJira Integrationsā€ settings.

Hi,

Step 6-4 in ā€œUpdated instructions as of 17:52 UTC on January 6ā€ says ā€œNote: We recommend this for all projects (ā€œgo to Project Settingsā€), orgs (ā€go to Organization Settingsā€), and users (ā€œgo to User Settingsā€).ā€, but as far as I checked app.circleci.com/settings/organization/github/${MY_ORG}/overview and app.circleci.com/settings/user , no SSH key related settings seems to exist.

Could anyone help me to understand what are the exact steps?

2 Likes

Hi, regarding this quote:

OAuth tokens : For GitHub: As of 07:30 UTC on January 7, all GitHub OAuth tokens have been rotated on behalf of CircleCI customers. Customers who wish to do so may rotate their own OAuth tokens by logging out of the CircleCI application, going to https://github.com/settings/applications, selecting ā€œAuthorized OAuth Appsā€, and then revoking the CircleCI entry. Once thatā€™s done, log back into CircleCI to trigger reauthorization.

I donā€™t understand the phrasing. The first sentence claims that the token has already been rotated, but the second sentence claims that we should rotate it. Does that mean that we need to revoke and reauthorize the access of circleci in Github or not?

Hi A few clarifications please:

For Bitbucket: As of 10:00 UTC on January 6, 2023 our partners at Atlassian expired all OAuth tokens for Bitbucket users. Bitbucket tokens will refresh for users upon login, and no additional action is needed here. Bitbucket users will still need to replace SSH tokens.

Can you clarify what that last part means please as it is not clear to me? i.e. what ssh tokens and where?

Can you confirm that only projects connected to CCI i.e. via Bitbucket need to be audited? And that other non connected projects on that GitHub or BB account are not at risk?

Can you confirm if there is an audit log available for a bitbucket repository or organisation? Other than going through commits on individual repos, I see no access logs available in Bitbucket, but the suggestion in your FAQ is that there is a way of doing this.

Thanks

All posts so far seem to indicate that CircleCi is taking the view that all data is at risk and so should be regenerated. This makes a lot of sense for a system-wide issue as anything else would need the reviewing of a lot of fine detail logs which may or may not exist.

2 Likes

I am also confused about this!

I know User SSH keys exist as an option ā€“ see this process here. Less common than deploy keys in my experience. If you used it maybe youā€™d see something on the user page? Clarification from CircleCI would be great.

User SSH keys are an area where it would be great to be able to see in CircleCI UI or API which users had used the feature. Users need to take individual action to revoke, which is hard for organisations to manage. For many organisations this could confirm no-one had used the feature.

I donā€™t understand what would be on the organisation page. There is no notion of an organisation SSH key in GitHub so far as Iā€™m aware. Clarification from CircleCI here would be really useful.

So as of Friday, we completed this action so the customer no longer needs to do it. What we were trying to convey is if they already had rotated user OAuth tokens or wish to do so again, there is no detriment. Sorry for any confusion!

HI @makotoshimazu,

Thank you for pointing this out, and please accept our apologies for the confusion.

There are indeed no SSH key related information under ā€œUser Settingsā€ or ā€œOrganization Settingsā€.

We are in the process of updating the ā€œProject SSH keysā€ section of the blog post to bring more clarity about the required actions.

 
Hello @microbit-matth,

Iā€™m sincerely sorry this paragraph caused some confusion.

I confirm that SSH keys are only present in ā€œProject Settingsā€.

There are 3 types of SSH keys you can find in the ā€œSSH Keysā€ section of a given ā€œProject Settingsā€:

  • Deploy Key. There can be either one or none per project.
  • User Key. There can be either one or none per project.
  • Additional SSH Key(s). There can be none, only one, or several in a given project.

There are no SSH key related settings/information in the ā€œUser Settingsā€.

 

User SSH keys added to ā€œProject Settings > SSH Keysā€ can easily be linked to the VCS user they belong to. Those keys are always named according to this format: <vcs_username>/<project_name> user key.

The above is actually incorrect. The format for the SSH keys names is:

  • <org_name>/<project_name> deploy key for deploy keys
  • <org_name>/<project_name> user key for user keys

(Thank you @microbit-matth for pointing this out :pray: )

 

This is correct. There are no SSH key settings of any sort in the ā€œOrganization Settingsā€.

 
We are currently updating the ā€œProject SSH keys ā€ section of the blog post to bring more clarity about the required actions.

3 Likes

Any repository stored with BitBucket for a project on CircleCI will need to have their SSH keys replaced, and those repositories audited. In BitBucket, you can find the user-level audit log under >https://bitbucket.org/ account/settings/auditlog/, and for the workspace/org level, you can find the audit log under > https://bitbucket.org/ <org_name>/workspace/settings/auditlog.

(ty @yannCI for the info!)

2 Likes

As I have a free plan-based service can I ask for ticket #125038 to be upgraded from the general 3-5 business day service level as I have manually deleted the connection at the Bitbucket level.

While you have been working with Atlassian to make the process far simpler Iā€™m starting from a blank slate as our environment has been a mix of R&D and production configurations for far too long.

Thanks for the response, really useful to know itā€™s all about the project keys and user keys are shown there. I was able to use the project API to audit these by checking for type-=github-user-key and check in the UI for the key names.

I see the key names in the format ā€œ{my org}/{my project} user keyā€ so doesnā€™t seem to directly link to the user for org projects.

In my case I can identify the user based on the project history but for users with more widespread use this might be more of a challenge.

1 Like

How are we supposed to remove the secrets in an archived repo? In the old circleci, I can goto the project page of a repo that is ā€œnot setupā€, but now it pops up a wizard that requires a valid config.yml reference.

1 Like

Youā€™re absolutely right, @microbit-matth!

The format of the SSH keys names is: <org_name>/<project_name> user key.

It just happens to be equivalent to <vcs_username>/<project_name> user key when the organization in CircleCI corresponds to a:

  • GitHub personal account

or

 
But the rule is indeed: <org_name>/<project_name> user key.

Thank you for pointing this out.

I see, thanks for checking that!

1 Like