THERE ARE MANY DIFFERENT RISKS associated with smart devices, including lost data from lost or stolen devices, access and device control issues, and malware, to name a few. Another risk is the fact that smart devices are also wireless client devices, and as such present risks to wireless networks. Whether used in unintentional acts by unknowing users or deliberate attempts to gain unlawful access or otherwise sabotage a wireless network, smart devices present an entirely new arsenal of potential attacks for which IT security teams must account. This chapter looks at the risks that mobile clients present to corporate networks, as well as the tools and techniques used to mitigate these risks.

Scanning the Corporate Network for Mobile Attacks

The advent of mobile devices, including smartphones and tablets, and their subsequent prevalence in the enterprise due to the bring your own device (BYOD) trend, have created a huge security issue. Data leakage is but one concern, as these devices open up other attack routes for cybercriminals: back doors. Employees who bring jailbroken, rooted, or otherwise compromised devices into the network create a gateway for cybercriminals to exploit not only the devices but also the networks to which they are attached.

Security professionals must regularly scan the network for unauthorized smart devices. Ironically, that’s just what cybercriminals do when gathering information prior to an attack. Therefore, scanning a wireless network is both an essential administrative function and a hacker activity. Gathering information on the network is an essential tool for administrators and hackers alike, and they use many of the same tools and techniques. Both are looking for weaknesses in the infrastructure; only their intentions differ.

Complicating the matter for IT teams is the fact that they must scan not only known networks, but also unauthorized ad hoc networks. These temporary networks have become a major source of threats and have great potential for abuse due to the ease with which smart devices can establish them.

The good news is that mobile phones and Wi-Fi equipment manufacturers have worked hard to reduce the attack surface (the sum of all potential attack routes) for potential cybercriminal attacks through their devices. In doing so, they have greatly reduced the number of security vulnerabilities available to an attacker—assuming, of course, that users have not intentionally or unintentionally undermined these efforts. This leads to a key aspect of mobile security: security awareness.

Security Awareness

One problem with technologies aimed at consumers is that developers often overestimate the general public’s technical literacy. For example, when it comes to Wi-Fi security, it’s a good bet that few members of the public understand the difference between Wired Equivalent Privacy (WEP), Wi-Fi Protected Access 2 (WPA2), and Lightweight Extensible Authentication Protocol (LEAP)—let alone understand the implications of not understanding. As a result, despite warnings about potential hacks on unprotected wireless systems, many access points remain unprotected or use outdated security protocols.

This same problem exists with smartphones and tablets. Indeed, it may be worse, as users may understand the need for security on their Wi-Fi router but remain oblivious to the need for securing their mobile phone or their tablet’s Wi-Fi connection. This makes exploiting mobile devices very attractive to cybercriminals.

From a security perspective, this lack of awareness on the part of the public is worrying. After all, how can a network be secure if authorized users—now equipped with intelligent networked accessories—have little or no concept of security, or are willing to circumvent security measures in a cavalier fashion? For this reason, the IT department, with the full support of management, must deliver security awareness training to employees. In addition, employees must understand the security policies, such as the BYOD security policy, before bringing their devices onto the company network.

This problem is compounded by today’s prevalence of smartphones, tablets, and wearable devices on the network. Gone are the days when there was a roughly 1:1 ratio of employees and devices. With BYOD, employees might bring to work a laptop, one or two smartphones, a tablet, and a smart, Wi-Fi–enabled watch, of which only one or two devices may be authorized.

The real problem is that those unauthorized devices regularly leave and re-enter the premises as the employee comes and goes. If a device is unauthorized, it likely uses default wireless settings and attempts to establish a wireless connection with every Wi-Fi network it encounters as the employee moves around. The employee’s device might promiscuously connect to any of these networks, whether it’s a free hotspot from a legitimate source (which can still be compromised) or a hacker-deployed device. Even if the device does not promiscuously connect, the employee who owns it may seek out and connect to a network, unaware of the dangers. This is normally not the concern of IT, but when the employee returns to the company, bringing his or her newly infected—and perhaps highly contagious—smartphone, it becomes IT’s problem.

Keeping track of authorized smartphones and tablets on the network is hard enough without having the additional burden of tracking down unauthorized devices connecting through mobile hotspots or ad hoc connections, or piggybacking on Bluetooth connections. Therefore, even with strict enterprise mobility management (EMM) in place, administrators must still regularly scan the wireless network and assess it for vulnerabilities, noncompliance with security policies, and vulnerability to malicious attacks.

