Customer Data is the Customer’s (private) Data — It should not be open for all — Part 2— Croma

Discovery by: Rahil Bhansali & Ankit Pandey

Disclaimer: What you’ll read below and in the series of blog posts are simple but massive security vulnerabilities that exist in some of the most popular brands. My approach in each case has always been (& will continue to be) to understand the extent of the loophole, exhaust every connect to try and bring it to the company’s notice, have them fix it and then write about it so consumers and companies alike can focus on improving their defences in protecting consumer data, privacy and security. In cases where I’ve not been able to reach the company, the post serves as a last ditch effort to alert the company so that they can fix the issue. Please do note — we have no particular affinity to any brand of companies, and some of the brands mentioned in the series — we are subscribers / customers of and admire the leadership and what they do for our country as well.

This is the second post in a series of posts that detail out security vulnerabilities. The first post can be found here. Some of the information may not be repeated since its detailed in the previous post.

Part 2: Croma

Summary of Findings: Croma on https://www.croma.com/— inadvertently exposed its customers’ data including:

• Name
• Registered Mobile Number
• Address
• Offline & Online Transaction History for all previous purchases (including but not limited to): invoice #, amount, item name, image, item price, qty purchased, addressed shipped, delivery status, etc.

The data accessible included names, phone numbers & addresses of celebrities, popular business people, doctors, among others.

Scale: The above data for ALL Croma Customers was accessible by any one who knows how to hit an API (any developer to be honest). The data above is accessible for their current and old customers who’ve walked into a store or shopped online.

IMPORTANT: If you are connected to any senior executive to Croma, kindly bring this to their notice so they can fix it immediately. You can also have them contact me.

UPDATE: I have this morning received confirmation and verified that the issue is temporarily fixed. Appreciate the promptness and the candid acknowledgement of the Croma team in resolving the vulnerability discussed. Thank you to everyone who has helped connect with their network to help patch the vulnerability.

Possible Malicious Uses of Data: Data acquired from such vulnerabilities could theoretically be used for a lot of different malicious plays — some posing risks to consumer privacy, security while others that could be a business risk to the company itself. Here are some ways:

• Sale / Use of Sensitive Information — Equipped with a large database of Personally Identifiable Information (PII), an attacker could use the data to pretend to be the user across various corporate call centers in India (Croma has a lot of customers across major metros).
• Consumer Targeting by Competitors — Any other portal could use this information to target consumers by finding the highest value consumers or inactive consumers and targeting them (legally or otherwise by writing scrapers).
• Phishing and Credit Card Details — Given the sensitivity of the information, KYC update or Warranty Renewal phishing emails/SMS could be easily devised which would look realistic and sent to the customer. A customer could be taken to a look-alike warranty renewal page and be requested to enter their credit card details there by helping the attacker get even more information on the customer and cause a financial loss. Example of possible phishing campaigns that I could have theoretically run if I had to think of malicious uses:

1. Hi {{ name }}, your samsung refrigerator warranty is set to expire. Please click <a href="www.google.com">here</a> to renew to stay protected for another year.
2. Hi {{ name }}, you can still buy apple care for your recently purchased iPhone 12 Pro. Please click <a href="www.google.com">here</a> to purchase it.
3. Hi {{ name }}, your KYC needs to be updated. Is this still a valid contact number: {{ mobile number }} and address: {{ address}}? Please click <a href="www.google.com">here</a> to update.

Backstory: On December 28/29th, I found vulnerabilities in Tatasky (detailed here). Given the scale of the discovery, I spent some more time in the following days trying to look at Starbucks, Croma, Taj Hotels and other Tata Group entities to check if they used similar levels of programming patterns. To my surprise (rather sad) — Croma used a similar weak level of security for a critical data interface that allowed any attacker to theoretically get all the data detailed above.

Discovery (Technical Explanation): With my tech capabilities, I was able to see under the hood and realised that an API (what gets the data from a database) being called was open and even though it is behind authentication — a basic mistake exposed the entire customer base. (Won’t be sharing the API since its still not fixed due to inability to contact the company even via customer care — detailed in the section below — but I’m hoping its fixed soon).

After finishing the work required to get the Tatasky vulnerability detailed, on Jan 1st, I wrote a script to start accessing the Croma API to understand the extent of the vulnerability.

