WITH THE POPULARITY OF SMARTPHONES, it’s no surprise that cybercriminals have shifted their focus to them, creating a new battlefield for IT security. Mobile malware presents some unique challenges, however, that make this more than just another front in an ongoing war.

One troubling aspect of the smartphone and smart-device culture is that users trust links and download apps without a second thought. This greatly increases the likelihood of users being subject to malware and other attacks. Combine this with the fact that there is now a free flow of devices between work and public networks and suddenly, the IT department is faced with a whole new set of challenges, the scale of which dwarfs the malware issue on company-owned PCs and laptops.

This chapter examines mobile malware, exploring not just where it is most likely to exist but also what forms it takes and how it finds its way onto devices. It also looks at mitigation strategies that will help prevent malware from finding its way to corporate resources.

Malware on Android Devices

When it comes to malware, cybercriminals have focused their efforts on the market leader, Android. In fact, 90 percent of all malware targets the Android operating system (OS). Android competitors, such as Apple iOS, Windows Phone, Symbian, and BlackBerry, barely register on the scale. Despite this obvious threat, Android has built up huge market share in the consumer sector, capturing more than 80 percent of the global market at the time of this writing.

Although Android’s dominance in the market is a factor in why cybercriminals have targeted that operating system so vigorously, it is not the only one. The main driver is that the Android OS is an open source system. This is in contrast with Apple iOS and Windows Phone, which are closed systems.

Both Apple and Microsoft lock down and secure their products. That is, they require their customers to obtain applications from their own proprietary marketplaces—the App Store and the Windows Store, respectively. In contrast, for Android, Google opted for an open system, whereby customers could obtain applications from any number of outlets—secure or not. This decision resulted in more choices and greater flexibility for users, but it also opened up the Android OS to malware.

This is not to say that the Android OS is inherently unsecure. Although it does have a few known vulnerabilities (fewer than Apple’s iOS), the Android OS is actually very secure and is not inherently vulnerable to malware. The real reason for Android’s susceptibility to malware is more a function of software fragmentation among vendors, poor user administration, and poor update-management practices.

All OS software is very complex. Due to this complexity, vendors, users, and hackers regularly find security vulnerabilities, even after the software is released. When these vulnerabilities are found, the race is on to uncover the root cause, code a fix, test it, and distribute it. Then it’s up to users to update their devices—which they may or may not do. The lag between the time a vulnerability is found and when it’s patched is a time of increased risk, as cybercriminals look to exploit the vulnerability. This is hard enough for developers in closed systems to mitigate. For Android, it’s especially difficult.

Consider an example. Suppose Google becomes aware of a vulnerability in its Android software and issues a patch. In a closed system, the patch would be delivered directly to users, who would then adopt it at some normal rate. However, because Android is an open source OS, Google must first release the patch to the many hardware vendors whose devices run the operating system. These vendors must then determine if and how the patch applies to their software. For example, they may have modified the base OS, so implementing the patch may require additional development on their end, not to mention all the necessary testing. Only after that occurs can these various patches be released (at varying rates) so users can adopt the fix.

Of course, Android works not only on smartphones, but also on tablets and phablets (devices that are somewhere between a phone and a tablet), each with its own diverse software features and hardware configurations. This is wonderful from an innovation and production perspective, but it creates even more security vulnerabilities due to even more complexity. In contrast, Apple can make global updates available to its user base via download, as the code will be identical on every phone, tablet, and phablet. This is a huge advantage in terms of closing vulnerabilities.

Google does not have that option. Instead, as mentioned, Google must identify vulnerabilities and engineer security patches, which it makes available to the many device manufacturers that host Android. The manufacturers must then study the update for compatibility with their versions of the Android code and, if necessary, engineer the patch to fit. Compounding the problem is the fact that hundreds of manufacturers use Android, some of whom support only limited versions of their modified code—in some cases, only those models still in production or devices less than two years old. As a result, there are many devices for which patches may not be available, meaning that many devices remain susceptible to the vulnerability. For those vendors that do roll out upgrades, there is the problem of distributing them through their partner network. Partners must perform regression testing and confirm that the updates are not harmful to their customized code before releasing them. It takes time to make these patches available for end users to download, even on the latest phone models.

