SCADA Hacker: Water District Used 3-Character Password 213
Trailrunner7 writes "In an e-mail interview with Threatpost, a hacker who compromised software used to manage water infrastructure for South Houston, Texas, said the district had HMI (human machine interface) software used to manage water and sewage infrastructure accessible to the Internet and used a password that was just three characters long. The hacker, using the handle 'pr0f' took credit for a remote compromise of supervisory control and data acquisition (SCADA) systems. Communicating from an e-mail address tied to a Romanian domain, the hacker told Threatpost that he discovered the vulnerable system using a scanner that looks for the online fingerprints of SCADA systems. 'This was barely a hack. A child who knows how the HMI that comes with Simatic works could have accomplished this,' he wrote in an e-mail."
How about passwords that don't have to charged 30 (Score:5, Interesting)
How about passwords that don't have to charged each 30 days and you can't use the last 4 passwords.
Password not the problem (Score:5, Interesting)
I'm in this line of work.. The password was not the problem. Even the hacker is thinking like 'corporate IT' would think in terms of security. The plant floor is different.
Here's the rule: A computer that controls industrial machinery should not be connected to the Internet. The only part of an industrial process that can even possibly be connected to the Internet is historical data and alarming.
HMI software is typically a set of screens representing the automation parts of a plant process. This means that in order to start/stop a motor or energize a valve, the screen is required. It is insecure to put a password on that screen. Yes.. insecure. The priorities at a plant are different. It is always the most secure to allow control of the plant to the people at the plant. There are physical E-stop buttons on control panels in case of emergency, but the E-stop is not the end all to prevent industrial disasters. For example, if a person has his hand caught in a valve, hitting the E-stop may cause the valve to move. Another example would be an exothermic process where explosive gases could accumulate in the wrong parts of the process, hitting the E-stop may not get rid of the gas. The operator at the plant is in charge of the process - it is critical that he or she always have control over the system.
Therefore, don't connect your plant floor to the Internet.. unless you want China to be able to control it. If white-collar executive-type people want to see pretty screens, give them historical data.
By contrast... (Score:5, Interesting)
Some government sites have these onerous password requirements e.g no fewer than 15 characters, no consecutive characters even if they are a different case, at least one numeric and at least one punctuation. It's not surprising that coming up with something you can remember that fulfills these requirements is a bitch. Oh, and you have to change it periodically. IMHO, this naturally leads to writing the damn thing down somewhere.
Epic Fail & no-win situation (Score:5, Interesting)
Network admin for another city govt in Texas here... albeit a very much smaller city.
1) first of all, it's absolutely nuts to place your water purification SCADA (or even your wastewater plant's SCADA) onto any network segment that's accessible from the public Internet, and we in the IT department know that all too well, however we're not "in charge" of the SCADA systems and have essentially zero authority to do anything about it. Part of the problem here is that the folks who *are* in charge of these systems are thoroughly aware that we in IT know how to better secure their systems, but do not want us involved in any way because our security will "make things too hard for them to do their jobs".
2) The folks who run the SCADA systems on a daily basis know only two things about systems security: 1) diddly and 2) squat. They are water process and industrial chemistry people, not computer people, and it shows big time.
3) The vendors who supply and support the SCADA systems feverishly demand that the SCADA systems be easily accessible over the Internet for their convenience for remote support, and frankly do not give a rat's ass about the customers' security... their response is that security is not their problem it's ours.
So, it's no wonder these systems are getting hacked and it's going to get worse as time progresses.
Well that makes it OK, then! (Score:3, Interesting)
Re:and why... (Score:4, Interesting)
No one can hack it? Yeah right, until someone stuffs some firmware into the ethernet driver that reverses the RX and TX lines.
And they would install this firmware on the PLC how?
Re:3 characters can be enough (Score:3, Interesting)
Disabling access after X tries might be enough where the token to uniquely identify access is relatively well-defined, like say your ATM card, and disabling access for that user doesn't de-facto terminate the system (i.e. other ATM users can still use the machine with their credentials after it eats your card).
For admin-access to such systems over the internet it's dangerous to disable the admin account after X tries, because then you lose remote administration functionality of a potentially critical system. "Ah, but you can reset with physical access" you will say - yes, true, but this is a critical system they put *on the internet* in the first place, for better or worse, probably because physical access to that system is pretty difficult for the poor sod designated the "administrator" (disused lavatory, beware of leopard, etc.). Who knows how long the system will be offline for administration until the first opportunity for physical access.
The disabling of (admin) access after X tries also effectively creates a DOS attack against that system. I don't know the login procedure of this particular type of system, but assuming it's username/password, you could DOS the system by spamming all kinds of *usernames* with X repetitions of the wrong password to disable them. Preventing the DOS attack would require hard-to-brute-force usernames - the username becomes the secret, not the password.
It's probably also possible to spoof session identifiers for a hacker to evade repetition detection.
I think the SCADA system can only lose in this kind of scenario, unless they have a password that is very hard to crack within its valid timespan. Or until they finally figure out that putting critical systems online with weak passwords or account disabling is probably not such a good idea.
Re:Password not the problem (Score:5, Interesting)
And a guy I know at another plant described "adversarial SCADA" to me where two separate systems from two separate mfgrs and two separate consultants, one run by an "operator" and reporting up the operations management chain all the way to the board, and another run by "safety" and reporting up the safety management chain all the way up to the board.
The operations guy and his SCADA system do whatever they want whenever they want, but if the safety guy and his SCADA detect an overspeed or an overtemp or underpressure then safety guy and his scada cuts power to the operations guy and his scada. Also operations guy can "get even" with safety guy because he has relays installed that can simulate sensor failure, and the safety guy has to respond within X minutes following whatever procedures, and the operations guy is presumably intelligent enough to only perform those tests when operationally convenient.
Also although technically either the safety guy OR the operations guy can punch the "give up" buttons, because the safety guy does not answer to the bean counters, that means the dump tank and suppression buttons are for all intents and purposes exclusively operated by the safety guy... The operations guys have training issues in not bothering to even know how to operate the fire suppression valves, for example. Which is bad, because the centers are geographically separate, so if a tornado wiped out the safety center, or even just a failure or a hack event took it out, the ops guys might literally not know how to put out a fire at the plant, even though they are technically capable.
This is a fail when weird plant conditions require jury rigging and close coordination, and also a financial failure because the independent supplier of the operations scada knows the plant shuts down if they try to change out, so he's free to charge as much as he pleases.
Hack our safety scada yesterday? who cares, ops will safe the plant. Hack our ops today? who cares, safety will safe the plant. Hack both separate systems with separate designs and separate manufactures tomorrow at the same time? who cares, that has to be an inside job...
Re:Predicting Government Response (Score:5, Interesting)
You think this is funny, eh?
Richard Feynman had a story about how his hobby was safe cracking. He cracked a cabinet that had a combination lock on it and then told the people who mattered the security hole. Did they upgrade the security on the cabinet? No, they banned him from the room. Problem solved.
--
BMO
Re:How about passwords that don't have to charged (Score:4, Interesting)
At a larger scale: say your China and you are hacking power plant passwords to be able to shut them off (not blow them up). If the passwords are cycled frequently you likely will always have some passwords you've cracked and some you haven't, but the chances that you'll get a sufficient subset of the passwords cracked so you could completely bring the power grid down in a geographical area is remote.
Re:Predicting Government Response (Score:2, Interesting)
Oh that's just illogical and silly. Obviously they needed to ban all safe crackers from the room, not merely Richard Feynman.