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
[wc_pay_can_read id=’2026,2029,2030′ tishi=’You do not have permission to read this content, click here to become a member and refresh this page to read it’]
As shown in the figure below, directly search and download the specified version firmware from the official website.
After extracting the firmware, it is necessary to analyze the firmware, but before that, it is necessary to determine whether the firmware is encrypted. Usually, use binwalk to analyze and view first. At this time, if the following figure appears, the firmware may be encrypted firmware
Unencrypted firmware is usually as shown below
You can use the command
binwalk -e firmware name
After extraction, you can see the squashfs file system, and then analyze its source code.
Cloud is also a very important environment for IoT. After all, only things that can connect to the Internet are considered IoT.
In the actual test, obtaining the cloud address is a particularly important link. Generally speaking, you can directly see the device cloud address by using a packet capture tool such as wireshark. After obtaining the cloud address briefly, the first step must be performed on the cloud server. For regular and complete penetration, this part is mainly about collecting information; then, testing according to the actual situation, the scenarios I have encountered include, in a test of a car-machine system, the back-end web management terminal can directly communicate through an HTTP request The car machine issues commands, such as software upgrade updates, message push, etc. At this time, you can try to change the corresponding car machine VIN code or unauthorized vulnerabilities. Finally, you can try to analyze the firmware, filter and extract some hidden interfaces to see if There are points available.
APP and C/S clients are also vulnerable points. Regardless of the attack surface mentioned above, we can perform unpacking analysis for APP, except for the problems of conventional APP itself such as repackaging and component security issues. In addition, the most important point to pay attention to should be the information leakage part, such as some sensitive interface addresses (testing for unauthorized and deeper information leakage) and account keys for certain functional services (such as secretkey, telnet or oss server ftp service account password) etc.
For the security test of the C/S client architecture, the first thing to do is to analyze the protocol used, which can be done by conventional packet capture tools, and then test according to the attack surface of the protocol above. In addition, the client can also test Reverse information collection, DLL hijacking, etc., this test is not much, series of articles
In fact, there are many places where RFID is used in life. The most common ones are access control card swiping, subway bus swiping, smart printer swiping and printing.
Common usage scenarios include copying the access card of the community, modifying the balance of the school water card, and modifying the elevator card to swipe the floor.
This type of use is also relatively simple. Buying an NFC device from amazon basically comes with an operation tutorial. The operation of modifying the balance and elevator floor can refer to this article
After comparing hex, infer the law and the points that need to be modified, and use winhex and other tools to modify it.
In addition, due to an accidental opportunity, I have some new ideas. For example, smart printers need to swipe a card for identity authentication before printing the documents you upload. First, let’s take a look at the normal first use of the work card to swipe the card, the feedback from the printer is as follows：
Then I swiped my community access card again, and it turned out to be okay. The feedback is as follows:
Then the test idea is obvious. Through comparison and analysis, the data segment read by the printer is obtained, and then modified to infer the job number of other colleagues, and then modify it to the job number of other colleagues, so that you can see What other colleagues are printing every day…? (So it’s not really useful)
Of course, we can do more than that. Assuming that the read data will enter the database, is there a SQL injection problem? After all, the parameters are controllable. If you know the administrator’s serial number, can you directly swipe the card to become the printer administrator? , And so on.
After thinking about this, you ask me why I didn’t practice it, because I bought a PN532 and I can’t afford PM3 and more advanced card readers, and PN532 can read too few cards.
In addition, Bluetooth is actually a type of RFID, and there are actually many places where Bluetooth is used in life, such as earphones, speakers, and shared bicycles. The Bluetooth protocol is really difficult to study and learn, but it does not prevent you from coming up with a little idea. One is a man-in-the-middle attack, which modifies or intercepts information through a man-in-the-middle method. Refer to the article Bluetooth man-in-the-middle attack proxy tool. To release the attack, you can try to unlock the shared bicycle, refer to the article Bluetooth low energy data packet sniffing and Bluetooth packet capture repla
For hardware-level things, refer to the following article.
Common intrusion methods of self-service terminals
There are many things about hardware, and it is not limited to this. If there are other good articles, I hope you can recommend them.
The IoT is too extensive to cover, and it cannot be stated in one article. In actual combat, more and more comprehensive capabilities are definitely needed. This article only proposes personal opinions and opinions, and summarizes some experience after thinking.