CISA, Australia warn of IDOR vulnerabilities after major breaches

Cybersecurity agencies in the U.S. and Australia warned Thursday of a specific brand of vulnerabilities that allow hackers to change or delete data by using the identities of users allowed to access the information.

Known as insecure direct object reference (IDOR) vulnerabilities, the bugs involve hackers issuing requests to websites or web application programming interfaces (API) that do not require authentication.

In an advisory released this week, the U.S. Cybersecurity and Infrastructure Security Agency, National Security Agency and Australian Cyber Security Centre (ACSC) warned that the vulnerabilities “are frequently exploited by malicious actors in data breach incidents because they are common, hard to prevent outside the development process, and can be abused at scale.”

“IDOR vulnerabilities have resulted in the compromise of personal, financial, and health information of millions of users and consumers,” the agencies said, noting that hackers have used the bugs to “access sensitive data, modify or delete objects, or access functions.”

“IDOR vulnerabilities are access control vulnerabilities in web applications (and mobile phone applications [apps] using affected web API) that occur when the application or API uses an identifier (e.g., ID number, name, or key) to directly access an object (e.g., a database record) but does not properly check the authentication or authorization of the user submitting the request.”

In just the last few years, multiple security incidents have involved IDOR vulnerabilities, including a situation affecting a payment plugin for WordPress sites, U.S. electronics giant Eaton, Microsoft Teams, AT&T and First American Financial.

The cybersecurity agencies included advice for vendors, designers, and developers of web applications and organizations using web applications.

They urged developers to take a range of preventive actions like using secure-by-design and -default principles as well as automated tools that can review code for IDOR vulnerabilities. End users also need to be wary of vulnerable applications and vendors selling tools that have not been verified.

IDOR vulnerabilities are typically classified by the level of access they provide hackers and come in a variety of forms. One of the most common is called “body manipulation” – where threat actors change the HTML code of a website to give themselves access. Similar versions involve the manipulation of URLs or cookies.

BugCrowd CTO Casey Ellis said that as an example, if a website is vulnerable to IDOR, simply changing or incrementing a numeric value in the URL of a logged-in user number will provide access to a different user’s information.

“These vulnerabilities are common and hard to prevent outside the development process since each use case is unique and cannot be mitigated with a simple library or security function,” the agencies explained.

“Additionally, malicious actors can detect and exploit them at scale using automated tools. These factors place end-user organizations at risk of data leaks (where information is unintentionally exposed) or large-scale data breaches (where a malicious actor obtains exposed sensitive information).”

Ellis noted that the timing of the advisory was curious but was likely prompted by the breach of Optus, Australia’s second-largest telecommunications company, where the details of a large percentage of the Australian population were stolen “because of a combination of poor API security and the presence of IDOR.”

Others said much of the advice in the advisory were things developers should have already been doing.

“While there are legitimate use cases where [insecure direct object references] are perfectly valid and don't add unacceptable security risks, the fact that they are insecure by default means their use should be limited,” said Mike Parkin, senior technical engineer at Vulcan Cyber.

“Security best practices would have developers use IDOR sparingly and never in a case where a user could compromise the system just by manipulating the calls. Everything in this joint recommendation are things the developers should already be doing. It's basic secure coding practice, not rocket science.”