Scanning the Network: What to Look For

The first step in assessing the wireless network is to conduct a network search, or scan, to discover which entities are communicating on the 20 and 40 MHz channels in the 2.4 GHz and 5 GHz unlicensed bands. Typically, when performing a wireless network scan, the information the administrator or attacker will collect from discovered access point entities is as follows:

•  Media access control (MAC) address

•  Extended service set identifier (ESSID)

•  Channel

•  Average/peak signal-to-noise ratio

•  Power levels

•  Network type (802.11a, b, g, or n)

•  Beacon security parameters (WEP, Temporal Key Integrity Protocol [TKIP], or Advanced Encryption Standard–Counter Mode Cipher Block Chaining Message Authentication Protocol [AES-CCMP])

•  Beaconed quality of service (QoS) parameters

•  Location

Additionally, the administrator or attacker will document the following from discovered wireless stations:

•  Associated access points or peer stations

•  802.1X identity

The administrator can then compare the results of the network scan against the inventory and the as-built network designs to uncover any discrepancies. Alternatively, an attacker can identify weak points in the network to exploit.

After identifying unknown devices, the administrator can set about investigating them. Discovering the presence of such rogue devices is a relatively straightforward task, but actually locating and eliminating them is quite difficult. This is because they may not always be malicious devices. Rather, they could be devices owned by neighbors, vendors, guests, or employees. To compound the problem, it takes far too long to investigate and evaluate these devices using tools such as NetStumbler or Kismet. An alternative is the commercial inSSIDer Office tool, which enables you to scan and visualize the network more quickly.

Ideally, an enterprise should have a wireless intrusion protection system (WIPS) architecture with central control, a reporting console, and distributed agents, which protect each wireless segment. As an effective automated solution, a WIPS agent should be running 24/7 on each wireless network segment, scanning for and identifying probe requests by unauthorized devices.

Obviously, before an administrator or attacker can uncover a rogue entity, there must be a baseline inventory of authorized devices. Unfortunately, this is not always the case. This is especially true in some large companies, where authorized access points and BYOD devices were rolled out indiscriminately to meet urgent employee requirements.

Scanning for Vulnerabilities

Wireless scanning is not just about finding rogue devices. It is also about verifying that security measures are in place on authorized access points. All access points should be subjected to the same vigorous security testing as routers and firewalls because they are subject to association with both trusted and untrusted devices. Specifically, access points should be checked for the following:

•  The latest firmware and security patches

•  The correct security credentials

•  The appropriate security protocols

•  Encrypted administration interfaces

•  Appropriate protocol filters

•  Vulnerability to common attacks such as denial of service (DoS) attacks via authentication floods

Authorized smartphones and tablets are also a concern. They must be checked for the latest operating-system (OS) and security patches using a vulnerability scanner such as OpenVAS. They should also be checked for anti-malware and anti-spyware software and for information regarding their usage—for example, when this software last scanned the device. Other points of interest would be the existence of a firewall and of open ports that may be targets for exploit.

A typical weakness in smartphones is the default configuration to automatically reassociate with previously associated access points’ service set identifiers (SSIDs). This is done to aid in connection. However, many Android and iOS devices can connect to any neighboring access point if it has a strong signal. For this reason, it is important to be selective about which networks roaming devices will be allowed to associate with.

Service providers often ignore this, as convenience tends to trumps security. As a result, they often configure their smart devices to automatically connect to any wireless network that is nearby. The result is that the device, such as an iPhone or iPad, will always poll and try to access these networks. Although this is helpful for quick association and connectivity, it is also a vulnerability. Any rogue device can impersonate an access point and therefore capture client-station connections.

Another issue is that a smartphone may simultaneously connect to both a mobile and a Wi-Fi network. In doing so, it can bypass the company network’s routers and firewalls by transferring data between the phone’s interfaces and bridging the two independent networks. This is an inherent vulnerability in smartphones and is a major concern with regard to data leakage.

These are just a few of the wireless security issues that apply to unauthorized smartphones from a security perspective. The prevalence of smartphones as data-communication devices has made securing wireless networks very challenging. At issue is the fact that you can only protect (or attack) what you know is there. Therefore, scanning the wireless network topology is the key first step for any audit or attack.

In general, the wireless network should be subject to at least the same level of diligence and penetration testing as all other external components, such as firewalls and routers. Most of these tests are not specific to wireless, and will be part of the fixed and Internet-facing network infrastructure program. However, given the nature of wireless and the much broader attack surface, special attention should be paid to wireless networks and Wi-Fi–enabled smart devices.

