I’m certain you’ve seen The Matrix series of movies. In short, the movies postulate that we’re not actually alive, breathing and interacting with each other—we’re actually all just jacked into a huge computer program simulating everything we perceive as real. There’s a big temptation here for me to launch into perception versus reality, dimensional variations and destiny versus free will, but this is a tech book, not a philosophy class, so I’ll avoid it. No, what I want to talk about here is the real-life Matrix you may not even be aware you’re plugging into—the Internet of Things and Internet Everywhere.

I tried to find a single definition of the Internet of Things, but none of them adequately fit the bill for me, so I decided to take a different tack. No matter where you are, glance around for a second and pick out the things you think are on, or should be on, your network. I’m sure you can identify some objects pretty quickly. Just a couple years back you’d point out your cell phone and your PC. Today, you may even point out other electronic devices that are obvious—your TV, refrigerator, and maybe even your microwave. Also, there’s your car. But take a closer look. Expand your imagination for a second.

Your toothbrush might have something to say. Maybe your kitchen counter could help with a bunch of things, too. Your pantry sure has lots to say about what you need to buy—not to mention that potato you’ve forgotten about rotting on the floor in the corner. The road and toll booths have information, too. Light bulbs, plumbing systems—heck, maybe even your cat has valuable information. The Internet of Things is, or soon will be, all of that.

It’s a great thing to think about, and the benefits to us all in that future dream are fantastic. But it is a little scary when you think about it. Not only could all these things be accessed from afar (just imagine trying to secure all this), but what happens when they all start talking to each other without you even needing to be a part of the conversation? Suppose, for example, your toilet and plumbing system notice some disturbing health indicators in your, uh, creations. What if they just go ahead and schedule your appointments for you? Sound good? Well, what if that information is used to demonstrate your unworthiness as an insurance policy holder, or to pass laws making sure everyone eats at least two bowls of kale a day?

Or what if they’re hacked by a bad guy and you’re held ransom by your toilet? It’s all really concerning if you consider how much harm all this access and technology can cause individuals and organizations. I’m not ready to pull the plug and go off the grid just yet, but I’m wondering just how invasive this can all get, and I’m concerned that by the time we figure out we don’t want it, it will be too late. Not to mention I don’t want the cat talking to anyone. Ever.

This chapter is all about the mobile world and the Internet of Things. It’s brand new, longer than most in this book, and packed with information. So climb into Neo’s chair there, jack into the Matrix, and grab the red pill. I’ve got some things to show you…

The Mobile World

Forget the coming zombie apocalypse—we’re already there. If you’ve been outside anywhere in the United States over the past couple of years, you can’t help but notice it just as I have: most people are stumbling around, with vacant expressions on their faces, and only half-heartedly engaging the world around them. Why? Because they spend most of their waking hours staring down into a smartphone or tablet. And if you’re a parent reading this book and your teenagers can make it through an entire meal without picking up a phone to text, take of picture of what they’re eating, or post an update of their exciting life (“Johnny is eating spaghetti—FOR BREAKFAST!”), you probably should be nominated for some sort of award.

But come on, admit it: you’re probably one of them, too. We’ve allowed mobile computing to become so much a part of our lives, it’s here to stay. We chat over our mobile devices, play games with them, do our banking over them, and use them for all sorts of business. According to Google Analytics, from April of 2011 to January of 2017, smartphone ownership within the U.S. population went from 34 percent to a whopping 77 percent of adults, and mobile digital usage stats showed fully 70 percent of all online time was spent on mobile devices. The laptop may not be dead as far as a target, but the mobile army is certainly closing in. Because of all this, EC-Council focuses an entire chapter of its official courseware on mobile platforms, and I’ll do our best to cover it all for you here.

Mobile Vulnerabilities and Risks

Companies the world over are struggling with implementing policy to contain all this growth. BYOD (Bring Your Own Device) offers some exciting opportunities in potential cost savings and increased productivity, but at what risk? If Bob uses his own smartphone and keeps company secrets on it, what happens if/when it gets stolen? Even if the smartphone (or tablet) in question isn’t owned by the company, and even if it’s not allowed access to super-secret-squirrel areas, is it possible Jane could store information on it that puts all that information at risk?

While digging through the dumpster for useful information is still a good idea for the ethical hacker, a little focus on mobile may definitely be worth your while. A bunch of users possibly storing sensitive organization information on devices that aren’t centrally controlled, have little to no security built into them, and have multiple avenues of connectivity (wireless, Bluetooth, and/or 3G/4G)? That sounds like a target-rich environment to me.

Attacking mobile platforms should be a part of any hacking endeavor and should definitely become part of your arsenal. The bad news is, this will be tested, there’s a lot to remember, and, as always, some of it is weird and off the rails. The good news is, despite ECC devoting an entire chapter to the subject, a lot of this you already know—or should, assuming you don’t live under a rock and can read. For example, were you aware there are multiple operating systems available for mobile (GASP! You don’t say?!?), that Android and iOS devices can be rooted/jailbroken (SHOCKING!), and that applications not specifically written by Google or Apple engineers can be put on smartphones and tablets (SAY IT AIN’T SO!!)? In this convenience versus security realm, I’ll cover what you need and, as always, try to dump the fluff.

When it comes to smartphones, there are three main avenues of attack—three surface points to look at. First is the device itself, which offers tons of options. Everything from browser-based attacks (like phishing) to attempts over SMS and attacks on the applications themselves belong in this realm. And don’t forget rooting or jailbreaking the device itself (don’t worry—we’ll cover more of that later in this chapter). Next are the network attacks, covering everything from DNS cache poisoning to rogue access points and packet sniffing. These attacks should sound very familiar, as we’ve covered them already and they work just as well here as they do against web servers and wireless laptops. And, finally, data center or cloud attacks in the mobile world exist just as they do everywhere else, so don’t think you can get away with not worrying about those databases and such here either.

OWASP Top 10 Mobile Risks

Remember our discussion on OWASP back in Chapter 6? Back then we were talking web servers and all things hacking related to it. But remember when I said they do bunches of other stuff? Welcome to that stuff…

