3 ms·

Some things to realize about read-only devices is that once they are cracked, they are cracked forever. The devs have dev time to secure the device, the hacker

by jayd16 2y ago

Some things to realize about read-only devices is that once they are cracked, they are cracked forever. The devs have dev time to secure the device, the hackers have infinite time to crack it. Once done, the game is up. All instances are now easily exploited. The more popular the device, the more knowable upside to an exploit. If the device can be updated, then usually the exploitable timeframe is limited and its unknown if the attempt is even worthwhile. > After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only'). Well basically because any device of consequence is trivially hacked by now. Think about game consoles or anything that would have DRM today.

mjevans 2y ago
A really dumb camera that just has an interface that's polled for data by a remote host is more likely to be used in a secure way than a 'smart' camera that tries to remember state and talk to an external server itself.
- kube-system 2y ago
  Not at all. Many old mjpeg IP cameras worked this way and they ended up on the open internet. Shodan is full of them, still.
  - ndriscoll 2y ago
    So don't put them on the open Internet. It's much easier to do that than it is to secure a device that creates outbound connections to some untrusted external server (which manufacturers are). If it doesn't try to use UPnP or anything, it will not be in the open by default. If your threat model for consumer IoT devices does not include manufacturers in 2025, you are completely confused about computer security. Having a standard to encourage devices to talk to manufacturers is completely backwards. We should have certifications that devices create no outbound TCP/UDP flows.
    - comex 2y ago
      I hear all the time about non-consumer devices being left exposed to the public Internet, most recently traffic cameras two days ago: https://news.ycombinator.com/item?id=42624930 https://news.ycombinator.com/item?id=42624930 I do not know for sure whether these devices use UPnP or similar, but considering that they are not intended to be accessible from the Internet, probably not. The blame probably lies with (in this case) all the random government agencies deploying the devices in an insecure way. But assigning blame won’t fix the problem. Something needs to change, and it’s probably going to be the devices. Consumer devices are different. On one hand, they’re less likely to be exposed to the public Internet… at least proportionally. I think. But on the other hand, consumers expect to be able to access their devices from anywhere, and right now in practice that means going through a manufacturer-controlled proxy server. I would love if someone would come up with a standardized mechanism to make home devices securely remotely accessible, without a manufacturer-controlled proxy, but just as easy to use as the status quo. Until that happens, don’t expect anything to change.
    - kube-system 2y ago
      > So don't put them on the open Internet. That's a valid answer for an audience familiar with computer networking concepts. It's a silly suggestion for consumer IoT customers, who do not understand those concepts. They don't know what is or is not 'on the open internet'; they buy a product at the store and plug it in. > We should have certifications that devices create no outbound TCP/UDP flows. This is the "bury your head in the sand" method of solving the problem. If you design your requirement so that zero consumer accessible devices are capable of meeting them, then what's the point? As long as people (1) want to watch their camera away from home, and (2) don't have the networking expertise to configure a remote access VPN tunnel, the devices are going to have to reach outbound to traverse home router firewalls.
      - ndriscoll 2y ago
        IoT customers by default would not have devices exposed to the Internet. This has been the status quo for decades ever since wifi and NAT became popular. If they don't understand it, it will be secure by default. It would be technically quite easy for either a dedicated home-access box or just the router-AP combo box to have some auto-config wireguard setup (e.g. scan a QR code or install an app that looks for the box on the local network or through bluetooth). This would be far more secure than the current setup, which is for devices to constantly connect to generally malicious C&C servers. If regulations pushed for actual security (no-cloud), this would be the obvious solution to guide to market toward. Then you only have to trust your gateway device, which also would have no reason to ever create outgoing Internet connections, though it would need outgoing/forwarded LAN connections. With SLAAC to generate a random initial IPv6 address that it never rotates combined with UDP so there's no indication that you talked to anything if your wireguard keys are wrong, there's basically no way to find such a box if you didn't have the correct config.
- jayd16 2y ago
  What you're describing is a completely unsecured device. Any security comes from elsewhere.
  - mjevans 2y ago
    Precisely. The camera is not the Security SYSTEM. It should be an unthinking, and thus difficult to corrupt or abuse, sensor for a security system.
    - jitl 2y ago
      If only every human was an omniscient and perfectly rational actor with infinite time to become network security professionals and infinite budget to implement their perfect security boundary
