Kevin BosticAt least six months after being alerted to a possible exploit in the way users connect to its App Store, Apple has added encryption to users' connections, plugging the security hole.
Google security researcher Elie Bursztein said on his blog that he alerted Apple of the potential for attack in July of last year, with the flaw affecting users connected to the App Store, reports CNet. The vulnerability Bursztein pointed out was made possible by Apple's use of the non-encrypted HTTP protocol instead of HTTPS for certain parts of communication with the App Store.
Bursztein pointed out that, in theory, a malicious network attacker could exploit the use of HTTP to steal user passwords, force users to install a specific app instead of the one they were looking for, trick users into downloading fake app upgrades, prevent application installation, or scan the apps on a user's device.
Bursztein published a number of videos detailing how the attacks might work, as well as additional technical details on the attack methodology earlier this year.
In an Apple Web Server notifications update published on Feb. 23, Apple addressed the issue. Active content is now served over HTTPS by default. Apple acknowledged Bursztein for pointing out the issue, as well as Bernhard Brehm of Recurity Labs and Rahul Iyer of Bejoi LLC.
The App Store has periodically been the target of attacks in the past. In 2010, Apple tightened security for the online marketplace following incidences of account fraud that saw some users hit with several hundred dollars worth of erroneous charges.
In April of 2012, Apple again updated its security protocols, adding a measure requiring users to fill out security questions to be associated with their accounts. In the event that a user signs on from a new device, iTunes and the App Store now requires them to answer the questions in order to verify their identity.
Andrew Orr
Christine McKee
Sponsored Content
Wesley Hilliard
AppleInsider Staff
Amber Neely
13 Comments
Better late than never I guess? It would be nice to see them respond to such security issues quicker.
Apple has been very responsive to security threats lately to an impressive level. This is a low risk vulnerability: App developers have the opportunity to encrypt their data using an API provided by Apple. Listener must be on the same (likely public) Wi-Fi network. The HTML would need to be prepared in advance considering that the request is temporary. I am glad Apple did address this vulnerability.
Why would simply enabling SSL take so long? Not saying it was high risk, but it doesn't seem complicated either.
[quote name="bedouin" url="/t/156377/apple-adds-encryption-to-app-store-connections-addresses-six-month-old-hole#post_2290656"]Why would simply enabling SSL take so long? Not saying it was high risk, but it doesn't seem complicated either.[/quote] There are potential issues with implementing SSL and such potential issues must be considered and possibly resolved such as SSL through NAT. One must also consider that the code must be compatible with (or at least not break) multiple versions of iOS, Mac and PC software. I can only speak to my experience but my experience is pretty typical. Here are some of the steps taken to resolve a defect in a software product: 1. Defect reported (security vulnerability) 2. Defect verified and reproduced 3. Defect forwarded to Defect Management Team 4. Defect Management Team needs more information (triage delayed until next week) 5. Defect Management Team forwards to iTunes team 6. iTunes team forwards to Security team 7. Security team reproduces 8. Security team evaluates and recommends a "low threat" status with "low effort" 9. Defect Management Team triages based on Security team's recommendation (now one weeks later) (two weeks total) 10. Eventually, the defect reaches the water mark (twelve weeks later or 4 development cycles later) (fourteen weeks total) 11. Security team is scheduled 12. QA team is scheduled 13. Security team resolves the defect (delivered to QA in a revision three weeks later per the development cycle) (seventeen weeks total) 14. QA team tests the defect (testing is complete three weeks later per the development cycle) (twenty weeks total) 15. Revision is delivered to the iTunes NOC with a quarterly revision (twelve weeks later) (thirty two weeks total) 16. iTunes NOC schedules the revision deployment for six weeks later (based on the low threat status) 17. iTunes NOC deploys new version of iTunes server to hundreds of servers
[quote name="MacBook Pro" url="/t/156377/apple-adds-encryption-to-app-store-connections-addresses-six-month-old-hole#post_2290660"]There are potential issues with implementing SSL and such potential issues must be considered and possibly resolved such as SSL through NAT.[/quote] Still, think how many transactions a site like Amazon has to deal with. Encrypted communication with a store should have been in place at all times. It's about time all internet communication was encrypted by default. I think ipv6 was supposed to help here but I don't know why they had to make ipv6 addresses so complex. I don't think we need that many possible addresses, it really should have been easy enough to tack on a 4 digit hex code at the start of ipv4 to give 281 trillion possible addresses e.g fefe:198.277.0.12 with existing codes starting with ffff: as opposed to FE80:0000:0000:0000:0202:B3FF:FE1E:8329 or even just use 3 or 4 hex codes like fefe:8bbe:9001.