The Kali Linux Security Platform

To scan and assess vulnerabilities in an enterprise, a professional security administrator or serious attacker requires a security toolkit based on a secure and mobile platform. The Linux operating system (OS) supports an open source security platform called Kali Linux. This is a restricted version of Linux with single-user root access, but it hosts a multitude of security and penetration testing tools.

Kali Linux is a security platform containing tools that enable an administrator to check or verify security measures in categories such as the following:

•  Information gathering

•  Vulnerability analysis

•  Wireless attacks

•  Web applications

•  Exploitation tools

•  Forensics

•  Stress testing

•  Sniffing and spoofing

•  Password and hardware hacking

Kali Linux also includes Metasploit and Aircrack-ng as well as more than 300 other penetration-testing tools, along with recipes for validating and penetration testing the security of the network.

The Kali Linux security platform, which can be downloaded as open source and loaded on a laptop, a USB drive, or even an Android phone, is based on Debian Linux. This makes it a very dangerous tool in the wrong hands. It is not necessary, but is advisable, to have some Linux knowledge before trying to use this tool. However, Metasploit includes tools that enable users to target virtual hosts to improve their skills before attempting a security assessment on a live network.

Some of the tools included with Kali Linux are used for scanning wireless networks. For example, Fern Wi-Fi Cracker and Aircrack-ng make the task of scanning a network much easier. After all, the goal in scanning a wireless network is to uncover all the wireless devices on the network, seek out vulnerabilities, hunt down rogue and unauthorized devices (that may be open to attack), test the authorized access points, and update the inventory. This is before considering taking action and eliminating or exploiting vulnerabilities.

Scanning with Airodump-ng

An example of a wireless network scanning tool is Airodump-ng, which is part of the Aircrack-ng suite bundled with Kali Linux. With Airodump-ng, the audit results returned from a wireless scan for each discovered device are as follows:

•  Basic service set identification (BSSID)—An association with a station

•  Extended service set identification (ESSID)—The network name

•  MAC address—The unique ID for each access point and station

•  Probe—The network that the station is trying to reach

•  Power level—The level the entity is broadcasting on (the higher the power, the better the chance to crack the password)

•  Cypher—WEP, TKIP, or CCMP

•  Authentication—Preshared keys (PSK), Remote Authentication Dial-In User Service (RADIUS), or none

The administrator then collates and compares this data to the inventory to detect discrepancies. This is when the investigation really begins.

Client and Infrastructure Exploits

Cybercriminals tend to seek out weak points that they discover in a network infrastructure or in a device’s hardware or OS. The weak points in a wireless network relate to the association and authentication of devices. In a wired network, much of this can be taken for granted, as a physical connection is required via a cable and switch. With a wireless network, this is not the case. Any device listening on the same 2.4 or 5 GHz band can listen and perhaps negotiate an association and join the network.

In the early days of 802.11, wireless networks were easy to penetrate because encryption was weak and people didn’t understand best practices. Today, IT departments have good standards and better tools with which to secure wireless networks. However, weak points in the network still exist. One of the main problems with wireless networks is that clients broadcast to any device that cares to listen. It is therefore imperative that wireless communications be protected against unauthorized access or eavesdropping.

Mobile devices, such as smartphones and tablets, have Wi-Fi capabilities that enable them to listen and communicate over wireless networks, both licensed (Telecom, 3G, LTE) and unlicensed (802.11). The fact that most devices can do this simultaneously creates a back door into corporate networks through which data (leakage) can flow undetected.

Other potential security vulnerabilities are mobile devices configured to automatically back up data to cloud data storage services such as iCloud, Google Cloud, One Drive, and Azure. This off-device storage of data may be OK for personal data, but it might not be the right choice for corporate data. Worse, in many cases, the company may not even be aware that it’s being done. At issue is the fact that data stored on these sites is also available to other devices and applications that operate on the same user account. This leaves serious security questions unanswered, such as where does this data reside and under what secure conditions?

Client-Side Exploits

Interestingly, Wi-Fi communication has become far more secure in recent years. The same is true of authentication with Extensible Authentication Protocol–Transport Layer Security (EAP-TLS) and encryption techniques detailed in 802.11i. Consequently, attackers have started to shift to client-side exploits via malware through attachments, downloads, Web site browsing (drive-by attacks), and direct USB connections.

