Lack of HTTPS on iOS App Store left users open to attacks, researcher says

Apple fixed the issue in January by enabling HTTPS by default for App Store active content

Until late January, Apple's App Store servers did not encrypt all communications with iOS clients, which exposed users to several potential attacks, according to a Google security researcher.

"The Apple App Store and associated applications, such as the Newsstand, are native applications provided by default with iOS to access/purchase content from the Apple App Store," said Google researcher Elie Bursztein Friday in a blog post. "While the Apple App Store is a native iOS app, most of its active content, including app pages and the update page, is dynamically rendered from server data."

[ Learn how to protect your systems with Roger Grimes' Security Adviser blog and Security Central newsletter, both from InfoWorld. ]

Network attackers could have exploited the lack of HTTPS (HTTP Secure) encryption for certain parts of the communication between Apple's servers and the App Store iOS clients in order to inject rogue content into application pages seen by users, Bursztein said. The technique would have allowed attackers to trick users into exposing their passwords by injecting fake password dialogs into the App Store app, force users to buy and install rogue apps by altering purchase parameters on the fly, trick users into installing rogue applications by passing them as updates for already installed apps, prevent users from installing or upgrading particular apps, or see what applications users have installed on their devices.

These attacks were possible before Jan. 23, when Apple enabled HTTPS by default for App Store active content. The company noted the change in a support document listing fixes on Apple's websites and credited Bursztein and two other researchers with reporting the issues

Bursztein claims to have reported the attack scenarios to Apple in early July 2012. "I am really happy that my spare-time work pushed Apple to finally enabled HTTPS to protect users," he said.

Like most attacks exploiting the lack of full-session HTTPS on websites, the App Store attacks found by Bursztein could have easily been executed against iOS users connected to public Wi-Fi networks like those found in libraries, airports, coffee shops or other public spaces.

The researcher described each attack scenario in detail in his Friday blog post and published video demonstrations on YouTube showing how the attacks would have appeared to targeted iOS users.

"I decided to render those attacks public, in the hope that it will lead more developers (in particular mobile ones) to enable HTTPS," Bursztein said. "Enabling HTTPS and ensuring certificates validity is the most important thing you can do to secure your app communication."

During the past few years, major Internet companies like Google, Facebook and Twitter have enabled always-on HTTPS for their online services in order to protect users.

"Apple, it seems, didn't bother with HTTPS everywhere, even for its own App Store, until 2013," said Paul Ducklin, the head of technology for the Asia-Pacific region at Sophos, Saturday in a blog post. "Since there's no other place to shop when you're buying or selling iDevice software, and since Apple likes it that way, you might think that Cupertino would have set the bar a bit higher."

Even the ability to see what applications an iOS user has installed on his device, which appears to be the least serious attack scenario reported by Bursztein, has significant implications, according to Ducklin.

"Firstly, some of those Apps will identify aspects of your life that would be handy for a social engineer to know: the bank you use, the newspapers you like, the games you play, the share-trading services you invest with, and more," he said. "Secondly, the complete selection of Apps on your device may very well be unique to you, thus making it a handy form of digital fingerprint for an attacker."

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies