Lessons Learned – USPS API Vulnerability and 60 Million Exposed Users

Photo by Ethan Hoover

By now you’ve probably seen the news about the USPS vulnerability where an attacker with simple access to usps.com, an understanding of the API logic and no special tools beyond a common web browser could easily manipulate that logic to get a dump of data. This dump could include account details like usernames/IDs, email addresses, account numbers, street addresses, phone numbers and a slew of other sensitive PII. It was a flaw in the API logic of the Informed Visibility USPS service that potentially exposed this data for over 60 million customers. Exploitation of the flaw in this case is not far fetched but luckily didn’t happen as far as we know.

This is another example of the research community working hard to call attention to the increasingly potential risk in insecure APIs and the need for focus on API protection. A year after the original disclosure to USPS it wasn’t until Brian Krebs called it to their attention that USPS ultimately addressed the issue. You can read more details about the vulnerability in Kreb’s article – USPS Site Exposed Data on 60 Million Users.

While APIs have become an easy way for developers to build, extend and connect applications they’ve  also become an increasing target for attackers. These types of API logic based vulnerabilities have become far too common in recent years. Many of the high profile breaches like those at T-Mobile, Facebook and Verizon have had a component of API as part of the attack path. Some, like the breach at Panera Bread had the vulnerability disclosed but left unaddressed until it was too late. It’s time to take API protection seriously.

What have we learned? API vulnerabilities are a real threat to organizations especially when customer information or other valuable data is at stake. Disclosures like these need to be taken seriously and should not be ignored for so long after disclosure. Reliance on traditional security approaches won’t keep up with this trend of API logic based attacks since these solutions have no insights into the unique logic of the APIs where attackers focus. A proactive approach to API protection must include granular knowledge of your unique APIs and an understanding of normal API behaviour in order to detect potential vulnerabilities and prevent successful attacks.

Want to learn more about Salt and our approach to API protection? We have more resources to get you up to speed at the Salt website.

Share this post