11. PDAs and Smartphones

Our world has continued to provide newer and faster ways to connect us with our networks. Each day we pick up the newspaper, there’s a new device that’s supposed to be the hottest thing on the market. The end result to you as a professional is that you wind up having to support, and worry about, a million different threats to your network.

Précis

In this chapter, we explore the world of the mobile micro platforms supplied to us by the likes of Verizon and AT&T. Just like their big brethren, the market for these tiny marvels sports multiple operating systems just to keep life exciting. But, unlike the gravity-hampered notebooks, the fits-in-your-pocket market also supports different hardware. Yes, there is Apple in the notebook market, but not with the penetration that some of the non-Windows systems have demonstrated in the personal digital assistant (PDA) and smartphone (SP) market.

We’ll start with a look at each of the operating systems, what their architectures look like, what some of their weaknesses are, and what we can do to mitigate any threats that presently exist.

Points of Interest

For the purposes of this chapter, I’m not going to differentiate between a handheld organizer and a smartphone. The way I see it, the difference is in where the device started its evolution. Did it start the way the Palm and Windows did, as an organizer, or did it start like Symbian, as the heart of a cell phone? This is similar to the firewall argument that touts the benefits of a proxy-based firewall over those of a stateful packet inspection firewall. Each has its benefits, but in the end the market-driven forces of evolution have pushed each vendor to include some elements of each technology in their offering. So it is with PDAs and SPs. So, for the purposes of making the discussion easier, I refer to this entire class of devices as “handhelds,” because you must hold them in your hands to use them.

Handheld devices are, for the most part, new additions to our networking environment. Until recently, most PDAs or cell phones were generally relegated to voice calls or synchronizing contact and calendar information over a serial port. Times have changed, however, and the handheld is now considered one of the great tools of our enterprise. They are also a great pain for the security group that protects your network.

Unfortunately, they have about the same maturity with respect to security that notebooks had five years ago. The operating systems claim to have security functionality, but malware continues to spread. Companies claim to have tools, but phones are still getting clobbered. In a strange “life imitates art” kind of event, let’s look at what happened to Paris Hilton and her phone. Paris lost control of her address book, and although she didn’t seem to have a serious problem with it, the folks who were on the list did. Apparently, some folks didn’t want the world to know that they were on Paris Hilton’s speed dial. In a nutshell, it was embarrassing for them in much the same way it was embarrassing for the Veterans Administration (VA) to lose millions of veterans’ personal information. In case you’re curious, I’ve already received my notice from the VA (because my name was on the list). I’m actually hoping that someone steals my identity. Maybe they can get my credit score above 350.

We need to come to grips with the fact that handheld endpoints are the single largest threat to our networks today. The multitude of connection methods multiplied by the number of operating systems means that security people are going to be very busy for the next few years trying to plug the holes in the dike. There might be some interesting tools, but they have to become a part of our architecture and philosophy for them to succeed.

A Serious Threat Today

Although we are beginning to see more malware aimed at PDAs and SPs, I think the biggest threat is really the loss of device and the resulting loss of data. Someone may steal your device, and if you don’t protect it, that person will have access to the valuable data stored on it. In my chats with people, I’ve learned that people will put all kinds of data on their PDA because they don’t associate the value of the data with the ease that the data could be lost.

It doesn’t have to be a malicious attacker who gets your data. It could be just about anyone, and you could be the reason. On more than one occasion, I’ve seen the lone phone slide down the X-ray machine conveyer belt with no owner in sight to claim it. I’ve also listened to folks putting themselves back together after the trek through the metal detector start conversations with “I think you picked up my phone.”

And, you don’t just lose things at the airport. According to Hertz spokeswoman Paula Stifter,¹ cell phones and cell phone accessories are the items most often left behind in their rental cars. In this same article, De Lollis quoted Donna Maxi, the Transportation Security Administration’s logistics manager at Los Angeles International, as saying that at least four notebooks and three to four cell phones are lost, every day! If you figure that number is probably an average for an airport of that size, you’re looking at more than 30,000 endpoints missing in action every year.

Interesting Solutions

There are ways to protect against the threat posed by theft or loss, but it does mean using a couple of protection mechanisms in tandem in much the same way we use layered defense in our network environments.

One of the tools that I ran across would erase the device information if it decided that the device was being threatened. Of course, that means you need some serious password management tools to ensure that just fat fingering your password doesn’t trigger a data meltdown. But the interesting conclusion is that you’ve lost physical control of the device and it must be destroyed! This is similar to the safeguards placed in military communications devices. If the enemy attempts to open the device, it “self-zeroizes” the contents, making the device useless to the enemy.²

Connectedness

I can’t help but think that a handheld endpoint is really today’s version of a protocol bridge. As you can see in Figure 11-1, they communicate over serial, infrared (IrDA), Bluetooth, USB, and WiFi. With little effort, data could be passed from one protocol to the other.

Figure 11-1. The handheld device has become a nexus for multiple communications protocols and technologies. IrDA, radio, cable media over serial and network protocols.

This means that these devices have two ways to synchronize: over the air (OTA), or through the host, which usually means a cradle. When syncing OTA, the device must be capable of protecting itself and engaging in a secure conversation with the data service. In most cases, this means an encrypted link back to an exchange server.

Using a host means that the handheld is synchronizing with the data on the host through USB, serial, or IrDA. Hopefully, the host has some security tools on it to reduce the exposure that the handheld has to viruses and worms.

New Territory

One interesting thing that I discovered is that there’s not a whole lot about handheld device hardening out there. This is clearly new territory, which means that there’s going to be lots of mistakes made. As we learn more, we’ll begin to classify those mistakes and begin to create a body of best practices knowledge to help us create templates and guidelines.

I suspect that the main reason that there’s not much information is due to the diversity of operating systems and the lack of focus within the hacking community that this engenders. With Windows, you have a nice, well-defined target. Not so here.

Operating Systems