Client-side attacks have always been part of the attacker’s arsenal, infiltrating clients with Trojans and malware through a variety of techniques. Smartphones are inherently more secure than PCs, however. This creates a bit of a dilemma for cybercriminals. One “solution” is to attack a smartphone via the PC’s USB port.

For example, a cybercriminal could begin an attack by using social engineering to gather e-mail addresses and other information. After finding e-mail addresses of trusted partners (for example, the company’s mobile phone supplier), an attacker could use the company’s e-mail address as the source of a forged e-mail. Typically all it takes to get someone to open an attachment is a convincing e-mail (and subject line) offering in invitation to a special event or a change in billing that must be approved.

The attacker can then construct his or her client-side payload using Metasploit exploits such as the Adobe util.printf, which targets a vulnerability in Adobe Reader. The goal of the attack is to inject a payload disguised as a file with a .pdf extension (attached in an e-mail, as noted). The file executes a reverse TCP/IP connection back to the attacker’s machine to load a USB exploit. When loaded, the program can gain remote control of the USB ports. The malicious PDF file will pass an antivirus check and will be activated when opened, thereby initiating a connection back to the attacker’s machine and simultaneously capturing control of the USB ports. Gaining remote control of the USB port gives the attacker the opportunity to take control of a smartphone when it is attached to the port. The attacker can then jailbreak or root the device, steal data, or infect it with a Trojan or other malware, depending on his or her intent.

This type of client-side exploit is difficult to remediate. This is because the attacker uses social engineering to gather information and then uses sophisticated tools to embed the malicious payload into an attachment sent from what appears to be a trusted source. Once the payload is activated, however, a WIPS should be able to detect traffic anomalies and raise an alarm.

Other USB Exploits

The smart device’s vulnerability lies in the handshake between the USB port and the device when it is connected. Among other things, this handshake determines what the plugged-in device is. For example, a rogue USB device might claim to be a human interface device (HID) such as a keyboard, at which point all keystroke information typed on the infected PC will be forwarded to the connected USB device. Called a keylogger, this exploit is common on both fixed and wireless peripherals. This attack is often deployed in hotel business lounges, where an attacker plugs a USB key into a PC used by dozens of people to check various accounts. This works because very few people think to look at what is physically connected to the machine they are using. The hacker can come back weeks later to harvest a potential windfall of account name and password combinations.

Of specific concern for smart devices is that USB standards allow a promiscuous association that makes the USB connection between a vulnerable PC and a tethered smartphone very dubious. Therefore, many cybercriminals target weak PC clients (lower-priority targets). By infecting them, they have direct control that enables them to infect smartphones and tablets (high-priority targets) when using the USB connection. Kali Linux features several tools designed to reprogram USB controllers and allow exploits on the hardware vulnerability that affects all devices. Furthermore, to the delight of cybercriminals, the USB vulnerability has no remediation other than to disable the USB controller.

Network Impersonation

Another common network attack is network impersonation. With this method, the attacker impersonates an access point by broadcasting an identical SSID (evil twin), but on a network interface on which he or she has boosted the power setting. By having a stronger radio power signal than the genuine access point, the attacker’s rogue access point can capture clients trying to connect. For this attack to be effective, though, the original access point must drop all its associations with clients by sending out deauthorization (deauth) packets. Using tools such as hostapd and a couple of wireless adapters, an attacker can easily set up a rogue access point on an Android smartphone or just about any other wireless device capable of running Kali Linux.

When the attacker sends the deauth command to the original (valid) access point, that access point will drop all connections. At that point, the clients will attempt to reassociate. Always favoring the stronger signal, the clients will associate with the rogue access point, and all communications will flow through the Kali Linux box. From there, an attacker can run any man-in-the-middle (MITM) exploit, such as Evilgrade (used to inject fake updates) or SSLsplit (to take over an encrypted session). Hackers can also spoof Domain Name System (DNS) queries by running the Dnsmasq tool to redirect the victim’s smartphone’s browser requests to a phishing site.

Creating an evil twin access point is pretty straightforward. Indeed, there are Kali Linux recipes for constructing these rogue access points. Unfortunately, regular audits will not mitigate the risks, as these rogue access points might be on a smartphone that will be difficult to locate due to its size and portability. Using a smartphone-based rogue access point, the hacker can move around or operate intermittently, lying dormant for long periods to avoid detection. A WIPS is a critical tool for listening for and detecting rogue devices on the network’s spectrum. A WIPS will not stop them from occurring, but it will make it much easier to detect them, which may prove to be a deterrent.

