Introduction
Mobile World Congress 2012 is almost upon us, and one of the most hotly-anticipated topics is the next generation of Microsoft’s smartphone operating system Windows Phone 8, which has been kept under wraps far more tightly than its PC counterpart, Windows 8.
While Microsoft was an early adopter in the creation of smartphones with Windows Mobile, it has lagged behind both Apple’s iOS and Google Android, at least until the end of 2010, when Window Phone 7 was released. To date, Windows Phone has only achieved niche status, but has received kudos and critical acclaim, often from organizations and people not known for charity towards Microsoft. Despite the small following so far, both consumers and developers are expressing interest, and Microsoft seems determined to keep a fast-paced released cycle in order to achieve parity in the marketplace.
Since we are a security blog and not a marketing blog, though, I would like to take a look at some of the security implications for Windows Phone, both currently and for the future.
Shoplifters in the Marketplace
Like Apple and Google, Microsoft uses an application store model for distributing software, called the Marketplace. While it is possible to “root” or “jailbreak” Windows Phones in order to install applications from other sources (and, indeed, Microsoft worked with one group to approve such a hack), most users of Windows Phones will be going through the Marketplace. Like both Apple and Google, Microsoft has a policy in place for what sorts of applications can be offered in their application store, and, like one of the aforementioned vendors, Microsoft is making an effort to curate application submissions.
In addition to removing applications from the Marketplace, Microsoft can remotely remove an already-installed application from a Windows Phone. While this may generate some specter of intrusiveness on Microsoft’s part, it is not different from what Apple or Google can do on their smartphones. The decision to remove an application may take some time to be reached, and even after the command is given, it may be a while before Windows Phone receives the request, during which the undesirable app would still be present.
Microsoft seems to be doing a good job of reviewing submitted applications and enforcing its policy. As of January, 2012, there are over 60,000 apps in the Marketplace, and ESET is aware of only four applications that have been removed from the store:
- A fake Spotify music streaming application that cost $0.99 (the real Spotify app is available for free)
- A fake Google Chrome Browser that cost $1.99 but just launched Internet Explorer with a skin to make it look like Google Chrome
- An antivirus application was removed by Microsoft for violating developer policies
- A clone of a popular game was removed for a trademark violation
This is a very small sample set of data to work from, but finding four applications out of over 60,000 gives us a ratio of about 1:15,000 bad apps to good apps. While this makes the likelihood of coming across what we might characterize as potentially unwanted applications in the Marketplace as being very low, an attacker might choose to masquerade as a popular or heavily-requested application in order to entice people into installing it, relying on popularity to drive up the number of installations.
One thing to keep in mind about these four unwanted apps is that none of them were malicious in the classic sense: They did not contain computer viruses, nor were they worms, bots, or Trojan downloaders. The design of Windows Phone means that applications are heavily compartmentalized, both from the underlying operating system and each other. This means that those classic types of threats may not apply to Windows Phone, or, at least, not be seen in any great number.
Of the four apps that have been removed two were out-and-out scams, apparently designed to generate money for the rogue developers of such apps; one was removed for policy violations (duplicating functionality that already existed in the operating system was the reason given), and one was a trademark violation. It may be arguable as to whether the latter was malicious, however, since it was removed from the Marketplace, we are including it.
While there does not seem to be a need for classic anti-malware software at this time under Windows Phone, the fact that these types of applications made it through the approval gauntlet show that users of Windows Phone devices need to be cautious of what they install on their devices.
Reflections on abusing trust
The infamous bank robber Willie Sutton is alleged (incorrectly, I might add) to have said that he robbed banks because “that’s where the money is.” What the above four apps show us is that elements wish to exploit a new environment like Windows Phone are not necessarily going to use old methods of doing so, such as the parasitic file infectors and mass-mailing email worms of yore. In fact, if an attacker is after your money, they might not even have to directly attack Windows Phone.
We have been talking about the various ways in which digital certificates can be abused for a number of years now in the ESET Threat Blog, sometimes in relatively obscure ways, but other times in ways that affect us all. While the mechanics of certificate fraud are beyond the scope of this article, you should know that digital certificates are a basic building block—a kind of atomic element for trust, determining whether a connection has been securely established to your bank’s web site, or that a program you have just downloaded is indeed intact and unmodified since it was written by the developer. If a web site connection has an invalid certificate, or a program has been tampered with, you will see some sort of warning when attempting to visiting the web site or run the program.
Windows Phone’s Marketplace handles digital certificates on apps, meaning this issue is largely opaque to Windows Phone owners, and whether that’s good or bad is a matter for some debate… elsewhere. If you have a smartphone, though, you are likely using it to access the Internet in some way and you might want to make use of a secure connection at some point to visit a financial institution, do some online shopping, or even access your email or social media sites. What makes the secure connections to those sites possible are digital certificates. In March, 2011, digital certificate vendor Comodo notified Microsoft (and other web browser vendors) that its systems had been hacked and used to generate fraudulent digital certificates for logging into services as disparate as Windows Live (Hotmail), Google, Yahoo!, and Skype, amongst others. The various vendors, including Microsoft, issued advisories such as these:
Microsoft Security Advisory (2524375) Fraudulent Digital Certificates Could Allow Spoofing
Mozilla Security Blog: Firefox Blocking Fraudulent Certificates
And, for the most part, followed up quickly by issuing updates, patches or other technical means for users to secure their web browsers. But there was one platform for which the updates were considerably delayed: Windows Phone.
A Patchy Conundrum
Microsoft had just begun rolling out their first Windows Phone update about a month before Comodo’s notification, only to end up having to stop the rollout a couple of days later due to flaws in the patching process. The requirement to release a security patch to update Windows Phones to v7.0.7392 shortly thereafter compounded the process. Unlike Apple, who manufactures the iPhone and is solely responsible for releasing updates to it, Microsoft works with both handset manufacturers like HTC, Nokia and Samsung as well as mobile operators like AT&T, Bell, Optus, O2, Verizon and Vodafone, to name a few.
It is quite expensive to release an update for any smartphone, and Windows Phone is no exception. Microsoft, the handset manufacturers and the carriers all have to work together to devote significant resources to testing and validating the updates, ensuring that they can be deployed successfully, do not interfere with any proprietary software or customizations added by the handset manufacturer or the carrier (or both), update reliably when tethered or on a 3G connection and so forth. A failure at any point during this testing means they all have to work together to identify the root cause, create a fix and then verify the fix. If a failure occurs after testing and patch release, it could result in a customer with a bricked phone, which usually ends up causing costs to the mobile operator and device manufacturer, not to mention bad publicity.
While desktop operating system (and other smartphone) users had their web browsers patched within a few days, the delays caused by having to verify the update lasted throughout spring and into summer of 2011, causing Microsoft, handset manufacturers and carriers to deal with upset and angry customers. Microsoft finally resorted to posting matrixes showing when the update would be released, and for which phones and which carriers on their euphemistically-named Where’s My Phone Update? site. These pages are no longer at Microsoft, but archived copies can be found here for the United States and here for the rest of the world. Microsoft took these lessons to heart, though, and the next major update for the Windows Phone operating system (Version 7.5, code-named “Mango”) went out to customers in an incredibly smooth fashion, and in fall of 2011, the update was installed across all Windows Phones in a matter of weeks. But Microsoft announced after the release of Mango that they would no longer be sharing detailed information about updates to Windows Phone. Windows Phone will continue to be updated by Microsoft, of course, but it now becomes the responsibility of phone owners to find out check the Windows Phone Update History web site and then ask their mobile operator or device manufacturer if (or when) they will receive an update.
In the case of adding new features or functionality to Windows Phone, this might be okay; while it is always nice to have the shiniest toy, not having such features may result, at worst, in some slight loss of productivity. When it comes to fixing non-security-related bugs that affect the reliability and stability of Windows Phone, it becomes far more urgent. When it is a security vulnerability that’s being exploited, mitigation is critical.
The next major update for Windows Phone is 7.6 (code-named “Tango”) and it will add much new functionality for device manufacturers, carriers and Windows Phone owners. It is, however, evolutionary and not revolutionary. Which leads us to what’s next: Windows Phone 8.
The Undiscovered Country
Windows Phone 8 (code-named “Apollo”) is the next major version of Windows Phone, and a companion, of sorts, to the desktop and tablet versions of Window 8 that Microsoft has talked about. However, Microsoft is keeping Windows Phone 8 tightly under wraps, and it is far easier to speculate about Windows Phone 8 than getting any factual information about it. If Windows Phone 8 is anything like its predecessors, it will grow the Windows Phone brand, and that means all sort of new apps and services will be available for it, both good and beneficial, and some which are more towards the malign end of the spectrum. How Microsoft will choose to address these disparate security issues while balancing the needs of handset manufacturers, mobile operators, developers and both consumers and enterprise users is going to be tricky. Microsoft had gotten off to a rough start with security patches for Windows Phone, but from everything I have seen they greatly improved their patching process—Android handset manufacturers could learn a lesson from Microsoft here. However, security advisories and vulnerability patching are always going to be activities which require a rapid response, and hopefully Microsoft and its ecosystem partners can reach an equilibrium here that ensures its customers remain protected against the latest Windows Phone threats. Personally, I think Microsoft will succeed, but until Windows Phone 8 has its first security vulnerability patched, we won’t know for certain.
Aryeh Goretsky, MVP, ZCSE
Distinguished Researcher