A number of mobile operating systems power the handheld endpoint market. Palm led the pack for a considerable time, but Symbian is the worldwide front-runner, with Windows Mobile and Linux slugging it out for second place. Of course, there would be no discussion of operating systems, no matter their size, without mentioning Linux and its fervent followers.

Windows Mobile

Windows Mobile is the name that Microsoft gives to its class of software that powers any number of endpoints that aren’t chained to a desk. Debuting on PDAs starting in 1996,³ it was the competition to the Palm operating system. If you were a geek, you were probably looking down on Windows CE as big, bloated, and slow. But that’s changed. The newest version of this mobile operating system is sleeker, faster, and more capable than its predecessors.

But CE isn’t alone in the Microsoft mobile computing stable. If you go to the MSDN page,⁴ you’ll find CE listed with XP Embedded, Windows Embedded for Point of Service, and NT Embedded. Quite a selection. We’ll go over the Embedded class of software in Chapter 12, “Embedded Devices,” but for this chapter we’re going to look at Windows CE, because it’s the operating system tucked inside of PDAs and SPs.

Keeping up with the marketing times and changing its name to Windows Mobile, Microsoft has been making inroads into the SP market. Depending on who you talk to, Windows Mobile is either as popular as Linux or more popular than Linux.

Any way you shape it, Microsoft is turning into a real player in the mobile market. I suppose you would have to have some faith in the operating system if you actually dumped your own operating system in favor of CE as Palm did by dropping Palm Source. That faith translated into more than 50 percent growth last year, with revenue topping $74 million.⁵

The Mobile kernel is based on WinCE 5.1 and offers enhanced wireless multimedia extension (MMX) capability. I suppose that this is an admission that the world is going to be wireless and multimedia oriented—as far as Microsoft is concerned. I wonder what they’re going to call it when all the media types are seamlessly integrated?

Windows CE is architected as a layered solution. As you can see in Figure 11-2, the four basic layers starting from the top are as follows:

1. Application
2. Operating System
3. OEM
4. Hardware

Figure 11-2. The Windows CE embedded operating system is a layered construct that employs an OEM layer that interfaces vendors’ unique hardware with the Windows CE kernel.

Symbian OS

Symbian claims that they have licensed over 700 million copies of their operating system on 100 different phone models.⁶ Founded in 1998, Symbian has more than 1,300 employees and is owned by Ericsson, Nokia, Panasonic, Samsung, Siemens, and Sony Ericsson. Symbian is essentially a company that creates and licenses their operating system to all the phone manufacturers. In Q1 of this year, their licensees shipped more than 11.7 million Symbian-powered phones.

Symbian also claims that it is based on open standards, runs in real time, and sports a multithreaded kernel that “provides the basis for a robust, power-efficient, and responsive phone.”

The basic architecture of Symbian is based on an old concept called the Trusted Computing Base, or TCB. The idea behind the TCB is that it is small and well understood. Failure modes of the TCB are predictable and properly mitigated. Symbian builds on this model by surrounding the TCB with a semi-trusted layer called the Trusted Computing Environment. User processes then plug into the next layer, which is treated as untrusted. Figure 11-3 shows a diagram of how this works.

Figure 11-3. Symbian employs a TCB-based architecture that reduces the kernel’s exposure to untrusted code.

Saying that you have a TCB doesn’t imply that you have perfect code; it just implies that you have trust in how it operates and how it fails. It also doesn’t imply that there won’t be security flaws, because the TCB needs to operate within a particular security context.

Symbian supports their security context through the use of something called capabilities. Why they chose this term to describe how their security context works is beyond me, but the best I can come to guessing why is that they consider specific actions, such as writing to memory, a capability. Sure, in the strictest sense, writing to memory is a capability, but I really think that something more security related, such as “permissible actions,” would have worked better.

A capability allows an application to do things, and as you would expect, the further you get from the TCB, the fewer actions you’re allowed to have.

Actions are communicated through an Inter Process Communication protocol that is mediated by the TCB. As applications request access to files and services, such as dialing a phone number, the TCB checks to see whether the application has the suitable capability. If it doesn’t, the request is denied. An interesting extension of this also applies to code segments that the application loads to support its function. Any application that loads a dynamic link library (DLL) must check to ensure that the DLL has at least the same capabilities as the calling application. This makes it very difficult for a rogue application to take advantage of a Symbian native application, because it must have the same, if not greater, level of trust.

The architecture supports DLLs and plug-in software modules, making it extremely versatile. The most recent version is 9, and it does have some interesting security features:

• Applications are granted access based on signed certificates.

• Hardware-based memory protection.

• Applications can have private protected data stores.

• Certificate management.

• Full encryption.

• Secure protocols. HTTPS, SSL, and TLS.

• WIM framework.

As you can see from the list, Symbian understands certificates! Signed applications have a level of trust even if they operate in untrusted user space. The reason for that is to ensure that if malware does get loaded onto the system, it can’t use the capabilities of a signed application to gain greater access.

All the design constraints associated with Symbian indicate a well thought-out security design, but like every well thought-out design, a weak spot exists. Symbian relies on a vetting process for applications prior to granting a signature. As long as the vetting process continues to work, things will be fine. However, it will only take one time, one missed hole, to destroy this trust.

Blackberry

Research In Motion, or RIM, has been in the hardware business since 1984. Their premier product, the Blackberry, has evolved since its introduction as a two-way pager in the mid 1990s. Many of the mobile solutions today owe their success to the trials and tribulations that RIM endured as they pioneered this new market.

In 1999, the first Blackberry debuted as a wireless email device and quickly got the derogatory nickname “crackberry” because of the constant and habitual usage by Blackberry owners. Being able to get your email anywhere proved more addictive than anyone would have assumed.

The basic premise of the RIM solution involved the pushing of email to the handheld device. Mobile users could respond to emails as if they were sitting at their desk, although the common responses were generally as few words as possible.

To integrate the Blackberry into your corporate network requires the use of a product called the Blackberry Enterprise Server (BES). As shown in Figure 11-4, BES acts as a proxy or relay by scanning the inbox of your Exchange, Novell Groupwise, or Lotus Domino server and relaying the messages to RIM’s network operations center (NOC). The NOC relays the messages to the wireless provider that is supporting your version of the Blackberry.