Network Security Protocol Exploits

In addition to exploiting clients and infrastructures, cybercriminals can (and do) exploit network protocols and services. This is especially effective when network security protocols and services can be spoofed. In that scenario, the very foundation of an organization’s security is used against itself.

RADIUS Impersonation

The preceding section outlined how a hacker could use a rogue access point to direct traffic to a false DNS server. Along those same lines, FreeRADIUS is a tool that enables a rogue access point to intercept and capture clients’ login credentials by passing the RADIUS authentication requests to a rogue host running FreeRADIUS. Packages such as PwnSTAR and easy-creds can automate the setup of the fake environment, with Karmetasploit (another Metasploit tool bundled with the Kali Linux platform) impersonating access points, capturing passwords, and harvesting data.

In the RADIUS server exploit, the attacker first sets up a fake access point and RADIUS server and waits for (or more likely forces) clients to authenticate. The attacker can then capture the challenge-and-response traffic between the RADIUS server and the client. These are encrypted, but the cipher can be broken using a variety of password-cracking tools. When this is complete, the attacker has a user account and password, which, depending on the user’s credentials, could allow the attacker access to sensitive data. These credentials can work on a variety of access methods, from remote access, to virtual private networks (VPN), to Outlook Web Access (OWA).

This attack works because self-signed certificates are often used in 802.11 environments, and these are installed on the RADIUS server. Unfortunately, Windows clients are forced by default to accept any certificate the server presents to them. (Protected EAP [PEAP] configuration does not require clients to validate the RADIUS server certificate.) Furthermore, clients are often configured to support external certificate authority (CA) certificates. (A certificate authority is a company or agency that issues digital certificates.) If an external certificate is enabled, an attacker sending a forged certificate will prompt the client for confirmation. The client will almost always confirm the false certificate, causing the forged external certificate to become trusted. This authenticates the attacker’s device, providing the attacker access to many network resources.

To remediate this type of attack, administrators should use EAP-TLS. It is not vulnerable to this type of attack because it uses mutual authentication. Unlike with PEAP, where only the client authenticates to the server, with EAP-TLS, the client authenticates to the server and the server also authenticates to the client. An alternative is to install an internal CA certificate and disable external or public signed certificates, which can be forged. By forcing clients to validate RADIUS certificates and by manually configuring the internal server certificate (and deselecting all other certificates), administrators can prevent this exploit. This remediation is best accomplished through Active Directory, which allows centralized configuration and ensures distribution to all wireless clients.

Public Certificate Authority Exploits

Certificates are used for authentication in communication with servers in banking and retail Web sites to assure clients that the sites are indeed who they claim to be. This Secure Sockets Layer (SSL) protocol uses certificates from trusted CAs to prove the authenticity of the server and ensure the confidentiality of the data. Most browsers strictly enforce a policy of checking the validity of the SSL certificate and immediately throw a warning if the certificate is out of date or invalid. However, many mobile applications are deployed without requiring a check of the validity of SSL certificates.

Compounding the issue is the growing number of self-signed but fraudulent certificates. These include fraudulent certificates for Facebook, Google, Apple, and a Russian bank. Although few up-to-date browsers would pass these fraudulent, self-signed certificates, many mobile applications do. This is a problem because if an application does not validate the authenticity of an SSL certificate, an attacker can use a forged certificate to launch MITM attacks on banking and e-commerce sites.

The Heartbleed security vulnerability discovered in OpenSSL in early 2014 was a staggering blow to what was believed to be secure communications and reliable authentication processes. This shook peoples’ confidence in online banking and e-commerce platforms. Moreover, OpenSSL was used in many open source and commercial software programs, including the Android OS. In fact, the Android OS had vulnerable versions of OpenSSL in all releases from Jelly Bean to KitKat. Fortunately, these releases had heartbeats disabled, so only early versions of Android OS (4.1.1) were vulnerable to this exploit.

Developer Digital Certificates

In addition to communication and authentication, certificates are also used for application validation. In this case, an encrypted digital signature in the code, signed by a trusted source, is used to ensure that an app has not been tampered with. For example, the trusted source could be Apple, Microsoft, or Google within its own application portal—the App Store, the Windows Store, or Google Play, respectively. In corporate settings, where an enterprise may need to side-load or download in-house applications to BYOD devices, applications can be verified with enterprise developer certificates. Developer certificates can be stolen, however, and sold on the black market. Or, they can be forged and then used to sign malicious applications, which can then be downloaded from a captive portal or side-loaded using a USB cable.