For the bad guys, this is ideal. This lag provides them with a window of opportunity to exploit the vulnerability. The longer the window is open, the more lucrative the vulnerability may be. This explains why there is a disproportionate focus on Android. It’s not because the core OS is less secure than its competitors. It’s because the open system through which it is distributed, modified, and supported results in greater complexity, which makes it harder to mitigate those vulnerabilities that do exist. This, along with the fact that it takes more time to distribute fixes, gives cybercriminals more opportunities to exploit vulnerabilities.

Still, this is only part of the story. The rest is that unlike the walled garden approach taken by both Apple and Microsoft, Android vendors allow developers to distribute software through a wide variety of channels, and they do not police these applications. This is ideal for cybercriminals. Vulnerabilities that remain active on devices and a lack of application policing (at least compared to Apple and Microsoft) have provided a profitable environment in which cybercriminals can ply their trade.

Criminal and Developer Collaboration

The large number of active smartphones operating on older, unsecure versions of Android is a major temptation for both criminals and rogue developers. Consequently, security experts suspect that there is broad collaboration between cybercriminals and dubious developers who focus their attention on Android malware—potentially unwanted applications (PUAs) and commercial mobile adware (madware). Not surprisingly, the top types of Android malware, as reported by the security company Sophos, are financially focused. As of 2013, these malware categories, or families, included the following:

•  Andr/BBridge-A—This is a family of malware that collects phone numbers, contact IDs, and subscriber identity module (SIM) card information, along with the phone model and OS version of the breached device.

•  Andr/FakeIns-V—This malware targets and damages system files in such a manner that it becomes impossible for end users to gain control of their systems. This family of malware badly damages Android and Windows systems by blocking users’ searches and delivering them to false Web sites via a proxy.

•  Andr/Generic-S—This malware includes backdoor Trojans, fake applications, and premium-rate Short Message Service (SMS) messaging.

•  Andr/Qdplugin-A—This is a Trojan horse that can steal information from the infected device.

•  Andr/Adop-A—This is an advertising application that creates shortcuts and advertising notifications.

•  Andr/Boxer-D—This malware appears to be an installer for other software. When activated, however, it initiates premium SMS messages.

•  Andr/SmsSend-BY—This is a premium SMS messenger.

•  Andr/DroidRt-A—This is a privilege-escalation application that allows other related apps to gain privileges to system functions.

•  Andr/SmsSend-BE—This is a premium SMS messenger.

•  Andr/FakeInst—This is a false installer that sends premium SMS messages.

Bear in mind that the Android ecosystem is very fluid. This list is meant to illustrate the focus of cybercrime at a specific time rather than to serve as an enduring list. There are thousands of variants of these categories, which shift on a weekly basis. For example, during the early first quarter of 2014, the number of families of malware had risen to 369—not 369 instances, but 369 families—each with dozens and even hundreds of variants.

More worrying is that over the past few years, cybercrime gang structure has morphed, taking on more of a hierarchal pyramid structure. This is in great contrast to the fabled perception of the socially inept hacker working alone in a dark basement. The new hierarchy consists of an army of enablers or distributors of software payload or malicious code, comprising the core of these dynamic “organizations.” Atop them are divisions of technical analysts and financiers of various projects. These organizations are formidable in their scale, expertise, and ability to execute.

For obvious reasons, the exact makeup and strategies of these groups are not entirely known. What is known is that the groups tend to focus on the following goals:

•  Claiming personal or confidential information by gaining access to a phone

•  Gaining control of phones for other attacks, such as launching distributed denial of service (DDoS) attacks to cause business disruptions or sending premium SMS messages for financial gain

•  Gaining access to GPS and other location information to sell to third-party advertisers

•  Gaining control of phone file systems to steal data, photos, and the like, or to lock out the user for ransom

•  Gaining control of features, such as the camera and microphone, for surveillance or location tracking—prevalent in commercial and business espionage and cyberstalking

In some cases, these groups focus on a single target over time in an advanced persistent threat (APT). These continuous, coordinated attacks usually target organizations and/or nations for business or political motives.

Cybercriminals go about achieving these goals through a variety of techniques, which target the inherent risks that apply to mobile smartphones. These risks include the following:

•  Unsecure data storage

•  Weak server-side controls

•  Insufficient Transport Layer protection

•  Poor authorization and authentication

•  Improper session handling

•  Data leakage

•  Poorly implemented encryption

•  Sensitive data disclosure