Figure 11-4. The Blackberry uses the BES to check for email on the corporate server, and a service at RIM to relay email messages.

RIM claims that the proprietary operating system is multitasking capable and has built-in connection encryption using Triple DES (3DES) and Advanced Encryption Standard (AES). The Blackberry also supports Java ME (Micro Edition). Being Internet Protocol (IP) capable, the Blackberry supports email protocols and Wireless Application Protocol (WAP), thus making it an effective solution for your mobile endpoints. There is some limited security functionality provided, because third-party applications must be signed if they want to use restricted functionality. However, this is not an attestation of application security but is merely an identification of authorship.

The Blackberry isn’t without its fans. At Black Hat USA 2006, a presentation on analyzing complex systems featured the Blackberry and the supporting communications infrastructure.⁷ The conclusion was that a back channel to the corporate network could be discovered and leveraged.

From a business perspective, with more than five million Blackberry users,⁸ we must assume that this is going to be pervasive solution despite RIM having to pay NTP Inc. $612.5 million for the rights to the Blackberry technology.

Palm

It’s hard to predict the future. After all, who would have thought that that Novell was staging a comeback? But I think it’s pretty safe to say that unless the folks at Palm Source do something quick, it’s only a matter of time before the Palm operating system becomes an interesting milestone in the handheld historical timeline.

Starting life as a PDA and evolving into what it is today, a very capable and connected handheld endpoint, the Palm has provided a similar marketing force as the one provided by RIM. Palm enhanced their PDA functionality and added the networking capability later in the product’s evolution.

One nice add-in feature is Palm Security 5.0p. Palm Security 5.0p adds 128-bit data encryption in AES, RSA, or RC4. To address those who are constrained by regulation, Palm Security 5.0p is FIPS 140-2 certified when using AES.

Something that you would think would be a standard feature for all devices, failed password protection, is also part of this package.

Mobile Linux

The Open Software Development Lab, or OSDL, is pushing what they call a mobile Linux initiative. Their hope is that the open source people will help prepare Linux for use in the handheld mobile computing market.

There are other users of Linux, such as MontaVista, who have shipped more than eight million phones in the last two years.⁹ The downside of Linux is that it takes time and money to customize it so that it works on the handsets. It would seem that one of Linux’s strengths, its flexibility, is going to be its biggest hurdle to acceptance in the handheld market.

But this is not to say that the mobile computing companies aren’t working on Linux. As I said earlier, depending on who you listen to, Linux is at least as popular as CE. If you look at Japan, it’s incredibly popular, and this region alone may account for the surge in the operating system’s popularity. Panasonic and NTT DoCoMo have recently released the P902iS to run on their 3G network.

Initial Health Check

This is the hard part for these systems: determining what the security state of the device is. All the security functionality seems to focus on prevention. No tools are available to check the health state of your device!

About the only thing you can do to check the security posture of your device is to turn it on and run some applications. If it runs, you’re probably okay. At this point, I would only say that this is more an indication on the state of the malware “industry” than a testament to the security of handheld endpoints.

Securing Handhelds

So flash back to before the time of Windows NT, when hardening your computer meant running antivirus (AV) software on it. That’s pretty much where we are today with the present state of handheld devices. There are some third-party security tools that we’ll discuss later, but for the most part they’re signature-based AV or encryption tools.

It is my opinion that the present market isn’t driven by security functionality, and the diverse nature and competitiveness of the operating system vendors is creating a huge security vacuum. Couple that with the hardware manufacturers’ push to get new technology literally into the hands of more people, and the mobile endpoint community begins to look more like a ripe target of opportunity.

That said, you can do a few things to protect your handheld, but virtually all of them require you to add more software to your system.

Windows Mobile

The first thing you should do is enable the PIN or password feature on your mobile endpoint. It will ensure that in the event that your system is lost or stolen, nobody will be able to read those erotic stories you’ve been secretly writing. It will also prevent the loss of any personal information that you’ve put on it. I know folks who have their ATM PIN and their various passwords stored on their mobile toy of choice.

This strategy will slow down some digital attacks, too. When I was synchronizing my HP Jornada with my Mac, I actually had to disable the PIN feature on the HP to make it work. Suffice it to say that I sent the manufacturer, PocketMac, a note saying that this was unacceptable. I was assured that it would be addressed in future versions. However, PocketMac Pro 2.0 does not support password protection. Why is this important? Because it means that the PIN is used to authenticate the device prior to allowing access.

Symbian OS

The Symbian operating system has numerous viruses and Trojan horses that are actually in the wild. For example, CommWarrior.a¹⁰ will spread using Mobile Messaging Service (MMS), but will only infect Symbian-equipped phones. There is some good news here, however: For the moment, the code doesn’t seem to be very well written. And if you consider that the threats all have a low risk of data loss, although they might hose your phone’s operation, it’s not too bad.

As for trying to determine whether the device has been successfully attacked, it would seem that the only way to determine that is to look at your device. If it’s working, you’re fine.

All of the security software seems to address the following:

• PIN locking

• File encryption

• Systems Management Server (SMS) security

• AV

Palm

The first thing that you should do is password protect your Palm device. You can use the Security application to assign a password and to set the endpoint to automatically lock itself during idle periods.

You can also “hide” sensitive data from prying eyes. The Palm allows you to classify data as “private,” and when you engage the security application, you can either hide or mask records. If you hide them, you can’t see them, but the mask option leaves a gray bar in the file list. When you attempt to access files marked as private, you must enter the password before the record is accessed.

All other security is via third-party providers. You can get password managers, encryption tools, and some hacking tools if you dig hard enough. Because this is a practitioner’s book, we do discuss tools later, but you’ll have to find your own hacking tools.

Blackberry

RIM touts the fact that the Blackberry has been “approved” by various governments for use with sensitive data. Canada, Australia, New Zealand, and the United Kingdom have approved the Blackberry for restricted and protected (protected B) type information. Protected information corresponds loosely to SBU (Sensitive But Unclassified) and is focused primarily on industrial security.

