Dynamic analysis of firmware components in IoT devices
9.7.22 IoT Securelist
Research object and procedure
System-level emulation using Renode
Application-level debugging using GDB and QEMU
Application-level debugging using the Qiling Framework
Bonus: using GDB for debugging on a real-world device
Conclusion
Firmware analysis is an essential part of security research and targeted search for vulnerabilities in IoT products, vehicle components, industrial control systems, and a multitude of other types of software/hardware systems designed for various purposes.
The overall size of device firmware and the volume of software code in individual binary files can often be quite large. In such cases, it can be a good idea to conduct dynamic analysis of the firmware to save time and effort. Dynamic analysis allows the researcher to see how specific code works, find the call chain that leads to the execution of a specific branch, do fuzzing, and much more.
This article examines conventional methods of dynamic analysis:
Combining QEMU and GDB, and debugging directly on the target system.
It also discusses some less obvious but at the same time more interesting methods:
The Renode emulator, a tool for full system emulation that has largely been neglected by the security research community.
The Qiling framework, a tool for emulating APIs of operating systems and environments (such as UEFI). This tool is inherently similar to qemu-user, but is highly flexible and adaptable because it is written in Python, a high-level programming language.
Each tool has its own strong points and shortcomings, and can be suitable for a specific range of tasks to varying degrees.
We will demonstrate some of the capabilities of these tools using the firmware of a network video recorder from a major manufacturer. It is worth noting that our research will be conducted without having the actual device on hand.
As a bonus case study, we will demonstrate debugging using GDB on another device that we have on hand – a head unit from a major car brand.
Research object and procedure
Using the analysis of a network video recorder’s firmware as an example, we will show some of the difficulties encountered by security researchers when analyzing device firmware and possible ways to overcome these difficulties using a modern and effective toolset.
The general workflow of a firmware researcher can be divided into several stages:
Determine the format of the firmware, unpack it, and analyze the component parts of multi-component firmware.
Conduct an initial analysis of the data obtained: determine the target architecture, the OS, and the purpose of individual files.
Conduct static analysis of those parts of the firmware which are of interest, and determine whether dynamic analysis is necessary and what its scope should be.
Choose targets for dynamic analysis and tools for implementing it.
Attempt to run the component to be analyzed using the tool selected.
Set up “stubs” to bypass parts of the software that either do not require emulation or cannot be emulated, and to define the initial state.
Analyze the results of running the code being analyzed using the selected tool.
The video recorder selected for our firmware research is based on the HiSilicon platform and runs Linux. The firmware downloaded from the manufacturer’s website consists of a single file in which the binwalk tool detected a CramFS file system. After unpacking the file, we find uImage – a combined image of the Linux kernel and initramfs – as well as several encrypted scripts and TAR archives.
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0xCA9A1902, created: 2019-08-23 07:16:16, image size: 4414954 bytes, Data Address: 0x40008000, Entry Point: 0x40008000, data CRC: 0xDE0F30AC, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.18.20"
64 0x40 Linux kernel ARM boot executable zImage (little-endian)
2464 0x9A0 device tree image (dtb)
16560 0x40B0 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: -1 bytes
4401848 0x432AB8 device tree image (dtb)
After obtaining basic information about the object of our research, we attempt to employ the tools mentioned above to obtain more information, including additional files. Among these files, we identify potential targets for further analysis.
System-level emulation using Renode
Renode is a tool designed to emulate the entire target system, including the interactions between multiple virtual processors, each of which may have its own architecture and firmware, virtual memory chips, sensors, displays and other peripheral devices. Renode also enables you to interlink emulated hardware with real hardware implemented as a programmable logic device (an FPGA chip).
It is worth noting that, although Renode is primarily designed to emulate Embedded/IoT devices running embedded operating systems, it can also run full-fledged operating systems such as Linux or QNX. The project’s repository on GitHub provides relevant examples of these different scenarios. Please refer to documentation for a list of debug boards for which Renode provides out-of-the-box support for at least some peripherals.
Renode developers primarily position it as a tool designed to make embedded software development, debugging, and automated testing easier. However, it can also be used as a dynamic analysis tool to analyze the behavior of systems. Useful features provided by Renode include:
Support for ARM Cortex-A/M, x86, RISC-V, SPARC, and POWER architectures
Capability to emulate any peripheral device in C#
Interconnection of virtual devices using I2C, SPI, USB, Ethernet, and other interfaces
Capability to connect to the emulated system with the GDB debugger for debugging purposes, and to analyze and change CPU registers, the state of system memory, virtual devices, and much more at any time, including by scripting.
Capability to write handlers for specific events (for example, reading from / writing to specific memory addresses) in Python or C#.
Capability to write plug-ins in .NET languages to implement new commands, such as commands that import function and variable names from IDA/Ghidra SRE.
Describing the emulated platform
Peripheral devices that are part of single-chip systems are normally available via Memory Mapped I/O (MMIO) – physical memory regions to which registers of the corresponding peripheral modules are mapped. Renode provides the capability to build an on-chip system from building blocks using a configuration file with the .repl (REnode PLatform) extension that describes which devices should be mapped to which memory addresses.
Information about available peripheral devices and the memory map for the platform employed can be found in SoC documentation (if publicly available). If the documentation is not available, you can find this information through other means, such as by analyzing the contents of the Device Tree Blob (DTB), a data block describing the platform that is required by the Linux kernel to run Linux on embedded devices.
In the firmware being analyzed, the DTB block is attached to the end of the uImage file (according to information from the binwalk tool). After converting the DTB into a readable format (DTS) using the dtc tool, we can use it to create a platform description for Renode:
uart0: UART.PL011 @ sysbus 0x12080000
-> gic@6
size: 0x1000
uart1: UART.PL011 @ sysbus 0x12090000
-> gic@7
size: 0x1000
uart2: UART.PL011 @ sysbus 0x120a0000
-> gic@8
size: 0x1000
uart3: UART.PL011 @ sysbus 0x12130000
-> gic@20
size: 0x1000
timer0: Timers.SP804 @ sysbus 0x12000000
-> gic@1
memory: Memory.MappedMemory @ sysbus 0x40000000
size: 0x8000000
sysCtl: Miscellaneous.ArmSysCtl @ sysbus <0x12050000, +0x1000>
procId: 0x0C000191
pl310: Cache.PL310 @ sysbus <0x10700000, +0x10000>
gic: IRQControllers.GIC @ {
sysbus new Bus.BusMultiRegistration { address: 0x10301000; size: 0x1000; region: "distributor"};
sysbus new Bus.BusMultiRegistration { address: 0x10300100; size: 0x100; region: "cpuInterface"}
}
0 -> cpu@0
itLinesNumber: 2
numberOfCPUs: 1
cpu: CPU.Arm @ sysbus
cpuType: "cortex-a9"
sysbus:
init:
Tag <0x12080000, 0x12080FFF> "UART0"
Tag <0x12090000, 0x12090FFF> "UART1"
Tag <0x120A0000, 0x120A0FFF> "UART2"
The above platform description for Renode was created using a minimal set of peripheral devices listed in the Device Tree, which includes serial interfaces (UART), the system clock, RAM, and an interrupt controller. This should be enough to at least run something, and then we can proceed according to the situation. An example of a serial interface description in DTS is shown below:
uart@12080000 {
compatible = "arm,pl011\0arm,primecell";
reg = <0x12080000 0x1000>;
interrupts = <0x00 0x06 0x04>;
clocks = <0x02 0x23>;
clock-names = "apb_pclk";
status = "okay";
};
Luckily for us, all the necessary devices in this case were already available in the Renode library: the PL011 serial port, the SP804 clock, and the standard ARM interrupt controller. However, in many cases, a minimal implementation of a specific device that is not included in Renode has to be written or, alternatively, stub tags can be used instead (as described below).
Starting emulation
An initialization script has to be prepared to run something useful on the platform obtained. The script normally loads executable code into the platform’s memory, configures processor registers, sets additional event handlers, configures the output of debug messages (if necessary), etc.
:name: HiSilicon
:description: To run Linux on HiSilicon
using sysbus
$name?="HiSilicon"
mach create $name
machine LoadPlatformDescription @platforms/cpus/hisilicon.repl
logLevel 0
sysbus LogAllPeripheralsAccess true
### create externals ###
showAnalyzer sysbus.uart0
### redirect memory for Linux ###
sysbus Redirect 0xC0000000 0x40000000 0x8000000
### load binaries ###
sysbus LoadBinary "/home/research/out/uImage" 0x40008000
sysbus LoadAtags "console=ttyS0,115200 mem=128M@0x40000000 nosmp maxcpus=0" 0x8000000 0x40000100
### set registers ###
cpu SetRegisterUnsafe 2 0x40000100 # atags
cpu PC 0x40008040
The script loads the uImage file into the platform’s memory at the address taken from the binwalk output, configures kernel arguments (Linux expects ATAGS to be passed at the offset of 0x100 bytes from the start of RAM, and the address is also passed in the r2 register), and passes control to address 0x40008040 because the first 0x40 bytes are taken by the uImage header.
The initialization script may also perform many additional actions, such as setting different processor registers (e.g., if code execution does not begin from the entry point) or write any value to the platform memory (e.g., if it’s necessary to patch specific instructions in the executable code loaded at previous steps). It can also enable the GDB server or print debug information about all peripheral access attempts:
# Start GDB server on localhost:3333
machine StartGdbServer 3333
# Write 2 NOP instructions (ARM Thumb) at address 0xdeadbeef
sysbus WriteDoubleWord 0xdeadbeef 0x46c046c0
# Print all queries to virtual devices to console
sysbus LogAllPeripheralsAccess true
The Renode emulator provides enough capabilities to quickly start the dynamic analysis of the firmware being studied. Now we can start emulation:
Starting emulation
The console output shows that the emulator apparently entered an infinite loop while checking some condition (register value in memory) and refuses to continue execution:
Infinite query at the address 0x1000001
We start by looking at the unpacked Device Tree and try to find out which device corresponds to the address requested. We determine that this should be the address of the Flash Memory Controller (NOR/NAND memory controller):
flash-memory-controller@10000000 {
compatible = "hisilicon,hisi-fmc";
reg = <0x10000000 0x1000 0x14000000 0x10000>;
reg-names = "control\0memory";
clocks = <0x02 0x2c>;
#address-cells = <0x01>;
#size-cells = <0x00>;
...
We can try to trick the system into continuing execution. Instead of adding a full-fledged Flash memory controller to the platform description file, we can try to emulate only the register requested by adding a stub tag. But first we need to find out which value is expected by the kernel in the register located at address 0x10000018 to continue execution. Through a search on GitHub, we find the source code of the controller’s driver in the Linux kernel (drivers/mtd/spi-nor/hisi-sfc.c) and we notice that the register in question is used in the wait_op_finish function:
static inline int wait_op_finish(struct hifmc_host *host)
{
u32 reg;
return readl_poll_timeout(host->regbase + FMC_INT, reg,
(reg & FMC_INT_OP_DONE), 0, FMC_WAIT_TIMEOUT);
}
The FMC_INT_OP_DONE constant is equal to 1. Therefore, to skip the loop, the kernel needs to read 1 from the FMC_INT register. This can be ensured by adding the following tag after Tag <0x120A0000, 0x120A0FFF> "UART2" in the platform description:
Tag <0x10000018, 0x1000001C> "FMCINT" 0x1
Now the value 1 will always be read at address 0x10000018. In addition to setting a fixed value, Renode enables you use Python scripts embedded in the platform description to implement a more sophisticated logic for handling address-based read/write operations. Examples of this usage scenario can be found in startup scripts and platform description files provided with Renode.
Next, we restart the emulator. Now, the window of the terminal connected to the virtual serial port uart0 displays the standard Linux shell, with which you can interact as usual:
Starting emulation
This means that we were able to partially run the firmware of the network video recorder without actually having the recorder on hand. In the next steps, we can use the tools available in the emulated file system to decrypt the encrypted firmware files, extract kernel modules that provide the recorder functionality and analyze their logic, etc.
Exchanging data with the emulated system
Previously, we extracted several encrypted tar.lzma archives from the video recorder’s firmware file. After a quick analysis of the files and scripts present in the system running in Renode, we can see that these archives are decrypted using the /bin/ded application, which in turn queries the /dev/hikded device provided by the hik_ded.ko kernel module. This kernel module in its turn queries another kernel module, hik_hal.ko, which actually decrypts the encryption key and the encrypted archive. To avoid wasting time on a detailed analysis of the entire process using static analysis tools, we can run this chain in the emulator to complete processing the encrypted files and then download the decrypted archives.
First we need to find a way to transfer the encrypted files to the emulated system. The only on-chip devices available in our virtual system that can be used for communication are the RAM and serial ports. However, the total size of the archives is too large for transferring them through a serial port (with its low transfer speed) to be practicable. Therefore, we will try to transfer them through RAM. As regards virtual serial ports, Renode supports setting up communication with them from a host system via the TCP server or creating a pty device (the latter works only in Linux and macOS).
We use a familiar command to load an encrypted file into the memory of the virtual machine:
sysbus LoadBinary "/home/research/out/sys_app.tar.lzma" 0x48000000
The sys_app.tar.lzma file will be loaded into physical memory at the address specified. We can retrieve it from there by using the /dev/mem device, which can be used in Linux to read and write directly to physical memory.
dd if=/dev/mem of=/sys_app.tar.lzma.encrypted bs=1M seek=1152 count=10
Now we can decrypt the data using standard tools included in the firmware:
ded -d /sys_app.tar.lzma.encrypted /sys_app.tar.lzma
tar -atvf /sys_app.tar.lzma
After verifying that the file was successfully decrypted, we need to transfer the decryption results from the virtual machine. This can also be done through /dev/mem. However, the out-of-the-box configuration of Renode does not include a command for saving a fragment of physical memory contents to a file, while commands that provide communication with memory through the GDB server work with virtual addresses. We’ll have to implement this capability with a simple plug-in:
using System;
...
namespace Antmicro.Renode.Plugins.MemoryDumpPlugin {
public sealed class MemoryDumpCommand : Command {
public override void PrintHelp(ICommandInteraction writer) {
base.PrintHelp(writer);
writer.WriteLine(String.Format("{0} address length \"file\"", Name));
}
[Runnable]
public void Run(ICommandInteraction writer, HexToken address, HexToken length, StringToken fileName) {
byte[] memory = monitor.Machine.SystemBus.ReadBytes((ulong)address.Value, (int)length.Value);
File.WriteAllBytes(fileName.Value, memory);
}
public MemoryDumpCommand(Monitor monitor) : base(monitor, "dump_memory", "Dump memory to file.") { }
}
}
After loading the plug-in, the Renode console will support a new command, dump_memory, which can be used to extract data from the VM memory and unpack the archive. Further analysis of the files extracted is beyond the scope of this article and will be omitted.
Conclusions on this tool
We have examined a practical example of using the Renode emulator to run and decrypt firmware files from a real-world device. In this case, thanks to Renode’s support of the peripherals used in the HiSilicon SoC, we were able to use a fully functional Linux terminal without having to write any code.
At the same time, where necessary, the modular architecture of the emulator and its scripting capabilities make it relatively easy to implement support for any lacking functionality at a level that is sufficient to conduct research.
The emulator’s versatility enables it to run full-fledged operating systems such as Linux or QNX as well as small embedded real-time operating systems such as FreeRTOS, mBed OS, embOS, etc.
One of the distinguishing features of this tool is its use of system-level emulation. As a result of this, it can be difficult to use it to fuzz-test or debug a user-space application that runs in an emulated operating system.
The tool’s shortcomings include the lack of detailed documentation, with existing documentation describing only the most basic usage scenarios. When implementing something more complicated, such as a new peripheral device, or when trying to understand how a specific built-in command works, you have to repeatedly refer to the project repository on GitHub and study the source code of both the emulator itself and bundled peripheral devices.
Application-level debugging using GDB and QEMU
Strictly speaking, in our particular case third-party tools are not really required for dynamic analysis of user-space applications: the operating system we are using, i.e., Linux, enables limited debugging of these applications using the standard GDB.
The firmware to be analyzed is designed for the ARM architecture, while our research is being conducted on an x86_64 system, so we will need QEMU with support for user-mode ARM emulation to run ELF files.
To conduct our experiment, we need to extract the file system that we have already seen in the Renode terminal from the firmware to be analyzed and to install the qemu-user and gdb-multiarch packages:
udo apt install gcc-arm-linux-gnueabihf libc6-dev-armhf-cross qemu-user-static gdb-multiarch
Now we can run the chroot command and switch to an environment that is similar to the one we saw in Renode. QEMU, which was installed at the previous step, provides transparent emulation of ARM instructions. However, when using this approach, only user-level programs will be available for running and debugging because the Linux kernel in the chroot environment will be inherited from the host operating system.
chroot in an ARM environment
Thanks to the built-in GDB server, QEMU is able to debug Linux applications that were compiled for the ARM architecture by using the GDB debugger on an x86 system. As an example, we will try to debug /bin/ded:
qemu-arm-static -g 9999 -L ~/out/cpio/bin/ded
Next, we start GDB in another terminal window:
GDB QEMU 1
GDB QEMU 2
The debugger started and stopped at the entry point of /bin/ded.
Conclusions on this tool
Obviously, one of the limitations of this approach (in contrast to Renode) is that, when using qemu-user, we cannot load the Linux kernel and its modules, which implement a substantial part of the functionality in the case of the firmware we are analyzing. Specifically, the /bin/ded tool from the above example returns an error, even though it runs flawlessly and correctly decrypts encrypted files when it is run in the Renode emulator. In addition, this approach will not work if the firmware being analyzed is not based on Linux. This is because qemu-user works by converting ARM executable code to x86_64 instructions and directly relays system calls to the Linux kernel. However, the method we will examine next does not have this limitation.
Application-level debugging using the Qiling Framework
Qiling is an advanced multi-platform framework for emulating binary files. It can emulate a multitude of platforms and environments, including:
Emulation of Windows, MacOS, Linux, QNX, BSD, UEFI, DOS, MBR, and Ethereum Virtual Machine
Support for x86, x86_64, ARM, ARM64, MIPS, and 8086 architectures
Support for various executable file formats, including PE, Mach-O, ELF, COM, and MBR.
The framework itself was written in Python, which makes adapting its functionality to our specific needs sufficiently easy. The Qiling Framework uses the Unicorn engine, which is simply an emulator of machine instructions, while Qiling provides high-level functions such as file system emulation, dynamic libraries, loading various formats of executable files, etc.
Compared to QEMU, the Qiling Framework can emulate more platforms, provides flexible configuration of the emulation process, including the capability to modify executing code on-the-fly. In addition, it is a cross-platform framework, which means it can be used to emulate Windows or QNX executables on Linux, and vice versa. The Qiling Framework repository also contains examples of running the AFL fuzzer in Unicorn mode for Linux and QNX executables. We’ll take advantage of this later.
For our first encounter with Qiling, our equivalent hello-world example will be to use Qiling to start the familiar ded tool from the firmware being analyzed. To do so, we will copy the device file system to examples/rootfs/hikroot and write the following simple script named examples/hikded_arm_linux.py:
import sys
sys.path.append("..")
from qiling import Qiling
from qiling.const import QL_VERBOSE
def run_sandbox(path, rootfs, verbose):
ql = Qiling(path, rootfs, verbose = verbose)
ql.run()
if __name__ == "__main__":
run_sandbox(["rootfs/hikroot/bin/ded"], "rootfs/hikroot", QL_VERBOSE.DEFAULT)
When operating at the DEFAULT logging verbosity level, the Qiling Framework sends information about emulated system calls to the console similarly to the strace Linux tool.
Now we can try to start the AFL++ fuzzer, which will use Qiling as a runtime environment. In most cases, this type of fuzzer will run very slowly. However, thanks to the fact that the Qiling Framework can emulate a broad variety of environments and operating systems, as well as its support for UEFI and various microprocessor architectures, in some cases this may be the only way to do fuzzing with minimal effort.
The ded tool examined earlier is not suitable as a target for fuzzing because its code is too simple and will return an error and exit due to the inability to open the /dev/hikded device regardless of the input data. This is why we will use another tool, hrsaverify, from the same firmware. It is used to validate encrypted files and takes the path to the file to be validated as an argument. The Qiling Framework already has several examples of running the AFL++ fuzzer in the examples/fuzzing directory of its repository. We will adapt the example named linux_x8664 to run hrsaverify. The modified script for running the fuzzer is shown below:
import unicornafl as UcAfl
UcAfl.monkeypatch()
import os, sys
from typing import Any, Optional
sys.path.append("../../..")
from qiling import Qiling
from qiling.const import QL_VERBOSE
from qiling.extensions import pipe
def main(input_file: str):
ql = Qiling(["../../rootfs/hikroot/usr/bin/hrsaverify", "/test"], "../../rootfs/hikroot",
verbose=QL_VERBOSE.OFF, # keep qiling logging off
console=False, # thwart program output
stdin=None, stdout=None, stderr=None) # don't care about stdin/stdout
def place_input_callback(uc: UcAfl.Uc, input: bytes, persistent_round: int, data: Any) -> Optional[bool]:
"""Called with every newly generated input."""
with open("../../rootfs/hikroot/test", "wb") as f:
f.write(input)
def start_afl(_ql: Qiling):
"""Callback from inside."""
# We start our AFL forkserver or run once if AFL is not available.
# This will only return after the fuzzing stopped.
try:
if not _ql.uc.afl_fuzz(input_file=input_file,
place_input_callback=place_input_callback, exits=[ql.os.exit_point]):
_ql.log.warning("Ran once without AFL attached")
os._exit(0)
except UcAfl.UcAflError as ex:
if ex.errno != UcAfl.UC_AFL_RET_CALLED_TWICE:
raise
# Image base address
ba = 0x10000
# Set a hook on main() to let unicorn fork and start instrumentation
ql.hook_address(callback=start_afl, address=ba + 0x8d8)
# Okay, ready to roll
ql.run()
if __name__ == "__main__":
if len(sys.argv) == 1:
raise ValueError("No input file provided.")
main(sys.argv[1])
The first thing we should look for is the base address of the executable file (in our case, 0x10000), the address of the main function. Sometimes it is necessary to additionally set hooks on other addresses that, when encountered, should be considered as a crash by the fuzzer. For example, when running AFL in a QNX environment (in the qnx_arm directory), this type of additional handler is set for the address of the SignalKill function in libc. In the case of hrsaverify, no additional handlers are needed. It should also be kept in mind that all files that must be available to the running application should be put into sysroot, and their relative paths should be passed (in this case, ../../rootfs/hikroot/).
AFL++ is started with the following command:
AFL_AUTORESUME=1 AFL_PATH="$(realpath ./AFLplusplus)" PATH="$AFL_PATH:$PATH" afl-fuzz -i afl_inputs -o afl_outputs -U -- python ./fuzz_arm_linux.py @@
The AFL fuzzer will start, and after some time we will see some crashes:
AFL++
Conclusions on this tool
Qiling is a promising tool whose main advantages are its high flexibility, extensibility, and support for a broad variety of architectures and environments. The framework can serve as a substitute for qemu-user in cases where using the latter is not possible (for example, unsupported target OS or the lack of required additional capabilities, such as setting arbitrary handles for any memory addresses, special handling of interrupts, etc.). However, its high flexibility and shallow learning curve due to its use of Python also contribute to its low emulation speed.
Bonus: using GDB for debugging on a real-world device
Developers deliberately leave various engineering interfaces (such as the UART console, JTAG, etc.) on many devices’ circuit boards. These interfaces are often deactivated on the software or hardware level, are password-protected, or have some other form of access restriction. However, in many cases an interface is immediately accessible or a researcher is able to gain access to it during research. In such cases, communication with the system being analyzed is possible via the command line or the JTAG debugger.
When using JTAG, you can read or write contents to ROM or RAM, set breakpoints, manage peripheral devices by writing to addresses corresponding to their I/O registers, analyze the state of processor registers, etc.
When using UART, it is often possible to interact with the first-stage bootloader (such as U-Boot) and with the command shell of the operating system that has been loaded. When combined with the ability to modify ROM contents or other ways to write/edit files in the device file system (such as downloading files over the network via FTP), this opens up the possibility of interactively debugging applications directly on the device. To use this method, you usually have to start by compiling the GDB server for the target architecture and OS.
To demonstrate this method, we will connect a debugger to the head unit of a multimedia system for one of the more popular car brands, which runs the QNX real-time operating system.
The QNX SDK includes a modified GDB debugger with its own remote debugging protocol that is incompatible with the standard GDB server. This is why the pdebug daemon must be run on the device instead of the GDB server, after first copying it from the SDK if it is not already present on the device. The daemon can communicate with the remote GDB debugger via TCP or a serial port, which means that at least one of these device communication methods must be available for debugging to be possible.
We added the pdebug daemon to the device file system by modifying the memory contents. Let’s run it:
Starting the pdebug daemon
The port used for the connection is TCP port 22, which is the only port on the device being analyzed that is available for remote connections, while all other ports on the device are protected by the firewall. Now we can connect to the daemon using the GDB debugger that is included in the QNX Software Development Platform (SDK), and select a process to be debugged from the list of running processes or start a new process.
GDB is connected to the head unit via TCP
Please refer to official documentation for a concise guide on debugging with GDB in QNX.
GDB is connected to process with ID 24584
In addition to using the device being analyzed for debugging, you can use other suitable devices. For example, the QNX 6.6 operating system used in this example can also be run on an easily accessible and affordable BeagleBone Black board. Although its hardware is different from that of the device being analyzed, you will most likely be able to analyze some of the applications from the firmware by simply copying pdebug to a partially compatible board and running it.
This could prove very useful, especially since modifying a device’s firmware to load the pdebug daemon into it, as demonstrated in this section, takes significant time and effort. Therefore, it may be less resource-intensive to just copy individual files from the firmware and run them on a compatible processor.
Conclusions on this tool
In the initial stages of research, it is usually difficult or even impossible to access various debugging interfaces of industrial devices. This means that it will most likely take some effort to ensure such access by activating disabled interfaces, soldering the missing electronic components onto the board, modifying the firmware, etc. However, after completing this intermediate task, debugging directly on the device may substantially simplify the rest of the research process.
Conclusion
Naturally, this article does not cover all of the diverse issues that the author encounters when researching device firmware. Nonetheless, it attempts to cover those issues which are most frequently encountered in the initial stages of research, and discusses problems that the author believes are potential stumbling blocks for the inexperienced researcher.
The author hopes that this overview of tools will make the work of beginning researchers easier and will accelerate their immersion into the subject matter of device firmware dynamic analysis.
The author also hopes that this overview will encourage the more experienced researchers to contribute to further development of the tools and frameworks described in this article.
New Privacy Framework for IoT Devices Gives Users Control Over Data Sharing
11.6.22 IoT Thehackernews
A newly designed privacy-sensitive architecture aims to enable developers to create smart home apps in a manner that addresses data sharing concerns and puts users in control over their personal information.
Dubbed Peekaboo by researchers from Carnegie Mellon University, the system "leverages an in-home hub to pre-process and minimize outgoing data in a structured and enforceable manner before sending it to external cloud servers."
Peekaboo operates on the principle of data minimization, which refers to the practice of limiting data collection to only what is required to fulfill a specific purpose.
To achieve this the system requires developers to explicitly declare the relevant data collection behaviors in the form of a manifest file that's then fed into an in-home trusted hub to transmit sensitive data from smart home apps such as smart doorbells on a need-to-know basis.
The hub not only functions as a mediator between raw data from IoT devices and the respective cloud services, it also enables third-party auditors to vet an app developer's data collection claims.
The manifest file, for its part, is analogous to Android's "AndroidManifest.xml" file that details the permissions an app needs in order to access protected parts of the system or other apps.
But while it is more of a binary approach in Android where apps are either unilaterally allowed or denied access to a specific feature (e.g., camera), Peekaboo makes it possible to define the data collection practices in a more adjustable manner — the kind of data to be gathered, when it should be carried out, and how frequently.
"With Peekaboo, a user can install a new smart home app by simply downloading a manifest to the hub rather than a binary," the researchers explained.
"This approach offers more flexibility than permissions, as well as a mechanism for enforcement. It also offers users (and auditors) more transparency about a device's behavior, in terms of what data will flow out, at what granularity, where it will go, and under what conditions."
What's more, Peekaboo is also designed to auto-generate live privacy nutrition labels that summarize an app's declared behavior à la Apple's privacy labels in iOS and Android's Data safety section.
"Peekaboo offers a hybrid architecture, where a local user-controlled hub pre-processes smart home data in a structured manner before relaying it to external cloud servers," the researchers said.
Researchers Demonstrate Ransomware for IoT Devices That Targets IT and OT Networks
3.6.22 IoT Thehackernews
As ransomware infections have evolved from purely encrypting data to schemes such as double and triple extortion, a new attack vector is likely to set the stage for future campaigns.
Called Ransomware for IoT or R4IoT by Forescout, it's a "novel, proof-of-concept ransomware that exploits an IoT device to gain access and move laterally in an IT [information technology] network and impact the OT [operational technology] network."
This potential pivot is based on the rapid growth in the number of IoT devices as well as the convergence of IT and OT networks in organizations.
The ultimate goal of R4IoT is to leverage exposed and vulnerable IoT devices such as IP cameras to gain an initial foothold, followed by deploying ransomware in the IT network and taking advantage of poor operational security practices to hold mission-critical processes hostage.
"By compromising IoT, IT, and OT assets, R4IoT goes beyond the usual encryption and data exfiltration to cause physical disruption of business operations," the researchers said, thereby adding an additional layer of extortion to a traditional ransomware attack.
Put differently, R4IoT is a new kind of malware that brings together an IoT entry point and ransomware-related lateral movement and encryption on an IT network, causing an extended impact on both IT and OT networks.
In a hypothetical scenario, this could entail compromising a machine in the corporate network to not only drop ransomware but also retrieve additional payloads from a remote server to deploy cryptocurrency miners and launch denial-of-service (DoS) attacks against OT assets.
To mitigate both the likelihood and the impact of potential R4IoT incidents, organizations are recommended to identify and patch vulnerable devices, enforce network segmentation, implement strong password policies, and monitor HTTPS connections, FTP sessions, and network traffic.
"Ransomware has been the most prevalent threat of the past few years, and so far, it has mostly leveraged vulnerabilities in traditional IT equipment to cripple organizations," the researchers concluded.
"But new connectivity trends have added a number and a diversity of OT and IoT devices that have increased risk in nearly every business."
Lumos System Can Find Hidden Cameras and IoT Devices in Your Airbnb or Hotel Room
26.5.22 IoT Thehackernews
A group of academics has devised a system that can be used on a phone or a laptop to identify and locate Wi-Fi-connected hidden IoT devices in unfamiliar physical spaces.
With hidden cameras being increasingly used to snoop on individuals in hotel rooms and Airbnbs, the goal is to be able to pinpoint such rogue devices without much of a hassle.
The system, dubbed Lumos, is designed with this intent in mind and to "visualize their presence using an augmented reality interface," said Rahul Anand Sharma, Elahe Soltanaghaei, Anthony Rowe, and Vyas Sekar of Carnegie Mellon University in a new paper.
At its core, the platform works by snuffing and collecting encrypted wireless packets over the air to detect and identify concealed devices. Subsequently, it estimates the location of each identified device with respect to the user as they walk around the perimeter of the space.
The localization module, for its part, combines signal strength measurements that are available in 802.11 packets (aka Received Signal Strength Indicator or RSSI) with relative user position determined by visual inertial odometry (VIO) information on mobile phones.
On Apple's iOS devices, for instance, the positional tracking is achieved by means of ARKit, a developer API that makes it possible to build augmented reality experiences by taking advantage of the phone's camera, CPU, GPU, and motion sensors.
"As the user walks closer to each device, the RSSI values corresponding to those data points increase and then reduce as she walks away from the device," the researchers said. "Lumos leverages the spatial measurements of RSSI values and their variations to estimate the location of each device."
What's more, Lumos can localize IoT devices irrespective of the user's walking speed. Also incorporated is a fingerprinting module that analyzes the captured 802.11 traffic patterns using a machine learning model to identify the devices based on the MAC addresses.
The research evaluated Lumos across 44 different IoT devices spanning various types, models, and brands across six different environments, finding that it can identify hidden devices with 95% accuracy and locate them with a median error of 1.5m within 30 minutes in a two-bedroom, 1000 sq.ft. apartment.
That said, an advanced attacker can leverage techniques like MAC address randomization to evade detection and sidestep localization by arbitrarily modifying the devices' transmit power.
"Lumos can potentially generalize across different device brands and models, as long as it has seen at least one device with similar behavior in the training phase," the researchers said, pointing to how the system can even identify unprofiled devices.
Unpatched DNS Related Vulnerability Affects a Wide Range of IoT Devices
3.5.22 IoT Thehackernews
Cybersecurity researchers have disclosed an unpatched security vulnerability that could pose a serious risk to IoT products.
The issue, which was originally reported in September 2021, affects the Domain Name System (DNS) implementation of two popular C libraries called uClibc and uClibc-ng that are used for developing embedded Linux systems.
uClibc is known to be used by major vendors such as Linksys, Netgear, and Axis, as well as Linux distributions like Embedded Gentoo, potentially exposing millions of IoT devices to security threats.
"The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device," Giannis Tsaraias and Andrea Palanca of Nozomi Networks said in a Monday write-up.
DNS poisoning, also referred to as DNS spoofing, is the technique of corrupting a DNS resolver cache — which provides clients with the IP address associated with a domain name — with the goal of redirecting users to malicious websites.
Successful exploitation of the bug could allow an adversary to carry out Man-in-the-Middle (MitM) attacks and corrupt the DNS cache, effectively rerouting internet traffic to a server under their control.
Nozomi Networks cautioned that the vulnerability could be trivially exploited in a reliable manner should the operating system be configured to use a fixed or predictable source port.
"The attacker could then steal and/or manipulate information transmitted by users, and perform other attacks against those devices to completely compromise them," the researchers said.
Healthcare IoT Security Firm Cylera Closes $10 Million Series A Round
19.3.2021 IoT Securityweek
Healthcare IoT cybersecurity and intelligence provider Cylera today announced that it has raised $10 million in Series A funding. To date, the company has secured $17 million in funding.
Founded in 2017 and headquartered in New York City, Cylera seeks to protect both healthcare organizations and patients, providing a security and analytics platform that aims to deliver asset management, risk analysis, and threat detection for IoT, ICS, and IoMT (Internet of Medical Things).
Cylera seeks to secure the entire connected environment, providing insights and recommendations that simplify response, accelerate remediation, and improve the decision making process.
Cylera’s Series A funding round was led by Concord Health Partners and Maverick Ventures. Previous investors include Dreamit Ventures, Great Oaks Venture Capital, Red Bear Angels, and Samsung NEXT.
The funds will help the company expand to new global markets, as well as make its technology available for new verticals. Furthermore, Cylera plans to expand its research and development, customer success, channel support, and sales and marketing teams.
“Over the past year there has been a further acceleration of the digitalization and adoption of IoT devices across hospitals, pharmaceutical companies, biotech, life sciences and manufacturing in an effort to decrease operational risk and increase efficiencies. […] With our latest round of funding, Cylera is fueling the next phase of innovation to safeguard organizations against attacks on connected devices,” Cylera co-founder and CEO Timur Ozekcin said.
New Mirai Variant Leverages 10 Vulnerabilities to Hijack IoT Devices
18.3.2021 IoT Vulnerebility Securityweek
Over the past month, a variant of the Mirai botnet was observed targeting new security vulnerabilities within hours after they had been disclosed publicly, researchers with Palo Alto Networks reveal.
Around since 2016, Mirai has had its source code leaked online, which resulted in tens of variants being released over the years, each with its own targeting capabilities.
What makes the variant tracked by Palo Alto Networks stand out in the crowd is the fact that, within a four-week timeframe, it started exploiting several vulnerabilities that have been disclosed this year.
On February 23, the Mirai variant was observed targeting CVE-2021-27561 and CVE-2021-27562, two vulnerabilities in the Yealink DM (Device Management) platform that had been disclosed the very same day.
Impacting Yealink DM version 3.6.0.20 and older, the flaws (pre-auth SSRF and command injection, respectively) exist because user-provided data is not properly filtered and could be exploited to execute arbitrary commands as root, without authentication.
On March 3, Palo Alto Networks’ security researchers noticed that the same samples were also using an exploit for CVE-2021-22502, a critical (CVSS score of 9.8) remote code execution vulnerability in Micro Focus Operations Bridge Reporter.
Exploitable without authentication, the security bug exists because a user-supplied string isn’t properly validated when the Token parameter provided to the LogonResource endpoint is handled, allowing an attacker to execute code as root.
Ten days later, on March 13, the samples also incorporated an exploit targeting CVE-2020-26919, a critical vulnerability (CVSS score 9.8) affecting NETGEAR JGS516PE business-grade gigabit switches. The bug is described as “lack of access control at the function level.”
In September 2020, Netgear published an advisory for this vulnerability, advising customers to update the firmware on their devices.
Other vulnerabilities being exploited in these attacks include a SonicWall SSL-VPN bug referred to as VisualDoor, CVE-2020-25506 (D-Link DNS-320 firewall), CVE-2020-26919 (Netgear ProSAFE Plus), and CVE-2019-19356 (Netis WF2419 wireless router). Three other security issues are also being exploited, but they haven’t been identified yet.
“The attacks are still ongoing at the time of this writing. Upon successful exploitation, the attackers try to download a malicious shell script, which contains further infection behaviors such as downloading and executing Mirai variants and brute-forcers,” Palo Alto Networks reveals.
IoT Security Firm Armis Raises $125 Million at $2 Billion Valuation
11.2.2021 IoT Securityweek
Enterprise IoT security company Armis on Wednesday announced another major funding round that brings its valuation to $2 billion.
Armis said it raised $125 million in the latest round, which brings the total investment secured by the company to $300 million.
Armis valued at $2 billionThe latest funding round was led by Brookfield Technology Partners, with participation from Insight Partners, CapitalG (Alphabet’s independent growth fund), and Georgian.
Insight Partners, which announced the acquisition of Armis in January 2020 at a valuation of $1.1 billion, will remain the majority owner. Armis will remain an independent company and its founding executives will continue to manage it.
Armis says the new investment will be used to “fund an exciting backlog of new product development and expansion of the marketing and sales teams.”
The company has developed a platform that is designed to help organizations discover and monitor managed, unmanaged and IoT devices, including medical devices and industrial control systems (ICS). The company provides EDR, asset management, compliance, incident response, threat detection, and visibility solutions.
The company claims its revenue increased by more than 750% over the past couple of years and the number of customers rose by 425%. Armis says it has Fortune 100 and Global 2000 customers, including Mondelēz, Sysco, Fresenius, Home Depot, Oracle, and DocuSign.
IoT Cybersecurity Improvement Act Passes Senate
18.11.20 IoT Securityweek
The IoT Cybersecurity Improvement Act, a bill that aims to improve the security of Internet of Things (IoT) devices, passed the Senate on Tuesday and is heading to the White House for the president’s signature.
The bill was first introduced in 2017 and it was reintroduced in 2019, passing the U.S. House of Representatives in September 2020.
Backers of the legislation include Reps. Will Hurd (R-Tex.) and Robin Kelly (D-Ill.), and Sens. Mark Warner (D-Va.) and Cory Gardner (R-Colo). The bill is also backed by several major cybersecurity and tech companies, including BSA, Mozilla, Rapid7, Cloudflare, CTIA and Tenable.
IoT Cybersecurity Improvement Act has passed the Senate
“While more and more products and even household appliances today have software functionality and internet connectivity, too few incorporate even basic safeguards and protections, posing a real risk to individual and national security,” Sen. Warner said in a statement emailed to SecurityWeek. “I’m proud that Congress was able to come together today to pass this legislation, which will harness the purchasing power of the federal government and incentivize companies to finally secure the devices they create and sell. I urge the President to sign this bill into law without delay.”
Sen. Gardner commented, “I applaud the Senate for passing our bipartisan and bicameral legislation to ensure the federal government leads by example and purchases devices that meet basic requirements to prevent hackers from accessing government systems.”
He added, “Most experts expect tens of billions of devices operating on our networks within the next several years as the Internet of Things (IoT) landscape continues to expand. We need to make sure these devices are secure from malicious cyber-attacks as they continue to transform our society and add countless new entry points into our networks, particularly when they are integrated into the federal government’s networks.”
The IoT Cybersecurity Improvement Act requires NIST to issue guidelines and standards for the development, patching, and identity and configuration management of IoT devices. The law also states that government organizations can only acquire IoT devices that meet NIST’s recommendations.
The bill also focuses on making it easier to report and patch vulnerabilities found in IoT devices.
Gitpaste-12 Worm Targets Linux Servers, IoT Devices
7.11.20 IoT Virus Threatpost
The newly discovered malware uses GitHub and Pastebin to house component code, and harbors 12 different initial attack vectors.
Researchers have uncovered a new worm targeting Linux based x86 servers, as well as Linux internet of things (IoT) devices (that are based on ARM and MIPS CPUs).
Of note, the malware utilizes GitHub and Pastebin for housing malicious component code, and has at least 12 different attack modules available – leading researchers to call it “Gitpaste-12.” It was first detected by Juniper Threat Labs in attacks on Oct. 15, 2020.
“No malware is good to have, but worms are particularly annoying,” said researchers with Juniper Threat Labs in a Thursday post. “Their ability to spread in an automated fashion can lead to lateral spread within an organization or to your hosts attempting to infect other networks across the internet, resulting in poor reputation for your organization.”
The first phase of the attack is the initial system compromise. The malware’s various attack modules include 11 previously-disclosed vulnerabilities. That includes flaws in Apache Struts (CVE-2017-5638), Asus routers (CVE-2013-5948), Webadmin plugin for opendreambox (CVE-2017-14135) and Tenda routers (CVE-2020-10987).
The malware will attempt to use known exploits for these flaws to compromise systems and may also attempt to brute force passwords, said researchers. After compromising a system, a main shell script is then uploaded to the victim machine, and starts to download and execute other components of Gitpaste-12.
The Malware
This script sets up a cron job it downloads from Pastebin. A cron job is a time-based job scheduler in Unix-like computer operating systems. The cron job calls a script and executes it again each minute; researchers believe that this script is presumably one mechanism by which updates can be pushed to the botnet.
It then downloads a script from GitHub (https://raw[.]githubusercontent[.]com/cnmnmsl-001/-/master/shadu1) and executes it. The script contains comments in the Chinese language and has multiple commands available to attackers to disable different security capabilities. These include stripping the system’s defenses, including firewall rules, selinux (a security architecture for LinuxR systems), apparmor (a Linux kernel security module that allows the system administrator to restrict programs’ capabilities), as well as common attack prevention and monitoring software.
The 11 vulnerabilities utilized for Gitpaste-12’s initial attack vectors. Credit: Juniper Labs
The malware also has some commands that disable cloud security agents, “which clearly indicates the threat actor intends to target public cloud computing infrastructure provided by Alibaba Cloud and Tencent,” said researchers.
Gitpaste-12 also features commands allowing it to run a cryptominer that targets the Monero cryptocurrency.
“It also prevents administrators from collecting information about running processes by intercepting ‘readdir’ system calls and skip directories for processes like tcpdump, sudo, openssl, etc. in ‘/proc’,” said researchers. “The ‘/proc’ directory in Linux contains information about running processes. It is used, for example, by the ‘ps’ command to show information about running processes. But unfortunately for this threat actor, this implementation does not do what they expect it to do.”
Finally, the malware also contains a library (hide.so) that is loaded as LD_PRELOAD, which downloads and executes Pastebin files )https://pastebin[.]com/raw/Tg5FQHhf) that host further malicious code.
Researchers said they reported the Pastebin URL, as well as the Git repo mentioned above that downloads malicious scripts for the malware. The Git repo was closed on Oct. 30, 2020. “This should stop the proliferation of this botnet,” said researchers.
Wormable Features
In terms of its worming capabilities, Gitpaste-12 also contains a script that launches attacks against other machines, in an attempt to replicate and spread the malware.
“The malware chooses a random /8 CIDR for attack and will try all addresses within that range,” according to researchers. Classless Inter-Domain Routing (CIDR) is a method for allocating IP addresses and for IP routing – meaning that the attack targets all IP addresses within the random CIDR’s range.
Another version of the script also opens ports 30004 and 30005 for reverse shell commands, said researchers. Port 30004 uses the Transmission Control Protocol (TCP), which is one of the main protocols in TCP/IP networks; while port 30005 is a bidirectional SOAP/HTTP-based protocol, which provides communication between devices like routers or network switches, and auto-configuration servers.
Worms can have a widespread impact, as seen in a 2019 campaign that exploited a vulnerability in the Exim mail transport agent (MTA) to gain remote command-execution on victims’ Linux systems, using a wormable exploit. Researchers said that currently more than 3.5 million servers were at risk from the attacks.
Several new worms have popped up in 2020 so far, including the Golang worm, which is aimed at installing cryptominers, and recently changed up its tactics to add attacks on Windows servers and a new pool of exploits to its bag of tricks.
In August, a cryptomining worm from the group known as TeamTNT was found spreading through the Amazon Web Services (AWS) cloud and collecting credentials. Once the logins are harvested, the malware logs in and deploys the XMRig mining tool to mine Monero cryptocurrency.
IoT Device Takeovers Surge 100 Percent in 2020
24.10.20 IoT Threatpost
The COVID-19 pandemic, coupled with an explosion in the number of connected devices, have led to a swelling in IoT infections observed on wireless networks.
Connected cameras, refrigerators and other seemingly-mundane internet-of-things (IoT) devices are a cybercriminal favorite this year, with new research showing a sharp increase (100 percent) in IoT infections observed on wireless networks.
IoT devices are now responsible for 32.72 percent of all infections observed in mobile and Wi-Fi networks – up from 16.17 percent in 2019. And researchers with Nokia’s Threat Intelligence Lab said, in the Threat Intelligence Report 2020 released this week, that they believe that number of IoT infections will continue to grow “dramatically” as connected devices continue to populate in homes and enterprise settings alike.
“It’s not a surprise that IoT devices are the crown jewels for cybercriminals,” Dirk Schrader, global vice president at New Net Technologies, told Threatpost. “Businesses around the world are transforming their processes, their production lines using digitalized assets. Having control over these assets means that a cybercriminal’s hand is – literally – at the main switch of a digitally transformed company. ”
IoT devices are even a target for ransomware, he added: “The danger of being shut down almost completely is the reason why companies are more likely to pay even higher ransoms.”
Researchers pointed to the visibility of devices connected to the internet as a barometer for IoT infection rates, with high IoT infection rates occurring when devices are connected to publicly facing internet IP addresses. In networks where carrier grade network address translation (NAT) is enabled on a firewall or router, the infection rate is reduced, as the connected devices are not visible to network scanning, they said. While standard NAT translates a private IPv4 address to public IPv4 address, carrier-grade adds an additional translation layer as an extra security measure.
There are more and more devices for cybercriminals to scan: Brandon Hoffman, CISO at Netenrich, pointed out that due to the pandemic, people are also not spending money on vacations and therefore buying more connected “things” for their homes.
“As devices at home and other ‘things’ become smarter, and have computing capacity they don’t need, cybercriminals can snap that computing power up and use it to perform attacks, transfer data anonymously, and store it in places people aren’t looking,” Hoffman told Threatpost.
Overall, in 2020, Android devices were the most commonly targeted by malware, researchers found, making up 26.64 percent of all infections. Meanwhile, Windows devices and PCs, which are increasingly connected to mobile networks via USB dongles and Wi-Fi, made up 38.92 percent.
Researchers said that the coronavirus pandemic caused a surge (a 30 percent increase over 2019, specifically) in mobile-malware infections, saying the volume and type of attacks have also seen “profound” changes.
“The situation is certainly worsened during the pandemic, as the IT operations and information security teams had to organize, setup and secure a remote workforce more or less in no time,” Schrader said. “Plans for digital transformation need to be altered to reflect this ‘new normal,’ and such the problem is likely to worsen.”
IoT devices have long been under scrutiny for their lack of security measures, with researchers finding in March that more than half of all IoT devices are vulnerable to medium- or high-severity attacks, for instance.
In September, researchers found a Bluetooth Low Energy (BLE) vulnerability that impacted billions of IoT devices and remained unpatched in Android devices. And in August, researchers urged connected-device manufacturers to ensure they applied patches addressing a flaw in a module used by millions of IoT devices.
Meanwhile, the growth in IoT is far from over: The introduction of 5G is also expected to continue to increase not just the number of IoT devices, but the share of connected devices accessible directly from the internet.
Google, Intel Warn on ‘Zero-Click’ Kernel Bug in Linux-Based IoT Devices
15.10.20 IoT Threatpost
Intel and Google are urging users to update the Linux kernel to version 5.9 or later.
Google and Intel are warning of a high-severity flaw in BlueZ, the Linux Bluetooth protocol stack that provides support for core Bluetooth layers and protocols to Linux-based internet of things (IoT) devices.
Threatpost Webinar Promo Retail Security
Click to Register!
According to Google, the vulnerability affects users of Linux kernel versions before 5.9 that support BlueZ. BlueZ, which is an open-source project distributed under GNU General Public License (GPL), features the BlueZ kernel that has been part of the official Linux kernel since version 2.4.6.
The flaw, which Google calls “BleedingTooth,” can be exploited in a “zero-click” attack via specially crafted input, by a local, unauthenticated attacker. This could potentially allow for escalated privileges on affected devices.
“A remote attacker in short distance knowing the victim’s bd [Bluetooth] address can send a malicious l2cap [Logical Link Control and Adaptation Layer Protocol] packet and cause denial of service or possibly arbitrary code execution with kernel privileges,” according to a Google post on Github. “Malicious Bluetooth chips can trigger the vulnerability as well.”
The flaw (CVE-2020-12351) ranks 8.3 out of 10 on the CVSS scale, making it high-severity. It specifically stems from a heap-based type confusion in net/bluetooth/l2cap_core.c. A type-confusion vulnerability is a specific bug that can lead to out-of-bounds memory access and can lead to code execution or component crashes that an attacker can exploit. In this case, the issue is that there is insufficient validation of user-supplied input within the BlueZ implementation in Linux kernel.
Intel, meanwhile, which has placed “significant investment” in BlueZ, addressed the security issue in a Tuesday advisory, recommending that users update the Linux kernel to version 5.9 or later.
“Potential security vulnerabilities in BlueZ may allow escalation of privilege or information disclosure,” according to the security advisory. “BlueZ is releasing Linux kernel fixes to address these potential vulnerabilities.”
Google has also published proof-of-concept exploit code for the flaw on GitHub. See a video demo of BleedingTooth below:
Intel also issued a fix for two medium-severity flaws that affect BlueZ, both of which stem from improper access control. That includes CVE-2020-12352, which could enable an unauthenticated user to potentially enable information disclosure via adjacent access.
“A remote attacker in short distance knowing the victim’s bd address can retrieve kernel-stack information containing various pointers that can be used to predict the memory layout and to defeat KASLR,” according to a description on GitHub. “The leak may contain other valuable information such as the encryption keys.”
Another flaw (CVE-2020-24490) could allow an unauthenticated user to potentially enable denial of service via adjacent access. The flaw can be exploited by a remote attacker in short distance, who can broadcast extended advertising data and cause a denial-of-service state, or possibly arbitrary code execution with kernel privileges on victim machines (if they are equipped with Bluetooth 5 chips and are in scanning mode), according to Google.
Andy Nguyen, security engineer with Google, was credited with discovering the flaw. Further details will soon be available on Google’s security blog.
ALERT! Hackers targeting IoT devices with a new P2P botnet malware
8.10.20 BotNet IoT Thehackernews
Cybersecurity researchers have taken the wraps off a new botnet hijacking Internet-connected smart devices in the wild to perform nefarious tasks, mostly DDoS attacks, and illicit cryptocurrency coin mining.
Discovered by Qihoo 360's Netlab security team, the HEH Botnet — written in Go language and armed with a proprietary peer-to-peer (P2P) protocol, spreads via a brute-force attack of the Telnet service on ports 23/2323 and can execute arbitrary shell commands.
The researchers said the HEH botnet samples discovered so far support a wide variety of CPU architectures, including x86(32/64), ARM(32/64), MIPS(MIPS32/MIPS-III), and PowerPC (PPC).
The botnet, despite being in its early stages of development, comes with three functional modules: a propagation module, a local HTTP service module, and a P2P module.
Initially downloaded and executed by a malicious Shell script named "wpqnbw.txt," the HEH sample then uses the Shell script to download rogue programs for all different CPU architectures from a website ("pomf.cat"), before eventually terminating a number of service processes based on their port numbers.
The second phase commences with the HEH sample starting an HTTP server that displays the Universal Declaration of Human Rights in eight different languages and subsequently initializing a P2P module that keeps track of the infected peers and allows the attacker to run arbitrary shell commands, including the ability to wipe all data from the compromised device by triggering a self-destruct command.
Other commands make it possible to restart a bot, update the list of peers, and exit the current running bot, although an "Attack" command is yet to be implemented by the botnet authors.
"After the Bot runs the P2P module, it will execute the brute-force task against the Telnet service for the two ports 23 and 2323 in a parallel manner, and then complete its own propagation," the researchers said.
In other words, if the Telnet service is opened on port 23 or 2323, it attempts a brute-force attack using a password dictionary consisting of 171 usernames and 504 passwords. On a successful break-in, the newly infected victim is added to the botnet, thereby amplifying it.
"The operating mechanism of this botnet is not yet mature, [and] some important functions such as the attack module have not yet been implemented," the researchers concluded.
"With that being said, the new and developing P2P structure, the multiple CPU architecture support, the embedded self-destruction feature, all make this botnet potentially dangerous."
New Ttint IoT botnet exploits two zero-days in Tenda routers
5.10.20 BotNet IoT Securityaffairs
Security researchers provided technical details about an IoT botnet dubbed Ttint that has been exploiting two zero-days in Tenda routers
Security researchers at Netlab, the network security division Qihoo 360, have published a report that details an IoT botnet dubbed Ttint.
The experts are monitoring the Mirai-based botnet since November 2019 and observed it exploiting two Tenda router 0-day vulnerabilities to spread a Remote Access Trojan (RAT).
Unlike other IoT DDoS botnets, Ttint implements 12 remote access functions such as Socket5 proxy for router devices, tampering with router firewall and DNS settings, executing remote custom system commands.
The botnet uses the WSS (WebSocket over TLS) protocol for C2 communication to circumvent the typical Mirai traffic detection and provide secure encrypted communication for command and control.
“About the infrastructure, the attacker first used a Google cloud service IP, and then switched to a hosting provider in Hong Kong” reads the analysis published by Netlab.
“Two zero days, 12 remote access functions for the router, encrypted traffic protocol, and infrastructure IP that that moves around. This botnet does not seem to be a very typical player.”
When the botnet was first detected in 2019, experts noticed it was exploiting the Tenda zero-day flaw tracked as CVE-2020-10987.
The vulnerability was detailed in July 2020 by the security researchers Sanjana Sarda.
On August 21, Netlab researchers observed the Ttint botnet exploiting a second zero-day flaw in the family of Tenda routers.
On August 28, 2020, Netlab reported the details of this second 0-day flaw and the PoC to Tenda, but the vendor has not yet responded.
According to the experts, Tenda routers running a firmware version between AC9 to AC18 are vulnerable to the attack.
The report published by Netlab includes Indicators of Compromise (IoCs).
“We recommend that Tenda router users check their firmware and make necessary update.” concludes the report. “We also recommend that our readers monitor and block related IoCs.”
Looking for sophisticated malware in IoT devices
23.9.20 IoT Securelist
One of the motivations for this post is to encourage other researchers who are interested in this topic to join in, to share ideas and knowledge and to help build more capabilities in order to better protect our smart devices.
Research background
Smart watches, smart home devices and even smart cars – as more and more connected devices join the IoT ecosystem, the importance of ensuring their security becomes patently obvious.
It’s widely known that the smart devices which are now inseparable parts of our lives are not very secure against cyberattacks. Malware targeting IoT devices has been around for more than a decade. Hydra, the first known router malware that operated automatically, appeared in 2008 in the form of an open-source tool. Hydra was an open-source prototype of router malware. Soon after Hydra, in-the-wild malware was also found targeting network devices. Since then, different botnet families have emerged and become widespread, including families such as Mirai, Hajime and Gafgyt.
Apart from the malware mentioned above, there are also vulnerabilities found in communication protocols used in IoT devices, such as Zigbee, which can be exploited by an attacker to target a device and to propagate malware to other devices in a network, similar to computer worms.
In this research, we are focusing on hunting low-level sophisticated attacks targeting IoT devices and, in particular, taking a closer look at the firmware of IoT devices to find backdoor implants, modifications to the boot process and other malicious alterations to different parts of the firmware.
Now, let’s talk about the structure of the firmware of an IoT device in order to get a better understanding of the different components.
IoT firmware structure
Regardless of the CPU architecture of an IoT device, the boot process consists of the following stages: the boot loader, the kernel and the file system (shown in the figure below). When an IoT device is switched on, the code from the onboard SoC (System on Chip) ROM transfers control to the bootloader, the bootloader loads the kernel and kernel then mounts the root file system.
The boot loader, the kernel and the file system also comprise the three main components of typical IoT firmware.
IoT boot process
There are a variety of CPU architectures used in IoT devices. Therefore, being able to analyze and understand the different components of firmware requires a good understanding of these architectures and also their instruction set. The most common CPU architectures among IoT devices are:
ARM
MIPS
PowerPC
SPARC
Possible attack scenarios
Understanding the firmware structure enables us to think about how an attacker might take advantage of the various components when deploying a stealth attack that’s difficult to detect.
The bootloader is the first component that takes control of the system. Therefore, targeting the bootloader offers an attacker a perfect opportunity to carry out malicious tasks. It also means that an attack can remain persistent after a reboot.
An attacker can also manipulate the kernel modules. The majority of IoT devices use the Linux kernel. As easy as it is for a developer to customize and choose whatever they need from the Linux kernel, an attacker who manages to access and manipulate the device firmware can also add or edit kernel modules.
Moving on to the file system, there are also a number of common file systems used in IoT devices. These file systems are usually easy to work with. An attacker can extract, decompress and also mount the original file system from the firmware, add malicious modules and compress it again using common utilities. For instance, SquashFS is a compressed file system for Linux that is quite common among IoT manufacturers. It’s very straightforward to mount or uncompress a SquashFS file system using the Linux utilities “squashfs” and “unsquashfs”.
Challenges of this research
Obtaining firmware
There are different ways to obtain firmware. When deciding to investigate, sometimes you want the acquired firmware to belong to the exact same device with the same specifications; and you also want it to be deployed on the device through some specific means. For example, you suspect that the network through which the firmware is updated has been compromised and you consider the possibility of the firmware being manipulated in transition between the vendor’s server and the device, hence you want to investigate the updated firmware to validate its integrity. In another example scenario, you might have bought a device from a third-party vendor and have doubts about the firmware’s authenticity.
There are also a large number of IoT devices where the manufacturers don’t implement any ways to get access to the firmware, not even for an update. The device is released from the manufacturer with firmware for its lifetime.
In such cases the surest way to obtain the exact firmware you are after, is to extract the firmware from the device itself.
The main challenge here is that this process requires a certain domain-specific knowledge and also specialist hardware/software experience of working with embedded systems. This approach also lacks scalability if you want to find sophisticated attacks targeting IoT devices in general.
Among the various ways of obtaining IoT firmware, the easiest way is to download the firmware from the device manufacturer’s website. However, not all manufacturers publish their firmware on their website. In general, a large number of IoT devices can only be updated through the device physical interface or via a specific software application (e.g. mobile app) used to manage the device.
When downloading firmware from a vendor’s website, a common issue is that you might not be able to find older versions of the firmware for your specific device model. Let’s also not forget that in many cases the published firmware binaries are encrypted and can only be decrypted through the older firmware modules installed on the device.
Understanding firmware
According to Wikipedia, “firmware is a specific class of computer software that provides the low-level control for a device’s specific hardware. Firmware can either provide a standardized operating environment for more complex device software (allowing more hardware-independence), or, for less complex devices, act as the device’s complete operating system, performing all control, monitoring and data manipulation functions.”
Even though the main components of firmware are almost always the same, there is no standard architecture for firmware.
The main components of firmware are typically the bootloader, the kernel module and the file system; but there are many other components that can be found in a firmware binary, such as the device tree, the digital certificates, and other device specific resources and components.
Once the firmware binary has been retrieved from the vendor’s website, we can then begin analyzing it and taking it apart. Given the specialized nature of the firmware, its analysis is very challenging and rather involved. To get some more details about these challenges and how to tackle them, refer to the “IoT firmware analysis” section.
Finding suspicious elements in firmware
After the components of the firmware have been extracted, you can start to look for suspicious modules, code snippets or any sort of malicious modifications to the components.
An easy step to start with, is to scan the file system contents against a set of YARA rules which can be based on known IoT malware or heuristic rules. You can also scan the extracted file system contents with an antivirus scanner.
Something else you can do is look for the startup scripts inside the file system. These scripts contain lists of modules that get loaded every time the system boots up. The address to a malicious module might have been inserted in a script like this with malicious intent.
Here the Firmwalker tool can help with scanning an extracted file system for potentially vulnerable files.
Firmwalker capabilities (https://craigsmith.net/firmwalker/)
Another place to investigate is the bootloader component, though this is more challenging.
There are a number of common bootloaders used in IoT devices with U Boot being the most common. U Boot is highly customizable, which makes it very difficult to determine whether the compiled code has been manipulated or not. Finding malicious modifications becomes even more complicated with uncommon or custom bootloaders.
IoT firmware analysis
There are a variety of open-source and closed-source tools that can help with firmware analysis. The best approach is to use a combination of the tools and techniques suggested by experienced firmware analysts.
Let’s begin with Binwalk, the most comprehensive firmware analysis tool. Binwalk scans the firmware binary and looks for known patterns and signatures.
It has a large collection of signatures for various bootloaders and file systems used in IoT devices. It also has signatures for common encryption and compression algorithms along with the respective routines for decompression and decoding.
Binwalk is also capable of extracting the components it finds in the firmware binary.
The following screenshot shows the output of a Binwalk scan on a sample firmware binary:
Binwalk scan output
In this screenshot, Binwalk has found and printed out the header, the bootloader and the Linux kernel as well as the file system. There are also metadata details that have been extracted from the headers and the components themselves, such as the type and size of each component, CRC checksums, important addresses, CPU architecture, image name and so on. Now you can go on and use Binwalk itself to extract the above-mentioned parts, or manually calculate the sizes and extract the parts based on the start offset found by Binwalk.
After extracting the components of the firmware, you can go on and extract, decompress or even mount the file system and start investigating the file system content. You can also look at the bootloader code in a disassembler, or debug it through a debugger.
However, doing firmware analysis is not always that straightforward. Firmware is so varied and diverse that understanding its structure and extracting the components is usually quite complicated.
Let’s take a close look at another sample firmware and try to understand its structure.
1. Binwalk firmware.bin
The Binwalk scan shows nothing in the result. This means that Binwalk could not find any known signatures.
Binwalk scan output
We can see in this case that the simple Binwalk scan was not very helpful. However, be aware that there are other tools and techniques we can use to learn more about the structure of this firmware.
2. File firmware.bin
Let’s next try the Linux file utility on the firmware binary.
File utility output
The file utility shows the file type as Targa image data. By looking at the beginning of the binary file, and doing a Google search on the Targa image data signature, the result is obviously a false positive.
First bytes of the firmware binary
This is because the first bytes of the firmware file, 0x01010000, match the Targa image data signature. See the screenshot above.
3. Binwalk -E firmware.bin
Let’s use another capability of Binwalk and check the entropy of the firmware binary.
Running Binwalk using the “-E” command option gives an entropy diagram for the firmware file and some additional details such as the offset for falling and rising entropy.
Entropy details
Entropy diagram
Entropy figures close to 1 indicate compression, while the lower entropy figures indicate uncompressed and unencrypted areas. As can be seen from the screenshots above, the offset 55296 (0xD800) is the beginning of the high entropy part.
There is also another tool that can be helpful in visualizing the binary. With the help of binvis.io you can see the contents of the firmware file and its visualization in two side-by-side panes. Different parts are shown in different colors based on their entropy. (binvis.io)
Visualization of the firmware created by binvis.io
4. Binwalk -A firmware.bin
Binwalk can also scan the binary file for common executable opcode signatures.
First function prologues found in the file
Last function prologues found in the file
As we can see from the screenshot above, the result of the opcode signature check is actually very helpful! First, we can see that the firmware belongs to an ARM device.
Second, if we consider the offsets of the first and last function prologue signatures, we get an indication that these are the sections of the firmware binary that contain code.
From the screenshot, we can also see that the last function is found at the address 0xD600, which is just 0x200 bytes before the part where the entropy goes up. From this, we can make an educated guess that this offset is likely the end of the code of the bootloader and the beginning of the compressed kernel modules.
5. Hexdump -C
hexdump -C firmware.bin | grep -C 4 -e “^\*$”
Now that we know the rough boundaries of some of the components of the firmware file, we can try to confirm these boundary offsets by looking at the actual contents of the firmware file around these areas.
If we run the firmware file through a hexdump, and look for lines that contain only an asterisk “*”, we can locate the compiler-added padding for each of the firmware components.
Contents of the firmware binary
Contents of other parts of the firmware binary
The output of the Hexdump utility, together with the previous findings, confirm the section of the firmware binary containing ARM code. We previously suspected that this code belongs to the bootloader.
6. Strings –radix=x firmware.bin
Next, let’s extract the ASCII strings from the firmware together with their offsets.
Last ASCII strings found in the firmware binary
Looking at the screenshot above, there are some strings related to the module entry point. These strings can give us a good indication of the nature of the code involved.
We can see some other interesting strings from the beginning of the firmware binary in the screenshot below. For example, the “MctlApplet.cpp” library name can be used to find other binaries or packages from the same developers. Having other firmware images from the same vendor helps to better understand the binary structure.
Another interesting string from the same screenshot is “Not Booting from softloader” which can indicate the process state or perhaps the nature of this module.
Strings containing “Assert()” can suggest different information about the code. Using Asserts is a common practice in firmware development, as it helps the developer to debug and troubleshoot the code during the development and production phase.
First ASCII strings found in the firmware binary
7. IDA -parm firmware.bin
We can see that we have already collected lots of valuable information from this firmware binary that seemed quite incomprehensible at the beginning.
Let’s now use IDA to inspect the code. As this binary is not an ELF file with standard headers that show the ISA, we need to explicitly tell IDA to use the ARM instruction set to disassemble the code.
Disassembly view of part of a function in IDA
The above screenshot from IDA shows how the strings found in the previous analysis steps can be used to help find the call to the entry point of the kernel module.
8. dd
We can now go ahead and extract the part of the firmware binary which our analysis found to be the bootloader module.
9. Qemu
After all the modules have been extracted from the firmware binary – the file system content, the kernel modules and other components – we can then use Qemu to run the binaries, and even emulate the files that were meant for a different architecture from our own machine, and start interacting with them.
Conclusion
The number of IoT devices is getting bigger and bigger every day. From industrial control systems, smart cities and cars to consumer-grade devices such as mobile phones, networking devices, personal assistants, smart watches and a large variety of smart home appliances.
IoT devices are derived from embedded systems that have been around for many years. The manufacture and development of software for embedded devices has always had different priorities from those of general-purpose computer systems due to the different nature of these devices. These priorities have been shaped by the limited and specific functions of the devices themselves, the limited capabilities and capacities of the underlying hardware as well as the inaccessibility of the developed code to subsequent alteration and modifications. However, IoT devices have significant differences to traditional embedded systems. Most IoT devices nowadays run on hardware that have similar capabilities to a general-purpose computer system.
As IoT devices become more prevalent, they are now accessing and controlling many aspects of our lives and day-to-day interactions. IoT devices can now potentially give malicious actors unprecedented opportunities to do harm. This highlights the importance of security in IoT devices and also shows the relevance of research around this topic. The good news is that there are many tools and techniques available to assist current and future research in this field. Acquiring a good understanding of the architecture of IoT devices, learning the language these devices speak and a good dose of determination and perseverance are what it takes to enter this research field.
This post has been written primarily to motivate individuals who want to start diving into IoT security research. You can reach out to us regarding this research at iot_firmware_research@kaspersky.com or via my twitter account, @Noushinshbb.
We’ll be publishing more in the future! Stay tuned!
Mozi Botnet Accounts for Majority of IoT Traffic
18.9.20 BotNet IoT Threatpost
Mozi’s spike comes amid a huge increase in overall IoT botnet activity.
The Mozi botnet, a peer-2-peer (P2P) malware known previously for taking over Netgear, D-Link and Huawei routers, has swollen in size to account for 90 percent of observed traffic flowing to and from all internet of things (IoT) devices, according to researchers.
IBM X-Force noticed Mozi’s spike within it’s telemetry, amid a huge increase in overall IoT botnet activity. Combined IoT attack instances from October through June is 400 percent higher than the combined IoT attack instances for the previous two years.
“Attackers have been leveraging these devices for some time now, most notably via the Mirai botnet,” according to IBM. “Mozi continues to be successful largely through the use of command-injection (CMDi) attacks, which often result from the misconfiguration of IoT devices. The continued growth of IoT usage and poor configuration protocols are the likely culprits behind this jump. This increase may have been fueled further by corporate networks being accessed remotely more often due to COVID-19.”
Mozi first sauntered onto the scene in late 2019 targeting routers and DVRs, and has been analyzed a couple of times by various research teams. It’s essentially a Mirai variant, but also contains snippets from Gafgyt and IoT Reaper – it’s used for DDoS attacks, data exfiltration, spam campaigns and command- or payload-execution.
IBM observed Mozi using CMDi for initial access to a vulnerable device via a “wget” shell command, then altering permissions to allow the threat actor to interact with the affected system. Wget is a command-line utility for downloading files from the web.
“CMDi attacks are extremely popular against IoT devices for several reasons. First, IoT embedded systems commonly contain a web interface and a debugging interface left over from firmware development that can be exploited,” according to the firm’s analysis, published Wednesday. “Second, PHP modules built into IoT web interfaces can be exploited to give malicious actors remote-execution capability. And third, IoT interfaces often are left vulnerable when deployed because administrators fail to harden the interfaces by sanitizing expected remote input. This allows threat actors to input shell commands such as ‘wget.'”
Mozi’s DHT Attack Routine
In Mozi’s case, the wget command downloads and executes a file called “mozi.a” on vulnerable systems, according to IBM. Researchers said that the file executes on a microprocessor. Once the attacker gains full access to the device through the botnet, the firmware level can be changed and additional malware can be downloaded, depending on the goal of any specific attack.
Mozi constantly updates the vulnerabilities that it tries to exploit via CMDi, banking on slow patch implementation, IBM noted. This is an activity that can be easily automated, which accelerates Mozi’s growth. In IBM’s latest analysis, the sample was using exploits for Huawei, Eir, Netgear, GPON Rand D-Link routers; devices using the Realtek SDK; Sepal SPBOARDs; MVPower DVRs; and multiple CCTV vendors.
In addition, it can also brute-force Telnet credentials using a hardcoded list.
Once it cracks a device, the Mozi botnet attempts to bind local UDP port 14737, and it finds and kills processes that use ports 1536 and 5888. Its code contains hardcoded distributed hash table (DHT) public nodes, which are then used to join the botnet’s P2P network. DHT is a distributed system that provides a lookup service allowing P2P nodes to find and communicate with each other.
Click to enlarge. Source: IBM.
“The Mozi botnet uses a customized DHT protocol to develop its P2P network,” according to IBM.
In order for a new Mozi node to join the DHT network, the malware generates an ID for the newly infected device. The “ID is 20 bytes and consists of the prefix 888888 embedded in the sample or the prefix specified by the config file [hp], plus a randomly generated string.”
This node will then send an initial HTTP request to http[:]//ia[.]51[.]la to register itself, and it also sends a DHT “find_node” query to eight hardcoded DHT public nodes, which is used to find the contact information for a known Mozi node, and then connected to it, thus joining the botnet.
The Mozi botnet infrastructure appears primarily sourced in China, accounting for 84 percent of observed infrastructure, IBM said.
Rise of the P2P Machines
P2P botnets are increasingly common. Just this year, the FritzFrog botnet hopped onto the scene, actively breaching SSH servers since January. FritzFrog propagates as a worm, brute-forcing credentials at entities like governmental offices, educational institutions, medical centers, banks and telecom companies.
Since the beginning of the year, a P2P coin-mining botnet known as DDG has seen a flurry of activity, releasing 16 different updates by April. Most notably, its operators have adopted a proprietary P2P mechanism that has turned the DDG into a highly sophisticated, “seemingly unstoppable” threat, according to researchers.
And late last year, a P2P botnet named Roboto was found targeting a remote code-execution vulnerability in Linux Webmin servers.
The P2P architecture is popular with cybercriminals; it offers greater resiliency than other types of botnets because control is decentralized and spread among all nodes. As such, there’s no single point-of-failure and no command-and-control server (C2).
As for Mozi, IBM warned that the IoT landscape will continue to be a rich hunting ground for botherders.
“As newer botnet groups, such as Mozi, ramp up operations and overall IoT activity surges, organizations using IoT devices need to be cognizant of the evolving threat,” the firm concluded. “IBM is increasingly seeing enterprise IoT devices under fire from attackers. Command injection remains the primary infection vector of choice for threat actors, reiterating how important it is to change default device settings and use effective penetration testing to find and fix gaps in the armor.”
Threatpost has reached out for more information on Mozi’s share of IoT traffic.
Bluetooth Spoofing Bug Affects Billions of IoT Devices
17.9.20 IoT Threatpost
The ‘BLESA’ flaw affects the reconnection process that occurs when a device moves back into range after losing or dropping its pairing, Purdue researchers said.
A team of academic researchers have discovered a Bluetooth Low Energy (BLE) vulnerability that allows spoofing attacks that could affect the way humans and machines carry out tasks. It potentially impacts billions of Internet of Things (IoT) devices, researchers said, and remains unpatched in Android devices.
The BLE Spoofing Attacks (BLESA) flaw arises from authentication issues in the process of device reconnection — an area often overlooked by security experts. Reconnections occur after two devices are connected and then one moves out of range (or disconnects) and then connects again, according to a paper published recently by researchers at Purdue University. Reconnections are common in industrial IoT environments, for example, where sensors may periodically connect to a server to transmit telemetry data, for instance, before disconnecting and going into monitoring mode.
A successful BLESA attack allows bad actors to connect with a device (by getting around reconnection authentication requirements) and send spoofed data to it. In the case of IoT devices, those malicious packets can convince machines to carry out different or new behavior. For humans, attackers could feed a device deceptive information.
The vulnerability is particularly significant due to the ubiquity of the BLE protocol which, because of its energy efficiency and simplicity of use, is used by billions of devices to pair and connect, said the team—comprised of researchers Jianliang Wu, Yuhong, Vireshwar, Dave (Jing) Tian, Antonio Bianchi, Mathias Payer and Dongyan Xu.
Threatpost Webinar Promo Bug Bounty
Click to register.
“To ease its adoption, BLE requires limited or no user interaction to establish a connection between two devices,” researchers wrote. “Unfortunately, this simplicity is the root cause of several security issues.”
The paper describes the ease with which an attacker can launch a BLESA attack: A threat actor, upon discovering the server to which a BLE-enabled device is connected, also pairs with it to it to obtain its attributes. This is easy because the BLE protocol is designed to allow any device to connect with another BLE device to get this info, researchers wrote.
BLE further facilitates access for an attack because its advertising packets are always transmitted in plain-text, so an attacker can easily impersonate the benign server by advertising the same packets and cloning its MAC address, they said.
In an attack’s next phase, the threat actor starts broadcasting spoofed advertising packets to ensure that whenever the client attempts to start a new session with the previously-paired server, it receives the spoofed advertising packets, researchers explained.
“At this point, the adversary is ready to launch BLESA against the client,” they wrote.
The paper focuses on two critical weaknesses in the BLE spec that allow for BLESA attacks. One of the issues occurs if the authentication during the device reconnection is marked as optional instead of mandatory. “The client and the server may choose to disable [authentication] for a specific attribute,” researchers wrote. “Therefore, in the case of the basic attribute, the confidentiality, integrity and authenticity goals of the attribute-access request and response can be violated.”
The other weakness arises because the specification provides two possible authentication procedures when the client reconnects with the server after pairing, meaning that authentication can potentially be circumvented, said researchers, who describe both types of attacks in detail in the paper.
Attackers can use BLESA on BLE implementations on Linux, Android and iOS platforms, researchers said. Specifically, Linux-based BlueZ IoT devices, Android-based Fluoride and the iOS BLE stack are all vulnerable, while Windows implementations of BLE remain unaffected, they said.
Researchers contacted Apple, Google and the BlueZ team about the vulnerabilities, with Apple assigning CVE-2020-9770 to the flaw and fixing it in June, they noted. However, “the Android BLE implementation in our tested device (i.e., Google Pixel XL running Android 10) is still vulnerable,” they said.
The BlueZ development team said it would replace the code that opens its devices to BLESA attacks with code that uses proper BLE reconnection procedures that aren’t susceptible to attacks, according to researchers.
This is the second major bug found in Bluetooth this month. Last week, the “BLURtooth” flaw was announced, which allows attackers within wireless range to bypass authentication keys and snoop on devices in man-in-the-middle attacks.
Vulnerability in Thales Product Could Expose Millions of IoT Devices to Attacks
20.8.20 IoT Securityweek
Security researchers at IBM have discovered a potentially serious vulnerability in a communications module made by Thales for IoT devices. Millions of devices could be impacted, but the vendor released a patch six months ago.
The flaw, tracked as CVE-2020-15858, was discovered in September 2019 and it was patched in February 2020. It was initially identified in Thales’ Cinterion EHS8 M2M module, which enables secure 3G and 4G communications in IoT devices, but it was later also found to impact ten other modules in the same product line.
The impacted modules are present in millions of IoT products, including ones used in the medical, telecom, energy and automotive industries.Cinterion vulnerability
The vulnerability is related to the fact that the product runs Java code that can include information such as encryption keys, passwords and certificates. An attacker who has access to the targeted IoT device can exploit the vulnerability to bypass security mechanisms and gain access to this information, which can then be used to take control of a device or access the network housing it. In some cases, remote exploitation is possible via the communication capabilities provided by the module itself, IBM said.
The impact of an attack depends on what the targeted IoT device is used for. An attacker could, for example, target medical devices and manipulate readings or even tamper with the treatment delivered by the device (e.g. insulin pumps).
Another theoretical attack scenario described by IBM targets the energy and utilities sector. An attacker could hack smart meters and manipulate readings, which can lead to smaller or larger electricity bills.
“With access to a large group of these devices through a control network, a malicious actor could also shut down meters for an entire city, causing wide-reaching blackouts that require individual repair visits, or, even worse, damage to the grid itself,” IBM said in a blog post.
While a patch has been available for months, the company pointed out that it may not be an easy task to roll it out to some products, such as medical devices or industrial control systems (ICS). The patch can be delivered either via an update conducted over a USB connection or over the air, depending on the device’s capabilities.
High-Wattage IoT Botnets Can Manipulate Energy Market: Researchers
5.8.2020 IoT Securityweek
A team of researchers from the Georgia Institute of Technology has demonstrated how, in theory, a malicious actor could manipulate the energy market using a botnet powered by high-wattage IoT devices.
Most botnets are powered by devices such as routers, cameras and DVRs. However, researchers from Princeton University warned a few years ago that threat actors looking to cause disruption to an energy grid could create a botnet of high-wattage devices, such as internet-connected ovens, air conditioners, and water and space heaters, which use 1-5 kilowatts of power.
The botnet described by the Princeton researchers, named BlackIoT (MadIoT), focused on causing disruptions, including local outages and large-scale blackouts, by simultaneously switching on and off the compromised high-wattage devices. However, the attack might not always be successful in practice, especially when the power grid protection mechanisms respond effectively to the shock caused by the botnet.IoT botnets can manipulate the energy market
In the new attack method described by Georgia Tech researchers, which they have dubbed “IoT Skimmer,” the attacker uses a botnet of high-wattage devices to manipulate the electric market, either for financial profit or financial damage.
Most power markets include a day-ahead market, where participants purchase and sell electric energy with prices determined on the previous day, and a real-time market, which balances the difference between the actual demand for electricity and the day-ahead commitments.
The Georgia Tech researchers say a threat actor could manipulate the electricity market the same way financial markets can be manipulated: generate an event that causes prices to drop or rise, and buy when the price is low and sell when the price is high.
The researchers cited a report from the Federal Energy Regulatory Commission (FERC) in the United States that said there had been 16 potential market manipulation cases in 2018, with 14 of them closed without any action taken due to no evidence of manipulation being found. They also pointed to a recent attack on a British electricity market administrator.
The researchers believe that an attacker who has control of a high-wattage IoT botnet can slightly change demand in the power grid, thus impacting market prices.
One potential attacker could be a market player, which launches an attack in an effort to manipulate prices for their own profit. Another potential attacker is a state-sponsored actor, whose goal is to manipulate prices simply to cause the targeted country or targeted market players to suffer financial losses.
A nation-state attacker can obtain information on how market players are bidding — this data is publicly available — and influences real-time market prices for maximum economic loss.
The Georgia Tech researchers believe the gain of the attack is directly proportional to the number of bots within the botnet. The attack can be pulled off with as few as 50,000 bots with considerable financial impact.
The notorious IoT botnet Mirai was powered by 600,000 devices, but those were mostly low-wattage devices. However, the researchers told SecurityWeek in an interview ahead of a talk at the Black Hat cybersecurity conference, an attacker with large resources could create a botnet of high-wattage devices from scratch, by searching for vulnerabilities in the targeted IoT devices and then exploiting them in an effort to ensnare them in a botnet.
They pointed out that there are currently an estimated 30 million smart thermostats, which would give malicious actors plenty of potential targets, and the researchers anticipate that at one point in the future we will see such high-wattage botnets.
For an attack to be successful in the long term, it would have to be stealthy, and for that, the extra power consumption generated by the botnet would have to be within certain limits to avoid being detected by both the energy market and consumers whose devices are abused.
The difference between the predicted electricity load and the actual load is called the load forecasting error. If the changes generated by the attack are within the boundaries of this load forecasting error, the attack is unlikely to be detected by market operators and players.
As for avoiding detection by consumers, if the botnet turns on its devices for 100 days per year (or 8 days per month) for an average of 3 hours, the increase seen on the consumer’s bill would be of up to 7 percent, which the researchers believe is unlikely to be noticed by many users. However, this would still be enough for a significant attack.
In order to make the operation even stealthier, the threat actor could launch attacks on even fewer days, and they could turn on the compromised devices at strategic times of day (e.g. smart fridges in the middle of the day; EV chargers, ovens and dryers early in the morning). If the campaign is conducted by a market player, they could target competitors and even launch attacks that would affect them to some extent in order to throw off suspicion from themselves.
Since it would be illegal to create such a botnet and conduct real-world tests, the researchers used available data from the New York and California markets to calculate the efficiency of an attack.
For example, if a market player launches an attack, they could make an additional daily profit of $100,000 if they use a botnet of 150,000 bots — the size of the profit is directly proportional with the size of the botnet.
A state-sponsored threat actor could cause economic loss of $2 million per day with a botnet of 150,000 devices, while keeping the load profile within limits, the researchers said.
Based on their calculations, a market player could make an additional yearly profit of $24 million, while a nation-state group could cause economic damage of up to $350 million per year.
As for countermeasures against such attacks, the researchers propose the development of a real-time monitoring database that stores information on a small fraction of high-wattage IoT devices. This database would make it possible to detect potential attacks by looking for suspicious activity.
They also believe that market data should not be shared publicly — it should only be available to market players, and even they should only receive the data with a delay, not in real time.
IoT security: In 2020, action needs to match awareness
26.5.2020 Net-Security IoT
As the power of IoT devices increases, security has failed to follow suit. This is a direct result of the drive to the bottom for price of network enabling all devices.
IoT security 2020
But small steps can greatly increase the overall security of IoT.
A better IoT security story has to be one of the most urgent priorities in all of technology. That’s because IoT is one of the industry’s most compelling opportunities and squandering it due to security challenges would be a massive blunder – especially since those challenges are surmountable.
There’s a good reason IoT has become an ever-present buzzword: it has the potential to change many aspects of life and is brimming with opportunities for exciting innovation. This is especially true on the industrial side, where the technology is fueling advances in digital factories, power management, supply-chain optimization, the connected car, and robotics.
Indeed, many companies are moving beyond piloting and prototyping IoT projects to real-world applications. Many are incorporating machine learning and other artificial intelligence (AI) technologies to gain insights from the colossal amounts of data all these sensors and other devices produce.
Yet lack of security continues to threaten the progress of this game-changing technology.
Various research has shown that security is the number one concern for enterprise IoT customers and that they would move faster on IoT programs if their concerns were allayed.
More than three years have passed since the IoT security threat crashed into public view with the massive denial-of-service attack on a major DNS provider which caused outages of some of the web’s most popular sites. The attack was instigated by a botnet of around 145,000 IoT devices – mostly webcams and DVRs – compromised by Mirai malware. In the intervening years, IoT botnets have grown in size and so has the number of attacks fueled by them. But IoT has other troubling security issues, as demonstrated by the rash of IoT locks with glaring security holes in the past year.
The incident should have served as a rallying point for concerted industry action to address IoT security, but little progress has been made.
What’s taking so long?
A primary IoT selling point – the advent of inexpensive sensors and devices – is also a thorn in IoT security’s side. Many manufacturers are pumping out these things without properly securing them for the internet. Many companies, simply looking for the cheapest deals to keep IoT project costs down, buy them without amply considering their security readiness.
Too many devices are being shipped to customers with no password or a standard, hard-coded default password that can easily be discovered and exploited. (The start of the now 400,000 strong Mirai BotNet was a single list of 60 usernames and passwords.)
Beyond passwords, many devices simply are not designed with security in mind at both the software and hardware levels. For example, configuration bit streams should be encrypted and protected, but often aren’t.
Another issue is a lack of software updates. When an attack or vulnerability is discovered, updates are not always rolled out in a timely manner – and sometimes not at all.
While IoT security guidelines exist – for example, the Secure By Design code issued by the U.K. in 2018 – they’re seldom enforced. Contrast that with the payment card industry (PCI), which polices itself with rigid security standards and levies penalties on member companies that fail to follow them.
The IoT segment needs to get serious
Awareness of the IoT security issue has reached government awareness. In the U.S., a Senate bill introduced in 2019 and similar legislation in the House would require the National Institute of Standards and Technology (NIST) and the Office of Management and Budget (OMB) to take steps to increase the security of IoT devices.
In California, a law took effect on Jan. 1, 2020 requiring that all connected devices sold in the state have “a reasonable security feature or features” and banning shared default passwords.
While this government action is a positive sign, industry typically moves faster than government and IoT manufacturers themselves should take greater responsibility for improved security.
A good start might be an IoT security equivalent to the Energy Star certification for energy efficiency of appliances, electronics, HVAC systems, etc. Energy Star is actually a U.S.-government-backed program, but IoT is moving so fast that I think the industry could get this done faster than waiting for the public sector.
It is up to the industry to once and for all deal with the security challenge or face the prospect that IoT will never achieve its enormous promise and all of us will be paying the price for years from vulnerable devices in the field.
Number of active IoT devices expected to reach 24.1 billion in 2030
22.5.2020 Net-security IoT
At the end of 2019 there were 7.6 billion active IoT devices, a figure which will grow to 24.1 billion in 2030, a CAGR of 11%, according to a research published by Transforma Insights.
active IoT devices
Short range technologies, such as Wi-Fi, Bluetooth and Zigbee, will dominate connections, accounting for 72% in 2030, largely unchanged compared to the 74% it accounts for today.
Public networks growth
Public networks, which are dominated by cellular networks, will grow from 1.2 billion connections to 4.7 billion in 2030, growing market share from 16% to 20%. Private networks account for the balance of connections, 10% in 2019 and 8% in 2030.
In revenue terms, the total IoT market in 2019 was worth $465 billion, a figure which will rise to $1.5 trillion in 2030. Services, including connectivity, will account for 66% of spend, with the remainder accounted for by hardware, in the form of active IoT devices, modules and gateways.
The consumer sector to dominate in terms of connected devices and finance
The consumer sector will dominate in terms of connected devices, accounting for 65% of all connections, up from 62% in 2019. Of the enterprise segment in 2030, 34% of devices will be accounted for by ‘cross-vertical’ use cases such as generic track-and-trace, office equipment and fleet vehicles, 31% by utilities, most prominently smart meters, 5% by transport and logistics, 4% by government, 4% for agriculture, and 3% each for financial services and retail/wholesale.
The single biggest use case is Consumer Internet & Media devices, accounting for 1/3 of all devices in 2030. The next largest is Smart Grid, including smart meters, representing 14% of connections. Connected Vehicles, dominated by connected cars, is the third biggest category, representing 7% of the global installed base.
In financial terms, the biggest vertical sector is consumer, generating $652 billion in revenue, or 43% of the total market value. Cross-vertical applications account for 24%. The remaining 33% is sector-specific applications across sectors such as energy, transport, retail and healthcare.
“One of the benefits of building a highly granular set of forecasts is that we can uncover striking trends, such as the huge $500 billion revenue opportunity associated with a diverse range of niche vertical-specific applications,” said Transforma Insights Founding Partner Matt Hatton.
Geographically, China, North America and Europe dominate, accounting for 26%, 24% and 23% respectively of the total value of the IoT market in 2030.
Both Mirai and Hoaxcalls IoT botnets target Symantec Web Gateways
19.5.2020 Securityaffairs BotNet IoT
Experts from Palo Alto Networks discovered that the Mirai and Hoaxcalls botnets are targeting a vulnerability in legacy Symantec Web Gateways.
Palo Alto Networks Unit 42 researchers observed both the Mirai and Hoaxcalls botnets using an exploit for a post-authentication Remote Code Execution vulnerability in legacy Symantec Web Gateways 5.0.2.8.
“I recently came across new Hoaxcalls and Mirai botnet campaigns targeting a post-authentication Remote Code Execution vulnerability in Symantec Secure Web Gateway 5.0.2.8, which is a product that became end-of-life (EOL) in 2015 and end-of-support-life (EOSL) in 2019.” reads the analysis published by Palo Alto Networks. “There is no evidence to support any other firmware versions are vulnerable at this point in time and these findings have been shared with Symantec.”
Symantec pointed out that the flaw has been fixed in Symantec Web Gateway 5.2.8 and that it doesn’t affect Secure Web Gateway solutions, such as ProxySG and Web Security Services.
Experts first observed the exploitation of the flaw in the wild on April 24, 2020, as part of an evolution of the Hoaxcalls botnet that was first discovered early of April. The botnet borrows the code from Tsunami and Gafgyt botnets, it expanded the list of targeted devices and added new distributed denial of service (DDoS) capabilities.
Operators behind the Hoaxcalls botnet started using the exploit a few days after the publication of the vulnerability details.
In the first week of May, the experts also spotted a Mirai variant using the same exploit, but this samples don’t contain any DDoS capabilities.
“they serve the purpose of propagation using credential brute force and exploitation of the Symantec Secure Web Gateway RCE vulnerability This blog post provides any noteworthy technical details on these two campaigns.” continues the report.
According to Unit 42, both the Mirai and Hoaxcalls botnets used payloads designed to discover and infect vulnerable devices. In the case of Mirai, the bot is able to propagate via either credential brute-forcing or exploitation of the Symantec Web Gateways exploit.
Experts note that the exploit is only effective for authenticated sessions and the affected devices are End of Life (EOL) from 2012.
“In the case of both campaigns, one can assume that their success with this exploit is limited by the post-authentication nature of the Symantec Secure Web Gateway RCE vulnerability.” concludes Palo Alto Networks.
The report published by Palo Alto Networks contains technical details about the botnet, including the Indicators of Compromise (IoCs)
Microsoft launches IoT-focused bounty program with $100K awards
9.5.2020 Bleepingcomputer IoT
Microsoft announced today the launch of a new IoT-focused research program with awards of up to $100,000 for vulnerabilities found by security researchers in the Azure Sphere IoT security solution.
The new research challenge, dubbed Azure Sphere Security Research Challenge, is an expansion to the Azure Security Lab bounty program announced by Microsoft last year at Black Hat 2019.
Azure Security Lab's first phase was announced on August 5, 2019, and it included a sandbox-like environment that allowed security researchers to test Azure's security, featured an increase in Azure bug bounty rewards, as well as new scenario-based challenge rewards.
An archive of previous Azure Security Lab research challenge scenarios is available here.
We are excited to announce a new IoT-focused research program, the Azure Sphere Security Research Challenge, with awards up to $100,000 USD! Deadline to apply is May 15, check out the blog post for more information: https://t.co/YGqcSqh6fy
— Security Response (@msftsecresponse) May 5, 2020
With the Azure Sphere Security Research Challenge announcement, Redmond added to the incentives, support resources. and coordination framework to make Coordinated Vulnerability Disclosure (CVD) easier for researchers and to encourage further Azure Sphere research.
Microsoft will award bounties of up to $100,000 during this new research challenge to researchers who can demonstrate their ability to execute code on the Microsoft Pluton security subsystem or the Azure Sphere application platform's Secure World.
Participants enrolled in Microsoft's Azure Sphere Security Research Challenge will also have access to resources that will support them in their research, including:
• New bounties for Azure Sphere, up to $100K
• Access to Azure Sphere development kit
• Access to Microsoft products and services for research purposes
• Azure Sphere product documentation
• Direct communication channels with the Microsoft team
"This research challenge is focused on the Azure Sphere OS," Microsoft explained. "Vulnerabilities found outside the research challenge scope, including the Cloud portion, may be eligible for the public Azure Bounty Program awards.
Also, "[p]hysical attacks are out of scope for this research challenge and the public Azure Bounty Program."
To apply for this three-month application-only security research challenge, you will have to submit your application here before May 15, 2020, with the challenge to run between June 1, 2020, through August 31, 2020.