General principles and methods for security testing of ubiquitous Internet of Things terminal equipment

0 21
First, overviewThe ubiquitous Internet of Things is a通俗 expression of widely exi...

First, overview

The ubiquitous Internet of Things is a通俗 expression of widely existing Internet of Things. It is a layered architecture system, composed of terminal layer, network layer, platform layer, and business layer from bottom to top. The terminal layer, as the 'fingers' of the Internet of Things, is mainly composed of business terminals with various perception capabilities and is the carrier of information recognition and the source of information collection in the Internet of Things.

The terminal layer can be further divided into collection components, intelligent business terminals, local communication networks, and Internet of Things agents. At the intelligent business terminal layer, it includes basic functional architecture such as chips, operating systems, and intelligent components, and implements unified interfaces for business terminal manufacturers in the form of APP.

General principles and methods for security testing of ubiquitous Internet of Things terminal equipment

Local communication networks mainly include wired communication networks represented by Ethernet, passive optical network, and 485 bus, and short-distance wireless communication networks represented by WiFi, Zigbee, infrared, and Bluetooth.

The Internet of Things agent is the difference between the ubiquitous Internet of Things and the traditional Internet of Things. It mainly completes various communication protocol adaptation, data edge intelligent processing, terminal secure access, and data model unification. By introducing the Internet of Things agent and the Internet of Things management platform, the isolated structure of business systems has been broken.

Second, general detection principles and content

2.1Access security

It should be able to prove its network identity to the access network, at least supporting one of the following identity authentication mechanisms:

(1) Authentication based on network identity identifier;

(2) Authentication based on MAC address;

(3) Authentication based on communication protocol;

(4) Authentication based on communication port;

(5) Authentication based on symmetric encryption mechanism;

(6) Authentication based on asymmetric encryption mechanism.

The role of access authentication is to ensure that only legitimate terminals/authenticated users can access the Internet of Things system. It requires the access authentication protocol adopted by the Internet of Things agent, or at least it can prove its network identity to the Internet of Things agent.

Local networks mostly use wireless communication. In open environments, wireless communication lacks physical protection. As long as within the network transmission coverage range, theoretically, anyone may access the network or eavesdrop on the data transmitted over the network. Therefore, network access authentication and data transmission confidentiality are the most basic two security requirements for the Internet of Things perception network.

Local perception network access mainly refers to the access to the local perception layer gateway, and the access authentication protocol used is usually directly related to the communication method adopted by the perception network. For example: if the Internet of Things network adopts WIFI communication, the access authentication protocol generally adopts WPA/WPA2 protocol; if the Internet of Things network adopts LoRaWAN communication, it generally uses OTAA or ABP protocol. Generally, each mainstream communication method has a corresponding network access authentication protocol.

Taking MQTT protocol as an example, a certain type of collection terminal communicates with the property management platform using MQTT protocol + JSON without unnecessary authentication methods. After analyzing the relevant communication specifications, it is possible to arbitrarily forge subscription/publishing information.

Unauthorised connection detection results---

msf5 auxiliary(scanner/mqtt/connect) > exploit

[*] 192.168.*.*:1883      - 192.168.*.*:1883 - Testing without credentials

[+] 192.168.*.*:1883      - Does not require authentication

[*] 192.168.*.*:1883      - Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

Through MQTT.fx, it is possible to construct publish-subscribe information for data exchange. In security detection, this item does not meet the identification requirements based on network identity (1).

2.2Device Security

2.2.1Operating System Security

Device security is mainly for the security of the Internet of Things terminal itself. In actual scenarios, Internet of Things terminals are divided into 'terminals with operating systems' and 'terminals without operating systems'. The article focuses on terminals with embedded operating systems, as shown below----

sy****@S********A:~$ uname -a

Linux S********A 3.10.108 #9 SMP Wed Apr 22 14:23:55 CST 2020 armv7l armv7l armv7l GNU/Linux

sy****@S********A:~$ cat /proc/version

Linux version 3.10.108 (root@ubuntu-work) (gcc version 4.6.3 20120201 (prerelease) (crosstool-NG linaro-1.13.1-2012.02-20120222 - Linaro GCC 2012.02) ) #9 SMP Wed Apr 22 14:23:55 CST 2020

sy****@S********A:~$ cat /proc/cpuinfo

processor : 0

model name : ARMv7 Processor rev 5 (v7l)

BogoMIPS  : 48.00

Features  : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32

CPU implementer  : 0x41

CPU architecture: 7

CPU variant  : 0x0

CPU part  : 0xc07

CPU revision  : 5

 

processor : 1

model name : ARMv7 Processor rev 5 (v7l)

