I have to admit that Internet-enabled gas station equipment has been around for a long time. In fact, WireSpring actually developed an early version of a remotely-managed fuel dispensing system for a (now defunct) company called ifuel waaaaay back in 2004. The system featured remote monitoring and management of the pumps, digital signage, CRIND devices, and even had social components. Unfortunately, it was a bit ahead of its time. However, it was never hacked while it was live.
While there have been a few reports about actual fueling infrastructure getting hacked, the focus of today's story is on a series of honeypots (computer systems intentionally left unsecured so that researchers can learn from would-be attackers) set up to look just like Veeder fuel monitoring systems. The so-called "GasPots" were left online for a period of about six months, during which time researchers at Trend Micro noted attacks coming from various groups. Since the monitoring systems can't actually affect fuel flow, most of the attacks attempted were harmless -- and likely would be if they were carried out on real-world infrastructure. However, the researchers also noticed a number of denial-of-service (DoS) attacks that could have taken a real-world pump offline for some period.
So while the researchers technically didn't observe any real-world attacks (since they weren't looking for them), it's safe to assume that the same type of attackers who came across their honeypots are likely to either have come across real-world devices that are similarly (in)secured, and if not, they probably will in the near future. And while again the focus in this case was on devices that can't actually modify the flow of fuel on is way from tank to pump, there are certainly other internet-enabled devices at many fueling stations and depos that can do precisely that. I'm sure that being able to remotely manage these devices can be beneficial to business owners and managers. However, this type of infrastructure should always be behind a firewall, a VPN, or both.
If you can get past the silly-sounding GasPot terminology, the Trend Micro report actually makes for some interesting reading. It can be downloaded in its entirety here.
I wonder if I should just rename this blog "M2M and IoT Hacks" and get it over with, as I'm now sitting on three or four articles about a big-name IoT or M2M installation being remotely exploited by external agents (sometimes good, sometimes not so much). The first of which popped up last week when the Department of Homeland Security's Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) announced that an Internet-enabled smart IV pump that's in fairly widespread use contains remote exploits that would allow attackers to take control of the device.
The model in question, the Hospira Symbiq Infusion System, is no longer being sold, and the manufacturer has yet to announce a security patch. There's also no word on whether new models derived from the Symbiq have similar vulnerabilities. The current workarounds are to disable network access for the devices and close the various ports required to enable their remote control functions. The specific ports listed are a little worrying:
- Ensure that unused ports are closed, including Port 20/FTP and Port 23/TELNET.
- Monitor and log all network traffic attempting to reach the affected product via Port 20/FTP, Port 23/TELNET and Port 8443. Contact Hospira’s technical support to change the default password used to access Port 8443 or close it.
While it's good to see port 8443 (the "backdoor" TLS port) listed, ports for the hugely insecure and obsolete FTP and... gasp... telnet ports are listed as well. Whether the advisory recommends closing them because they're actually being used by device or just because those ports should always be closed (and the protocols should never be used) is unclear.
As a number of users and commenters on various IoT forums also pointed out, these devices do ship with password protection. Unfortunately, many times the default usernames and passwords are not changed, or if they are, they are changed to something simple and memorable because the devices often need to be accessed by a large number of hospital staff.
The worrying trend of finding insecure hardware infrastructure continues. It's only a matter of time before the problem jumps from external assets like IV pumps to internal devices like pacemakers and deep brain stimulator implants.
The low-power, low-bandwidth wireless protocol ZigBee has found widespread adoption in IoT and M2M smart devices that need to be inexpensive, rugged and often separated by distances greater than be covered by conventional WiFi signals. Backed by Samsung, Motorola, TI and others, it represents one of the few successful standards adopted by Internet of Things companies to date. Unfortunately, according to research conducted by security firm Cognosec, it's also insecure, and maybe incurably so -- but not for the usual technical reasons.
If you choose to read the entire report, you might find yourself waiting for the punchline. After all, the protocol in question is completely open, well-pedigreed, widely-adopted, and has been audited and reviewed by some of the best research firms over the seven or eight years that it has existed. The researchers go into some detail about its scalability and built-in security features, pointing out their overall robustness.
So what's the problem, then?
Basically, people. Or money. Or both.
It seems that to gain certification, devices only need to implement some minimum number of features, and the security model of the protocol is such that if one part of the software stack is trusted, they all are trusted. Consequently, a poor or incomplete implementation of the protocol on one node of a deployment could potentially open up an attack vector for all of the other connected devices in the deployment. Short of figuring out the weakest link(s) in a deployment and weeding it out, this makes securing an IoT network next to impossible. And keep in mind that many of the "deployments" in this use-case are inside peoples' homes, where devices from a variety of different vendors might be networked together to provide smart home functionality, from controlling the lights and A/C to locking and unlocking doors.