Peekaboo! I Own You.

Transcription

1 Peekaboo! I Own You. The Tale of Hundreds of Thousands Vulnerable Devices with no Patch, Ever. Amit Serper Cybereason Inc. Yoav Orot Cybereason Inc. Abstract This paper details how crafting a special HTTP request allows us to get a device s administrator password and fully control it. Also, by accessing a certain webpage in the administration panel, a full root shell can be achieved by injecting a specific command. This paper covers the reverse engineering process of the product, the vulnerabilities discovered and their ramifications. 1

2 Introduction In this paper we will demonstrate how a specially crafted HTTP request is used as a vector to a fully compromise the product by detailing numerous zero-day remote vulnerabilities. In this paper we will fully demonstrate the following: Bypassing the web authentication mechanism by crafting a special HTTP request Launching a socket binding shell Redirecting a port to the socket binding shell by leveraging the UPNP client on the product We have two goals in this paper. First, we want to show how insecure this product is and how it s developers never took security into consideration. Second, we want researchers and developers to look at the big picture when it comes to embedded systems security. The vulnerabilities we discovered give attackers root access to the camera, allowing them to do whatever they want to the devices, including enslaving them into IoT botnets. These flaws, when exploited, can threaten the Web s ability to function, as we saw with the Dyn attack in October Product overview The product is a very affordable IP surveillance camera with many features such as motorized control, wireless connectivity and an SD card slot to save recorded videos. But its main feature is a plug- n -play system that allows users to connect to their camera from anywhere using a mobile app without the hassle of dealing with nat traversals or port forwardings. 2

3 The cameras are manufactured by a white-box vendor, making tracing their origins and what companies are selling them difficult. We managed to identify 31 vendors that are selling vulnerable cameras. We decided to name one vendor -- a Chinese manufacturer called VStarcam -- since their cameras can be easily purchased on Amazon and the company made claims on its website that users will no longer have security vulnerability worries with the device since it tells them if they have a weak password. Figure 1: Camera advertisement from Vstarcam's website The plug- n -play feature is the very feature that makes the camera such an interesting device to research. The reason is that the plug- n -play system is in fact a vendor managed solution in the form of a cloud. Every camera has a unique ID (in the form of a QR sticker on the camera) that identifies it inside the vendor s cloud and authenticates it with a password, which is also on the same sticker (the default passwords are the same for all the cameras). Theoretically, if attackers possess the victim s unique ID and password, they could watch the camera s image and control it. Analyzing the target device As always with embedded systems, firmware analysis is the best and easiest way to start since vendors usually include firmware update images in their website. Unfortunately, unlike other popular embedded devices, this device is not made by a well-known vendor, hence, firmware upgrades are not in priority. We could not find firmware files anywhere on the Internet so we had to extract them from the product. 3

4 There are several ways to extract firmware. The standard (and more complicated) approach if there is no shell access to the device is to take the flash storage chip off the circuit and read the data directly from it. This approach is usually rather complicated and not for resource-less researches such as us. Luckily, most of those IoT devices have UART headers on their circuit board. That allows one to solder and connect wires to the appropriate headers and achieve an effect that s the equivalent of plugging a monitor and keyboard directly into the console. In our case, it took us about 30 minutes to find the RX, TX, ground and VCC headers on the board using a bus pirate device. Figure 2: Using a BUS Pirate to find the UART headers After successfully locating the UART (serial) ports on the board we rebooted the camera in order to see if we can see it booting. Luckily enough, we guessed all the parameters correctly and got the following boot log, which finished with a root shell: See Appendix As seen in the image, the camera is running a version 2.6 Linux system and we now have a busybox root shell on it. While trying to work on the camera s shell using the serial connection, our console was constantly bombarded by debug error messages (caused by the disconnected camera motors). Since we now had a root shell on the device, getting the firmware itself was as easy as using the dd program on the camera in order to read the raw file system from /dev/mtdblock0 and write to the camera s SD card so that we could further analyze the firmware. 4

