Echelon PII Leak and Disclosure Fail

Echelon (Echelon Fitness) is a competitor to companies such as Peloton. You buy the hardware, quickly assemble it, buy a subscription, use a built-in or external smart device and you do your exercise thing! However, their API had significantly worse security flaws than those we found in Peloton.

Echelon were also somewhat more challenging to deal with during the disclosure process than Peloton, first failing to respond and eventually claiming that they had fixed the issues ~90 days earlier, despite being provided with evidence to the contrary.

TL; DR

Echelon’s application and APIs did not sufficiently protect users’ information as several functions openly disclosed personally identifiable information (PII). We immediately reached out to reasonably disclose these issues but were actively ignored until we asked a trusted journalist to speak to Echelon on our behalf. All of these issues have been resolved, though the leaderboard system still shows your city and age range.

Harvestable information includes:

• User IDs
• Locations (address, zip code, city, state. All of which are populated from your payment info.)
• Names
• Email addresses
• Telephone numbers
• Stripe IDS
• Age, Sex, Weight, Birthday
• Equipment serial numbers
• Retailer purchased from
• Subscription dates
• Badges, workout stats, workout history

Complete PII Disclosure: API IDOR Vulnerability (Issue One)

There is a social aspect to this application so you can modify your own profile, view peoples’ profiles, add them as friends and so on. The application consumes the below API endpoint to grab information about a user, and any authenticated user that knows this endpoint could feed it user IDs to extract their information. This is caused by an Insecure Direct Object References (IDOR) vulnerability, which essentially means there is a lack of access-controls or privileges to safeguard this functionality.

Real world exploitation would have been trivial as user ids are openly disclosed, which could’ve been fed into Burp’s Intruder (an automated tool) to extract all or most of their users.

API Request:

GET /v1//user/USER ID HERE HTTP/1.1
Host: api.echelonfit.com
Connection: close
Accept: */*
X-Echelon-Source: X
User-Agent: X
Authorization: Bearer TOKEN HERE
Accept-Language: en-gb
Accept-Encoding: gzip, deflate

API Response:

Class Information Disclosure (Issue Two)

Any user that enters a live or pre-recorded class can intercept the traffic to interrogate data that is not presented to users’ devices. I recently discovered that the application and its leaderboard system has changed since I initially disclosed the vulnerabilities so I will include screenshots and information before and after the changes.

API Request:

It should be noted that this could be viewed by an unauthenticated user. The Authorization token is not checked.

POST /leaderboard HTTP/1.1
Host: lbload.temporal.echelonfit.com
Content-Type: application/json; charset=UTF-8
User-Agent: X
Connection: close
Accept: */*
X-Echelon-Source: X
Accept-Language: en-gb
Authorization: Bearer [[TOKEN HERE]] – THIS IS NOT NECESSARY!
Content-Length: 188
Accept-Encoding: gzip, deflate
{
"friends" : "",
"ondemand" : "[[ID HERE]]",
"heartrate" : "",
"user" : "[[ID HERE]]",
"ride" : "[[ID HERE]]",
"ts" : X,
"page" : ""
}

API Response:

New Leaderboard:

Echelon are now using PubNub’s (third-party) technology to power their leaderboards.

Request:

{"bdy":{"userId":3*****},"to":"pubnub-manager:\/","mid":"*D*-*A-*2-A*-*","typ":"pnjoin","frm":"*@client:\/","aut":"Bearer [[REDACTED]] "}

Response:

Intended Functionality = Interesting Find

The user search functionality is functioning as intended, however, Echelon have given users the ability to search for friends using email addresses. This led me to an interesting find, which amplifies the risk of the IDOR issue that was active for 85+ days after disclosure.

Perhaps not the wisest move to use government email addresses for user accounts…

Metadata Disclosure

Users’ profile photos that were uploaded did not have metadata stripped, so GPS and other sensitive information could be pulled from any photo with metadata present.

Echelon resolved this issue and now strip metadata at the point of upload.

COPPA violation?

The Children’s Online Privacy Protection Rule, or COPPA, is a US FTC rule that imposes a number of requirements on operators of web sites or online services directed at children under the age of 13. This adds a significant administrative overhead of, for example, obtaining parental consent, so most web site and service operators prevent children 12 and under from registering.

We found a number of children’s profiles under the age of 13, which may be a breach of the rule. According to the FTC ‘civil penalties of up to $42,530 per violation’ may be imposed.

Echelon have now made changes to prevent children under 13 from registering.

Disclosure Time!

We wish this disclosure played out differently, however, it ultimately resulted with fixes for all disclosed vulnerabilities. We reached out but heard nothing until a trusted journalist contacted Echelon on our behalf, which didn’t go quite to plan.

Disclosure Timeline

20^th January: My colleague Ken DM’d Echelon on Twitter and was promptly given an email to send the report to. All good.

22^nd January: Echelon confirmed receipt of the report and that it been forwarded to the ‘correct department’ and ‘They will reach out as soon as possible’.

Various interactions with their social media team followed over the coming two months, getting no further forward with the vulnerability being fixed. I asked to speak to their security team direct, but this was refused.

6^th May: Ken asked for contact details of their press office, as we were way over 90 days since initial disclosure. This request was refused!

We resorted to the ‘big guns’ and brought in your friendly neighbourhood cyber reporter, Zack Whittaker. Zack being Zack managed to break through and started a conversation.

The plan did not go to plan. The plot thickened…

Zack received an email from their in-house legal counsel that claimed they had received the report and acted promptly to resolve the matters. They also claimed that they had engaged a 3rd party security firm who could no longer recreate the problem.

During email discussions, Echelon then claimed that they had fixed the vulnerabilities on the 21^st of January! The day after they received the report. Impressive. We kept a watchful eye on the vulnerabilities and found it was still present on the 15^th of April:

The leaderboard flaw was not fixed on the 21^st of January either. They replaced the old solution with a new one that presented the exact same data but with nicer formatting. Our evidence shows that they replaced precise ages with age ranges sometime after the 7^th of May.

Why would Echelon state something that was not correct? We don’t know. We asked Zack to give them another opportunity to clear the air before we went public, but they stuck to their story and replied with

“They have been remediated”.

We have experienced a wide range of disclosures, good ones, bad ones, tricky ones. This one takes the biscuit though. Why make a bold claim of remediating the issues within 24 hours of disclosure when they simply hadn’t?

“When in hole, stop digging”.

It has been an eventful disclosure, but we are happy to see that the vendor fixed the issue and eventually communicated with us. Let us hope that this promotes security awareness and the importance of proactive security.