Unpacking an IDOR-Based Exploit in International Shipping (70 Million+ PII Data Breach)

Introduction

Hi, my name is Suyesh Prabhugaonkar and I’m a Security Engineer passionate about network security and client/server architecture. Recently, I came across my second Insecure Direct Object Reference (IDOR) vulnerability within a month — this time in the infrastructure of a billion-dollar international shipping conglomerate. The exploit I found underscores how critical security is, especially as businesses scale and handle sensitive user data.

What is an IDOR Vulnerability?

An Insecure Direct Object Reference (IDOR) vulnerability is a type of access control flaw that occurs when an application provides direct access to objects — such as files, database entries, or API endpoints — without proper authorization checks.

In simpler terms, think of a webpage or API call that uses unique identifiers, like a URL parameter or a serialized number, to fetch data. If these identifiers aren’t adequately protected, a malicious actor could manipulate them to access data they shouldn’t see. For example, changing https://example.com/tracking/12345 to https://example.com/tracking/12346 might allow a hacker to view another user’s data.

IDOR is dangerous because it often goes unnoticed, leaving sensitive information like personal details, shipment logs, or even financial data exposed to anyone with basic scripting skills.

The Exploit: Step by Step

The vulnerability I discovered consisted of three interconnected flaws:

1. Shipment Tracking Endpoint with Brute-Force Potential

The company offered a shipment tracking feature at https://example.com/tracking/{awb} where {awb} represented an Air Waybill number. These numbers followed a predictable format:

• The first 3 digits were a prefix for the airline.
• The next 7 digits were a serial number unique to the shipment.
• The final digit was a check digit, calculated as the remainder when the serial number was divided by 7.

This design made the endpoint vulnerable to brute-forcing. A malicious actor could easily write a script to iterate through all possible combinations, identifying valid AWB numbers and uncovering tracking information for shipments. No authentication was required to access this data.

2. MD5 Hash in the HTML

Within the shipment tracking page’s HTML, there was an MD5 hash of the customer’s phone number. MD5 is an outdated and insecure hashing algorithm, susceptible to brute-force attacks or lookup in precomputed “rainbow tables.” If someone reverse-engineered the hash, they could obtain the customer’s phone number.

3. API Endpoint Exposing Full Customer PII

On a separate subdomain (https://subdomain.example.com/api_version/user/info?uid={uid}), the company had an API endpoint where the MD5 hash of the phone number could be entered as the {uid} parameter. This returned a JSON file containing the following personally identifiable information (PII):

• Mobile number
• Address (line 1 & 2)
• City, state, and country
• Email address
• First and last name
• Postal code (pincode)

Insecure Publicly Accessible API Endpoint with Exposed PII

Since the MD5 hashes could be brute-forced, an attacker could systematically query this API and harvest sensitive data. With over 70 million customers, including users from Europe, the potential for misuse was staggering.

Why This is Important

Data Privacy and GDPR

The exposed information not only jeopardizes customer privacy but also places the company in violation of the General Data Protection Regulation (GDPR). GDPR requires companies that handle EU citizens’ data to implement robust measures to protect their information. A breach of this scale could lead to hefty fines — up to €20 million or 4% of annual global revenue, whichever is higher. Beyond financial penalties, the company’s reputation could suffer irreparable damage.

Impact on Customers

For customers, this kind of exploit could result in identity theft, phishing attacks, and scams. Malicious actors could impersonate the company, contact users with personalized details, and manipulate them into disclosing further sensitive information.

How Vulnerabilities Like This Go Undetected

Such vulnerabilities often stem from systemic issues in how software is developed and maintained:

1. Legacy Code: This shipping company likely started with a small development team that built the original codebase. Over time, as the company scaled, much of the code remained unchanged, even as newer, more secure standards emerged.
2. Staff Turnover: As new teams replaced the original developers, institutional knowledge was lost. Documentation gaps further compounded the problem, leaving security flaws unnoticed.
3. Cybersecurity as an Afterthought: Many companies don’t prioritize security until after they face a breach. This company’s cybersecurity team likely consisted of developers tasked with patching issues rather than proactively securing the system.
4. Cost vs. Security: Implementing robust security measures, like tokenized tracking or cryptographically secure hashing algorithms, might have been deprioritized due to cost or time constraints.

Building a Secure System from the Start

Preventing vulnerabilities like this requires a security-first approach:

Adopt Secure Development Practices:

• Use secure hashing algorithms like SHA-256 instead of MD5.
• Implement authentication and authorization checks for all sensitive endpoints.
• Follow the principle of least privilege: users should only access data they need.

Regular Security Audits:

• Conduct frequent penetration testing.
• Use automated tools to identify common vulnerabilities like IDOR.

Educate Developers:

• Train development teams on secure coding practices.
• Encourage collaboration between security teams and developers during the software development lifecycle.

Invest in Cybersecurity:

• Allocate resources to hire dedicated security professionals.
• Establish a bug bounty program to reward ethical hackers for discovering vulnerabilities.

Data Minimization:

• Avoid exposing sensitive customer information unnecessarily.
• Use one-time tokens or other secure methods to fetch user data.

Conclusion

The IDOR vulnerability I discovered is a stark reminder of the risks associated with insecure software design. As companies grow, they must prioritize security at every stage of development. With data breaches becoming increasingly common, the cost of neglecting security far outweighs the investment required to build a secure system.

For this shipping conglomerate, the lesson is clear: robust security is not optional. It is a necessity — both for protecting customer trust and for complying with global data protection standards like GDPR.