Critical security flaw is exposing older Wemo Smart Plugs to hackers

Posted:
in General Discussion
Researchers found a security flaw in an older version of the Wemo Mini Smart Plug that involved changing its name -- and Belkin isn't going to fix it.

Wemo Smart Plugs have a flaw
Wemo Smart Plugs have a flaw


The Wemo Mini Smart Plug is designed to offer convenient remote control over lights and basic appliances, such as fan lamps, through a mobile app. The application utilizes Wi-Fi for communication and seamlessly integrates with HomeKit and other smart home ecosystems.

Among other functions, the app lets people change the device name. The length is limited to 30 characters or less, but only the app enforces that rule.

However, through reverse engineering, the security experts at Sternum discovered a method to circumvent the character limit, thereby triggering a buffer overflow. They subsequently named this vulnerability "FriendlyName."

A buffer overflow happens when there's too much information put into a storage area (buffer) that it can't handle. It's like pouring more water into a cup than it can hold, causing it to overflow.

That can lead to unexpected results in computer systems because the extra information can overwrite or change nearby data. Hackers can use a buffer overflow to gain unauthorized access or cause malfunctions in a computer program.

Accessing the firmware
Accessing the firmware


The researchers from Sternum examined the smart plug's firmware and used it to change the device's name to one that was longer than the app's rule of 30 characters. The resulting overflow allowed them to issue commands to the device and control it.

In the hands of a malicious hacker, that could lead to data theft or possibly controlling other devices plugged into the Wemo device.

The team contacted Belkin to inform the company of the security flaw. However, Belkin said it wouldn't fix the vulnerability because the Wemo Smart Plug V2 is at the end of its life.

The current Wemo Smart Plug is version 4.

How to protect yourself from "Friendlyname"

Sternum says people who own one of these plugs shouldn't connect them to the internet. They also shouldn't be allowed to connect to sensitive devices on a home network.

Considering the lack of future updates for version 2 of the Wemo device, there is also the option to explore newer smart plug alternatives if they desire ongoing support and enhancements.

Read on AppleInsider

