Belkin Wemo Smart Plug V2 – the buffer overflow that won’t be patched – Source: nakedsecurity.sophos.com

Researchers at IoT security company Sternum dug into a popular home automation mains plug from well-known device brand Belkin.

The model they looked at, the Wemo Mini Smart Plug (F7C063) is apparently getting towards the end of its shelf life, but we found plenty of them for sale online, and detailed advice and instructions on setting them up on Belkin’s site.

Old (in modern terms) though they might be, the researchers noted that:

Our initial interest in the device came from having several of these lying around our lab and used at our homes, so we just wanted to see how safe (or not) they were to use. [… T]his appears to be a pretty popular consumer device[; b]ased on these numbers, it’s safe to estimate that the total sales on Amazon alone should be in the hundreds of thousands.

Simply put, there are probably lots of people who have bought and plugged these things in, and use them to control electrical outlets in their homes.

A “smart plug”, simply put, is a power socket that you plug into an existing wall socket and that interposes a Wi-Fi-controlled switch between the mains outlet on the front of the wall socket and an identical-looking mains outlet on the front of the smart plug. Think of it like a power adapter that instead of swapping, say, a round Euro socket into a triangular UK one, swaps, say, a manually-switched US socket into an electronically-switched US socket that can be controlled remotely via an app or a web-type interface.

The S in IoT…

The problem with many so-called Internet of Things (IoT) devices, as the old joke goes, is that the it is the letter “S” in “IoT” that stands for security…

…meaning, of course, that there often isn’t as much cybersecurity as you might expect, or even any at all.

As you can imagine, an insecure home automation device, especially one that could allow someone outside your house, or even on the other side of the world, to turn electrical appliances on and off at will, could lead to plenty of trouble.

We’ve written about IoT insecurity in a wide range of different products before, from IoT kettles (yes, really) that could leak your home Wi-Fi password, through security cameras that crooks can use to keep their eye on you instead of the other way around, to network attached disk drives at risk of getting splatted by ransomware directly across the internet.

In this case, the researchers ended up finding a remote code execution hole in the Wemo Mini Smart Plug back in January 2023, reporting it in Februry 2023, and getting a CVE number for it in March 2023 (CVE-2023-27217).

Unfortunately, even though there are probably loads of these affected devices in use in the real world, Belkin apparently said that it considered the device to be “at the end of its life” and that the security hole will therefore not be patched.

(We’re not sure how convincing this sort of “end of life” dismissal would be if the device turned out to have an electrical flaw, such as the possibility of overheating and emitting noxious chemicals or setting on fire, but it seems that faults in low-voltage electronic, or digital, components can be ignored, even if they could lead to a cyberattacker switching the device on and off at will.)

When friendly names are your enemy

The problem that the researchers discovered was a good old stack buffer overflow in the part of the device software that allowed you to change the so-called FriendlyName of the device – the text string that is displayed when you connect to it with an app on your phone.

By default, these devices start up with a friendly ame along the lines of Wemo mini XYZ, where XYZ denotes three hexdecimal digits that we’re guessing are chosen pseudorandomly.

That means that if even you own two or three of these devices, they’ll almost certainly start out with different names so you can set them up individually, but you’ll also probably want to rename them so they’re easier to remember in future, such as TV power, Laptop charger or Raspberry Pi Server.

The Belkin programmers (or, more precisely, the programmers of the code that ended up in these Belkin-branded devices, who might have supplied smart plug software to other brand names, too) apparently reserved 68 bytes of temporary storage to keep track of the new name when you renamed the device.

But they forgot to check that the name you supplied would fit into that 68-byte slot.

Instead, they assumed that you’d use their official phone app to perform the device renaming process, and thus that they could control the amount of data sent to the device in the first place, and thus head off any buffer overflow that way.

Ironically, they took great care not merely to keep you to the 68-byte limit required for the device itself to behave properly, but also to restrict you to typing in just 30 characters.

We all know why letting the client side do all the error checking, rather than of checking instead (or, better yet, as well) at the server side, is a terrible idea:

• The client code and the server code might drift out of conformity. Future client apps might decide that 72-character names would be a nice option, and start sending more data to the server than it can safely handle. Future server-side coders might notice that no one ever seems to use the full 68 bytes reserved, and unilterally decide that 24 should be more than enough.
• An attacker could choose not to bother with the app. By generating their own requests, they can trivially bypass any security checks that rely on the app alone.

The researchers were quickly able to try ever-longer names to the point that they could crash the Wemo device at will by writing over the end of the memory buffer reserved for the new name, and corrupting data stored in the bytes that immediately followed.

Corrupting the stack

Unfortunately, in a stack-based operating system, most software ends up with temporary memory buffers that are closely followed by a block of memory that tells the program where to go when it’s finished what it’s doing right now.

Technically, these “where to go next” data chunks are known as return addresses, and they’re automtically saved when a program calls what’s known as a function, or subroutine, which is a chunk of code (for example, “print this message” or “pop up a warning dialog”) that you want to be able to use in several parts of your program.

The return address is magically recorded every time the subroutine is used, so that the computer can automatically “unwind” its path to get back to where the subroutine was called from, which could be different every time it is activated.

As you can imagine, if you can trample on that magic return address before the subroutine finishes running, then when it does finish, it will trustingly, but unknowingly, “unwind” itself to the wrong place.

With a bit (or perhaps a lot) of luck, an attacker might be able to predict in advance how to trample on the return address creatively, and thereby misdirect the program in a deliberate and malicious way.

Instead of merely crashing, the misdirected program could be instructed to run code of the attacker’s choice, thus delivering what’s known as a remote code execution exploit.

Two common defences help protect against exploits of this sort:

• Address space layout randomisation, also known as ASLR. The operating system deliberately loads programs at slightly different memory locations every time they run, thus making it harder for attackers to guess how to misdirect buggy programs in a way that ultimately gets control instead of merely crashing the code.
• Stack canaries, named after the birds that miners used to take with them underground because they would faint in the presence of methane, thus “detecting” the risk of explosion. The program deliberately inserts a known-but-random block of data just in front of the return address, so that a buffer overflow will unavoidably and detectably overwrite the “canary” before it gets as far trampling on the return address.

To get thir exploit to work quickly and reliably, the researchers needed to force the Wemo plug to turn ASLR off, but with lots of tries in real life, an attacker might nevertheless get lucky, guess correctly at the addresses in use, and get control anyway.

But the researchers didn’t need to worry about the stack canary problem, because the buggy app had been compiled from its source code with the “insert canary-checking safety instructions” feature turned off.

(Canary-protected programs are typically slightly bigger than unprotected ones because of the extra code needed in every subroutine to do the safety checks.)

What to do?

• If you’re a Wemo Smart Plug V2 owner, make sure you haven’t configured your home router to allow the device to be accessed from “outside”, over the internet.
• If you’ve got a router that supports Universal Plug and Play, also known as UPnP, make sure that it’s turned off. UPnP makes it notoriously easy for internal devices to get opened up to outsiders automatically, by mistake.
• If you’re a programmer, avoid turning off software safety features (such as stack protection or stack canary checking) just to save a few bytes. If you are genuinely running out of memory, look to reduce your footprint by improving your code or removing features rather than by diminishing security so you can cram more in.