Industry Reactions to USPS Exposing User Data
Security blogger Brian Krebs revealed recently that an API used by the United States Postal Service (USPS) had a vulnerability that potentially exposed the data of 60 million customers.
Krebs learned of the security hole from an unnamed researcher who had reported the issue to USPS over a year ago. The flaw was only patched after the organization was contacted by the blogger.
The vulnerability was related to the Informed Visibility tracking service. The flaw could have been exploited to obtain near real-time data about packages and mail, and it allowed logged-in users to access information on others, including email addresses, usernames, physical addresses, phone numbers, and account number.
Industry professionals have commented on the story, particularly on the risks associated with the use of insecure APIs.
And the feedback begins…
Mark Risher, Head of Account Security, Google:
“We’ve increasingly seen this type of leaked information — email addresses, street addresses, and phone numbers — used to add credibility in targeted “spear-phishing” messages. Identifying these messages can be quite tricky, so users are encouraged to use a mail client and web browser with robust anti-phishing warnings; the default app on your phone or laptop may not offer these protections. Users with Google Accounts should also consider taking a Security Checkup to ensure their apps and devices are in the best-protected state.”
Torsten George, senior director of product marketing, Centrify:
“The U.S. Postal Service’s API vulnerability — which exposed data on 60 million users — is a stark reminder that nowadays access requesters are no longer solely humans but also machines, services, and Application Programming Interfaces (APIs). In fact, cyber adversaries are already targeting APIs when planning their attacks. Earlier this year, Panera Bread left an unauthenticated API endpoint exposed on its website, allowing anyone to view customer information such as username, email address, phone number, last four digits of the credit card, birthdate, etc. Ultimately, data belonging to more than 37 million customers was leaked over an eight-month period.
Both the U.S. Postal Services and Panera Bread vulnerabilities are a perfect example why organizations need to adjust their enterprise security model to account for an ever-expanding attack surface that should not only cover infrastructure, databases and network devices but extend to include cloud and DevOps environments, big data projects, and hundreds of containers or microservices to represent what used to be a single server.
Unfortunately, DevOps security – or DevSecOps as it is now called – is often underrepresented in the software development process, including securing public-facing APIs. However, developers need to consider the security implications of API usage within the overall development process, including ways in which APIs can be used for nefarious purposes. Forrester estimates that 80% of breaches involve privilege misuse and a good example is when applications don’t bother enforcing role-based access controls. That is what was uncovered in the U.S. Postal Service and Panera Bread vulnerabilities, were administrative commands did not check to verify the user’s role before execution, effectively allowing ANY user to perform administrative actions.
In a world where developers are moving fast and DevOps pushes code quickly to production, it is vital that security checks get built into this automation flow and real DevSecOps processes get put in place to avoid such potentially costly mistakes. A fundamental component in securing APIs lies in implementing solid authentication and authorization principles. For APIs, developers commonly use access tokens that are either obtained through an external process (e.g., when signing up for the API) or through a separate mechanism (e.g., OAuth). The token is passed with each request to an API and is validated by the API before processing the request. The idea is that for those accounts that have access to sensitive data, they should only be given the ‘least amount of privilege’ and only for just the period when it is needed, then removed. Embracing these DevSecOps recommendations can minimize the security risks associated with API exposure and keep applications safe from cyber security breaches.”
Richard Blech, CEO, Secure Channels Inc:
“Perhaps the most interesting thing about the Postal Service breach is that it wasn’t a breach. There was a public Application Programming Interface (API) that was ostensibly designed to help legitimate users track the status of mail and packages in real-time. Among the other as-implemented features of the API was that it could be fed “wildcard” search parameters. As a consequence, any non-privileged user logged in to usps.com could search for account details belonging to any other user. Those details included email addresses, usernames, account IDs, account numbers, addresses, phone numbers, authorized users and mailing campaign data. For as many as 60 million USPS customers.
As I mentioned, this wasn’t a breach. This was a software component operating exactly as implemented, if not as intended. What the Postal Service data exposure highlights are the criticality of up-front engineering, assiduous quality assurance practices, security-conscious development methodologies, feedback, continuous learning, and continuous process improvement. It’s not enough to build something that works. As part of the build process, organizations that produce software must assume that their products will be abused. Secure product development means structuring development paradigms so that verification activities are pushed as far to the left as possible, and that both internal and external testers think maliciously, continually attacking and abusing their own products before release to identify and close as many vulnerability gaps as possible before deployment.”
Bernard Harguindeguy, CTO, Ping Identity:
“This latest headline involving an API vulnerability serves as a wake-up call to organizations everywhere to step up their API security. API infrastructures need special attention to defend against abuses and attacks such as the vulnerability impacting USPS. A recent survey found that 25% of companies have over 1,000 APIs and 45% of security and IT professionals aren’t confident in their organization’s ability to detect whether a bad actor is accessing their APIs. This illustrates one of the greatest obstacles to effective API security today — the people trusted with securing APIs don’t always have enough visibility into who is accessing what account to track whether illegitimate access is occurring.
Effective API security starts with deep visibility into all API traffic, followed by strong authentication and data governance. Companies’ crown jewels — their customers’ data — are increasingly being made accessible via APIs, and protecting this infrastructure from vulnerabilities and cyberattacks has to be the top priority for CISOs and CIOs everywhere.”
Doug Dooley, COO, Data Theorem:
“Businesses must enable automated mechanisms to share data in a scalable manner in order to deliver better services and remain relevant in the modern era. The US Postal Service, like most organizations, is enabling new API services daily. These APIs can help deliver better real-time data access to improve customer experiences. However, in this specific case, it appears data from 60 million USPS customers could have been shared with an unauthorized set of users. It appears the API operations did not match their API design specification at least for some period of time.
Organizations cannot count on only good code hygiene, developer security training, and legacy security best-practices. Customers need more effective tools for this explosive growth in APIs. Security protection tools that help organizations discover API changes and ensure that their API operations match their intended specifications are something the industry needs now. These tools did not exist a few years ago but API exploits like this one illustrate their growing importance and need. Organizations that care about their data and privacy need to re-evaluate their API security approach.”
Mukul Kumar, Chief Information Security Officer and VP of Cyber Practice, Cavirin:
“This brings up two issues beyond what has been reported. The first is the need for a national consumer privacy act that includes fines for delayed notifications. Both the GDPR and California’s CCPA are good moves in this direction, but any national act can’t be watered down by those who monetize user data. The second is that consumers and businesses must be very diligent with regards to their cyber posture. This includes non-reuse of passwords across sites. We can’t eliminate these types of breaches, but we can minimize their damage.”
Tim Mackey, Open Source Technology Evangelist, Synopsys:
“With applications increasingly dependent upon third party APIs, this report highlights the risks organizations have without proper vetting of the services. Understanding the data transmitted to an API and a method to validate the sanity of the returned data should be part of the review process in all development and procurement teams. Armed with this information, API consumers can then monitor for any security disclosures associated with their API usage. When you consider the US Senate Commerce Committee is hearing briefs on a national data protection law similar to CCPA and GDPR, organizations should view tracking of API dependencies as a core strategy in reducing risks associated with potential data breaches.”
Ambuj Kumar, CEO and co-founder, Fortanix:
“The USPS incident is staggering in its scope and its brazen poor security. Private information of 60M users was left exposed without any protection. Anyone with a usps.com address could have viewed the name, address, phone number, and more of all the people on the system. The new service, Informed Visibility (IV)) was not designed to check for permission and it allowed anyone to see everyone’s data. Such an insecure method is similar to a lock manufacturer selling 60M home locks only to find that all the locks have the same key! Anyone who purchased one lock and a key can get into everyone else’s house!
The incident also reveals ugly facts about the lack of effective security regulation for large scale services in the US. When a drug company creates a new medicine, the FDA has a very comprehensive set of tests to ensure no harm is done. But, a web service that can affect the lives of 60M people is somehow launched without even passing the basic sniff test of security common sense. Reports suggest that the USPS took more than one year to fix the bug. In today’s world, security bugs are constantly reported and fixed. A question needs to be asked whether this bug should have been fixed in hours rather than taking more than a year.”
Chris Morales, head of security analytics, Vectra:
“I consider what happened to be a case of lack of understanding and misconfiguration of user permissions on a web facing system. This is a concern across any API or web system that has access to a back end database. Misconfiguration of systems is as big of a risk as system vulnerabilities. Offering APIs for external service integrations is important to offer services expected by customers, but poor security practices in API access and design puts enterprises in danger.
The team implementing the API needs to have a better grasp at what type of access an API actually provides different levels of users and what kind of ways could that system be misused. This is a growing problem.”