![](https://securelist.com/files/2017/11/AdobeStock_133171498-990x400.jpeg) Black Friday and Cyber Monday are great for shopping. Vendors flood the market with all kinds of goods, including lots of exciting connected devices that promise to make our life easier, happier and more comfortable. Being enthusiastic shoppers just like many other people around the world, at Kaspersky Lab we are, however paranoid enough to look at any Internet of Things (IoT)-device with some concern, even when the price is favorable. All because there is little fun in buying [a coffeemaker that would give up your home or corporate Wi-Fi password]() to an anonymous hacker, or a baby-monitor that could livestream your family moments to someone [you most definitely don't want it livestreamed to](). It is no secret that the current state of security of the IoT is far from perfect, and in buying one of those devices you are potentially buying a digital backdoor to your house. So, while preparing for IoT-shopping this year, we asked ourselves: what are our chances of buying a perfectly secure connected device? To find the answer, we conducted a small experiment: we randomly took several different connected devices and reviewed their security set up. It would be an exaggeration to say that we conducted a deep investigation. This exercise was more about what you'd be able to see at first glance if you had a clue about how these things should and shouldn't work. As a result we found some rather worrying security issues and a few, less serious, but unnecessary ones. We looked at the following devices: a smart battery charger, an app-controlled toy car, an app-controlled smart set of scales, a smart vacuum cleaner, a smart iron, an IP camera, a smart watch, and a smart home hub. ## **Smart Charger** The first device we checked was the smart charger that attracted us with its built-in Wi-Fi connectivity. You may ask yourself: who would need a remotely controlled battery charger, especially when you need to manually set the battery to charge? Nevertheless, it exists and it allows you not only to charge the battery, but to manage the way you charge it. Like a boss. The device we tested charges and restores most types of batteries with a nominal voltage from 3 to 12 volts. It has a Wi-Fi module, which allows the device owner to connect remotely to control the charging process, to change the charging settings and to check how much electricity the battery is storing at any time. [![](https://securelist.com/files/2017/11/171127-hackspace-report-1.png)]() Once turned on, the device switches by default to 'access point' mode. The user should then connect to the device and open the management interface web page. The connection between the charger and the device you use to access the management panel uses the outdated and vulnerable WEP algorithm instead of WPA2. However it is password protected. _Having said that, _the predefined password is '11111' and it is actually written in the official documentation that comes with the device and is searchable online. However, you can change the password to a more secure one. _Having said that_, the length of the password is limited, for some reason, to five symbols. Based on the information available [here](), it would take four minutes to crack such a password. In addition to that the web interface of the device itself has no password protection at all. It is available as is, once it is connected to your home Wi-Fi network. Who would attack a smart charger anyway, you may well ask, and you would probably be right as there are likely few black hat hackers in the world who would want to do that. Especially when it requires the attacker to be within range of the Wi-Fi signal or have access to your Wi-Fi router (which, by the way, is a much bigger problem). On the other hand, the ability to interfere with how the battery is charging, or randomly switching the parameters could be considered as worth a try by a wicked person. The probability of real damage, like setting fire to the battery or just ruining it is heavily dependent on the type of battery, however the attack can be performed just for lulz. Just because they can. To sum up: most likely when using this device, you won't be in constant danger of a devastating remote cyberattack. However, if your battery eventually catches fire while charging, it could be a sign that you have a hacker in your neighborhood, and you have to change the password for the device. Or it could be the work of a remote hacker, which probably means that your Wi-Fi router needs a firmware update or a password change. ## **Smart App-Controlled Wireless Spy Vehicle** While some people are looking for useful IoT features, other seek entertainment and fun. After all, who didn't dream of their own spying toolset when they were young? Well, a Smart App-Controlled Wireless Spy Vehicle would have seemed a dream come true. This smart device is actually a spy camera on wheels, connected via Wi-Fi and managed via an application. The spy vehicle, sold in toy stores, has Wi-Fi as the only connection interface. For management there are two official applications, for iOS and Android. We assumed that there could be a weakness in the Wi-Fi connections – and we turned out to be right. [![](https://securelist.com/files/2017/11/171127-hackspace-report-2.png)]() The device is able to execute the following commands: * Move across the area (with multiple riding modes, it is possible to control speed and direction) * View an image from the navigation camera during movement, for ease of navigation * View an image from the main camera, which can also be rotated in different directions (there is even a night vision mode) * Record photos and videos that are stored in the phone's memory * Play audio remotely via a built-in speaker Once connected to a phone, it becomes a Wi-Fi access point without password requirements. In other words, any person connected to it can send remote commands to the vehicle – you'd just need to know which commands to send. And if you – being a bit concerned about the lack of password protection in a child's toy that has spying capabilities – decided to set one up, you'd find there was no opportunity to do so. And if you have basic network sniffing software on your laptop, and decided you'd like to see what the vehicle was currently filming, you'd be able to intercept the traffic between the vehicle and the controlling device. That said, a remote attack is not possible with this device, and an offensive third-party would have to be within the range of the toy's Wi-Fi signal which should be enabled. But on the other hand, nothing prevents an attacker from listening to your traffic in a passive mode and catching the moment when the device is used. So if you have seen someone with a Wi-Fi antenna near your house recently, chances are they're curious about your private life, and have the means to look into it. ## **Smart Robo Vacuum Cleaner. With camera** Speaking of other devices with cameras that are around you, we spent some time trying to figure out why a smart vacuum cleaner would need to have a web-cam - is it for the macro filming of dust? Or to explore the exciting under-bed world? Joking aside, this function was made specifically for the cleaning enthusiast: if you find it exciting to control the vacuum cleaner manually while checking exactly what it's doing, this is the gadget for you. Just keep in mind that it is not quite secure. [![](https://securelist.com/files/2017/11/171127-hackspace-report-3.png)]() The device is managed via a specific application – you can control the cleaner's movement, get video live-streaming while it's cleaning, take pictures, etc. The video will disappear after streaming, while photos are stored in the application. There are two ways to connect to the device via Wi-Fi: * With the cleaner as access point. If you don't have a Wi-Fi network in your home, the device will provide the connection itself. You simply connect to the cleaner via the mobile application – and off you go! * The cleaner can also work as a Wi-Fi adapter, connected to an existing access point. After connecting to the cleaner-as-access-point you can then connect the device to your home Wi-Fi network for better connection and operation radius. As the device is managed via a mobile phone application, the user should first go through some kind of authorization. Interestingly enough, for this they only need to enter a weak default password – and that's it. Thus, an attacker just needs to connect to cleaner's access point, type in the default password to authorize themselves in the application for pairing the mobile phone and the cleaner. After the pairing is completed, they can control the device. Also, after connection to a local network, the robot vacuum cleaner will be visible in the local network and available via a telnet protocol to anyone who is also connected to this network. Yes, the connection is password protected, which can be changed by the owner of the device (but really, who does that?!), and no, there is no brute force protection in place. Also the traffic between the app and the device is encrypted, but the key is hard-coded into the app. We are still examining the device, and the following statement should be taken with a big grain of salt, but potentially a third-party could download the app from Google Play, find the key and use it in a Man-in-the-Middle attack against the protocol. And, of course, like any other Android-app controlled connected device, the robot vacuum cleaner is a subject to attack via rooting malware: upon gaining super user rights, it can access the information coming from the cleaner's camera and its controls. During the research, we also noticed that the device itself runs on a very old version of Linux OS, which potentially makes it subject to a range of other attacks through unpatched vulnerabilities. This, however, is the subject of ongoing research. ## **Smart Camera** IP cameras are the devices targeted most often by IoT-hackers. History shows that, besides the obvious unauthorized surveillance, this kind of device can be [used]() for devastating DDoS-attacks. Not surprisingly, today almost any vendor producing such cameras is in the cross-hairs of hackers. In 2015, our attempt to evaluate the state of security of consumer IoT took a look at baby monitor; this year we've focused on a rather different kind of camera: the ones used for outside surveillance – for example the ones you've put up in your yard to make sure neighbors don't steal apples from your trees. [![](https://securelist.com/files/2017/11/171127-hackspace-report-4.png)]() Originally, the device and its relatives from the same vendor were insecure due to a lack of vendor attention to the problem. But the issue of camera protection changed dramatically around 2016 after reports of unauthorized access to cameras became publicly known through a number of publications like [here]() or [here](). Previously, all the cameras sold by this vendor were supplied with a factory default account and default password '12345'. Of course, users tended not to change the password. In 2016, the picture changed radically when the vendor became an industry pioneer in security issues, and started to supply cameras in 'not activated' mode. Thus, there was no access to the camera before activation. Activation required the creation of a password and some network settings. Moreover, the password was validated in terms of basic complexity requirements (length, variety of characters, numbers and special characters). Activation of the camera could be performed from any PC with access to the camera over the local network. Since this reform, updating the firmware on a camera with a default password leads to the camera demanding a password change and warning the user about security issues every time they connect. The password requirements are quite solid: [![](https://securelist.com/files/2017/11/171127-hackspace-report-5.png)]() Additionally, protection from password brute forcing has been implemented: [![](https://securelist.com/files/2017/11/171127-hackspace-report-6.png)]() [![](https://securelist.com/files/2017/11/171127-hackspace-report-7.png)]() Moreover, the vendor added a new security feature to the firmware in 2016. This involves protection against brute forcing, by automatically blocking access for an IP address after five to seven attempts to enter the wrong password. The lock is automatically removed after 30 minutes. The feature, which is enabled by default, significantly increases the level of security. Nevertheless, not everything is perfect in the camera. For instance, the exchange of data with the cloud is performed via HTTP, with the camera's serial number as its ID. This obviously makes Man-in-the-Middle attacks more realistic. In addition to a standard WEB interface for such devices, there is a specialized tool for camera configuration, which can search for cameras on the network, display data on the cameras, and perform basic settings including activation, password changes, and the implementation of password resets for network settings. When triggering the device search the PC sends a single Ethernet frame. The camera's response is not encrypted, and contains model information such as the firmware, date reset and network settings. Since this data is transmitted in a non-encrypted way and the request does not have authorization, this one Ethernet package can detect all cameras on the network and obtain detailed information about them. The algorithm has one more weakness: when forming a response, time delays are not considered. As a consequence, it is easy to organize a DDoS attack in the network, sending such requests to all cameras within the presented Ethernet network . Apart from the described specific protocol, cameras support a standard SSDP protocol for sending notifications, and this allows any software or hardware to automatically detect the cameras. This SSDP data also contains information about the model and serial number of the camera. One more attack vector lies in the remote password reset, which is supported by a technical support service. Anyone with access to the camera's network can select a camera through the specialized tool for camera configuration and request the reset procedure. As a result, a small file containing the serial number of the camera is created. The file is sent to the technical support service, which then either refuses the request or sends a special code to enter a new password. Interestingly enough, the service doesn't even try to check whether the user is the owner of the camera – outdoor surveillance assumes that the camera is located out of reach, and it is almost impossible to identify remotely the author of the request. In this scenario, an insider cybercriminal attack is the most probable vector. To sum up: luckily this is not the worst camera we've ever seen when it comes to cybersecurity; however, some unnecessary issues are still there to be exploited by an offensive user. ## **Smart Bathroom Scales** Remember that picture from the internet, where hacked smart scales threaten to post their owner's weight online if they don't pay a ransom? Well, joking aside we've proved this may be possible! [![](https://securelist.com/files/2017/11/171127-hackspace-report-7-5.jpg)]() This is a smart device, interacting with a smartphone app via Bluetooth, but it is also equipped with a Wi-Fi module. This connectivity provides the owner with a number of additional features, from weight monitoring on a private website secured by a password to body analysis and integration with various healthcare apps. Interestingly enough, the only Wi-Fi-enabled feature is the receiving of weather updates. We decided to test the possibility of arbitrary updates\software installation on the specified device in LAN using ARP spoofing and the implementation of Man-in-the-Middle attacks. Here's what we found. [![](https://securelist.com/files/2017/11/171127-hackspace-report-8.png)]() The mobile phone interacts with the main server via HTTPS, in a series of queries. The scales themselves are connected to the mobile phone via Bluetooth. The process of pairing is simple: you request connection via the application, and then turn the scales' Bluetooth connection on. Given the very limited time for this stage, it is very unlikely that someone will be able to pair the devices without the user's knowledge. Among other things, the device transmits via Bluetooth various user data – mail, indication of weight, etc. The device receives updates via the application. The latter sends the current version of updates and a number of other parameters to the server – the server, in turn, passes to the application a link to the downloaded file and its checksum. However the updates are provided as is, on the HTTP channel, without encryption, and the updates themselves are also not encrypted. Thus, if you are able to listen to the network to which the device is connected you would be able to spoof the server response or the update itself. This enabled us to, firstly, 'roll back' the version of the updates, and then install a modified version that does not match the one retrieved from the server. In this scenario, the further development of attacks is possible, like installing arbitrary software on the device. The good news is that this device has no camera, so even if any other severe vulnerabilities are found, you are safe. Besides that, who would want to spend time on hacking smart scales? Well, the concern is a valid one. First of all, see the picture at the beginning of this text, and secondly: as we already mentioned above, sometimes hackers do things just because they can, because certain things are just fun to crack. ## **Smart Iron** Fun to crack – that is something you can definitely say about a smart iron. The very existence of such a device made us very curious. The list of things you could potentially do should a severe vulnerability be found and exploited looked promising. However, the reality turned out to be rather less amusing. Spoiler: based on our research it is impossible to set fire to the house by hacking the iron. However, there are some other rather interesting issues with this device. [![](https://securelist.com/files/2017/11/171127-hackspace-report-9.png)]() The iron has a Bluetooth connection that enables a number of remote management options through a mobile app. We assumed that communication with the server would be insecure, allowing someone to take control of the device and its sensitive data, as manufacturers would not be paying enough attention to the protection of this channel, believing that a smart iron would be of little value to an attacker. Once it is connected to the user's mobile phone, the iron is managed via the application, which exists in versions for both iOS and Android**. **The app allows you to: * View the orientation of the iron (whether it is lying flat, standing, or hanging by its cable) * Disable (but – sadly - not enable) the iron * Activate 'safe mode' (in which iron does not react to a mechanical switch on. To turn the iron on when it is in that mode you need to turn off safe mode in the app). In terms of on/off safety the iron automatically switches off if it is stationary for five seconds in a 'lying' position, or for eight minutes in a 'standing' position. The iron can also be controlled via the internet. For this, it is necessary to have a gateway near the device, like a separate smartphone or tablet with internet access and a special app. Given all that, we decided to take a closer look at the applications for the device. There are three of them – one for iOS and two for Android. The first Android app is for when you manage the device via Bluetooth and are standing nearby, and the other one is for the gateway, which serves as an online door to your iron when you are not at home. The iOS app is for Bluetooth management. Speaking about the security of all applications, it is worth mentioning that the vendor's code is not obfuscated at all. When viewing online traffic, we found out that the Android Bluetooth application uses HTTPS, which is a sensible solution. The corresponding app for iOS does not and neither does the gateway app for Android. We decided to test the traffic for the iOS application. [![](https://securelist.com/files/2017/11/171127-hackspace-report-10.png)]() _Example of phishing attack via the application_ Once it is enabled, the application offers the user the chance to register, and then sends the data without encryption via HTTP. This gives us a very simple attack vector based on the interception of traffic between the mobile application and the vendor's server within the local network. As already mentioned, the phone also communicates with the iron using BLE. The BLE traffic is also not encrypted. After deeper investigation of the applications, we were able to control the iron by creating specific commands just from looking into what is transmitted between the devices. So, if you were a hacker, what could you do with all this knowledge? First of all if you would be able to capture the user's credentials, to pass the authorization stage in an official application and to switch off the iron or set it to 'safe mode'. It is important to note here that these applications are used for all of the vendor's smart devices, and there are quite a few. This significantly enlarges the attack surface. No need to worry if you miss the chance to intercept the authentication data. Given that the data exchange between the app and the device is not encrypted, you would be able to intercept a token transmitted from the server to the application and then create your own commands to the iron. As a result, within the local network an attacker can perform: * Identity theft (steal personal email address, username, password) * Extortion (take advantage of the ignorance of the user to enable 'safe mode' so that the user could not mechanically turn on the iron, and to demand money for disabling 'safe mode') Of course both these vectors are highly unlikely to be extensively performed in the wild, but they are still possible. Just imagine how embarrassing it would be if your private information was compromised, not as a result of an attack by a sophisticated hackers, but because of the poor security of your smart iron. ## **Smart home hub** The biggest problem with the vast majority of connected devices currently available is that most of them work with your smartphone as a separate, independent device, and are not integrated into a larger smart ecosystem. The problem is partly solved by so called smart hubs – nodes that unite in one place the data exchange between multiple separate smart devices. Although prior art in finding a secure smart hub, conducted by multiple other researchers, leaves little room for hope, we tried anyway and took a fancy smart hub with a touch screen and the ability to work with different IoT-protocols. It is universally compatible, works with ZigBee и ZWave home automation standards, and very easy to handle: according to the manufacturer, it can be set up within three minutes, using the touchscreen. [![](https://securelist.com/files/2017/11/Devices_smart_router.png)]() In addition the hub serves as a wireless Wi-Fi router. Given all the features this multi-purpose device has, being a router, range extender, access point or wireless bridge, we decided to check one of the most common and most dangerous risks related to unauthorized external access to the router. Because, if successful, it would possibly lead to full control of a user's smart home, including all connected devices. And, no surprise, our research has shown there is such a possibility. To check our assumption we created a local network, by connecting a PC, the device and one more router to each other. All network devices received their IP addresses, and we successfully scanned available ports. Our initial research has shown that, by default, there are two opened ports over WAN. The first one, port 80, is one of the most commonly used and assigned to protocol HTTP. It is the port from which a computer sends and receives web client-based communication and messages from a web server, and which is used to send and receive HTML pages or data. If opened, it means that any user can connect to port 80 and thus have access to the user's device via the HTTP protocol. The second one, port 22 for contacting SSH (Secure Shell) servers is used for remote control of the device. Attackers can gain access to a device if they obtain or successfully brute force a root password. Usually it's not an easy task to do. However, in our research we explored another interesting risky thing with the smart hub that makes this much easier. While analyzing the router, we discovered it might have problems with a very common threat risk – weak password generation. In the router system we found ELF (Executable and Linkable Format) file 'rname' with a list of names. By looking at this list and the password displayed on the screen, it became clear that device's password is generated based on the names from this file and, thus, it doesn't take long for brute force cracking. After a hard reset, the source line for passwords remained, with slightly changed symbols. However, the main password base remained the same, and that still leaves a chance to generate a password. In addition, we found that for device access a root account is constantly used. Thus, offensive users will know the login and a base part of the password, which will significantly facilitate a hacker attack. In case the device has a public IP address and the ports described above are opened, the router can be available for external access from the internet. Or, in other case, if a provider or an ISP (Internet Service Provider) improperly configures the visibility of neighboring hosts of the local network, these devices will be available to the entire local network within the same ISP. In all, we weren't surprised; just like most any other smart hubs on the market, this one provides a really vast attack surface for an intruder. And this surface covers not only the device itself, but the network it works on. And here are the conclusions which the results of our experiment have brought us to. ## **Conclusions** Based on what we've seen while doing this exercise, the vendors of many IoT-devices developing their products assume that: 1. They won't be attacked due to limited device functionality and a lack of serious consequences in the case of a successful attack. 2. The appropriate level of security for an IoT-device is when there is no easy way to communicate with the wider internet and the attacker needs to have access to the local network the device is connected to. We have to say that these assumptions are reasonable, but only until the moment when a vulnerable router or multifunctional smart hub, like the one described above, appears in the network to which all other devices are connected. From that moment, all the other devices, no matter how severe or trivial their security issues, are exposed to interference. It is easy to imagine a house, apartment or office populated with all these devices simultaneously, and also easy to imagine what a nightmare it would be if someone tried each of described threat vectors. So in answer to the question we asked ourselves at the beginning of this experiment, we can say that, based on our results at least, it is still hard to find a perfectly secure IoT-device. On the other hand, no matter which device you purchase, most likely it won't carry really severe security issues, but again, only until you connect them to a vulnerable router or smart hub. [![](https://securelist.com/files/2017/11/171127-hackspace-report-11.png)]() Keeping that and the ongoing high sales holiday season in mind we'd like to share the following advice on how to choose IoT devices: 1. When choosing what part of your life you're going to make a little bit smarter, consider the security risks. Think twice if you really need a camera-equipped robo vacuum cleaner or a smart iron, which can potentially spill some of your personal data to an unknown third-party. 2. Before buying an IoT device, search the internet for news of any vulnerability. The Internet of Things is a very hot topic now, and a lot of researchers are doing a great job of finding security issues in products of this kind: from baby monitors to [app controlled rifles](). It is likely that the device you are going to purchase has already been examined by security researchers and it is possible to find out whether the issues found in the device have been patched. 3. It is not always a great idea to buy the most recent products released on the market. Along with the standard bugs you get in new products, recently-launched devices might contain security issues that haven't yet been discovered by security researchers. The best choice is to buy products that have already experienced several software updates. 4. To overcome challenges of smart devices' cybersecurity, Kaspersky Lab has released a [beta version]() of its solution for the 'smart' home and the Internet of Things – the Kaspersky IoT Scanner. This free application for the Android platform scans the home Wi-Fi network, informing the user about devices connected to it and their level of security. When it comes to the vendors of IoT-devices, the advice is simple: collaborate with the security vendors and community when developing new devices and improving old ones. ## **P.S. 1 out of 8** There was one random device in our research, which showed strong enough security for us at least not to be worried about private data leakage or any other devastating consequences. It was a smart watch. Like most other similar devices, these watches require an app to pair them with the smartphone and use. From that moment, most of data exchange between the device and the smartphone, the app and the vendors' cloud service are reliably encrypted and, without a really deep dive into encryption protocol features or the vendor's cloud services it is really hard to do anything malicious with the device. For the pairing the owner should use the pin code displayed on the clock for successful authorization. The pin is randomly generated and is not transmitted from the clock. After entering the pin code in the app, the phone and clock create the key for encryption, and all subsequent communication is encrypted. Thus, in the case of BLE traffic interception an attacker will have to decrypt it as well. For this, an attacker will need to intercept traffic at the stage of generating the encryption key. It is apparently impossible to get user data (steps, heart rate etc.) directly from the device. Data synchronization from the clock on the phone is encrypted and, in the same form is sent to the server. Thus, data on the phone is not decrypted, so the encryption algorithm and the key are unknown. [![](https://securelist.com/files/2017/11/171127-hackspace-report-12.png)]() From our perspective this is an example of a really responsible approach to the product, because, by default the vendor of this device could also easily limit their security efforts to assuming that no one will try to hack their watches, as, even if successful, nothing serious happens. This is probably true: it is hard to imagine a hacker who would pursue an opportunity to steal information about how many steps you made or how fast your heart beats at any given moment of the day. Nevertheless, the vendor did their best to eliminate even that small possibility. And this is good, because cybersecurity is not all those boring and costly procedures which you have to implement because some hackers found some errors in your products, we think cybersecurity is an important and valuable feature of an IoT-product, just like its usability, design and list of useful functions. We are sure that as soon as IoT-vendors understand this fact clearly, the whole connected ecosystem will become much more secure than it is now.

IoT lottery: finding a perfectly secure connected device