BogoMIPS  : 48.00

Features  : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32

CPU implementer  : 0x41

CPU architecture: 7

CPU variant  : 0x0

CPU part  : 0xc07

CPU revision  : 5

If a deeper test is required, you can use host vulnerability scanning and other methods to scan the terminal, especially focusing on privilege escalation vulnerabilities.

The main detection content of the operating system includes--

a. User identification and authentication. The operating system user of the terminal should have a unique identifier, and user authentication should be performed when the user logs in, and the user password should meet certain complexity requirements;

b. Access control, 'The system should be able to control the access permissions of operating system users' and 'Operating system users should only be granted the minimum permissions required to complete the task'. During testing, different role users (such as operators, auditors) can log in to the operating system to check whether the permissions allocated to various users by the operating system are reasonable (such as operators should not have the right to delete audit records, auditors should not have the right to perform business operations), and at the same time, examine whether the permission allocation conforms to the principle of least privilege;

c. The terminal should provide security measures to control its remote configuration. Many IoT terminals use private protocols or WEB methods for remote configuration. When testing, it is necessary to examine whether there is a security protection mechanism (such as identity authentication, encryption authentication, etc.) in the configuration method.

d. Log audit, 'The system should be able to generate audit records for operating system events, and the audit records should include information such as date, time, operation user, operation type, etc.', 'The audit function of the operating system should be able to be enabled and disabled by the security auditor', 'The system should provide the function to view the audit records of the operating system'.

e. Configuration check, check the configuration information of the operating system.

The results of checking the embedded operating system using the configuration check tool lynis---

S************A:~/SecTool/lynis$ https://www.freebuf.com/articles/endpoint/lynis audit system

[ Lynis 3.0.0 ]

[+] Initializing program

------------------------------------

###################################################################

#                                                                #

#   Non-privileged scan mode (non-root)                                     #

#                                                                 #

###################################################################

Description:

--------------

* Some tests will be skipped (no root privileges)

* Some tests may produce different results or no output

 

- OS detection...                                           [Completed]

- Check file...                                          [Completed]

 

---------------------------------------------------

Program version:           3.0.0

Operating system:          Linux

Operating system name:     Ubuntu

Operating system version:  16.04

Kernel version:            3.10.108

Hardware platform:         armv7l

Hostname:                  **********

---------------------------------------------------

Profiles:                  /home/sysadm/SecTool/lynis/default.prf

Log file:                  /home/sysadm/lynis.log

Report file:               /home/sysadm/lynis-report.dat

Report version:            1.0

Plugin directory:          https://www.freebuf.com/articles/endpoint/plugins

---------------------------------------------------

Auditor:                   [Not Specified]

Language:                  en

Test category:               all

Test group:                all

---------------------------------------------------

- Program update status...                                  [ Skipped ]

 

[1] System Tools

------------------------------------

- Scanning available tools...

- Checking system binaries...

[2] Plugins (phase 1)

------------------------------------

Note: plugins have more extensive tests and may take several minutes to complete

 

- Plugins allowed                                           [ None ]

[3] Boot and Services

------------------------------------

- Service Manager                                           [ Configuration ]

- Boot loader                                             [ Not found ]

- Check running services (systemctl)                            [完成 ]

Result: Completed 14 running services

- Check allowed services at boot (systemctl)                     [完成 ]

Result: Completed 15 allowed services

- Check startup files (permissions)[ OK ]

[4] Kernel

------------------------------------

- Checking default run level                                [ RUNLEVEL 5 ]

- Checking kernel version and release                         [完成 ]

- Checking kernel type                                      [完成 ]

- Checking loaded kernel modules                            [ Completed ]

Completed 36 active modules

- Checking Linux kernel configuration file                  [ Completed ]

grep: /etc/kernel-img.conf: No such file or directory

- Checking for available kernel update                      [ Unknown ]

- Checking core dumps configuration

- configuration in systemd conf files                      [ DEFAULT ]

- configuration in etc/profile                            [ DEFAULT ]

- 'hard' configuration in security/limits.conf               [ DEFAULT ]

- 'soft' configuration in security/limits.conf                [ DEFAULT ]

- Checking setuid core dumps configuration                [ Disabled ]

- Check if reboot is needed                                 [ Unknown ]

[5] Memory and Processes

------------------------------------

- Checking /proc/meminfo                                    [ 完成 ]

- Searching for dead/zombie processes                        [ 未发现 ]

- Searching for IO waiting processes                           [ 未发现 ]

- Search prelink tooling                                      [ Not found ]

Append full system detection chart----

1604298567_5f9fa747568a6471a30cc.png!small

