Mobile Browsers Bring New Security Headaches
The new generation of mobile Web browsers is going to introduce for enterprise IT departments a rash of security challenges. The good news is that many of those challenges are familiar ones, from desktop browsers.
A December online survey by F-Secure found that about 30% of U.S. and Canadian mobile phone users access the Internet, broadly similar to other regions. The scary thing is that two-thirds of the North American users (and 83% of all respondents) said they lack any security software on their mobile phone -- and at a time when mobile Internet use is on the rise with the emergence of mobile browsers that can access the same Web sites as their desktop cousins. AT&T, for example, reported a big jump in data usage among iPhone subscribers, who were using the phone's Safari browser.
IT departments, according to experts, need to focus on three areas: assessing the security architecture and features in the mobile browser and the underlying operating system; working with users on smart and safe browsing practices; and creating a solid handheld device management system.
"Browser vulnerabilities are the easiest way to get remote code running on a smartphone," says Charlie Miller, principal analyst for software security at Independent Security Evaluators (ISE), which has identified a range of mobile security problems. "That's because browsers are pretty complex compared to most programs on a smartphone. Once exploitation occurs, the remote code can do a variety of things."
Browsers make requests to Web sites, downloading HTML pages, images, PDF files, music and video, and applications. Depending on the how the browser is designed, and the underlying operating system, these downloads and file executions can create a range of problems -- some accidental, some intentional. The result is that mobile enterprise users could find themselves with an inoperative handset, or compromised corporate and personal data.
One growing area of concern is Web widgets, bits of downloadable code embedded in a Web page. They're growing in popularity on handsets because they offer fast, focused ways to send or retrieve data, without having to go through multiple steps with a mobile browser. Many of the programs available via online application stores, such as Apple's App Store, are widgets.
"They're great because you can certify the application [with a signed digital certificate], but the widget's data may not be controlled, or even controllable," says Norman Woodward, senior manager for wireless at Accenture's mobile communications division. "You can't screen the data before it's downloaded."
A desktop example of the potential problems is the 2008 "Secret Crush" Facebook widget, which purported to reveal who on Facebook had a secret crush on you but was actually luring you to download an adware program.
Build on a secure mobile OS
For enterprise security, the starting point is the handheld's operating system. The key issue is whether the operating system makes use of a "sandbox" architecture for the applications it runs, including the browser. In effect, each application gets to "play" in a separate "space" defined by memory and permissions in the operating system. Its activity, benign or malicious, can't affect other applications or access other parts of the operating system.
"Most of these operating systems do have a sandbox for their applications," says Dave Field, device management and security architect with Enterprise Mobile, a Microsoft-backed company that specializes in enterprise Windows Mobile deployments. "With a sandbox, you can lock down the execution environment based on things like the application characteristics and limit its access to certain configuration settings, APIs, data and so on. You put a cage around the application."
Taking that a step further, ISE's Miller says, some mobile operating systems have a non-executable heap, which he describes as a mechanism to hinder or block the execution of malicious code.
The sandbox coupled with execution blocking are features exploited by Windows Mobile, according to Field. "We can prevent untrusted code from installing at all, unless it's blessed' by IT," he says. "It's like inoculating the device."
The Android operating system for mobile devices is built on the Linux kernel, which was developed originally for mainframe-class computers. That kernel was designed to separate multiple simultaneous users, and protect them from stepping on each other's applications and resources, says Rich Cannings, Android security engineer at Google. What Android did, in effect, was to substitute multiple applications for multiple users, each in its own separate user process.
"On the desktop, a browser vulnerability gives [malware] access to the full desktop machine," Cannings says. "But in Android, it will only affect the browser, not the dialer or any other application."
Securing the browser
On top of the operating system, browsers can add a battery of built-in protections and alerts. The existing Mobile Internet Explorer has a range of security zones, and alerts users when they're leaving an encrypted SSL session, for example. But there's a key drawback to such browser-based features, Field notes: "It relies on the user's decision."
For enterprise customers, Field focuses on identifying what security elements can be controlled on the mobile device, and then automating their configuration, taking those decisions away from fallible or careless users.
The Android browser's design isolates some types of vulnerability. For example, earlier this year, ISE's Miller approached the Android team with a suspected browser vulnerability: a malicious MP3 file that potentially could execute code. According to Cannings, this is not actually a browser vulnerability, because the Android browser hands off such files to a separate, sandboxed program -- in this case to the media player that's part of the Android multimedia subsystem developed by PacketVideo. The malicious MP3 file "can only affect what the media server can do -- read and write certain types of files," he says.
An emerging security standard, called extended validation certificates for SSL, is making its way into desktop and more slowly into mobile browsers, as an antiphishing mechanism. These extended certificates provide users with color-coded alerts to confirm that an SSL-protected Web site is a valid site or a known or possible phishing site. Microsoft's mobile Internet Explorer is one of the few mobile browsers that currently support this, according to Miguel Myhrer, wireless network lead with Accenture's mobile communications division.
Phishing is an example of how even mobile browsers with well-designed security can be subverted, as are their desktop cousins, by users who are ignorant or careless regarding safe browsing. Enterprises can tackle this by combining effective mobile device and application management with appropriate mobile security and user policies, and with user education and training.
Make it manageable
Increasingly, the browser may become one of the most important mobile applications to be monitored, configured and managed.
"Device management gives you the means to diagnose, interrogate, and modify settings on a handset," Accenture's Myhrer says.
Effective device management means being able to control file downloads, to clear device caches, sandbox data, deploy antivirus packages, enforce mobile VPN usage and so on. Tools range from Microsoft's System Center Mobile Device Manager 2008, to Research in Motion's expanded management features in the upcoming BlackBerry Enterprise Server 5.0, to third-party applications from Sybase iAnywhere's Afaria as well as from F-Secure, McAfee, Symantec, Tangoe and Trend Micro.
With effective device management in place, "you have the ability to apply remotely [software] patches and updates as vulnerabilities are identified," says Chris Saint-Amanat, mobile application architect with Enterprise Mobile. "And you have the ability for Internet access to be proxied via VPN to the enterprise Web proxy servers." An advantage with Window Mobile 6.1, he says, is that this VPN connection is active all the time.
One key issue about mobile software patching is who is creating the patch and the process for doing so. With mobile devices, there can be multiple players: the operating system vendor, the device maker, the carrier. An operating system patch may not come directly to the enterprise, but go through a handset maker, and then have to be tested by the carrier.