 So, hello. Thank you for coming to our presentation. We're going to talk about exploiting the IoT Hub, which includes attacking the smart phone by compromising IoT devices and some countermeasures for this attack. And I know that the IoT Village is also running the Android Track and the CDL Track. And maybe this talk is helpful for those who are participating in the tracks. So, my name is Huon Lee, and I'm a graduate student of HCL Lab at Korean University. And I like to play in CDF, and I'm currently participating in DEF CON CDL Final as DEF Corp. And I've been researching on open-source software targeted forging and contributing to security by reporting the found bugs, and I got some CVS. And I'm also interested in embedded security such as IoT and SCADA and so forth. And we're also meant to best of the best, also known as BoB program, which is a cyber security expert educating platform in Korea. Hello. My name is Changhyun. I'm working in a cyber security consulting team at the company UI Korea. I'm a graduate student of Songyong-gun University, and I'm so excited. But also a little nervous, giving my first overseas presentation. Thank you. So, now we'll introduce our agenda of this presentation. We briefly explained the structure of smart-tone after the introduction of this over a talk. And we'll analyze real-world case study of threats that may arise in the smart-tone environment. Next, we'll conduct vulnerability analysis for different IoT devices. We found 20 vulnerabilities, and we'll describe their types. And we'll suggest feasible tech scenarios by changing these vulnerabilities. Then we'll briefly outline the countermeasures required to prevent these attacks and conclude this talk. So, now let's get started. In 2016, there were mental infections targeting IP cameras and home routers. The attack targeted against a large number of internet-connected devices to form a bond network, which was used for large-scale dose attack. In fact, the vulnerability used for this attack is quite simple, but fairly critical. Attackers can easily compromise those devices just by processing the password for talent, which means that there was no secret consideration in IoT devices. In 2017, a new internet-connected network called Perciri has been discovered targeting over 1,000 IP current models. The use of vulnerability for this attack was command injection with authentication bypass, and approximately 120,000 IP cameras were found vulnerable. However, the worst is many of these vulnerable users didn't recognize that their IP cameras were exposed to the internet. There was a case of attacks on different routers, which are used widely in the world. Even the exploit codes were released on the exploitative website. This attack consists of only two vulnerabilities as well, command injection and authentication bypass where you needed to compromise the routers. Likewise, attackers can download and execute the model on the device and build up sensible network to fully take control of the devices remotely. So, now let's focus on the secret of smart home. You know, the IoT Hub which connects all the smart things to the same network area and communicate with remote server for management is considered as vital element in the smart home environment. The Hub device is also connected to the internet, which means it can be attacked as the previous IoT exploit cases. If an externally accessible port is open, or the routers can access the same network area. In fact, Cisco tells intelligence recently released vulnerability analysis results on Samsung SmartThings Hub device. The found vulnerabilities include command injection, workflow, information leakage. And these vulnerabilities can be chained together to form a fully split code compromising the Hub device. So, as you know, the IoT threats are still ongoing and countermeasures for these threats should be considered urgently, I think. So, we have conducted trial analysis and found many vulnerabilities for the Hub devices made from different manufacturers. And we want to share the results from now on. Yes, next I will talk about the structure of smart home. According to this diagram, smart home services can be broken down into application platform server IoT Hub IoT Things. There are times when there is no need for IoT Hub, but it is present in most smart homes. I will now explain more about the IoT Hub in detail. IoT Hub manages small devices in the smart home. It supports wireless protocol like the Z-Wave, ZGB, Wi-Fi, Bluetooth, and Zera. Also, to connect to a platform server, it uses diverse provisioning protocols. These protocols include DR069, MQTT, COAP, HTTP, 1M12, and custom protocols. Yeah, next is the process of IoT Hub. The IoT Hub process is composed for steps. First, the smart home service app will register the IoT Hub with the server. And second, the IoT Hub performs a user authentication through the server. Third, the IoT Hub and the Things goes through the process of pairing. Finally, the user is able to access the Things through the application. So far, we have covered the functions of the IoT Hub in smart homes. Now we will frame why we chose the IoT Hub as our target. Our first listen is that once the IoT Hub is taken over, it would be very possible to take over everything connected to the IoT Hub. Because of this, there would be many possible scenarios are like louder exploitation. Furthermore, we imagine that through the exploitation of the IoT Hub, we would be able to hack difficult wireless protocol such as the Z-Wave. Lastly, our most important reason for choosing our target as the IoT Hub was for money. And we are both. Now we will find out more about the smart home and IoT Hub and the various threat. This picture shows a threat that exists in smart home services. I have separated the threat into two graphs, the external part which is outside the home and the internal part which is inside the home. I have only included points that were important in my opinion. In the external section, the primary threat, the supply chain attack of formula server and the user aspect pass and many the middle. And the internal section, there are memory corruption, command injection, LPE, many the middle. And very important threat is remote control of things. And now we will consider real example of a threat in each section. This case is a mobile application, an example of a threat that cannot go outside the home. One is able to control another devices using once on application. There are two examples in the internal section. We will first examine the one concerning the IoT Hub. Recently, many vulnerabilities have been discovered in the Samsung IoT Hub. This including threat is RCE, dust, information disclosure and injection. This one was discovered in the Z-wave which is a wireless protocol. It is using the default encryption key, many the middle attack was possible and now the first has been patched. Let us take a cruiser look at the IoT Hub to learn more precisely and carefully into potential threat of the IoT Hub. We drew a threat model based on stride. As you can see in the flow diagram, the IoT Hub indicated by red dot line is connected to the other section including the platform server and things. The IoT Hub was many processes and flows. Process is a circle, just line is flows. A lot of stride and other vectors is just because of this. Yes, in the table below which threat is explained now, we will talk about this in detail. So number 32 is the potential lack of info validation or poor pairing. We will now present a specific example of an instance when this threat was properly exploited. My partner we will take it from here. So from now on, I'm going to talk about vulnerability analysis for IoT Hub. We analyzed total four products. For each product, the MC architecture is classified as ARM and MIPS. Also a jet wave, Wi-Fi, Bluetooth and RF are used for wireless communication between IoT Hub and smart devices. And the IoT Hub transmits the threat status information of the device such as phone information, certificates and secret keys and so on to the server via provisioning so that the remote server can't manage the device such as automatic updates, device registration, connection and communication with mobile application. So company A uses TR-069 as provisioning that is customer premises equipment, wide area network management protocol also known as CWMP. And this will be explained more detail later on on our slide. And company C uses the MQTT protocol. MQTT is a machine to machine and Internet of Things connectivity protocol and it was designed as an extremely lightweight public subscribed messaging transport. To manage IoT Hub devices, there are management services in the form of web application or something else. And web applications are usually developed based on open source such as, well, go ahead for web server and light HDPD, but nowadays it seems to be a trend to customize the source or develop the service directly from the manufacturer. In addition, we confirmed whether it can access to the debugging shell from remote or you are at the debugging port. As you can see, we can get a debugging shell by you are for all of the target devices. So there are six steps to analyze IoT devices. First of all, instruct the firmware because the functions need to be analyzed are usually embedded in the firmware. Second, acquire a command shell for debugging. When you access the shell, you will notice which processes are running as a key role. Those requests, once the main binary is extracted, we can analyze the vulnerabilities and finally exploit them. There are roughly three ways to extract the firmware through the provisioning. The remote server checks the firmware version of the Hub device and performs automatic update when the version is not up to date. At the same time, the updated firmware URL information can be obtained and the firmware can be downloaded. Another way to get the firmware is using the UR debugging port. As you can run all commands in the debugging shell, we can extract the desired binary through commands like TFTP, FTPGa, CoralNC, and so on. Also, we can use JTAG instead of the UR, but we'll skip it because it's too expensive. So if both methods are impossible, there is a way to dump the flash memory directly. There are many ways to dump the flash memory, but in our case, we used Arduino equipment. In addition, we can also remove the flash memory chip through the disordering for memory dump. Next, we need to acquire a debugging shell usually using the UR method. Sometimes it's easy to get a shell if Telet or SS40 is open and it says it's set as a default account, which can be easily cracked. And the UR attack exploited this type of vulnerability. And usually a login account is required, as you know, when assessing via UR or Telet. Then how to log into the shell? Let's suppose the firmware is extracted already obtained in a different way. Then we can search the hard-core password or check the password routine by reversing the relevant binary containing the login-related functions. Sometimes the password is written in the config file and we can find it easily. Now, what if you cannot get the firmware or do not know the password? Is there a way to log in even if UBoot's boot delay option is set to zero? You know, UBoot is a bootloader handling lots of tasks such as system initialization, current loading and execution. Normally if the boot delay option is set to enough, we can get it to bootload the prompt and change the kernel image booting option. But otherwise, we'll have to short the NAND flash chip. It's the principle that connects between groundpeat and the particular pin of the NAND chip because it's a current loading error and can bootload the prompt. After entering bootload the prompt, we can set boot ARGS options by adding entity call pin as a string and then reboot. Then we can get the UR debugging shell with root account. Next, identify main process. Since the program startup commands are usually defined in the startup script file, we can easily find the main process. The network status check command tells you which ports are open and which processes are running. There are five categories of vulnerabilities we have found. Let's take a closer look at each one. When sending a payload to a web application, it usually validates the session value and we can bypass the authentication with a simple URL trick. As you can see, if the request URL ends in .css, .gif, .jpg and et cetera, the function of validation for a session is not called, which means we can bypass authentication routine. In some cases, the program itself creates a session value with non-random. In this case, we can bypass the authentication by generating our forward session value. In fact, this is one of the vulnerabilities used in the recently released Router exploit. As you can see, the first vulnerability is authentication bypass. This was done by putting question mark images strings at the end of the URL. Attackers could easily bypass authentication by inserting certain keywords into the end of the URL and succeed in remote code execution with a second vulnerability command ejection. The most common but fatal vulnerability is command ejection. The vulnerabilities could be implemented literally by inserting arbitrary commands into certain headers or parameters. This can reliably execute code without the need for bypassing mitigations like DP and AS at all. As you can see in the image, if you inject a command into a certain parameter, it passes an argument of the system function without sanitization resulting command ejection. As you can see, one simple command ejection makes it possible to access to the system remotely. This is the most attractive vulnerability for attackers. Now, this is the very typical vulnerability, workflow. In fact, many of the IT devices we had analyzed didn't have secure coding applied. So we focused on the vulnerable functions like searching copy, espring tab, mem copy and so on to find workflow. As you can see from the image below, the functions are used quite a lot. Now, on some devices, we could find functions that simply execute commands. This function is assumed to be used for debugging from the perspective of developer. However, it is considered as a backdoor from attackers point of view. Unlike most cases, in this picture, the name of the function is too clear that it is a backdoor. However, the function is usually hidden and some constraints should be met to execute commands. Likewise, you can control the device very easily. As you can see, we inserted command creating directory on command parameter. Then we can create the directory successfully. Lastly, local privilege escalation vulnerability. There are many ways to elevate privileges on Linux embedded systems. Sometimes in an embedded system, the privileges are separated as root and user so that certain processes run with normal user account. In the account accessed through talent is a normal user account. Elevation privilege is required to execute work commands. Instead of Linux current exploitation, we'll show you privilege escalation by using a logical file, which is user-owned script file executed as root account. As you can see, the user account is linear. It's a normal account. And the rc.local file is a startup script that is executed with root permission. And it executes serial.sh file as a command. However, the serial.sh is a user-owned file and can be modified as normal user account. If we insert a command to change the password of the root account into the serial.sh file, then we can access to the system with root account successfully. Based on the found vulnerabilities, we can develop a final exploit. Profile flow can be exploited to remote code execution. To do this, our apetecity and shellcode development are needed. So you can run shellcode by chaining three gadgets that control specific registers, get the address of the shellcode on the stack, and jump to the shellcode. This code is a reverse TCP connection for architecture that allows you to execute commands from a remotely connected server. So we have developed a complete exploit for company A hub product. And we will demonstrate that we can fully take control of the hub device by combining the authentication bypass with buffer flow. So in first demo, we'll show you the company A's hub device is fully compromised by buffer flow and authentication bypass. So the left side is attacker side. So we have to open the port, a listening port from remote reverse TCP connection. And the right side is a tele-session for checking our exploit's success. And this is the UART debugging shell. Also checking the exploit's success. And the middle side is attacker side and execute the exploit code by setting target IP. The target IP is a web service of the hub device. And we can get a remote shell. For proof of concept, we create a flag pile as contents point. And as you can see, the flag file is created successfully and the content is the same. And also in the UART debugging shell. So as you can see, we can execute any commands as we want. So we compromise the hub device successfully. So now let's look at which attack scenarios are possible with the identify vulnerabilities. First, it is the scenario that controls the things. If an attacker gains control of the hub device, all IoT devices connected to the hub can be controlled. Usually hubs and devices communicate wirelessly by jet wave, GCP and RIF, but there is no authentication between them. So we can leverage these points to manipulate command packets to control devices or for status information. As you can see, the hub device recognizes the specific file of the packet as control code. And based on this, it gives a certain command to the relevant devices. Also, if the main process is implemented as Java application, you can see that the payload is also sent in a specific format. So by delivering packets based on these formats, we can control the devices as we want. So this is a second demo. This is a door open sensor. In this demo, we will show that we can forge status information of the smart things and it can lead to false information on mobile application. Because the company only service for Korean customers, so the mobile application supports only Korean. So please understand that. And we have subtitle as English. So as you can see, the application tells the door open sensor is open. However, if we send the packet that includes closed information for the sensor, then you can see that the application status information is just forced. But still, the door open sensor is open. And the next demo, we can disconnect the smart things by sending this package to the hub device. So, yeah, as I said before demo, we can disconnect the device. And we can also control the smart bulbs. It's the PLX hub bridge and the smart light. If you compromise the hub device, you can analyze many command packets and send counter packet to the connected smart things. For the proof of concept, we developed a Python script, yeah, to control the light bulb. At first, we can turn on the light. So, and also we can adjust the brightness of the light bulb. And so if you set, oh, sorry. Sorry. If you set the brightness as middle, the brightness will be dim. And also we can turn off the light. And we can flash the light bulb also. So this means you can control the device as you want if you compromise the hub device. Then let's look at the cases of encrypted communication between the server and the hub. Since the updated devices are communicating with servers as encrypted as SSL or TLS, there is no useful information to be extracted in the case of many in the middle. However, one of the devices we have analyzed uses a scheme that the IoT hub itself generates as toward the encryption key in the device. Which means that the packet can be decrypted if the hub is compromised. So we analyzed the encryption algorithm and found that it is Ace128 ECB mode. This is a symmetric key. Cypher, so the server and the hub share the same key. Coincidentally, there was a peripheral vulnerability in the hub device which we could take over the system and extract the 16-byte encryption key. So as you can see the data area of the packet is encrypted. For peripheral set, Ace AES128 ECB mode encryption algorithm was written in C code. And corresponding message is decrypted by entering the extracted key values. This can be used as a scenario for disconnecting a hub device by sending a first information to the server. So my partner Chang-yeon will continuously. Hi, I'm back. This scenario is the man in the middle. Some IoT hubs use TR069 protocol for visiting with the server. When the server and IoT hub communicate, the HTTP response message is changed and exposing the hub's critical information. We will show the admin web password in the next demo. Oh, sorry. The TR069 protocol is authenticated via two HTTP list guests with the server. After authentication, change the HTTP list guests, this point, yeah, change. Just as the server asks for information, this hub is disclosed the admin web password and the string is small. Sorry. This is the web admin password and we dropped the packet. It's a simple man in the middle demo. These vulnerabilities may be used in Burnet because its IoT devices are connected to internet, which means that those can be used for Burnet. A lot of Burnet have a code since the Mirai Burnet case. Yes, let me take a cruiser, look at the IoT Burnet in detail. First, IoT Burnet is increasing. Burnet such as Mirai, Hajime, and Moon continue to be found. Last year many IoT malware were discovered. Second, the IoT attack method includes Saturday on the admin web, one day on the open source and misconfiguration like the same password, default password. And third, the attack purpose is evolving. In the beginning, IoT Burnet used the DOS, but today used as PDoS, ransomware, and mining pool. Finally, many countries are causing damage like the Mirai Burnet. So how about the IoT Hub we found? We searched, we searched through Shodan. We haven't found much, but 70,000 devices has been exposed. Also, the vulnerabilities of IoT Hub can be used as a mining pool. There are cases where Bitcoin was mined through OpenWRT. Of course, you need hardware support for mining. It is just one of the many scenarios. Two weeks ago, the article came out. It was mining through micro-thick devices. According to this article, there was a mining code on the admin web page of micro-thick devices. Like this example, mining pools can damage devices or users. Maybe the IoT Hub is also possible. The final part of our presentation, we did IoT security. How should we secure IoT? I think there are three necessary steps to follow. Device security and compliance and detect anomalies and threats. The first is device security. Each device needs each unique password, share, admin web, and Wi-Fi password. Most always different each following password rules. Debugging ports like UART, JTA must be disabled. For calls developed individually, secure coding is absolutely necessary. And if we have an open source, it must always be updated to its latest version. We are able to easily carry out our analysis because three out of the four corporations had not encrypted in their respective partners. Then, even if the hacker obtained the partner, the file system will not easily be obtained. Second about compliance, IoT security guideline made by international organization must be followed. It is good to keep this guideline as a reference because they explain the security of the IoT ecosystem. A good guideline to follow it is this IR-A200 made by NIST. But we should not stop here. There are the guidelines of minimum. And security must constantly be maintained. Third, one must be ready to deal with anomalies and threat detection. To detect anomalies and threat, one must do the following, data collection, intelligence analysis, automated response, and visualization. So, it's conclusion of our target, our talk, sorry, our talk, to level our presentation. We found many different threats, the IoT hub, and smart home services increasing due to technology like the voice recognition, AI, and machine learning. Furthermore, the IoT hub is evolving to the forms of AI speakers and work paths. This is good news for us. We have plenty of research to do in the IoT security. We will threaten more findings and research about security in the future. Here are the reference and special thanks to Anastasia, Singi, Bongi, and Boombom Park. Thank you for listening to our presentation. If you have any questions, we are happy to take them. When you come to us, please, we are always open. Thank you.