Sensitive Data Exposure and Vulnerability Reporting

Sensitive Data Exposure and Vulnerability Reporting

How to report security vulnerabilities to responsible parties

·

6 min read

Warning: This blog post is for educational purposes only. Do not attack unauthorize computers.

It was a nice Sunday afternoon and it was way past lunchtime. I decided to hit up a ring sushi restaurant. They had recently done away with paper menus for ordering and had opted for a QR code dine-in ordering portal. Cool. I up my camera and took a picture of it before opening up the link via the camera app.

QR Codes

I always thought that QR Codes looked cool. In the past, I've written logic to parse barcodes, but haven't given these 2D barcodes much thought. They serve as a pretty cool way to transfer digital information and track usage. Urls, contact cards, images, plain text, calendar events, and other information can be encoded onto them. Great for those URL links since, who wants to type that into a phone, every time they see one? They come in two flavors, static and dynamic and both can be stylized.

  • Static QR Codes can't be changed after they've been created and can't be used for tracking/analytics.

  • Dynamic QR Codes reference the information and that information can be changed and the access to that information tracked. I'm guessing there is some site that acts as a proxy that links the static information conveyed in the QR code to some entry in a database.

Reconnaissance

Later that night I remembered that I had the QR code and wanted to see if I could access the site a normal browser at home. The code opened to:
https://www.somesite.com/?menu=restaurant_name&tid=table_id_some_id

I expected there to be some sort of timeout or geolocation restriction with the phone proximity and restaurant. Turns out this was not the case. Firing up the Chrome tools to take a deeper dive:

API Calls

By filtering by Fetch/XHR type which corresponds with API/ajax calls, you can see the endpoints, request and response payloads. I noticed that the menu made calls to a mobile endpoint /m/api while the root site made calls to /api.

A lot can be known from these details:

The backend is using ExpressJS. Could be a vector for attack, knowing the version can narrow down possible security vulnerabilities. Are they using appropriate security headers in their response?

https://www.somesite.com/m/api/restaurants/restaurant_name/tables

Returns back all available tables.

https://www.somesite.com/m/api/restaurants/restaurant_name

Returns restaurant details, no surprise.

https://www.somesite.com/m/api/restaurants

Returns a giant blob of json. After formatting it and scrolling through it, I can find instances of passwords that appear to be MD5 hashes. A quick reverse lookup of it reveals a string of digits. Don't ever use a non-cryptographic secure hashing algorithm to store passwords. MD5 is ok if you want a unique hash unlikely to collide for the case of Merkle trees.

But what is most concerning are the bank details returned for their customers (restaurants):

This isn't good.

There is personally identifiable information (PII). This information could be used for social engineering purposes by malicious actors upon owners of those bank accounts. Can, possibly, be used for withdrawals without authentication. Note that this information isn't credit card information which companies follow and should adhere to Payment Card Industry Data Security Standard(PCI-DSS). There are the National Automated Clearinghouse Association standards which this would fall under.

Javascript

The javascript code was not minified and I didn't need to use the browser to prettify it. Some comments left were funny.

  • Javascript is not obfuscated.

  • jQuery framework used.

  • There are regular and admin endpoints.

  • User IDs are sequential and hence enumerable.

Considerations

At this point, I had been doing the equivalent of looking through a window of a house and noticing a checkbook left on a desk. None of the information gathered was behind any kind of authentication or was any attack done to exfiltrate sensitive information. All that was involved was essentially the path traversal of an API.

As with any penetration testing/ethical hacking, permission must be obtained before any such testing/attack is to take place.

The most recent version of the Computer Fraud and Abuse Act (CFAA) has expanded the details of what is considered cyber-crime and this type of path traversal doesn't seem to be explicitly called out. My expertise isn't in cyber-law or even bird law.

On the other side, the business in question is responsible for protecting its client's sensitive information. According to the Federal Trade Commision, when there is a breach, there is a responsibility of the business to investigate and remediate as well as inform impacted customers. This isn't an instance of a breach, more like the door was just left open.

I have a responsibility to report this.

Reporting

With just the domain name of the site, there was a support email link, however, who was the company? There were some clues in the javascript source code, but I wanted to confirm. I can tell that the domain is registered with GoDaddy.com with who.is. The name servers indicate that the site is hosted through Amazon AWS. This information could have been obtained with a ping of the domain and IP address detail lookup as well. Checking the domain on Instagram and Facebook wasn't fruitful in this case. However, searching LinkedIn provided me with the details to the parent company. I can see previous developers who worked there and in some instances, know what code they worked on about the site, based on source code comments.

I sent an email to the support of the parent company asking to be directed to a proper resource.

  • To be safe, the company should provide a PGP/GPG public key for you to encrypt the report details.

  • Summarize the vulnerability/issue.

  • Provide steps to reproduce the issue or create a proof-of-concept of the exploit.

  • Illustrate the impact.

  • Add any other supporting material/references.

Glad I could help. Hope the invite isn't a honey pot.

Summary

  • Sometimes it's a fine line between exploration and hacking.

  • OWASP TOP 10 continues to be relevant.

    • Path (API and website) enumeration.

    • ID enumeration

    • Broken Access Controls - I once was able to make myself administrator on a tool with a POST request to update role.

    • Misconfiguration

    • Sensitive Data Exposure

  • A lot of information can be obtained from the client-side source code and APIs (authenticated and non-authenticated).

  • There are many ways to track down information via search engines and social media sites.

  • When you find one vulnerability, it's an indicator that there are more. Code smell? Smoke?

  • It's easier to find security vulnerabilities with smaller companies than you would with a company that offers a bug bounty or uses a platform like hackerone.com.

References