Figure 1 Full System Security Detection of the Operating System

2.2.2Device body security

a. When adopting the card insertion method for network identity authentication, measures should be taken to prevent the card from being pulled out or replaced;

b. Storage devices that store encrypted data or keys should have a strong disassembly self-destruct mechanism and have a clear warning mark to prevent misoperation;

1604298663_5f9fa7a7006660cafcde1.png!small

Figure 2 Warning of a certain type of encryption device anti-theft

c. Failure protection, 'The Internet of Things terminal should be able to self-detect defined device failures and generate alarms to ensure that the functional parts of the device that are not affected by the failure are normal'. The key point of this item is the failure alarm function and availability. In the test, sensor failure, network failure, and other simulations can be performed to see if the perception terminal can generate an alarm, and to examine whether other functions are affected. For control devices, it is required that communication failure should not affect the control function.

2.2.3Container security

a. Encryption detection of secret information in the container environment, check the encryption algorithm of the secret information stored in the container environment;

b. Container image security vulnerability detection, perform security scanning on the container environment;

c. Container account security detection, check if there are any problems with the container account security policy;

d Container image consistency detection, check if the container image signature is consistent with the trusted source.

Containers running in terminals can be exported as files for convenient analysis:

1604298696_5f9fa7c8a04561af6bdbf.png!small

Figure 3 Container Export

There are many tools for container analysis, here we take the open-source tool dockerscan as an example to illustrate:

info collection of image basic information---

[root@localhost tmp]# dockerscan image info basicimg.tar

[ * ] Starting analyzing docker image...

[ * ] Selected image: 'basicimg.tar'

[ * ] Analysis finished. Results:

[ * ] - Host name = 3827efb8b9b3

[ * ] - Entry point:

[ * ]   > /usr/local/monitor/appctl-daemon

[ * ] - Created date = 2010-10-23T17:03:37.95190981Z

[ * ] - Docker version = 18.09.6

[ * ] - Environment:

[ * ]   > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Analyze running permissions:

[root@localhost tmp]# dockerscan image analyze basicimg.tar

[ * ] Starting the analysis of docker image...

[ * ] Selected image: 'basicimg.tar'

[ * ] Analysis finished. Results:

[ * ] - Running user = root

Extract image file:

[root@localhost tmp]# dockerscan image extract /tmp/basicimg.tar /basic

[ * ] Starting the extraction of docker image...

[ * ] Selected image: 'basicimg.tar'

[ * ] Image content extracted

The directory structure of the image file is shown as follows---

1604298831_5f9fa84f200a4d6c0f3bb.png!small


Figure 4 Directory of container image files

View the password file---

[root@localhost /]# cat /basic/etc/passwd

root:x:0:0:root:/root:/bin/ash

bin:x:1:1:bin:/bin:/sbin/nologin

daemon:x:2:2:daemon:/sbin:/sbin/nologin

adm:x:3:4:adm:/var/adm:/sbin/nologin

lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin

sync:x:5:0:sync:/sbin:/bin/sync

shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown

halt:x:7:0:halt:/sbin:/sbin/halt

mail:x:8:12:mail:/var/spool/mail:/sbin/nologin

news:x:9:13:news:/usr/lib/news:/sbin/nologin

uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin

operator:x:11:0:operator:/root:/bin/sh

man:x:13:15:man:/usr/man:/sbin/nologin

[root@localhost /]# cat /basic/etc/shadow

You can also import the container image into a virtual machine environment and further analyze within the container environment---

S***********A:~$ docker ps -a

CONTAINER ID        IMAGE                   COMMAND                  CREATED                 STATUS                         PORTS                     NAMES

E********d        basic_img-arm2:latest   "/usr/local/monitor/…"   9 days ago          Exited (0) 9 days ago                           romantic_swanson

E********4        basic_img-arm2:latest   "/usr/local/monitor/…"   2 months ago

Loading container

S**********A:~$ docker start e**********4

E***********4

Enter container operation:

S**********A:~$ docker exec -it e***********4  bin/bash

E************4

Bin/bash cannot log in, you can try bin/sh. You can conduct more in-depth tests on databases, applications, and more within containers.

2.2.4Firmware Security

Firmware (firmware) is a program written into flash memory or EROM, EPROM (erasable programmable read-only memory) of special application integrated circuits (ASIC) or programmable logic devices (PLD), which is commonly understood as 'fixed software'.

a. Firmware upgrades via the public internet (FTP, HTTP) should be prohibited, and unnecessary ports should be closed;

b. Support for remote secure upgrade and update should be provided;