Sensitive data disclosure is a common aim of malware, PUAs, and many “genuine” applications that are not considered malicious but still harvest information, such as location, contacts, photos, and other sensitive data. Furthermore, many benign mobile apps are very talkative, commonly exchanging data with third-party application programming interfaces (APIs)—especially advertising and marketing networks. In short, there is a near constant flow of information to known and unknown recipients from smart devices.

Interestingly, the main mobile malware threat today is not credit card theft or device control, but premium SMS hacks. At first blush, this may be surprising, given what makes the headlines. Nevertheless, it does make sense when one looks at the numbers.

For example, a single credit card can be sold on the black market for approximately 60¢. Compare that to a premium SMS Trojan. Cybercriminals often deliver their malware through an affiliate program, paying people a commission to deliver the payload. Some affiliates make up to $10 per successful SMS Trojan activation. Additionally, malware that sends premium SMS text messages can provide an ongoing revenue stream—at least until the unfortunate victim notices the charges in his or her mobile phone bill or credit card statement. In fact, premium SMS attacks are so lucrative that entire ecosystems have formed to support them, complete with developers, distributers, partners, and affiliates. These ecosystems closely parallel legitimate software ecosystems, the primary distinction being that they support a criminal enterprise.

Madware

As mentioned, madware is a form of very aggressive adware that is prevalent on mobile devices. Due to the way the “free application” business model works on the Internet, developers consider madware to be not only harmless, but a legitimate aspect of application behavior. Although some free applications that use advertisements as a revenue source are legitimate and benign, others run background processes that access GPS information, scan address books, and send out stolen data via HTTP to third-party APIs. Some also track and share location details, browsing histories, and contact lists, often with the phone owner’s unknowing permission.

Of course, developers maintain that the terms of use have been explicitly stated and that the user’s permission has been granted. However, developers also know that very few users read the entire terms and conditions, which are typically very long and filled with complicated language. Indeed, it’s likely that few users ever give these agreements more than a glance as they scroll through to the Accept button. As a result, application vendors have begun to take more and more liberties with application permissions. Indeed, in recent studies of Android applications, researchers found that many applications—even some Top 20 Google Play applications—request far greater access to the phone’s features and data than is justified.

One could argue that users have a responsibility to read and understand the terms and conditions before agreeing to an application, and that in a “buyer beware” market, perhaps they deserve what they get if they don’t. This is debatable. Regardless, when users allow these apps on devices that hold company data and access company resources, it becomes the IT department’s problem. Knowing users’ tendencies, it’s in IT’s best interest to monitor app stores and make users aware of applications with excessive or unwarranted permissions.

Excessive Application Permissions

A recent study by SnoopWall on the threat assessment of the Top 10 Android flashlight apps revealed that all the flashlight applications they tested obtained access and information well beyond their needs. One naturally wonders why developers would ask for permission that their applications don’t require to function. It’s especially suspicious when refusal of these permissions seems to have no effect on the execution of the application, which would indicate that access to these resources is unnecessary.

Consider the scale and scope of permissions and access developers request to run these flashlight applications. Here’s a list from one app:

•  Retrieve list of running apps—For a flashlight application, this is a dubious requirement.

•  Modify or delete contents of your USB storage—Why would a flashlight application want to delete files on a USB device? Other applications, such as a camera interface or music system software, may have a legitimate reason to delete uploaded or downloaded files, but it’s hard to make a case for a flashlight doing this.

•  Test access to protected storage—This is dubious. Why would a flashlight application need to read or write to protected memory outside its container?

•  Take pictures and videos—This is a rather frightening ability for a flashlight if it’s done without user notification.

•  View Wi-Fi connections—This is another unnecessary permission for a flashlight.

•  Read phone status and identity—A request to read the phone status is a yellow flag, but this one does have a genuine use. Developers need to retrieve this information for analytics, to identify the phone model, and to identify the OS on which end users are using their product.

•  Receive data from the Internet—Most applications request this access because they are client/server models with the main application residing on a remote server. The danger here is that client-side injection could cause security issues. For a flashlight app, this may be needed to receive advertisements.

•  Control flashlight—This permission seems legit.

•  Change system display settings—This seems acceptable, as the flashlight application needs to change screen display parameters.

•  Prevent device from sleeping—This may be a necessary function for a flashlight to prevent it from shutting off while in use.

•  View network connections—This is yet another unnecessary request for permission.

