Chapter 12: Hacking Mobile Platforms

Today, when we see devices on mobile platforms come out, we have this tendency – hopefully, from the hacker's perspective – of thinking, "What am I going to do now?"

A favorite quote of mine comes from the great Star Wars character Master Yoda when he says, "Size matters not. Look at me. Judge me by my size, do you?" It's the same concept here with mobile devices. They're extremely small. Most of our smartphones are more powerful than the computer systems NASA used to get man on the moon in the 1970s. The rate at which mobile devices are coming out and the applications that are being supported on these devices is mind-boggling.

So, buckle up – I'm about to take you through several different aspects of the mobile platform from a hacker's perspective.

In this chapter, we will cover the following topics:

• Vulnerabilities in mobile environments
• OWASP's Top 10 risks for mobile devices
• Hacking Android
• Hacking iOS
• Mobile device management

Let's start by identifying the process and some keywords for attacking vulnerabilities or attack vectors in mobile devices.

Vulnerabilities in mobile environments

In addition to the vulnerabilities that we see in our network attacks, cloud attacks, and wireless attacks, there are more vulnerabilities or attack vectors associated with mobile devices than there are with standard desktop environments. Here are some of the other vulnerabilities that affect our mobile world:

• Apps and app stores: It's important to know where you're getting apps from because as an attacker, I'll take a popular application, recompile it with my malware, and try to redistribute it.
• Viruses, worms, and rootkits: The malware we deal with in the desktop environment is the same malware we will encounter in the mobile device environment.
• Data storage: Developers must carefully consider which data will be stored on the smartphone and how it will be secured. A mobile app should avoid storing sensitive information, such as passwords or credit card numbers, on the phone's local filesystem since that may allow an attacker to gain access after the device has been physically acquired.

Storing any sensitive information on the local filesystem is not recommended but doing so in a SQLite database may be marginally better… if your security senses just tingled, it should be because of what we know about SQL and injection attacks. That's why I say marginally better.

• Copying information: If I get information via an email and I save it (since it came as an attachment) to my local Secure Digital (SD) card, and then I forward it to my Dropbox, I'll be exposing my system to attackers. You may want to consider encrypting your data storage so that if somebody pulls your SD card or gets hold of your device, they must type in a pin, just like when you turn a phone on from a cold boot.
• Social engineering: We covered this in Chapter 8, Social Engineering, but to reiterate, it's a non-technical method of getting people to do things they normally wouldn't do. We can use technology to socially engineer, but manipulation is always involved at the human level, not at the device level. From a mobile perspective, most social engineering happens via email, text messages, or multimedia messages.

You have probably been a victim of in-person social engineering – you just didn't know it. Social engineering also happens on social networking sites. Advertisement is also a way of implementing social engineering to get you to click on the link, like something, or hijack a Facebook account. Then, I can post to their friends saying, "Hey, there's this new security issue out there, click on this link, I'm trying to help you out," and when they click on it, I infect them.

It's also being done via video chat. For example, when I installed Skype or Zoom to be able to do video conferencing, I received eight invitations within the first 3 minutes from strangers. Listen, I know I'm popular, but come on!

• Short message service (SMS) environment: There's a big increase in attacks in SMS environments, especially via SMS phishing, because most people don't know how devices are designed to work. We get messages from what looks like our banks or one we don't even have an account with. They include links that can very easily be links to a phone number that dials a different number from what's being displayed. When you click on it, they dial a different number or route you to a different phone number. Some links take you to a fake but identical website. They tell you, "Hey, your account has been locked out, follow this link to learn more."
• Drive-by: This is when an attacker delivers a piece of malware to a device when somebody browses a specific web page. A lot of times, a drive-by is software-created, or in web browsers. The software could be the operating system, Java, or any type of web plugin, but web browsers also create this big hole for us.
• Older versions of operating systems on mobile devices: It's hard for manufacturers to keep up with this. They struggle with updating the operating system. There are vulnerabilities in most operating systems and we're not talking about older legacy stuff. It could be a second-gen iPad on the network, a first-gen iPad, Samsung S3, or iPhone 4. The real challenge is if they are still allowing updates to fix holes in security.
• Phishing: This is done via fake emails. Sometimes, it's hard to realize that the link in an email is invalid or know if a website is fake. Of course, it's part of our social engineering environment. They get you to type in your username and password because of an email that says your Citibank credit card has been locked out and you need to log in. They then take you to a website that's not Citibank. Luckily, it is getting harder to accomplish phishing-type attacks because many companies have separate apps. People can confirm such information quickly.
• Connections: Is your device always connected to a cellular network, Wi-Fi network, Bluetooth, or the scary Near Field Communication (NFC)?