c. Measures should be taken to prohibit direct external reading of memory, preventing bypassing the control device controller (or processor) to directly read the contents of the chip;

d. The process of reading Flash in the MCU (or processor) Bootloader should be controlled to prevent data from being output to the host side (such as PC) through the communication bus;

e. The interfaces used for hardware development debugging should be disabled, including but not limited to JTAG/SWD and UART interfaces, etc.

For firmware detection, it should first be checked whether the terminal circuit exposes a debugging interface, as the existence of a debugging interface may lead to the risk of firmware information being exported.

Under the condition of obtaining the firmware file (usually provided by the manufacturer), detection can be carried out from the following aspects (part of it)----

Serial number

Detection items


1

File hashes

2

CPU architecture

3

Operating system

4

File system

5

Firmware format

6

Risk of user password information leakage

7

Risk of certificate file and key leakage

8

Software component identification

9

Malware detection

10

Integer overflow defect detection

11

Security mitigation mechanism detection

12

Debug information leakage

There are many firmware detection platforms on the public network, but to avoid the suspicion of advertising, they will not be listed one by one.

2.3Application security

2.3.1 APPSecurity

a. The Internet of Things terminal application software (APP) product should rename various elements in the code, such as variable, function, and class names, to meaningless names to achieve obfuscation purposes;

b. Strengthen the Internet of Things terminal application software (APP) product to effectively prevent the cracking, piracy, repackaging, injection, decompilation, etc. of mobile applications, ensuring the security and stability of the program;

c. The Internet of Things terminal application software (APP) should adopt an authentication signature mechanism;

d. The Internet of Things terminal application software (APP) should support password protection to unlock the locked state, such as passwords, patterns, biometric recognition, and various forms of passwords;

e. The Internet of Things terminal application software (APP) should provide authorized access capabilities for file-type user data, and access should be allowed only after the user confirms when third-party applications access protected user data. File-type user data includes images, videos, audio, and documents, etc.;

f. Any unauthorized entity should not be able to recover the real content of the user's private data from the encrypted storage area of the Internet of Things terminal application software (APP);

g. The Internet of Things terminal application software (APP) should provide a complete data deletion function to ensure that the deleted user data cannot be restored;

2.3.2 WEBApplication security

a. Malicious code prevention: Block common malicious attack behaviors at the code level to prevent illegal data submission; for example: SQL injection;

b. Two-factor authentication: Implement user identity verification using two or more combinations of authentication technologies for the same user;

c. Password complexity: Force users to change the initial password during the first login; the password length must be at least 8 characters and composed of numbers, uppercase and lowercase letters, and special characters;

d. Session expiration and timeout: restrictions on browser Cookie expiration, no action expiration, forced expiration, maintaining session, etc.

e. Security audit function:

Firstly, audit coverage should be extended to each user, and important user behaviors and important security events should be audited, such as: login, logout, add, delete, modify, or overwrite, etc.;

Secondly, audit records should include the date and time of the event, user, event type, whether the event was successful, and other information related to auditing.

2.3.3 WEBRequirements for security risk detection

WEB detection generally can be carried out by WEB leak scanning, commonly used WEB leak scanning has AWVS, NESSUS, etc.

Content of security risk

Risk description

Cross-Site Scripting (XSS)