•  Gain full network access—This is likely a request for unrestricted Internet access, which hints at uploading personal information.

•  Approximate location (network based)—This is an obvious requirement for adware.

•  Precise location (GPS)—This is totally unnecessary.

As you can see, this flashlight app requests 14 permissions. Of the 14, only four have anything resembling a legitimate need to operate the application. In general, a long permission list like this should raise a red flag—whether in Google Play, the App Store, or the Windows Store and on the phone itself when the user reads the terms and conditions of use. Unfortunately, this is not possible with a jailbroken or rooted device, as the security permissions will likely have been circumvented.

Objections to requests for excessive permissions do not always stop malware developers. They use a variety of tricks to fool the OS security. One way to ask for a long list of permissions without raising an alarm is to split the application into modules, each requesting only one or two permissions each. The first module typically asks only for a couple of innocuous permissions but also requests permission to download updates. As each subsequent module is constructed, it is sent as an update. These often pass undetected by the OS security. Of course, the phone user must permit each download, which might raise concern (if the user is even paying attention).

Malware on Apple iOS Devices

Unlike Android, there appears to be very little iOS malware out in the wild at the time of this writing. Perhaps this is testimony to Apple’s very secure closed system and focus on application provenance. Surveys suggest, however, that roughly 50 percent of iPhones in China have been jailbroken. If that figure is correct, it is surprising there are not more Apple-based malware apps going around.

That said, just because malware is rare doesn’t mean it doesn’t exist. One example is the flashlight app noted in the previous section, which requested excessive permissions, including access to sensitive features. While there is no evidence to suggest this flashlight is indeed malware, it certainly looks to be a PUA that contains unwanted and perhaps aggressive advertising. It also violates the user’s privacy by seemingly sending location details to an advertising network.

Although malware targeting Apple iOS is not common, there are proven cases of it. Recent research by Kaspersky Lab revealed a spy Trojan called Xsser mRAT that targeted iOS 7 in China and Hong Kong. Kaspersky discovered that the infection was delivered through contaminated PCs or Mac OS malware. Typically, the malware first targeted the PC or Mac, where it lay dormant, waiting for an iPhone to be attached via USB. The Trojan was then activated via the remote control system (RCS), at which point it attempted to silently jailbreak the device and infect the iPhone. This sophisticated iOS Trojan could then discreetly conduct its spying activity with little impact on battery performance. It could perform many functions, including tracking location via GPS coordinates, stealing personal data, taking photos and video, and spying on SMS and other messages.

However, like other forms of malware, Xsser mRAT had limitations. One was that the phone had to be jailbroken. Typically, if a user keeps his or her device up to date with the latest (approved) version of iOS, the iPhone is far more likely to be protected. Of course, this assumes that the user (or another form of malware) does not jailbreak the phone. As noted, roughly 50 percent of iPhones in China have been jailbroken—many of those with sponsored malware from APT groups or syndicates.

Other, older iOS malware exists, but some are threats only on jailbroken devices. These are outlined in Table 15-1.

At the time of this writing, only 11 known iOS malware instances are found in the wild, and only a few of these were found inside the App Store. This is negligible when compared to the thousands of variants of Android malware, but it does show that while Apple malware is rare, it’s not a myth—it’s more a narwhal than a unicorn.

Malware on Windows Phone Devices

At the time of this writing, there have been no confirmed instances of malware targeting Windows Phone. This may be due in part to its low market penetration in both the consumer and business markets rather than its superiority in terms of its operating system or provenance model.

That said, Windows Phone has some security measures in place that make it very difficult for typical forms of malware to take hold. These measures include the following:

•  A requirement for digitally signed applications—This prevents tampering and repackaging.

•  Prompts for permissions whenever an application requires access—This is as opposed to requiring authorization only at install for all permissions with a single click.

•  Not allowing silent calls or SMS text messaging—The user is always notified when there is an outgoing communication.

In combination with the Windows proprietary OS and application provenance, these restrictions not only limit the ability for malware to reach Windows Phone devices, they also limit the ability of malware and madware to execute their various schemes in the event that such software does reach a device.

Mobile Malware Delivery Methods