Browser Application and Phishing Exploits

Another class of indirect attacks on mobile devices is browser and phishing exploits. These types of exploits have existed for years on PCs and are essentially unchanged on mobile devices. What is different is the small size of mobile clients, which makes it more difficult to spot some of the telltale signs of these exploits, and a more nonchalant approach to clicking on links and opening e-mails on mobile devices.

Captive Portals

Captive portals play an important role in IT security. They are often used to validate guest users on a per-guest basis and to communicate terms of use for Wi-Fi networks. However, like many tools and technologies, captive portals can and are also used by hackers and cybercriminals. In addition to being used for MITM attacks, captive portals can be used to steal user credentials. Usually, this occurs on a Web site that allows users to access the Internet or a private intranet.

The security tool PwnSTAR can be used to front-end a rogue access point for this purpose. Client mobile devices are directed to the captive portal through DNS spoofing. The client then auto-connects without the owner even being aware that he or she has been redirected. Once the client is on the captive portal, the hacker can steal Wi-Fi Protected Access (WPA) handshakes and e-mail credentials, serve up phishing Web pages, and launch assorted exploits such as Aireplay-ng and Airdrop-ng to deauthenticate stations.

As an example, a cybercriminal in a shopping mall could use routing tables to route clients to a captive portal. After users enter their credentials, the captive portal could act as a real hotspot by allowing users to access the Internet. Similarly, the portal could allow Internet access, but only after the user downloads a client-side PDF attack that exploits the Adobe Reader vulnerability in the client-side attack detailed earlier. In addition, the attacker could launch several browser exploits to track usage and to log keystrokes.

Drive-By Browser Exploits

Captive portals and phishing sites are not the only dangers of which mobile users must be wary. Drive-by browser exploits are becoming more common. Drive-by browser exploits target Web browser plug-ins on mobile devices for Java, Adobe Reader, and Flash. These attacks are most often launched via legitimate but compromised Web sites that infect browser software running on mobile clients. The fact that they can do this without any user interaction is worrying—just browsing the site is enough to be contaminated.

An example of a drive-by exploit on Kali Linux is the Browser Exploitation Framework (BeEF). This tool can be easily installed and launched to assess or exploit mobile devices through their Web browsers. BeEF uses a JavaScript hook, which runs on the client’s browser. The script is embedded into the code of the Web page, requiring that the site be compromised. Once this is done, setting up the exploit is easy. Any number of means can be used to get the victim to the Web site, including, but not limited to, social engineering and DNS spoofing. When the victim visits the page, the code injects a Trojan payload into the browser.

Keeping browsers and plug-ins up to date and hardening Web sites are the best defenses against this exploit for users and site owners, respectively. Users can also disable JavaScript plug-ins, but this can seriously degrade the Web-browsing experience.

Mobile Software Exploits and Remediation

Like all network-based devices, mobile devices are subject to attacks that seek to exploit holes, back doors, or other weakness in the software responsible for running the basic functions, the communication protocols, and the applications that reside on the device. Given the combination of varied usage patterns, broad adoption, relative newness, and complex software, it’s no surprise that mobile devices are attractive targets for hackers and cybercriminals.

The Open Web Application Security Project (OWASP) is an international foundation and open community dedicated to enabling organizations to develop secure applications and to raising the visibility of software security so that individuals and organizations can make informed decisions about security risks. Recognizing mobile threats as their own class of security issues, the OWASP lists its top 10 mobile risks as follows:

•  Weak server-side security

•  Unsecure data storage

•  Insufficient Transport Layer protection

•  Unintended data leakage

•  Poor authorization and authentication

•  Broken cryptography

•  Client-side injection

•  Security decisions via untrusted inputs

•  Improper session handling

•  Lack of binary protections

Each of these is detailed in the sections that follow.

Weak Server-Side Security

Weak server-side security can allow the injection of malicious code to infect the mobile browser using drive-by exploits. This vulnerability exploits the Web interface or Web application programming interfaces (APIs), and the impact can be severe. The solution to this problem is to use applications from trusted sources that have a reputation for developing secure application software.

Unsecure Data Storage

