Apple is learning why shortcut security is a bad idea

Credit to Author: Evan Schuman| Date: Wed, 20 Feb 2019 11:00:00 -0800

When Apple launched its enterprise developer certificate program — which helps enterprises make their homegrown apps for employee use-only available through iTunes — it had to make a difficult convenience-vs.-security decision: how much hassle to put IT managers through to get their internal apps posted. It chose convenience and, well, you can guess what happened.

Media reports say pirate developers used the enterprise program to improperly distribute tweaked versions of popular apps — including Spotify, Angry Birds, Pokemon Go and Minecraft — while others used the platform to distribute porn apps along with real-money gambling apps. And all the bad guys had to do was lie to Apple reps about being associated with legitimate businesses. Apple didn’t bother to investigate or otherwise verify the answers.

Apple now has two ways to go: gut or severely limit its enterprise certificate program or pour in enough resources to effectively verify all answers before granting access. Any longtime Apple watchers know which route is more likely. Hint: The enterprise program aims to make it easier for companies to leverage iOS devices, but it doesn’t deliver a ton of direct revenue. Assigning talent to fix it when Apple is struggling to make its iPhone sales goals seems unlikely.

Let’s drill into what happened. First, courtesy of Reuters, comes the report of the software pirates. “These pirate operations are providing modified versions of popular apps to consumers, enabling them to stream music without ads and to circumvent fees and rules in games, depriving Apple and legitimate app makers of revenue,” the Reuters story said. “Apple confirmed a media report on Wednesday that it would require two-factor authentication — using a code sent to a phone as well as a password — to log into all developer accounts by the end of this month, which could help prevent certificate misuse.”

Two quick thoughts on Apple’s 2FA approach, assuming this reference is correct. First, texting a code is begging for a man-in-the-middle attack, and these pirates are well able to deliver such a move. There are far more secure 2FA options. Secondly, all this will do is verify that the person who created the account is the person who is right now trying to gain access. It doesn’t address the real issue here, which is that they were fraudulent applications initially.

The story of the porn and real-money gambling apps came from TechCrunch, and it delivers far more specifics about how easy these frauds were to commit, given Apple’s ultra-convenient approach.

“Developers simply have to fill out an online form and pay $299 to Apple, as detailed in this guide from Calvium. The form merely asks developers to pledge they’re building an Enterprise Certificate app for internal employee-only use, that they have the legal authority to register the business, provide a D-U-N-S business ID number and have an up to date Mac,” TechCrunch reported. “You can easily Google a business’ address details and look up their D-U-N-S ID number with a tool Apple provides. After setting up an Apple ID and agreeing to its terms of service, businesses wait one to four weeks for a phone call from Apple asking them to reconfirm they’ll only distribute apps internally and are authorized to represent their business. With just a few lies on the phone and web plus some Googleable public information, sketchy developers can get approved for an Apple Enterprise Certificate.”

Apple has managed to make this process convenient from a security standpoint (which is a bad thing), but inconvenient and arduous from an IT perspective. Put more bluntly, the company made it relatively easy for crooks while forcing legitimate IT workers to jump through a lot of hoops. Steve Jobs is doing some serious rolling in his grave.

Given that Apple is already having a call center representative calling to reconfirm, why not call the company whose D-U-N-S number is being used to verify that it really made the request? Apple could ask for the contact person and then make sure that everything is legitimate. If the contact person is not known, that’s a good reason to delay or even outright reject the approval. Ideally, delay it and give the applicant a chance to explain. After all, the chance that the person answering the corporate switchboard might be a temp and can’t find the employee is not so unlikely.

That said, this verification effort will significantly add to the labor that Apple needs to expend on authentication, and it’s not clear if this makes fiscal sense for the company.

But, Apple, if you want to enforce these rules, then truly enforce them. Making people fill out a lot of online forms and then wait a month for a phone call makes little sense if no one is bothering to verify the answers.

http://www.computerworld.com/category/security/index.rss