NATO has also approved the Blackberry for transmission and storage of data to the NATO “restricted” classification.

Just for clarification, the only level of classification lower than restricted is public, and depending on who you talk to, just about anything can be considered “restricted.”

A certification that does carry some weight is FIPS 140-2. FIPS is a crypto certification that ensures that your crypto engine and the associated functions operate properly. The Blackberry 7290 has been approved to Assurance Level 3.¹¹ Without going into a complete breakdown of FIPS 140-2, I will say that this is fairly impressive, because it incorporates the following:

• Level 1. Basic security compliance and the use of approved algorithm, crypto module (CM) specification, CM ports and interfaces specification, finite state model, key management, electromagnetic interference / electromagnetic compatibility (EMI/EMC) testing, self-test (power on and on demand), design assurance document

• Level 2. Tamper evidence and role-based authentication for cryptographic module management and/or usage

• Level 3. Tamper prevention and zeroization of critical security parameters (CSPs in FIPS lingo) and identity-based authentication

The documents required for FIPS certification easily outweigh a Blackberry.

Perusing the 7290 Users Guide isn’t very useful if you’re a security person. Basic security functions are as follows:

• Enter device password

• Lock/unlock keyboard

• Content protection

Although the device password and keyboard locking are fairly straightforward features, content protection isn’t. Content protection is pretty general and can get in the way when your device is locked. I ran across a trouble ticket that says if content protection is enabled and the device is locked, names won’t appear in the display when a call comes in. The ticket resolution was to disable content protection. So much for content protection.

There is an upside to the Blackberry security: You can’t exchange files using Bluetooth.

Synchronization

For many people, the method of choice is still the “hot sync” process, whether it be through Bluetooth or a serial connection. This is still a connection, however, and as such, it is an infection and attack vector. However, as more handhelds become IP ready, their capability to synchronize via the network is growing.

The Mac seems to have standardized on a synchronization protocol that incorporates some standards, such as SyncML, but most of the sync routines are custom to the device being synchronized.

You should know that some synchronization tools require that you drill holes through your firewall for them to work. This begs the question of how much access is being provided to both the handheld and the host endpoint. For example, the instructions in PocketMac Pro 2.0 tell you to open the firewall to ports 990, 999, 5678, and 5679. Because there is no other identifier, we must assume that any device that attempts to access those ports will be presented with access.

This isn’t only on the Mac. Active Sync behaves the same way on the PC and also adds NetBIOS to the mix of required ports.

Believe it or not, there is a standard for exchanging synchronization information, and it’s called SyncML. Begun in 2000 as the SyncML Initiative, it is now supported by the Open Mobile Alliance,¹² with the newest version of the specification referred to as OMA Data Synchronization V1.2. This is a candidate release based on the V1.1.2 Approved Enabler spec that increases the functionality of the service considerably. OMA uses Hypertext Markup Language (HTML) to encode data and incorporates data management facilities that allow you to sync with numerous devices. OMA Data Synchronization is supported by virtually all SP and PDA manufactures.

The nice thing about OMA is that it uses existing HyperText Transfer Protocol (HTTP) to exchange information. This is also a problem because it becomes difficult to differentiate between authorized synchronization activity and data theft. The good news is that OMA does use authentication, but the authentication protocol relies on HyperText Transfer Protocol Secure (HTTPS) to protect the credentials.

Applications

I don’t know about you, but my eyes are getting too old to look at the tiny type on the screens of these mobile devices. Truth be told, I’m starting to look real hard at going from a 17-inch to a 21-inch monitor just to get bigger print for the same amount of information displayed.

Aside from the size of the screen, most people I talk to tell me that they use their mobile devices for one of three things:

• Email

• Messaging

• Browsing

The next three sections discuss the security issues of these applications so that you will understand that these emerging problems require some thought. Each application does have its own set of security concerns, but the solution used is quite platform dependent, because each platform’s capability to protect various aspects of the operating system differs.

Email

The app that made the Blackberry famous! I’ve had people curse their widgets in the same breath that they’ve claimed that their pocket annoy-a-tron had saved not only their careers, but also the future of their company. All by being able to respond to a message when it came through.

But the simple fact is that in their native state, email applications allow suspect content to be sent to your mobile endpoint, where it could be a potential threat to the data.

Messaging

Instant messaging (IM) is the fastest-growing medium for communication, but this also shows up in the fact that it’s the fastest growing threat space. IM protocols work just like email, except that they’re happening in real-time rather than store and forward.

So, let’s take a message from the past here. IM and Internet Relay Chat (IRC) protocols are the method of choice for botnets, and if what we’re seeing in the desktop and notebook world is any indication, the mobile handheld world is next on the list. Botnet owners act with impunity and show no sign of giving up. They are driven by profit, and as the handheld community grows, they are going to become a target for the botnet community.

Browsing

As more networks allow for the downloading of complex multimedia content, the higher the probability that this content will be exploited to the detriment of the user. Many of the attacks that we’ve seen rely on the user browsing to sites that aren’t what they purport to be, resulting in malware being downloaded and installed on the target system. Although this isn’t widespread yet, neither is handheld browsing when compared to the mainstream habits of desktop- and notebook-based endpoints.

Networking

If you look at the ways that handhelds get infected, it’s by some form of networking. Physical access generally means that you’ve either lost the darn thing or someone has taken a spark plug and broken a side window of your car to steal your stuff.

There is a good news–bad news kind of ending here, however. The good news is that modern technology has made it easy for you to network your endpoint over any number of choices. You can wire, or you can go wireless. If you choose wireless, you have a few choices to pick from. More good news is that the handheld manufacturers have included all the popular methods of connecting your device to the countless masses who yearn to send you a message. You can use the good old cell phone protocols because they provide basic message exchange, photo (really just a file) exchange, and a connection to the Internet. Using 3G, or third generation cellular technology, you can have the Internet at your fingertips.

WiFi

