Security Incident Response

[mikhail-tokarev]

On December 5th, we received a message from an independent security researcher telling us that one of our storages is misconfigured and allows unauthorized access to list all objects in the storage, including private user data.

As soon as we confirmed this vulnerability, we immediately removed unauthorized access to this information and also started implementing various measures to protect the data.

We are incredibly sorry that this happened. Security is a paramount goal to the entire team at Codemagic, and as soon as we became aware of the issue, we took immediate steps to protect your data.

We will continue to work with you to provide as much detail as possible about the incident, our response, and the actions we will be taking as a result.

Incident details

On Monday, December 5th, we learned that due to the misconfiguration of one of our Google Cloud buckets, the following data was potentially available to everybody via the Internet:

• Users’ built binaries including IPA, APK and AAB if your build is configured to upload and store build artifacts on Codemagic storage.
• Users’ cache data. UPDATE 12/10/22: Only for Linux and Windows builds.
• Build logs.
• Internal logs for the last 30 days.
• Write-only credentials used internally to upload data to the storage.
• User avatars, application icons and public media files.

The storage in question is designed to store data using random and secure names which makes it impossible for anyone to connect the data to a specific user. Only authorized users can access the direct links to download the files. However, the bucket’s configuration allowed unauthorized users to list all objects in the storage, potentially leading to unauthorized access to approximately 140TB and 31 million files.

Our response

On the same day, December 5th, we modified the bucket’s permissions and removed access to list objects in the storage. As a precaution, we began cycling internal security credentials uploaded to the same storage.

We have confirmed that the storage didn’t contain any other sensitive information, such as user credentials or passwords, and the incident didn’t affect other internal storages. Additionally, we want to remind you that we don’t store any source code on our servers and this information cannot be compromised.

On Tuesday, December 6th, we completed transferring more than 24 million user and internal log files from the compromised storage to a new secured one. Our goal was to protect our users from potential leakage of sensitive information that logs might contain.

On Wednesday, December 7th, we began to implement additional security measures to completely remove access to the rest of the files in the compromised storage. We additionally began notifying our users of what had happened.

—
We take security seriously. We appreciate your trust and have done everything possible to protect your data. Along with the entire Codemagic team, I am sorry that this incident has occurred. We will continue to work hard to keep your data and systems secure. Please feel free to contact us for specific information about your data, or any more detail about how you can protect yourself from this incident.

Mikhail Tokarev
CTO at codemagic.io

[nevotheless]

No offense, but wrong bucket permissions is the most preventable issue someone can have. I'm very disappointed reading this, but kudos for open communication and your response to this.

[the-ginger-geek]

I didn't see them listed but just want to make sure, was environment data affected?

[mikhail-tokarev]

I can confirm that NO secret environment variables, including any passwords, private keys, code signing credentials or provisioning profiles were stored on compromised storage.

However, if you believe that this information could be echoed in your build logs or you noticed any suspicious activity related your accounts we highly recommend you to update all secrets and passwords.

Thanks for the question and sorry again for the troubles.

[the-ginger-geek]

Great thanks

[alabrecq]

Could you please elaborate on what kinds of things are in "users' cache data" and "public media files"? I'm not sure I fully have a handle on that. Thank you in advance.

[mikhail-tokarev]

• users' cache data means all files you configured to store as described here. You can delete all cached data in app settings > Caching tab
• public media files just images and files used in the app and landing pages. It's really nothing to be worried about.

[alabrecq]

Great, thanks!

[mikhail-tokarev]

fyi we have updated original post with new information regarding cache data

[UrK]

I see that my build archives are still available for download with unauthenticated link. Is this planned to be fixed?

[helinanever]

Hi @UrK ,

We’re sorry to hear you did not find out about the incident when it was first discovered. We used multiple public channels to communicate this, such as Codemagic Slack, GitHub Discussions and our Twitter Status page, as well as email to notify customers with whom we have signed respective agreements. However, we’ve noted your feedback and will take care to improve our communication of important news in the future.

What you’re describing as an issue actually works like this by design and is not related to the aforementioned security incident. The direct link to the build artifact can be acquired only through the authenticated session in Codemagic. It is not possible to simply take a wild guess or deduct the URL to come up with a link to download a specific build artifact. You’re correct in that once you share this link outside Codemagic, anyone can access it.

While having publicly accessible links to build artifacts is a standard practice in several other well-known CI/CD services, we can consider restricting access to build artifacts to authenticated users if there is popular demand for that. The downside of this would be complicating the sharing of app artifacts with QA engineers or other stakeholders without giving them access to Codemagic.

I hope this clarifies things for you.

[helinanever]

Hi again @UrK , we've released some improvements to restrict unauthenticated access to build artifacts: https://docs.codemagic.io/notes/release-notes/#artifact-url-expiration

With these changes, the direct links to old build artifacts are no longer accessible for unauthenticated users and new links in email and Slack are valid for 24h.

[josemiguelvarela]

Hi @helinanever ,
In our case we have a script that integrates with Codemagic API and gets the artifact url to download it. Could the API return a download url that expires in 24h as with the email links? What other options are available?

[helinanever]

Hi @josemiguelvarela , you can use the Codemagic API to create public download URLs with a custom expiration time: https://docs.codemagic.io/rest-api/artifacts/

[josemiguelvarela]

Thank you @helinanever