When it comes to mobile malware, it’s one thing for hackers to be able to use available tools to construct a mobile exploit package. It is quite another to deliver it successfully to the target. This is why cybercriminals find value in organized groups. With enough teams attempting to deliver various payloads, it doesn’t matter what information they collect through the spyware. It seems the more the merrier. Once the payloads are delivered, it is up to the analysts to sort through all the data and find a way to monetize the information collected. The job of the distributor or enabler is simply to deliver the exploit payload to infect as many devices as possible and then harvest the maximum amount of data.

Cybercriminals often deliver their malware through an affiliate program. That is, they pay people a commission to deliver the payload, just as with any other legitimate affiliate program. In fact, commercial software companies use the same model. The tactics used by affiliates vary considerably, but they tend to rely on social engineering to send targets to infected Web sites for drive-by attacks. A Web attack on an Android or jailbroken Windows Phone or Apple iPhone is one of the easiest ways to infect a smartphone.

Other mobile malware delivery methods include the following:

•  Binding an application to a genuine popular free app available in Google Play, the App Store, or the Windows Store—Unless done well, this effort is likely to be short lived. This is especially true with the App Store, which is manually curated. That is, Apple employees check the authenticity and integrity of all applications in the store.

•  Loading malware to the many third-party stores—These are plentiful for Android phones as well as for jailbroken iPhones and Windows Phones.

•  Creating a Web page infected with a drive-by download—Cybercriminals then use a variety of means to get users to visit and click on the page (for example, offering “free” merchandise).

•  Using a hybrid attack with a dual payload to target both PCs and smartphones—If the victim device is a PC, it will activate the PC version of the code and wait for a smartphone to be connected via the USB port. When the smartphone is connected, the malicious code on the PC will try to jailbreak the phone and inject a Trojan payload.

•  Using social engineering—The idea here is to trick targets into using premium SMS to connect to infected sites, where they may download a Trojan payload.

•  Creating malicious QR codes for malware distribution—A QR code can represent as many as 7,089 numeric or 4,296 alphanumeric characters. These are very popular with marketers and poster advertisers, and can also be used to distribute malware.

Mobile Malware and Social Engineering

Not a day goes by in which cybercriminals don’t collaborate to discuss how to attack what is most often the weak link in corporate network security: the end user. These are typically employees with no idea of security awareness, who also happen to be equipped with powerful and intelligent smartphones. Compounding this issue is the fact that cybercriminals have proven to be highly collaborative. Despite being a loose collection of syndicates and individuals, new exploits are communicated throughout these informal networks much more quickly than information is spread in many corporations with well-defined information-dissemination processes.

Captive Portals

The most common tactic cybercriminals use to take advantage of users involves the use of a captive portal. That is, the cybercriminal launches and advertises an attractive free Wi-Fi portal, realizing that many people will join any hotspot—for example, in a mall or supermarket—if it is free. Many of these same users will also click on ads that offer too-good-to-be-true deals or giveaways. This takes them from the captive portal to a phishing Web site, which uses JavaScript (or other means) to perform a drive-by browser attack. This JavaScript will run on the user’s browser to implant a Trojan, which will then load malicious code.

Drive-By Attacks

Drive-by attacks involve injecting malicious code into Web sites to exploit vulnerabilities in browsers. The result: A user’s device can be infected simply by visiting a site. Drive-by attacks can occur not only on hacker Web sites specifically created to launch an attack, but also on legitimate sites that have been hacked and infected with malicious code.

Drive-by attacks are launched when a user visits an infected Web site. In cases where a site has been specifically set up for an attack, there is typically an effort made to entice a victim to visit the page (for example, by offering free items or services). Remediation methods include disabling JavaScript (when feasible) and setting preferences to allow Java and Flash to run only on trusted sites.

Clickjacking

Even if users manage to avoid a drive-by attack, they might still fall for clickjacking. The purpose of this exploit is to confuse the victim by creating a Web page with a background of invisible frames. The attacker then superimposes another set of frames or buttons that the victim can see. If the victim clicks on a frame button once or twice and nothing happens, he or she will tend to swipe the mouse around, clicking indiscriminately, hence triggering the exploit.

Likejacking

The likejacking exploit is usually very successful on smartphones due to their smaller screens, which are more difficult to see. In this case, an invisible frame or button is placed directly on top of a Facebook Like button. Clicking the button works as normal, but also infects the device.

Plug-and-Play Scripts

