MQTT server security test

The Internet of Things market is growing at an explosive rate. As the scale of devices continues to grow and business logic becomes increasingly complex, the security of iot platform infrastructure becomes increasingly important. Whether the specific implementation of the protocol is complete and whether the parsing process of specific messages is secure has become a top priority.

This requires thorough testing of the protocol’s complex standards and specified codes of conduct. At the same time, considering various interference and attacks that may exist in actual use, the test process also needs to cover various non-standard exception packets to analyze the fault tolerance and processing capability of the target platform.

Fuzzy testing is a very effective testing method. This article will use EMQ X as an example to show how to use fuzz testing tools to find possible flaws and vulnerabilities in the IMPLEMENTATION of the MQTT server /MQTT client protocol.

What is fuzziness test

Fuzz testing (Fuzzing) is a software testing technique. The idea is to input random data generated automatically or semi-automatically into a program and monitor for program exceptions, such as crashes and assertion failures, to detect possible program errors, such as memory leaks. Fuzzy testing is often used to detect security vulnerabilities in software or computer systems.

Fuzz tests can be used as white box, gray box, or black box tests. Usually used for black box testing, the return rate is higher.

Source: zh.wikipedia.org/wiki/ Fuzziness test

The preparatory work

Test tool and object selection

For this article we chose Defensics as the tool for fuzz testing. Defensics is a black box fuzziness test tool developed by Synopsys, offering a suite of fuzziness tests for a wide range of file formats, network protocols, and interfaces. It uses a large number of automatically generated MQTT packets to test brokers/clients against the MQTT V3.1 protocol standard, helping developers and testers improve software security.

A test suite for MQTT V5 is not yet available

We will take the open source MQTT messaging server – EMQ X as an example to test the security of its protocol implementation. EMQ X is a large-scale cloud native distributed Internet of Things MQTT message server, which is open source and scalable by EMQ Cloud Technology. It can efficiently and reliably connect massive Internet of Things devices, process message and event flow data with high performance in real time, and help build key business Internet of Things platform and application.

Test Environment Preparation

This test was carried out in Arch Linux environment with rolling updates to the latest version using EMQX 5.0-be.2-8BE2AAF7.

In addition, before proceeding to the next step, you need to download the Defensics installation package, the.install test suite installation file, and the DEFENSIC executable file from Synopsys for use by the FlexNet license server to verify the license status.

Deployment License Server (FlexNet)

Synopsys Defensics Using FlexNet management license, deploy FlexNet Server in the network environment where Defensics Fuzzy test is executed. To manage the license certificate (license. Lic file) obtained from Synopsys.

You can use Systemd User Unit to start the FlexNet Daemon locally. The license.lic certificate file and DEFENSIC (Vendor Daemon) executable file are in the same directory. FlexNet will search Vendor Daemon executables from $PATH for authentication.

Of course, Defensics can also be deployed on a dedicated certificate server to provide certificate authentication services to more users in cases where more testers are required to use it. Refer to the Defensics and FlexNet Publisher documentation for additional information and parameters.

Then run the systemctl –user enable –now lmgrd.service command to start the Vendor Daemon provided by the Synopsys authentication server. Defensics can then start testing with a license.

Other configuration

On Linux, display problems and fuzzy fonts may occur. For details, see Java Runtime Environment Fonts – ArchWiki.

Install Defensics and test suite

Run the. Sh installation program as the root user to install the software. During the installation, you are advised to select /usr/local/bin/defensics for generating the startup script.

If all goes well, the verified License status is displayed in File -> License Manager after Defensics is started. After that, you can install and load the test suite.

Defensics test

Basic configuration

In the base configuration, set the IP address and port number of the MQTT Server, as well as the MQTT Client configuration for testing.

Where MQTT defaults to port 1883 (port 8883 when TLS/SSL is enabled).

If the MQTT Server has client authentication or message subject permissions enabled, more detailed configuration is required for the two clients under test. Defensics also provides advanced Payload ambiguity tests and TLS/SSL connection based tests. However, this test only involves fuzzy tests related to the MQTT V3.1.1 protocol standard, so no configuration is required.

After the corresponding field values are configured, Defensics will connect to the MQTT Server with the specified Client ID, user name and password, and PUBLISH and SUBSCRIBE messages with the specified MQTT topic.

For more advanced and complex tests, you can use the Edit Sequence feature to Edit the corresponding configuration file to change the behavior of a connection or disconnection, such as auto-subscribe after a connection, publish messages immediately after a connection, and so on.

Operability test

