SMS and MMS: The mobile environment has its own unique form of spam based on mobile messaging, in particular SMS and MMS. As any employee who’s used a mobile phone abroad can attest, hordes of spam SMS messages can hound the user to a disturbing degree. What’s even more jarring is that in quite a few places, incoming SMSs are charged to the receiving party, so now the user not only gets an Inbox full of uninvited mobile spam but also has to pay for it.
While the threat vectors (ways to get spam to your device) can vary widely, the intent of the perpetrator(s) remains the same:
• Entice users to part with their money by making grandiose marketing claims.
• Phish for users’ data (or simply trash their devices) by getting them to open the message and click following links that load malware.
Service provider assistance
As mentioned in Chapter 9, the bulk of antispam solutions are provided by the hosting entity (e-mail, service provider, content provider, and so on), and the reason is simple: Identifying and stopping spam before it gets to the device is the most efficient way to counter this threat. In addition, you can identify spammers by utilizing a large aggregation of information — whether in the form of e-mail or messaging — at point-of-service provisioning. Then you can constantly update and hone this database to make the blacklist more effective. Real-time protection can only be achieved by service providers who have the data, computational resources, and means to adopt this approach.
Choosing an antispam solution
A plethora of device-based solutions abound that claim to stop spam in its tracks. While this claim may be more marketing-speak, it’s clear that to protect your users effectively against all the various spam threats, your solution needs a device-based component for spam protection. Although such a component should not be the only antispam solution used in your enterprise, it’s important to include in your tool chest.
As we’ve seen with on-device firewall and antivirus solutions, the choice of a particular antispam vendor is based on a number of factors, but be sure to keep these particular points in mind:
Which smartphones the product supports
Whether the product works with existing antispam solutions in your enterprise
Whether you can get enterprise-wide policy support for the solution
Whether a cloud-based antispam solution is available and works with the on-device component
Human nature being what it is, be prepared for a small portion of your users to fall prey constantly to spammers. If antispam protection is one of your responsibilities, have a well-thought-out remedial action ready to take and a well-articulated recovery procedure in place. It’s time well spent.
Global operator initiative to combat spam
With the widespread advent of mobile spam, the GSMA (GSM association) —the largest mobile consortium of its kind with nearly 800 members — has taken matters into its own hands. It has also kick-started an initiative called GSM spam reporting service whereby users who receive spam can forward those messages to a standardized number (it’s currently proposed as #7726, which spells SPAM on the handset). This is a great way to build a database of blacklists for the spam operators and eventually build an in-network spam-blocking solution. Information about spammers will also be shared among participating members, who will receive correlated reports with data on misuse and threat to their networks.
A successful trial of this service concluded in December 2010, and the service is now available to operators worldwide to join. Customers can report spam they encounter and help build a robust and growing database that can be used by all operators worldwide to stop the advent of this nuisance.
Preventing Intrusion
This section builds on the previous section, “Keeping Devices Safe with On-device Firewalls,” and delves into the dark and murky world of even more intrusive attacks and the armory you have to protect your unsuspecting users: on-device intrusion prevention. But before we delve in, keep in mind that intrusion prevention is computation-intensive. It takes processing power and (you guessed it) battery power.
The more intensive the protection that intrusion prevention software provides for your users, the greater the cost in processing power, which translates into the single biggest fear that mobile users have: battery drain.
In essence, you have to counter intrusive, high-tech attacks against smartphones with low-power-but-effective weapons.
There are three primary mechanisms that provide vehicles with which mobile devices get infected. These are
Installing malicious apps (or seemingly innocuous apps that are actually malware)
Connecting to “untrusted” networks, typically over wireless LAN
Getting infected with spyware using SMS
In the following sections, we examine each of these mechanisms in turn, explaining how an infection happens and how to prevent against it, or at the very least detect and remediate.
Installing malicious apps
From a hacker’s point of view, a smartphone presents a target far more fertile and wide-reaching than what a traditional desktop environment provides. Why? One primary reason — the app store. Thanks to Apple’s revolutionary, easy way to download free and cheap (and some not-so-cheap) apps to smartphones, apps proliferate for every type of smartphone out there. (See Figure 10-5.) With hundreds of thousands of applications available to your employees with a touch of a button (and sometimes a voice command, so not even touch is needed), it’s no wonder they constantly experiment with new applications.
“New” does not necessarily mean “good.” Some applications are written with the same rigor as traditional desktop applications, but most are written with the express intent of getting a quick return on investment. Bottom line: Their creators tend to circumvent good programming techniques, which makes them vulnerable to attack.
Figure 10-5: Apps-in-app-store comparisons — January 2011.
But wait, there’s more; these applications, vulnerabilities and all, could also have widespread access to your employees’ data stored on the smartphones, (contacts, messages, location, photos, and so on). An attacker could compromise those as well — and compound the trouble.
The familiar patterns of attack reassert themselves. One application that was sold as a simple wallpaper program also sent stored telephone numbers to a Chinese server; malicious Trojan Horses have turned up in gaming applications. One hack forced phones to make long-distance international calls, so the phone owner was then heavily charged for the “privilege” of being hacked.
When you’re responsible for a device in the enterprise, you have to include all the associated applications, data, and security posture that go along with the smartphone or device. The relevance of the application explosion to these concerns is that it’s also an explosion in potential smartphone vulnerability, and by extension, any associated data that a smartphone’s apps may have access to is also vulnerable.
So what can you do to prevent against this? The odds are stacked against you — users will experiment with new apps, and malware developers will flock to generate nefarious apps that threaten to expose data, become part of a botnet, or wreak havoc on other devices. Your best tools for prevention are education and communication. Constantly and consistently communicate about the need for users to employ good judgment when downloading apps. Users should follow these practices:
Avoid downloading apps created by unknown individuals.
Check the rating and feedback provided by other users on those apps before downloading any apps.
If the apparent value that an app touts sounds too good to be true, then it probably is. Avoid these apps at all costs.
After you pick your on-device firewall vendor, check with the vendor to see if it provides outbound monitoring solutions as well, which could point to anomalous behavior on the mobile device that could, in turn, provide insight into errant applications.
Connecting to unknown networks
As we have seen repeatedly, the
mobile nature of the smartphone further exposes it to attacks that a fixed device may not be subject to. Here’s why:
A mobile device is always on the go.
Smartphones support a plethora of interfaces.
Bottom line: The likelihood is very high that any given smartphone is connected to one or more wireless networks almost all the time and could be anywhere.
This constantly nomadic existence and propensity for tethering means much greater exposure to unknown networks. Therefore, intrusions are far more likely on these devices than on a fixed desktop.
Typically, these intrusions are in the form of an infected machine in the network. Note that nomadic users connecting to ad hoc networks — sometimes with no encryption on the network — present a very tantalizing target for hackers. Hackers could be on that same network with an infected machine or could have infected a device that they’re controlling remotely from their console with the express purpose of attacking unsuspecting users as they attach to these networks.
So what can you do? Education, education, education. Your users need to follow these guidelines:
Check for the security posture of a wireless network you are connecting to. Is it encrypted (WEP, WPA, WPA2, and so on)? If not, understand that there are risks associated with connecting to this network.
Use the company-provided VPN client to ensure that all traffic is encrypted.
Run the antivirus/firewall client after you log off from the network to look for any potential breaches that may have occurred.
Your panacea is to periodically scan your enterprise-issued mobile devices using the antivirus, firewall, and newer forms of threat-detection solutions as they emerge, assuming your users will be constantly coming on and off public networks. For non-enterprise-issued devices, there is little you can do in terms of exercising control at the endpoint, so your posture should be more defensive, looking for threats emanating from the mobile that could attack the enterprise and using your network-based security solutions to prevent against this. Chapter 9 details enterprise security policies that you can adopt to mitigate this.
Getting infected with spyware via SMS
One of the most popular applications on the mobile device is SMS — and this popularity has not been lost on the hackers! As mentioned earlier — and it bears repeating — spyware is a real threat. One particular variety manipulates SMS messages and exposes them so they can be read by others in the near vicinity.
Given the ubiquity of SMS, it provides a compelling attack vector for hackers to exploit, and an innocuous-looking SMS can result in an inadvertent installation of spyware by the unsuspecting user. This spyware then scans through the contact database of the user and starts spamming the user’s contacts via any means possible, including SMS, e-mail, or even a call to the contact.
So what can you do? Again the same refrain — education, education, education. You users need to adopt these practices:
Be wary of any unsolicited SMS and don’t click any embedded links in the SMS.
A rapid drain in battery usage should serve as a warning that spurious applications may be at play. You need to get the device inspected by a technical expert. If it’s an enterprise-issued device, contact IT; if it’s a personal device, contact the service provider or other reputable third-party.
You need to be vigilant in keeping up with the variety of SMS-related threats prevalent in the mobile device ecosystem. At a minimum, work with the service provider for the enterprise-issued handsets to negotiate a service contract that includes a device replacement policy as well as a service for cleansing infected devices of spyware. The provider may also offer an SMS-related security service that you should consider seriously if there is an uptick in user complaints.
Using Enforceable Encryption
One way to counter spyware is with enforceable encryption — software that uses encryption to obfuscate critical data residing on the device. As noted in Chapter 9, extensible memory on the devices, including removable storage, makes the loss of the device quite dangerous if it contains any sensitive data. One way to mitigate this loss is to encrypt the data on those memory cards; then, if the device is lost or stolen, unauthorized users can’t use a card reader to access the memory card’s data. For the same reason, the use of strong authentication techniques should be mandatory for on-board memory as well. The following sections cover the various types of enforceable encryption you can use to secure your organization’s devices.
Encrypting all outbound and inbound communication
If your goal is to protect the whole data ecosystem, you need mandatory encryption of all outbound and inbound communication — that is, all messages to and from the device. On the face of it, this is no different from the policies that are imposed on the users of laptops and desktops that connect to your network via VPNs (virtual private networks).
There is, however, one important way that mobile device encryption must differ from typical laptop encryption: Your polices must address the ever-expanding set of customized applications that mobile device users constantly download and experiment with.
Although a majority of these applications have nothing to do with you — because they don’t access any enterprise content — they do pose a problem for a potential encrypt all policy. You’d have to transport all that non-enterprise application data, dragging it into the enterprise only to redirect it back to the Internet, as illustrated in Figure 10-6.
Encrypting only enterprise traffic
The obvious alternative to this approach is to discern enterprise applications from non-enterprise applications and intelligently encrypt only the traffic destined for the enterprise. That’s a win-win for everyone, right? Well, not exactly. The solution requires a smart agent to reside on the mobile device and make the decision of what traffic to encrypt and what to let fly, as shown in Figure 10-7.
Figure 10-6: All traffic encrypted and backhauled to enterprise.
Figure 10-7: Enterprise-only traffic encrypted and backhauled to enterprise.
Voice communication exploits
Now, this may be overkill for the average enterprise, but . . . with the widespread adoption of smartphones comes a tendency to use them to conduct mission-critical business. That makes the smartphone a very juicy target for all the vandals out there. And while there haven’t been widespread exploits against voice communication so far, the day can’t be far away when this critical conduit becomes a frequent target for attackers. In fact, as recently as January 2011, a European researcher showed how some bugs he discovered in the baseband chipset firmware of iPhone and Android smartphones could be exploited to ultimately take control of these devices. (Let’s just hope the wrong people weren’t taking notes.)
More uneasy news: Ralf-Philipp Weinmann, a researcher at the University of Luxembourg, demonstrated an exploit he created that turns on the auto-answer feature of a smartphone and then uses it as a remote listening device.
With mandatory two-factor encryption on a smartphone, the auto-answer feature would work only when calls from trusted third parties were answered. And then the communication would be encrypted, so the hacker couldn’t decipher the conversation anyway.
You have to depend on the device manufacturer and the OS vendor to supply the supported encryption algorithms, but at least it’s a mature technology. Most of these new devices offer pretty comprehensive feature support, so it shouldn’t be a problem area.
Using carrier-provided voice encryption
Another type of encryption starting to become prevalent is carrier-provided voice encryption. Yes, I know what you are thinking: “Isn’t there some form of encryption already provided by the radio technologies in the network?” Good question — and the answer is yes. Although such embedded encryption has been robust for years, lately it’s starting to show signs of weakness. In fact, in 2009, Karsten Nohl cracked the famed A5/1 GSM encryption. But what took the cake was the modest level of technology it took to crack the encryption scheme — RF equipment, p
atience, and a $500 laptop!
To put this event in context, A5/1 is the most common encryption technology. It’s used by over 80 percent of subscribers worldwide.
This is the point at which the additional encryption provided by carriers starts to make sense, specifically for your most critical users (chief-level officers, sales heads, and so on). With sensitive data at stake, adopting voice encryption is not too outlandish.
The most common way to implement voice encryption is to use a carrier-provided two-factor encryption solution:
Each smartphone gets a hardened, self-contained crypto engine inserted into its microSD slot.
• The phone gets the strength of additional hardware authentication.
• Members of a defined group of trusted users can exchange encrypted calls.
• You can manage this capability over the air.
Users can easily place and receive encrypted calls by integrating with the mobile phone’s standard operation and address book.
• This security function is now on-demand.
• Mutual authentication and end-to-end encryption make a high-security call mode possible.
Case Study: AcmeGizmo Endpoint Security Deployment
Back at AcmeGizmo, Inc., Ivan the administrator has run into a serious issue. One of the executives downloaded some applications to his Android device, and as it turns out, one of those applications was a phishing application made to look like the Customer Relationship Management (CRM) application that AcmeGizmo uses. As a result, the bad guys who posted the app got their hands on the executive’s login credentials.
Mobile Device Security For Dummies Page 25