This week, we have news of an API vulnerability in the Travis CI platform that allowed to access logs on public instances, leading to leaking keys and tokens. Also this week, we have an excellent guide from Microsoft on their recommendations how to mitigate against API threats, some views from the Economic Times on why API security needs special attention, and updates on the OWASP crAPI project.
Vulnerability: Credential leak in Travis CI log API
Team Nautilus at Aquasec has found an ongoing vulnerability affecting public instances of the Travis CI platform. The vulnerability exposes tens of thousands of user tokens (typically for GitHub, AWS, and DockerHub) in historical Travis CI logs that are accessible through an API. Similar issues have been reported in 2015 and 2019, and in this newsletter we featured news of token leaks on Travis CI late last year.
Travis CI is a popular CI/CD platform that acts as a build orchestrator for software artifacts. As such, the platform requires access to various 3rd party platforms such, like source code repositories, container registries, and cloud platforms. Typically, the access credentials to these resources are stored as secrets in the CI/CD platform, only for internal use, and thus not accessible to the casual observer.
However, the researchers discovered that they could access historical logs of build jobs through a publicly accessible API. Using scripts to paginate through the log files, they determined that approximately 770 million logs were exposed. By examining the contents, they were able to identify secret values associated with various platforms:
The researchers did reveal that Travis CI did provide some mitigation against mass leakage: the API endpoint was rate limited, in many cases the secret values were masked in the log files, and they also recommend various techniques for masking secrets and deleting old log files.
Nonetheless, the sheer volume of logs available through the API endpoint pagination meant that tens of thousands of secrets may be accessible, representing a significant risk to assets on impacted 3rd party platforms. The researchers quoted Travis CI’s response that the issue is “by design” โ Travis CI has also previously be found wanting in their response to a similar leak. Users are urged to be cautious with credentials stored on Travis CI, including deleting log files, revoking and reissuing credentials, and narrowing down the roles in credentials to the bare minimum required to lessen the impact.
There are several important lessons to be learned here:
- Do not rely on security by obscurity โ in this case, the platform stored old log files under an undisclosed endpoint but this could easily be reverse-engineered.
- Rate limiting is important, but it is only one element of an API defense strategy.
- Always have a plan for revoking and reissuing credentials, both in an emergency and as part of security routine.
Article: Microsoft’s recommendations for mitigating against API threats
Microsoft has produced a high-quality set of recommendations for how to mitigate OWASP API security Top 10 threats with API management. Although primarily targeted at users of their Azure API tools (the balance of the recommendations focuses on using Azure platform features for secure configuration and monitoring), the recommendations are well-written and contain many excellent generic recommendations โ I learned a lot here, and recommend bookmarking this as a checklist for hardening your APIs.
For me, some of the standout recommendations include:
- For API1:2019 โ Broken object level authorization, the correct place for mitigation is through comprehensive authorization in the backend API code. Gateways can only offer limited defense, mainly by obscuring internal object identifiers.
- For API2:2019 โ Broken authentication, leverage the power of the gateway to enforce uniform authentication across all endpoints by using standard methods, such as OAuth2 and JWT tokens.
- For API3:2019 โ Excessive data exposure, again the best way to mitigate against this vulnerability is the judicious design of the data storage objects in the API backend code. Gateways can offer content validation but users should be aware of performance impacts with this method.
- For API4:2019 โ Lack of resources and rate limiting, gateways can offer short-term and long-term rate limiting; use the OpenAPI definition to limit the amount of data that can be accessed by specifying length limits; use Cross-Origin Policy (CORS) but avoid wildcards; and revoke access for users who abuse resources.
- For API5:2019 โ Broken function level authorization, the obvious recommendation is to requiring subscription keys for all endpoints by default and to avoid the use of wildcard endpoints.
- For API6:2019 โ Mass assignment, the recommendations are similar to those for API3: manage the data transfer in the API backend code.
Thanks to Microsoft for the excellent set of recommendations.
Article: Views on why API security needs special attention
The Economic Times featured a thought-provoking read on why API security needs special attention โ as the author astutely states “Web applications security is not API security”.
The most interesting observation for me was the benefits (and challenges) of the design-first approach for API development. On the upside, the use of a design-first approach through OpenAPI definitions allows for the enforcement of a very precise contract between the API and the client โ quite different from web applications where the boundaries are very blurred. This is the essence of the positive security model that uses the OpenAPI definition as the contract and only allows known good and blocks everything else. The author notes the major caveat with this approach: time pressures on developers mean that a design-first approach might not always be feasible so they begin by coding the API, thereby losing the benefits of contract enforcement.
The author highlights additional factors that impact APIs security:
- Lack of visibility into API inventory can inhibit security initiatives.
- Traditional security mechanisms (like rate limiting and network security) are useful but not entirely sufficient at thwarting threats to modern APIs.
- Due to time pressures on developers and testers, business logic flaws may be hard to detect.
Some great insight into the topic โ leverage the power of your OpenAPI definitions.
Article: OWASP crAPI for API hacking and learning
Finally this week,ย a shout out to the OWASP crAPI project in this quick guide on how to use the project as a way to get started in learning the foundations of API security.
The author emphasizes the point of the API developers taking ownership of API security rather than assuming it can be delegated to other parties. The two examples cited are:
- “Internal APIs do not need to be secure as they are not accessed by external users” โ of course, in time internal APIs may become external and as such should be designed securely by default.
- “Access controls can be implemented centrally by the identity team and developers do not need to worry about this at the API level” โ obviously, this is a dangerous assumption, and a defense-in-depth approach should be used instead.
The author recommends that developers adopt a project like crAPI to hone their API security skills, that security teams use it as a means for understanding real-world API attacks, and that API protection teams use it as a test bed for assessing their protection tools.
As the author perfectly concludes:ย โShift left is not just about shifting your tools and process but the knowledge as well.โ
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
