Mandatory step missed in the final line
"Or, perhaps, unplugged, replaced, and dropped in the skip."
Between "unplugged" and "replaced" needs an "accidentally set on fire". </BOFH>
The travelling side-show of industrial control kit insecurity continues, with an outfit called Red Lion being called out for hard-coded credentials on a wireless access point. ICS-CERT has issued an advisory noting that the company's N-Tron 702.-W industrial wireless access point has hard-coded private keys for SSH and HTTPS …
I have considered working at a company doing a lot of industrial control... however I decided against it.
The problem is that the people working there are still stuck in their 1990s mindsets and technologies. Even if they wanted to change, they can't because they are stuck with brain dead 1990s technologies like OPC (OLE for Process Control).
Those people haven't learned about Unix so they think OOP is the only way to go. They even actively work on things like "SCADA in the Cloud".
http://www.waterworld.com/articles/print/volume-28/issue-10/editorial-features/cloud-based-scada-alternatives-traditional-systems.html
Such a work environment probably is completely unbearable to anybody with the slightest knowledge about security. That's why those people aren't found there.
plenty of peoiple might if they had set up secure tunnels etc.
Its total cobblers to talk about this or that piece of kit in itself being insecure, when what is required is overall security of whole networks.
I remember asking a security consultant 'what is the weakest link in their Internetwork security' and being answered 'the dial up modems to their windows PCS the staff plug into their DDI numbers in order to be able to work from home'
Because the corporate firewall denied them internet access...
" Who would let a serious industrial control system be run from the cloud."
Well we shouldn't forget that this is exactly how many of the driver-less car systems are being envisioned...
The issue with "the cloud" isn't so much the "seriousness" of the application, but the criticality of time and failure modes. So for example a river management system probably doesn't need millisecond interactive control responses and if communications did fail what would the consequences be if nothing happened until a person could be got on site. This naturally is different to say a pump storage/hydro-electric power station where you do want things to happen in seconds and hence you will have both control systems and people permanently on site - but then even these are effectively managed from "the cloud" given they only do stuff in response to a call from some operation's centre at the other end of a comm's cable...
Reading between the lines, I would presume the vulnerability is in the AP's management interface, as I don't see where else the AP would need to be aware of SSH and HTTPS sessions. (The document does not go into any detail as to how the AP supports WPA2-Enterprise mode of operation and hence whether the vulnerability has any impact on WiFi security.)
From memory, Cisco AP's also contain hard-coded manufacturer's credentials, but I don't remember whether the certificate was unique to each AP or not, but you could load . Looking at the N-Tron user manual, the capabilities of these devices look very similar to the typical domestic xDSL/wifi/LAN router (rather than a Cisco enterprise AP) hence I wonder whether a similar issue is lurking in equipment from Netgear, D-Link, Draytek etc...