31,19 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
IoT is an upcoming trend in the IT industry today; there are a lot of IoT devices on the market, but there is a minimal understanding of how to safeguard them. If you are a security enthusiast or pentester, this book will help you understand how to exploit and secure IoT devices.
This book follows a recipe-based approach, giving you practical experience in securing upcoming smart devices. It starts with practical recipes on how to analyze IoT device architectures and identify vulnerabilities. Then, it focuses on enhancing your pentesting skill set, teaching you how to exploit a vulnerable IoT device, along with identifying vulnerabilities in IoT device firmware. Next, this book teaches you how to secure embedded devices and exploit smart devices with hardware techniques. Moving forward, this book reveals advanced hardware pentesting techniques, along with software-defined, radio-based IoT pentesting with Zigbee and Z-Wave. Finally, this book also covers how to use new and unique pentesting techniques for different IoT devices, along with smart devices connected to the cloud.
By the end of this book, you will have a fair understanding of how to use different pentesting techniques to exploit and secure various IoT devices.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Veröffentlichungsjahr: 2017
Ähnliche
BIRMINGHAM - MUMBAI
IoT Penetration Testing Cookbook
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: November 2017
Production reference: 1271117
ISBN 978-1-78728-057-1
www.packtpub.com
Credits
Authors
Aaron Guzman
Aditya Gupta
Copy Editors
Safis Editing
Laxmi Subramanian
Reviewers
Francesco Azzola Paul Massey
Project Coordinator
Shweta H Birwatkar
Commissioning Editor
Vijin Boricha
Proofreader
Safis Editing
Acquisition Editor
Prachi Bisht
Indexer
Pratik Shirodkar
Content Development Editor
Deepti Thore
Graphics
Tania Dutta
Technical Editor
Nilesh Sawakhande
Production Coordinator
Shantanu Zagade
About the Authors
Aaron Guzman is a principal security consultant from the Los Angeles area with expertise in web app security, mobile app security, and embedded security. He has shared his security research at a number of worldwide conferences, including DEF CON, DerbyCon, AppSec EU, AppSec USA, HackFest, Security Fest, HackMiami, 44Con, and AusCERT as well as a number of regional BSides events. Furthermore, Aaron is a chapter leader for the Open Web Application Security Project (OWASP) Los Angeles chapter and the Cloud Security Alliance SoCal (CSA SoCal) chapter, and was previously the technical reviewer for Practical Internet of Things Security by Packt Publishing. He has contributed to many IoT security guidance publications from CSA, OWASP, PRPL, and a number of others. Aaron leads the OWASP Embedded Application Security project, providing practical guidance to address the most common firmware security bugs for the embedded and IoT community. Follow Aaron's latest research on Twitter at @scriptingxss.
A special thanks to the readers of this book; I hope the content is useful for IoT security research and penetration testing.
Aditya Gupta is the founder of Attify, and an IoT and mobile security researcher. He is also the creator of the popular training course Offensive IoT Exploitation, and the founder of the online store for hackers Attify-Store.
Gupta has also published security research papers, authored tools, and spoken numerous times at conferences such as BlackHat, DefCon, OWASP AppSec, ToorCon, and more.
In his previous roles, he has worked with various organizations helping to build their security infrastructure and internal automation tools, identify vulnerabilities in web and mobile applications, and lead security planning.
He can be reached out to on Twitter at @adi1391 and over email at [email protected].
I would like to thank my parents and sister for providing me with the support and motivation required to succeed in life, and making me curious enough to know "how things work," which led me to pursue a career I love day in, day out.
Last but not the least, thanks to all my colleagues at Attify - I am lucky to have the best pentesters, reverse engineers and problem solvers on my side - to make sure we break every IoT device possible. You guys are the best!
About the Reviewers
Francesco Azzola is an electronic engineer with over 15 years of experience in computer programming and JEE architecture. He is Sun Certified Enterprise Architect (SCEA), SCWCD, and SCJP certified. He is an Android and IoT enthusiast. He loves creating IoT projects using Arduino, Raspberry Pi, Android, and other platforms.
He is interested in the convergence between IoT and mobile applications. Previously, he worked in the mobile development field for several years. He has created a blog called survivingwithandroid.com, where he shares posts about coding in Android and IoT projects. He is the author of Android Things Projects, published by Packt.
Paul Massey has worked in computer programming for over 20 years, 11 of which have been as the CEO of Scriptwerx. He is an expert in JavaScript and mobile technologies, as well as in working with the Arduino platform (and similar) for a number of years, creating hardware and software projects for the Internet of Things, audio visual, and automotive technologies.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.com. Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details. At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/1787280578.
If you'd like to join our team of regular reviewers, you can email us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Table of Contents
Preface
What this book covers
What you need for this book
Who this book is for
Sections
Getting ready
How to do it…
How it works…
There's more…
See also
Conventions
Reader feedback
Customer support
Downloading the example code
Downloading the color images of this book
Errata
Piracy
Questions
IoT Penetration Testing
Introduction
Defining the IoT ecosystem and penetration testing life cycle
Penetration testing approaches
Black box
White box
Grey box
Firmware 101
Digging deeper into firmware
Development supply chain of firmware
Web applications in IoT
Web communication
Mobile applications in IoT
Hybrid
Native applications
Device basics
Hardware inputs
Introduction to IoT's wireless communications
Wi-Fi
ZigBee
Z-Wave
Bluetooth
Setting up an IoT pen testing lab
Software tool requirements
Firmware software tools
Web application software tools
Mobile application software tools
Android
iOS
Hardware analysis tool requirements
Hardware tools
Hardware analysis software
Radio analysis tool requirements
Radio analysis hardware
Radio analysis software
IoT Threat Modeling
Introduction
Getting familiar with threat modeling concepts
Getting ready
How to do it...
Anatomy of threat modeling an IoT device
How to do it...
Step 1 - identifying the assets
Step 2 - creating an IoT device architecture overview
Step 3 - decomposing the IoT device
Step 4 - identifying threats
Step 5 - documenting threats
Threat #1
Threat #2
Threat #3
Step 6 - rating the threats
Threat modeling firmware
Getting ready
How to do it...
Step 1 - identifying the assets
Steps 2 and 3 - creating an architecture overview and decomposition
Step 4 - identifying threats
Step 5 - documenting threats
Threat #1
Threat #2
Threat #3
Step 6 - rating the threats
Threat modeling of an IoT web application
How to do it...
Step 1 :Creating an architecture overview and decomposition
Step 2: Identifying threats
Step 3 :Documenting threats
Threat #1
Threat #2
Threat #3
Step 4 : Rating the threats
Threat modeling an IoT mobile application
How to do it...
Step 1: Creating an architecture overview and decomposition
Step 2: Identifying threats
Step 3: Documenting threats
Threat #1
Threat #2
Threat #3
Step 4: Rating the threats
Threat modeling IoT device hardware
How to do it...
Step 1: Creating an architecture overview and decomposition
Step 2: Identifying threats
Step 3: Documenting threats
Threat #1
Threat #2
Threat #3
Step 4: Rating the threats
Threat modeling IoT radio communication
How to do it...
Step 1: Creating an architecture overview and decomposition
Step 2: Identifying threats
Step 3: Documenting threats
Threat #1
Threat #2
Threat #3
Step 4: Rating the threats
Analyzing and Exploiting Firmware
Introduction
Defining firmware analysis methodology
Obtaining firmware
Getting ready
How to do it...
Downloading from the vendor's website
Proxying or mirroring traffic during device updates
Dumping firmware directly from the device
Googling
How it works...
Analyzing firmware
Getting ready
How to do it...
How it works...
There's more...
See also
Analyzing filesystem contents
Getting ready
Manual analysis
Automated tools and scripts
How to do it...
How it works...
There's more...
See also
Emulating firmware for dynamic analysis
Getting ready
How to do it...
How it works...
There's more...
Getting started with ARM and MIPS
Getting Ready
How to do it...
There's more...
Exploiting MIPS
Getting ready
How to do it...
How it works...
There's more...
Backdooring firmware with firmware-mod-kit (FMK)
Getting ready
How to do it...
How it works...
Exploitation of Embedded Web Applications
Introduction
Getting started with web app security testing
How to do it...
Web penetration testing methodologies
Choosing your testing tools
Using Burp Suite
Getting ready
How to do it...
How it works...
There's more...
Useful intruder payloads
See also
Using OWASP ZAP
Getting ready
How to do it...
There's more...
Exploiting command injection
Getting ready
How to do it...
See also
Exploiting XSS
Getting ready
How to do it...
Introduction to using BeEF XSS payloads
Basic usage of BeEF when hooking a victim
Proxying traffic through a victim's browser
There's more...
See also
Exploiting CSRF
Getting ready
How to do it...
See also
Exploiting IoT Mobile Applications
Introduction
Acquiring IoT mobile applications
How to do it...
Decompiling Android applications
Getting ready
How to do it...
See also
Decrypting iOS applications
Getting ready
How to do it...
See also
Using MobSF for static analysis
Getting ready
How to do it...
Android static analysis
iOS static analysis
There's more...
Analyzing iOS data storage with idb
Getting ready
How to do it...
There's more...
See also
Analyzing Android data storage
Getting ready
How to do it...
See also
Performing dynamic analysis testing
Getting ready
How to do it...
See also
IoT Device Hacking
Introduction
Hardware exploitation versus software exploitation
Hardware hacking methodology
Information gathering and recon
External and internal analysis of the device
Identifying communication interfaces
Acquiring data using hardware communication techniques
Software exploitation using hardware exploitation methods
Hardware reconnaissance techniques
Opening the device
Looking at various chips present
Electronics 101
Resistor
Voltage
Current
Capacitor
Transistor
Memory types
Serial and parallel communication
There's more...
Identifying buses and interfaces
UART identification
SPI and I2C identification
JTAG identification
There's more...
Serial interfacing for embedded devices
Getting ready
How to do it...
See also
NAND glitching
Getting ready
How to do it...
See also
JTAG debugging and exploitation
Getting ready
How to do it...
See also
Radio Hacking
Introduction
Getting familiar with SDR
Key terminologies in radio
Hands-on with SDR tools
Getting ready
How to do it...
Analyzing FM
RTL-SDR for GSM analysis
Working with GNU Radio
There's more...
Understanding and exploiting ZigBee
Getting ready
How to do it...
There's more...
Gaining insight into Z-Wave
How to do it...
Understanding and exploiting BLE
Getting ready
How to do it...
There's more...
Firmware Security Best Practices
Introduction
Preventing memory-corruption vulnerabilities
Getting ready
How to do it...
See also
Preventing injection attacks
How to do it...
See also
Securing firmware updates
How to do it...
Securing sensitive information
How to do it...
See also
Hardening embedded frameworks
Getting ready
How to do it...
Securing third-party code and components
Getting ready
How to do it...
Mobile Security Best Practices
Introduction
Storing data securely
Getting ready
How to do it...
See also
Implementing authentication controls
How to do it...
See also
Securing data in transit
How to do it...
Android
iOS
See also
Securely using Android and iOS platform components
How to do it...
Securing third-party code and components
How to do it...
See also
Employing reverse engineering protections
How to do it...
There's more...
See also
Securing Hardware
Introduction
Hardware best practices
Uncommon screw types
Antitamper and hardware protection mechanisms
Side channel attack protections
Exposed interfaces
Encrypting communication data and TPM
Advanced IoT Exploitation and Security Automation
Introduction
Finding ROP gadgets
Getting ready
How to do it...
See also
Chaining web security vulnerabilities
How to do it...
Step 1 - identifying assets and entry points
Step 2 - finding the weakest link
Step 3 - reconnaissance
Android application
iOS application
Web application
Step 4 - identifying vulnerabilities
Step 5 - Exploitation -- Chaining vulnerabilities
See also
Configuring continuous integration testing for firmware
Getting ready
How to do it...
See also
Configuring continuous integration testing for web applications
Getting ready
How to do it...
See also
Configuring continuous integration testing for mobile applications
Getting ready
How to do it...
See also
Preface
IoT is a term used to reference embedded devices connected to a network in some form or fashion. Some devices are retrofitted to include modules that connect them to a network, and others are cutting edge devices created for specific needs. In each case, these devices create a risk to the safety of enterprises, nations, and individuals. Whether you are new to penetration testing or a seasoned pen tester, IoT Penetration Testing Cookbook contains recipes to help security professionals holistically assess and defend IoT ecosystems.
What this book covers
Chapter1, IoT Penetration Testing, begins by covering the basic concepts of IoT and mapping out what IoT penetration testing entails.
Chapter 2, IoT Threat Modeling, dives into what threat modeling is and how to conduct a threat model for an IoT device's ecosystem.
Chapter 3, Analyzing and Exploiting Firmware, explores how to reverse engineer an IoT device's firmware and exploit common vulnerabilities.
Chapter 4, Exploitation of Embedded Web Applications, explains the different types of embedded web applications and how to discover exploitable vulnerabilities to gain control of an IoT device.
Chapter 5, Exploiting IoT Mobile Applications, jumps into the basics of reverse engineering IoT mobile applications and discovering commonly found vulnerabilities to gain access to unauthorized functions.
Chapter 6, IoT Device Hacking, introduces basic hardware hacking techniques to compromise the IoT device component.
Chapter 7, Radio Hacking, introduces software-defined radio concepts and tools to discover and exploit commonly used wireless protocols in IoT.
Chapter 8, Firmware Security Best Practices, discusses how embedded developers can incorporate security controls into IoT device firmware to protect against common vulnerabilities.
Chapter 9, Mobile Security Best Practices, explains how mobile applications can employ proactive measures to ensure IoT applications are secured.
Chapter 10, Securing Hardware, dives into best practices for improving hardware security to prevent reverse engineering.
Chapter 11, Advanced IoT Exploitation and Security Automation, explains how to exploit and chain vulnerabilities together to gain control over an IoT product. Additionally, this chapter demonstrates how to implement automated application security scans into continuous integration environments.
What you need for this book
Following are the software requirements for this book:
Microsoft Threat Modeling Tool 2016
Binwalk, Firmadyne, Firmwalker, Angr (optional), Firmware-mod-toolkit, Firmware analysis toolkit, GDB, Radare2 (optional),
Binary Analysis Tool
(
BAT
), Qemu, IDA Pro (optional)
Burp Suite, OWASP ZAP
Mobile Security Framework (MobSF), Idb, SQLite Browser 3.10.1, Cydia, openURL, dumpdecrypted, ipainstaller, SSL Kill Switch 2, Clutch2, Cycript, JD-GUI, Hopper
RTL-SDR
Node security project
(
Nsp
), Retirejs, Dependency-check, flawfinder, Jenkins 2.60.3
Following are the hardware requirements for this book:
Attify Badge (alternatively, a combination of C232HM-DDHSL-0 cable and Adafruit FTDI Breakout), Salae Logic Sniffer (8-Channel), RzRaven USB Stick flashed with KillerBee framework, JTAGulator, Xbee with Xbee Shield, Ubertooth, BLE adapter
Who this book is for
This book is for software developers, quality assurance professionals, and security professionals who are looking to get familiar with discovering and exploiting vulnerabilities in IoT systems, as well as those who are interested in employing proactive defensive security controls.
Sections
In this book, you will find several headings that appear frequently (Getting ready, How to do it…, How it works…, There's more…, and See also). To give clear instructions on how to complete a recipe, we use these sections as follows:
Getting ready
This section tells you what to expect in the recipe, and describes how to set up any software or any preliminary settings required for the recipe.
How to do it…
This section contains the steps required to follow the recipe.
How it works…
This section usually consists of a detailed explanation of what happened in the previous section.
There's more…
This section consists of additional information about the recipe in order to make the reader more knowledgeable about the recipe.
See also
This section provides helpful links to other useful information for the recipe.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning. Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows:
"If we open the preferences file by double-clicking, we will see OAuth access_tokens and refresh_tokens stored in unprotected storage (CVE-2017-6082)."
A block of code is set as follows:
<Contextpath="/jira"docBase="${catalina.home} /atlassian- jira" reloadable="false" useHttpOnly="true">
Any command-line input or output is written as follows:
adb pull data/data/com.skybell.app/files/default.realm /path/to/store/realdb
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Click on View Class Dump to list the application's class details."
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors .
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you. You can download the code files by following these steps:
Log in or register to our website using your e-mail address and password.
Hover the mouse pointer on the
SUPPORT
tab at the top.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box.
Select the book for which you're looking to download the code files.
Choose from the drop-down menu where you purchased this book from.
Click on
Code Download
.
You can also download the code files by clicking on the Code Files button on the book's webpage at the Packt Publishing website. This page can be accessed by entering the book's name in the Search box. Please note that you need to be logged in to your Packt account. Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR / 7-Zip for Windows
Zipeg / iZip / UnRarX for Mac
7-Zip / PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/IoT-Penetration-Testing-Cookbook. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/IoTPenetrationTestingCookbook_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title. To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at [email protected] with a link to the suspected pirated material. We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
IoT Penetration Testing
Although the term IoT is known to have been coined in 1999 by MIT's Auto-ID Labs, embedded devices have been long-standing in technology for decades. The difference between new IoT and the embedded device world pertains to the legacy of design decisions and configurations that were never intended to be made public on the internet. Without manufacturing companies considering the consequences, widespread exploitation of IoT devices is now taking place, causing some of the world's biggest Distributed Denial of Service (DDoS) attacks ever recorded. We will cover various aspects of IoT pen testing and practical security guidance to provide preventative measures against the attacks we are currently seeing in the market.
To understand the origin of IoT you can visit this link:
http://autoid.mit.edu/iot_research_initiative
In this chapter, we will cover the following topics:
Defining the IoT ecosystem and pen testing life cycle
Firmware 101
Web applications in IoT
Mobile applications in IoT
Device basics
Introduction to IoT's wireless communications
Setting up an IoT pen testing lab
The goal of this chapter is to set a foundation for IoT penetration testing, which will then be used in the subsequent chapters ahead.
Introduction
This chapter focuses on the foundational knowledge that is required when performing an IoT penetration test. It provides basic concepts about the many attack surfaces within IoT and lays the groundwork to assist testers with jump-starting an IoT testing lab.
We will discuss the current state of IoT penetration testing and each area of possible attack surface to address how testing has advanced over the years. Then we will go over the basics of firmware security, web application security, mobile application security, hardware security, and radio communication.
Finally, we will walk you through how to set up the software tools and hardware tools required for testing.
Defining the IoT ecosystem and penetration testing life cycle
Over the last few years, the spotlight has been on IoT devices due to the sheer amount being deployed, the conveniences they provide, their ease of use, and the potential security risks they pose in our society. With the IoT boom taking place before our eyes, we as a people are closer to a technology singularity. The dependence on IoT and the internet, which powers them raises concerns about safety, privacy, and security. Due to the spread of devices infiltrating all industry verticals, such as consumers, entertainment, commercial, medical, industrial, energy, and manufacturing, it has been proven that consumers, as well as commercial technology operators and owners, are unable to properly ensure the security of these devices. The reliance on device manufacturers to provide the proper assurance that devices are built with methodologies such as security-by-design is heavily dependent on the industry in which the device was made for.
Each industry vertical and region has its own respective regulations for testing devices. It is important to do your own due diligence prior to testing in order to ensure laws are not being broken. In some regions, such as the United States, security research for consumer devices is allowed and exempt from the Digital Millennium Copyright Act (DMCA), so long as the research is acting in good faith, is lawfully acquired, conducted in a controlled environment, and does not violate the Computer Fraud and Abuse Act (CFAA) of October 2016. This means security research for connected vehicles, cameras, various smart home devices, video game consoles, and jailbreaking mobile devices are now legal. After a long road of battles with the DMCA and the security community, this is a big win.
Now that such laws have passed, this is where we come in; we will go through assessing device firmware, web applications, mobile applications, hardware, and radio communications. First, we need to understand what the full scope of IoT is, including penetration testing approaches, and life cycles, to recognize all of its attack surfaces. Let's discuss the fundamentals of each IoT component in order to understand the attacks.
Penetration testing approaches
Testing applications, networks, and devices for security flaws are vital for keeping the internet more secure and safe. Whether testing occurs by the manufacturers, third-party consulting firms, enterprise security teams, or security researches, approaches vary depending on the information given to the testers who are performing the assessment. Ideally, a comprehensive test should include the entire IoT system as well as its infrastructure, and not just the device itself, but it is not uncommon for testing to include only a subset of an IoT system due to pricing or technical ability.
Black box
Black box assessments are common and known to be performed for a relatively low cost. These types of assessments are performed with no prior knowledge of the technology or device implementations employed. More often than not, black box assessments are performed by security researchers or third-party consulting firms, but can also be conducted by internal security teams for risk assessment purposes.
White box
White box assessments are when testers are given full access to source code, network diagrams, architecture diagrams, data flow diagrams, and various other pieces of detailed information on the technology employed by the target device. Generally, the more information on the target device or application(s) given to testers beforehand, the better the test results will be. White box assessments are more expensive but also ensure a more thorough review of a device's security controls and its implementation.
Grey box
Grey box assessments are performed when testers have limited or partial knowledge that an insider of the organization is aware of. These assessments can consist of testers only knowing the application stack and libraries utilized, but not having detailed documentation on the API.
Firmware 101
Firmware is a kind of software that is written to a hardware device in order to control user applications and various system functions. The firmware contains low level programming code that enables software to access hardware functions. Devices that run firmware are known as embedded systems which have limited hardware resources, such as storage capabilities as well as memory. Examples of embedded devices that run firmware are smartphones, traffic lights, connected vehicles, some types of computers, drones, and cable set-top boxes.
It is apparent that embedded technology and the firmware that runs on these devices controls our daily lives, from the critical infrastructure cities rely on, to bank ATMs and the homes that consumers live in. It is important to understand what a firmware binary consists of as well as its associated properties. Firmware is comprised of a bootloader, kernel, filesystem, and various other resources. There are different types of firmware built upon embedded Linux, embedded Windows, Windows IoT core, and various Real Time Operating Systems (RTOS). This book will be geared toward an embedded Linux environment, however, the principles will remain platform agnostic.
The following diagram represents what a piece of firmware contains: flash contents, the bootloader, the kernel, and a root filesystem:
Digging deeper into firmware
Let's first have a look at the bootloader. A bootloader's responsibility is to initialize RAM for volatile data storage, initialize serial port(s), detect the machine type, set up the kernel tagged list, load initramfs (initial RAM filesystem), and call the kernel image. The bootloader initializes hardware drivers via a Board Support Package (BSP), which is usually developed by a third party. The bootloader resides on a separate Electrically Erasable Programmable Read-only Memory (EEPROM), which is less common, or directly on flash storage, which is more common. Think of the bootloader as a PC's BIOS upon start up. Discussing each of the bootloaders' responsibilities in detail is beyond the scope of this book; however, we will highlight where the bootloader works to our advantage. Some of the common bootloaders for ARM and MIPS architectures are: Redboot, u-boot, and barebox. Once the bootloader starts up the kernel, the filesystem is loaded.
There are many filesystem types employed within the firmware, and sometimes even proprietary file types are used depending on the device. However, some of most common types of filesystems are SquashFS, cramFS, JFFS2, YAFFS2, and ext2. The most common filesystem utilized in devices (especially consumer devices) is SquashFS. There are utilities, such as unsquashfs and modified unsquashfs that are used to extract data from squashed filesystems. Modified unsquashfs tools are utilized when vendors change SquashFS to use non-supported compressions, such as LZMA (prior to SquashFS 4.0, the only officially supported compression was .zlib), and will have a different offset of where the filesystem starts than regular SquashFS filesystems. We will address locating and identifying offsets later in this book.
For additional reading on filesystems for embedded Linux, please visit the following link: http://elinux.org/images/b/b1/Filesystems-for-embedded-linux.pdf.
Similarly, there are many types of file compression utilized for firmware images, such as LZMA, .gzip, .zip, .zlip, and .arj, to name a few. Each has pros and cons such as the size after compression, compression time, decompression time, as well as the business needs for the device itself. For our purposes, we will think of the filesystem as the location that contains configuration files, services, account passwords, hashes, and application code, as well as start up scripts. In the next chapter, we will walk you through how to find the filesystem in use as well as the compression in use.
Development supply chain of firmware
Within the filesystem, device-specific code resides, written in C, C++, or other programming languages, such as Lua. Device-specific code, or even all of the firmware itself, can be a mix of third-party developers contracted out, known as Original Design Manufacturers (ODM), or in-house developers working with the Original Equipment Manufacturer (OEM). ODMs are an important piece of the embedded device development supply chain. They are often small companies in Asia and are a dime a dozen. Some OEMs have trusted ODMs they work with on product lines, while others will do business with ODMs that have the lowest fees for only one product. Depending on the industry, an ODM can also be referred to as a supplier. It is important to note that ODMs are free to work with a number of different OEMs and can even distribute the same code base. You may be familiar with this notion or even wondered why a critical public advisory affects ten plus device manufactures for a software bug. This occurs due to a lack of secure development life cycles processes by the ODM and verification by the OEM. Once an ODM completes their application deliverables, which may be an SDK or firmware to the OEM, the OEM will merge its code base(s) into the firmware, which may be as small as OEM logos on web interfaces. The implementation varies depending on how the ODM and OEM merge their code; however, it is not uncommon for an ODM to provide a binary file to the OEM. OEMs are responsible for distributing the firmware, managing firmware, and supporting the device itself. This includes firmware security issues reported by third-party researchers, which puts a strain on OEMs if ODMs retain the source code and the OEM only has access to a binary image.
In Chapter 3, Analyzing and Exploiting Firmware we will learn how to reverse engineer firmware binary images by recognizing the filesystem, identifying compression, and emulating binaries for testing, to take advantage of common firmware issues.
Web applications in IoT
Websites, otherwise known as web applications, need no introduction. At the very least, web applications contain frontend HTML, JavaScript, a backend web server, an application server, and a database. As web applications progress, heavy reliance on frontend code such as JavaScript is utilized more often in order to take the computational load off of the backend infrastructure or device. Web applications on the greater internet are slightly different than the web applications that are served via embedded devices.
The web applications you are used to have many more dependencies including the separation of web servers, application servers, database servers, as well as micro services that run in the backend. Separating each server is due to performance and availability reasons. Traditionally, embedded web applications are designed to run in their own self-contained environment. In a broad sense, there is less of a focus on performance and availability for embedded web applications.
There are two different models of web applications being utilized within the IoT space today, such as the hybrid cloud model and the embedded server standalone model. The hybrid model is a mix of the vendor or manufacturer providing Software as a Service (SaaS) web application(s) and also connecting the embedded device's web application running off of the firmware. The data is then synced from the manufacturer's cloud with the embedded device on the device's local network. For some IoT devices, IoT cloud service provider SDKs are utilized, such as AWS' IoT SDK and Azure's IoT SDK, and are built into the device web application stack. Recognizing a hybrid model is important in order to stay within a company's terms of service as well as within the legal bounds of your region. Many IoT companies who do utilize a hybrid model often use a third-party software development firm or ODM to host their web application on behalf of the OEM. These ODMs' web applications are usually rebranded for the specific OEM product, which can go unnoticed without proxying the communication.
A hybrid cloud model with IoT devices that have internet capabilities may look like the following figure. A user accesses the device's interface, where web services between the vendor's cloud and the user's device makes changes or collects data behind the scenes:
Embedded device web applications are, as mentioned, running internally off the device's firmware utilizing an embedded web server such as lighttpd or nginx with no outside dependencies. You might be familiar with these standalone embedded web apps, which are known to be run on printers, VoIP phones, and home routers. Quite often, input is sent directly to the device firmware, and if the user input is not validated or sanitized, attackers can perform arbitrary command execution within the device's context. In some cases, embedded web applications are designed to operate only within the Local Area Network (LAN) to protect from outside attacks or for administrative purposes. This can be the case for home IoT, industrial, and commercial devices. Often, having devices only available locally to a LAN is for security purposes, but as we have learned, this is not a stopgap for mitigating attacks. Device makers who design products with this intent are learning that customers are knowingly or unknowingly putting their devices on the internet, posing a risk to customer networks.
The following diagram demonstrates a user connecting to an embedded standalone web application via a web browser without outside system dependencies:
Web communication
The communication between browsers, embedded servers, and web application servers is typically done through a web service such as Simple Object Access Protocol (SOAP)/XML or an API which is based on Representational State Transfer (REST) over HTTP/HTTPS. SOAP requests consist of an envelope element, an xmlns:soap namespace, an encodingStyle attribute, and various elements such as the SOAP body element. Additional details on SOAP can be found by visiting the following link: https://www.w3schools.com/xml/xml_soap.asp.
An example of a HTTP SOAP request querying for an account balance is shown here:
POST http://example.com/soap/webservices HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Authorization: BasicYWRtaW46YWRtaW4= Content-Length: 821 Content-Type: text/plain;charset=UTF-8 DNT: 1 Connection: keep-alive Host: example.com <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://example.com/webservices/BillingAccountSummary/V1"> <soapenv:Header/> <soapenv:Body> <getAccountBalance> <messageHeader> <action>get</v1:action> <scopeObject>AccountBalance</v1:scopeObject> <revision>1.0</v1:revision> <createdTimestamp>2017-01-13T09:15:01.469</v1:createdTimestamp> <sourceInterface>WEB</v1:sourceInterface> <messageIdentifier>00810187-101EDDA4</v1:messageIdentifier> <functionName>getAccountBalance</v1:functionName> </messageHeader> <billingAccountIdentifier>1234566</v1:billingAccountIdentifier> </getAccountBalance> </soapenv:Body> </soapenv:Envelope>
REST style APIs utilize various HTTP methods that may not be standard in traditional web applications, such as the PUT method, to update resource values as well as DELETE methods to remove values within an API. REST requests can utilize parameter calls via the URL (not recommended for sensitive data) or via the HTTP body in JavaScript Object Notation (JSON).
An example REST request subscribing the [email protected] email address to an email distribution list is shown here:
POST /rest/email/subscribe HTTP/1.0 Host: example.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Content-Type: application/json Content-Length: 160 Connection: close { "subscriberId":"12345", "emailAdress":"[email protected]", "confirmed":"Y" }
In order to view SOAP or REST requests, a man-in-the-middle proxy is required. Tools such as Burp Suite and/or OWASP ZAP are used as web proxies to view all requests being made from the browser and the mobile application to the application's web backend infrastructure. We will go through setting up the configuration to proxy the application traffic later on in Chapter 4, Exploitation of Embedded Web Applications.
As it pertains to IoT, web applications are a common way to control devices and are just one attack entry point from both the internal and external network perspective. In Chapter 4, Exploitation of Embedded Web Applications, we will learn how to identify common IoT web application flaws and exploits.
Mobile applications in IoT
In the IoT space, mobile applications are similar to the web application models previously discussed. Although discussing specific details about security models for mobile device platforms is beyond the scope of this book, having a foundational knowledge of mobile application development models will help with testing when moving forward.
Hybrid
Mobile applications installed on an Android, iOS, or Windows phone device can be hybrid or native. Although the terms hybrid and native have different meanings in the mobile application sense rather than web applications, the principals are similar. A hybrid application utilizes both web technologies, such as HTML/HTML 5, CSS, and JavaScript, as well as some native platform hardware, such as GPS or Bluetooth. Access to hardware resources is only through the use of plugins provided by the hybrid framework. Think of hybrid apps as web applications packaged up into a wrapper that the native platform can use. This means that a web developer can now code a mobile app without having the learning curve of a new language.
Hybrid applications use one code base for multiple platforms, such as Windows Phone, Android, and iOS, which is a huge plus when thinking of the first to market for IoT devices. Applications are called over the web using an embedded web browser known as WebView. There are many hybrid frameworks that the most popular apps use in the market today, such as Apache Cordova, Adobe PhoneGap, and Xamarin, to name a few.
Each of the mobile hybrid frameworks contains a third-market place which contains plugins for various features. Some frameworks such as Xamarin are written in one programming language (C#) and translated into a native language (Objective C and Java) for rapid development purposes. These mobile frameworks are known to have a number of security advisories ranging from critical remote code execution issues on the native platform to privacy concerns. If you happen to notice a certain mobile hybrid framework being utilized, it might be a good idea to have a look at a vulnerability database for easy wins.
To give you a better idea about the architecture it takes to run a hybrid application, the following diagram shows the different components between the application code, WebViews, plugins, and the mobile device itself. Keep in mind, most of the wrapper code and plugins are developed by the hybrid framework or third-party developers who contribute to the framework:
Native applications
Native applications are built for specific operating systems and written within the device platform's native language, such Java, Objective C, Swift, and even C# for Windows phones. Native applications use their respective platform SDKs, which gives the app access to hardware such as the camera, Bluetooth, and GPS. Performance and security are better with native apps but they are dependent on an experienced developer who knows a native language. This may be difficult, in some cases, for staffing developers as platform APIs often update and deprecate language classes or methods. More and more, platforms such as iOS and Android are developing native security APIs that developers can take advantage of without the need for utilizing third-party libraries. This is important for secure communication and secure data storage.
A native architecture is much simpler than hybrid application architectures. The following diagram shows a native application running native code directly on the device without the need for third-party components to access hardware resources:
It's important to understand the pros and cons of each mobile application model for efficient testing. As device control is delegated to mobile apps, they are another attack entry point into a device that can sometimes be easier than another entry point. In Chapter 5, Exploitation of IoT Mobile Applications, we will delve into some of the most common vulnerabilities in IoT mobile apps as we dissect an IoT device.
