131. Attacks on Mobile Devices (OBJ 3.5)
In this section of the course, we’re going to discuss the different types of attacks that can be conducted against mobile devices, things like smartphones, tablets, smart watches, and other wearables. Now, due to the rapid expansion of mobile devices and networks they rely on, organizations are no longer relying on just standard desktops and laptops in the way they used to do their work. In reality though, smartphones are really just small computers that are being carried by employees who are working all over the globe, and this has led to the de-perimeterisation of the network.
Unfortunately, many organizations and their employees don’t really view these devices that way, and so, this leads to a lot of smartphones remaining misconfigured and unpatched, and this leaves them with many vulnerabilities that can be exploited by an attacker. Nowhere is this more true than the Android device space, because of the way updates are released. When Google finds a vulnerability in the Android OS, they’re going to go ahead and create a patch and then release it. But then Samsung, Motorola, Huawei, or some other third-party developer has to take that patch and deploy it to their smart phone models for all of their customers.
For this reason, updating of Android takes a little bit longer than what you see with Apple. Apple on the other hand, tends to be a bit better in terms of their patching, because they can push out security patches out directly to all of their handsets, because they own the software and hardware. Now, the users still needs to accept and install that update, and this becomes another reason that vulnerabilities can remain on many of these mobile devices and these devices remain not fully patched. So, as we move through this section on attacks on mobile devices, we’re going to continue looking at various attacks and exploits that we can use during the third stage of our engagement. As we move through this section, we’re going to be focused on covering the first half of Objective 3.5 and focusing on mobile devices as a type of specialized systems for the exam. Now, this objective states that you must explain common attacks and vulnerabilities against specialized systems. Notice that this objective is a little bit different than the other ones we’ve covered in Domain 3, because those other objectives all stated, given a scenario, you must research and or perform some different attacks on some kind of system, but here, in Objective 3.5, that is not what you’re being asked to do, instead, you simply need to be able to explain common attacks and vulnerabilities. For the exam, this means you’re going to get a lower level of questions when it comes to mobile devices and specialized systems than you do for things like networks and web applications. Now, as we move through this section of the course, we’re going to begin by discussing some mobile device protection mechanisms from the cybersecurity defense perspective such as using enterprise mobility management and mobile device management, as well as how they’re going to be used to conduct patching, securing the device’s storage, and conducting certificate pinning to a device. After that, we’re going to cover different mobile device deployment options that you may come across in the field, including corporate-owned business only, corporate-owned personally enabled, choose your own device, and bring your own device, as well as the security implications and vulnerabilities that are associated with each type of those different models that you can then exploit using the unique vulnerabilities you find in those deployment models.
Next, we’re going to discuss the type of information that you can gather from mobile devices by conducting reconnaissance and eavesdropping on smartphones, tablets, and wearables. After that, we’re going to move into our coverage of some of the different insecurities that can exist inside of a mobile device, things like jailbroken and rooted devices, devices with custom firmware installed, side loading of applications on a device, and third-party app installation. Then, we’re going to talk about some of the best practices that you can use to secure mobile devices, things like configuration profiles, full device encryption, VPNs, location services, and geofencing, along with some ways that an attacker can try to exploit these best practices. After that, we’re going to move into a discussion of the different types of authentication that’s being used with mobile devices, this includes biometrics and multifactor authentication.
After building up this solid baseline of information in terms of securing the mobile devices, we’re going to then focus on the different types of mobile device attacks that can be conducted by a penetration tester, including spamming, installing malware, conducting reverse engineering, and using sandboxes to analyze malicious code. I’m also going to provide a demonstration of how you can conduct some basic malware analysis using both static and dynamic tools. Finally, we’re going to take a quick look at the different types of tools that you’re going to be able to use when you’re doing mobile device penetration testing, this includes tools like Drozer, ApkX, APK Studio, APK SDK, Frida, Objection, Needle, Ettercap, the Mobile Security Framework, Burp Suite, and Postman during your engagements. All right, it’s time to continue our coverage of Domain 3, Attacks and Exploits, with attack on mobile devices in this section of the course.
132. Enterprise Mobility Management (OBJ 3.5)
With the ever increasing move towards mobile devices and wearables, the big question becomes, how do we secure all of these devices that are connecting to various networks that we can’t control? This is especially true with those devices, are allowed to connect back to our own enterprise networks later on, such as our employees’ smartphones that travel with them from home to work and home again each and every day. Well, the answer to this challenge is Enterprise Mobility Management, also known as EMM. This is also going to be called Mobile Device Management or MDM in some circles. Now Enterprise Mobility Management describes a suite of policies and technology tools that enable the centralized management and control of mobile devices in a corporate setting. To put more easily, EMM and MDM consists of the processes involved to conduct tracking controlling and securing of our organization’s mobile devices and infrastructure.
Now, technically, EMM and MDM are actually two different things, because MDM or Mobile Device Management is a subset of the larger Enterprise Mobility Management suite. But most people use these two terms interchangeably. If we want to be really precise with our wording though, we should consider EMM to be the policies and tools that are involved in securing our enterprise mobility devices, whereas MDM is really focused on the technical controls that we’re going to use to ensure compliance with an organization security requirements. So EMM is both the policies and tools, but MDM is really just the tools themself. Now in the marketplace, there are a lot of solutions available to perform this technical control of our devices and therefore, put our mobile device management functionality into our organizations. These solutions offer a centralized management control for our administrators to be able to implement and enforce our security policies over a wide variety of different mobile devices.
Most of these solutions have six main features. First, we have application control. Application control is going to be used to provide the capability to install, configure and block or remove different apps from a given device. For example, your organization might want to a block TikTok or Facebook from being installed on a smartphone that you provide to your users. And you can do this with application control inside of your mobile device management tool set. Second, we have passwords and passcode functionality. Now most MDMs provide you with the ability to enforce password policies for the entire device or you can control password protection for specific applications. For example, one of my previous organizations required that all iPhones use a long and strong password of at least 16 characters that consisted of uppercase, lowercase, numbers and special characters. Or, alternatively, you can enable the fingerprint reader or the facial scanning feature instead. Now, if you try to enable a four to six digit Newark passcode though, the MDM would block this ability and force you to use one of the stronger methods instead.
Now, in addition to this global password policy setting, the MDM can also enable stricter controls on a specific application, so that it’s going to be required to have a facial scan or a fingerprint scan before you can use that application, even if the phone itself only requires a password to unlock the device. The third feature of most MDMs is the ability to require multifactor authentication. Now MFA or multifactor authentication requirements can be set so that a device must be authenticated with two or more authentication factors such as using a password, a one time use code that’s texted to the phone or a biometric factor, like a fingerprint or facial recognition scan. With most MDMs, you could set the ability for multifactor authentication to become required if that device meets certain conditions. For example, it might no longer be located in the same state or country as your organization’s headquarters, and therefore, it now needs two factor authentication or whatever other risk factors you may be trying to mitigate. The fourth feature we have that’s provided by most MDMs is token-based access. Now token-based access requires that the enrolled device is provided a token or digital certificate in order for it to be able to gain access to your network resources by fulfilling the requirements of NAC or Network Access Control Solutions. This is a solution that does authentication and checks before somebody’s allowed to connect to your network. This can be done using digital certificates, using something like the 802.1X protocol or other features inside of your NAC. The fifth feature that an MDM provides is the ability for organizations to conduct patch management through the use of a centralized patch repository.
This centralized repository of tested and validated patches could then be used to ensure all of your corporate enrolled devices are being patched and updated to a certain version level in a controlled and scheduled manner. For example, in one of my previous organizations, we would give all of our mobile device users only seven days to update their devices to a particular iOS version once it was out and it was tested and approved by us. If the device wasn’t updated by the end of the seven day period though, we would then place them into a block group. And this would deny them from gaining access to our network by using our MDM and NAC solutions until that device was updated to the correct version. So as you can see, we can use these mobile device management tools to manage our applications, our data and other content that we want to have authorized for use on our devices, as well as push security controls across our entire device inventory, instead of trying to apply the policies individual to each and every smartphone device.
Now, when it comes to patch management, for example, many MDM solutions will also provide you with the ability to push out operates system and application patches and updates, or to conduct authentication of devices, or enforce a security policy or locate devices through GPS, or push out notifications to large groups of users or devices, or remotely lock or wipe lost devices. Now this last feature, remote wipe, is an important feature too, because mobile devices are often lost or stolen, and we want to ensure that our sense of information doesn’t fall into the wrong hands. To prevent this, a device can be subject to a remote wipe if it’s been reported lost or stolen by our employees. A remote wipe is going to be used to send a remote command from your MDM solution to a mobile device in order to delete the data and settings on that mobile device. This will revert the device back to its factory default settings and essentially sanitize the sensitive data from the device’s on board storage.
Now note here, a device must have a connection to the internet or the cellular network in order to receive that remote wipe command from the mobile device management tool though. So if a thief puts your smartphone in a faraday bag or turns it onto airplane mode, they can prevent the remote wipe from being initiated by your mobile device management suite. Now to overcome this limitation of remote wipe though, your devices can also be configured to remote wipe that device if the incorrect password or pass rate is entered too many times, or if the device tries to connect to the network and it no longer meets the minimum baseline requirements. Another important concept here that we need to discuss in terms of smartphones is that device certificates can be used on them. Now device certificates can come in two different types. We can have a trust certificate and a user-specific certificate.
Now a trust certificate is a digital certificate that’s going to be used to globally identify a trusted device within an organization. In its simplest form, this relies on a single certificate that’s going to be installed on all the trusted devices within the organization. Then when a device tries to connect to the network, that trust certificate is going to be checked. And if it’s found to be in place, the device is considered trusted and is able to connect to the network. Now, the vulnerability here though, is that if the trust certificate is copied by an attacker they can then pretend to be authorized as well. And if you need to revoke the certificate because a single device has gone missing, it’s going to actually revoke it for all devices because they all use the same certificate. For this reason, I prefer to rely on user specific certificates instead. Now a user specific certificate is a digital certificate that’s a assigned to a device to uniquely identify it on the network. To ensure the right certificate is installed on each device, you should implement a PKI-based solution with your MDM to issue and install those certificates on each authorized device. This will also allow you to revoke individual certificates if you need to, instead of removing everybody’s trust certificate at once.
All right, the final concept we need to discuss is firmware updates. Now firmware updates are usually conducted over the air and they’re going to be used to update the base band of the radio modem inside of your device that’s used for cellular, wifi, Bluetooth, NFC and GPS connectivity. Regardless of if you have an Android or iOS device, your smartphone also has a second type of room installed on it. And this is going to be used to run a software defined radio within your mobile device. This firmware is essentially the operating system for your modem and it has its own processor and memory. So it relies on a realtime operating system known as an RTOS to conduct the modulation and frequency shifts that are required to maintain radio connectivity with the different cellular towers. Over time, the cellular company may need to make changes to their frequency or modulation or other parameters and they may send out a firmware over their update to add these new capabilities or performance capabilities to your smartphone. Now, while over the year, updates are necessary for cellular devices to maintain the best connectivity, attackers have also found ways to exploit these updates for their own evil purposes.
For example, if an attacker in a local area set up a stingray or IMSI catcher as an evil base station, they could trick a user’s smartphone into connecting to the attacker like an on path attack and then sync corrupted or malicious firmware to those handsets without the victim even being aware of it. To prevent this, smartphone manufacturers and cell phone providers are working to embed authentication and integrity mechanisms into the over their update process. But until that has come in place, this is a vulnerability you need to be aware of.
133. Deployment Options (OBJ 3.5)
In this lesson we’re going to discuss the different mobile device deployment options that you can use in your organization. Now, a mobile device deployment model describes the way employees are provided with mobile devices and applications to use as part of their job functions. Now, this can be one of the largest decisions an organization needs to make in the world of mobile devices. And there are four common models that are used today. Corporate Owned Business Only or COBO Corporate Owned Personally Enabled, or COPE. Choose Your Own Device, (CYOD) or Bring Your Own Device, (BYOD). Now Corporate Owned Business Only or COBO devices are devices that are purchased by the company for use by the employees for work related purposes only. All ownership including the purchase, security and maintenance of that device is going to be handled by the organization. Now, this deployment model is considered the most secure but it is also the most restrictive for employees and the most expensive for employers. The second model we have is the Corporate-Owned Personally- Enabled or COPE model.
Copy devices are a more relaxed version of Corporate Owned Business Only because it provides the employees with a company procured and managed device, but it also makes provisions to allow the employee to utilize it for personal use too. This method can cause some privacy concerns for your employees though because the organization technically owes the device that the employees putting all their personal data onto and the company may choose to inspect those devices at any time. Also, the employee is subject to the acceptable use policies of the organization when they’re using this device because it’s technically still part of the corporation’s network and not theirs. The third option we have is Choose Your Own Device or CYOD. Now CYOD is a method that allows the employee to select a device for an improved list of vendors or devices. This method is similar to Corporate-Owned Personally-Enabled, but the employee can actually choose the device they want to use from a list of supported devices. This allows the employee some choice in the smartphone and it provides a limit to the different types of devices. Then organization has to support.
This also mitigates some of the age vulnerabilities because the organization can select two or three devices and create a pretested and approved version of a particular operating system or device for all the employees to use. For example, at my last organization we supported three models of iPhones and one model of Android that our employees could choose from. And then we would go out and buy that device and give it to the employee. Now, the fourth option we have is known as Bring Your Own Device or BYOD. This refers to a deployment model where employees are allowed to bring their own laptops, tablets and smartphones into work and then connect those devices to the corporate network. This transfers to the financial cost of the device to the employee. But it does introduce a ton of security issues and legal concerns for your organization because these devices are not owned or maintained by your organization. And yet their organizational data will find their way onto those devices. Now, when you’re using a BYOD for your mobile devices, a lot of organizations will require the employee to purchase a compatible device. For example, a company might only support iPhones or only Android devices or whatever it is. In the BYOD model, the employee is going to agree to allow the company, to install corporate applications, and even give the company the ability to install an MDM or other oversight and auditing software on the device, in a lot of organizations.
Now, most employees like the BYOD model, because they can own and choose their own devices but it is the most difficult to secure for security professionals and it does bring up these privacy concerns. Personally, I prefer to use Corporate Owned Business Only or Corporate-Owned Personally-Enabled deployments in my organizations and my networks. Now, there is one other two type of mobile deployment that you may come across in the real world. This is known as VMI or Virtual Mobile Infrastructure.
Now VMI is similar to VDI or Virtual Desktop Infrastructure that’s used in large organizations, but with VMI we’re utilizing a virtualized mobile operating system. That’s hosted in a server farm. That’s accessed through a mobile web browser on your personal device or company owned device. Now this is a newer mobile deployment method and it is gaining some popularity because it has some really cool benefits. Virtual Mobile Infrastructure, provides a sandbox environment for work related activities that provides a more secure method of accessing things from an employee’s perspective while still allowing those employees have the ability to use a personally procured device. From an organizational security standpoint, it’s also great because your data is never leaving your network. Nothing is stored on the employee’s device. It all remains in your cloud-based infrastructure that you’re hosting as part of VMI.