Without doubt, 802.11 has its problems. From the early days of this wireless protocol to the current version of 802.11g, there has been a trail of hacked networks and lost data that demonstrates that the hackers are ahead of the designers.

Wireless is a textbook example of complexity versus ease of use. When you first turn it on, there is no security. From a product sales and customer satisfaction perspective, this is the kind of customer experience you want new customers to have. I turn it on, and it works! This wouldn’t be the case if I had to connect a computer to the access point (AP) and tell it what computers to allow on to the network. I’d have to do a bunch of things prior to having that joyous experience that only doing a Google search from an SP can give! Okay, maybe not nirvana, but there have been a few times when I was glad that I didn’t have to search for a network connection.

You can add “security” to a WiFi network in numerous ways. You can restrict the computers allowed to connect to your network by maintaining what is called a “while list” of authorized computers. The Media Access Control (MAC) address of the wireless endpoint is added to the AP’s list of permissible devices. If your MAC address doesn’t match with one in the list, the AP won’t talk to you. Sounds simple enough, but it eliminates the flexibility that WiFi is supposed to provide. It also adds administrative complexity, because now you have to know how to find the MAC address on any endpoint that wants to connect to your network, and you have to manually update the list as endpoints are added and removed.

So, to accommodate our need to search from the comfort of the local Starbucks, handheld vendors are adding 802.11 protocols to the feature set of their devices. And thankfully, the good folks at Starbucks are using some security protections to keep your precious data secure. But, are they really? Let’s examine how the process works.

WiFi is a physical medium, which means that it’s at the lowest layer in the stack. For you to connect to a password-protected network, you need to know the password prior to connecting. I’ve actually been to some hotels where the password is written on a piece of paper at the front desk! WEP encryption works this way. Sure, it keeps the neighbors out for a little while, but you have to figure that eventually the password will get out. Some places have “solved” this problem by changing the password on a weekly, or should I say “weakly,” basis, but the clear indication is that this simple method of restricting access isn’t adequate.

Originally, WiFi security—well, I should correctly say “privacy”—was provided via the WEP protocol, but as more users came online, WEP came under enough scrutiny that multiple holes were discovered. To address these holes, new security protocols, such as WPA, were added to enhance WiFi security.

Bluetooth Security

Bluetooth is wireless technology typically used to connect a headset to a cell phone, synchronize your calendar with your PC, connect to a printer, connect keyboards and mice to PCs, or to transfer photos or ring tones between cell phones. Note that all these uses expose the host device to some form of threat. In the case of the headset-to-cell phone connection, most allow the headset to issue commands to the cell phone, such as “take a picture.” When you connect one piece of hardware to another, as is the case with printers, keyboards, and mice, you open the door to impersonation. The last “feature,” sending photos and ring tones, is essentially a file transfer protocol, and that’s just wrong over a weak public channel such as Bluetooth.

Technically, Bluetooth uses a 48-bit device identifier (which looks suspiciously like a MAC address) and frequency hopping over 79 channels coupled with low power to prevent misuse and confusion between devices. Although the protocol does provide the connectivity features quite effectively, the privacy aspects of Bluetooth leave quite a bit to be desired.

When BT made its debut, the security freaks were told “it’s a short-range radio protocol, so don’t worry.” Two years ago at the Black Hat Briefings in Las Vegas, Adam Laurie and Martin Herfurt did a presentation outlining the many flaws of Bluetooth.¹³ To make matters worse, or more interesting depending on your perspective, Bruce Potter and Brian Wotring, both members of the famed Shmoo Group,¹⁴ did a presentation and demonstration called Tracking Prey in the Cyberforest during the Black Hat Briefings. During the conference, Bruce and Brian set up sensors designed to pick up and track Bluetooth devices. Dubbed “proximity-based Bluetooth tracking,” Brian and Bruce successfully demonstrated that BT could be used for purposes other than those intended by the original designers. They tracked people as they migrated through the conference. So much for worry; now it’s reality that we have to think about.

One feature of BT is the capability to “hide” the device in a way that is similar to how 802.11 hides, by not broadcasting a service set ID (SSID). Called nondiscoverable, it essentially hides your device by not broadcasting its ID. However, last year a paper was written by Wong and Stajano on discovering hidden Bluetooth devices through brute-force attacks.¹⁵ It’s slow, but it proves yet once again that security by obscurity isn’t a good plan.

Although some manufacturers are starting to become security-aware, authentication is not the default; and if it is, it’s pretty weak. I hope that I’m not giving up any corporate security secrets, but take my Motorola E815. The default Bluetooth pin is 0000, and I haven’t found a way to change it. At that point, why bother the user with entering a PIN at all? Maybe the designers think it makes us feel better. Like taking off our shoes at the security checkpoint at the airport.

To make matters worse, BT authentication isn’t consistent across devices, and this inconsistency has been realized as the lowest common denominator in authentication implementations. Authentication usually occurs during the pairing process. As I brought up with my Motorola earlier, a PIN is exchanged that causes the generation of a link key. The link key is then used to authenticate with the aforementioned security mechanisms being used to protect the key.

One interesting thing about this networking protocol is that there is no logging! A search through the specification doesn’t even generate a hit on the word logging (or log, for that matter).

I took the liberty of perusing the BT 2.0 specification titled “Specification of the Bluetooth System, Covered Core Package Version 2.0 + EDR.” First, fascinating reading. I begin to see why there are so many interpretations of the standard. Second, much of the security is recommended. For example, if you wanted to launch a brute-force attack against the endpoint, the mechanism that prevents that is an ever-increasing time between allowed attempts. However, the spec says, “That is, after each failure, the waiting interval before a new attempt can be made, could be for example, twice as long as the waiting interval prior to the previous attempt.” Note the use of the word could.

I’m not a cryptographer, but it seems that the cryptographic functions leave something to be desired. Keys are based on the PIN (which defaults to 0000 in the preceding example), the BD_ADDR (the device BT MAC address), and a random number. If we know the first two and we have a poor random number generation (RND) function, breaking the encryption seems trivial.

