Posted
by
Unknown Lamer
on Thursday January 10, 2013 @03:57PM
from the easier-that-way dept.

Trailrunner7 writes with news of the continuing poor state of security for industrial control systems. From the article: "Never underestimate what you can do with a healthy list of advanced operator search terms and a beer budget. That's mostly what comprises the arsenal of two critical infrastructure protection specialists who have spent close to nine months trying to paint a picture of the number of Internet-facing devices linked to critical infrastructure in the United States. It's not a pretty picture. The duo ... have with some help from the Department of Homeland Security (PDF) pared down an initial list of 500,000 devices to 7,200, many of which contain online login interfaces with little more than a default password standing between an attacker and potential havoc. DHS has done outreach to the affected asset owners, yet these tides turn slowly and progress has been slow in remedying many of those weaknesses. ...The pair found not only devices used for critical infrastructure such as energy, water and other utilities, but also SCADA devices for HVAC systems, building automation control systems, large mining trucks, traffic control systems, red-light cameras and even crematoriums."

Part of the problem is the engineers designing them. They don't understand the sandbox they're playing in. It isn't in their culture and they don't know that they should secure them much less how to. I'm starting to see organizations hire product security engineers now to try and institute this stuff into the products but they seem way behind the curve IMHO.

The thing with security is... outside of the curve, there's outside-the-box thinking, comprehension and competence that are involved. You're trying to outsmart potentional attackers, not follow a white paper that they have access to. "Behind the curve" is false because there is no curve, there's just secure and insecure practices. The exploit will either work, or it won't. This only applies at the application level btw.

Two factors have caused this - one, the assumption that those with the knowledge to cause havok have better things to do with their time, and two, the assumption by manufacturers that factory floor equipment will be physically seperated from the public (and by implication, the Internet).

All the changes that have resulted in this situation or probably very recent (10 years), and are in situations where legacy networks and equipment have been bolstered by or re-connected with new stuff by young IT-types, not engineers, who probably had no idea all the industrial stuff wasn't secured!

They are now used to checking their nuclear powerplant controls from their iphones (ok maybe that example is exgerated to make a point... I hope!) If you now make it secure they will throw a hissy fit if they can't get their reports.

They will call IT to put it back on the internet to fix it. Once the cat got out of the bag it is hopeless.... 2 factors.

The sales team sold it and told their engineers to include it too so they can sell more units. This was the selling po

and two, the assumption by manufacturers that factory floor equipment will be physically seperated from the public (and by implication, the Internet).

You have to really wonder how it is that 1) we are running out of IPV4 addresses, and 2) all these factory floor and crematoriums manage to expose their SCADA devices to the internet with public IPs

How much penetration did these researchers have to engage in to get access to things behind routers? (I ask this because I refuse to believe there are that many companies wasting public IPs on process control computers who have not heard about firewalls and VPNs).

for example to make a free phone call on the repeater's autopatch system here locally just key up on 146.820 (-.600 repeater shift of course) and press *7 unkey the controller will say "Autopatch activated" you will then hear dialtone, the controller is programmed to not allow long distance calls at least but you can make any phone call you wish. It's a little wonky as it's not full duplex, but works, I use it when calling home that I will be runn

The Windows PC is the Scada controller I'm out of date so i could be wrong but most if not all Scada systems sit on top of windows and for a very very long time. Windows versions can be from 98 upwards.

First you tried to prove me wrong about AdBlock - and you're still wrong, you're so stupid and old that you haven't even read and understood that AdBlock prevents the browser from even using the OS to lookup anytning!

Also, your condescending assumption that I know nothing. I'm so sick of it. Take a look at yourself, scumbag, you're the one doing all the cyberstalking here!

Oh, and I've been trying to hold off on this one because of the potential backlash -

Where's the developers of Firefox to correct you when you need them? I don't care about tcpip.sys and all that, and neither does AdBlock - which uses it's own list during page parsing, yes, just after the 1st DNS for the page and then before parts (ie ads and plugins) are loaded (and do their own DNS). Before!!!

Also, other people have told you before that your silly methods poll local webservers. i.e. 10-30 seconds for each element in your HOSTs file rubbish.

Number one, never actually trolled you via TOR, just threatened to, because you were being an abusive scumbag.