Now, let's look at what OWASP has specified as the top attack vectors for mobile.

OWASP's Top 10 risks for mobile devices

Open Web Application Security Project (OWASP) publishes the top 10 risks for mobile devices each year. The M stands for Mobile, and the list is pretty similar to the OWASP Top 10 web application risks that were finalized and published in 2016. Note that OWASP is a fantastic resource for you to follow and learn from (https://owasp.org). Let's take a closer look at these risks:

• M1: Improper Platform Usage: This category pertains to a violation of the platform's functionality or failure to use security features. This might be an Android intent, platform permissions, TouchID misuse, the keychain, or some other mobile system security feature that you don't utilize correctly.
• M2: Insecure Data Storage: There is a trade-off with supporting offline functionality. Developers must carefully consider which data will be stored on the mobile device and how it will be stored. A mobile app should avoid storing sensitive information on the local filesystem, if possible, as that could lead to an attacker gaining access after the physical acquisition of the device.

Storing any sensitive information on the local filesystem is not recommended but doing so in a SQLite database may be marginally better.

• M3: Insecure Communications: Mobile apps should avoid using non-secured communication methods that could result in attackers sniffing or manipulating transmitted data. This includes HTTP, FTP, Telnet, WAP, and GPRS (if not over SSL). There are often cases where an HTTPS connection cannot be established due to certificate validation failures (for example, self-signed certificates). In this case, a developer may choose to accept the risk and disable HTTPS validation.
• M4: Insecure Authentication: Mobile apps should always implement secure authentication methods. This includes using OAuth 2.0 wherever possible, as well as implementing strong password/PIN policies to lock the device after a few failed attempts. An application that supports single sign-on should only do so with trusted sources that adhere to security best practices.
• M5: Insufficient Cryptography: Mobile apps should always use standard cryptographic algorithms and implementations. This includes using FIPS 140 validated cryptography for any operations that require strong cryptography. Weak cryptography increases the risk of a data breach, whether it's intentional or not.
• M6: Insecure Authorization: Insecure authorization exposes data, allows attackers to perform actions as authenticated users, and facilitates attacks such as Insecure Direct Object Reference.
• M7: Client Code Quality: Mobile app client code should never be trusted. Malicious mobile apps can easily exploit client-side vulnerabilities by modifying how the application functions using reflection, changing the flow of execution, injecting commands into the command stream, or even executing native machine code. Developers need to verify that mobile app clients are valid before accepting them. A mobile app scanner, such as Drozer, can be used to test for these vulnerabilities.
• M8: Code Tampering: Malicious mobile apps can leverage dynamic code loading to tamper with the original app. Several commercial and open source dynamic code loading frameworks are commonly used for legitimate purposes but also leave developers vulnerable to abuse.
• M9: Reverse Engineering: Mobile apps may be reverse-engineered using automated tools or manually by examining application binaries after being decompiled.
• M10: Extraneous Functionality: An attacker will download and inspect the mobile app in their environment. They'll look at the log files, configuration files, and perhaps the binary itself to see whether any hidden switches or test code was left behind by the developers. They will utilize these switches and covert functions on the backend system to execute an assault.

Now, let's talk about hacking Android.

Hacking Android

To begin, it's important to understand the bigger picture about what we're dealing with when it comes to hacking mobile platforms. So, let's start by understanding the Android security environment.

Android security

To understand any type of security, you need to know the architecture that lies underneath the platform, because it can show you where the holes are on that device.

Android security is layered like an onion. Let's look at each layer one by one.

Linux kernel layer

Like Windows, macOS, and others, Android has a Linux kernel as its first layer.

Android used it because it's stable – it has a proven driver set. The Linux kernel creates an interface between the hardware that may be installed on the device, be it the display, the camera on the device, USB ports, networking ports, the keypad on the screen, Bluetooth, Wi-Fi, sound, and the power features. All these devices are supported directly by the operating system via this layer of the architecture.

Libraries layer

This layer has some built-in libraries, including the following:

• The Surface Manager: This is simply there to compose the windows you see displayed on the screen.
• Open Graphics Library (OpenGL) and Graphics Library Kit (GLKit): These oversee both 2D and 3D displays. What's cool about this infrastructure is that an application can switch from 2D to 3D almost seamlessly.
• Media framework: This allows you to play back and record multimedia (audio, video, or pictures) back on the display. For example, most of our codex is built into this framework, such as MP3. So, when you power on a brand-new phone, you can take a picture and look at it immediately. That's because it's in JPEG format. You can also download an MP3 file and listen to it immediately; you don't have to download and install any additional codex.
• FreeType: This component is there to render our fonts. You can change the fonts that are being displayed throughout the system, including their size and type. Some applications will also pull on this free type so that you can change the font within the application itself.
• Open SSL: This gives us security when we're communicating with other devices.
• SQLite: This is a database engine. However, it can create vulnerabilities on Android devices. The same type of vulnerabilities that we see in a standard Structured Query Language (SQL) database server can be implemented in some cases against these mobile devices.
• WebKit: This is an open browser. It's the same engine that Apple's Safari uses.

Next, let's talk about the runtime layer.

Runtime layer

At this layer, we have the core libraries and the Dalvik virtual machines. It is simply a runtime layer that includes a set of core Java libraries. This allows application programmers to build their apps using the standard Java programming language.

Here is a list of the most common runtime layers:

• The Dalvik VM: This is an open source software that was named after a fishing village in Iceland where the creator's ancestors hailed from. It's a virtual machine and it's been streamlined for mobile devices so that multiple virtual machines can be running to support multiple apps. In the Android world, we sandbox each of our apps. It has a low memory requirement, and it relies on the underlying OS for process isolation, memory management, and thread support.
• Framework layer: This is where we see the core applications that come with our device. For example, T-Mobile may load some default applications that are proprietary to their environment, such as TouchWiz, the interface they load on top of Android.
• Activity manager: This simply manages the life cycle of applications. This includes starting and running an application. It also manages a pause state if an application is paused because we switch out to a different app. There's a stop state if the application hasn't been used in a while, as well as a destroy state, which removes things out of the resources when the activity manager decides there's no more use for that activity.
• Window manager: This is what we see on the screen itself. So, there's a component that's managing that for us.
• Package manager: This keeps track of which applications we have installed when it comes to updates or how to uninstall a particular application.
• Telephony manager: This oversees managing your phone calls. If you've built an application in which when you click on a contact, you see their phone number, and when you click on it, you need to fire off and have it dial that phone number, the application is calling on the telephony manager.
• Resource manager: This manages the resources that your application may use.
• Content providers: This manages the data that's shared between applications, so we get that seamless feeling in the environment itself. For example, a couple of our default content providers include the call log, which provides our missed calls, call details, and the time of the calls. The address book or the user dictionary is also a content provider. As you start to type things in, the default user dictionary may not recognize the word, but you know that it's a correct word and you sometimes hit the check that says, "This is the correct spelling." Another example would be when you install, say, Facebook – the Facebook wall is an activity. When you click on the photo button, you may pull up the content provider into the Photoshop gallery so that you can share photos via the Facebook application.
• Location manager: This is the framework that's used by your GPS and possibly your cell phone towers to determine where someone is located. For example, I can pull this up via an application and see where my kids are. They don't have to have GPS on – it triangulates through the cell towers.
• The view system: This is simply what it sounds like; the different views we have of applications and windows. It does a lot of communication through the windows manager.
• Notification manager: This application simply notifies us when we've missed a call or a text message.

Next, let's look at the apps layer.

Apps layer

This is where we see things such as the home screen or our contacts, the built-in applications, the phone, and the browser. As you add additional applications to your device, it adds them here at this level. It uses the framework, the libraries, and the runtime to interact with the devices to do what we want our device to do.

Now, let's look at near-field communication (NFC) attacks next.

NFC attacks

I love NFCs. As an attacker, I might be looking out for legitimate NFC tags. I may create a tag and place it on top of one on a sign in a mall or a grocery store or tear it off and replace it with mine. Usually, the user simply tags or taps to get information. I could then send them off to a website that has an exploit to a vulnerability in WebKit, such as 1759. Any user who scans the tag will end up with a rooted and compromised device.

Relay attack

All the attacker needs to execute a relay attack are two devices that act as a token and a reader. They create a connection via a proxy channel. This is typically Bluetooth, but it could also be Wi-Fi. This allows us to relay the information over a greater distance. The proxy reader is then used to communicate with the real token while the proxy token is placed near a real reader. The token assumes it's talking to the reader and responds accordingly. That response is then relayed back to the token proxy, which will transmit the information back to the reader.

Hacking techniques

Let's discuss some of the techniques as an ethical hacker you can gain access to devices, networks, and systems.

Rooting

When it comes to rooting, we escalate our privileges to gain root access to the device. Rooting allows you to make all kinds of customizations, including tweaking settings, loading custom OSs, and even improving performance. I root my devices so that I can get rid of bloatware that comes with most phones, but I do understand the risk that I take by doing so.

When it comes to applications, they are restricted by the security model so that an application can only access its own files, the external storage, or the external SD cards and only has access to resources and features that it requested during installation. By rooting, we're allowing certain applications to run as the root user. When this happens, the security model breaks down because we're bypassing the default permissions.

Not all applications will automatically use root-level access. Facebook, for instance, will still use the resources and information that it needs.

Rooting shouldn't be done by the weak-hearted or someone that doesn't understand what they're doing as you can brick a device or open you and your company to added risks.

Tools such as KingoRoot, TunesGo Root Android Tool, and One Click Root can be used to open things up a bit for you. Other options include rooting via the Android Debug Bridge (ADB) and tools such as Phonesploit.

Man-in-the-disk attack

When an attacker has physical access to a device and can install a harmful program on it, this attack can be performed. The app does not need to be downloaded via the official app store; malware may be installed in any way, including through a USB connection or over a wireless network. Once the app has been installed, it can exploit vulnerabilities in the Android operating system to gain access to sensitive data.

The Android OS consists of two types of storage: internal and external. In general, the internal storage for Android apps is sandboxed, whereas the external storage is intended to enable file sharing between applications, making it vulnerable to MITD assaults.

When a genuine program attempts to perform a typical upgrade, an attacker watches the data stored on the external storage and tries to modify, delete, or replace the application data by editing the source code of the upgrade. When the legitimate app update is successfully injected by malware, the user application downloads and executes the malicious code, allowing an attacker to install a fake app.

Speakerphone attack

Android applications may capture speakerphone traffic without any need for permission. Sniffing speakerphone voice conversations between remote mobile users is possible via the hardware-based motion sensor, known as the accelerometer, which attackers use to listen in on them. The accelerometer is a piece of hardware that is built into most smartphones and may be accessed by any app on the phone without requiring additional permissions. The motion sensor allows applications to monitor the device's physical movement based on changes in position and velocity. This built-in sensor may also capture speech reverberations because the speakerphone is on the same surface.

Tap 'n Ghost attack

There's a unique type of assault that may steal your PIN without you noticing it. The Tap 'n Ghost attack exploits NFC to obtain your PIN from your phone. Here's how it works: the attacker taps their phone against yours, and then quickly removes their phone before anything happens. This sends a signal to your phone that opens up a special page where you can enter your PIN. Since the page only appears for a split second, most people would not notice it. Even if you do notice it, you won't have time to enter your PIN before the attacker puts away their phone again.

This attack was demonstrated by security researchers at the Black Hat conference in Las Vegas. They showed how they could steal PINs from phones running Android. Then, not long after that, I got hit with this one at Defcon. Thank heavens I was using my burner phone so that I could take photos (this phone doesn't have any accounts or personal information associated with it – I just carry it to take photos at Black Hat and Defcon). So, I was standing to the side minding my own business, trying to put some books I had just bought into my backpack, when an individual came up to me and tried (poor attempt) to social engineer me by saying "What books did you buy?" As I turn to look at him, I felt my phone vibrate in my pocket. I stared at him, pulled out my phone, and he got real nervous. I said "hang on a second" and he turned and walked away real fast... my screen didn't show anything (that's how this hack works), but I was curious why my phone would have vibrated since it had no SIM card in it, the wireless was turned off, Bluetooth was off.... ahhhh, I forgot about the NFC feature! So, yeah, it's a good reminder to be careful when you're using your phone near other phones. And you know my mantra... if you don't use it, TURN IT OFF!

Next, let's talk about how we can lock down an Android device.

Locking down Android devices

When it comes to Android devices, there are a couple of things we need to look at. First, it's important to know about the wonder of app stores and how apps get onto their platforms.

The approval process for applications

This is going to be where Android suffers a tad because developers pay a one-time fee to upload their application to the Google Play Store and the application appears within an hour. However, Apple does statistical analysis to detect any improper usage of their API. This causes the application to take about a week to be approved.

Also, developers are required to pay a $99 developer fee, slightly raising the bar as far as entry into the App Store goes. Android supports installing apps from unknown sources. Can you see where the issue is just by that statement? We call this sideloading. What this means is a user can install an app from a third-party app store. And just because the app says it's signed doesn't necessarily mean it's signed, because Android doesn't care who signs the application. However, Apple only allows users to install iOS applications from its App Store. There's no sideloading natively, so the iOS kernel enforces this security mechanism by only executing signed code by an approved party.

When it comes to which one you should use, it's like choosing between driving a car and taking a flight. If I choose to drive, I risk getting into an accident or being affected by somebody else. A trip on a plane is much safer. Similarly, Apple's approach to its strict control gives the added benefit of a reduced target as far as malware is concerned – not that it's invulnerable. However, Google's approach allows more freedom but comes with more risks.

Other ways to secure Android devices

Here's a great list of items we can consider to help protect our Android devices. Note that these don't include looking at Mobile Device Management (MDM). We'll cover that in a second:

• Updates – not just the OS, but also the apps. Here's the real kicker – after a couple of years, you'll no longer have OS upgrade support from the manufacturer. Samsung just announced in 2022 that they would be expanding their OS support for new devices from 3 years to 4 years. After that time frame (or if you have an older device already), you're forced to upgrade.
• Add user information to your lock screen. My lock screen looks like this:

Figure 12.1 – Using a lock screen's user information

• Do I need to speak about anti-virus or malware protection?
• Use multiple accounts if your device is shared with others.
• Don't download .apk files from any source. Yes, this includes torrents!
• Encrypt your device using the necessary option in your settings feature.
• Read the permissions that an app wants on your device. No game should ever have access to your contacts or phone number.
• Turn off Wi-Fi when you're not using it… please!
• My favorite trick – uninstall apps you're not using. For example, when I'm not traveling, I do not need Uber, so I uninstall it. When I need it, I just reinstall it. This will also improve the performance of the device.
• Use a VPN when you're not on your network. My favorite statement is, "Not your network? It may no longer be your device!"
• Use a password manager.
• Enable two-factor authentication on any app that supports it.

Now, let's move on to the Apple side of things.

Hacking iOS

Now that we've covered hacking Android, let's discuss the process of hacking iOS and its products.

The Apple architecture

Apple is unique, but like Android, it has several different layers.

iPhone Operating System (iOS) is the platform Apple uses for iPhones, iPads, iPods, and other iDevices. It is an integrated system. Apple does not allow iOS to be implemented on non-Apple devices. iOS is simply an intermediary between the hardware and applications.

Applications are not supposed to try to access hardware directly. Instead, they go through several different layers of the architecture.

The core OS

The system level involves the kernel environment, the drivers, and low-level Unix interfaces of the operating system. iOS provides a set of interfaces for accessing many of the features of the operating systems. When folks create applications, those features are handled through the libSystem library. The interfaces are C-based, which gives us the ability to control things such as networking, BSD sockets, locale information, networking components, as well as filesystem access. It's also in charge of DNS services and Bonjour.

The Cocoa application

This is an important layer. It's the main layer that most developers deal with. It's responsible for the interface we see standardized throughout the Apple platform. It's also in charge of the text kit, which is what oversees the way the text is formatted – paragraphs, columns, and pages. It's also in charge of our push notification services. So, we can push text notifications or add a badge to our icon that says, "You've got a notification, you have a new text message."

The media layer

This layer oversees several technologies that deal with media and what you see on the screen – the camera, audio, 2D, and 3D. It uses OpenGL and GLkit, which oversee both 2D and 3D rendering.

The core services layer

This layer has different features associated with it, such as the peer-to-peer services that your device uses to connect or initiate a connection to other devices that are nearby. This is mostly used in games.

iCloud storage

This feature allows you to write applications so that users' documents and data are pushed to the iCloud.

Other architecture layers exist to support iOS, but these are the main ones you need to be concerned about for your exam.

Now, let's discuss jailbreaking.

Jailbreaking

Jailbreaking is different from rooting. Jailbreaking can be compared to what Morpheus could do in The Matrix. He could bend the rules of The Matrix to overcome some restrictions. He could leap across tall buildings but could still be killed within The Matrix. Rooting is what Neo could do. He could not only bend those rules but break them.

What happens during jailbreaking?

When jailbreaking, we start by removing the restrictions that Apple has placed. Most people jailbreak their devices to be able to do things such as load applications that Apple doesn't necessarily want you to utilize. Apple does this for various reasons, including marketing issues such as blocking pop-up ads because some game manufacturers or developers make their money through advertisements.

We can accomplish this by loading up a custom kernel that has root access.

Note

Root access in iOS has a different definition from root access in Android. Once the user gives themself this control, they're able to download applications and software that the app store doesn't want to allow.

It also allows for customization, such as adding themes or extensions that Apple doesn't support. It also lets you unlock the phone. This is how we were able to get AT&T versions of the iPhone to work on the T-Mobile network.

Jailbreaking allows you to use software Apple doesn't think you should have access to and one of the biggest ones is ad blockers.

Another cool feature is being able to untether Hey Siri. This means that normally, we say, "Hey Siri" and iOS picks that up for hands-free operation and voice commands, but it's typically restricted when you have your device plugged into a power outlet. Well, there's an app that allows you to recognize Siri when it's plugged in, or you want to get rid of some of the applications or interface elements. There's one out there called HideMe8, which allows you to hide apps, hide badges, get rid of certain elements, customize the date text, and change the lock screen.

Activator is another nifty item that's out there. It allows you to assign custom actions to gestures and button presses. So, if you wanted to launch Facebook, you could say whenever I do a three-finger swipe, launch Facebook. You could also say that if I short hold the home button, fire up the camera. You can get crazy with customizations. When it comes to dealing with WinterBoard, you can also change your toggle settings so that you can have a toggle for your VPN or personal hotspot. You can even bypass the tethering options so that regardless of whether your carrier allows you to tether or not, you can turn your device into a hotspot, and as far as your carrier is concerned, it's the iPhone or the iDevice that's requesting the data.

Remember, when jailbreaking, we are modifying the security of the device, so we must be careful. Do it if you know what you're doing. I would never jailbreak a device and hand it over to my in-laws or to a kid who doesn't understand what I've done to the device and why I did it.

Types of jailbreaking

There are different techniques for jailbreaking you can implement, as follows:

• Untethered jailbreak: This has the attribute that if a user turns the device off and then back on, the device starts up completely, and without the assistance of a computer, the kernel will be patched.
• Tethered jailbreak: Here, a computer is needed to turn the device on each time it's rebooted. If the device starts up on its own, it's no longer a patched kernel, and it gets stuck in that partially started state. By using a computer, the phone is essentially re-jailbroken each time it turns on, which sounds like a hassle.
• Semi-tethered: When a device boots, it will no longer have a patched kernel, so it won't be able to run any modified code, but it's still usable for normal functions, such as placing calls or texting. To use any features that require modified code to execute, the user must use a jailbreaking tool to start the device with a patched kernel.

Now, let's talk about the three types of jailbreaking.

The three types of jailbreaking

It's important to understand the three main ways you can jailbreak your device. We'll cover them in the following subsections.

The userland exploit

This is a piece of software that runs on the iOS device after the kernel has started. This exploit uses a loophole in the system application. It allows user-level access but does not allow iBoot-level access. These types of exploits cannot be tethered because nothing can cause a recovery mode loop. These types of exploits can and have been patched by Apple.

The iBoot exploit

The iBoot exploit allows for jailbreaking, user-level access, and iBoot-level access. It's an exploit that can be semi-tethered if the device has a new boot ROM. This exploit turns off code signing and runs a program that does all the work for us. This exploit can be patched with some firmware updates.

Boot ROM exploits

This exploit uses a loophole in the secure ROM, which is the first bootloader. It disables the signature checks, which can be used to load a patch or firmware. Firmware updates cannot patch these types of exploits. The boot ROM exploit allows user-level access and iBoot-level access. The only way for them to patch this is for Apple to update the hardware of the boot ROM.

Locking down the Apple platform

As far as locking down the Apple platform is concerned, when it comes to the jailbreaking device, even though you open a plethora of options that Apple doesn't necessarily want you to have access to, you just need to know what those ramifications can include because I can now gain access to the device remotely. Think of that from the attacker's perspective.

For me, the biggest issue is still at the physical level. If an attacker gets physical access to any device – Apple, Android, a PC, laptop, or server – we need to consider what risks come into play as we move around with these devices. We need to batten down the hatches:

• Passcode-lock your device. I know that's a "duh Dale" statement, but I needed to say it.
• Don't sideload apps.
• Disable JavaScript and add-ons from your web browser.
• Don't store sensitive data on any client-side databases.
• If you jailbreak, please change the default root password from "alpine."
• Configure Find My Phone to wipe if the device is lost or stolen.
• Update, update, update. This includes the OS, the apps, and any plugins.
• Disable iCloud services to stop sensitive enterprise data from being backed up to your cloud.
• Enable Ask to Join Networks so that you connect to rogue wireless networks.
• Enable Erase Data after 10 attempts.
• Turn off Siri. She doesn't need to be listening in and logging the things you talk about or what your company is talking about.
• While you're at it, turn off voice dial. Attackers can access your phone without entering your passcode if it's enabled and they have physical access to your device.
• Turn off some of the same protections we saw with Android. This includes turning off secure networks, two-factor authentication, encryption for the device, staying off public Wi-Fi, and stopping clicking on email links.

Now, let's explore MDM.

Mobile device management

MDM is a piece of software that monitors all your mobile devices, allowing us to deploy secure smartphones, tablets, desktops, and laptops.

MDM optimizes and automates the functionality and security of your devices throughout the enterprise in and out of the corporate network. We can control things such as allowing applications to be distributed where data is stored, how the device is configured, which patches to install, and how to handle the device that's been compromised. How about just shoot it, put it out of its misery?

MDMs work with frameworks and each device manufacturer has a framework that injects into the MDM. MDM usually has policies or features that mobile device administrators can control or enforce on these devices.

The combination of these policies and features forms the framework. Android, Blackberry, and Apple provide MDM frameworks to allow administrators and MDM vendors to simply link to their devices.

There are a bazillion different MDM software solutions out there, but these are the big boys:

• AirWatch: This is handled by the same people who developed VMware.
• System Center Configuration Manager: This is by Microsoft, and it supports the mobile Windows platform, Android, and iOS. It requires an additional component, Intune, a monthly subscription for you to be able to manage your devices when they're not inside of your network infrastructure. Intune acts as a proxy for you. It has a connection to the internet, your devices make a connection to it, and it relays it back to your system center configuration manager on the backend.
• Spiceworks: This is completely free and doesn't take up a lot of configuration or servers.

The overall concept here is to make sure you have some options when it comes to not only supporting organization-issued devices but also controlling Bring Your Own Devices (BYODs). It's a fine line of controlling personal devices while protecting resources, but I get it, it's a cost-saving issue for most companies as well as an annoyance issue for employees having to carry two of the same devices. Oh, I could go off about BYODs and the reasons to not utilize them, but that would be another book in itself.

Now, let's talk about the importance of guidelines and some cool tools you can use.

Guidelines and cool tools

When it comes to guidelines, I can't think of a better phrase than Pirates of the Caribbean's Captain Barbosa's words, "The code is more what you'd call "guidelines" than actual rules."

There are some good guidelines when it comes to mobile devices. Let's discuss some of them:

• Apps: One of the biggest issues I see out there right now with the mobile platform is that people load up too many apps.
• Photos: Try to be careful about automatically uploading photos to social networks. When I do presentations for communities, specifically for parents, I talk about how we're sharing way too much information. Sometimes, we don't even realize it. We post photos on Facebook without looking at the photo. What's in the background? Are you exposing your address or other personal or family information? Be careful not to put up too much information.
• Control: Can you maintain control of these devices? If you lose control of them, it's time to get them back in the office and reassociate.
• Security assessment: Do security assessments on the devices, the application, and its architecture.
• Trusted applications: Only install applications from trusted locations. I sideload all the time to make some useful applications available on my tablet.
• Location: Don't add any location-based features unless there's a component that supports the application. Don't load Google Maps if you don't need it. I know most Android devices come with those applications pre-installed but you also need to be careful of applications that want to look at your location. Only allow it if it's important.
• Bluetooth: Turn your Bluetooth off if you don't need it, especially while traveling. You'll get a little bit of extra battery life too.
• Connecting to separate networks: Don't connect to two networks at the same time, such as Wi-Fi and Bluetooth, as an attacker can use one network to pull information from the other.
• Backup: Do backups and check how often your devices are synchronizing, especially if they're synchronizing outside of your network.
• Passwords: Use strong passwords.
• Idle timeout: Set the idle timeout to automatically lock when the phone is not in use. My phone locks automatically when I hit the power button.
• Lockout and wipe features: Take advantage of the lockout and wipe features. If somebody types in my code incorrectly four times, my device gets wiped.
• Jailbreaking and rooting: A best practice by EC Council is to never allow rooted or jailbroken devices. However, I enjoy rooting my devices because when Stagefright came out for the Android, if I hadn't rooted my device, I would have waited until Samsung came out with a fix. However, because I run a custom ROM, it took the author of that ROM 2 days to come out with the patch and I was able to redeploy and be locked down.
• Updates: Keep all applications and the OS itself up to date. However, review the changes all the updates want to accomplish – don't hit Apply all; you could be lowering the security profile of your device because the application could sneak in a new game, for example, and the new patch gives them access to all your contacts.
• Hardware encryption: This is like encrypting the hard drive on a PC. If somebody steals your PC and they don't know the encryption key to type in when they boot up, they're not getting the data.
• MDM: Review your MDM policies. This comes down the road of change management because when you come up with these policies, you need to make sure there's complete agreement across departments on what is allowed and what's not allowed.
• Emails: Filter email forwarding barriers because most of our malware is coming across via email. Do we want those heading out to our devices? Some newer email servers make filtering easy. You can set a filter to only allow emails that are generated internally to be forwarded to mobile devices – don't forward emails from advertisers.
• Browsers: Harden up the browsers on these devices. This includes permission rules to ensure when somebody visits a page on these devices, they're not getting injected with some code that's going to jailbreak them or root them.
• Signed applications: Only use signed applications, meaning they've been signed by the app stores, or have been signed for internal use.
• Erase data: Set up to erase data to keep people from guessing passwords on the devices.
• Auto-lock: Ensure you have auto-locking turned on.
• Backup location: Make backups and locate them in a secure location.
• Password: Require a passcode. Studies show that people use patterns after the alphabet, giving attackers an easy time. They need a few guesses, starting with the initials.
• Software maintenance: Have a software maintenance plan in place. If there's an app you haven't used in 90 days, you probably don't need it.
• Sandbox data and the app: If you're a developer, sandbox data and the apps to avoid cross-infection.
• Wi-Fi: Always make sure someone must ask to join. Windows 10 allows devices to automatically join known Wi-Fi access points – not the ones you know but the ones Microsoft is aware of. That's risky.
• Emails: Don't allow emails to be cached. Even though you've deleted the email, it's still in the cache. If I get that device, I'll be able to read that information.
• Data: As a company, decide whether data can leave the environment. Do we allow people to send the payroll spreadsheet via email so that Bruce Wayne can open the spreadsheet on his device? Why not use the newer technologies, such as Share File Options, where I don't send you a copy of the file? Instead, I give you a URL link back to our SharePoint server or maybe back to a Dropbox location. That way, I don't have files leaving the environment.
• Google: When it comes to Android, watch what Google is backing up, what they're storing, what they're cashing, and all the data that they're collecting.
• Notifications: Turn off notifications on the lock screen so that someone must unlock it to see them.
• Turn off autofill: This is about convenience. The challenge with this is that if an attacker gets access to the computer, it becomes a liability as an attacker could easily get significant access to many things.
• Users: One of the best things you could ever do is train your users on how to use these devices, as well as what's acceptable and what's not acceptable. Make sure there are written policies in place so that they understand what the consequences are, and hold them to those consequences if they break them.
• Timeout: If users are getting in remotely, how long do you allow them to stay inactive before the session times out? It's annoying to keep typing in a username and password but don't cache domain passwords. That's as reckless as posting all your passwords on Facebook, Twitter, and Google Plus.

Okay, so who here is now thinking a little differently about mobile devices?

Summary

It's important to remember the shift we are experiencing as more and more is being done and transacted on mobile devices and less on desktops and laptops. Because of the mobility of these devices, we must prepare ourselves and how to best deal with the unique challenges and vulnerabilities that mobile platforms present to us. In this chapter, we provided an overview of how we can prepare to attack and protect ourselves on a mobile platform. We reviewed the key terms we must know when it comes to hacking mobile platforms. We also discussed hacking iOS, Android, and other mobile platforms before covering the importance of MDM.

In the next chapter, we will cover hacking web servers and web apps.

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. What are the advantages of encrypting mobile devices?
   1. Data sent to websites is protected
   2. Malware protection
   3. Protection against gadgets that have been stolen
   4. Data security on lost or stolen devices
2. What does it mean to jailbreak a phone?
   1. Removing DRM from a system
   2. Getting rid of ransomware from a computer
   3. Removing a device from a network
   4. Taking control of a device by gaining root access
3. Which operating system is Android based on?
   1. Windows
   2. Linux
   3. OS X
   4. macOS
4. What is the impact of rooting a device on security?
   1. It improves it.
   2. It is hardened.
   3. It diminishes it.
   4. No change.