5 ms·
My graduate project at university was about air-gap malware, soft TEMPEST and hacking on industrial PLCs (S7-300, Stuxnet and all that :P). What terrified me m
by 9214 9y ago
My graduate project at university was about air-gap malware, soft TEMPEST and hacking on industrial PLCs (S7-300, Stuxnet and all that :P).
What terrified me most is not only the state of ICS nowadays (it's pretty much fucked), but also the fact that cyber-security vendors try to make a profit from that by shoving their products down the throats of scared managers.
And what @donquchotte says is pretty much true - on facility there I practiced, all PLC were connected via TeamViewer to company network, passwords were written on stickers and slapped on monitors. They used Modbus over TCP, plain-text packets easily viewable with Wireshark.
On the first day I accidentally broke my S7 because of wrongly uploaded configuration, it took them 3 days to find some special Siemens laptop to connect to this PLC and reset it. Also tried to play around with Metasploit and follow the work of Beresford [1,2], but the most trivial attack of mine was just flood on PLC's IP with random junk - it stopped responding to any commands.
[1]: https://www.youtube.com/watch?v=33kouEKm0zo https://www.youtube.com/watch?v=33kouEKm0zo
[2]: https://github.com/moki-ics/s7-metasploit-modules https://github.com/moki-ics/s7-metasploit-modules
- lima 9y agoThe first time I tried to automate the S7-1200 web UI, it crashed hard when I sent a POST requests with an empty body. These things do not belong anywhere near the internet, patched or not.
- daemin 9y agoPretty much built for someone that knows exactly what they are doing. Like they've read the manuals cover-to-cover and taken an exam.
- blincoln 9y agoAn industrial control system that crashes when it receives an unexpected network request isn't built for someone that knows exactly what they are doing. It was built by someone who wanted to expend the minimum effort possible and make contingency-handling someone else's problem. This isn't just about hacking. A device that crashes hard when it receives a POST with an empty body may do the same thing if there's a physical glitch with its connection, or if a cosmic ray flips a bit somewhere. Devices that control industrial machinery should be more reliable than that. If this were a hobbyist project, or a toy, that would be one thing, but these are specialized devices that cost a lot of money. They're fragile liabilities that don't belong anywhere near a shared network.
- folkhack 9y ago> An industrial control system that crashes when it receives an unexpected network request isn't built for someone that knows exactly what they are doing. Yeah - I can see even the simplest of network vulnerability scans wreak havoc on a device like this.
- Parcissons 9y agoIts enough to just plug in a cable into two switch ports.
- daemin 9y agoYeah, that's the reasoning someone needs to use as to why something like this exists. It only works at all if you everything exactly correct.
- karmicthreat 9y agoI am not convinced air-gap is even a good idea for PLC networks. More and more these systems are developed by consultants and OEMs. Who then need to service and troubleshoot them. I work for an OEM with this problem and it plagues me all the time. "Sorry, I can not fix your issue without access and I am not flying someone down for this." This business reality is going to get worse as time goes on. Companies would be receptive to change if people at the executive level were educated first. The carrot being more cost effective system development.
- junkcollector 9y agoI would argue that air gaps are critical in ICS networks and PLCs because it is an extreme safety risk to push a potentially bad update from offsite without clearing the operator. The major issue will be pushing back against cost pressure from management. This is already turning into a major problem with IOT devices from supposedly reputable companies i.e. home thermostats that let pipes burst because of a bad or incorrectly pushed update. Now consider if that bad update could instead kill someone.
- snowwindwaves 9y agoThe operator should never be in harms way period. If they are working on equipment it should be physically locked out, say a valve would have a 6" diameter pin through the mechanism and a padlock on it so the pin can't be removed except by the operator, and electrical equipment is powered off and the breaker is locked in the off position. If they put themselves in harms way they will eventually be fired for unsafe work. bad updates are bad updates. they are incompetence on the part of the programmer. but the worst they should be able to cause is minor equipment malfunction or the physical system has been poorly designed.
- junkcollector 9y agoI think you misunderstand. When maintenance is being done on the machine itself, yes you are going to do a lock-out tag-out routine. On the flipside, if you remote push the update and it contains for instance, a register read error on the rate controller that shifts the bits by 1, the operator's first notice us going to be when he loads it up and the ensuing chatter violently throws the work piece. Or something dumber, maybe they pushed a temp variable to the wrong type of memory (say flash eeprom) that updates every cycle of the control loop, and then did a push to an entire line of manufacturing equipment. Congratulations, all of those are going to brick in an hour or so when the memory hits it's maximum write cycle lifetime and you'll have to get new boards shipped in while your entire line is down. Remote pushing needs to be handled very carefully when controlling real world equipment.
- laythea 9y agoI work in the industry and I can definitely say that these things aren't built to be internet facing, but nor should they be.