Although BT uses separate keys for authentication and encryption, the encryption key can range from as little as 8 bits to a maximum of 128 bits. Encryption keys are based on authentication keys, and because authentication keys don’t change, and if you happen to break through the encryption used, you gain access to the authentication key.

One more interesting thing that I noticed was that all pairing activity is done in clear text. That is, it’s not encrypted. Encryption is optional.

Linux has a BT configuration tool call hcitool that enables you to control the BT connection from the command line. It’s convenient in that it allows very detailed control of remote devices. The following list of hcitool commands indicates that there is a rich set of commands that you can use to connect to a BT device, submit commands, or change configurations. Of particular note are the commands that enable you to enumerate other BT connections and delete them:

• dev Display local devices.

• inq Inquire remote devices. For each discovered device, Bluetooth device address, clock offset, and class are printed.

• scan Inquire remote devices. For each discovered device, the device name is printed.

• name <bdaddr> Print device name of remote device with Bluetooth address bdaddr.

• info <bdaddr> Print device name, version, and supported features of remote device with Bluetooth address bdaddr.

• cmd <ogf> <ocf> [parameters] Submit an arbitrary HCI command to local device. ogf, ocf, and parameters are hexadecimal bytes.

• con Display active baseband connections.

• cc [--role=m|s] [--pkt-type=<ptype>] <bdaddr> Create baseband connection to remote device with Bluetooth address bdaddr. Option pkt-type specifies a list of allowed packet types. <ptype> is a comma-separated list of packet types, where the possible packet types are DM1, DM3, DM5, DH1, DH3, DH5, HV1, HV2, and HV3. Default is to allow all packet types. Option --role can have value m (do not allow role switch, stay master) or s (allow role switch, become slave if the peer asks to become master). Default is m.

• dc <bdaddr> Delete baseband connection from remote device with Bluetooth address bdaddr.

• sr <bdaddr> <role> Switch role for the baseband connection from the remote device to master or slave.

• cpt <bdaddr> <packet types> Change packet types for baseband connection to device with Bluetooth address bdaddr. packet types is a comma-separated list of packet types, where the possible packet types are DM1, DM3, DM5, DH1, DH3, DH5, HV1, HV2, and HV3.

• rssi <bdaddr> Display received signal strength information for the connection to the device with Bluetooth address bdaddr.

• lq <bdaddr> Display link quality for the connection to the device with Bluetooth address bdaddr.

• tpl <bdaddr> [type] Display transmit power level for the connection to the device with Bluetooth address bdaddr. The type can be 0 for the current transmit power level (which is default) or 1 for the maximum transmit power level.

• afh <bdaddr> Display AFH channel map for the connection to the device with Bluetooth address bdaddr.

• lst <bdaddr> [value] With no value, displays link supervision timeout for the connection to the device with Bluetooth address bdaddr. If value is given, sets the link supervision timeout for that connection to value slots, or to infinite if value is 0.

• auth <bdaddr> Request authentication for the device with Bluetooth address bdaddr.

• enc <bdaddr> [encrypt enable] Enable or disable the encryption for the device with Bluetooth address bdaddr.

• key <bdaddr> Change the connection link key for the device with Bluetooth address bdaddr.

• clkoff <bdaddr> Read the clock offset for the device with Bluetooth address bdaddr.

• clock <bdaddr> [which clock] Read the clock for the device with Bluetooth address bdaddr. The clock can be 0 for the local clock or 1 for the piconet clock (which is default).

Another tool, obexFTP,¹⁶ enables you to transfer files to and from most BT-equipped phones. With these two tools and a script, it seems trivial to automate address book theft or SMS message fraud.

There is also a turnkey solution that you can buy if all you want to do is snarf BT packets. Frontline¹⁷ has a device designed to help out in the BT development process by providing access to intercepted and decoded BT signals. It listens on all 79 channels and can report on packet error rates. Pairing is important!

Cell Protocols

As I said earlier, cell phones can bring the Internet to your fingertips. The downside of that is that now, the Internet is at your fingertips with little or no security. Sure, your calls are encrypted, but as I’ve often said before, an encrypted pipe is a great way for a hacker to hide his activities.

Modern 3G cell protocols, such as EDGE¹⁸ (Enhanced Data rates for GSM Evolution) and EVDO¹⁹ (1x Evolution-Data Optimized), allow for broadband network connections and the applications that chew up that bandwidth. Most users have no real security on their SPs and instead rely on the cellular company to provide security and privacy. This means that as you browse the network or engage in your IM conversations, you’re leaving yourself open to attack.

Some cell phone protocols are now encrypted, thereby making it more difficult to intercept conversations; but when the channel is terminated at the other end of the radio, the communications channel is again unencrypted. As you can see in Figure 11-5, the encryption only protects the airborne portion of your call.

Figure 11-5. Your cell phone conversation is only encrypted to the cell base station. When your call is on the Public Switched Telephone Network (PSTN), it is no longer encrypted.

The EVDO folks are fond of saying that they can use AES to encrypt your cell conversations, and the cell phone industry has been using an algorithm called Cellular Authentication and Voice Encryption (CAVE). Through a fairly convoluted process, a 42-bit key called a long code is used to seed the CAVE algorithm. The output of that is then used as the key material for AES. Unfortunately, a paper titled “Cryptanalysis of the cellular authentication and voice encryption algorithm” suggests that CAVE is significantly flawed.²⁰

This doesn’t mean that GSM is any better. In a paper penned in 2003, it is suggested that the authentication algorithm COMP128 and the communications cipher A5/3 are vulnerable to various attacks, including a fairly trivial brute-force attack.

Tools and Vendors

“See a need, fill a need” seems to be the motto here. A number of vendors are adding varying forms of security to our mobile endpoints, but none of them seems to have learned from the mistakes that we’ve made in the past. From what I can tell, they’re focusing on transport security and data-at-rest security. Each vendor seems to be staking out their portion of the market, thereby reducing their business risk. It also allows them to focus on their solution set. Yes, there is of course AV, but once again that is, in my opinion, just an extension of the existing commodity AV market.

