Worrying
But not surprising.
Medical systems to traffic light boxes are apparently wide open to hackers thanks to a lack of authentication checks in equipment exposed to the internet. That's according to research from security toolmaker Rapid7, which says it found plenty of essential electronics that can be freely remotely controlled via public-facing …
And just how often does someone connect to a device of this kind locally?
When they are setting them up maybe, then its sitting in a cabinet for the next 12 months gathering dust while its LED is blinking green.
Yeah that is a sweeping statement, and there will be exceptions, but in the main, someone hoping to make use of this vulnerability will be waiting a long time.
One of the sites I work with has it's heating system remotely managed by a third party who are suppoed to check 24/7. The system is accessed via telnet and just requires a password, no username. I can vouch for the fact that they use it regularly as I locked down the firewall to only accept incoming telnet from a single IP address. Their stupid monitoring system is on a dynamic IP.
After about the 5th phone call one of their engineers suggested not locking the port down - hopefully I educated him suitably about what a bad idea it was.
I was going to go meh none here but actually things like our WAN routers which are managed have modems attached to their Cisco Routers, we also have a few Lantronix Ethernet converters (Actually come to think of it commands passed to a port from the software contain no authentication info other than one connection to an ip at a time, time to review it methinks).
So the attacker sends the 'destroy all humans' command to the device once a minute, for the next year. Repeat the above for 365 devices that are 'only connected to once a year' and you've got plenty to be getting on with!
by El Reg commentards in 2011 on the Stuxnet story. So finally some official research.
Now, if ATMs have been easily hacked via their ports by mid level crackers, what chance do these even more publicly accessible systems have? What about remote sensors connected into a serial bus or by Ethernet? Being remote they can be got to quietly.
Then there's wireless... http://www.welivesecurity.com/2011/08/09/hack-wireless-industrial-sensors-in-a-few-easy-steps/
You fail to see the reason from the manglement perspective.
Anything that can cut costs is a GOOD THING, which leads to higher executive bonuses. Executives don't have to worry about security, that is your job!!!
Do it with your hands tied behind your back courtesy of manglement, who would quickly throw you under the bus when the shit hits the fan!!!!
... that the history of DRM and Copyright protection, as well as all the hacking incidents reported for the last 3o years, would have convinced people that there is no such thing as 100% protection. What one person can defend, another can attack.
That being the case, anyone who allows remote control of anything must assume that at some point it is going to be attacked successfully, and should do their risk analysis accordingly.
Maybe the cost-benefit for these connected items has been considered, and determined to be acceptable. But I strongly suspect that it hasn't been considered at all...
I once had to kill off a global virus infestation at a company. After a couple of days work we ended up with one system that we could not identify, but which was still bursting to try and reach other machines (etherape is an *excellent* tool for that).
Once we pinned down the exact network segment we could not find the machine which nmap identified as running NT 4.0. As far as we could tell there was no production on the segment so we got permission to try and nuke the machine offline by flooding it with nmap..
..at which point the switchboard in reception died :)
It turned out to be running NT 4, but without any such exciting things as automatic patching and anti-virus, so it was wide open and well saturated with our little problem..
I suspect that many of these systems use convertors because they are a bit legacy and do not have the credential functionality built in to the main control software. Some will be truly distributed and will need to be connected from different IP addresses while others can be locked down to a single IP. Even in the locked down case it will still be vulnerable from man in the middle routing attacks if the packets are not encrypted. The safest way in the single IP case would be to have paired convertors, doing certificate based SSL. This would mean the two legacy systems being connected would not need software change, just best practice IT configuration control and some routing rules.
And some are at the end of a mobile phone as they are in such remote areas.
However, once you find one, what are you going to do with it? Unless it responds to a terminal emulator, its not going to be so easy to find out what is on the end. You could have a modbus link, you could have a old Texas Instrument PLC. Its going to be tricky to find out what is on the end of it as many won't respond unless the right bit of software is sending the write bit of data to it. And thats not even a user authentication level.
Not impossible. Just very tricky.
What if the evil hacker just doesn't care about side effects?
If they just squirt some fairly random data at it until it responds, what happens?
A lot of these have a very simple command set, so the odds of a random data stream doing something are pretty good. In some cases even the bootloader or test modes might be exposed, so random data could even "brick" the kit by accident!
Many of the rest have normal terminals, complete with headers saying what they are - so a black hat could simply look up the manual for the equipment to find valid commands.
On top of that, most serial devices respond with things like "NACK" or "?" if they don't understand a request, and as many don't have much CPU, simply flooding the serial port can affect their ability to do whatever job they are doing.
Aside from that, a miscreant could easily prevent legitimate use of the device.
Either way results in a denial of service to a piece of physical plant, which could be quite dangerous.
These systems will be the battlefields of the next war, which will be unique in that it will be difficult* to positively identify the combitant countries and because of the level of civillian casualties and economic damage.
All because properly securing systems is seen as an unwarranted cost by too many vendors.
And we haven't even started rolling out IP6 and the 'Internet of things' yet, we have the 'oppurtunity' to make this a much larger problem before kick off.
*Nationstates aren't going to launch an attack from their own IP block, they're going to launch it from exploited machines in the target Nation and route the commands through a crapload of compromised machines in other 'usual suspect' nationstates, including their own. The global Internet links will be physically disabled pretty quickly once things kick off.
I scream and shout and throw big heavy things at the managers where I work while shouting 'air gap air gap' between the internet connected stuff (3 office PCs ) and the stuff networked to the robots (2 pcs and a laptop).
Last thing we need is for the robots to go berzerk and start killing everyone.. especially when its my shift getting killed.
<<wondering where he can get a phased plasma rifle in the 40 watt range
In general a lot of kit comes with serial ports so the installers can configure it - but the chance of the end user fiddling about with it - is a lot slimmer.
Trust me - you install sound systems in a Theatre that are configurable via TCP/IP and it won't be long until the service calls start coming in about how "the noise sensing mic in the foyer is making the paging system far too loud" well yes, that's what happens when you remotely turn up the gain control.....
Not really sure why this kit is then being connected to an Ethernet convertor though - but I suppose certainly in the event of traffic lights - they will be controlled by some central authority - although I thought they tended to be wireless these days....
Anyhow by all means connect the kit up if you really must - but don't let it talk to people outside the network unless you have a VERY good reason for doing so.
As a side note -
There is an architectural lighting installation somewhere in the UK (I won't say where) that has 2 windows computers sitting on standard broadband connections just waiting for remote desktop connections for remote update of the lighting programs....
There is an architectural lighting installation somewhere in the UK (I won't say where) that has 2 windows computers sitting on standard broadband connections just waiting for remote desktop connections for remote update of the lighting programs....
I'll beat you for scary. I once worked at a power company where all the drawings of where cable was buried were kept in a system where the supplier had FULL control over. Drawings are rather important to a power company, but the supplier was forever reorganising the thing at root level without any supervision or audit log, and when we blocked them on the firewall (as the system wasn't on a DMZ) the supplier just used the test system and hopped over instead. Long story short, we contained them on a DMZ and started clipping their wings, which the supplier really, really didn't like.
I made the mistake of asking how we selected this supplier and the answer was worrying.
Apparently they were first choice because they had other clients...
... such as nuclear power stations.
Therein lies the problem. You see serial ports (RS/EIA 232, 25 pin and 9 pin) have been around for at least 50 years (and in other forms probably more than that!). There is no escaping them. Try as we might, they are a VERY simple interface to add on to an embedded device, and with the help of a converter, to the internet encrypted with little access controls (passwords/accounts/user names).
In one instance I know of a product that has a nice serial port that users want to really have made to an usb port somehow. The pain involved in designing it, and getting the proper vendor/product ids (among others) just aren't worth it for a product that might ship 10k (or less) of a single product. Even if they DO provide an interface (TCP/IP, or USB, etc..) the "easy way out" is to just emulate a serial port (no passwords, etc.) and the problem happens again and again.
So, serial ports (DB-25s and DE9s) are here to stay, and not much we can do about it. The security needs to be built into the devices that have the serial ports, not some silly add-on.
Personal note: I was guilty of having serial ports hung on modems that allowed full control of the system they were connected to. Fortunately back in the day (1982 or so) there was a cost to "war dialing" and it wasn't done much (he says knocking on wood!). Then again one should revisit the movie "War Games".
You can't put useful security on the serial port itself, there isn't the CPU (or the bandwidth) in most devices.
Aside from that, even if you did it could not even begin to protect against man-in-the-middle or replay attacks without making the port itself useless for its intended purpose - namely simple interconnect between disparate systems.
Your TV probably has a serial port - it's for remote control like on/off and channel select when used in places like the Heathrow baggage area.
As long as that network stays private, the risk is easily mitigated. The trouble arises when the network is not private!
The security has to be in the serial-to-internet link, that's the only effective location.
You can't put useful security on the serial port itself, there isn't the CPU (or the bandwidth) in most devices.
Bollocks. The common problem is not that it can't be done (show me a reasonably current embedded system that has less processing power than a MicroVax II, and even then it's not a problem), but that it simply isn't done properly, if at all: fixed usernames and passwords are all too common.
I use serial-controlled devices regularly. It's part of my day job.
Most of them are 9600 baud, many are in fact an 8-bit PIC/Arduino class microcontroller. So yes, we really are talking single-digit MIPs and 100's KB RAM - less than your Microvax.
Nearly all of these serial links are intended for integration of disparate systems from different manufacturers.
Add encryption and both ends need to handle it.
If the link doesn't work, it needs "sniffing" to test it because one or both ends won't have any form of UI.
Unless the transmission itself is encrypted, then username/password is utterly useless because a trivial replay attack will crack it!
And in many cases, one end isn't made anymore.
The security belongs on the Internet connection device.
In most cases, it is simply not practical (or useful) on the serial link itself!
"An attacker therefore just has to wait for a valid user to authenticate before hijacking the machinery by firing his or her own commands at the open TCP port."
Firstly, this implies a stateless mode of operation - else surely the box would drop the serial link / require re-authentication on a continuous tcp connection being dropped (as would happen if a bogus command was received from elsewhere)... So.... WHY????
Secondly, connected to the internet? WHY????