When I saw the API structure, even though the header accepted an access token (which is a form of authenticating which user is accessing the data), the developer who wrote this api decided to ignore such a token and chose to pass the mobile number as a parameter to the API. What that (assuming unknowingly — since it’s an amateur developer mistake) did was that I could now pass any mobile number without logging in as the customer and access the customer’s data.

Replicating at Scale (Technical Explanation): In under 2 hours, I was able to write a simple script that would get this information for any mobile number in a consumable format.

This was important so that I could bring the extent of the vulnerability to the Croma team’s notice without much back and forth (this after-all was an probono discovery).

Now the question was — can you get this data at scale for the entire customer base without having to input one mobile number at a time? After all, a sophisticated attacker would have to do that to really make use of the information.

To solve the problem of which mobile number to pass, we used a wikipedia article to understand mobile number formats in India. We also used the oldest series like 9820, 9821, etc. from Vodafone and in the Mumbai circle so that we could quickly test our script out. The assumption was, if we take any 4 digit series and sequentially went through the last 6 digits (000000 to 999999), we’d have a million hits on the open APIs and be able to pull data for whichever number returned a match.

But to do this at scale so that the process would not take time, my dear friend and ex-colleague, Ankit Pandey’s help with the Tatasky script came in handy. I could now run the process on multiple threads and write it to a CSV. With that, in another hour or two, we now had a script that we could theoretically run for all the mobile numbers in India and see if the person was a Croma customer and get the users order history.

We then tried this with a few 4 digit series just to check if our script was working and our assumption was correct.

To our surprise (rather sad it actually worked) — we were able to pull data for random mobile numbers. Additionally, without any API rate limiting, you could keep hitting the APIs (infinite times) in a few hours and it would return data. With that understanding, it was time we reached out to Croma so that this could be fixed.

Note: We have not pulled the entire database because we have no use of it, just tested whether it was technically possible. My intention is and never will be to trespass, just understand what someone with malicious intention can possibly do. I do not understand the legality of it and my intent has and will always be to have the issue patched by the company!

Company Interaction & Fix: At the time of this writing, the issue still exists.

I have tried various ways to reach the company between December 30/31st, 2020 and January 20th, 2020 (until the time of this writing).

My first obvious choice was to find out company leadership names and connect with them on LinkedIn. I have tried connecting with the CEO, CMO & other senior executives to no success. Don’t blame them — no reason to accept my invite on LinkedIn — however — I did send a note explaining I’ve found a major vulnerability.

I’ve also tried contacting and finding various ways to contact the leadership at Tatasons, including calling their landline of a corporate office (but was unanswered assuming because of Covid-19).

I’ve also tried contacting security teams and reached my network to see if someone knew anyone at Croma — to no avail. I’ve tried calling Croma stores near me — but since they’ve switched to a centralised call center number, that doesn’t help either.

Another effort has been to post on Croma’s page on LinkedIn with my findings (screenshot below). Basis their message, I dropped an email to customer care — who didn’t seem to understand the severity and has so far not escalated and help resolve the vulnerability.

IMPORTANT: This blog post is a last ditch effort to not only spread awareness to customers and other companies on the severity of cyber-security and privacy, but also hoping it gets the traction required to reach the right people at Croma who’ll get the issue fixed. As I mentioned — this is a probono finding and a lot of effort and time has been invested by us in bringing awareness to all the stakeholders.

UPDATE: I have this morning received confirmation and verified that the issue is temporarily fixed. Appreciate the promptness and the candid acknowledgement of the Croma team in resolving the vulnerability discussed. Thank you to everyone who has helped connect with their network to help patch the vulnerability.

Recommendations for Interaction with Security Researchers / Developers: Unfortunately, we’ve not heard back from the company as discussed above. As developers ourselves, we understand that issues exist in any tech product — but we do hope issues when discovered can be reported easily. A few suggestions for companies:

1. Do publish on your website a non customer-care email that can be used to report such issues / train customer-care to escalate these. Train customer care to understand and escalate such issues.

You can check other recommendations in Post 1.

Recommendations for Developers & General Basic API Security Tips (please research further and ensure best-in-class security): Below are some recommendations for ensuring security for your digital products:

1. You can check recommendations in Post 1.
2. One other learning from this discovery — maybe its time companies think of limiting order history data available easily to a few months instead of it being available since first purchase. Archive some order history in cold storage after crunching data to understand how much is relevant.