One caveat: I have experience with the Good product line and not the others. This is not an endorsement of any vendor, because, like weapons development, marketing is about leap-frogging the competition. At one point, Good will be better than SMobile; and at some point, Mobile Armor will take the lead. When nobody is watching, Bluefire will surprise us all and start the process all over again. So, evaluate each vendor on their present product offering as it meets your needs. Although a good roadmap is important, buying on future features is a bad idea.

What follows is a description of the major vendors, their products, and the platforms that they operate on. So, having made all the required legal disclaimers, caveat emptor.

Good²¹

It seems that a major player in the handheld security market is Good.²² We can have lots of fun at the expense of the good people at Good, but I’ll let the wordplay die here.

Through internal development and some clever acquisitions, most notably the purchase of JP Mobile, Good has expanded their product line so that it addresses the problems of secure connectivity as well as endpoint protection.

Good tools integrate into either the Microsoft Exchange or the IBM Domino environments on the server side, and they support Palm OS, Windows Mobile, and Symbian OS on the handheld side.

If you’re an enterprise, you should consider the centralized management component that Good provides.

From a feature perspective, Good provides the following:

• Password management. The user is locked out after successive failed attempts; temporary administrative passwords are supported.

• Feature control. Controls which features the user can change or use.

• Application lockdown. Uses a white list of approved applications.

• Encryption management. Controls the encryption of native, storage card, and specific applications.

• Data erase. The Final Solution wipes data and applications from the handheld.

• Secure messaging. Secures SMS on Windows Mobile and Palm.

• OTA management. Over the air push technology that reduces the number of IT touches of the handheld.

• Centralized management. Provides for policy driven device management.

• Compliance manager. Ensures that systems comply with the minimum level of policy.

Good supports AES 256 and Blowfish 64-, 128-, and 512-bit flavors.

Bluefire Security Technologies

When you first go to the Bluefire Web site, the first thing you see is this message: “Bluefire provides a complete handheld security solution.” If you click the Products tab, you’re greeted with a cute wheel picture that shows all their products. There was no mincing of words or any indication that they’re not focused on mobile handheld devices.

One thing that I found that none of the others were talking about was the fact that their firewall blocks traffic over 802.11, code division multiple access (CDMA), and General Packet Radio Service (GPRS). Another thing that they talked about was logging and alerts. Other features of the Bluefire Mobile Security Suite 3.6 product include the following:

• Firewall. Traditional rules-based type that does IP and port filtering

• VPN. Via Bluefire VPN 2.0

• AV. Bluefire bundles either McAfee VirusScan PDA Enterprise or Symantec AntiVirus Corporate Edition PDA

• Real-time logging. Password attempts, password resets, quarantine overrides, port scans, firewall security level changes, and integrity violations

• Intrusion detection. Almost intrusion prevention, because it blocks some attacks

• Integrity management. Alerts user and generates a log when violations occur (can also quarantine a device)

• Authentication. Enforces power on PIN or password requirements

• Central management. Essential for any enterprise-grade solution

I think the feature that intrigues me the most is the Integrity Manager, because it has the most potential to add a loop-closure mechanism to the handheld endpoint solution.

Another good thing is that their cryptographic module is certified under the FIPS CMVP (Cryptographic Module Validation Program). This is commonly referred to as FIPS 140-2. You can find a complete list of all vendors and their associated products at http://csrc.nist.gov/cryptval/140-1/1401val.htm.

This might be a simple thing (simple is good), but it means that the crypto module has been examined and compared to a published standard (FIPS 140-2) and has been found to comply with that standard. Having been through the FIPS process, I can tell you that it means that the crypto module has been well engineered and shouldn’t be a vulnerability in and of itself. This does not mean that the algorithms are any good; it just means that they’ve been implemented properly.

Like Good, this is an enterprise-grade solution that you should consider if you’re going to deploy handhelds. The only downside that I can see is that Bluefire Mobile Security is only available for Windows Mobile (Windows Mobile 2003 versions of Pocket PC and Phone Edition) and Palm OS (5.2 and 5.3). If you’re running Symbian or Linux, you’ll have to look elsewhere.

SMobile Systems

SMobile Systems,²³ formerly FB-4 Systems, does have an impressive list of supported handhelds and seems to be the only vendor serious about Blackberry AV. If you have a diverse environment, perhaps SMobile deserves a look. But coverage across devices isn’t consistent, with the common denominator being AV protection. For Palm and Blackberry, you’re pretty much constrained to AV products. When you move into the Windows Mobile platform, you can add SMS protection for the phone version. The good news is that if you’re Symbian powered, you get AV, SMS Guard, and PIN Guard.

VirusGuard is pretty much an AV protection application, and although it seems misnamed, PIN Guard adds file encryption and provides some security but seems to be focused on file protection only. This is not an access control mechanism in the traditional sense. Entering the password decrypts the files only.

PointGuard can filter messages by blocking unwanted connections and can use either a white list or a black list to control how SMS and MMS messages are permitted to the handset. PointGuard sports a firewall that can filter data packets on the cellular and WiFi mediums and also has a feature I wish my cell phone had—it can filter incoming calls.

Mobile Armor

Unlike Good and SMobile, Mobile Armor supports more than handheld endpoints. Based on your position, this can either be good or bad. It can be good if the company understands that they need to have a management solution that integrates policy in such a way that all mobile endpoints are addressed effectively and efficiently. It can be bad if the company treats every solution as a stand-alone silo, hoping that through the magic of the merger and acquisition process that a solution can be bought that solves their problem.

Although not listed on their Web site, Mobile Armor has sold a solution called Wireless Suite to the U. S. Secretary of Defense.²⁴ Wireless Suite combines a number of features into one centrally managed solution that provides the following:

• AV

• VPN

• Encryption

• Firewall

• Compliance and remediation

• OTA delivery and management

• Centralized management

Mobile Armor only support handhelds that sport Windows Mobile 2003, Windows 2005, or Palm with their MobileFirewall, VirusDefense, and RemoteNetwork products.

AV Vendors

