What went down at USPS Data Breach? Only ArecaBay could have prevented.

A Data Exposure flaw at the United States Postal Service (USPS) website was disclosed last week by Brain Krebs from KrebsonSecurity. The flaw was identified in the APIs exposed by a web component on the USPS website and potentially exposed data from 60 Million users. This blog does a quick rundown of how the flaw could be exploited, where exactly it is located, and most importantly, how you can protect your organization from similar API flaws.

How can the API flaw be exploited?

The flaw was explicitly in the “Informed Visibility” application service. Once a user logs into the USPS website’s Informed Visibility service, they are granted a session token or a cookie. The logged-in user can then use the same session token or cookie to query for other information such as username, email address, user ID, account number, street address, phone number, authorized users, and a lot of other personal data. The alarming problem with this flaw is that it allowed a logged-in user to request a change to the data for other users; such as email address, phone number, etc. As a bottom line, a valid logged-in session and API calls that are issued with modified parameters can exploit this flaw.

Where was the flaw?

The flaw was in the API implementation. Brain Krebs published a link to the JavaScript file that made the calls to the vulnerable API. Here are a few examples:

In the above example, the APIs are the URL path defined as “/externalapi/custreg”. And below is an example of the data that is returned by one of the above API calls as noticed in the same JavaScript file:

As can be noticed, the accountId, loginName, firstName, lastName, email, and phone details can be exposed using fetchAccount API. Similar information can be observed for other APIs, and the flaw has now been fixed by USPS.

How to get protected?

As an enterprise developing and using APIs, it is vital to identify and remediate such abuses. To this end, you need a tool capable of a few things:

  1. Ability to look at the application traffic in a world of encrypted communication between user’s and app service and between the app services themselves.

  2. Ability to go deep into the API and its parameters while building parameter context.

  3. Adapt to the changing APIs at a deep parameter level.

ArecaBay protects enterprise customer applications (and USPS if they were protected by ArecaBay) with similar flaws by identifying out-of-scope data being requested by a user defined by the session token.

What is the flaw category?

ArecaBay has identified and published the list of security threat categories here. This USPS API flaw is categorized under “Leaky App”, “Authorization Token Reuse”, “Session Manipulation”, and “Parameter Tampering”.

Will my existing security solution detect this API flaw?

There are no existing security solutions, other than ArecaBay, that can detect this type of API abuse flaw.

  • Traditional security solutions are opaque to SSL encryption.

  • The current API security solutions only look at the URL level and do not go deep into the API payload.

  • There is no host or platform vulnerability involved in this flaw. Similarly, there is no runtime flaw. Hence solutions such as RASP and CWPP do not play any role in protecting against such API defects.

ArecaBay is the industry’s 1st and only security solution catered towards detecting API abuses. Learn more about how ArecaBay makes it easy for anyone to discover, monitor, and secure the complete enterprise API surface in a 10 min demo.