5 As we examined the files on the camera s file system, we took special interest in the ones that existed in the webserver s root directory since we were looking for any file that might have anything interesting in it. We found an interesting file called system.ini. This is a binary file which contains the camera s running configuration settings,including the administrator s password. We realized that by disassembling the webserver s binary and looking for any occurrences of this file in the disassembly, we found that this file is being read and parsed by the webserver on its start time: Figure 3: system.ini being read by the webserver IDA Pro screenshot disassembly Since we know that system.ini contains the password and it is in the server s web root directory, we tried accessing it directly through the browser by visiting but we were greeted by the unfortunate authentication dialog. No luck. Since most consumer embedded devices are controlled and managed by the web administration system, it is very common that the webserver running on the embedded device is a vendor modified version of an open source webserver. The first step would be to try to identify the webserver by sending a HEAD / HTTP/1.1 HTTP request. Figure 4: Sending a HEAD request to the camera's HTTP server As seen in the image, the camera is running the goahead webs webserver. Goahead is a very popular open source webserver among embedded devices developers since it allows developers to implement a lot of custom features into the webserver itself, leading to a single lightweight binary executable that contains almost all of the features and functionality of the device in it. This is why the webserver makes the perfect penetration vector and creates the biggest attack surface in embedded devices. 5

6 As said in the previous paragraph, the webserver is being used to both manage the camera and view the images or video that the camera is taking (assuming that you do not wish to use either the camera s Android or iphone app or its built-in RTSP server). When the user is accessing the camera s IP address on port 81 (the default port for the camera s webserver), the user is prompted with a standard authentication request. Figure 5: Authentication prompt Since goahead is an open source product, we decided to look at its source code and look for ways to bypass the authentication. The code of the authentication function was fairly straight forward and nothing interesting was found there, so we decided to look somewhere else. Since the URL is the first user controlled string that an HTTP server meets, we decided that we should look at the logic of the URL parsing. 6

7 We started by looking at the websgetport() function: Figure 6: websgetport() GET /index.asp HTTP/1.1 Figure 7: Legitimate HTTP request 7

8 When the server is parsing a URL, it looks for the first / in the URL and uses s a delimiter to figure out the structure of the request. If the url[7] has a / in it, then it means that the structure of the HTTP request is legitimate and the regular flow of the program will continue; the server will check if the requested URL is protected (requires authentication) or not and normal behavior will continue. But as we looked more and more into the sources, we could not find any code that handles any exceptions.this raised a serious question: What would happen if we sent a malformed HTTP request that does not start with a /? A request like this one: GET index.asp HTTP/1.1 Figure 8: Malformed request Normal webserver behavior would be to return back the the HTTP 400 bad request error code. But no, this isn t the case with this version of goahead. The developers tried to stay as minimal as they could with their code. As far as they expected it, as you can see by looking at the websparsefirst() function, the way an HTTP could be invalid is if it won t be a GET, POST or HEAD. The structure of the request does not matter, it s only the type! Figure 9: websprasefirst() Bad request handling 8

9 So by now we had a theory that sending a malformed HTTP request may cause unexpected behavior in the form of just sending us the raw file that we are (brokenly) GET ing. What better way will be to test this theory than by sending a malformed request for system.ini! After going through all the source code in all of the versions of goahead webs that we could find and looking at the websparsefirst() function, we noticed that a fix for that bug was added by Luigi Auriemma: Figure 10: Broken request fix by Luigi Auriemmahandling As you can see, that fix was added in January This paper was written in January That means that this product, which is still being perpetually sold in stores to this day, doesn t ship with a 0day (that we had thought we discovered) but with 4745-day! It also means that every other product (be it an embedded device or whatever) is vulnerable to this ancient bug. Figure 11: Getting system.ini using a malformed HTTP request Success! The server sent us the contents of the system.ini file, which meant that we now had the camera s password. We could now authenticate to it. Since we now have a way to authenticate legitimately to the camera we can modify, view and control anything within the configuration page that also includes the viewing and streaming of the live feed from the camera. 9