I was going to give each vendor their own section, but in the end I decided that they didn’t deserve it. All they’re offering is a knockoff of their standard AV product or something that they bought so that they could say that they have an AV product for handhelds.

The upside of using one of these “big players” is that you may already have an investment in their enterprise products, so they might just want to “throw in” some handheld AV the next time you negotiate a contract. I hasten to say that I’m not advocating this approach, but there are those who think a cheap product that shows that they were at least thinking about it is better than nothing at all. Then again, they’re usually not the ones that have to spend the time to manage “yet another console” in the NOC.

Once again, I’m not going to rate AV products, because there are lots of articles that talk about AV products and how well they do their jobs. As a matter of fact, there’s even a comparison of comparison articles!²⁵ Surprisingly enough, there is little agreement about what is best, so I’m just going to list those vendors that have mobile AV products and the name and version of their product:

Nonenterprise Users

I’m mostly focused on solutions that address the problems of the enterprise, but I would be remiss if I didn’t spend a few words talking about single-user solutions. After all, they have the same problems that enterprise users do. Bad people are trying to break into their endpoints or just render them useless.

To start with, you need to enable PIN or password access to your system. If your endpoint has a privacy setting, turn it on. Finally, you should load some form of AV onto the thing. All the major vendors offer some form of handheld AV product, but make sure that you check to ensure that they handle your operating system and hardware (because it can be pretty specific).

Depending on your operating system, you might look at the following:

• BitDefender. A Google search will turn up numerous sites for free software.

• Symantec. Palm and Windows Mobile.

• Tucows. Multiple solutions for various operating systems.

• McAfee. All operating systems as long as they’re Windows Smartphone or Pocket PC.

Web Sites

Thanks in part to the fact that if you put three people together you will get at least two religions and two political parties and a will to express it, numerous sites on the Internet provide a fountain of information about all the mobile endpoints discussed in this chapter. Be warned, however: Although the vendor sites tend to be complete and for the most part accurate, many “independent” sites don’t spend as much time checking their solutions in multiple configurations, but they might have a solution that addresses your particular set of issues. Here is a short list of sites that might prove helpful:

• http://my-symbian.com/main/index.php

• www.simworks.biz/sav/AntiVirus.php?id=home

• www.symbiangear.com

• www.freewarepalm.com (pretty much speaks for itself)

• http://www.tranzoa.com/html/compete.htm (A pretty good list of Palm-focused security programs. It’s humorous to see that they’ve listed a good number of password-protection programs, and listed close to the bottom is a selection of password-defeating programs. It reminds me of a comic I saw called the Wizard of Id. A salesman was trying to sell the knight some arrow-proof armor. When the knight told him that he already had some, the salesman asked, “So, do you want to buy some armor-piercing arrows, then?)

• www.jpmobile.com/default.asp

Closing the Loop

The good news here is that some vendors are actually looking at compliance as a security function in their products. However, it is the traditional compliance model based on a policy that only works with regard to the handheld and the vendor product suite. The network is essentially a packet carrier and nothing else.

A separation exists between the mobile device and the infrastructure that must support it. The network isn’t aware of the device connecting to it, and the mobile device isn’t aware of the network. Until mobile devices can add a basic proportional control to their trust model, we will have to deal with this separation, using other mitigation techniques such as severely limiting the platform choices allowed to connect to and use our enterprise networks.

Key Points

The industry is still grappling with multiple platforms and therefore many multiples of issues. This is creating confusion and frustration for the folks who have to support mobile devices. Unlike the desktop, where a decision could be made to support only one operating system based on the cost associated with procurement and support, the mobile endpoint has a low enough price point and model-specific functionality that two systems are usually the norm.

The Industry Is Not Mature

I would say that the handheld mobile world is where the desktop world was about five years ago. Convergence is occurring in the mobile security industry, but new features and functionality are appearing faster than enterprise security groups can integrate them. Exceptions to security policy that are required during the integration process, missing features, and poorly executed functionality are creating gaps in our security that an attacker can leverage.

Handhelds Are the Next Target

Handhelds have been left alone for the past few years for the same reason that Macintoshes have been left alone: There wasn’t a large enough community of them with the requisite vulnerable application base to be interesting to the malware world. This is going to change.

Networking Woes

The multiple methods of networking create multiple problems for protection. We rely on a series of encryption protocols that have demonstrated at least theoretical, if not real, vulnerabilities to protect our authentication and authorization information. Security has been made optional in most of our networking protocols, and when security is engaged, it’s in a flawed and vulnerable manner.

Solution and Security Divergence

Because each operating system came at the problem from a slightly different perspective, it stands to reason that each solution will have its own set of strengths and weaknesses. As an enterprise begins to address the issues of handheld endpoints, an effort will be made to reduce the number of different platforms supported. The worst-case scenario is to combine two solutions with divergent issues (for instance, Microsoft and Symbian), because the solutions will have to be individually managed.

Enforcement Will Come

Future developments will take advantage of 802.1x simply because networks will evolve to the point where all network connections will be vetted prior to allowing access and it’s cheaper to put the supplicant on the handheld than it is to enter an exception for each and every device. If your endpoint does both cellular protocols and WiFi, you need to have an enforcement point to prevent network bridging. If you think that spam is annoying, just wait until the spammers start going through your mobile endpoints with direct marketing campaigns!

No CLPC Yet

The unfortunate conclusion is that there is no way to close the loop on these devices, so the best we’re going to get is reactive security. The closest we get to this is the Bluefire Mobile Security Suite product, but it still falls short of actual active loop closure, because it is not network aware.

Better PIN programs, some firewalls, AV, and secure communications protocols are all we can expect today. An agent that actively checks the mobile endpoint for compliance and engages in an active exchange of trust information with the network doesn’t exist yet for handheld mobile devices. When we allow a mobile endpoint to connect to our networks, we’re hoping that the reactive measures that we’ve taken are in place and working. Because the mobile endpoint can properly generate a crypto tunnel, we assume that the device is secure. This is a mistake and is similar to the belief that end users are capable of ensuring the security of their systems.