The mechanical lock is perhaps the most fundamental, tangible, and familiar layer of security in our daily lives. People lock their doors with the expectation that these locks will keep the bad people out, but there’s a common adage in the security industry that locks are only good at keeping honest people honest. This is perhaps truer than ever in the era of the IoT “smart lock” where lock picks and bump keys can often be replaced by scripts and sniffers. This was exactly the case with an Internet-enabled lock I evaluated late last year. At that time, an anonymous attacker could physically locate and remotely control any locks connected to the vendor’s
cloud infrastructure.
Although the specific issues outlined in this blog have since been resolved, the underlying concerns regarding privacy and safety in the industry still remain. The purpose of this article is to bring awareness to the issues surrounding Internet-connected devices and the centralized cloud computing that drives IoT.
The device I’ll be talking about in this post is the
U-Tec UltraLoq, which connects to the vendor’s U-Cloud infrastructure. For the record, I notified U-Tec in early November 2019, and the issues were resolved within a week. The underlying issue in this case, a service misconfiguration, will be explained at a high-level, but the bigger focus of this research is around the risks posed by feeding data and control through a central authority.
The U-Tec UltraLoq started on
Indiegogo and is now sold directly to consumers through major retailers such as Amazon, Home Depot, and Walmart. The locks boast some advanced features including fingerprint readers and anti-peep touchscreens as well as Bluetooth and WiFi connectivity for app-based control. Of course, these Internet-connected features are convenient, but they may leave some users feeling uneasy about security. Perhaps in anticipation of these concerns,
U-Tec’s web site has an article to reassure users that “the [cloud] server does have strong security” and that users’ data “have been encrypted by the MD5 algorithm”.
My U-Tec story began with Shodan and specifically with Shodan’s MQTT data set.
First, some background on MQTT.
MQTT is a lightweight publish-subscribe protocol in which a message broker coordinates topical data exchange between connected nodes. To illustrate how the protocol can be used, think of an HVAC system that contains multiple temperature sensors (thermostats), fans which can be electronically actuated, and a monitoring application that automatically turns the fans on/off according to room temperature. The sensors and actuators are simple low-power IoT components which connect to an MQTT broker. The sensors
publish data, the monitoring app
subscribes to this data and
publishes commands to the actuators.
Data is published using descriptive and hierarchical topic names. So the thermostat in room 101 would publish data using “
buildingX/temperature/floor1/room101.” The monitoring app would subscribe to ‘
buildingX/temperature/#.’ The # acts as the wildcard that allows the app to receive temperature inputs from all the rooms.
The risk of using MQTT arises when it is deployed without proper authentication and authorization schemes. Without this, anyone who can connect to the broker can leak sensitive data and potentially influence kinetic systems. An unauthorized user that gains access to the MQTT broker can easily guess topic names and use # to subscribe to all kinds of topics to obtain data transiting the broker.
Personal information exposed through public MQTT data
The folks at Shodan have been using these wildcard queries to collect data about MQTT brokers exposed to the public Internet. Although Shodan does not store individual messages received, it does give the ability to search discovered topic names across more than 83,000 brokers. I tested various MQTT search terms to see how many hits they yield. One server in particular caught my attention because it had pages and pages of MQTT topic names and repeatedly came up in searches including references to ‘lock’ and free email providers like ‘gmail.com.’
Figure 1: Redacted excerpt of data from Shodan.
This was an Amazon hosted broker with a list of topic names including personal email addresses and other data seemingly related to connected locks. I queried the server myself with Linux command line tools (e.g. mosquitto_sub), and I was instantly inundated with PII apparently from all over the world. The data included email and IP addresses associated with locks and timestamped records of when the locks where opened and closed, among other things.
The next step was to better understand the scope of the problem by purchasing an UltraLoq to test.
The lock, which is battery powered, maintains a Bluetooth pairing with a bridge device connected to WiFi. With the lock in hand, I paired it with the WiFi bridge and proceeded to monitor messages via MQTT while controlling the lock over WiFi.
Figure 2: Confirmation that the server has live customer data (redacted).
After a few lock/unlock cycles, I confirmed a repeating message flow on the unlock process. I then prepared a Python script to test replay these messages, and I confirmed that it worked to open the lock.
I found that attackers could easily steal “unlock tokens” in bulk or from specific devices knowing only the MAC address.
The MQTT data correlates email addresses, local MAC addresses, and public IP addresses suitable for geolocation. This is enough detail to precisely identify an individual. The device is also broadcasting the MAC address to anyone within radio range.
This means that an anonymous attacker would also be able to collect identifying details of any active U-Tec customers including their email address, IP address, and wireless MAC addresses.
- This is enough to identify a specific person along with their household address.
- If the person ever unlocks their door with the U-Tec app, the attacker will also now have a token to unlock the door at a time of their choosing.
Similarly, an attacker could take a disruptive approach by sending spoofed messages preventing the legitimate lock owner from connecting.
On November 10, I opened an incident with U-Tec pointing them to the exposed service and explaining that this creates a large danger for end-users. They responded within 10 hours and told me the following:
We have token authorize on the devices, Unauthorized users will not be able to open the door, please don’t worry.
At this point, I clarified that I had already demonstrated the ability to do this attack and further provided them with a screenshot from Shodan including active customer email addresses leaked in the form of MQTT topic names. U-Tec’s response was again relatively fast (within a day) and had the following to say:
I confirmed with our engineers, they respond to me.
1. We have close the port 1883, the port 8883 is an authenticated port.
2. We have turned off non-authenticated user access.
3. We have added some rules to the subscription and delivery features, now non-authenticated users can't subscribe.
4. For the email issue, they will fix it in the next app upgrade.
This was a definite improvement but did not actually resolve the issues. The key problem here is that they focused on user authentication but failed to implement user-level access controls. I demonstrated that any free/anonymous account could connect and interact with devices from any other user. All that was necessary is to sniff the MQTT traffic generated by the app to recover a device specific username and a MD5 digest which acts as a password.
Figure 3: Sniffing an account password with HTTP Canary.
U-Tec’s engineers went quiet for a few days but then came back to announce that user isolation had been implemented. I confirmed that I could no longer publish messages across accounts and promptly disconnected the lock and packed it away in the basement. Around this time, I also learned that
Pen Test Partners had reported critical failings at every level months before I had heard of U-Tec.
Smart locks are not the only issue. Why awareness of MQTT and IOT risks is important.
In the time since working with U-Tec, I continued my research into exposed MQTT systems and have identified countless industrial IoT network exposures including vehicle tracking, taxi dispatch, lottery kiosks, building management systems, and more. Many of these systems were operated by device makers providing services back to their customers. In one case, it was a European equipment provider running a monitoring center for products they’ve sold to compressed natural gas (CNG) filling stations. In another instance, an educational service provider’s network leaked detailed information about when individual students arrived at and left from grade school.
With new and unvetted cloud-enabled devices coming to market each day, consumers must be aware of the risks. We require that vehicles on the highway comply with safety standards and undergo emissions tests to keep the environment safe, but there is no such analogy for Internet devices on the information superhighway. People have some expectations that automakers have taken reasonable precautions to ensure that vehicles do not pose undue risk to our highways or our environment. The same cannot be said for devices operating on the Internet and the risk posed to device owners and the Internet at large.
Even with safety-critical systems like locks and furnaces, there is little in the way of requirements to make the products secure, and there is even less security oversight. As we’ve seen with
Mirai and other IoT botnets, devices on the Internet do not even need to be safety critical to wreak havoc when they fail. Mirai and others have amassed huge armies of compromised devices which they can then use to disrupt society and extort businesses. These botnets have proven themselves capable of generating unbelievable loads of traffic, but it is likely a small drop in the bucket of what is possible from a successful vendor compromise.
In this situation, I see a few paths toward improvement.
Broadly speaking, the solution to this problem is to realign the incentives associated with producing a secure system. Organizations will never focus on security if they don’t see it as contributing to their bottom line. This may be the result of better-informed consumers or through direct government action to impose safety requirements and levy fines in response to security lapses. Efforts like Mudge’s Cyber Independent Testing Laboratory (CITL) work towards this first goal, while some governments (including the state of California) have worked to ban insecure practices like default passwords. Although these developments are moves in the right direction, there is a huge lingering question about whether this will be enough to course correct.
As a security researcher, my goal is to continue working with vendors to correct issues as I find them and continue bringing broader awareness to worrisome trends in technology.
