The Need for Better Built-in Security in IoT Devices
As manufacturers develop Internet of Things (IoT) devices that integrate with widely popular internet-based applications, more and more users see the value in purchasing such devices. Ease of integration becomes an incentive for users to consider adding these products to their network of devices. But while the ease of use can be enticing, these products can also be susceptible to security issues that could introduce far-reaching problems.
To see just how safe and secure IoT devices are and to what extent an attacker can manipulate an IoT device, we tested the built-in security of a particular IoT device type — internet-connected speakers.
A Sound Hack
For our case study titled The Sound of a Targeted Attack, we tested a fairly popular IoT device and discovered that it exposed user data along with other pertinent information that can be used in an attack. In the case study, we used the Sonos Play:1 as our test unit and also looked into the Bose SoundTouch. After the tests, we reached out to Sonos, which responded quickly to fix the security gaps. The gaps addressed include a denial-of-service (DoS) bug which now returns an HTTP error code 412 (Precondition failed). A more detailed account of the updates made by Sonos can be found in the case study. We also reached out to Bose and are currently waiting for their response.
Whereas previous studies focused on seizing control of speakers like the Amazon Echo and Google Home, the results of our case study led to unique findings. These include security gaps that resulted from a simple open port that gave anyone on the internet access to the device and user information. The first glaring finding was access to email addresses that are linked to music streaming services synced with the device. Another was access to a list of devices as well as shared folders that were on the same network as the test device. We also got BSSID information that, paired with an existing API that queries specific BSSIDs, gave us the approximate location of access points used by the test unit. And lastly, we were able to see the device’s activities, such as current songs being played, control the device remotely, as well as play music through URI paths.
The implications of these gaps go beyond the loss of device control. Internet-connected speakers — and in turn, IoT devices — may be exposing information that can be used by attackers in malicious schemes. By first breaking into the case test device, a Sonos Play:1 speaker, to spot security issues, we were able to come up with plausible attack scenarios that can be used not just against home users but also against enterprise networks. And while the test unit used was an internet-connected speaker and updates for Sonos Play:1 have been rolled out, similar issues in other IoT devices can exist and give attackers the same upper hand.
Prerequisites for an Attack on IoT Devices
Regardless of the target IoT device, attackers make use of several elements when launching an attack. In any scenario, an attacker will utilize information that is accessible as well as exploitable. Listed below are prerequisites for IoT attack scenarios, which we formulated based on our tests on the Sonos speakers:
- Exposed device — As shown in our research on hacking industrial robots and exposed devices in U.S. and Western European cities, an attacker can look for exposed devices over the internet through search engines like Shodan. At the time of the study, we were able to see around 4,000 to 5,000 exposed Sonos speakers.
- Existing insecurity — A device may have a security lapse that gives an attacker something to take advantage of. This may come in the form of a lack of authentication process, an unpatched vulnerability, or information leakage from an external source. For the test unit, it was its open access to user information, among other things.
- Exploitable device capabilities – Given that IoT devices vary in form and function, certain devices may have unique capabilities which attackers can exploit. In the case of an internet-connected speaker, the attacker could utilize the ability to play music from an online source.
- Publicly available personally identifiable information (PII) – These can come from legitimate sources such as online search tools or social media, as well as from data breach information made public. In the case study, we found 727 unique email addresses that could be loaded into open source intelligence tools such as Maltego. We also saw several email accounts connected to previously reported breaches such as River City Media, LinkedIn, and last.fm.
Using the above attack prerequisites found in the case study, we were able to formulate three specific attack scenarios utilizing the internet-connected speakers. Again, any device with the same or similar vulnerability can be at risk of experiencing these attacks.
An attacker can send a customized phishing email based on the target’s musical preference.
Through an Nmap scan, we observed that the application running the Sonos Play:1 test device communicated with TCP/1400. Following that led us to an unauthenticated URI page.
Figure 1. Services shown from Nmap scan
The URI led to a site which was used to populate the applications that control the device and also contained information exposed without requiring authentication. It also included information about tracks currently being played, libraries connected to the device, devices used to control the speakers, devices that were in the same network as the speakers, as well as email addresses associated with audio streaming services synced with the device.
This exposure is not limited to home users. In a workplace scenario, an exposed device which identifies and lists down other IoT devices connected to the same network can give an attacker plenty of information to work on. Bad actors could find machines such as printers with existing vulnerabilities and use that to gather further information or as an entry point.
Figure 2. Contents of the status page of the Sonos
Aside from finding an entry point, an attacker could use the exposed information for spear-phishing. By studying the target’s musical preference based on the tracks being played, an attacker can tailor-fit an email and send it to the email address linked to the target’s music streaming account. This increases the success rate of schemes to compromise businesses too.
In a way, any IoT device which leaks personal or network information can give an attacker leverage for a successful attack.
An attacker can track down where the target lives and find out if they’re home.
This can be done using a website that compounds multiple sources of Wi-Fi geolocation. In the case study, we queried specific BSSIDs related to the test device and mapped out the location. The information came from the wireless access points (WAPs) the device tried to access during installation.
Figure 3. Address mapped with SSIDs
After determining the location of the target, an attacker can monitor the presence data available from the device, such as the times when the speaker is activated and deactivated. The pattern can more or less tell the attacker when the target is awake, asleep, or even when the target is not around.
This hybrid attack involving cyber and physical elements presents new dangers that home and enterprise users should be aware of. Devices leaking presence data not only make users easier to predict — they can also put the user at physical risk.
An attacker can play a fake recorded message and trick the target into downloading malware.
Using information found on the URI path like model numbers and serial numbers, an attacker can disrupt the user’s device, halt any song currently playing, and play a crafted status message containing misleading information.
Similar to the first attack scenario, an attacker could then send tailor-fit emails to accounts tied to the music streaming applications. This time, the email could contain a fake message from the manufacturer along with a link that downloads malware instead of a software update.
To make the email more believable, the attacker can search the target’s email address against online search tools that can locate people based off of public information, and add personalized details to the pre-recorded message. This scheme poses great risk to businesses that use internet-connected speakers or have Bring Your Own Device (BYOD) programs.
With a different IoT device, attackers can get creative and exploit other functions. Imagine what they could do if they had access to security cameras, a router, the thermostat, or even a FitBit.
Assuming that an IoT device inherently protects a user’s personal information and is safe to introduce to a network is risky. Cybercriminals will soon be exploring new ways to abuse IoT devices. As the production and consumption of IoT devices increase, the lack of built-in security becomes more and more of an issue. With all these devices connected to each other via networks and the internet, it could take just one security gap to compromise a user – or an entire network. From exposed features that could be exploited to devices leaking personal information on the internet, product insecurities have led to attacks and will continue to do so.
One of the more recent security incidents involved brands of smartwatches for children.
They were found to have vulnerabilities that can allow attackers to track the wearer’s movement, eavesdrop on conversations, and communicate with the wearer. This shows that even popular devices can fall short or leave massive gaps in terms of ensuring their products’ security.
The problem of unsecured internet-connected devices is not limited to home users but also extends to workplace environments when seemingly safe IoT devices are introduced into the company network, as was shown in the attack scenarios. Whether these devices are installed to improve productivity or are simply brought to work by employees, the risk of having an exposed and unsecured device should not be taken lightly.
Mitigating IoT Insecurities
Given that IoT devices need to be connected to the internet, manufacturers have to ascertain that what they produce poses very minimal risk to the buying public. With all the information fed to internet-connected devices, it is considerably difficult for users to know if these are protected properly by the built-in security that comes with the product. Although consumers are also tasked to employ proper security practices on their end (like applying fixes), manufacturers should also make sure that what they produce pose little to no security risk to their customers.
While IoT devices are connected to the internet, they should never be exposed. In the case of the test device, manufacturers should make sure that ports connecting to the devices cannot be accessed directly from the internet. Manufacturers should also secure data that’s being stored or compiled by these IoT devices and conduct security audits — including regularly reading public forums discussing their products.
At the same time, consumers and enterprise IT administrators should not rely entirely on manufacturers to do all the heavy lifting. Users should check their routers for rules that might provide outside access to devices and folders on the network. If access is needed, it should be limited to as few devices as possible. They should enable password protection on all devices if possible and replace default passwords immediately with stronger ones.
Users can also visit websites like WhatsMyIP to scan their network for any open ports. They should also make sure that the firmware of their IoT devices is updated as well. Businesses with BYOD programs must be aware of what internet-connected devices are being used by employees at work and ensure security guidelines are provided.
As we move to a more internet-connected world, manufacturers, consumers, and IT administrators must exercise a security-first mindset. With all the personal data managed and kept by IoT devices, securing them should be just as important as ease of use and integration with applications that run them.
To find out how we came up with the attack scenarios, read the full case study titled The Sound of a Targeted Attack. It also includes a rundown of exposed services our test unit had, the types of information that were made publicly available due to security gaps, and a Shodan query of exposed internet-connected speakers.