Typically the result of developers who assume that users or malware will not be able to access their device file systems, this vulnerability occurs when sensitive data is stored in locations with no or inadequate security. If the device is breached or compromised, the result could be data loss, fraud, or even stolen credentials. Attackers commonly exploit this vulnerability through malware, and the impact can be severe. Large numbers of users can be affected in a single breach.

Remediation methods vary by platform. For iOS developers, best practices include the following:

•  Never store credentials on the device’s file system.

•  If the storage of credentials on the device is necessary, use a secure iOS encryption library.

•  For items stored in the password keychain, use the most secure API designations.

•  Consider a layered approach to encryption, and don’t just rely on the device’s hardware encryption.

•  For a database stored on the device, use SQLCipher for SQLite data encryption

Best practices for Android devices include the following:

•  For secure storage of data on the device, consider using the enterprise Android Device Administration API. This can force encryption to the local file store.

•  Secure all plaintext data with a master password and AES-128 encryption.

•  Consider a layered approach to encryption, and don’t just rely on the device’s hardware encryption.

•  Ensure that the shared preferences properties are not set to Mode_World_Readable.

Insufficient Transport Layer Protection

Mobile applications often do not protect network traffic that uses secure SSL/TLS for authentication and then reverts to cleartext HTTP after secure logon. This makes them vulnerable to MITM attacks and eavesdropping. The impact is moderate, as it typically affects only one person/session at a time.

To protect against this, best practices for all developers are as follows:

•  Ensure that digital certificates supplied by the server for authentication are valid.

•  Use the secure transport API in all cases.

•  Do not allow self-signed certificates from external Web sites and servers.

In addition, Android developers should remove all code that refers to applications that accept all certificates by default, such as Apache’s AllowAllHostnameVerifier. This is the same as trusting all certificates, regardless of origin.

Unintended Data Leakage

Data leakage is often the result of developers inadvertently placing sensitive data in easily accessible storage locations on the mobile device. This is another common and easy-to-exploit vulnerability. In mobile devices, it typically manifests itself in the way the OS caches data and images and handles logging and data buffers.

To protect against this, best practices for application developers working on iOS and Android devices are as follows:

•  Check for URL, copy and paste, and keyboard caching.

•  Check HTML5 data storage.

•  Check browser cookies.

•  Check analytics and other information being sent to third parties.

Poor Authorization and Authentication

Poor or insufficient authentication mechanisms enable an attacker to gain access to and execute functions on mobile devices. The authentication failures on mobile devices are usually the result of input forms on mobile screens, which tend to use simple authentication schemes. This vulnerability is common and simple to exploit, but the impact can be severe. Remediation in this case falls on developers, who should ensure that server-side authentication mechanisms are enforced rather than relying on device authentication on the user’s part.

Broken Cryptography

Poor or weak encryption used for authentication or data communications can be easily captured and cracked by an attacker. In iOS applications, code is encrypted to prevent reverse engineering or tampering. However, upon startup, the iOS loader must decrypt the application in memory before it can execute the code. That means a rogue developer can load an application on a jailbroken iOS device and take a snapshot of the decrypted code resident in memory. Attackers can use tools such as ClutchMod and GBD to accomplish this task just before the application starts to execute. This vulnerability is common, and can have a severe impact. With the right tools, this vulnerability is easy to exploit.

Remediation methods for all developers are as follows:

•  Do not rely on built-in code encryption processes.

•  Manage keys effectively and securely.

•  Do not use deprecated algorithms such as RC2 (short for Rivest Cipher 2, after Ron Rivest, the algorithm’s developer), MD4 (short for Message Digest), MD5, or SHA-1 (short for Secure Hash Algorithm).

Client-Side Injection

Client-side injection leads to the execution of malicious code on a mobile application. This can generate malformed data that is intended to be malicious, and can result in Structured Query Language (SQL) injection, JavaScript injection, or gaining access to application interfaces or functions. Client-side injection vulnerabilities are common and easy to exploit, although their impact is considered moderate. This is because the client-side code typically runs with the same security permissions as the user, which can restrict the impact on other services or servers.

Best practices for mobile application developers include checking applications for the following:

•  SQL injection (via input validation)

•  JavaScript injection (via input validation)

•  Local file inclusion

•  Extensible Markup Language (XML) injection

•  Classic C attacks, such as C functions prone to injection, including strcat, strcopy, strncat, sprint, and gets

Security Decisions via Untrusted Inputs

