Tuesday, October 28, 2014

In-depth look at CurrentC and the personal data they want to collect

Just as quickly as CurrentC popped into the limelight, questions arose around the companies intentions. Even though I don't have an invite for CurrentC's invite-only system, I decided to take a look. I posted some initial findings on Twitter and a brief summary on iMore, but wanted to do a more in-depth technical post for anybody who was curious.

On launch, the app immediately does a few things. First, it starts sending pings to https://my.currentc.com/mobile/pinggateway every two seconds or so. No interesting data is sent in the requests and blocking them seems to have no impact on the app. Next, a deviceState request goes out. In the request are your device type (iPhone or iPad) and a unique device identifier. This identifier is stored in the device keychain so even if you delete the app and re-install, it gets persisted, allowing CurrentC to track users across app installs. The third and last request seen on launch is a call to Localytics. Localytics is a mobile analytics company and is used in countless other apps. As with the many other apps using Localytics, this call seems to include a variety of analytics information: not surprising for many apps, and not surprising for CurrentC (though it probably should be for an app seeking to handle payments and personal data).

After you've launched CurrentC you're given two options: I Have An Invitation or I Need An Invitation. If you tap I Have An Invitation you'll be asked for your email address and ZIP code. Entering an email that hasn't been invited yet will kick you back to the first screen and give you a message saying they'll let you know when CurrentC is available in your area. A concerning behavior I saw here is that regardless of what email you enter, CurrentC's service will respond with a large dictionary of user data.

Now, I have to stress here, I never got CurrentC to return me a real user's data. However, the fact that these fields exist is a good indicator that CurrentC plans to collect this data, and also why on Earth would you ever return these fields without any sort of authentication first? I never hit on an email that appeared to be a valid account, but I was honestly too nervous to keep trying given the data it seemed eager to send back.

While trying a number of different email addresses I discovered that any email address ending in @mcx.com will be accepted on the "I Have An Invitation" view and allow you to advance in the registration process. The check for the @mcx.com domain seems to be done locally. Before you get too excited, after registering, you will need to activate your account through a confirmation email, which will be sent to the @mcx.com email address you probably don't have access to. After realizing the check was done locally, I attempted to modify the request after it left the device (passing the local check with an @mcx.com email, but sending a gmail address on to the server), but after attempting to register, the server returned an error. So it seems that CurrentC is actually checking server-side to see if the email you're using to register was actually invited.

However, another possibility may exist. Any time you register an email in the app, a request is sent to a CurrentC endpoint that checks if the email already exists or not. If the email already exists (including users who have requested an invite, but not actually registered), the service returns a 200 OK message. If the email doesn't exist in CurrentC's system, then the server will return an error. This API call doesn't require any sort of authentication, so anybody is free to make as many requests as they want in order to determine user email addresses that have been registered with CurrentC's system. An attacker could use this to try and identify accounts that they should try to brute force, or possibly even sign up using an email address that was invited, but has not yet registered. Though without some sort of account to test on, this is informed speculation.

As an extra tidbit of info, it also looks like MCX (the entity behind CurrentC) is using Paydiant in their solution, though it's unclear if Paydiant developed the app for MCX, merely provided an SDK, or something in between.

I have additional concerns about CurrentC, but am hoping to hear back from them before disclosing them. Needless to say, CurrentC doesn't look like a great app for consumers to trust their information with.

With CurrentC, you're not the customer — you're the product being sold.








No comments:

Post a Comment