4 ms·

That's a really flimsy article. Someone is claiming 3 million smart toothbrushes were used in a DDoS, but no one is talking what/who/how. That seems like the

That's a really flimsy article. Someone is claiming 3 million smart toothbrushes were used in a DDoS, but no one is talking what/who/how. That seems like the kind of extraordinary claim that requires at least some kind of evidence. There is surely at least some technical details that enabled them to identify the toothbrushes, right?

blacksmith_tb 3y ago
It also seems odd that even if you (maybe unknowingly) connected your 'smart' toothbrush to wifi, it would be exposed to the public internet. Aren't most people using some kind of clunky cable modem etc. from their ISP, which would have a basic inbound firewall?
- d1sxeyes 3y ago
  Hypothetically, let’s say these toothbrushes connect periodically to an API from which they fetch firmware updates. If you’re able to MitM that connection, you could deliver whatever you like as a firmware payload to the toothbrush. Or maybe someone designed the toothbrush to open ports using UPNP to enable a remote connection to tell the toothbrush that the update server has moved to a new URL?
- Retr0id 3y ago
  There's lots of ways for this expectation to be broken. The most obvious is UPnP, where the device can ask the gateway router to forward ports. The second is the fact that devices on the LAN are accessible to other devices on the LAN. Malicious JS in a webpage can scan for and compromise other local devices. And the third is the fact that whatever serves code to the toothbrush (whether it's firmware updates, or an HTML5 dashboard) can be compromised. In the latter case, it could be something as simple as persistent XSS.
  - gtirloni 3y ago
    > The second is the fact that devices on the LAN are accessible to other devices on the LAN. Malicious JS in a webpage can scan for and compromise other local devices. Which browser API enables that?
    - Retr0id 3y ago
      HTTP, it's all the rage these days. (via <form>, fetch, XMLHttpRequest, et al)
      - gtirloni 3y ago
        Ah ok, so we are talking about dumb old methods. I thought it was something like the fancy APIs that are all the rage these days.
        Retr0id 3y ago
        There was a brief window when people knew that if they used non-HTTP protocols, then malicious webpages couldn't talk to it. But now even "native" apps are web apps, and IoT devices all use web APIs too. They can be locked down through CORS etc., but it's easier for devs to set `Access-Control-Allow-Origin: *` and worry about it "later".
        kevincox 3y ago
        In most cases `Access-Control-Allow-Origin: ` is actually a decent policy. It importantly blocks cross-site credentials. So as long as your API has any* authentication it should prevent it. The real mistake is mirroring the Origin header from the request in the `Access-Control-Allow-Origin` response header which allows credentials (unless you add other headers) Of course this all relies on you not accepting form posts without auth.
    - metadat 3y ago
      I was skeptical at first, but did some superficial scouting.. it's trivial for a malicious website to do nasty things to any internal resource which doesn't have a strict CORS policy. https://security.stackexchange.com/questions/177486/can-websites-access-computers-in-lan-localhost-through-browser-how-to-block-th https://security.stackexchange.com/questions/177486/can-webs... As the adage goes, the "S" in IOT stands for "Security".
      - 3y ago
- zoeysmithe 3y ago
  A lot of home, small business, or neglected enterprise routers and firewalls are broken into permanently. Many of these will not auto-update their firmware or the attackers got in before the patch was available. Then the initial actor sells access to them to other actors. I believe the Ubiquity Edge router, a small/medium/AV industry favorite, was paired with other exploits by a state actor to perform attacks on high value orgs.
Retr0id 3y ago
I'd like to see more details too, but it's not that extraordinary in my opinion - par for the course for low-cost wifi-enabled appliances.

blacksmith_tb 3y ago

It also seems odd that even if you (maybe unknowingly) connected your 'smart' toothbrush to wifi, it would be exposed to the public internet. Aren't most people using some kind of clunky cable modem etc. from their ISP, which would have a basic inbound firewall?

d1sxeyes 3y ago
Hypothetically, let’s say these toothbrushes connect periodically to an API from which they fetch firmware updates. If you’re able to MitM that connection, you could deliver whatever you like as a firmware payload to the toothbrush. Or maybe someone designed the toothbrush to open ports using UPNP to enable a remote connection to tell the toothbrush that the update server has moved to a new URL?
Retr0id 3y ago
There's lots of ways for this expectation to be broken. The most obvious is UPnP, where the device can ask the gateway router to forward ports. The second is the fact that devices on the LAN are accessible to other devices on the LAN. Malicious JS in a webpage can scan for and compromise other local devices. And the third is the fact that whatever serves code to the toothbrush (whether it's firmware updates, or an HTML5 dashboard) can be compromised. In the latter case, it could be something as simple as persistent XSS.
- gtirloni 3y ago
  > The second is the fact that devices on the LAN are accessible to other devices on the LAN. Malicious JS in a webpage can scan for and compromise other local devices. Which browser API enables that?
  - Retr0id 3y ago
    HTTP, it's all the rage these days. (via <form>, fetch, XMLHttpRequest, et al)
    - gtirloni 3y ago
      Ah ok, so we are talking about dumb old methods. I thought it was something like the fancy APIs that are all the rage these days.
      - Retr0id 3y ago
        There was a brief window when people knew that if they used non-HTTP protocols, then malicious webpages couldn't talk to it. But now even "native" apps are web apps, and IoT devices all use web APIs too. They can be locked down through CORS etc., but it's easier for devs to set `Access-Control-Allow-Origin: *` and worry about it "later".
        kevincox 3y ago
        In most cases `Access-Control-Allow-Origin: ` is actually a decent policy. It importantly blocks cross-site credentials. So as long as your API has any* authentication it should prevent it. The real mistake is mirroring the Origin header from the request in the `Access-Control-Allow-Origin` response header which allows credentials (unless you add other headers) Of course this all relies on you not accepting form posts without auth.
  - metadat 3y ago
    I was skeptical at first, but did some superficial scouting.. it's trivial for a malicious website to do nasty things to any internal resource which doesn't have a strict CORS policy. https://security.stackexchange.com/questions/177486/can-websites-access-computers-in-lan-localhost-through-browser-how-to-block-th https://security.stackexchange.com/questions/177486/can-webs... As the adage goes, the "S" in IOT stands for "Security".
    - 3y ago
zoeysmithe 3y ago
A lot of home, small business, or neglected enterprise routers and firewalls are broken into permanently. Many of these will not auto-update their firmware or the attackers got in before the patch was available. Then the initial actor sells access to them to other actors. I believe the Ubiquity Edge router, a small/medium/AV industry favorite, was paired with other exploits by a state actor to perform attacks on high value orgs.

Retr0id 3y ago

I'd like to see more details too, but it's not that extraordinary in my opinion - par for the course for low-cost wifi-enabled appliances.