Comments

  • Reply 1 of 17
    diz_geekdiz_geek Posts: 57member
    Absolutely inexcusable to not fix this. There are enough of these plugs functioning perfectly fine to consider these a “dead product” for a security flaw fix. 
    edited May 2023 mSakFileMakerFellerwatto_cobra
  • Reply 2 of 17
    jbdragonjbdragon Posts: 2,311member
    So WEMO just expects people to upgrade smart devices every couple of years?  As they just stop all support?    Well, I guess I was ahead of the curve and pulled all my WEMO smart plugs.  I moved over to Meross.  I have 5 WEMO plugs just sitting around not being used.  I do know who to avoid.
    watto_cobra
  • Reply 3 of 17

    Don’t you have to be on the WiFi network to do this and then don’t you already have a much bigger problem?


    appleinsideruserwatto_cobra
  • Reply 4 of 17
    mSakmSak Posts: 22member
    diz_geek said:
    Absolutely inexcusable to not fix this. There are enough of these plugs functioning perfectly fine to consider these a “dead product” for a security flaw fix. 

    Totally agree. This is absolutely inexcusable. Given that a quick firmware upgrade will protect others (and also with the potential to reduce e-waste) Belkin should be obligated to fix this. This is one reason I'm very wary of so-called "smart" devices because iteration after iteration they seem to quickly lose life. I mean, when has an ordinary electric outlet come to end of life so quickly? Not typically and it can be in one's home for decades without needing to change it. But these e-devices? yeah, the plug aspect may work but its main reason to be goes kaput.

    Not acceptable.
    diz_geekFileMakerFellerwatto_cobra
  • Reply 5 of 17
    danoxdanox Posts: 2,848member
    A perfect example of why Apple needs to get back into routers. (new AirPort Express mesh routers for the new generation). 
    watto_cobra
  • Reply 6 of 17
    jamnapjamnap Posts: 89member
    I have about a dozen of these Wemo plugs purchased over the last four years (the latest being 2 with Thread).  But how do I actually identify the flawed ones?  Is it the larger unit as shown in the article (mine has no V2 designation). Or does the V2 refer to firmware version?  I definitely will trash/pull off network the bad ones but the article should be more specific on how to identify them. I did just check Belkin website but found no info regarding this newly discovered security flaw.
    watto_cobra
  • Reply 7 of 17
    dewmedewme Posts: 5,362member
    It sounds like this exploit requires UPnP to be enabled. It's been a standard best practice to disable UPnP for a decade. If your router or security gateway comes with UPnP enabled by default, consider turning it off unless you know for certain that you need it enabled, which is most likely for some specific online games.

    appleinsideruserwatto_cobra
  • Reply 8 of 17
    eightzeroeightzero Posts: 3,063member
    danox said:
    A perfect example of why Apple needs to get back into routers. (new AirPort Express mesh routers for the new generation). 
    This among other reasons. Seems like a natural product line. And sell VPN services for...you know...Apple-level privacy. 
    watto_cobra
  • Reply 9 of 17
    mpantonempantone Posts: 2,040member
    danox said:
    A perfect example of why Apple needs to get back into routers. (new AirPort Express mesh routers for the new generation). 
    Apple got out of the router business, most likely for a variety of reasons. My guess is that profitability was one, home networking devices are a low margin commodity marketplace. Another is that their biggest value add is probably security which probably isn't enough in the eyes of Joe Consumer to pick an AirPort over some cheapo device.

    WiFi routers simply don't have enough differentiated features for Apple to stand out from the rest of the marketplace.

    That's probably why they bailed on this market.

    In any case, Apple cannot fix all of the problems of these poorly designed and poorly supported IoT devices. If a big, recognized company like Belkin won't support their brands, why would we expect other big companies to be any different. We've already seen Google abandon tons of hardware.

    Even the best designed Apple router won't fix a buffer overflow vulnerability in a moldy old smart plug.
    edited May 2023 jamnapwatto_cobra
  • Reply 10 of 17

    Don’t you have to be on the WiFi network to do this and then don’t you already have a much bigger problem?


    Yup. And, er, how does this cause an issue for other devices on your LAN? Nope, it could just unexpectedly control the power of the device plugged into it. Siri cocks that up often enough for this to be not really a big deal. Eek, did I say that out loud?
    watto_cobra
  • Reply 11 of 17
    dewmedewme Posts: 5,362member

    Don’t you have to be on the WiFi network to do this and then don’t you already have a much bigger problem?


    Yup. And, er, how does this cause an issue for other devices on your LAN? Nope, it could just unexpectedly control the power of the device plugged into it. Siri cocks that up often enough for this to be not really a big deal. Eek, did I say that out loud?
    This is where universal plug & play (UPnP) comes into the picture. If UPnP is enabled on your network it provides a way for a compromised device to discover and communicate with other devices on your network that expose network services through UPnP. As in most of these security vulnerabilities the attack scenarios are often in the realm of "possible" and "potential" threats that a knowledgable and motivated attacker would have to spend a considerable amount of time formulating. In the world of cybersecurity anything that's a possible threat to someone is assumed to be an existential threat to everyone, often for very good reasons.
    appleinsideruser
  • Reply 12 of 17
    dewme said:

    Don’t you have to be on the WiFi network to do this and then don’t you already have a much bigger problem?


    Yup. And, er, how does this cause an issue for other devices on your LAN? Nope, it could just unexpectedly control the power of the device plugged into it. Siri cocks that up often enough for this to be not really a big deal. Eek, did I say that out loud?
    This is where universal plug & play (UPnP) comes into the picture. If UPnP is enabled on your network it provides a way for a compromised device to discover and communicate with other devices on your network that expose network services through UPnP. As in most of these security vulnerabilities the attack scenarios are often in the realm of "possible" and "potential" threats that a knowledgable and motivated attacker would have to spend a considerable amount of time formulating. In the world of cybersecurity anything that's a possible threat to someone is assumed to be an existential threat to everyone, often for very good reasons.
    I guess those other discovered devices need a vulnerability too. And so it goes on... But the initial attack needs to be from inside your LAN. So does that mitigate the risk?

    Once they have a toe-hold on your LAN, UPnP lets a device establish an inbound route through your router. But if the device is going to phone home anyway, how is UPnP making it worse?
  • Reply 13 of 17
    dewmedewme Posts: 5,362member
    dewme said:

    Don’t you have to be on the WiFi network to do this and then don’t you already have a much bigger problem?


    Yup. And, er, how does this cause an issue for other devices on your LAN? Nope, it could just unexpectedly control the power of the device plugged into it. Siri cocks that up often enough for this to be not really a big deal. Eek, did I say that out loud?
    This is where universal plug & play (UPnP) comes into the picture. If UPnP is enabled on your network it provides a way for a compromised device to discover and communicate with other devices on your network that expose network services through UPnP. As in most of these security vulnerabilities the attack scenarios are often in the realm of "possible" and "potential" threats that a knowledgable and motivated attacker would have to spend a considerable amount of time formulating. In the world of cybersecurity anything that's a possible threat to someone is assumed to be an existential threat to everyone, often for very good reasons.
    I guess those other discovered devices need a vulnerability too. And so it goes on... But the initial attack needs to be from inside your LAN. So does that mitigate the risk?

    Once they have a toe-hold on your LAN, UPnP lets a device establish an inbound route through your router. But if the device is going to phone home anyway, how is UPnP making it worse?
    Rather than trying to explain it: https://www.varonis.com/blog/what-is-upnp 

    As I mentioned, many of these vulnerabilities are based on the "possibility" of someone gaining access to your system due to a discovered issue, which in the case and many others, is the identification of code that is vulnerable to attack. Many of these vulnerabilities exist in code that has been thoroughly tested from a functional standpoint - but not from a security standpoint.

    The exact issue with this specific vulnerability is due to the use of a C/C++ string copy function (strcpy) that does not inherently verify that the memory space allocated for the copied string is large enough to hold the string being copied. The developer obviously coded and verified that the failure condition could never be encountered through "normal" user interaction and took steps to protect themselves but obviously failed to consider every possible way the string could exceed the maximum size.

    Is this a bug? From a design-for-security (DFS) perspective it is, but not all developers and development organizations followed DFS strategies when the code was written and tested and/or the safeguards they put in place were incomplete. The code was written tested, and deemed to be fully functional. But in the face of security threats, being fully functional is no longer good enough. It has to be secure too. (It also has to be "safe" from a number of other perspectives like thread safe, not leak memory, not leak private information, handle exceptions appropriately, handle locality issues like language, date & time formats, and units of measure correctly, etc., too, so being fully functional plus secure isn't even good enough.) 

    How common is this specific issue? Very common. These kinds of vulnerabilities are everywhere. All you have to do is go looking for them, as the team that discovered the Wemo issue did. There was nothing obvious to draw them to the particular Wemo model in question. All they had to do was examine its code, look for instances where known "unsafe" functions were being used, and see whether these unsafe functions could be exploited. It's very likely that many other devices from many different vendors would have yielded similar results. This is the nature of the security beast - if you think something is safe because it hasn't been identified as being vulnerable, it's more likely that the product simply has not been scrutinized for vulnerabilities. Over time this situation has improved, but we are nowhere near the point of saying that everything out there has actually been put to the test from a security standpoint. It hasn't.

    Still, there's a huge difference between possibility and probability. The probability that a particular user of these Wemo smart plugs is going to be impacted is very remote. From a probability standpoint I think it is far more likely that a user of devices other than the one in question here would be impacted through an attack mechanism that has not yet been publicly identified, if for no other reason that this particular issue requires some enabling conditions that some users will now mitigate by shutting down at least one of the potential ingress mechanisms. There has to be some kind of reward for the attacker to go after someone, and in all likelihood you and I are not worth the effort.
    appleinsiderusermike1
  • Reply 14 of 17
    dewme said:
    dewme said:

    Don’t you have to be on the WiFi network to do this and then don’t you already have a much bigger problem?


    Yup. And, er, how does this cause an issue for other devices on your LAN? Nope, it could just unexpectedly control the power of the device plugged into it. Siri cocks that up often enough for this to be not really a big deal. Eek, did I say that out loud?
    This is where universal plug & play (UPnP) comes into the picture. If UPnP is enabled on your network it provides a way for a compromised device to discover and communicate with other devices on your network that expose network services through UPnP. As in most of these security vulnerabilities the attack scenarios are often in the realm of "possible" and "potential" threats that a knowledgable and motivated attacker would have to spend a considerable amount of time formulating. In the world of cybersecurity anything that's a possible threat to someone is assumed to be an existential threat to everyone, often for very good reasons.
    I guess those other discovered devices need a vulnerability too. And so it goes on... But the initial attack needs to be from inside your LAN. So does that mitigate the risk?

    Once they have a toe-hold on your LAN, UPnP lets a device establish an inbound route through your router. But if the device is going to phone home anyway, how is UPnP making it worse?
    Rather than trying to explain it: https://www.varonis.com/blog/what-is-upnp 

    As I mentioned, many of these vulnerabilities are based on the "possibility" of someone gaining access to your system due to a discovered issue, which in the case and many others, is the identification of code that is vulnerable to attack. Many of these vulnerabilities exist in code that has been thoroughly tested from a functional standpoint - but not from a security standpoint.

    The exact issue with this specific vulnerability is due to the use of a C/C++ string copy function (strcpy) that does not inherently verify that the memory space allocated for the copied string is large enough to hold the string being copied. The developer obviously coded and verified that the failure condition could never be encountered through "normal" user interaction and took steps to protect themselves but obviously failed to consider every possible way the string could exceed the maximum size.

    Is this a bug? From a design-for-security (DFS) perspective it is, but not all developers and development organizations followed DFS strategies when the code was written and tested and/or the safeguards they put in place were incomplete. The code was written tested, and deemed to be fully functional. But in the face of security threats, being fully functional is no longer good enough. It has to be secure too. (It also has to be "safe" from a number of other perspectives like thread safe, not leak memory, not leak private information, handle exceptions appropriately, handle locality issues like language, date & time formats, and units of measure correctly, etc., too, so being fully functional plus secure isn't even good enough.) 

    How common is this specific issue? Very common. These kinds of vulnerabilities are everywhere. All you have to do is go looking for them, as the team that discovered the Wemo issue did. There was nothing obvious to draw them to the particular Wemo model in question. All they had to do was examine its code, look for instances where known "unsafe" functions were being used, and see whether these unsafe functions could be exploited. It's very likely that many other devices from many different vendors would have yielded similar results. This is the nature of the security beast - if you think something is safe because it hasn't been identified as being vulnerable, it's more likely that the product simply has not been scrutinized for vulnerabilities. Over time this situation has improved, but we are nowhere near the point of saying that everything out there has actually been put to the test from a security standpoint. It hasn't.

    Still, there's a huge difference between possibility and probability. The probability that a particular user of these Wemo smart plugs is going to be impacted is very remote. From a probability standpoint I think it is far more likely that a user of devices other than the one in question here would be impacted through an attack mechanism that has not yet been publicly identified, if for no other reason that this particular issue requires some enabling conditions that some users will now mitigate by shutting down at least one of the potential ingress mechanisms. There has to be some kind of reward for the attacker to go after someone, and in all likelihood you and I are not worth the effort.
    Great DFS write up. Thanks.

    As for UPnP, it doesn’t let devices discover other LAN devices. It lets them reveal themselves to the internet via port forwarding. So, it seems there’s a subtlety at play here about how the first assault is completed. Anyway, yup, turn off UPnP unless you know you need it. 
  • Reply 15 of 17
    jayweissjayweiss Posts: 69member
    I recently dumped all my WEMO products after they all failed to connect for the 5th time. After resetting all of the switches and plugs I was unable to reconnect them to the WEMO app. 

    I replaced all of them with Lutron Caseta switches and plugs since I already had one Caseta switch installed. I needed a No Neutral Caseta switch since one switch box has no neutral wire. A wired Caseta Hub is needed for these products. Adding the new products was fast and easy. 


  • Reply 16 of 17
    eightzeroeightzero Posts: 3,063member
    jayweiss said:
    I recently dumped all my WEMO products after they all failed to connect for the 5th time. After resetting all of the switches and plugs I was unable to reconnect them to the WEMO app. 

    I replaced all of them with Lutron Caseta switches and plugs since I already had one Caseta switch installed. I needed a No Neutral Caseta switch since one switch box has no neutral wire. A wired Caseta Hub is needed for these products. Adding the new products was fast and easy. 


    I am on the verge of that. Sadly, I bit on the first generation Wemo wall switch, and it is less than trivial to replace it. 

    Igot good service from Meross -will likely go with them when I finally have had enough of Belkin's shenanigans.
  • Reply 17 of 17
    eightzero said:
    jayweiss said:
    I recently dumped all my WEMO products after they all failed to connect for the 5th time. After resetting all of the switches and plugs I was unable to reconnect them to the WEMO app. 

    I replaced all of them with Lutron Caseta switches and plugs since I already had one Caseta switch installed. I needed a No Neutral Caseta switch since one switch box has no neutral wire. A wired Caseta Hub is needed for these products. Adding the new products was fast and easy. 


    I am on the verge of that. Sadly, I bit on the first generation Wemo wall switch, and it is less than trivial to replace it. 

    Igot good service from Meross -will likely go with them when I finally have had enough of Belkin's shenanigans.
    Meross mains switches have been reliable for me for years
Sign In or Register to comment.