Some Recent API Security Related Gaffes, And How They Might Have Been Avoided

September 13, 2021

This is the second of three guest blogs as part of our collaboration with Cequence. In the first blog on August 30, I wrote about how we’ve seen the level of API security knowledge increase since our initial research in 2019 but more must be done to secure the use of APIs in today’s hyperconnected world. In that first blog, I noted that CISOs (particularly in financial services organizations) and software developers have stepped up their API security game and I’ve seen a general increase in API security maturity. Nonetheless, reported API security vulnerabilities and API-related security breaches continue to pop up every month. Hence, more must be done.

In the last 60 days, we’ve seen API vulnerabilities reported for Cisco’s networking equipment, Bumble’s dating application, Microsoft’s PowerApps Platform, and Valve Software’s Steam Portal. In the case of Microsoft’s PowerApps Platform, cybersecurity firm UpGuard linked the API vulnerability to the disclosure of as many as 38 million records containing personally identifying information (PII). Security researchers reporting these vulnerabilities made the following cause attributions:

  1. Cisco – Improper access control in an API that could lead to an attacker being able to read or write to files – and ostensibly tampering with device firmware. Impacted products included Cisco Application Policy Infrastructure Controller (APIC) and Cisco Cloud Application Policy Infrastructure Controller (Cloud APIC). Details can be found in CVE-2021-1577. This stemmed from broken authentication, #2 on the OWASP API Security Top 10 list.
  2. Bumble – A security researcher received a $2,000 bug bounty for reporting a location-based vulnerability stemming from a poorly designed API endpoint. The vulnerability could be exploited by an attacker to spoof their location and determine the precise location of a Bumble user without authorization. A separate API vulnerability would allow an attacker to access a user’s profile information without being in their feed. This resulted from broken object level authorization, #1 on the OWASP API Security Top 10 list.
  3. Microsoft – An open data protocol API used by PowerApps had a default setting that turned off table permissions and this made data publicly accessible. The primary cause was attributed to broken authentication, #2 on the OWASP API Security Top 10 list.
  4. Valve Software – A vulnerability in the Steam Wallet API created the situation where a user could add value to their account by modifying user input. The input schema was protected by a hash function, but the implementation was flawed. The vulnerability was attributed to poor enforcement of payload schemas and netted a $7,500 bug bounty from Valve.

Fine, let’s just stipulate that despite improvements in API security maturity, the creation and implementation of APIs are complex and are still a challenge for many organizations and development teams. Additionally, security teams often lack the tools to test APIs to look for these vulnerabilities. But in the case of the first three examples, the OWASP API Top 10 has detailed descriptions and recommendations to help developers avoid these authorization and authentication issues. The Valve Software vulnerability is a bit more complex but could have been avoided via secure coding practices.

To be clear, simple awareness and cursory testing are not sufficient to avoid these security gaffes. API security maturity encompasses many other factors including designating an API security point of contact, maintaining an inventory of internal and external APIs, and publishing an API catalog or API development portal to assist internal developers or external implementers with API implementation.

More specifically, creating an API specification for each API using a standard such as OpenAPI or API Blueprint will define how the API functions and its relationship to data sources and other APIs. Through the development of the spec, it’s possible to uncover potential authentication and authorization shortfalls. Spec development can also lead to a threat modeling exercise with security professionals to determine “…so, what’s the worst that can happen?”

Now is the time to embark or double down on your API security improvement program. I’ll be covering additional aspects and recommendations in the upcoming third blog and a joint webinar with Cequence “Shielding Right to Strengthen Shift Left: Here’s How” on October 6th.

­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­Joseph has been a cybersecurity analyst since 2019. He’s worked in information security for more than 45 years. His previous roles include operations officer for the U.S. intelligence community, a CISO at large publicly traded companies, and a cybersecurity strategy consultant for Accenture and PwC. He has worked in 115 countries, and he’s keenly interested in disruptive and emerging cybersecurity technologies.

Tags

API AttackAPI SecurityAPI standardsAPI vulnerability

About the Author

Joseph Krull

CISSP, IAM, CISA, CRISC, CIPP, Senior Cybersecurity Analyst at Aite-Novarica Group

22 September 2021

Multi-Tenant SaaS Authentication Bypass or Works-as-Designed?

Read More
20 September 2021

Top 5 API Discovery Insights for Security Teams

Read More
15 September 2021

Improving Development and Security Collaboration With API Specification Frameworks

Read More
2 September 2021

Tales from the Frontlines: API Sentinel Drives Security Collaboration

Read More
30 August 2021

Guest Blog: API Security – Off to a Booming Start, But We’re Not Done Yet

Read More

Subscribe to our blog