Where to report egregious credit card and phone esn data leak

Question

I'm not sure if this is the right community to be posting this in, please point me in the right direction if not.

I recently discovered that my cell service provider (an MVNO) has an unauthenticated API that returns (among other things) my credit card information (name, number, expiration date, address, CVV), hashed passwords and account numbers, and my phone's ESN number. Something like this:

Request

curl --data "phone=1234567890" https://example.com/api/getdata

Response

Please note: I've stripped out a lot of data and renamed the keys. There were a bunch more fields that didn't seem very important.

"account": {
  "phoneNumber": "1234567890",
  "ESN": "1111111111111111111",
  "startDate": "01/01/2010 00:00:00",
  "payment": {
    "card": "1111111111111111",
    "CVV": "111",
    "name": "My Name",
    "expMonth": "01",
    "expYear": "2021",
    "street": "111 Example Street",
    "zip": "11111"
  },
  "accountNumber": 11111111,
  "balanceEndDate": "01/01/2020 00:00:00",
  "balance": 0,
  "status": "Active",
  "planId": 00000,
  "password": "<what looks like a salted MD5 hash.>"
}

That is enough data to do a lot of damage. Besides using the card, they can port my number to a different carrier and use 2-factor authentication to reset passwords to a lot of my most security related accounts (think bank).

I discovered this the other day by using their website. They have a "Refill" option that takes your phone number and tells you your balance and lets you refill. When I realized they were telling my the balance without signing in, I opened the developer tools to look at the ajax response. To my surprise (and horror), I saw my credit card information.

What to do?

I'm not sure who I should report this to other than Visa/MasterCard. Are there any government/industry groups that would be interested? I'm in the US.

Answer 1

First of all:

• you do not report this to the government/external party/visa/mastercard

External parties serve to complicate matters via conflict of interest. It is not their business, it is the business of the company who has the vulnerable api. It is not for them to decide how to handle this, but the company.

• Tell no one in your circle of friends, family or anyone about the details.

Here you can get yourself into trouble very easily. If it is discovered later that someone you knew used or attempted to use the information, you could be held accountable for reckless action, or at the very least investigated heavily. Don't put yourself in this position and tell no one anything that would allow them to repeat the vulnerability.

• Don't panic

The best thing you can do right now is calmly make a plan and execute it. Anyone who is in the position to exploit this likely already knows about it. Anyone who is not is likely not going to discover this within the next few days.

Now, on to: Responsible Disclosure

Step 1 - Prepare

Before anything we need to make sure that the vulnerable API is well documented and has a set of instructions. For example, a small report, doesn't have to be long, just easy to follow. The idea is, the intern within the office should be able to follow the steps, reproduce the vulnerability and successfully identify the security risks. A small PDF or WORD document will do, just make sure you have something ready in case things move quickly.

Step 2 - First Contact

Next comes first contact with the company. First contact is a delicate thing. On the one hand you would expect that the company has the interest of their customers as a first priority. On the other hand some companies respond rather poorly (and in my opinion, irresponsibly) to people disclosing vulnerabilities for the benefit of everyone involved. For this reason you want to withhold the exact details until an agreement is made that no action will be taken against you.

Me, I'm the paranoid sort, and when I encounter this sort of thing ill go to a coffee shop, use TOR and use an email (one I've set up by using a similar process) to initiate first contact. It is however up to you what level of anonymity you wish to use.

Some things you can check. If the company has a bug bounty, or has a disclosure policy. You should be fine. You can call the company and ask if they have a department responsible for security disclosures. Most companies of this size have an [email protected] email. All of these would have information that would lead you to exactly where first contact should be made.

Step 3 - Processing

Once you are talking to the right person, it should work itself out from there, except as I've previously noted, if there is no bugbounty or disclosure policy make sure you get them to agree to a terms of disclosure that involves your safety first. At some point you will hand them the document you made in step 1.

Step 4 - Closure

The last step to do is public disclosure. This step is entirely optional, and will be heavily tied into the agreed upon disclosure terms in step 3. But usually both parties agree to an amount of time that the company has to fix this vulnerability before a public announcement can be made. It's entirely normal for the researcher to desire to post it on their blog, or use it as reference material for other projects or qualifications. This time period makes sure that the company is not put under undue pressure and gives them time to act.

Congratulations, you just had your first responsible disclosure. You may choose to not announce it ever, and that's fine. In that case the time period from step 3 would be, for you, when you can safely tell friends and family exact details.

I wish I could give rep for desiring to disclose responsibly, alas, in stead I'll wish you the best of luck. Try to be discreet, keep yourself safe, and try to work with them. Good Luck.