10 While the authentication bypass trick is nifty, that still isn t code execution. There are many ways to achieve code execution on such devices. The common approach is usually a stack buffer overflow. The problem is that such overflows are cumbersome to research. You need to traverse the code and look for unsafe calls and lack of boundary checks and also write shellcode and debug it. In this case, finding a code execution exploit was rather simple. While navigating through the camera s configuration pages we noticed one of the configuration pages, mail.htm. This page allows the user to configure mail notifications from the camera for miscellaneous cases (i.e movement detection) that will cause the camera to send an notification to the user. As you can see in the image, the user must first provide all of his SMTP server details and credentials for this function to work. Since this function was added by the camera s manufacturer to the webserver s source code, this is not part of the open source code that could be pulled from Goahead s GitHub page so some disassembly is required. IDA Pro identifies this function as aechosmailxasss() as can be seen in Figure 12 it is pretty easy to spot the problem there: Figure 12: loc_533d4 disassembly that calls aechosmailxasss() 10

11 The webserver simply executes echo and string formats the user input from the mail.htm form page without any sanitation. That opens up the door for a classic command injection attack by simply setting one of the options in the form to ;<command>. Moreover, since the webserver is executed as root, the commands that will be injected by the attacker will be executed with the highest privileges. After all of the malicious commands were placed in the appropriate field, all the attacker has to do is to click the Test button. That will cause the code to pass the parameters out to echo and once the malicious parameter with the semicolon (which will be placed in the Receiver 1 field) in it will be processed, the system will execute that command. Figure 13: mail.htm configuration page with malicious input That means that we now have two exploits. One 0day/4545-day that allows us to retrieve the camera s admin password and a 0day that allows us to execute commands as root through the camera s mail settings page. 11

12 The code to use both vulnerabilities, including the parsing of the system.ini binary file, boils down to 61 lines of python code (that I m sure that could be narrowed down and tidied up nicely to less code): 12

13 The above code will cause the camera to execute a telnet daemon running on port The following question is asked: What if the camera is behind NAT and only the web port is forwarded? What about port 4444? This makes this exploit useless since there is no reason for port 4444 to be forwarded to the camera. This is where UPNP comes into play. This protocol was created to make port forwarding a non-issue for programs and devices that are connected to the network. UPNP saves users from the long and sometimes cumbersome process of explicitly forwarding ports from their routers to their computers and other devices to make them accessible from the Internet. UPNP takes care of that automatically with the only one prerequisite: UPNP has to be enabled on the router, which it usually is by default. UPNP works in a client/server architecture where a UPNP client sends a request to the UPNP server and asks for a certain port to be opened and redirected to a specific IP for a certain time. The length of time could be anywhere from 1 second to infinity. It depends on the server. Our camera makes use of UPNP for the sake of user friendly-ness when forwarding various ports for the camera. In order to set the UPNP forwarding, the camera vendor implemented several UPNP functions into the webserver. These functions are also not part of the open source code and were reverse engineered. The main functions that handle UPNP port mapping is a function that we ve called SetUpnp(). This function holds a list of all of the port forwardings that are needed by the camera and then calls another function that we ve renamed CallUpnpc(). That function actually sends the UPNP requests to the router. To our surprise, the UPNP client itself was not implemented as a part of the webserver. Figure 14: Disassembly of CallUpnpC() (renamed) 13

14 But again, just like the in the case of the mail notification page, the webserver is using system() to execute a binary called UPNPC and passing the ports as parameters. That means that using our command injection exploit we could call the same UPNPC binary and open the ports for ourselves: Figure 15: upnpc-static being executed with no arguments on the camera Conclusion So why not just throw out the cameras that are impacted by this vulnerability? Not every person wants to toss out these devices and, more importantly, there are already hundreds of thousands of these devices already connected to the Web. This means the bad guys can see every image on the camera or load it with Mirai malware. Plus, sending these cameras to the trash heap wouldn t solve the greater problems around IoT security. There are other connected devices out there that are just as vulnerable and can be hijacked and commandeered into the joining an IoT botnet. Talking about these vulnerabilities is meant to show how easy it is to hack IoT devices and why security can't be tacked on after a product is released. 14

15 Appendix 15

16 16

17 17

18 18

19 19

20 20

21 21

22 22

23 23

24 24

25 25

26 26

27 27

28 28

29 29