Great hardware, but do you really want to run a full Linux system on low-end IoT devices? That's what made the recent massive DDOS attack possible - lots of little machines with way too much network-side functionality.
> While it's not possible for us to investigate all the attacking devices, it is fair to say that these attacks came from Internet-of-Things (IoT) category of devices.
> There are multiple hints confirming this theory.
First, all of the attacking devices have port 23 (telnet) open (closing connection immediately) or closed. Never filtered. This is a strong hint that the malware disabled the telnet port just after it installed itself.
> Most of the hosts from the Vietnamese networks look like connected CCTV cameras. Multiple have open port 80 with presenting "NETSurveillance WEB" page.
> The Ukrainian devices are a bit different though. Most have port 80 closed, making it harder to identify.
> We had noticed one device with port 443 open serving a valid TLS cert issued by Western Digital, handling domain device-xxxx.wd2go.com suggesting it was a hard drive (Network Attached Storage to be precise).
So its not Linux, its the apps. The insecurity of the boxes has nothing to do with their choice of OS, but rather their shoddy apps. Its a general pattern for IoT devices to be configured with default passwords and internet-facing admin pages etc, and using another OS doesn't directly address any of this.
ADDING: I'm a big fan and watcher of everything from OpenBSD to QubesOS to the Mill CPU to CHERI and all the rest, and I'm reluctant to say that right now the OS is immaterial to security :( ;)
Exactly. The best-selling home IP camera on Amazon [1], from a Chinese company, has the following "features":
- Default Wifi setup is done through their phone app through the "cloud" (let me tell you how much I trust that one)
- Has a webserver listening on port 80 with default u:p admin:admin (to be fair, their instructions are clear that you should change it, but it's not a mandatory part of the setup process)
- Has an RTSP server listening on port 554
- All of this a disaster waiting to happen because of UPnP (ugh, how many home routers have this enabled...)
- Sends outbound TCP traffic to amcrestcloud.com and amcrestview.com every few seconds (cannot be disabled on the device) [2]
- Sends a continuous stream of UDP data to 52.91.189.219:8800 (cannot be disabled on the device) [2]
The only way to prevent this device from a calling a CNC server is with a hardware firewall or an isolated LAN segment (I suppose this idea isn't at all specific to this camera). I bet fewer than 0.01% of their customers do that.
> All of this a disaster waiting to happen because of UPnP (ugh, how many home routers have this enabled...)
The problem is shitty UPnP implementations rather than UPnP itself. If you're pwned you are fucked one way or another, if an online device is vulnerable it's going to be vulnerable wether it exposes itself through UPnP or if it's manually forwarded.
And in the end if you don't like it and want to do your own manual forwarding in a home router, you're free to disable it.
Agreed. Bare metal programming is vastly preferable for many, if not most, realistic embedded applications. I hope they have a convenient gcc-arm-none-eabi setup available. It's not just about security; it's also a lot more work to do hard realtime systems with any sort of OS, even an RTOS.
We're even starting to see a bit of this on the high-level non-embedded side of things; projects like HaLVM and Mirage OS allow us to write bare-metal non-embedded code using extremely high-level languages. The idea is that you write a program that runs on bare metal (no OS or any OS-provided features) and you use standard library abstractions to get features that you would normally get from the OS. Then, if you want to run a bunch of these things, you run them in efficient hypervisor systems like Xen. This approach has many interesting benefits (and costs) compared to traditional OS-based high-level programming.
No. It would be more accurate to say that is is a lot more work to reimplement a hard realtime embedded RTOS from scratch, when you have a nontrivial application that needs features like tasking, synchronization, IPC, memory virtualization etc.
That is probably not Linux, but going bare target every time you have a new application and platform with hard realtime requirements would be a huge mistake.
> you use standard library abstractions to get features that you would normally get from the OS
They don't come ex nihilo. There are a lot of "standard library" APIs that are dependent on what would ordinarily be called an OS.
> Then, if you want to run a bunch of these things, you run them in efficient hypervisor systems like Xen.
This is often, if not usually, the wrong level of abstract for either application architecture or efficient resource usage.
There are intermediate steps between bare metal and Linux, and they're widely used in the embedded world. See Wikipedia for a long list.
I just noticed that there's now CapROS for ARM.[1] This is a capability-based secure operating system for small machines. It's a successor to EROS and KeyCOS, which had a good track record for security and reliability. Unfortunately, there's very little documentation. Somebody could bring that up to usability for ARM embedded devices and make money selling support to IoT companies.
The hobbyist/non-technical market can get on board better with Linux.
For one it has a GUI.
Also you don't have to write firmware and you dont have to cobble all the pieces together from scratch or from a miscellany of out-of-date examples.
Instead you can pipe together existing software and/or write your own in the high-level language of your choice.
No, you don't. You want your devices to be simple and talk to a bridge that runs e.g. Linux and handles networking. But at the moment this is where the ecosystem is at.
Linux just has too much attack surface.