Cybersecurity researcher Sam Sabetan yesterday went public with insecurity revelations against IoT vendor Nexx, which sells a range of “smart” devices including door openers, home alarms and remotely switchable power plugs.
According to Sabetan, he reported the bugs to Nexx back in January 2023, but to no avail.
So he decided to sound the alarm openly, now it’s April 2023.
The warning was considered serious enough by the powers-that-be that even the resoundingly if repetitiously named US Cybersecurity and Infrastructure Security Agency, or CISA, published a formal advisory about the flaws.
Sabetan deliberately didn’t publish precise details of the bugs, or provide any proof-of-concept code that would allow just anyone to start hacking away on Nexx devices without already knowing what they were doing.
But from a brief, privacy-redacted video provided by Sabetan to prove his point, and the CVE-numbered bug details listed by CISA, it’s easy enough to figure out how the flaws probably came to get programmed into Nexx’s devices.
More precisely, perhaps, it’s easy to see what didn’t get programmed into Nexx’s system, thus leaving the door wide open for attackers.
No password required
Five CVE numbers have been assigned to the bugs (CVE-2023-1748 to CVE-2023-1752 inclusive), which cover a number of cybersecurity omissions, apparently including the following three interconnected security blunders:
- Hard-coded credentials. An access code that can be retrieved from the Nexx firmware allows an attacker to snoop on Nexx’s own cloud servers and to recover command-and-control messages between users and their devices. This includes the so-called device identifier – a unique string assigned to each device. The message data apparently also includes the user’s email address and the name and initial used to register the device, so there is a small but significant privacy issue here as well.
- Zero-factor authentication. Although device IDs aren’t meant to be advertised publicly in the same way as, say, email addresses or Twitter handles, they’re not meant to serve as authentication tokens or passwords. But attackers who know your device ID can use it to control that device, without providing any sort of password or additional cryptographic evidence that they’re authorised to access it.
- No protection against replay attacks. Once you know what a command-and-control message looks like for your own (or someone else’s) device, you can use the same data to repeat the request. If you can open my garage door, turn off my alarm, or cycle the power on my “smart” plugs today, then it seems you already have all the network data you need to do the same thing again again and again, a bit like those old and insecure infrared car fobs that you could record-and-replay at will.
Look, listen and learn
Sabetan used the hardwired access credentials from Nexx’s firmware to monitor the network traffic in Nexx’s cloud system while operating his own garage door:
Today I’m unveiling my research on @GetNexx ‘s smart ecosystem: I could open any customer’s garage doors. Despite warnings, they ignored the issue. 1/4 https://t.co/9V5uuT3LLE
— Sam Sabetan (@samsabetan) April 4, 2023
That’s reasonable enough, even though the access credentials buried in the firmware weren’t officially published, given that his intention seems to have been to determine how well-secured (and how privacy-conscious) the data exchanges were between the app on his phone and Nexx, and between Nexx and his garage door.
That’s how he soon discovered that:
- The cloud “broker” service included data in its traffic that wasn’t necessary to the business of opening and closing the door, such as email addresses, surnames and initials.
- The request traffic could be directly replayed into the cloud service, and would repeat the same action as it did before, such as opening or closing the door.
- The network data revealed the traffic of other users who were interacting with their devices at the same time, suggesting that all devices always used the same access key for all their traffic, and thus that anyone could snoop on everyone.
Note that an attacker wouldn’t need to know where you live to abuse these insecurities, though if they could tie your email address to your physical address, they could arrange to be present at the moment they opened your garage door, or they could wait to turn your alarm off until they were right in your driveway, and thus use the opportunity to burgle your property.
Attackers could open your garage door without knowing or caring where you lived, and thus expose you to opportunistic thieves in your area… just “for the lulz”, as it were.
What to do?
- If you have a Nexx “smart” product, contact the company directly for advice on what it plans to do next, and by when.
- Operate your devices directly, not via the Nexx cloud-based app, until patches are available, assuming that’s possible for the devices you own. That way you will avoid exchanging sniffable command-and-control data with the Nexx cloud servers.
- If you’re a programmer, don’t take security shortcuts like this. Hardcoded passwords or access codes were unacceptable way back in 1993, and they’re way more unacceptable now it’s 2023. Learn how to use public key cryptography to authenticate each device uniquely, and learn how to use ephemeral (throw-away) session keys so that the data in each command-and-control interaction stands on its own in cryptographic terms.
- If you’re a vendor, don’t ignore bona fide attempts by researchers to tell you about problems. As far as we can see in this case, Sabetan lawfully probed the company’s code and determined its security readiness because he was a customer. On finding the flaws, he attempted to alert the vendor to help himself, to help the vendor, and to help everyone else.
No one likes to be confronted with accusations that their programming code wasn’t up to cybersecurity scratch, or that their back-end server code contained dangerous bugs…
…but when the evidence comes from someone who is telling you for your own good, and who is willing to give you some clear time to fix the problems before going public, why turn down the opportunity?
After all, the crooks spend the same sort of effort on finding bugs like this, and then tell no one except themselves or other crooks.
By ignoring legitimate researchers and customers who willingly try to warn you about problems, you’re just playing into the hands of cybercriminals who find bugs and don’t breathe a word about them.
As the old joke puts it, “The ‘S’ in IoT stands for security”, and that’s a regrettable and entirely avoidable situation that we urgently need to change.
Leave a Reply