please help me understand - how is it possible that unencrypted environment variables fell into the hands of an attacker?
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.
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?
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.
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 )
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.
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!)
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.
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.
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
- Bitbucket personal/default workspace (if said workspaceās name and the Bitbucket username match, which by the way, they should for the related Bitbucket organization to be supported in CircleCI)
But the rule is indeed: <org_name>/<project_name> user key
.
Thank you for pointing this out.
I see, thanks for checking that!