Run Interoperability tests in your configuration to verify that different messages can be sent and received. The test groups that can be executed when the MQTT Server is properly connected are highlighted in green.

Advanced configuration

In this section, users are allowed to configure specific test case execution, but generally the default configuration is sufficient.

This includes control over test case execution, such as timeout threshold, number of repetitions, number of attempts, and so on.

In addition, you can perform network configurations based on actual conditions to obtain test results in different network scenarios. You can also choose to automatically configure the MQTT Server based on the target IP address.

In addition, possible detected anomalies can be evaluated according to the vulnerability classification method provided by CVSS (Common Vulnerability Scoring System).

Instrumentation configuration

Instrumentation is the observation and control of the system under test during the test with the objective of detecting any failures caused by the test. Meters can also be used to restart or otherwise control the system under test while running tests.

Most test suites have default detection enabled, requiring no additional configuration. And the nature of this default configuration varies from test suite to test suite.

Select test cases

Defensics provides a total of over 1 million test cases for comprehensive fuzzy testing of target systems to the MQTT V3.1.1 protocol standard. At the same time, users can select and combine test cases based on these subdivisions to focus on analysis and problem solving.

This time, we selected some use cases for testing, including three groups of connect-disconnect publish-qos-0 subscribed-qos-0, and selected all abnormal message cases for testing.

In the test for exception messages, you can also select the number and degree of exception behavior for different types of data. Such as text, binary data, numbers, characters and so on; You can also configure byte limits for overflow exceptions to test malformed packets with value overflows.

Perform the test

By selecting the type of test case and the amount of exception data, you can begin testing. The test took about six minutes, with about 98% passing and about 1% (2,779 use cases) unknown.

Analysis of preservation results

Firstly, we select one of the abnormal messages with unknown results for analysis.

As you can see, Defensics tries to test with abnormal data that does not conform to the protocol specification during fuzzy testing in order to assess the robustness of the object under test. For example, the part highlighted in red indicates the utF-8 string length of the subscribed topic in the SUBSCRIBE message of MQTT V3.1.1 protocol. That is, the next data of length 0x009A (154 bytes) is a UTF-8 string to subscribe to the topic filter. However, the actual length of the topic filter is 18 bytes and the value should be 0x0012, which is different from the actual length.

In this case, the server must close the network connection that transmits the protocol violation control message, according to the mandatory specification of the protocol. **

However, it is not specified whether a message indicating the cause of the error must be returned. Therefore, EMQ X only performs internal error processing and directly discards abnormal packets. No information is sent back to the sender, so Defensics marks this result as unknown.

But according to the agreement, this result still meets the requirements.

According to statistics, 2779 test cases with unknown results had different types of errors as shown in the following table:

In the face of these abnormal packets, EMQ X directly discards them and does not send back any indication of the error information.

For some error types, trying to guess the boundary of the critical information may even result in larger and more unacceptable errors because the information at the error point is more critical. For example, the string length indicator value error dissected above. If you make a guess about the topic filter and its length, you might get the wrong topic filter, causing the client to get an unexpected topic subscription. It is even possible that the topic filter length is correct and the value of the topic filter is lost and corrupted in transit.

Such logic errors are more difficult to detect and troubleshoot during system operation, and the consequences are more difficult to accept. Therefore, it is better to discard abnormal packets directly.

For other types of errors, because the error point is too obvious, it is more likely to be due to data loss during transmission, or exceptions caused by incorrect data flow boundaries. Therefore, it is more likely to think that these data are not MQTT messages and are discarded, so as not to consume additional resources to deal with these exceptions.

conclusion

In this paper, we summarize the fuzzy testing process of EMQ X using Defensics fuzzy tester and MQTT V3.1 protocol test suite, and select some use cases for testing and analysis of the results.

It can be seen that EMQ X is very complete in the implementation of the protocol. Even if a large number of error packets are used for testing, EMQ X will not lose the ability to provide services, which can ensure the security of the protocol and provide security guarantee for the stable operation of the actual project.

EMQ is dedicated to providing highly available, highly reliable MQTT messaging server and other data infrastructure software for the Internet of Things. Last year, we also entered into a partnership with Synopsys, which will have overall responsibility for safety and quality risk management throughout the entire EMQ product lifecycle. We hope that users can build more stable and reliable iot platforms and applications through EMQ products.

EMQ X open source projects are also welcome your participation at any time, welcome to the us through GitHub:https://github.com/emqx/emqx submit PR or Issue.

Copyright: EMQ

Original link: www.emqx.com/zh/blog/mqt…