Coming barely weeks after my essay on the security risks from embedded systems, the Proofpoint report of a spam-sending refrigerator was just too good to be true. I was skeptical, so I didn’t blog it. Now Ars Technica has a good analysis of the report, and is also skeptical. In any case: it could happen, and sooner or later it will.
Jordan Brown • January 22, 2014 12:41 PM
Spam is canned, so doesn’t need refrigeration until after it’s opened.
Anura • January 22, 2014 12:45 PM
I can barely stomach this kind of reporting – refrigerators and spam mentioned, but no Monty Python reference? That is unacceptable. This whole post just leaves me with a bad taste in my mouth.
Dave Aronson • January 22, 2014 12:47 PM
@Jordan, SPAM is canned, but spam is not. (Hormel is quite insistent on that.) Sadly, the CAN-SPAM Act means “you can spam to your clogged little heart’s content if you do these trivial things”, not “spamming will land you in the can”.
Davi Ottenheimer • January 22, 2014 1:09 PM
Researchers are claiming Internet of Things risks where in fact there are none. Speculation is being reported as truth. This misrepresentation is unfortunate because false reports/intelligence diminishes our ability to manage real risks properly.
The example you used in your earlier essay, for example, conflates code being available to intent/targeting. I tried to illustrate the confusion here:
http://www.flyingpenguin.com/?p=20093
Title: “Linux Worm Targeting Hidden Devices”
Content: “…we have not confirmed attacks against non-PC devices yet.”
Targeting seems to be an overly speculative term. Are we saying someone putting a wine bottle in their car is obviously going to be drunk-driving and therefore a threat? That’s how I read the “targeting” definition of these researchers. Or worse, they spotted Ms. Jones buying wine at the grocery store and called 911 because she owns a car.
To be clear, I do not disagree entirely. There is important value in speculation. We see a continuing and natural curve that attackers will expand to new platforms and opportunities. My ask is that we try harder to avoid confusing potential harm with real present harm. Targeting should mean something.
With that in mind I looked at the refrigerator report. It says 10 email were sent per device, 3x a day, in 100k bursts. Out of those bursts only 25% were non-PC devices. And out of those non-PC devices, only ONE was believed to be a refrigerator. So less than 1% of SPAM messages were sent by refrigerators, which gets turned into a story about 100K+ kitchen appliances attacking us.
A few thoughts on this confusion:
1) Did anyone verify the banner of that refrigerator or was it a completely bogus data point? If bogus, I worry attackers will be encouraged to replace banners on every device they compromise to artificially increase the confusion; mostly for Lulz but also because we’re so eager for theater we’ll ignore reality and tangible steps to block actual attacks.
2) If not bogus, was the refrigerator device just an OEM tablet sold by a refrigerator manufacturer to fit a dock on a door? In other words, if a refrigerator has an iPhone dock on its door, do we reclassify every iPhone that uses it as a refrigerator device?
3) And if not bogus, and a real refrigerator, before we spin speculation about the hot mess of IoT attacking everything, we might want to keep a definition of attack in mind. An attack is something more than just a few email/SPAM, perhaps?
Brian M. • January 22, 2014 1:25 PM
This can only happen if the appliance in question can be accessed from outside the home firewall.
Another point is that the appliance must have services that allow for exploitation. Let’s say that the network devices simply have SNMP to facilitate house power management. The interface is pretty easy to secure, i.e., defend against being hacked. Now, if the fridge has its own web server, etc., then the developers are begging and pleading for trouble. How many web interfaces don’t guard against simple injection attacks? (I know my IP cams have crap interfaces, so I keep them isolated.)
For instance, let’s say that the fridge has a web interface, and the owner has allowed it to be accessible from the Internet. The first thing that someone can do is get the web server’s information, like version number. Then the attacker can simply look up the bugs for that release. If the fridge just allows read-only access for some simple information, then the attack surface is fairly small. On the other hand, let’s say that the fridge allows someone to log in and set values, etc. Gee, did the developers forget some permission values somewhere? Can you upload something into RAM due to that flaw?
The Samsung RH2777AT HomePAD Internet Refrigerator came loaded with WinCE, wireless and Ethernet. You could control various functionality, even remotely. Something like that, when exposed, would be a prime candidate for hacking.
Really, it comes down to what an attacker can access. If the attacker can’t access the fridge, then it doesn’t matter. But many users will put devices in the DMZ, just to have a little convenient access, without realizing the dangers associated with doing that.
If the Internet of Things eventually makes its way down to the can level, SPAM will be able to send SPAM spam.
name.withheld.for.obvious.reasons • January 22, 2014 4:36 PM
@ Brian M
This can only happen if the appliance in question can be accessed from outside the home firewall.
Most “home” firewalls lack sufficient default egress firewall rules, let alone the fact that most have uPNP enabled. The vacuum that is the space the home Internet security systems occupy is vast. Most people are lucky if there home systems keep the neighborhood kids out. I was at a friends house configuring his comms and I reconfigured his wifi, oops, that was the neighbors router. I’d reconfigured his neighbors wifi router by accident–by accident.
During a passive nmap scan (I know, oxymoron) as opposed to an active netcat survey, the first of two (in the same ip addr space) an APC UPS rebooted. Luckily the second on for the same rack did not reboot on a port scan. And good thing the naval station power generation control system wasn’t effected. Even the third UPS would not have held the rack closed–it is inline.
That was a fun day.
Peter • January 22, 2014 6:10 PM
Not so hard to believe. Basically the same as the Carna botnet.
Coyne Tibbets • January 23, 2014 12:43 AM
@article
It’s also hard to understand why someone would go to all the trouble of infecting a smart device and then use it to send just 10 spam messages. Traditional spam botnets will push infected PCs to send as many messages as its resources allow.
I can’t agree with this part of the article for two reasons.
First of all, with respect to spam, junk filters are highly sensitive to many identical emails coming from a device; this is kind of like the firing line of spam detection. The wire has been set lower and lower, with sudden bursts of as few as 50 identical emails triggering junk filtering. Sending just 10 messages would be a clever way to bypass most such filters, which would view this as more typical for a cc: or bcc: on an regular email.
Second, one of the advantages of going after something like a refrigerator is the mass production angle. If you make a refrigerator with a weak OS, it is going to be exactly the same on tens or hundreds of thousands of refrigerators; exactly the same OS, with exactly the same weaknesses, and with exactly the same difficulty in upgrades to that weak OS. This gives you a chance to automate, even if you have to come up with a different strategy for each class of device:
This is exactly the kind of thing that computers do well: It’s very easy to imagine a mass deployment program going through the catalog, deploying on randomly selected devices in the catalog, each in turn.
No need to hand-break each device: And if the device can’t easily be classified for mass breaking, go find another one that can be.
Since it is hard to upgrade these firmware’d devices to eliminate weaknesses, and since no one is likely to notice they were attacked anyway (so long as the refrigerator keeps working right) repeat Phase 2 as often as desired. In the meantime, keep adding to the catalog.
Now, on the other hand, the point about NAT and access to the devices is probably well taken…for IPV4. Except: part of the point of putting these devices “on the internet” is so that you can use an external app to reach them and query them. So maybe the first stage of the attack is the central contact server?
Brian M. • January 23, 2014 9:27 AM
@name.withheld.for.obvious.reasons:
I was at a friends house configuring his comms and I reconfigured his wifi, oops, that was the neighbors router. I’d reconfigured his neighbors wifi router by accident–by accident.
Let me guess: you didn’t log in at 192.168.0.1, did you? And the routers had been configured for Internet-side administration, weren’t they? 😉
There’s a big difference, though, between UPNP and default egress-allowed configurations. UPNP allows an application or device to set itself up as providing a service to world+dog on the Internet, while egress-allowed just allows devices on the inside to contact something on the outside.
Since UPNP makes swiss cheese out of any plausible “security” a site might have, I always turn it off. Since my new router can switch it on for a specific VLAN and my switches support VLANs, I might turn it back on.
name.withheld.for.obvious.reasons • January 23, 2014 11:07 AM
@ Brian M
I’m afraid any attempt to “inform” me about hardware and network stacks (OSI and classic) are lost on me. uPNP came about as a favor to gamers since they couldn’t be bothered in learning how port translation works. Even for home security I suggest a two layer approach with full time monitoring and logging. Between the two layers is instrumentation, dedicated hardware for SIGINT. And that’s a base configuration. Devices that are trusted can be CIDR blocked, only the size necessary and vlan’s ID of greater than 1000–MLS if afforded. DHCP should be off, no uPNP on the inside or outside interfaces. Locked down ssh only management interfaces with ACLs for all traffic (in/out on any interface) rules for non-public routed addrs (no 10, 169, 172, 198 nets) and no broadcast protocols, printers forcibly isolated–choice of methods include disabling all network protocols and wireless interfaces. I could go on and on and on, but that is a start for the most rudimentary home environment (this does not support a telecommute/work SOHO environment).
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Andrew • January 22, 2014 12:33 PM
It should be ‘spam’, not span-sending