The small screen on a smartphone also makes it difficult to use the navigation controls. Malware developers have found this to be to their advantage. By using JavaScript (a hacker favorite), they can cause any mouse click to activate the target button, which will infect the device. If the user inadvertently clicks in the wrong place (easy to do on a smartphone), it causes a malware script to run.

Browsers are not the only weak link, however. There are far more vulnerabilities in plug-ins and scripts. Users should be advised that if they do not need plug-ins, they should switch them off. This helps to reduce the attack surface area. The main takeaway, though, is to switch off scripting in the browser.

Mitigating Mobile Browser Attacks

Web site attacks on mobile browsers are commonplace, and many are rather sophisticated. As a result, you must make sure any browser on a smartphone is hardened to protect against client-side threats. Best practices include the following:

•  Practicing due diligence—This is especially true when downloading Android apps because Android phones are susceptible to malware.

•  Using HTTPS when entering credentials—If a site doesn’t offer HTTPS, users should think twice before keying in private or sensitive data. HTTPS is indicated by the site’s URL, which should begin with HTTPS://, or sometimes by a security lock icon.

•  Maintaining robust anti-malware software—Ensure it’s always up to date and scans often.

•  Blocking pop-ups (via the device’s Preferences screen)—This prevents malicious pop-ups, which are attack vectors for many forms of malware, from appearing.

•  Checking app permissions—Always check an application’s permissions before downloading and installing it to make sure they are relevant.

•  Removing unwanted apps—Surveys have revealed that 81 percent of downloaded applications were only used once. If you don’t use an app on a regular basis, it’s best to delete it.

•  Switching off auto-fill dialog boxes, JavaScript, and HTML5—Some advance features, such as auto-fill, are meant as time savers, but can be exploited because they store personal information in the browser caches. Features such as JavaScript and HTML5 can be used in drive-by attacks, so it’s best to disable them when possible, turning them on only as needed for trusted sites.

•  Enabling fraud warnings—These prevent users from visiting phishing sites.

•  Clearing the cookies, history, and cache—Regularly deleting your browsing history can prevent the theft of sensitive data by spyware and adware.

Mobile Malware Defense

Malware and PUAs are not easily distinguishable. Therefore, the common advice to users is to run anti-malware and antivirus software on their computers. So why aren’t these services standard on mobile devices?

The problem with antivirus and anti-malware tools is that they have the same restrictions as any other application—they are restricted to their sandbox. Unfortunately, unless these services have privileged access, their usefulness is limited. Testing on some products found antivirus software for Android devices had a detection rate of less than 10 percent, and that versions for iOS and Windows Phone were merely placebos. The same holds true for anti-malware apps—the strict application isolation that exists across all OSes makes them ineffective. To work, an antivirus application would have to break out of the sandbox. This would require the application to run as root, which would of course open the device to many new forms of malware—hardly worth the trade-off.

If anti-malware and antivirus software are not the solution, what is? The answer lies in many of the best practices already discussed. In review, they are as follows:

•  Providing security-awareness training for end users

•  Prohibiting applications from noncertified developers and third-party marketplaces

•  Restricting users to vetted and authorized marketplaces

•  Prohibiting the unlocking or jailbreaking of devices and the side-loading of apps

•  Policing third-party downloads

•  Adhering to policy using mobile device management

Mobile Device Management

A key strategy for protecting mobile devices in the workplace is to have a bring your own device (BYOD) policy and a mobile device management (MDM) system. Following MDM best practices for supporting BYOD smartphones and tablets in the enterprise will go a long way toward mitigating the risks.

Initially, it’s important to address the basics: controlling passwords, encryption, remote wipe, and data containers. You must address these essentials by setting a policy that includes requirements for strong passwords, auto-locking after five minutes of inactivity, auto-wiping after 10 consecutive failed login attempts, and segregating business data in its own isolated container.

Also, you must develop a lightweight inventory system and allow administrative access to those who require it. This includes members of your human resources team, who will need to reclaim mobile devices during exit interviews. This practice also alleviates the burden on the IT department. For example, giving help-desk employees access to the inventory enables them to access devices via remote control to troubleshoot and repair them. Another great timesaver is to empower users to enroll their own devices, lock and wipe devices if they have been stolen, reset their own pass codes, and locate lost devices.

Penetration Testing and Smartphones

When it comes to mobile malware defense, it’s a best practice to set realistic policy and security templates for each type of authorized device, and to become familiar with the devices used and their vulnerabilities. The best way to do this is to test the security measures in place via penetration testing (pentesting) on sample phones or emulators.