Number two, it matters not one iota that tcpip and HOSTS load before Firefox, and AdBlock - it matters that AdBlock does not use HOSTS to process it's blocking and is therefore before it in the execution cycle that matters here! In fact, it makes HOSTS completely redundant, as many others have tried to tell you. In the meantime, I earn Karma because I am calm, correct, and not an abusive old scumbag

I have done. Quit stressing, it makes you look old and bitter. I'm sorry that you can't face how wrong you are, both about HOSTS and the way you're treating people, but it's not really my problem. All you're doing at the moment is adding to my Karma...

I never bombed anyone like this, stalking them across slashdot and claiming crazy things about their gender.

Also, you're still talking bullshit because this isn't about whether HOSTS or tcpip loads on boot, it's about whether AdBlock uses it at all (which it doesn't) and the requests to local webservers caused by HOSTS! Shut up and go away you smelly trollbag! lol I love seeing you angry.

Can someone PLEASE post the links to all the red light cameras (down here they're also fucking speed cameras useful for nothing better than revenue generation which has essentially be admitted to by city)....

It's also the idiots implementing these systems. One of our international offices moved sites over the Xmas break. The contractor installing the HVAC controller at the new site wants me to open up the firewall so any public IP can access the device on port 80. Apparently it's safe because "...it's running Linux".*sigh*

Don't blame me, I'm just the guy that wrote the specification and the software.

- Management told me to remove security. Too much effort (what's a linter? Stop using it. Shorter passwords. Private network? Can't we just use a cable modem? "Fuzzing" ? Takes too long... turn it off)- Management told me to remove encryption. Too hard to read and debug over-the-wire for the field tech, who might have to run a program and click a button to decode traffic. Or worse, move a jumper to "debug".- Management had me source the cheapest possible components, and try to use software to recover from their faster and bizarre failures.- Management had me install DHCP support into the SCADA devices, so it could be hooked onto the easiest possible network.- Management had me unlock the cellular modem so it would connect to any tower.- Management had me use public DNS in my SCADA system, because running our own would have cost an afternoon.- Management had me write a 4 digit backdoor PIN into all hardware, that could not be turned off.- Management had me specify, design, and write a remote firmware flash interface supporting and utilizing most of the above.- Management had me write a remote reverse serial console proxy available by pointing your web browser at the right URL.- Management had me use public rdate servers rather than pay for an accurate internal clock.

Look, I'm just a software engineer. I know a bit of hardware. I let people know when things are dangerous. I quote them times and estimates and costs.

I quote them expected failure rates.

They settle on the cheapest most disease-ridden stray cat they can find starving in a ditch and sell it as a liger. And your engineers somehow buy it.

Look, I may not know everything about securing them -- but most of these problems aren't caused by inept engineers, they're caused by management and sales cutting corners to buy their third porsche.

I'd *LOVE* to see a reverse bounty program. Sell the management induced bugs in your software to a company client for legal protection against lawsuit, and five years of contractual consulting rates to clean it up.

As a SCADA/Integration guy, I can say that most controls engineers cringe at the thought of their networks being open to the internet. It's usually managers and bean counters who demand real-time global data reporting who drive this lunacy. It's not as simple as it appears.

I've lived in the industrial controls world for quite a while before striking it out on my own... "real-time global data reporting" doesn't require a world-accessible control interface, or even an open internet connection. It's much simpler than you're making it out to be. Hell a basic VPN connection back to HQ that puts the remote sites on the corp LAN (where all the data aggregation can take place and be accessed for "dashboards" and whatnot) would be a major step up.

I worked as a Controls Engineer for 6 years designing, installing, and commissioning PLC / SCADA systems. The clients were anything from large steel mills, manufacturing plants, government, and even propulsion systems for naval vessels. My company was contracted to install these systems and sometimes train the customer's personnel to then handle problems or make additions to the control system if necessary.

The personnel were more often than not your normal plant electricians and if we were lucky an actual engineer, but usually not one with much IT ability. Today's controls systems almost always have a normal Ethernet network sometimes utilizing commercial OTS network switches. This is a big change from 10-15 years ago when the communication media was mostly proprietary for control networks.

When a problem arose I've seen these guys just unplug and plug in CAT5E Cale's wildly in the hopes of rectifying a problem that brought a process line or machine to a hault without much thought as to where the issue lies. Other times the plant manager will want to view the SCADA data from his office so he will instruct an employee to just bridge the control network to the business / office network.

It's really not the fault of the people designing the systems. In the end the company that owns it takes the blame. The vast majority of customers will not pay extra to have their employees trained on these systems and I've never seen one concerned with security. My company sent me to Certified Ethical Hacking training in order to try and make our systems more secure, but in the end the systems integrator's hands are tied.

I would blame the engineers less than the vapid, bonus-seeking salesmen telling them to make access as stupid and easy as possible to allow mid-level managers to check in on things without having to get off their asses or sometimes even off the golf course. As usual, most of the blame can be laid at the foot of that three letter monument to sloth and incompetence: MBA.

I am a Controls Engineer and have worked at several companies and you are right on part of the problem.

There is more to it though. At many places, there is fighting between IT and Controls because IT thinks they know everything about how every computer should work and every network. They come in and try and make changes to fit their standards without realizing they just shut down production.

I have had some IT people that I fought with all the time, some who have ignored me and let me do my thing and a few

How on earth can you be fighting with the IT people and the 'requirements' the control people have?What 'requirement' for the network or security 'would not work' on the Control side?Can you give me a specific?

BackgroundI work for a company with large, dangerous machines that are controlled by SCADA\PCL's. The process controls Windows PC's and various PLC's, sensors etc. and network (normal TCP/IP network and equipment) are under the full control of the Maintenance Supervisor (former electrician) and his e

I was just talking to my boss about this subject today. The merging of mechanical and network engineering is still considered a "new" development, often times the engineers designing the system for a building doesn't fully understand the IT that it rides on. It's a problem, and it's being addressed, but as the submission states there's a huge lag time with huge companies, so it'll continue to be a problem for a while.

I was just talking to my boss about this subject today. The merging of mechanical and network engineering is still considered a "new" development, often times the engineers designing the system for a building doesn't fully understand the IT that it rides on. It's a problem, and it's being addressed, but as the submission states there's a huge lag time with huge companies, so it'll continue to be a problem for a while.

Very insightful but the problem is worse than just the merging of mech/network engineering within a single company. There is a sea of dysfunction washing over the different companies, systems, processes, players and roles. There is a big mess to clean up and although it galls me to say so, I think some sort of legislation may be required both in terms of setting standards and of assigning accountability for poor systems. I won't hold my breath waiting for help on this side.

Some stuff I know to be true:

- CEOs & CFOs are motivated by share price and stock performance issues; they consider IT infrastructure to be an expense item to be minimized. Security devices are cheap but no in house expertise is fostered, and external advice may be poor or ignored if it leads to inconvenient costs. Truck drivers and drag-line operators are valued positions at a mining company because what they do generates income and income to cost is readily calculated; network designers and IT security admins are just an expense item to be minimized. They generate no obvious positive monetary benefit. More trucks/draglines/drivers/operaters = more income and more profit. More IT people = less profit.

- Equipment vendors may be experts at their specific technology but the control programs are not part of their core knowledge. An example I have seen: although the vendor uses some robust logic controllers in the system, they all tie back to a custom control layer built originally by a summer co-op student for a lab demo. The control program does have login security but has never been through any sort of security audit. All system functionality funnels through this layer. It does have a beautiful presentation layer built by a contract software house. BTW, although the login has some protection, by default there is a network API that is always wide open and can not be shut off or everything crashes. No one knows why. If Production Company A buys production equipment from Vendor Company B, the security vulnerabilities are provided at no extra charge. None of the security issues are documented by B (they largely don't know they exist) and B has no good advice to offer on security issues in any case. The sales droids typically say security is not an issue and their track record speaks for itself. No serious events must mean the product is great.

- Even if production security is seen to be an area of need, corp culture and politics keep anything meaningful from happening. The IT expertise that a company does have is usually focused on internal desktop and financial/HR security issues. They know nothing of the SCADA world which marries physical devices to the abstract world of networks and computing. Worse, the IT division (complete with VP or EVP) views any use of computers and networks outside of the corporate LAN to be a threat to the corporate well being. The IT division sees the production network as a threat to the corporate LAN (usually the threat is worse in the other direction!) so production must run outside the corporate firewalls. This is ok, but IT management actively undermines development of a production side IT division as that is a threat to the corp. power structure. Production networks are built and run by engineers who are smart and have a side interest in computing but whose areas of expertise are power control or chemical production or mechanical systems.

- There is no widely accepted set of standards for production network design and deployment. Production network implementers invent the wheel again and a

At one place I worked, contractors went into a remote office to install a phone system and ended up wiring a Win2003 server directly to the Internet (and the internal network) so that they could log into it to make changes to the phone system.

I saw a gas station and one of the pumps there was in "maintenance mode" or something. Anyway, it wasn't working and on a little LCD display on its body there was an IP address. It wasn't a private IP so I noted it down and when I got to work I tried accessing it through HTTP. Well, what do you think? A nice web-based username+password interface popped up.

Now I ain't a hacker and I really didn't try anything, but I'm sure a skilled security professional would have hacked right through that interface. It's really amazing how many poorly secured interesting devices are out there.

I found I was wasting a lot to time reading irrelevant sigs so I turned off sigs in my settings.My sig attempts to encourage others to realize the waste of time in reading sigs.However, if you like to read sigs, please continue to do so (and I hope you will enjoy mine).

I have worked for a large world wide organisation where SCADA and similar on-line systems are very prominent. After raising concerns and asking ports to be locked down or default passords to be changed, there was a lot of departmental fighting over who's responsibility and usually after the battle royal of e-mails everyone would forget until the issue was brought up again.

Too much of a not broke don't fix attitude in smaller companies and bureaucracy in larger companies over responsibility.

Bah Humbug. I also worked at a place like that; on the engineering side though, not the IT side: It's often the case (in my experience) that the SCADA systems are coded in such-and-such a manner as to expect so-and-so ports to be open.

IT comes down and tells people 'oh no you have to lock all these systems down; kill all ports except HTTP and SSH' or some such.

But, you know.. We're actually using these ports. We can't just 'turn them off' as if this was some kind of Ruby-On-Rails website that for some reaso

You mention SSH. SSH does have this thing called port forwarding, you can tunnel traffic through an SSH connection. More flexible are Virtual Private Networks. You can also limit access to known IP addreesses. There is no reason AT ALL why these ports should be accessible over the internet for everyone. If the SCADA system itself doesn't provide adequate security put it behind a device that does. You can still use these ports, but not everyone can. It doesn't have to be on or off, it can be on for who's aut

Pay a couple more people to go through the list regularly and poke around, turn things on and off. Make it hotter on cold days and colder on hot days. Take pictures of cars running green lights, shut down all but one elevator, etc...

Just being mindful not to hurt anyone.

It'll soon be cheaper to fix the problem than to waste resources cleaning up the mess.

When I read; large mining trucks I immediately thought how awesome it would be for geeks to take them over via SCADA devices.

Wow, the large dirt hill fights you could have. The swimming pools of snobby rich people, mysteriously filled in. Monster truck rallies interrupted by attacks of 7 story Mega Monster Trucks. The sheer coolness of surrounding WalMarts with huge walls of landfill waste.

"I'm down here at city hall, and it's absolute mayhem. A large truck, bigger than the building in front of me, is now rolling over all the toll booths, after dumping a huge pile of what must be a mouton of coal on the doorstep of Matty Moroun's estate."

Those giant mining trucks aren't 7 stories tall only 3 to 4 story range, the shovels they use are probably in the 7 story range. Personally I would love to see a rampaging bucket wheel excavator but those things are really damn slow. The 400 ton (363 metric tons) trucks can really get up and haul ass as they can top out at about 45 mph and have a G.V.W. of 1,375,000 lbs (623,700 kg). As my oldest son (4 years old) put it the first time he was up at Mine View in the Sky "They have a big dump truck [constructi...ipment.com] and a litt

I found it completely by accident by searching for the part number of one of the modules that happened to be in the chassis with the controller and the ethernet bridge. The ethernet bridge has its own web page which automatically displays the contents of the chassis, with links to the modules.

I added a controller-scoped tag to it called "ICanSeeYouFromTheInternet", and a tag description of "Please put your ENBT on a private network"A couple days later it was gone.

For those not overly up to date on their acronyms:
"SCADA (supervisory control and data acquisition) is a type of industrial control system (ICS). Industrial control systems are computer controlled systems that monitor and control industrial processes that exist in the physical world. SCADA systems historically distinguish themselves from other ICS systems by being large scale processes that can include multiple sites, and large distances."
http://en.wikipedia.org/wiki/SCADA [wikipedia.org]

There are controls systems and controls software with passwords hard coded and some that are even burned into ROM - not EEPROM. The problem is that manufacturers have to be able to provide tech support and sometimes that tech support is to non-tech people. The prevailing attitude when I worked in the field was " who would be interested in the system anyway?" Security based on apathy I guess... IT people used to avoid the SCADA equipment because they needed to understand