Contents
1️⃣ Security in the IoT Era
As the performance of low-power MCUs improves and sensor capabilities advance, we're seeing a trend towards intelligent systems that analyze users' biometric data and learn IoT device usage patterns. One essential feature of these devices is network communication.
Familiar household appliances are becoming IoT-enabled, creating network connection points. Medical devices and industrial control systems (PLC, HMI, SCADA) are also incorporating IoT features for control and management. Recent analysis of IoT devices has provided an opportunity to examine external connection points and consider potential vulnerabilities.
Given the nature of IoT devices, network transit is inevitable, with destinations typically being users' smartphones or IoT Cloud servers. This blog post aims to share experiences from projects, exploring how attackers might analyze these communication processes for malicious purposes.
2️⃣ Objectives of IoT Device Network Analysis
The goals of analyzing network traffic from IoT devices are:
Understanding the internal data format of packets during communication
JSON transmission
Custom formats using HEX for socket communication
Cases where plain text can be obtained due to lack of encryption
Analyzing whether external third-party communications can manipulate the device arbitrarily
Confirming the absence of proper authentication processes
Identifying cases where authentication processes can be bypassed
3️⃣ Types of Network Communication Between IoT Devices
Devices typically connect to smartphones via Wi-Fi or Bluetooth, with occasional LTE module use. We'll focus on Wi-Fi for network traffic analysis. There are three main types of Wi-Fi connections for IoT devices:
Direct 1:1 connection between device and smartphone (device operating in AP mode)
In this simplest case, when powered on, the device functions like a router through its Wi-Fi module without any Bluetooth operation. The smartphone connects to the device's Wi-Fi, communicating via an internal network. This setup has a simple connection structure, making network analysis relatively straightforward when using an analysis-purposed smartphone.
Device connects to nearby Wi-Fi, communicating on the same network (STA mode)
The device connects to the same nearby Wi-Fi as the smartphone, executing application control commands through the Wi-Fi's internal network communication. While this method involves an additional router, analysis is still possible using a rooted smartphone for tcpdump and proxy functionalities, similar to the first scenario.
Device synchronizes with smartphone via IoT Cloud (STA mode)
This method is increasingly common today. The IoT device exchanges Wi-Fi connection information with the smartphone via Bluetooth. Once connected to Wi-Fi, the IoT device communicates with the IoT Cloud. Subsequently, after a settings synchronization process between the smartphone and IoT Cloud, the smartphone can control the IoT device. This scenario requires network packet capture and routing-based proxy processes at the Wi-Fi router to which the device connects. Caution is necessary when analyzing from the smartphone, as it could potentially lead to attacks on the IoT Cloud server due to the synchronization process.
4️⃣ Applicable Security Measures for IoT Device Networks
This section assumes that an attacker can connect to Wi-Fi through methods such as Dictionary Attack, Brute Force Attack, or public Wi-Fi connections. The network security techniques that can be applied to IoT devices are as follows:
4.1. Direct Communication Encryption Between IoT Devices and Smartphones
There have been cases where public key encryption processes were coded and applied to AP mode for communication between IoT devices and smartphones. By applying public key encryption to the values used in communication, it's possible to prevent attacks that expose or replay critical information or control commands.
4.2. SSL Certificate Application
Similar to web servers, one of the most universally applicable defense techniques is the application of SSL certificates. This allows for the encryption of communication channels, preventing the exposure of important information or control commands.
4.3. HPKP(HTTP Public Key Pinning)
Even when certificate security is applied to IoT devices, it's possible to view encrypted information transmitted over the network through private certificates using proxy functions.
When using proxy tools, private Certificate Authorities (CAs) are employed. If there's no verification of these private CAs on the smartphone or IoT Cloud connected to the IoT device, the encrypted communication content could be exposed through proxy tools. To solve this problem, a technology called HPKP(HTTP Public Key Pinning) is used.
The HPKP technology allows the server to determine whether the requesting CA is an authorized institution, permitting connections only from certificates that exist in registered CAs.
5️⃣ Network Analysis by Scenario
5.1. One-to-One Communication Analysis between IoT Devices and Smartphones
This scenario applies when a device operates in AP mode, connecting directly to a smartphone (first case in section 3), or in STA mode with a router in between (second case in section 3).
In this situation, packet capture and man-in-the-middle attacks are relatively straightforward. If an analysis smartphone is available, it can attempt to connect to the IoT device and capture packets using TCP Dump. Additionally, the smartphone can utilize proxy functionality to attempt man-in-the-middle attacks.
The image below shows packets captured via Tcpdump on a rooted analysis smartphone, depicting communication between the application and the IoT device.
As seen in the figure, devices communicate using plaintext JSON format, which could be exploited for attacks.
Furthermore, in STA mode with a router present (second case in section 3), if packet collection on the smartphone is impossible (e.g., due to root detection), the router can be replaced with a smartphone to create a network configuration as shown in the image below for packet collection and man-in-the-middle attack attempts.
5.2. Analysis of Encrypted Communication between IoT Devices and Applications
This scenario applies to both AP mode direct connections and STA mode connections through a router. If public key encryption, as mentioned in section 4.1, is implemented in code for application communication, decrypting all keys can be a cumbersome process.
The image below shows packets with public key encryption applied during communication.
The packet contents are encrypted and unreadable. In such cases, using Frida Hook to intercept data before encryption in the application, and writing code to modify this information, can be an effective approach. The specifics of writing Frida Hook scripts are beyond the scope of this article.
Below is the code used for the hook.
// hook.js
const S = "java.lang.String";
const B = "java.nio.ByteBuffer";
const I = "int";
const requestInfo = "";
const DASHCAM_RESPONSE_LISTENER = 'e1.b';
const DASHCAM_API = '-';
const SYSTEM_SETTING_API = 'c1.p'; // 'd.b.a.a.SystemSettingApi' // d.b.a.a.m
const JSON_OBJECT = 'org.json.JSONObject';
const BASE_API = 'c1.b';
const BASE_BO = '-';
const DASHCAM_CONSTANTS_ENUM = '-';
setImmediate(function () {
Java.perform(function () {
// SystemSettingApi 클래스 가져오기
var BaseApi = Java.use(BASE_API); // d.b.a.a.m
// A Method 후킹 (AE_SET_SETTING(2206))
BaseApi.a.overload(JSON_OBJECT, BASE_BO, DASHCAM_CONSTANTS_ENUM, DASHCAM_RESPONSE_LISTENER).implementation = function (jSONObject, baseBO, dashcamConstantsEnum, dashcamResponseListener) {
// console.log("a method called with arguments:");
console.log("Response: " + jSONObject.toString());
// console.log("BaseBO: " + baseBO.toString());
// console.log("DashcamConstantsEnum: " + dashcamConstantsEnum.toString());
console.log("DashcamResponseListener: " + dashcamResponseListener.toString());
var result = this.a(jSONObject, baseBO, dashcamConstantsEnum, dashcamResponseListener);
// console.log("Result: " + result);
// console.log("BaseBO (after method call): " + baseBO.toString());
return result;
};
var DashcamApi = Java.use(DASHCAM_API);
DashcamApi.g0.overload('java.lang.String', DASHCAM_RESPONSE_LISTENER).implementation = function (str, dashcamResponseListener) {
console.log("Request: " + str);
try {
var jsonObject = JSON.parse(str);
console.log("Parsed JSON Object: " + JSON.stringify(jsonObject, null, 2));
} catch (e) {
console.log("Failed to parse JSON string: " + e);
}
var result = this.g0(str, dashcamResponseListener);
console.log("Result: " + result);
return result;
};
DashcamApi.h0.overload('java.lang.String', DASHCAM_RESPONSE_LISTENER).implementation = function (str, dashcamResponseListener) {
try {
var jsonObject = JSON.parse(str);
console.log("Request: " + JSON.stringify(jsonObject, null, 2));
} catch (e) {
console.log("Failed to parse JSON string: " + e);
}
var result = this.h0(str, dashcamResponseListener);
return result;
};
});
});#hook.py
import frida
import sys
Hook_package = "-"
Hook_package2 = "-"
def on_message(message, data):
print("{} -> {}".format(message, data))
jscode = open("hook.js", encoding='UTF8').read()
try:
device = frida.get_usb_device(timeout=10)
# pid = device.spawn([Hook_package])
# print("App is starting.. pid:{}".format(pid))
# process = device.attach(pid)
# device.resume(pid)
pid = device.get_process(Hook_package2).pid
process = device.attach(pid)
print("Attach.. pid:{}".format(pid))
script = process.create_script(jscode)
script.on('message', on_message)
print("[-] Running FR1DA!")
script.load()
sys.stdin.read()
except Exception as e:
print(e)5.3. Analysis of IoT Devices Operating as APs with Limited Connections
This scenario involves IoT devices designed to allow Wi-Fi connection to only one device after verifying the application connection via Bluetooth. In such cases, using an analysis smartphone and laptop can be an effective method.
Modern smartphones support dual-band, allowing one band to operate in AP mode via hotspot for connecting an analysis laptop, while the other band is used for Wi-Fi connection, functioning like a single router.
As shown in the diagram below, the 5GHz band operates in AP mode while the 2.4GHz connects to the IoT device's Wi-Fi. The AP band IP and external Wi-Fi operate as a virtual NAT, ultimately reaching the IoT device through the smartphone's IP. Connecting external devices to the smartphone AP allows bypassing the single-connection limitation.
In this scenario, the analysis smartphone first connects to the IoT device via Bluetooth for application connection and then connects to the device's Wi-Fi. Subsequently, it activates the hotspot on the unused band (either 2.4GHz or 5GHz), allowing multiple analysis devices to communicate with the IoT device.
5.4. Analysis of STA Mode IoT Devices Communicating with IoT Cloud via Nearby Wi-Fi
When using an IoT Cloud setup, most communications are likely secured with SSL certificates via HTTPS connections, making analysis more challenging. While user-accessible proxy functionality would be ideal, most IoT devices lack this feature. One approach is to use two routers capable of utilizing iptables.
The basic concept involves Router 1 connected to an external network router via NAT, and Router 2 connected to the analysis PC.
Typically, communication flows as follows: [IoT Device → Router 1 → Router 2 → IoT Cloud]
When the IoT device sends packets to the IoT Cloud, Router 1 encapsulates them for Router 2's network range via NAT, and Router 2 then encapsulates them for the external AR router's IP range.
If the IoT device communicates with the IoT Cloud on port 443, applying the following iptables command to Router 2 will forcibly redirect packets entering and exiting through Router 1 to the PC IP connected to Router 2.
After this configuration, the packet flow between the IoT device and IoT Cloud becomes: [IoT Device → Router 1 → Analysis PC → IoT Cloud]
This configuration is possible due to the reverse tree structure of network packet flow.
Typically, network iptables follow this flow.
Packets entering through PREROUTING pass through the INPUT filter to reach the application. The application's response then passes through the OUTPUT filter to POSTROUTING before exiting externally.
With the iptables routing command applied, the packet flow becomes:
The PREROUTING and OUTPUT filters now pass through the target Proxy. In this configured environment, the following sequence occurs:
When a packet from the IoT device reaches Router 2 via Router 1, iptables redirects it to the analysis PC IP.
The packet reaches the analysis PC from Router 2.
The packet arriving at the analysis PC is encapsulated with the analysis PC as the source and the IoT Cloud as the destination.
The packet can then exit to the external network where the IoT Cloud resides, passing through Router 2.
Response packets follow the reverse path back to the IoT device.
With this setup and proxy configuration on the analysis PC, man-in-the-middle attacks become possible once a session is established. However, devices with HPKP security require additional steps to obtain certificates.
HPKP implementation rejects private CAs, preventing session connections and resulting in RST packets. To establish a normal session, the device's firmware must be analyzed to obtain the certificate used for IoT Cloud communication and apply it to the analysis PC.
Below is a packet capture of a man-in-the-middle attack attempt via proxy on an IoT device with HPKP technology communicating with an IoT Cloud, without the proper communication certificate:
As shown in the image, attempting to connect using a private CA results in an " Unknown CA" error and RST packets.
This process demonstrates how HPKP (HTTP Public Key Pinning) technology protects against external man-in-the-middle attacks by rejecting private CA connections.
In such cases, extracting the certificate used for IoT Cloud communication from the device's firmware and applying it to the proxy tool is necessary for a successful man-in-the-middle attack.
TLS encrypts certificate transmission through key exchange algorithms, making it impossible to obtain certificates through network packet capture alone.
In [IoT Device ↔ Smartphone] environments, application analysis remains an option if firmware analysis fails. However, in [IoT Device ↔ IoT Cloud : IoT Cloud ↔ Smartphone] environments, Cloud analysis is not possible, leaving firmware analysis as the only viable approach.
Consequently, without obtaining the certificate, man-in-the-middle attacks are impossible in environments where this security technique is implemented.
6️⃣ Insights Gained from Analysis In This Article
We explored:
Methods using an analysis smartphone for one-to-one communication
Techniques employing Frida Hook when encryption is applied to communication
Approaches utilizing mobile hotspots for scenarios with limited Wi-Fi connections
Man-in-the-middle attack methods using two routers with shell access
Through these methods, a hacker could potentially execute the following attacks:
Initiating device resets or abnormal operations (DoS) by transmitting control commands
Performing command injection through chaining of improperly handled system functions
Obtaining sensitive information not publicly accessible to regular users
These analytical techniques allowed us to examine information used in communications across various IoT devices. In situations lacking encryption, we could induce device malfunctions through malicious command transmissions. Notably, some devices remained controllable via plaintext even when encryption was implemented.
This project provided an opportunity to study diverse network analysis techniques, revealing methods that could be exploited for attacks and reinforcing the critical importance of network security. Given that all control in IoT is executed through external communications, this experience emphasized the necessity of network security and motivated further study in this area.
This article has highlighted that many IoT devices have more vulnerable network security than anticipated. Moving forward, we aim to conduct more in-depth studies on other attack techniques and share these findings on our blog.
