Analyzing the Travis CI Attack and Exposure of Developer Secrets

Originally published by Open Raven here.

Written by Michael Ness, Security Researcher, Open Raven.

Introduction

The Continuous Integration (CI) platform Travis CI was recently victim of a research based attack, where researchers from Aqua security were able to obtain approximately 73,000 sensitive tokens from numerous different organizations. CI is becoming an increasingly common practice, which allows teams to push out updates in software to different storage repositories that are often required for deployment or sharing with other teams. Due to the nature of a CI platform's purpose, it is common that they store and utilize various sensitive tokens that are required to carry out the actions that are necessary in the pipeline. These tokens can range from Github tokens, Docker repo access tokens, AWS keys and many more. This makes these CI platforms large targets for attackers as if they can compromise a pipeline they can often compromise multiple organizations and their wider assets. The recent research on Travis CI is the perfect example of this.

The Attack

The Aqua security researchers' attack path to disclosing these tokens is a fairly simple one and is an API based attack. The attack path involved using an indirect-object reference (IDOR) within the Travis CI API. In doing so the researchers were able to view logs of other users, without the required authorization. Through this they enumerated over 700 million log entries that ranged from 2013 through to May 2022. In a small sample of these log entries they were able to identify over 73,000 secret tokens which varied across numerous providers. You can see the distribution of providers below in Figure 1.

Figure 1: Displays the distribution of secret tokens found during the log enumeration of Travis CI. Credits: Aqua Security

Impact

Attackers having access to these tokens can have varying degrees of impact, let's consider a few examples. Access to a GitHub token, means they can access code repositories that the token grants access to and from there they can take the code, or even worse modify it to fit their own needs. Access to AWS tokens will allow users an entrypoint to an organization's cloud infrastructure, the impact here is they can enumerate and access assets, whether this be S3 buckets, databases or other resources that the token grants access to. DockerHub has a similar impact to Github, where they can clone private images and even modify these and re-upload as the latest image. A perfect example of this is through the CodeCov breach (https://about.codecov.io/security-update/) where an image was maliciously modified and re-uploaded, which meant it was then used by the end users. Despite being all different platforms and different resources you can see a recurring theme that comes with these tokens being leaked and that is they can access, enumerate and modify resources they otherwise should not have had access to.

Limiting the Damage

These attacks are often unavoidable as these tokens have to be provided to achieve the functionality required and this puts the security within the responsibility of the platform to ensure your secrets are kept safe. If these secrets ever become publicly exposed through any means, then there are steps to prevent your blast radius and these are:

• Ensure the tokens have the least access model in place, i.e. the tokens only grant access to the resources required for the actions within the pipeline.
• Regularly rotate these tokens, which means if they are compromised they can be easily rotated or by the time they are, they may even be expired.
• In the case of the Travis CI leak, avoid printing out your tokens - which will avoid them being readable in the CI log files.

Taking these steps when granting tokens and setting up pipelines will ensure if your organization is ever victim to data exposure through a pipeline, then your blast radius is limited.

Conclusion

Data Security is highly important to organizations and there are multiple attack vectors for attackers to breach data, some even outside control of the organization itself. This case has been shown here, where the breach of a pipeline can leak sensitive tokens, which in turn grants access to sensitive data from the organization - all outside control of the organization. In such cases it is important you have taken the appropriate steps to limit your blast radius and in turn the amount/nature of sensitive data the attackers can have access to. There are a few steps noted above that can help you ensure you have these in place, in case such an attack happens to you.