CircleCI Security Incident
support.circleci.com
support.circleci.com
So, did they do anything about that?
Even if using iframes and a secure api over postMessage/onmessage: safe, and security can be controlled by the external provider i.e. safer for both parties (ideally the servers pass the security context between each other - we even use an iframe internally for all the same reasons).
https://kevin.burke.dev/kevin/circleci-is-hopelessly-insecur...
Google allows custom JS injection via Tag manager, so there are possible vectors, even if only access to 3rd party site was stolen. Of course I have no idea what was the deal here.
It's worth noting, that CircleCI did nothing to address issues raised in the linked post. Their main app still loads tons of third party analytics garbage for e.g. Google, Hotjar, Amplitude and even Facebook of all people. I do block all those, but as someone pointed out it's not a solution and cant even be reliable at all times.
Please bear in mind, that CircleCI not only has access to private repositories. More often then not they do store private SSH keys to your production servers.
The 2019 post is vague but I think what happened is an attacker stole the credentials for e.g CircleCI’s account for Google Analytics. So an attacker could see URL’s that were visited, IP addresses, but they couldn’t run JavaScript on CircleCI’s domain.
The difference is between an attacker compromising the Google Analytics JavaScript snippet CDN and an attacker compromising a Google Analytics user account. The latter only lets you read the metadata not make any of the juicy AJAX calls.
(Also, it’s probably not actually Google Analytics, just listing a tool most people are familiar with).
It’s obviously not good but it’s not the same vulnerability I wrote about nor as bad as the one I described two years ago.
However if they haven’t resolved an obvious security issue in two years, that is a strong signal that security is a low priority, which is relevant to their risk of compromise (as has occurred).
Integrating third-party JavaScript has multiple known solutions that are secure, but they require choosing compromises and are usually significant work to implement. If CircleCI haven’t fixed serious security issues after 2 years then it it shows they probably don’t care enough about security - a very bad signal.
The question was: have they mitigated the security issue you raised, or ignored it?
> Security is taken very seriously here at CircleCI.
Compared with the other security handlings i've seen, this statement sounds genuine.
Well, if you had taken security seriously, the first thing you'd do is ensure 2fa on all accounts.
A convention I like is that team members creating, updating or removing accounts should reply to any automated emails sent to mailing lists saying "this is me". Ideally with a link to the relevant issue or story.
It really cuts down on unnecessary nerves.
The sad part is that they take this for granted and liberate all your data and security weaknesses too to unknown third parties for either a weird ideological reason about interoperability or a small marginal profit.
I don't understand why they can't do both(interoperability and security), their main profit is not data, it's customers paying for infrasctructure. They don't have to share any data at all and are fully capable of providing a competent level of security.
If anything I think if they cut out the profit line from sharing metrics etc with third parties it would actually bring more customers in because of increased confidence in the product.
I would imagine they have some services that are logging JavaScript errors and probably some that are tracking how people use the service.
If you have a Freemium or tiered service especially, you have to understand how people use your service in order to convince them to pay or upgrade.
Thats why they need Facebook's tracking inside the admin part of the APP (on na paid account)?
But the goal is explosive growth, not profit, hence marketing tools. Ask their VC.
The product is the source of profit, not the data.
I was never asked to work on anything relating to sharing metrics for money, and didn't hear of any such product in my time there. That's not the business model.
In fact, some users the only thing they know is the VCS username, and only then because that user has pushed a commit that has triggered a build: the user data they have for most users is literally worthless to any other party.
I ask this because as a Circle customer, if they are selling my data, I'll be out quick. But I see no indication they're doing anything of the sort.
> we will review our policies for enforcing 2FA on third-party accounts to the extent possible, and continue our transition to single sign-on (SSO) for all of our integrations
I think it is more likely the CircleCI didn't enforce 2FA or SSO[1] with the vendor, and a CircleCI employee reused an already compromised password.
[1] Nearly all SSO identity providers support 2FA, so using SSO is often the easiest way to get 2FA with third-party SaaS providers.
In general what I’m missing is why they share my email and github account with a 3rd party. GDPR should prevent them from doing so (at least for European users) without a legitimate reason, or explicit consent.
Error logs might be a bit different I suppose, if they are used to help resolve specific issues for your users, but even then I suppose one could argue that pseudo-anonymised data would be better than sharing an email address.
I'm no GDPR expert, but that's my understanding of it.
If you as the data controller are allowed (according to GDPR) to do some particular processing of some particular data, then GDPR also allows you to subcontract that processing, and thus provide the data to third parties (data processors).
There are a bunch of restrictions in place (you have to have a specific contract mandating that they only do the thing with the data you're contracting them to do, you're responsible if they violate that, some restrictions on "exporting" data out of EU), and you have to inform the customer to what third party 'data processors' you (as the data controller) are outsourcing these activities - so CircleCI would be required to give an exhaustive list of all the data processors to which they have given your data, but you don't need explicit consent or a very particular reason for that outsourcing.
What is prevented by GDPR is the common (at least in USA) "sharing data with trusted third party partners" where the data is essentially sold to third parties which are free to use that data as they wish for their own business or re-sell it further. That would require a very particular reason or explicit consent, but this is not the common scenario of outsourcing to a GDPR-compliant vendor.
So if the email is required in order to, say, send me notifications about CircleCI jobs that are running. That's a legitimate reason. If they share my email with the 3rd party to, for example, optimize their onboarding flows, then this isn't legitimate, unless I explicitly gave my consent to it.
To me, "analytics vendor" as they stated it, usually implies something similar to the latter rather than the former. But since they didn't indicate the provider, nor the reason, I can't really say.
I think we're not in any disagreement here by the way.
https://circleci.com/blog/modernizing-federal-devops-circlec...
I might suspect bc of their wording, segment and not google analytics would be such said 3rd party, and it seems it was one of the team's accounts in such service which got compromised and created a new destination, and no one noticed until 2 months later..
This is just pure speculation, but I would like to know!
"We're introducing this new, 2.0, version. It has some benefits, but is also missing a lot of features and bug ridden. It's easier for us though, so you're going to have to waste a couple days converting from 1.0 to 2.0."
We have a lot of problems with waiting for builds to start - it seems CircleCI don’t have even remotely enough capacity at peak times. We regularly get 10min plus delays to builds starting, sometimes it’s over 30 mins!
Mix that with this security issue... it’s not a rosy outlook for us.
Edit: oh, and the UI has terrible problems with caching and not updating state. Constantly have to hard refresh pages without cache for build status to update.
* cloudfront
* githubusercontent
* launchdarkly
* zendesk
* zopim
* gravatar
* optimizely
* pusher
* pusherapp
* segment
* statuspage
* wp
* zdassets (3 domains)
I use uMatrix to cut half of this crap, cause the page is too heavy to load on my laptop. Started looking for alternatives.
Repository details are another interesting point though. They too are published openly in any git clones but I accept that some people’s repositories, including any local clones, would be private and kept secured from prying eyes. That said, what matters more there is access credentials, encryption at rest (for local clones), etc. So keeping the branch names and repository URIs secret feels a little redundant compared to the actual security benefit it brings. One might even say it’s security through obscurity, though I don’t personally think it offers up even enough benefit to fall under that category. That said, I’m happy to be convinced otherwise if you feel I’ve overlooked some important detail.
" Due to our carelessness and relatively insecure practices, we had improperly disclosed user accounts to a moderately savvy hacker. We realize this is our fault.
If you'd like to help and given that we have your attention now, it would be valuable if you can help pentest our servers: the attacker used a simple SQL attack based on an unpatched server via CVE-3245. Are we missing anything else? Please let us know.
Thank you."