The Internet of Things (IOT) refers to real-time collection of any information sensors, radio frequency identification technology, global positioning system, infrared sensors, laser scanners and other devices and technologies that require monitoring, connection, and interaction The object or process of the collection of various required information such as sound, light, heat, electricity, mechanics, chemistry, biology, location, etc., through various possible network access, to realize the ubiquitous connection of objects and objects, objects and people , To realize the intelligent perception, recognition and management of objects and processes.
There are also some information on the Internet about the methods of IoT security testing, but there are not many that feel useful. There are still many things to learn about IoT. It is certainly not the content of this article. This article briefly summarizes how the IoT performs security testing based on the personal knowledge part and experience.
As a security personnel, you need to fully understand the test target before you can think about the possible problems of the target. It is also essentially starting from the collection of information.
First of all, you need to be clear about the architecture of the target of the current test, here is the classification summarized by the predecessors
Actuator: Control things through physical processes, such as air conditioning units, door locks, curtains
Gateway: used to collect sensor information and control center
Sensor: used to detect the environment, such as light, motion, temperature, humidity, water/electricity
Cloud: Web interface or API hosting cloud web applications for data collection and analysis of large data sets. Generally speaking, it is used to share information with other parties
Mobile (app): An application on the device that is mostly used by mobile devices to control the IoT environment on the mobile phone for interaction
IoT attack points and test ideas
Based on the above, I think the attack surface that can be tested for security has the following parts:
There are many protocols currently used in IoT. This article lists the more common ones I have encountered, including HTTP, TLS/SSL, S7Comm-plus, websocket, MQTT
The HTTP protocol is probably one of the protocols most familiar to security personnel. In the IoT scenario, it is simply divided into two situations, with web applications and without web applications.
First, analyze the scenarios with web applications. Common IoT devices include routing devices (TP-Link, D-Link, etc.), video surveillance (Hikvision, various DVRs, etc.), and access control and attendance systems (Linear eMerge E3- Series), Smart Gateway (GPON Home Gateway), etc.
In fact, there is no need to say more about this. It is basically a regular web penetration. Common problems include default passwords, weak passwords, ultra vires, and RCE.
Analyzing scenarios without web applications, there are too many such devices. Such as printers, smart ovens and rice cookers, smart coffee machines, smart voice assistants, etc. Most of the functions of this type of equipment are actually done using other protocols, but there are always some functions that require the HTTP protocol. For example, I have a smart electric oven at home, which can be issued through a voice assistant (turn on and off and set the oven temperature and time, etc.). You need to scan the QR code on the top of the product to bind, similar to the picture below
The QR code actually parses out to be a URL like http://target.com/xx/?sid=xxx
After testing, sid is the oven number, which can be traversed and modified, and the oven can also be unbound. However, the one in my home is more troublesome to use. The binding process requires entering the nearby WIFI password to connect the oven to the Internet, so it does not achieve the purpose of directly binding and then operating any other oven.
The above is actually biased towards web security testing, but there are also some IoT devices that can provide a special environment, LAN. For example, for a smart speaker, through the capture of software such as wireshark, it can be found that the function of music ordering is using HTTP requests. Then there are three testable scenarios at this point. One is a man-in-the-middle attack. In an insecure network environment, By replacing the request through the middleman, the speaker can play the specified song. For example, no matter what song the user clicks, the last one is “Today is a Good Day”, which may cause mental pollution to the user and eventually lead to returns and complaints. Certain hazards and impacts; the other is that if certain specific operations are implemented through HTTP requests, such as the coffee making function of a smart coffee machine (of course, most coffee machines do not use HTTP, here is just an example) through a After the HTTP request is completed, you can continue to obtain new coffee by replaying the attack after capturing the data packet; finally, to give an example, the smart access control system, if the HTTP protocol is used to upload the user card information to the server, The internal network can capture these data through sniffing and other methods, causing the problem of sensitive information leakage.
To briefly summarize this paragraph, to conduct a security test on a device without a web application, it is necessary to find the HTTP request of the device as much as possible, and on the basis of the request, try man-in-the-middle attacks, replay attacks, and sensitive data acquisition. (In addition, you can also test according to web penetration methods, such as permission bypass, SQL injection, etc. After all, there are too many IoT environments. I just cited three attack points that I think are more common.)
Although the encrypted traffic can be captured by packet capture tools, it is generally impossible to obtain effective information. Therefore, for devices using the TLS protocol, the traffic needs to be decrypted first. Regarding the decryption method, one is to decrypt through the loopholes in the protocol itself. However, I don’t have much research on this one, and I don’t go into it in depth. The other is to analyze the device firmware to obtain the decryption method. This one involves reverse engineering and binary, and it cannot be done too deeply. Of course, after the traffic is decrypted, the test method can refer to the HTTP protocol part written above.
I don’t know much, but seem to use a lot, you can refer to another article
The place where websocket is most used is still instant messaging, which is usually used in industrial Internet after all, such as equipment that needs to monitor certain information in real time.
Generally can be seen by capturing packets
The test method is not limited. As far as I have tested, the main problem is that there is no authentication. In many cases, the interface is directly requested and the server receives and executes normally. This is still very dangerous. However, most of the use of websocket is still used For real-time data transmission, but through the unauthenticated interface, in addition to performing certain operations beyond our authority, it is actually easy to cause a large amount of sensitive information to leak. Therefore, for websocket, test interface authentication and whether there is information leakage.
MQTT is a machine-to-machine (M2M) protocol, which is widely used in IoT. It was invented by IBM in 1999 to create a protocol for minimum battery consumption and minimum bandwidth for connecting petroleum pipelines via satellite connections. Because of its very low energy consumption, it is widely adopted by the IoT ecosystem. At present, almost all IoT cloud platforms support sending and receiving data through MQTT and several different IoT smart devices.
The test of this protocol is actually thanks to the previous work experience in a certain car company, because Headunit will use more MQTT protocols, and in fact, the application scenarios of MQTT in IoT devices are very wide.
Temperature and humidity sensor
Blood pressure measuring instrument
First understand the protocol, MQTT based on the TCP protocol default port 1883, the main functions are two, publish (Publish) and subscribe (Subscribe).
Regarding the attack surface of MQTT, I think MITM, password issues, and permissions issues are more useful.
MQTT and HTTP are both very vulnerable to man-in-the-middle attacks. Refer to the above for specific ideas.
2. Password problem
This part is also divided into empty password, weak password and brute force cracking.
Many devices that open MQTT on the Internet have empty passwords, and they can be connected directly using the mqtt connection tool
Similarly, for the neglect of security, there are many weak passwords, and there is no good defense against brute force cracking, so the password issue is an aspect of the MQTT protocol that needs attention. Attached brute force cracking script https://github.com/zombiesam/joffrey
3. Permission issues
The MQTT topic (Topic) supports wildcards of ‘+’, ‘#’, ‘+’ wildcarding one level, and ‘#’ wildcarding multiple levels (must be at the end).
That is to say, if our two topics are CMD/123/456 CMD/789/666, then we can subscribe to CMD/# to get all the messages under its CMD. In the attack, we can first use it to monitor all topics that do not start with $. For Topic starting with $, we can use $SYS/# to subscribe (see: https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics)
The following is the MQTT message server without permission control, directly view all Topics
The premise of the device firmware analysis is to obtain the firmware. For the method of extracting the firmware, please refer to this article:Several breakthrough points in smart device vulnerability mining (there are ten firmware extraction methods and uboot firmware extraction methods)
For me, the more practical method is to find it from the official website, or contact the product after-sales to obtain it. You can also obtain the firmware download address through software upgrade capture.
The following content is visible to members