Sunday, May 24, 2015

The Price Of Rushed Software For Apple Watch...

See bottom of article for June 25, 2015 Update

The Apple watch has caused a flurry of apps to be quickly updated to support it, sometimes successfully, and other times it would appear that it was done as part of a "look at us too" campaign by some companies shoe-horning their app onto the device.  With the rush to get software out, I am seeing some mistakes slipping through the QA systems of certain apps.  

Recently, I was contacted by one of my banks about a customer service issue, and as I sometimes do with that bank when they reach out to me, I pulled a single item off my pile of security issues and threw them a bonus bone to chew on.  (If they go to the trouble of reaching out to me, the least I can do is give them something to make themselves safer).

I raised this issue with the bank, who accidentally left "Backdoor" (their term, not mine) URL's for the iPad and iPhone in the localization strings under the Watchkit Extension for their app. 

Personally, I don't run this bank's app, but given my history in Canadian mobile banking (I've still got code in the Canadian retail banking pipeline that won't see light of day until 2016 or 2017 in everything from location services, to photo cheque deposit anti-fraud), I do keep an eye on this bank's mobile software to remain aware of the industry. 


Just to clarify for the legally minded, this isn't hacking/reverse-engineering/etc ... Hacking means breaking in or causing software to be coerced into doing something unintended, and reverse-engineering means taking software and getting back to the source to work out how something is done.  In this case, you don't need to even open/run the app, or perform any reverse-engineering...  As this information is left open, you just download the app from the Apple App Store, then open it up in Finder on a Mac and start reading what was left unprotected.  This is no more "hacking or reverse engineering" than reading the pages in a book is "reverse engineering that book".

The bank in question here can easily say "this posed no threat to our operations or customers" and they'd be totally correct... in the same way that leaving a million dollars on the sidewalk or having the entire CxO team dance naked down Bay Street would have little impact on customer privacy or be detrimental to operations - however it's still not something anyone should do willingly.  

What it does point to is a botched rollout where technical mistakes were pushed through to meet management deadlines.  Here's three reasons that led me to this conclusion.

First, URL's, in a bank app shouldn't be public.  As a bank, they're just asking for trouble when script-kiddies find this kind of stuff.   The URL's should be inside the app itself, where no class dumping tools can get to the strings (because they'd be encrypted, but whoever approved this from a security standpoint didn't understand that point when it was OK'd).

Second, from an architectural standpoint, this makes no sense as the iPad and iPhone URL's don't belong in the WatchKit extension (the iPhone/iPad does the internet stuff, not the Watch). At first glance, this looks like a schoolboy error in cut & paste coding.

Third, from a technical standpoint, this is sheer lunacy;  URL's don't belong in the localization strings file because you plug in the parameters of the language at runtime, not hardcode the URL's to the UI localization.

What we can do, is take the information that the bank provided and show what they should have done if they were doing this properly.  They should have created a function like this for the "Registration" url, and buried that in the app itself.

-(NSString*) getLocalisedRegistrationURL {
    NSString *URL = @"/olbtxn/registration/Registration.cibc?register=initRegistration&visitorId=native&locale=%@";
    NSString * locale = [[NSLocale currentLocale] localeIdentifier];
    return [NSString stringWithFormat:@"%@%@", URL, locale];
}

...then repeat this process for any other URL's that must be localised.  That's what should have been done.


Now, having said all the above, we can also take a step back from the technical lunacy and architectural nonsense, and ask if this was actually done deliberately?  

In my mind, this is the more likely scenario... 

In the above links there are instances of what appears to be a possible smoking gun in the form of "visitorId=native".  This gives the impression that under the hood, the app is doing a popular trick in the form of substituting the token flag word "native" for the value returned by identifierForVendor, which allows the bank to identify your device and track you, meaning that the URL is actually very likely being processed further in the app to do substitutions on the URL string. 

This obviously begs the question as to why they didn't substitute the locale when they've had every opportunity to do so?

I think the answer to this question would be that this is a somewhat ham-fisted attempt at casting the possible ISO locale values to force them to either "en_CA" or "fr_CA" because the backend servers don't have any idea what to do with en_US/en_UK, fr_FR, etc.

As you can guess, this problem is also easily solved... if the French language is not the user's primary language, cast the result to Canadian English:

-(NSString*) getEnglishOrFrenchLanguage {
    if([[[NSLocale preferredLanguages] objectAtIndex:0] isEqualToString:@"fr"]) {
        return @"fr_CA";
    } else {
        return @"en_CA";
    }
}

At this point, we've drawn two boxes around two mistakes, been given the preferred tracking mechanism and uncovered what looks like the hallmarks of a rushed rollout that at first glance looks like a schoolboy error and then later looks like back-end issues are being ham-fisted quickly to make deadlines... 

...all for the sake of seven lines of code.


Update - Jun 25, 2015

So the bank said that they would update the app to remove the backdoor URLs.  This week, I noticed that they have updated the app.  I took a look to see if they had removed them as they'd said they would.

This is what I found:


Yes, the word "Backdoor" has been replaced with "BD"...  

*face palm*