How IDOR caused exposure of Florida’s tax filers’ data?

The Social Security and bank account data of hundreds of taxpayers were disclosed due to a security vulnerability in Florida's Department of Revenue website.

What happened?

Security researcher Kamran Mohsin discovered a security vulnerability on Florida's Department of Revenue's website. The first information about the incident was issued in a report published by TechCrunch on Dec 2nd, 2022. The report said that the vulnerability exposed sensitive data belonging to hundreds of taxpayers, such as bank account numbers and social security cards.

How it happened?

The security researcher who discovered the vulnerability tried to manipulate the parameters in the URL that contains the taxpayers' application number. As these application numbers were sequential, the researcher could enumerate taxpayer information by incrementing the application number by a single digit.

For example: imagine the url is /applications/{application-id}. In this case {application-id} is sequential meaning they could be 200, 201, 202 and so on. The attacker can access the application details of any tax payer by simply incrementing the {application-id}. Attacker is able to access the information because the url doesn’t have a proper authorization mechanism set.

The vulnerability is known as Insecure Object Direct Reference (IDOR), a vulnerability type that allows unauthorized access to the user's sensitive data by manipulating user/object IDs.

By exploiting this vulnerability, the researcher discovered over 713,000 applications in the Department's system. He further claimed that on October 27th, 2022, he alerted the Florida Department of Revenue, and the flaw was fixed within four days. Despite the bug being resolved, he said he had not been contacted by the Department since.

What ‘s the impact?

Anyone who logged in to the state's business tax registration website could access, modify, and delete the personal data of business owners whose information is on file with the state's tax authority.  

The vulnerability allowed the external individual to view registration data submitted by taxpayers, including 417 registrations that contained confidential information. Within a two-day timeframe, the Department attempted to contact each affected business by phone and contacted all affected taxpayers by phone or in writing within four days. The Department has also offered each affected taxpayer one year of complimentary credit monitoring. 

Source: Techcrunch

Lessons learned:

1. ‍Implement robust auth - Identify all private objects and resources in your database. Ensure all those resources are checked for correct authentication and authorization before returning the result. ‍

2. Code review - Ensure authorization is implemented correctly when a new page or API is introduced. In case an API is modified, check if should need authorization.‍

3. Business Logic Security Testing - All authorized pages and APIs must go through a security check before a release. One of the business logic test is IDOR (now categorised as BOLA). It is important to check for all OWASP Top 10 vulns before every release. Manual process is time consuming - an automated solution, such as Akto, is the best resolution here. Deep business cases still have to be tested manually.