This week, we review three different cases of API authorization and privilege escalation vulnerabilities, each of which is a wake-up call for API teams. We examine NIST updates on password security guidelines and share findings from an industry survey on API security and an upcoming OWASP API Top 10 webinar.
Also this week we celebrate APISecurity.io’s 6th anniversary! Since publishing Issue #1 on October 11, 2018, the newsletter has become a trusted resource for staying up-to-date on the latest threats, best practices, innovations, and solutions in the API security space. Thank you to all subscribers for your continued feedback and support as we work to provide timely and valuable content to drive the conversation around API security.
Industry News: NIST updates the rules for password security
In the latest revision of Special Publication 800-63 Digital Identity Guidelines, the U.S. National Institute of Standards and Technology (NIST) updated the rules for password security, including changing the guidelines for password complexity and composition from recommendations (should, should not) to requirements (shall, shall not).
Forcing users to create complex passwords that include letters, numbers, and special characters can be counterproductive when it doesn’t result in strong and unpredictable passwords (the infamous “Password1!”). This was acknowledged in the original NIST publication in 2017, but the latest update now establishes clear requirements that password verifiers must not impose these composition rules on users.
You can read the rationale behind the changes to password strength in the Appendix. One point from the summary I think is worth noting for development teams:
“Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.”
So while the burden of complexity is being lifted off the end user (a good thing), these changes put an additional responsibility on development teams to ensure robust protections against brute force attacks on the functions and APIs that perform password verification.
Vulnerability: Kia vehicle’s insecure partner API hacked
A report by researcher Sam Curry describes how a team of ethical hackers discovered vulnerabilities in Kia’s APIs that allowed them to take over user accounts and remotely control vehicles. In issue 253 we referenced an industry white paper from VicOne on this very topic.
The main weakness was a dealer registration endpoint without any identification or verification checks, so any online user could register as a Kia dealer. A dealer has an elevated role, or partnership, with the vehicle manufacturer, and so is granted privileged access to systems and API services.
So once registered as a fake Kia dealer, the research team was able to use Kia’s dealer APIs to query vehicle owner’s personal information, add an attacker as the primary owner of the vehicle, and ultimately execute remote commands to control the vehicle. A video demonstration is included in the report.
Partner APIs typically provide privileged access to services and data and so need additional layers of security, and testing, around the registration process. Imagine how much harder it would be to hack this system if dealer registration was limited to a whitelist of approved email domains?
Or better yet, use mutual TLS so that dealer registration is only possible from a particular office or terminal. Don’t make it easy for hackers. If they want unauthorized access to partner APIs, force them to break glass and climb through some windows!
The report also highlights that obfuscation offers little protection. Just because your APIs and endpoints are hidden and undocumented doesn’t mean hackers won’t find them. The process by which this team discovered the dealer registration endpoint is a valuable lesson for API teams to heed.
Great writeup by Sam Curry. Essential reading for API teams.
Vulnerability: Broken Authorization in Cisco Nexus Platform APIs
Continuing on the topic of privileged access and vulnerable APIs, a Cisco security advisory highlights several REST API vulnerabilities that allow a low-privileged user to access administrator-level services on the Cisco Nexus Dashboard.
Cisco Nexus Dashboard is a centralized management platform for provisioning, managing, and operating data center networks. According to the advisory, the vulnerabilities involve missing or insufficient authorization checks on the REST API, which could allow an attacker to upload malicious files and read or delete sensitive data.
Incidents of attackers gaining privileged access to API services are often exploits of broken function level authorization (BFLA). According to OWASP, BFLA vulnerabilities are common and easy to exploit and can lead to data disclosure and service disruption.
The guidelines to prevent BFLA suggest adopting a zero-trust approach where access is denied by default, and requiring specific roles or permissions before access is granted. BFLA specific tests can also be run as part of automated continuous testing, to check if non-authorized users can gain access to privileged APIs.
Vulnerability: Privilege escalation flaw in e-filing platform API
A recent article in SecurityWeek describes how cybersecurity researcher Jason Parker claims to have discovered critical vulnerabilities in a number of public platforms used in the United States’ justice systems.
In one report, the researcher describes an API vulnerability discovered in the Granicus e-filing platform that allows a regular user to elevate their access levels. The e-filing system is used to submit legal documents to state courts.
According to the researcher’s disclosure document, the vulnerability is exploited by sending an API request to the platform with a special “TypeCode” property in the payload. If the TypeCode matched a value for a privileged account on the system, like a court or administrator account, the user’s access level was escalated.
This has the typical characteristics of an API mass assignment vulnerability, or a Broken Object Property Level Authorization (BOPLA) vulnerability in the OWASP API Security Top 10 list.
BOPLA exploits can cause a range of different adverse effects, from crashing a server to escalating a user’s role and access permissions.
An API should be securely designed to constrain the properties it accepts to only those that are expected. Additional properties should be rejected by default, to avoid unexpected behavior in the API.
Industry Report: 30% of public APIs are completely unprotected
F5 recently published a supplemental report titled “The Secret Life of APIs” summarizing the views of API decision makers, primarily C-level, on their current API security posture.
From what I’ve read, the results range from suspiciously optimistic to shockingly pessimistic.
On the optimistic side:
- 80% of organizations claim to begin API security in the API design phase
- 59% say they incorporate security at every stage of the API lifecycle
Security-by-design is the recommended approach to API security. However the devil is in the details, and some of the other statistics that emerge from the report suggest that teams are struggling to get some of the basics right:
- More than 30% of public APIs use the unsecure HTTP protocol
- Two-thirds of organizations leave their operational workflow APIs unsecured
The report also highlights how AI solutions are enabled by API-based integrations, so AI solutions will continue to be vulnerable until APIs are secured.
The take-away message from the report is that organizations must adopt a zero trust model for API security, to be implemented throughout the API lifecycle from development to operational phases. This is a recurring conclusion in industry reports for achieving effective API security.
Webinar: Mitigate OWASP API risks through security-by-design
The OWASP Top 10 API Security Risk list provides a clear roadmap of the most common and dangerous vulnerabilities that can compromise your APIs. In this webinar, you will learn how to incorporate the OWASP guidelines into your security initiatives for software development to help build secure, resilient APIs by design. This session will offer practical insights to enhance the security of your applications.
Key takeaways include?
- Why adopt security by design?
- How to leverage OWASP guidelines for API development
- How to get developers invested in the security of their APIs
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