The Open Web Application Security Project (OWASP) has an arm dedicated specifically to mobile security (https://www.owasp.org/index.php/OWASP_Mobile_Security_Project; see Figure 8-1) and publishes a list of Top 10 mobile risks. Much like our previous discussion on their other Top 10 list, we’ll go over each listed vulnerability and give you everything you need to know. The current Top 10 (https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10) includes the following vulnerabilities:

Figure 8-1 OWASP Mobile Security Project

•   M1 – Improper Platform Usage   This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk.

•   M2 – Insecure Data Storage   This category combines a couple entries from the previous list (2014) and covers insecure data storage and unintended data leakage. Threat agents include an adversary who has attained a lost/stolen mobile device as well as malware (or another repackaged app) acting on the adversary’s behalf that executes on the mobile device.

•   M3 – Insecure Communication   This covers poor handshaking, incorrect SSL versions, weak negotiation, clear-text communication of sensitive assets, and other insecure communication channels or methods. For example, poor SSL setup can also facilitate phishing and MITM attacks.

•   M4 – Insecure Authentication   This category captures notions of authenticating the end user or bad session management. Examples include failing to identify the user at all when it should be required, failure to maintain the user’s identity when it is required, and weaknesses in session management.

•   M5 – Insufficient Cryptography   This category refers to instances where code applies cryptography to a sensitive information asset; however, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all when it should, that probably belongs in M2. This category is for issues where cryptography was attempted, but it wasn’t done correctly.

•   M6 – Insecure Authorization   This category captures any failures in authorization (authorization decisions in the client side, forced browsing, and so on). It is distinct from authentication issues (device enrolment, user identification, and so on). Remember, authentication proves who you are, whereas authorization proves you have a right to access a particular resource. For example, if the app grants anonymous access to some resource or service when the use should have first been authenticated, then that is an authentication failure, not an authorization failure. If the app does authenticate users but puts no authorization protections on memory areas or other resources, that would fall under M6.

•   M7 – Client Code Quality   This is a catchall for code-level implementation problems in the mobile client that are distinct from server-side coding mistakes. This encapsulates things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that’s running on the mobile device.

•   M8 – Code Tampering   This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification. Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources.

•   M9 – Reverse Engineering   This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application. This may be used to exploit other vulnerabilities in the application, as well as revealing information about back-end servers, cryptographic constants and ciphers, and intellectual property.

•   M10 – Extraneous Functionality   This is another catchall for something coders do all the time: build in a backdoor. These are never intended to be released into a production environment, but they usually pop up in the weirdest places. Examples include a developer accidentally including a password as a comment in a hybrid app or disabling two-factor authentication during testing and forgetting to turn it back on.

Mobile Platforms and Attacks

When it comes to mobile platforms, there are two major players in the field—Android and iOS—with Blackberry bringing up the rear (see Figure 8-2). Android was created by Google specifically for mobile devices, and it contains an OS, middleware, and a suite of built-in applications for the mobile user. It offers a framework that allows reuse and replacement of components, media support for virtually everything you can imagine, a development environment to beat the band, and really cool names for each release (like Ice Cream Sandwich, Jelly Bean, Éclair, and Honeycomb). Head on over to www.android.com and you’ll find more than you ever wanted to know about it.

Figure 8-2 Mobile device operating systems

iOS, on the other hand, is Apple’s operating system for mobile devices—that is, the iPhone and iPad (you will also find iOS on Apple TV and iPods). Apple made its mark in the desktop world, targeting entertainment and education, and its mobile OS is no different. iOS was designed from the get-go for mobile devices, using direct manipulation (touch gestures) to interface with the OS. Built-in applications include everything from entertainment to an AI with a woman’s voice that answers questions for you (Siri). A good review of everything on the current release can be found at www.apple.com/ios/.

Whether Android or iOS, one thing you will get asked about is rooting or jailbreaking the device. Both mean the same thing: perform some action that grants you administrative (root) access to the device so you can do whatever you want with it, and there are hundreds of videos on online “how-tos” on getting it done. Rooting—the name given to the process on an Android device—is such a common, ubiquitous action it’s almost not thought of as technical anymore. And there are multiple tools to help you in your Android rooting efforts. One such groovy tool is KingoRoot (https://www.kingoapp.com), and it makes the whole process ridiculously easy with or without a laptop or PC handy. Others are TunesGo (https://tunesgo.wondershare.com), OneClickRoot (https://oneclickroot.com), and MTK Droid (https://androidmtk.com).

As far as jailbreaking an iOS device (which, just like rooting, invalidates every warranty you can think of), some tools include evasi0n7, GeekSn0w, Pangu, Redsn0w, Absinthe, and Cydia. There are three basic techniques and three different types, regardless which tool you want to try. Techniques include untethered, semi-tethered, and tethered:

•   Untethered jailbreaking   The kernel will remain patched (that is, jailbroken) after reboot, with or without a system connection.

•   Semi-tethered jailbreaking   A reboot no longer retains the patched kernel; however, the software has already been added to the device. Therefore, if admin privileges are required, the installed jailbreaking tool can be used.

•   Tethered jailbreaking   A reboot removes all jailbreaking patches, and the phone may get stuck in a perpetual loop on startup, requiring a system connection (USB) to repair.

And the three types of jailbreaking include Userland, iBoot, and BootROM:

•   Userland exploit   Found in the system itself, which is leveraged to gain root access, modify the fstab, and patch the kernel. These types of exploits cannot be tethered because nothing can cause a recovery mode loop, but they can be patched by Apple. This exploit provides user-level access but not admin.

•   iBoot exploit   Found in one of the device’s bootloader, called iBoot (the other bootloaders are called SecureROM and LLB). It uses a vulnerability in iBoot to turn codesign off, and runs a program that gets everything done. iBoot exploits can be semi-tethered, and they can be patched by Apple.

•   BootROM exploit   Allows access to the file system, iBoot, and custom boot logos, and is found in the device’s first bootloader, SecureROM. This kind of exploit can be untethered, but cannot be patched by Apple: it’s hardware, not software.

When it comes to mobile vulnerabilities, no matter the platform, it’s almost laughable to ask about them. These are devices owned and operated mainly by users who can roam at will and can install virtually anything at all on them at will, for any reason. Security concerns? You betcha. Mobile platforms have gobs of vulnerable attack points warranting your attention, including everything from server-side controls to client injection and more. (Refer back to the list of Top 10 mobile risks covered earlier.) A hacker can take advantage not only of data on the device but also the camera and microphone—how neat would it be to listen in on or even watch a board meeting, hmm?

Many of the vulnerabilities and attack vectors we talked about on everything else also apply to mobile. Just as with web hosts, perhaps the most obvious attack vector comes from the apps themselves. App stores may not have any vetting of apps at all when entering the marketplace and are often used to distribute malicious code. From iPhones to Android devices, users download and install applications for everything from working on documents to faking a Star Wars lightsaber for impromptu interoffice Jedi battles (Obi-Wan’s is my personal favorite). Most users don’t even think about it—they just click the link, install the app, and start playing—and many don’t even bother to read or care about what the app is asking for, permissions-wise, on the device. Got an app for hacking? You bet we do, and if it’s tied to a fun-looking application, all the better.

How about social engineering, phishing, and (gulp!) physical security? Mobile users are as, if not more so, susceptible to all of it as their desktop peers. There’s not really a community standard mechanism for dealing with spam and phishing, and because mobile users are always on, it works quite well as an attack vector. What about theft or loss of the devices themselves? It’s one thing to black widow a website and peruse it on your own or to grab a SAM file and spend time pounding away on it, but what if you could just steal the whole dang server? In effect, that’s what’s going on with these things. In addition to any files or data the user has on the phone, a smartphone has all the data, contacts, phone numbers, and e-mails you’d need to set up social engineering attacks in the future.

And speaking of attack vectors, as we’ve briefly mentioned earlier, I’m sure you’re aware of BYOD—Bring Your Own Device—sweeping across organizations faster than hot doughnuts off the Krispy Kreme rollers. BYOD allows companies to take advantage, for free, of all that computing power we’re all walking around with in our hands. The problem with it is security and control, and that problem is we don’t really have any. Sure, we’re trying some things here and there and feel like we have some measure of control, but the reality of the situation from a pen testing (or hacking) perspective is, it’s a good time to be alive.

Mobile Device Management (MDM) is an effort to add some control to enterprise mobile devices. Much like Group Policy and such in the Microsoft Windows world, MDM helps in pushing security policies, application deployment, and monitoring of mobile devices. Most MDM solutions offer the same basic features: passcodes for device unlocking, remote locking, remote wipe, root or jailbreak detection, policy enforcement, inventory, and monitoring/reporting. Some solutions are XenMobile, IBM MaaS360, AirWatch, and MobiControl.

Want more? Consider the connectivity these devices provide for users. Most folks hate security and turn off everything they can to make life easier for themselves, and that goes for Wi-Fi connectivity on phones too. There are tons of open Wi-Fi spots all over the place that people use with their smartphones and tablets, and sniffing these types of connections is ridiculously easy. Throw in location awareness and spyware apps, and this all gets pretty scary pretty quickly.

Frightened yet? Heck, we’re not even done with the platform spectrum. Any real discussion on wireless standards and architecture must at least mention 3G, 4G, and Bluetooth. 3G and 4G refer to third- and fourth-generation mobile telecommunications, respectively, and offer broadband-type speeds for data usage on mobile devices (cell phones and such). The actual technology behind these transmission standards is tweaked from mobile carrier to mobile carrier, so unlike a wireless NIC complying with 802.11g working with any manufacturer’s access point with the same standard, one company’s devices may not work with another’s on 3G or 4G.

Bluetooth refers to a very open wireless technology for data exchange over a relatively short range (10 meters or less). It was designed originally as a means to reduce cabling but has become a veritable necessity for cell phones and other mobile devices. Part of what makes Bluetooth so susceptible to hacking is the thing that makes it so ubiquitous—its ease of use. Bluetooth devices are easy to connect one to another and can even be set to look for other devices for you automatically. Bluetooth devices have two modes: a discovery mode and a pairing mode. Discovery mode determines how the device reacts to inquiries from other devices looking to connect, and it has three actions. The discoverable action obviously has the device answer to all inquiries, limited discoverable restricts that action, and nondiscoverable tells the device to ignore all inquiries.

Whereas discovery mode details how the device lets others know it’s available, pairing mode details how the device will react when another Bluetooth system asks to pair with it. There are basically only two versions: yes, I will pair with you, and no, I will not. Nonpairable rejects every connection request, whereas pairable accepts all of them. Between discovery and pairing modes, you can see how Bluetooth was designed to make connection easy.

So in addition to the, roughly, billion or so new smartphones that will be sold this year, a growing populace (in and out of the business world) carrying, adjusting, manipulating, and rooting these devices at will, and the ease with which data can be stored on them with little to no oversight or security control, you have to be aware of short-reach wireless connectivity that may offer virtual control over these devices. We also have virtually nowhere to hide with them, since 3G and 4G reach nearly everywhere. Sleep well tonight, security folks. Sleep well.

Mobile Attacks

Attacks on mobile devices abound. First and foremost, phishing attacks and social engineering are merciless when it comes to mobile devices. I’m sure you’re all familiar with good-old SMS (text) messaging, but have you ever thought about SMS phishing? While our users at least think about whether or not they should click a link in e-mail, a text message is another thing altogether. Almost every vendor from airlines to UPS packaging gives you an option to get your updates via text, and the practice is growing quickly. How easy would it be to just send User Joe a text message telling him, “You have a package coming. Click Here to track”? Definitely something to think about.

The list of Trojans available is almost without end. Notable Android Trojans include Obad, Fakedefender, TRAMP.A, and ZitMo. Spyware is really scary, and tools like Mobile Spy and Spyera make it really easy to listen in on or even watch what the target is doing. And if that’s not enough, the tools we use to manage our own devices can be used against us. Ever heard of Google Voice? How about Remote Wipe from Google? One loose password and mobile device hacking becomes a nightmare. How about tracking where I’m at all the time? Tools like AndroidLost, Find My Phone, and Where’s My Droid were designed to help me find my lost phone, but they (and many, many others) can be used to track where I happen to be at. Wouldn’t it be helpful to know where folks are at during a social engineering visit to the site?

And how about using your mobile device as an attack platform? Tools like Network Spoofer allow you to control how websites appear on a desktop/laptop. DroidSheep allows you to perform sidejacking by listening to wireless packets and pulling session IDs. Nmap works great on a mobile device, and sniffers are a dime a dozen. Heck, you can even install Kali Linux on the thing and turn it into a full-featured hacking machine.

Finally, we can’t finish any wireless attack section without visiting our friendly little Bluetooth devices. After all, think about what Bluetooth is for: connecting devices, usually mobile (phones), wirelessly over a short distance. And since we keep everything on our devices (e-mail, calendar appointments, documents, and just about everything else you might find on a business computer), it should seem fairly obvious, then, that hacking that signal could pay huge dividends.

Bluetooth definitely falls into the wireless category and has just a few things you’ll need to consider for your exam and for your career. Although hundreds of tools and options are available for Bluetooth hacking, the good news is their coverage on the exam is fairly light, and most of it comes in the form of identifying terms and definitions. The major Bluetooth attacks are listed here:

•   Bluesmacking   A simple denial-of-service attack against the device.

•   Bluejacking   Consists of sending unsolicited messages to, and from, mobile devices.

•   Bluesniffing   An effort to discover Bluetooth-enabled devices—much like war driving in wireless hacking.

•   Bluebugging   Successfully accessing a Bluetooth-enabled device and remotely using its features.

•   Bluesnarfing   The actual theft of data from a mobile device due to an open connection—such as remaining in discovery mode.

•   Blueprinting   Think of this as footprinting for Bluetooth: Blueprinting involves collecting device information over Bluetooth.

Although they’re not covered in depth on your exam, you should know some of the more common Bluetooth tools available. Of course, your first action should be to find the Bluetooth devices. BlueScanner (from SourceForge) does a great job of finding devices around you, but it will also try to extract and display as much information as possible. BT Browser is another great, and well-known, tool for finding and enumerating nearby devices. Bluesniff and btCrawler are other options, providing nice GUI formats for your use. As far as attacks go, Blooover is a good choice for Bluebugging, and PhoneSnoop is good for spyware on a Blackberry.

In a step up from that, you can start taking advantage of and hacking the devices nearby. Super Bluetooth Hack is an all-in-one software package that allows you to do almost anything you want to a device you’re lucky enough to connect to. If the device is a smartphone, you could read all messages and contacts, change profiles, restart the device, and even make calls as if they’re coming from the phone itself.

IoT

I suppose before discussing anything, and especially before discussing a topic so important EC-Council created a whole new chapter in its official curriculum for it, we’d need to first define the topic at hand. I looked up several definitions of the Internet of Things (IoT) and found more variations on this definition than I thought imaginable. Want a try at it? Well, the best I can do is an amalgamation of what I’ve read in several resources: the IoT is a collection of devices using sensors, software, storage, and electronics to collect, analyze, store, and share data among themselves or to a user. Sound far reaching and a little broad? It probably is, but the reason for that is self-evident: the IoT is everywhere, and expanding by the minute.

Just look around you right now, wherever you are. Chances are there’s an IoT device nearby. Your phone, watch, printer, vacuum, refrigerator, toothbrush (maybe), light bulbs, electrical outlets, thermostat for your A/C unit, and your water heater are all probably right now, or will be soon, collecting and sharing information. I even read somewhere there’s now Internet-enabled underwear. And that’s just inside your house. Forget the cars on the road—that’s too obvious—how about the road they’re driving on, the surveillance cameras, streetlights, traffic signals…it’s literally endless and downright mind boggling. So forgive EC-Council, and me, if we can’t really get a handle on it just yet. It’s literally too much to squeeze down into a short description.

A couple definitions I saw in EC-Council reading and online I think may add a little clarity, at least to where we’re heading here anyway. One is, the IoT refers to a network of devices with IP addresses that have the capability of sensing, collecting, and sending data to each other—basically a web of connected devices made possible by machine-to-machine communications, large availability of storage, and internetworked communications. Another source listed IoT as technologies extending Internet connectivity beyond “standard” devices, such as desktops, laptops, smartphones, and tablets, to any range of traditionally non-network-enabled physical devices and everyday objects. And I think that is the crux of the whole thing—we traditionally have thought of certain, specific devices belonging on a network, and those specific devices behaving accordingly. The IoT has taken that to a whole new level by making everything internetworked.

So how does this all fit together? And how can we hope to defend it? Hopefully that’s what the remainder of this chapter will help to answer.

IoT Architecture

Since IoT is, by nature, changing all the time and adding ever new and inventive ways to use devices for data gathering—I can’t wait for Internet-enabled toenail clippers—trying to nail down an architecture for the whole thing seems like a fool’s errand. I mean, we can certainly take apart a specific network and look at each device enabled on it, but the entirety and breadth of each and every one? Impossible. What we can do is look at some things that are common across the board and try to categorize them for study as best we can. This isn’t, and will never be, comprehensive in nature—as fast as the IoT is growing, I’m certain there will be new information out before we even get to print—but we will follow EC-Council’s lead here and, for the most part, I think you’ll find it pretty good.

How it all works comes down to three basic components—things using sensing technology, IoT gateways, and the cloud (or put another way, data storage availability). A thing inside the IoT is defined as any device implanted somewhere with the ability (and purpose) of communicating on the network. Each embedded with some form of sensing technology, IoT devices can communicate and interact over the Internet, and oftentimes can be remotely monitored and controlled. In other words, sensors are embedded in the devices to measure and forward data (for example, a medical device sensing a patient’s health statistics or the Nest thermostat implanted in your A/C system, providing information and feedback on its use).

Those things communicating with each other must have a couple items intact in order to work. The first is some sort of operating system allowing all this data collection and analysis in the first place. EC-Council nicely provides a quick list for your amusement and perusal:

•   RIOT OS   It can run on embedded systems, actuator boards, and sensors, uses energy efficiently, and has very small resource requirements.

•   ARM mbed OS   This is mostly used on wearables and other devices that are low-powered.

•   RealSense OS X   Intel’s depth sensing version, this is mostly found in cameras and other sensors.

•   Nucleus RTOS   This is primarily used in aerospace, medical, and industrial applications.

•   Brillo   An Android-based OS, this is generally found in thermostats.

•   Contiki   This is another OS made for low-power devices; however, it is found mostly in street lighting and sound monitoring.

•   Zephyr   This is another option for low-power devices, and devices without many resources.

•   Ubuntu Core   This is used in robots and drones, and is also known as “snappy.”

•   Integrity RTOS   This is primarily found in aerospace and medical, defense, industrial, and automotive sectors.

•   Apache Mynewt   Devices using Bluetooth Low Energy Protocol make use of this.

And once devices have all that data prepared, they need a network of some sort to communicate on. Mostly this is done over wireless communications in all its various forms and generally follows one of four IoT communication models—device to device, device to gateway, device to cloud, or back-end data sharing. All work exactly as their name suggests, with only a couple of knowledge nuggets you can tuck away for test purposes. Device to device and device to cloud are pretty straightforward, with the things communicating directly with each other or shooting their data off directly to a cloud. Device to gateway adds a collective before sending to a cloud, which can be used to offer some security controls. Finally, the one outlier, back-end data sharing, is almost exactly like device to cloud; however, it adds the ability for third parties to collect and use the data. Figure 8-3 displays device to gateway and back-end data sharing for your comparison.

Figure 8-3 IoT communication models

Once a thing has sensed and collected data, it forwards to the next component, the IoT gateway. This is designed to send collected data from devices to the user or to the third component, data storage or cloud, for use later. The cloud stores and analyzes data, providing information back for future queries. A fitness watch, for example, may provide you, the user, immediate feedback and information on your workout while simultaneously storing details for your comparison and review later.

In addition to the basic components, EC-Council lists a few architecture layers inside IoT. These aren’t tricky, they don’t require weird mental gymnastics to remember, and seem to make a lot of common sense:

•   Edge Technology Layer   This layer consists of sensors, RFID tags, readers, and the devices themselves.

•   Access Gateway Layer   First data handling takes place in this layer, with message identification and routing occurring here.

•   Internet Layer   This is a crucial layer, as it serves as the main component to allow all communication.

•   Middleware Layer   This layer sits between the application and hardware layers, and handles data and device management, data analysis, and aggregation.

•   Application Layer   This layer is responsible for delivery of services and data to the user.

Regarding the architecture, just remember how quickly IoT is growing and evolving. I did a search for IoT trends and found over 60 million pages of information to peruse. Keep your eye out and read all you can on it. IEEE maintains a journal on all things IoT (https://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=6488907), and ITU has a great collection of news articles about current IoT efforts (https://www.itu.int/en/ITU-T/ssc/resources/Pages/topic-001.aspx). In other words, make use of all these search engines we have available and try to keep up. It’ll help, both on your exams in the future and your job.

IoT Vulnerabilities and Attacks

Remember OWASP? Well, guess what? They’re back again, this time helping us to identify vulnerabilities and issues inside the IoT realm. The OWASP Top 10 for IoT (https://www.owasp.org/index.php/Top_IoT_Vulnerabilities) is called out explicitly in the official courseware and is listed here for you (you’re welcome):

•   I1 – Insecure Web Interface   An insecure web interface can be present when issues such as account enumeration, lack of account lockout, and weak credentials are present. Insecure web interfaces are prevalent, as the intent is to have these interfaces exposed only on internal networks; however, threats from the internal users can be just as significant as threats from external users. Issues with the web interface are easy to discover when examining the interface manually, along with using automated testing tools to identify other issues such as cross-site scripting.

•   I2 – Insufficient Authentication/Authorization   Authentication may not be sufficient when weak passwords are used or are poorly protected. Insufficient authentication/authorization is prevalent, as it is assumed that interfaces will only be exposed to users on internal networks and not to external users on other networks. Deficiencies are often found to be present across all interfaces. Many issues with authentication/authorization are easy to discover when examining the interface manually and can also be discovered via automated testing.

•   I3 – Insecure Network Services   Insecure network services may be susceptible to buffer overflow attacks or attacks that create a denial-of-service condition, leaving the device inaccessible to the user. Denial-of-service attacks against other users may also be facilitated when insecure network services are available. Insecure network services can often be detected by automated tools such as port scanners and fuzzers.

•   I4 – Lack of Transport Encryption/Integrity Verification   Lack of transport encryption allows data to be viewed as it travels over local networks or the Internet. Lack of transport encryption is prevalent on local networks, as it is easy to assume that local network traffic will not be widely visible; however, in the case of a local wireless network, misconfiguration of that wireless network can make traffic visible to anyone within its range.

•   I5 – Privacy Concerns   Privacy concerns generated by the collection of personal data in addition to the lack of proper protection of that data is prevalent. Privacy concerns are easy to discover by simply reviewing the data that is being collected as the user sets up and activates the device.

•   I6 – Insecure Cloud Interface   An insecure cloud interface is present when easy-to-guess credentials are used or account enumeration is possible. Insecure cloud interfaces are easy to discover by simply reviewing the connection to the cloud interface and identifying if SSL is in use or by using the password reset mechanism to identify valid accounts, which can lead to account enumeration.

•   I7 – Insecure Mobile Interface   An insecure mobile interface is present when easy-to-guess credentials are used or account enumeration is possible. Insecure mobile interfaces are easy to discover by simply reviewing the connection to the wireless networks and identifying if SSL is in use or by using the password reset mechanism to identify valid accounts, which can lead to account enumeration.

•   I8 – Insufficient Security Configurability   Insufficient security configurability is present when users of the device have limited or no ability to alter its security controls. Insufficient security configurability is apparent when the web interface of the device has no options for creating granular user permissions or for forcing the use of strong passwords, for example. Manual review of the web interface and its available options will reveal these deficiencies.

•   I9 – Insecure Software/Firmware   The lack of ability for a device to be updated presents a security weakness on its own. Devices should have the ability to be updated when vulnerabilities are discovered, and software/firmware updates can be insecure when the updated files themselves and the network connection they are delivered on are not protected. Software/firmware can also be insecure if it contains hardcoded sensitive data such as credentials.

•   I10 – Poor Physical Security   Physical security weaknesses are present when an attacker can disassemble a device to easily access the storage medium and any data stored on it. Weaknesses are also present when USB ports or other external ports can be used to access the device using features intended for configuration or maintenance.

As with the mobile vulnerabilities mentioned previously, be sure to examine everything OWASP has to offer on the project home page:

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Vulnerabilities

You’ll be able to keep up with the list as it updates and read up on any new developments that may wriggle their way into your exam.

Lastly in this section, we need to cover some of the attacks against IoT. For the most part, virtually every attack we’ve discussed (or will discuss later) in this book can be leveraged against IoT—or make use of IoT devices to work. For example, DDoS (distributed denial of service) in IoT isn’t any different from any other DDoS against or using “normal” devices. In the IoT world, though, you can leverage your toaster and all these other little data producers and collectors to carry out outlandish DDoS attacks. In one version of this, noted as the Sybil attack in EC-Council’s curriculum, multiple forged identities are used to create the illusion of traffic congestion that affects everyone else in the local IoT network.

A couple other attacks specifically called out are rolling code and BlueBorne. The code used by your key fob to unlock (and in some cases) start your car is called a rolling (or hopping) code. An attack can sniff for the first part of the code, jam the key fob, and sniff/copy the second part on subsequent attempts, allowing the attacker to steal the code—and your car. One of the better ways to pull this one off is to use hardware designed for a wide radio range spectrum, like the HackRF One (https://greatscottgadgets.com). A BlueBorne attack is basically an amalgamation of techniques and attacks against known, already existing Bluetooth vulnerabilities.

Ransomware, side channel, man in the middle (MITM), and so on all still apply here, as they do everywhere else. And let’s not forget malware. Just like their wired cousins, IoT devices can fall prey to malware. For example, Mirai malware purposefully looks for and interjects itself onto IoT devices. After successful infiltration, it basically propagates and creates gigantic botnets—with the primary purpose of DDoS attacks thereafter.

IoT Hacking Methodology

Lastly in this chapter, things just wouldn’t be right without a good old-fashioned CEH methodology to commit to memory. I can’t really blame EC-Council for this—a methodology is after all, and as previously mentioned, not necessarily a step-by-step, rote list to follow in order. Rather, it’s a good means to ensure you cover all your bases and make sure the test moves forward comprehensively. When it comes to this IoT hacking methodology, the steps will probably look really familiar to you: information gathering, vulnerability scanning, launching attacks, gaining access, and maintaining access.

The information gathering phase is exactly what it sounds like: call it reconnaissance and footprinting for IoT devices. And just how would one pull this off? Glad you asked—ever heard of Shodan?

Suppose you were sitting at home one night watching a cooking show and you saw a baker talking about a sweet, delicious ganache. After a brief sip on your bourbon, you think to yourself, “What the heck is a ganache? How does one make ganache? Where was ganache invented, by whom, and why?” If you wanted all the answers to those questions, you’d get up, go to your laptop, and open Google and start searching. Why? Because Google is a giant search engine crawling nearly every website worldwide, and you know the answers to your questions are in there somewhere.

Shodan (https://www.shodan.io/) is often referred to as the search engine for everything. See, Google and other search engines index the Web, while Shodan indexes pretty much everything else (see Figure 8-4). Want to find all webcams in a specific city? Shodan can help. Want to see where the wind turbines are in your state and how they’re doing? Shodan again. How about utilities, smart TVs, SCADA systems, medical devices, traffic lights, refrigerators, and the aforementioned Internet-enabled underwear? I’ll take Shodan for $500, Alex. Shodan indexes anything and everything imaginable that is or once was (and many times probably shouldn’t be) plugged into the Internet.

Figure 8-4 Shodan

Shodan is to everything else what Google is to the Web. It’s incredibly powerful, super cool, and fun to use—and can be exceptionally dangerous. Shodan can provide you loads of information about all the devices you wish to look for, and can do so with the benefit of hiding your identity while you’re searching. After all, Nmap can be incredibly noisy at times, but Shodan may have crawled your targets weeks ago, and done so anonymously (for you anyway).

EC-Council doesn’t go into Shodan use in the curriculum, but I highly recommend you check it out anyway and learn some common filters (like city, hostname, geo, port, and net, for starters): for example, apache city:"Huntsville" will show you all Apache servers Shodan found in Huntsville, Alabama, and cisco net:"69.192.0.0/16" will show all the Cisco devices it can find on the subnet hosting basspro.com (as an aside, this is just an example—please leave BassPro alone; they’re awesome and you’ll get in bunches of trouble for ignoring me here). There are also multiple built-in, common searches available—just click them and adjust as needed. I’d bet cash money you’ll see it on future exam versions.

The second phase in IoT hacking methodology, vulnerability scanning, is exactly as it sounds and reminds me of a cold data center floor on Marshall Space Flight Center, many, many years ago. I was there with a couple of guys installing and configuring a vulnerability assessment suite. I won’t go into the name of the vendor, to protect the innocent, but you’d recognize them. At any rate, we were plugging along and I got to talking with the lead engineer from the vendor. We discussed the how, when, where, and whys, until I asked him about scanning a network appliance we had. He paused for a moment, turned away from the server rack with cables in hand, and told me, “Matt, this thing will scan a microwave if you want it to.” At the time, we all thought that was just hilarious. Imagine, scanning a microwave for vulnerabilities you could exploit against the enterprise. How ridiculous.

Fast-forward a few years, and now I’m wondering if there’s going to be a Patch Tuesday for my toilet. There are, in fact, several vulnerability scanners and assessment tools for IoT devices, and more are coming every day. Even though I’d argue it’s not a vulnerability assessment tool, EC-Council lists Nmap as an option. Beyond Trust offers a couple of tools for IoT scanning, including RIoT Vulnerability Scanner (https://www.beyondtrust.com/resources/data-sheet/retina-iot-riot-scanner/) and beSTORM (https://www.beyondsecurity.com/bestorm.html). Some other tools are IoTsploit (https://iotsploit.com) and IoT Inspector (www.iot-inspector.com).

The third phase in the methodology, launching attacks, is one we’ve covered a bit already in this chapter. A few hacking tools not mentioned earlier include Firmalyzer (https://firmalyzer.com, for performing active security assessments on IoT devices), KillerBee (https://github.com), JTAGulator (www.grandideastudio.com), and Attify Zigbee Framework (https://www.attify.com, providing a suite of tools for testing Zigbee devices). As the IoT expands, so do the number, names, and frequency of attacks.

The last two phases, gaining access and then maintaining access, have been covered before, and most everything in previous discussions applies here. One thing I did find very interesting, in both the official courseware and in reading up on IoT, is that, believe it or not, Telnet is big in the IoT world. That’s right—our old insecure friend Telnet is often leveraged in IoT devices and provides a rather easy means to gain access. Once there, you can, of course, install backdoors and malware, or force firmware updates to ensure you can maintain a presence.

And that, ladies and gentlemen, wraps up our short little foray into the IoT. It is, quite literally, impossible for this or any book or study session to capture the entire breadth of the IoT’s scope. I applaud EC-Council’s attempt, and actually found this information useful and largely coherent and clear. I did my best here to shrink it down into digestible portions and sincerely hope it helps you come exam time—and real-world work time. Once again, however, I must implore you to do your own research. This technology is growing by leaps and bounds, and the next exam-worthy attack tool discussion or terminology will be right around the corner.

Chapter Review

The Open Web Application Security Project (OWASP) has an arm dedicated specifically to mobile security (https://www.owasp.org/index.php/OWASP_Mobile_Security_Project) and publishes a Top 10 list of mobile risks. Here are the current top 10 (https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10): M1 – Improper Platform Usage, M2 – Insecure Data Storage, M3 – Insecure Communication, M4 – Insecure Authentication, M5 – Insufficient Cryptography, M6 – Insecure Authorization, M7 – Client Code Quality, M8 – Code Tampering, M9 – Reverse Engineering, and M10 – Extraneous Functionality.

When it comes to mobile platforms, there are two major players in the field—Android and iOS. Android was created by Google specifically for mobile devices, and it contains an OS, middleware, and a suite of built-in applications for the mobile user. iOS is Apple’s operating system for mobile devices—that is, the iPhone and iPad (you will also find iOS on Apple TV and iPods). Built-in applications include everything from entertainment to an AI with a woman’s voice that answers questions for you (Siri). A good review of everything from Android and iOS can be found at https://www.android.com/ and www.apple.com/ios/, respectively.

Whether Android or iOS, one thing you will get asked about is rooting or jailbreaking the device. Both mean the same thing: perform some action that grants you administrative (root) access to the device so you can do whatever you want with it. There are multiple tools to help you in your Android rooting—the name given to the process on an Android device—efforts. These include KingoRoot (https://www.kingoapp.com), TunesGo (https://tunesgo.wondershare.com), OneClickRoot (https://oneclickroot.com), and MTK Droid (https://androidmtk.com).

As far as jailbreaking an iOS device (which, just like rooting, invalidates every warranty you can think of), tools include, but are not limited to, evasi0n7, GeekSn0w, Pangu, Redsn0w, Absinthe, and Cydia. There are three basic techniques and three different types, regardless which tool you want to try. Techniques include untethered (kernel will remain patched—that is, jailbroken—after reboot, with or without a system connection), semi-tethered (reboot no longer retains the patched kernel but the software has already been added to the device; therefore, if admin privileges are required, the installed jailbreaking tool can be used), and tethered (reboot removes all jailbreaking patches, and the phone may get stuck in a perpetual loop on startup, requiring a system connection, such as USB, to repair). The three types of jailbreaking include Userland (provides user-level access but not admin), iBoot, and BootROM (both provide admin-level access).

Many of the vulnerabilities and attack vectors we talked about on everything else also apply to mobile. Perhaps the most obvious attack vector comes from the apps themselves. Others include social engineering, phishing, and physical security. Android’s Device Administration API (https://developer.android.com/guide/topics/admin/device-admin) provides system-level device administration that can be used to create “security-aware” apps that may prove useful within an organization.

BYOD—Bring Your Own Device—allows users to bring their own smartphones and tablets to the organization’s network. The problem with it is security and control. Mobile Device Management (MDM), much like Group Policy and such in the Microsoft Windows world, is an effort to add some control to enterprise mobile devices. MDM helps in pushing security policies, application deployment, and monitoring of mobile devices. Most MDM solutions offer the same basic features: passcodes for device unlocking, remote locking, remote wipe, root or jailbreak detection, policy enforcement, inventory, and monitoring/reporting. Some of the solutions are XenMobile, IBM MaaS360, AirWatch, and MobiControl.

3G, 4G, and Bluetooth are other connectivity means to know. 3G and 4G refer to third- and fourth-generation mobile telecommunications, respectively, and offer broadband-type speeds for data usage on mobile devices (cell phones and such). Bluetooth refers to a very open wireless technology for data exchange over a relatively short range (10 meters or less). Bluetooth devices are easy to connect one to another and can even be set to look for other devices for you automatically. Bluetooth devices have two modes: discovery mode and pairing mode. Discovery mode determines how the device reacts to inquiries from other devices looking to connect, and it has three actions. The discoverable action obviously has the device answer to all inquiries, limited discoverable restricts that action, and nondiscoverable tells the device to ignore all inquiries.

Whereas discovery mode details how the device lets others know it’s available, pairing mode details how the device will react when another Bluetooth system asks to pair with it. There are basically only two versions: yes, I will pair with you, and no, I will not. Nonpairable rejects every connection request, whereas pairable accepts all of them.

Attacks on mobile devices abound. First and foremost, phishing attacks and social engineering are merciless when it comes to mobile devices. SMS phishing leverages text messaging to attack users and devices. The list of Trojans available is almost without end. Notable Android Trojans include Obad, Fakedefender, TRAMP.A, and ZitMo. Spyware is really scary, and tools like Mobile Spy and Spyera make it really easy to listen in on or even watch what the target is doing. Tools like AndroidLost, Find My Phone, and Where’s My Droid were designed to help users find lost phones, but they (and many, many others) can be used to track where users happen to be at.

The mobile device can also be used as an attack platform. Tools like Network Spoofer allow you to control how websites appear on a desktop/laptop. DroidSheep allows you to perform sidejacking by listening to wireless packets and pulling session IDs. Nmap works great on a mobile device, and sniffers are a dime a dozen. Heck, you can even install Kali Linux on the thing and turn it into a full-featured hacking machine. NetCut (www.arcai.com/netcut/) claims to be able to identify all systems on your current Wi-Fi, identify which one you don’t like, and, with the click of a button, cut them off Wi-Fi.

The major Bluetooth attacks are Bluesmacking (denial-of-service attack against the device), Bluejacking (sending unsolicited messages to, and from, mobile devices), Bluesniffing (effort to discover Bluetooth-enabled devices—much like war driving in wireless hacking), Bluebugging (accessing a Bluetooth-enabled device and remotely using its features), Bluesnarfing (theft of data from a mobile device due to an open connection—such as remaining in discovery mode), and Blueprinting (footprinting for Bluetooth).

The Internet of Things (IoT) can be defined as a collection of devices using sensors, software, storage, and electronics to collect, analyze, store, and share data among themselves or to a user. It refers to a network of devices with IP addresses that have the capability of sensing, collecting, and sending data to each other—basically a web of connected devices made possible by machine-to-machine communications, large availability of storage, and internetworked communications. IoT technologies extend Internet connectivity beyond “standard” devices, such as desktops, laptops, smartphones, and tablets, to any range of traditionally non-network-enabled physical devices and everyday objects.

IoT architecture comes down to three basic components—things using sensing technology, IoT gateways, and the cloud (or put another way, data storage availability). A thing inside the IoT is defined as any device implanted somewhere with the ability (and purpose) of communicating on the network. Embedded with technology, IoT devices can communicate and interact over the Internet, and oftentimes can be remotely monitored and controlled. Each of these things has some form of sensing technology. In other words, sensors are embedded in the device to measure and forward data.

IoT OS examples include RIOT OS, ARM mbed OS, RealSense OS X, Nucleus RTOS, Brillo, Contiki, Zephyr, Ubuntu Core, Integrity RTOS, and Apache Mynewt. There are four IoT communication models—device to device, device to gateway, device to cloud, and back-end data sharing. All work exactly as their names suggest, with only a couple of knowledge nuggets you can tuck away for test purposes. Device to gateway adds a collective before sending to cloud, which can be used to offer some security controls, and back-end data sharing is almost exactly like device to cloud; however, it adds the ability for third parties to collect and use the data.

Once a thing has sensed and collected data, it forwards that data to the next component, the IoT gateway. This is designed to send collected data from devices to the user or to the third component, data storage or cloud, for use later. The cloud stores and analyzes data, providing information back for future queries. The Vehicle Ad Hoc Network (VANET) is the communications network used by our vehicles. It refers to the spontaneous creation of a wireless network for vehicle-to-vehicle (V2V) data exchange.

In addition to the basic components, EC-Council lists a few architecture layers inside IoT: Edge Technology Layer, Access Gateway Layer, Internet Layer, Middleware Layer, and Application Layer. IEEE maintains a journal of all things IoT (https://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=6488907), and ITU has a great collection of news articles about current IoT efforts (https://www.itu.int/en/ITU-T/ssc/resources/Pages/topic-001.aspx).

Here is the OWASP Top 10 for IoT (https://www.owasp.org/index.php/Top_IoT_Vulnerabilities):

•   I1 – Insecure Web Interface   An insecure web interface can be present when issues such as account enumeration, lack of account lockout, and weak credentials are present.

•   I2 – Insufficient Authentication/Authorization   Authentication may not be sufficient when weak passwords are used or are poorly protected.

•   I3 – Insecure Network Services   Insecure network services may be susceptible to buffer overflow attacks or attacks that create a denial-of-service condition, leaving the device inaccessible to the user.

•   I4 – Lack of Transport Encryption/Integrity Verification   Lack of transport encryption allows data to be viewed as it travels over local networks or the Internet.

•   I5 – Privacy Concerns   Privacy concerns generated by the collection of personal data in addition to the lack of proper protection of that data is prevalent.

•   I6 – Insecure Cloud Interface   An insecure cloud interface is present when easy-to-guess credentials are used or account enumeration is possible.

•   I7 – Insecure Mobile Interface   An insecure mobile interface is present when easy-to-guess credentials are used or account enumeration is possible.

•   I8 – Insufficient Security Configurability   Insufficient security configurability is present when users of the device have limited or no ability to alter its security controls.

•   I9 – Insecure Software/Firmware   The lack of ability for a device to be updated presents a security weakness on its own.

•   I10 – Poor Physical Security   Physical security weaknesses are present when an attacker can disassemble a device to easily access the storage medium and any data stored on that medium.

All previous, and subsequent, attacks mentioned in this book probably have a role in the IoT world as well. For example, DDoS (distributed denial of service) in IoT isn’t any different from any other DDoS against or using “normal” devices. In one version of this, noted as the Sybil attack in EC-Council’s curriculum, multiple forged identities are used to create the illusion of traffic congestion that affects everyone else in the local IoT network. EC-Council also notes HVAC attacks in IoT attacks. It’s pretty much exactly what it sounds like—hack IoT devices in order to shut down air conditioning services.

A couple other attacks specifically called out are rolling code and BlueBorne. The code used by your key fob to unlock (and in some cases) start your car is called a rolling (or hopping) code. An attack can sniff for the first part of the code, jam the key fob, and sniff/copy the second part on subsequent attempts, allowing the attacker to steal the code—and your car. A BlueBorne attack is basically an amalgamation of techniques and attacks against known, already existing Bluetooth vulnerabilities. One of the better ways to pull this one off is to use hardware specifically designed for it, like the HackRF One (https://greatscottgadgets.com). Mirai malware purposefully looks for and interjects itself onto IoT devices. After successful infiltration, it basically propagates and creates gigantic botnets—with the primary purpose of DDoS attacks thereafter.

The IoT hacking methodology phases are information gathering, vulnerability scanning, launching attacks, gaining access, and maintaining access. Shodan (https://www.shodan.io/) is often referred to as the search engine for everything and is a good start in information gathering. Some other tools to assist in information gathering include Censys (https://censys.io) and Thingful (www.thingful.net).

The second phase in IoT hacking methodology, vulnerability scanning, is exactly as it sounds. There are several vulnerability scanners and assessment tools for IoT devices, and more are coming every day. EC-Council lists Nmap as an option. Beyond Trust offer a couple of tools for IoT scanning, including RIoT Vulnerability Scanner (https://www.beyondtrust.com/resources/data-sheet/retina-iot-riot-scanner/) and beSTORM (https://www.beyondsecurity.com/bestorm.html). Some other tools are IoTsploit (https://iotsploit.com) and IoT Inspector (www.iot-inspector.com).

In the launching attacks phase, IoT hacking tools include Firmalyzer (https://firmalyzer.com, for performing active security assessments on IoT devices), KillerBee (https://github.com), JTAGulator (www.grandideastudio.com), and Attify Zigbee Framework (https://www.attify.com, providing a suite of tools for testing Zigbee devices).

The last two phases are gaining access and then maintaining access. Telnet is often leveraged in IoT devices and provides a rather easy means to gain access. Once there you can, of course, install backdoors, malware, or force firmware updates to ensure you can maintain a presence. Sniffers for IoT traffic include Foren6 (http://cetic.github.io/foren6/), Z-Wave (www.suphammer.com), and CloudShark (https://www.cloudshark.org).

Questions

1.   Which of the following is the best choice for performing a Bluebugging attack?

A.   PhoneSnoop

B.   BBProxy

C.   btCrawler

D.   Blooover

2.   Operations promotes the use of mobile devices in the enterprise. Security disagrees, noting multiple risks involved in adding mobile devices to the network. Which of the following actions provides some protections against the risks security is concerned about?

A.   Implement WPA.

B.   Add MAC filtering to all WAPs.

C.   Implement MDM.

D.   Ensure all WAPs are from a single vendor.

3.   You wish to gain administrative privileges over your Android device. Which of the following tools is the best option for rooting the device?

A.   Pangu

B.   SuperOneClick

C.   Cydia

D.   evasi0n7

4.   Which of the following jailbreaking techniques will leave the phone in a jailbroken state even after a reboot?

A.   Tethered

B.   Untethered

C.   Semi-tethered

D.   Rooted

5.   A mobile device communication session using SSL fails, and data is available for viewing by an attacker. Which OWASP Top 10 Mobile Vulnerability category has been made available for exploit?

A.   M3 – Insecure Communication

B.   M4 – Insufficient Authentication

C.   M5 – Insufficient Cryptography

D.   M10 – Extraneous Functionality

6.   Which of the following is an iOS jailbreaking type that cannot be patched by Apple, as the failure is within the hardware itself, and provides admin-level access after successful completion?

A.   iBoot

B.   Userland

C.   Untethered

D.   BootROM

7.   Which IoT communication model makes use of a component adding a collective before sending data to the cloud, which adds a measure of security control to the application?

A.   Device to device

B.   Device to cloud

C.   Device to gateway

D.   Device to security

8.   Which OWASP Top 10 IoT Vulnerability category deals with poorly protected passwords?

A.   I1 – Insecure Web Interface

B.   I2 – Insufficient Authentication/Authorization

C.   I8 – Insufficient Security Configurability

D.   I9 – Insecure Software/Firmware

9.   An attacker leverages a vulnerability within Bluetooth on an IoT device and successfully shuts down the air conditioning to the data center floor. Which of the following best describes the attack type used?

A.   HVAC

B.   BlueAir

C.   Rolling code

D.   BlueBorne

10.   In which phase of the IoT hacking methodology would the Shodan search engine most likely be used?

A.   Vulnerability scanning

B.   Information gathering

C.   Launching attacks

D.   Gaining access

11.   Which of the following tools is the best choice for sniffing IoT traffic?

A.   Firmalyzer

B.   beSTORM

C.   Foren6

D.   Shodan

Answers

1.   D. Blooover is designed for Bluebugging. BBProxy and PhoneSnoop are both Blackberry tools, and btCrawler is a discovery option.

2.   C. Mobile Device Management won’t mitigate all the risks associated with unending use of mobile devices on your network—but at least it’s something.

3.   B. SuperOneClick is designed for rooting Android. The others are jailbreaking iOS options.

4.   B. If untethered jailbreaking has been performed, the device is in a jailbroken state forever, with or without connection to another device.

5.   A. Even though SSL refers to cryptography in communications, almost every time you see SSL or TLS, M3 is your answer.

6.   D. BootROM deals with hardware and provides admin privileges. The remaining answers either don’t provide admin access, have patch availability, or, in the case of untethered, aren’t applicable.

7.   C. The IoT gateway provides a collective area that allows for at least some measure of security controls.

8.   B. I2 – Insufficient Authentication is the clear answer here.

9.   A. An HVAC IoT device attack is exactly what’s being described here. Rolling code isn’t applicable, BlueBorne isn’t the best choice, and BlueAir doesn’t exist.

10.   B. Shodan is, after all, a search engine. While it may be useful in other areas, it’s clearly an information-gathering tool.

11.   C. Foren6 is the only IoT traffic sniffer listed.