Malicious attackers insert malicious html code into web pages, when users browse the page, the embedded html code will be executed, thus achieving the special purposes of malicious users; (phishing, stealing cookies, manipulating the victim's browser, worm attack)

SQL injection vulnerability

User input data is used to construct SQL query statements without verification, querying sensitive content in the database, bypassing authentication to add, delete, modify data, and denial of service.

XML injection

If there is no escaping when querying or modifying, directly inputting or outputting data will lead to XML injection vulnerabilities. Attackers can modify the XML data format, add new XML nodes, and affect the data processing process.

Cross-Site Request Forgery (CSRF)

Force the victim's browser to send a request to a vulnerable web application, finally achieving the operation behavior required by the attacker. Malicious requests will carry the browser's Cookie. The attacked web application trusts the browser's Cookie.

Any file download

Download any file on the server, such as script code, service and system configuration files, etc.; the obtained code can be further code audited to obtain more exploitable vulnerabilities

File upload

When a web application handles user-uploaded files, it does not judge whether the file extension is within the allowed range, or whether the content of the file is legally checked, and then stores the file on the server, even uploads a trojan script to the web server, directly controlling the web server. (Unrestricted file extensions, unchecked file content, virus files)

Remote command execution

Remote code execution can be performed directly using administrative privileges to execute malicious commands;

Leakage of sensitive information

Leakage of sensitive information

Permission control

A normal user A can usually only perform add, delete, modify, and query operations on some of their own information. However, due to the programmer's momentary oversight, there was no judgment made when performing add, delete, modify, and query operations on information, whether the information to be operated on belongs to the corresponding user, which can lead to user A being able to operate other people's information.

Decrypted login request

It may steal user login information that is sent without encryption, such as usernames and passwords

The verification code mechanism has not been set

Malicious attackers can use brute force methods to guess account numbers and passwords

For comprehensive detection of APPs, it is recommended to use the open-source platform MobSF, which supports iOS and Android applications. Some screenshots of the detection results are as follows---

1604298798_5f9fa82ee7587a0105bb0.png!small

Figure 5 APP detection results

2.3.4Database Security

a. Users registered in the database management system should be identified. User identification information is public information, generally realized by username and user ID. For management convenience, users can be grouped and aliases can also be used. Regardless of the username, user ID, user group, or user alias, the uniqueness principle of identification should be followed;

b. Use identity authentication for users logging into the database. By verifying the 'authentication information' provided by the user, it is proven that the user indeed has the claimed identity, and these 'authentication information' must be confidential and not easily forged;

c. It should be defined by the database sublanguage and stored together with the data in the data dictionary. Any operation on any SQL object should have explicit permission authorization, and the permission should change with the operation and object, and the security system should be able to judge this permission authorization;

d. It should be represented in the form of an access control table or access matrix and implemented through the execution of the corresponding access control program. Whenever an SQL statement is executed or an access requirement arises, the corresponding access control program is called to control the access requirement;

e. It should be restricted that a user with certain permissions should not grant these permissions to other users. When a user is granted certain permissions and also has the power to grant these permissions to other users, the user has the right to spread these authorizations. In order to enhance the security of the database system, certain restrictions need to be placed on the spread of authorization.

In the actual detection process, it was found that in some terminal applications using containerization, lightweight data storage business data is stored using SQLite, and the database connection is not authenticated, which poses a risk of database leakage----

S**********A:~$ docker exec -it e********4  /bin/sh

/ # find -name *.db

https://www.freebuf.com/articles/endpoint/usr/local/…/db/f********1.db

https://www.freebuf.com/articles/endpoint/usr/local/…/db/T********5.db

https://www.freebuf.com/articles/endpoint/usr/local/…/db/r********5.db

Based on the characteristics of SQLite, a db file is a database in itself, which can directly export a file connection to the database for operations such as addition, deletion, modification, and query, without any access control measures.

1604298905_5f9fa899edecb10b88bf5.png!small

Figure 6 Part of the exported data table

2.4Data security

2.4.1Data availability

To ensure the availability of terminal data, terminal equipment must meet the following requirements:

It should be able to store the configuration data information of the terminal.

It should support the classification management and storage of real-time collected data, with a storage time of not less than three months.

During network disconnection, it should be able to cache the business data of all connected business terminals.

After the network connection to the IoT management platform is disconnected and reconnected, it should be able to support the IoT management platform to obtain a certain amount of historical data (the time can be configured).

Management and control interaction messages reported to the IoT management platform should be identified using timestamps.

For collection terminals, data temporary storage function should be designed to prevent temporary data storage during power failure or network disconnection, and the data can be automatically uploaded during recovery. This type of detection mainly relies on manual detection, and a simulated/test environment can be established for testing.

2.4.2 Data integrity

To ensure the integrity of terminal data, terminal equipment must meet the following requirements:

It should use verification technology or cryptography technology to ensure the integrity of important data during storage.

It should integrate hardware cipher modules or software cipher modules to achieve authentication and the confidentiality and integrity of data transmission between the secure access gateway, using cryptography algorithms recognized by the national cryptography authority department, and providing digital certificate or key management services through a unified cryptography infrastructure (device).

It should have a mechanism for checking the integrity of transmitted data, which can use technologies such as checksums, message digests, and digital signatures to protect the integrity of important data such as privacy data and business data.

There is no general tool for this type of detection, and it is generally analyzed through manual packet capture.

2.4.3 Data confidentiality

To ensure the integrity of terminal data, terminal equipment must meet the following requirements:

Communication data between IoT terminals should be encrypted and transmitted using encryption algorithms recognized by the national cryptography department.

It is advisable to encrypt the user passwords and other critical data stored locally.

Encryption technology should be used to protect the time series in data information.

The encryption protection should be based on a unified password technology facility, which can be realized by means of secure chips, software, or cipher modules.

你可能想看:
最后修改时间:
admin
上一篇 2025年03月29日 07:39
下一篇 2025年03月29日 08:01

评论已关闭