When Web Services are a Dumb Idea
Last week I was lucky enough to talk to a group of smart developers in the control industry (a group that I would actually trust to write an embedded web app). We got on the subject of the disturbing trend of, “Web Servers in Everything!,” an idea whose time should never have come. Why, for example, a furnace controller, whose sole input in life is “on” or “off” from a thermostat, and whose sole outputs are “furnace on, blower on, or both on,” needs a web server is a bit beyond me.
Large and small control modules are getting embedded web servers thrust upon them with increasing frequency. “For the users!” is cited as the reason, ignoring the fact that web service vulnerabilities are almost at the top of the exploitation heap. In another year or two I’ll bet that they will be #1.
In timely fashion, just a few days after my impromptu luncheon, Mikko Hypponen at F-Secure tweeted a cute Google query. The search is for a particular phrase in the <TITLE> tag of a web page. It reveals an embedded webserver from one of Digital Bond’s favorite insecure vendors — quite a few of them are on the Interwebs with apparently no firewalls in front. A quick poke around said vendor’s website gets a document which details default account names for the products (two accounts that can’t be disabled) as well as its capabilities (complete control of your Profibus or ProfiNet network! The device is an HMI, after all).
Shucks, I might have just given away who makes it.
At Digital Bond we’ll often see finicky web servers running on embedded controllers during an assessment, and while trying to find a little more information on it we stumble upon dozens of the systems available on the internet with no protection.
For control systems manufacturers, here is a helpful decision tree for deciding whether to put a web server in your product.
Web servers are far worse on embedded than usual because 1) these products often run (surprise) embedded operating systems, which don’t have well-tested stacks of any kind. Embedded operating systems’ filesystem? Not so throughly tested. IP stack? Not so thoroughly tested. Web server’s HTTP parsing? Not so thoroughly tested. Web application itself? </broken_record>. Embedded operating systems also rarely provide nice features like memory protection, so a flaw in an embedded web server is more likely to yield full control of the system to an attacker.
Couple the software issues with the normal hardware concerns that manufacturers have, and now the app also needs to cope with constrained resources. RAM, flash, and processor speed are restricted due to industrial requirements, plus the interest in keeping unit costs down over the ten to twenty year manufacturing cycle. So doing thorough input sanitization everywhere can make the product unusably slow.
Developers: please, please put this technology as far away from your actual controllers as possible. When you place well-understood and commonly-exploited protocols right next door to actual process control, you are just begging for trouble. Of course, you’re welcome to join our new insecure products list if you’re still feeling up for it…
Photo by proimos