Note: This series simplifies and analyze breach/exploit details which are usually cryptic and legal led and to help other enterprises avoid the same mistake.

Company: HealthEngine
App: Feedback System
Data Leaked: 59,000+ patient’s personally identifiable information.
The complexity of hack: Low
Vulnerability Type: Day-0
Common Vulnerability: Yes and can exist on multiple endpoints.

What was exposed?

Personally identifiable information – We don’t know what exact information was leaked.

How was this hack perpetrated?

This hacked required no special tools or exploits or account hijacking of any sorts etc. Simply a web browser would do the job or an API call. The feedback system’s backend/API was sending feedback information along with the patient information who submitted the feedback. The feedback page would only show the feedback text and would skip/hide the rest of the sensitive patient information on the UI page. This information was right there in the network call or in the hidden section of the pages. All hackers had to do was to analyze the chrome or firefox’s network calls and extract sensitive patient information.

It’s a Day-0 vulnerability. What it means is, APIs with these vulnerabilities will expose sensitive information to any other third-party integrators on the first automated call itself. Most countries like in Europe and the USA have rules that require reporting these violations when companies expose just over 500 customer records. And are dealt with punitive damages, stringent audits and legal, etc.

How does this exploit works?

For example, let’s take this simple scenario.

Let’s assume the vulnerable app had these endpoints.

GET: /feedback // return list of feedback dataGET: /feedback/{feedback-number} // returns feedback details

Note: The {feedback-number} param can be a path param like the above one or could have been a query or body params. This exploit will still work across all the scenarios.

Here is an example response from the backend API. As you can clearly see the API returns the sensitive patient information as part of the “created_by” attribute. The UI page may be only interested in the other parts i.e. text and rating attributes etc. This extra information is easily accessible to the hackers and it’s right there in the browsers network call.

{“event_type”:”feedback.updated”,“created_at”:”SatDec1517:58:22+00002015″,“feedback”:{“created_at”:”SatDec1517:58:20+00002015″,“updated_at”:”SatDec1517:59:22+00002015″,“id”:”123456789″,“text”: “text…”,“ratings”: “4”},“created_by”: {“name”: “Foo Bar”,“age”: 25,“favorite_color”: “#ffa500”,“gender”: “male”,“location”: {“city”: “Seattle”,“state”: “WA”,“citystate”: “Seattle, WA”}}}

How common is this vulnerability?

It’s a common scenario. Most modern apps without realizing would end-up exposing some sort of sensitive information via the APIs if they’re using ORM frameworks. ORM framework manages relation data as large navigable objects trees or nested JSON objects when exchanged in & out of the system. This problem can become even worse if other third-party systems are consuming your APIs. Because the leak can happen on first on a regular request because there is no hiding possible on an API call.

What kind of systems have these vulnerabilities?

The industries that use customer submitted data like feedback, ratings, products, etc. E.g., E-commerce, Rating Sytems, or ORM enabled apps, etc.

What kind of systems have these vulnerabilities?

Any industry that uses customer submitted data like feedback, ratings, products, etc. E.g. E-commerce, Ratings Sytems, or ORM enabled apps, etc.

What won’t work in thwarting these kinds of attacks

Typical scanners and static code analyzers won’t help detect these exploits, they focus more on injection and on fuzzing attacks rather on sensitive data exposure scenarios.

How to protect your Apps and APIs against these attacks?

GraphQL can solve not having to send large JSON objects in/out of the system issues but it’s not going to help with actual access-control logic.

A Type-2 Scanner can be helpful which looks in addition to injection attacks and looks for business logic vulnerabilities including RBAC, ABAC, Hijack, Sensitive Data Exposure attacks, etc.