rkagerer 2y ago
Fair enough but nobody ever hacked my transistor radio ;-).
baobun 2y ago
Sure. But how the firmware process functions matters. There's a world of difference between remotely initated OTA over the interent vs flashing it locally via a USB drive or microSD card. You know like PC motherboards keep working for decades now. They are effectively read-only under normal use and need to have a certain reboot sequence (BIOS/UEFI fw admin) to unlock flashing. Or maybe even load firmware from a preinstalled SD card which makes swapping easy. Or if you really need to be fancy wity remote updates: at least require the push of a physical button to allow flashing remotely.

by jayd16 2y ago

mjevans 2y ago

A really dumb camera that just has an interface that's polled for data by a remote host is more likely to be used in a secure way than a 'smart' camera that tries to remember state and talk to an external server itself.

kube-system 2y ago
Not at all. Many old mjpeg IP cameras worked this way and they ended up on the open internet. Shodan is full of them, still.
- ndriscoll 2y ago
  So don't put them on the open Internet. It's much easier to do that than it is to secure a device that creates outbound connections to some untrusted external server (which manufacturers are). If it doesn't try to use UPnP or anything, it will not be in the open by default. If your threat model for consumer IoT devices does not include manufacturers in 2025, you are completely confused about computer security. Having a standard to encourage devices to talk to manufacturers is completely backwards. We should have certifications that devices create no outbound TCP/UDP flows.
  - comex 2y ago
    I hear all the time about non-consumer devices being left exposed to the public Internet, most recently traffic cameras two days ago: https://news.ycombinator.com/item?id=42624930 https://news.ycombinator.com/item?id=42624930 I do not know for sure whether these devices use UPnP or similar, but considering that they are not intended to be accessible from the Internet, probably not. The blame probably lies with (in this case) all the random government agencies deploying the devices in an insecure way. But assigning blame won’t fix the problem. Something needs to change, and it’s probably going to be the devices. Consumer devices are different. On one hand, they’re less likely to be exposed to the public Internet… at least proportionally. I think. But on the other hand, consumers expect to be able to access their devices from anywhere, and right now in practice that means going through a manufacturer-controlled proxy server. I would love if someone would come up with a standardized mechanism to make home devices securely remotely accessible, without a manufacturer-controlled proxy, but just as easy to use as the status quo. Until that happens, don’t expect anything to change.
  - kube-system 2y ago
    > So don't put them on the open Internet. That's a valid answer for an audience familiar with computer networking concepts. It's a silly suggestion for consumer IoT customers, who do not understand those concepts. They don't know what is or is not 'on the open internet'; they buy a product at the store and plug it in. > We should have certifications that devices create no outbound TCP/UDP flows. This is the "bury your head in the sand" method of solving the problem. If you design your requirement so that zero consumer accessible devices are capable of meeting them, then what's the point? As long as people (1) want to watch their camera away from home, and (2) don't have the networking expertise to configure a remote access VPN tunnel, the devices are going to have to reach outbound to traverse home router firewalls.
    - ndriscoll 2y ago
      IoT customers by default would not have devices exposed to the Internet. This has been the status quo for decades ever since wifi and NAT became popular. If they don't understand it, it will be secure by default. It would be technically quite easy for either a dedicated home-access box or just the router-AP combo box to have some auto-config wireguard setup (e.g. scan a QR code or install an app that looks for the box on the local network or through bluetooth). This would be far more secure than the current setup, which is for devices to constantly connect to generally malicious C&C servers. If regulations pushed for actual security (no-cloud), this would be the obvious solution to guide to market toward. Then you only have to trust your gateway device, which also would have no reason to ever create outgoing Internet connections, though it would need outgoing/forwarded LAN connections. With SLAAC to generate a random initial IPv6 address that it never rotates combined with UDP so there's no indication that you talked to anything if your wireguard keys are wrong, there's basically no way to find such a box if you didn't have the correct config.
jayd16 2y ago
What you're describing is a completely unsecured device. Any security comes from elsewhere.
- mjevans 2y ago
  Precisely. The camera is not the Security SYSTEM. It should be an unthinking, and thus difficult to corrupt or abuse, sensor for a security system.
  - jitl 2y ago
    If only every human was an omniscient and perfectly rational actor with infinite time to become network security professionals and infinite budget to implement their perfect security boundary

rkagerer 2y ago

Fair enough but nobody ever hacked my transistor radio ;-).

baobun 2y ago

Sure. But how the firmware process functions matters. There's a world of difference between remotely initated OTA over the interent vs flashing it locally via a USB drive or microSD card. You know like PC motherboards keep working for decades now. They are effectively read-only under normal use and need to have a certain reboot sequence (BIOS/UEFI fw admin) to unlock flashing. Or maybe even load firmware from a preinstalled SD card which makes swapping easy. Or if you really need to be fancy wity remote updates: at least require the push of a physical button to allow flashing remotely.