Pentesting smartphones involves the following stages:

•  Recon—During this stage, the tester gathers information by identifying the types of mobile devices on the target network.

•  Scanning—After the types of phones have been identified, the scanning phase can proceed. When scanning for mobile devices, the tester looks to identify networks sought out by mobile devices.

•  Exploitation—In the exploitation stage, the tester actually captures and gains control of the mobile device.

•  Post-exploitation—During the post-exploitation stage, the tester inspects the phone for sensitive data in common areas such as notes as well as SMS and browser history databases. The tester might also search the device for stored passwords in the keychain or payloads such as a back door, depending on the scope of the project.

As always, when pentesting on corporate networks, it is necessary to obtain permission in writing from senior management. Equally important is having the right tools for the job. The Smartphone Pentest Framework (SPF) is a good option, as it runs on the Kali Linux platform. The SPF can identify and port-scan a victim smartphone and look for vulnerabilities such as the default Secure Shell (SSH) password for jailbroken iPhones. Additionally, SPF features a range of remote, client-side, and social-engineering exploits.

When pentesting a smartphone, the tester first uses basic social-engineering techniques to construct a convincing SMS with an embedded link. All that is required is to get the victim to select the link, which will take him or her to a Web page. The level of success is proportional to the diligence of the social-engineering and information-gathering process. The user must trust both the source and the link. If the SMS is well crafted and the user falls for the trap, his or her device’s browser will be directed to a SPF-controlled Web page running a client-side attack.

The exploits used will depend on the goals. A typical pentest objective would be to download to the phone via the compromised browser an SPF agent with a variety of payload options. The tester could then interrogate the phone and receive data back in HTTP or SMS replies. There are also remote-control functions to demonstrate SPF’s control of the device, such as taking a picture or sending a text message.

Another example of an Android smartphone pentest tool is Armitage. A graphical user interface (GUI) for Metasploit, Armitage is used to create an Android application package that carries a malicious payload. In this case, the payload is a simple reverse connection back to the tester’s console. Getting the user to launch the application requires either a client-side exploit on the Android’s browser or, more likely, some clever social engineering to entice the user to download and open the app. When the user is reverse-connected to the tester’s console, the tester establishes a connection to the compromised Android phone. This only creates a reverse connection, however. Another exploit needs to accompany it in the payload—perhaps a remote-control agent. However, even if these methods are not taken to their logical conclusions, if nothing else they can prove to be a good assessment of users’ level of security awareness.

CHAPTER 15 ASSESSMENT

1. Malware tends to be evenly distributed across Android, Apple iOS, and Windows Phone devices.

A. True

B. False

2. Which of the following describes Android-targeted malware?

A. It exists because of a weakness in Android code.

B. It is easy to get through Google Play.

C. It mostly exists due to software fragmentation.

D. It is not that big a problem.

3. In what way are the top categories of mobile device malware financially focused?

A. They target financial and banking apps.

B. They target banks directly.

C. They extract data or services that are easily monetized.

D. All of the above.

4. Madware often tracks people illegally by pulling data from a device without the owner’s knowledge or consent.

A. True

B. False

5. Mobile malware tends to focus on which of the following?

A. Gaining control of phones to launch DDoS attacks or send premium SMS messages

B. Gaining access to the ports that control GPS and other location information to sell to third-party advertisers

C. Gaining control of phone file systems to steal data, photos, and so on, or to lock out the user for ransom

D. All of the above

6. Any application that harvests data from applications or storage is considered to be either malware or madware.

A. True

B. False

7. Which of the following describes Apple iOS malware?

A. It is proportionate to the company’s market share.

B. It primarily targets iPhones that have been jailbroken.

C. It is a growing problem in the App Store.

D. All of the above

8. Which of the following does not explain the lack of Windows Phone malware?

A. Windows Phone code is more secure than Google Android code.

B. Windows has a policy of preventing silent calls and SMS messages.

C. Windows Phone uses application provenance controls.

D. Windows Phone uses a per-use permission policy for application permissions.

9. Social engineering does not play a prominent role in mobile malware.

A. True

B. False

10. Which of the following is an example of a malware-delivery technique?

A. Captive portals

B. USB exploits that jailbreak phones when they are connected to PCs

C. Likejacking

D. All of the above