A mobile application can accept data from many sources via an inter-process communication (IPC), which allows different phone processes and subdevices to share information. To prevent malicious code from infecting other applications, a sandbox approach should be used in development. Only applications that are explicitly required to communicate with an app should be permitted to do so. This occurs through the use of a white list, a list of permitted applications or users. The prevalence of open communication between processes is a common security weakness, and the impact of exploitation is severe—especially given that it is also considered an easy vulnerability to exploit.

To mitigate this, best practices for developers are as follows:

•  Only allow applications to interact if there is a pressing business requirement.

•  Actions that may access sensitive data or functions must require user intervention.

•  All input received from external sources should undergo strict validation testing.

•  Do not use the Apple Pasteboard for IPC communications, as it can be read by all applications.

Improper Session Handling

Sessions must be handled for users during interactions with Web applications due to the stateless nature of HTTP. For a user to follow a seamless set of transactions with a Web server without having to authenticate each time, the session must be maintained so that the server can uniquely identify the user. This is done through tokens or cookies, which identify and maintain the session between the server and client user. The vulnerability here lies in the fact that an attacker can gain access to the cookie and use it to hijack a session by impersonating the user (or server). Attack routes tend to be through physical access to the device, over-the-air capture of a communication stream, or malware. The vulnerability is common, and the impact can range from moderate to severe. This exploit is easy to initiate.

The best option for remediation is for developers to understand that they must invalidate sessions on the server side and on the mobile device. Otherwise, there’s a window of opportunity for an HTTP exploit tool to capture the existing session. Developers should also place adequate timeout limits on applications based on the application’s sensitivity—for example, three minutes for a secure app and one hour for an app that’s less secure.

Another common mistake is failing to rotate cookies during session management. Cookies should be rotated and existing sessions torn down and re-created during events such as the following:

•  A user switching from anonymous to logged on

•  A change in logged-on users on the device

•  A switch from a regular user to an elevated privileged account (admin or root)

•  After each session timeout

Lack of Binary Protections

Many mobile developers provide little in the way of binary protection to their code. Binary protection, also referred to as binary hardening, is a software security technique in which binary files are analyzed and modified to protect against common exploits. Binary protection prevents rogue developers from reverse engineering or tampering with application code. Without it, cybercriminals can alter code and inject malicious code in the form of malware into the application to perform some hidden functionality. The vulnerability is common, and the impact can be severe. Reverse engineering the code is not a trivial task, however.

To mitigate this, best practices for developers include ensuring the application code adheres to secure coding techniques, especially with regard to jailbreak detection, checksum controls, certificate pinning controls, and debugger detection. Additionally, the mobile app must be able to determine at the time of execution if there is a code-integrity violation.

CHAPTER 13 ASSESSMENT

1. Weak server-side security does not pose a direct threat to mobile clients.

A. True

B. False

2. Which of the following is not a risk from client side–injection attacks?

A. SQL injection

B. Data leakage

C. JavaScript injection

D. Hackers gaining access to application interfaces or functions

3. Which of the following describes binary protection?

A. It is a two-way handshake for authentication.

B. It prevents rogue developers from reverse engineering or tampering with application code.

C. It is a form of session security.

D. It prevents Bluetooth-based attacks.

4. In addition to searching for rogue devices, scanning wireless networks is also used to do which of the following?

A. To see which Web sites employees are using

B. To prevent data leakage

C. To frequency-jam unauthorized access points

D. To verify that security measures are in place on authorized access points

5. Given the improvements developers have made on their mobile platforms, user security awareness is no longer an issue.

A. True

B. False

6. The ability of many smart devices to access mobile and Wi-Fi networks simultaneously creates potential issues with which of the following?

A. Corporate governance

B. Data leakage

C. Security patches

D. Sandboxing

7. PC-based USB exploits are not a concern for mobile devices because most of these devices do not have USB ports.

A. True

B. False

8. Why are certificate authority (CA) exploits an issue on smart devices?

A. Mobile browsers do not enforce the validation of certificate authority certificates.

B. Many mobile applications are deployed without requiring a check of the validity of SSL certificates.

C. Mobile devices are small, which makes the certificates hard to read.

D. All of the above.

9. Which of the following is not true about captive portals?

A. They can be used to steal user credentials.

B. The can be used to front-end rogue access points.

C. They are used only for hacking purposes and should be avoided.

D. They can be used to launch attacks.

10. Drive-by browser exploits target which of the following?

A. Access points with no encryption

B. Mobile devices on highways

C. Near field communication–based applications

D. Web browser plug-ins for Java, Adobe Reader, and Flash on mobile devices